IT Pro 記者の眼「あなたの知らない超高速開発」 は、日経コンピュータ特集記事「超高速開発が日本を救う」と連携したレポートです。この記事についてのさまざまな反応を、はてなブックマークで知ることができます。また、Twitter でも多くの反響がありました。
コメントは「すごい」と「懐疑的」に別れていますが、それはこの市場がまだ黎明期であることを示しています。いずれも「使ったことがないので評価しようがない」という点で一致しています。
ここで気になったのは、"超高速開発" が開発ツールと結びついてしまい、ツールの良し悪しで語られるのであれば、この記事（提言）の意図が伝わらないのではないかということです。BRMS という分野の良し悪しという議論の前に、そもそもなぜ、このような動きになってきたのかという背景を考えてみます。
先が暗いといわれる現状の SI 業界の解はどこにあるのか
多くのブログで SIer の先が暗い、こういうデスマーチがあったという意見があり、SI 業界が大好きな人間の一人として、残念に思います。しかし私の仕事は共感することでも同調することでもなく、どうすればいいのかという具体的な方策を提案し、実践することです。
私は、今の SI 業界の問題の原点は、（業務アプリケーション）開発は属人的であり、価格に対する成果物の品質が開発担当者によって大きく変わるという内部構造にあると考えています。ただ、これ自体は人がシステムをつくるという以上、根源的な部分なので変えようがありません。
真の問題は、この構造を前提に「より安く、より高品質のシステムを提供しよう」とやってきた取り組みが、間違った方向で進んできたのではないかということです。
- 人月単価というビジネスモデルを工程全体に適用してしまった。本来、人月単価制度はコンサルティングや要求分析では有効だが、製造や運用という部分にはそぐわないのではないか。
- 高いスキルをもった技術者は、そうでない技術者の数倍から数十倍の生産性がある。これは時間短縮につながる。この時間短縮という価値をお金に変えることができなかった。それどころか早く仕上がると人月単価の視点では売上が減るという矛盾が生じた。
- むしろ低スキルでも画一的な旧式技術で固め、大量動員するという開発体制が売上に貢献してしまった。そのためお客様との関係を築くよりも技術者の人材派遣が儲かるビジネスモデルとなり、その果てにオフショア開発が登場した。
- お客様（発注側：ユーザー）は現状の開発方式に不満を持ったとしても代替手段を求めるのではなく、むしろアウトソーシングや自治体への1円入札、丸投げ発注などによって、ますます SI 業界の構造問題を悪化させる方向で付き合ってきた。自らの業務ルールはパッケージソフト内にブラックボックス化されていったため、システムへの主体性が失われてしまった。
このような現状に対して何ができるのか？ 最初に取り組むのは、お客様に対して SIer の価値を認めてもらうことではないかと感じています。
お客様が感じる SIer の価値
「仕様書どおりにシステムを開発すれば SIer の価値はある」
多くの方が漠然と "No" という感覚をもっているのではないでしょうか。存在理由にはなるかも知れませんが、お客様へ感動を与えることはできません。感動がなければ価値として評価されません。"パートナー" ではなく "業者" そして "IT土方" に格下げされるのです。
景気がよかった時代、開発の仕事はたくさんあったため、そこまで配慮する必要はなかったかも知れません。しかし不景気が続く日本において、お客様から選ばれるためには感動という要素が必要です。
では SIer がお客様に与える感動の要素とは何か。私は三つあると思います。
- 他社にない、斬新な提案。（類のない機能、技術要素）
- 圧倒的な開発スピード。
- 圧倒的に安い価格。
ここで "斬新な提案" はいつもできるものではありません。また、プログラミング的な部分であれば、すぐに真似されます。（業務ノウハウがもっとも真似されにくいですが、これも賞味期限があります。）となると残りの二つ - 開発スピードと価格で感動を与えることが SIer にとって本質的に重要です。開発スピードの向上と価格の低下により、システムの細かい改変も現実的になり、結果として（お客様における）経営と IT の結びつきが強化されることが期待されます。
いわずもがな、多くの SIer がその価値を高めようとしてきました。しかし残念なのは "開発スピード" は異常な残業に、そして "価格" は人件費の圧縮によって実現されてきたことです。現場に負担をかけるという方法は、長続きしません。結果として、この業界に関わる多くの開発者を疲弊させつづけています。
正しい方向性は、少人数による大規模システムの開発
ではどうすればよかったのか。私は、例えば従来方式で 1000 人月と見積もったシステムを 10 名前後の技術者で対応することがよいというように考えています。仮に期間 1 年とすると 120 人月ですから、およそ 10 分の 1 です。少人数の方がコミュニケーションコストが低く、お客様と近い位置にいるので何かと有利です。
つまり 100名、200名の、スキルもばらばらな人材を集めるのではなく、少数精鋭を指向する。
プロジェクト費 = 工数 x 人月単価
という式において、工数を下げて人月単価を上げることが、SI ビジネスのあるべき姿だと思うのです。これは従来のビジネスモデルからの大転換を意味します。
この実現のためにはどうするべきか。これでようやく議論の出発点に立つことができました。
汎用的なプログラミング言語を極めるか、制約の中で超高速開発を実現するツールを利用するか
少数精鋭という方針のもと、具体的な実現策はいろいろ考えられます。優秀な人材を集め、汎用的なプログラミング言語を使いつつも従来より生産性を高めるという方式が、真っ先に思いつきます。
この方式はしかし "優秀な人材を集める（育てる）" ことを一定量、確保できるかという点が懸念されます。これを達成している（または目指している）SIer は少数ながらもすでに存在します。そういった信頼できるパートナーとなる SIer と出会えたお客様は本当に恵まれています。 しかし日本全国で、これから開発しなければならない業務アプリケーション案件はまだまだあります。人的資源には自ずと限界があるため、物理的にこのようなSIerだけでカバーすることはできないと感じています。
また、開発には所要時間や人件費だけでなく、その後の保守という問題も見逃せません。
多くの業務アプリケーションは "最初に一気につくって、あと何年も同じものを使って" いるようです 。しかし本来は "長期間にわたって、業務の変化にあわせて自らを少しずつ改変しつつ成長する" ということが理想です。作りっぱなしではありません。
その保守の過程で、技術がさまざまに変わっていきます。10年前、Visual Basic で開発したシステムや、IE6 限定で動作するようなアプリケーションを抱えてしまったところは、その後の OS のバージョンアップ計画で苦労しています。それは本来、コストをかけずに乗り切りたい話ではないでしょうか。
"超高速開発" として紹介されている開発ツールが便利だと実感するのはこのときです。数年前につくった定義ファイル（仕様書）を、最新版に読み込ませてビルドすれば、新しい環境向けにつくりなおされるのです。それに加えて、数年前には存在しなかったスマートフォンに対応するなど、嬉しい副産物もあることでしょう。
このような開発ツールは汎用的プログラミング方式と比較するとさまざまな制約があることは承知しています。それでも SI 業界が新しいビジネスモデルに自らを適合させようとするならば、次のいずれかの方式しかありません。
- 優秀なプログラマを育成し、お客様の要求をすべて満たしつつ、高い生産性を実現する。
- 開発ツールを使い、制約の中で超高速開発を実現する。従来のプログラミングは仕様の策定に代わる。
前者は、お客様の要求通りのものを開発するという（これまでと同じ）方針で、より生産性の高いプログラミング方式を学びます。開発ツールは無償かも知れませんが、代わって教育コストを負担します。仮に組織全体で2倍の生産性とするためには、相当の教育コストが必要です。（これは実際にやった人は痛感する数字でしょう。）そして2倍という数字は、かなり野心的です。組織によっては 5% の向上だけでも大変というところもあるでしょう。小規模かつ社歴の若い SIer には有利ですが、大規模案件に対応しにくいという課題もあります。
後者は、お客様の要求を開発ツールの制約範囲内で実現することになります。ここでお客様の満足度が下がると心配される人が多いのですが、その代わりに汎用プログラミング言語の利用では達成が困難といえる高い生産性（5倍から10倍に相当する）と、その後の保守性の向上が手に入ります。経験上、多くのお客様は制約が課せられても開発スピードと（工数減による）価格の低下を価値と感じます。すべての案件に適用できるわけではありませんが、後述するようにバランスをとることで適用範囲を拡げることができます。
開発ツールは "銀の弾丸" ではないが、ツールが進化しつづけていることは気にしておいてもいい
COBOL 時代から自動生成という発想はありました。"超高速開発" の記事が登場する前にも、何度もこのような（自動化という発想を活かした開発スタイルの）提唱がなされてきましたが、未だに標準にはなっていません。これをもって「開発ツールは銀の弾丸（問題をすべて解決する魔法のツールという意図）ではない」というコメントを聞くこともありますが、それ自体は否定しません。
それでも、時代時代において登場するこれらの開発ツールは着実に進化しているのです。初期の頃は、生成されたソースコードは可読不能でカスタマイズもできず、内部のパラメータもブラックボックスでした。また、自動化の万能性を追い求めるあまり複雑化し、開発者の制御ができないと判断されたこともあったかと思います。しかし現在はこれらの反省を踏まえて「生成されたソースコードの可読性があり、カスタマイズも可能で、ブラックボックスではなく良く知られた OSS のミドルウェアに依って立つ」というタイプのツールが登場しています。開発ツールでできるところと、人間がプログラミングによって解決するところのバランスをとるというハイブリッド型開発により、高い生産性・保守性を手に入れることができるようになっています。
10年、いや20年以上前の知識を元に「超高速開発などというのは空論」と結論づけてしまうのは、"羹に懲りて膾を吹く" ことに似ています。開発ツールに完全性を求めるのではなく、開発ツールを使いながら人間の力で補完するという発想であれば、銀の弾丸ではなくとも使い勝手はあります。（銀の弾丸でなければ使わない、というのは、その代わりどうするのかということもあわせて考える必要があります。ここで思考停止することは現状維持であり、SIer の価値を訴えることができません。）
まとめ
"超高速開発" とはツールの選定の話ではなく、ユーザー企業が気付き始めたニーズのことです。そしてニーズを迅速に提供することはSIer にとってのビジネスチャンスです。
そうであれば "超高速開発" を「ありえない」とするのではなく、これは SIer の価値を向上するチャンスになると考えることができます。それは SIer が自らの立ち位置を、良い技術者を他社よりも安く派遣するというビジネスモデルから変えることにつながっていくことでしょう。
どのような業種、業態にも問題はあります。現状はその問題を現場レベルで - 人によって乗り切ろうとするから - いずれも厳しいようにみえます。しかし少なくとも IT 業界なら、その解決のために、やはり IT を使うという発想が使えるはずです。これが日経コンピュータが特集した、開発ツールの存在理由になると解釈すれば、全体の構図が見えてきます。
補足：参考にした意見
(1) IT Pro 連載記事「東葛人的視点」のブログ「システムの運用と保守は分離、そして開発と保守を一つにしよう」
お客様（発注者）が目指す姿は、ここに示している "永続開発" でしょう。そしてクラウドの登場は、その敷居を確実に下げています。
(2) @gothedistancce 氏のツイート。
これがPaaSが目指す未来に思えます。メンテするのツライかもしれないけど・・・＞あなたの知らない超高速開発 - 記者の眼：ITpro nkbp.jp/GBji1R #itprojp
PasS のゴールは "超高速開発" のためのプラットフォームだと私も予感しています。多くの開発ツールが目指しているはずです。この競争の中で、各ツールはますます鍛えられていき、その恩恵は開発者そして利用者に還元されます。そのとき、これらのツールは開発の主流になっていることでしょう。（そしてその時期はそう遠い未来ではない... と感じています。）
