読者です 読者をやめる 読者になる 読者になる

日経コンピュータ2015年10月1日特集記事「広がる超高速開発」

日経コンピュータが最初に「超高速開発」というキーワードを世に出したのが2012年3月でした。それから3年が経過し、超高速開発の現状を取材する特集が組まれました。これは私たちにとって追い風になります。

「超高速開発コミュニティ」はこのキーワードを普及させるという目的で設立されました。(設立においては、日経コンピュータ編集部へ、言葉を使わせていただきたいと説明し、了承をいただいています!)あれから3年、次のような動きがありました。

時期 イベント
2012.03 日経コンピュータ「超高速開発が日本を救う」特集記事で、はじめて超高速開発というキーワードが登場する
2012.08 超高速開発コミュニティ発足。初期会員数は13。
2014.04 超高速開発コミュニティ第一回総会。3/末時点の会員数118。
2014.05 日経BP「超高速開発が企業システムに革命を起こす」出版
2015.02 日経コンピュータ「オルタナティブSI」特集記事で、自動生成SIを言及
2015.04 超高速開発コミュニティ第二回総会。3/末時点の会員数180。
2015.04 日本情報システム・ユーザー協会(JUAS)「ソフトウェアメトリックス調査2015」に超高速開発が登場
2015.10 日経コンピュータ「広がる超高速開発」特集記事

当初は眉唾と思われていた超高速開発ですが、2015年10月現在は、だいぶ市民権を得てきたように感じます。市場を一言で表現する、わかりやすいキーワードは重要だとつくづく思います。

さて記事中にもあるように、超高速開発とは

プログラムを自動的に生成するツールを用いた開発手法のこと。業務に関するルールを自然言語や数式、独自の開発言語で設計情報として入力すれば、当該業務を実行するプログラムがクリックするだけで完成する。

これによりプログラミングと単体テストの工程をほぼゼロに短縮できる。(中略)開発、さらには運用時の保守にかかる時間を大幅に削減できることから「超高速開発」と呼ぶ。

と明記されています。ここでいう「ルール」というのは「設計情報(リポジトリ)」と呼ぶこともあります。

記事中には、保守の削減効果が大きいという事例や、JUASの報告書における超高速開発の位置付けが分析されています。日本では、エンタープライズアプリケーション分野への超高速開発は各社の実験的な取り組みの成果がひととおり出揃い、これから本格普及期に入ることを予感させる内容となっていました。是非ともご一読をおすすめします。

超高速開発は "銀の弾丸” か?

記事中でもっとも興味深かったのは、富士通のユーザー会で超高速開発を研究するチームがコメントされたとする、次の一言です。

超高速開発は正しく使えば必ず効果が現れる。”銀の弾丸” はあると信じ、一歩を踏み出そう。

"銀の弾丸” とは、あらゆる問題を解決する魔法のツールという意味で捉えられており、そんなものはない(のに、それを追い求めるのは暗愚だ)という文脈で使われることが多いです。私自身、超高速開発は銀の弾丸ではない、と説明してきました。そんなものはない、というのがベンダー側(開発側)の主張ですが、ユーザー側(発注側)は「もしあるなら使いたい」という期待を常に抱いている、ということに改めて気付かされました。

ここでポイントになるのは「正しく使えば」という前提です。これは双方の溝を埋めるための大きな枠組みです。思ったものが何でも叶う銀の弾丸ではなく、いくばくかの条件を伴う *限定的な* 銀の弾丸であっても、そこに一定の効果があればユーザーは評価する、ということです。

多くの場合、その条件とはツールの特性・制約と考えられています。できるだけ自社の要件を満たすツールを探すことが必要ということで、本記事中にも「(ツールの)選び方で結果は変わる」と説明されています。そして私は、より広範囲な視点で「正しく使えば」を議論することが、超高速開発のより一層の普及にかかせないと感じています。

正しく使えば、とはどういうことか

すべてのニーズを満たす銀の弾丸ではなく、制約条件の中での選定ですので、私は次の視点をもつことを推奨しています。

  • 開発しようとしているアプリケーションは短命なのか長命なのか。短命であれば、今ほしい機能を満たしているツールがよいにこしたことはありません。しかし長く使い続けるなら、短期的な機能よりも、そのツールが提供するアーキテクチャや動作プラットフォームの柔軟さ、そして今後の開発ロードマップを含めて検討する方がよいでしょう。
  • 制約を乗り越えるためにはカスタマイズコードを追加する必要があります。そのコードは読み書きがしやすいか(保守性が高いか)もポイントです。私の理解では、どのツールも基本的な設計情報の書き方に差異はありません。やや応用的なテーマまで設計情報で書けるのか、そしてどの部分からカスタマイズコードの適用が必要になるのか、それはどう記述するのか、で大きな違いがあります。
  • しかしカスタマイズコードはできるだけ書かず、その機能をツールに取り込んでもらうのがユーザにとっては最良の選択肢です。そのための開発費をツールベンダーに出してでも、長命なアプリケーションであればあるほど、保守コストは安くなります。それを許容できるか、つまりユーザーの希望をツールの標準仕様として実装してもらえるか、がポイントです。

つまり選定の際には、今できることのマルバツ表ではなく、このような長期的視点での検討を行った方がいい、ということです。そしてもう一つ、これも記事中にありますが、ツールを効果的に使うために、ツールに否定的な従来のパートナーとの関係を解消し、ツールに精通した新しいパートナーと組むということ、そして社内の体制もこれにあわせて変えていくということも求められます。「新しい酒は、新しい革袋に盛れ」という言葉どおりです。

そして私はこの点に楽観的です。超高速開発コミュニティはその役割を担う場になるでしょう。ユーザー企業と、ツールベンダーがそれぞれの立場を明らかにしつつ「限定的な銀の弾丸」についての意見すりあわせを行い、よりベターな関係性を構築することは、これまでにない画期的な取り組みだと思います。

なぜならば、これまでのユーザー企業とSIerの関係は「言われたものをつくる」「安い方を選ぶ」「トラブルは訴訟に発展」という、とてもパートナーというには程遠い距離があったためです。それをアジャイル的なアプローチで埋めるという手法もありますが、エンタープライズな世界観では、自動生成による開発・保守工数の削減という切り口の方が効果が高い局面が多い、と考えています。ツールを媒介としてユーザー企業とSIer、そしてツールベンダーの三者が改めてパートナーになるという関係性を構築することが、三方良しの理念にも合致します。

超高速開発はこのようにツールの話ではなく、発注と開発の関係性にまで踏み込むほどの力がある、のです。そして嬉しいことに、その世界観を受け入れてもよいと考えるユーザー企業が増えつつあるということです。それがこの記事を読んで改めてわかった流れです。

Wagby開発スタッフ募集中です!