IT投資はバクチ並に難しいのである：上手なIT投資のためのシステム発注の考え方

IT投資が失敗する場合には大きく分けて2つのパターンがある。システムができあがらないということ。もうひとつはできあがったシステムが期待通りのものではないということ。ではこのような失敗パターンを回避するにはどうすればいいのだろうか。

[相馬純平（ケペル株式会社），＠IT]

なぜいまシステム開発の方法を見直さなければならないのか？

　現代のビジネスにおいてIT化による業務改善は必要不可欠とされています。IT投資は効果的に行えば飛躍的に業務の流れを改善しますが、効果的な投資により、理想どおりの効果が得られていないケースの方が多いようです。多くの企業がIT投資を行っていますが、その成功率は20％以下といわれています。中には失敗により、キャッシュフローを著しく損傷して倒産に追いやられてしまうケースすらあるのが現状です。

　では、どのようにしてIT投資は失敗してしまうのでしょうか？ IT投資における失敗には次の2段階があります。1段階目は、検討して作成した仕様どおりにソフトウェアができあがらないケース。2段階目はできあがったとしても、当初見込んでいた目的を果たせないケースです。

生産性を測定する単位はいまだに発見されていない

　1段階目をクリアするためには、決められた納期に、決められた機能のソフトウェアが決められた基準を満たす品質で納品できなければなりません。そのためには発注側は、何を作ってもらうのかを十分に検討し、その結果をソフトウェア要求仕様として作成して、ITベンダに発注します。ITベンダは受け取ったソフトウェア要求仕様を基に見積もりを行い、見積もったコストを考慮しながらソフトウェア要求仕様を動くソフトウェアとして作成します。そこで、受注したITベンダが見積もった工数が、実際掛かった工数を上回れば1段階目はクリアしますが、それが外れるとここで終わってしまいます。なぜ見積もりが外れてしまうのか？ これについてはさまざまな議論がありますが、ソフトウェアの生産性を測定する単位がいまだ発見されていないことから正確な答えが出ていない状況です。そのため、経験則に基づきそれにいくらかのサバ（バッファ）を乗せることで見積もりとしているのが現状です。

　2段階目をクリアするためには、1段階目で要求したソフトウェアシステムが完成したとしても、そのシステムへ投資した効果が期待どおりに得られなければなりません。しかし大体のケースでは目的とした効果が得られず、2次開発という名の下、要求を修正したり、追加したりします。これは最初に計画した段階では分からなかった事実が、検討をする時間やシステムの効果を経て分かってきたために発生します。

　ところが、一度設計して作り込んだシステムのプログラムコードを修正する手間は、最初から作るよりも工数が掛かるのが現状です。そのため、機能の追加修正コストは、システムが複雑になり、プログラムコードが多くなるに従って増加していく傾向にあります。ともかく、決めた要求どおりに作ったシステムが見積もりどおりの結果を組織にもたらすか？ という難題を発注元担当者が背負う形になってしまいます。

　このように、IT投資には、プログラミング作業コストを正確に見積もる作業と、最初に検討した要求の妥当性を見積もる作業の2つの不確実性に対処しなければならないのです。この2重の複雑性をうまく乗り越えられれば、IT化投資の恩恵を受けることができ、強力な市場競争力を一時的に得ることができます。

　なぜIT化投資がバクチのように難しいのか理解していただけたでしょうか？ IT化投資の失敗が原因でビジネスの価値を市場に展開できなくなることは避けなければなりません。このようなバクチにしないためにも、IT化投資の計画を見直していかなければなりません。

どのように解決すればよいのか？

　それでは本当に必要と思われる要求項目に対して重点的に資本を投資し、迅速にその効果を得ていくにはどうしたらよいかを見ていきます。一度で予算の限りの投資をしようとせず、システムの価値を効果測定により得ながら目的に沿った内容にしていくことが求められます。当初考えていた機能が実は効果がないかもしれない、もしくは効果を得るためにどうしたらよいのか分からなければ、動くソフトウェアで試してみることです。次にシステムを発注する側が失敗するリスクを抱えることになるアンチパターンを挙げます。

• 機能を最初に決めてはいけない
• 実現方法を最初に決めてはいけない
• 大量の要求を一斉に発注してはいけない
• 長期間にわたって机上での検討を続けてはいけない
• 開発に効果測定というフェーズがない

機能を最初に決めてはいけない

　機能を最初に確定することは、もしその機能が当初目的としていた効果が得られなかった場合変更が困難です。今回はこの方針で試しますが、効果が得られなかったら若干の変更をします。という姿勢を貫き通してください。最初に未来を予想してもバクチになり、リスクを背負うことになります。ですから、完全な完成形を定義してはいけません。

実現方法を最初に決めてはいけない

　目的やシステムに求める要求は定義しますが、その実現方法を机上で定義してはいけません。プログラムする作業担当者は最もシンプルな手段を選んで実装しますが、実現方法を最初に定義すると、それは技術的制約となってしまいます。それでも発注側が良い方法を思い付いているケースもあるでしょう。その場合は、発注後に開発者と一緒になって実現方法について検討することをお勧めします。実際に作りながら良い方法を思い付くケースも多くあります。最初に実現方法を確定してしまうと、その良いアイデアを捨ててしまうことになります。

大量の要求を一斉に発注してはいけない

　大量の要求を一斉に発注すると、本来価値のあるものと、ないものの判断がつかなくなります。また、すべての完成を待つと、最初に出来上がった価値の恩恵を得るのが、すべての要求が完成した後に合わされます。そして、大量の要求の見積もりは大きく外れるリスクがありますから、急いで作ろうとするためソフトウェアの品質を保つことが難しくなり、やはり機能を変更してほしいという状況に対処することへの妨げになります。検討が終わってIT化が必要と判断された要求から順序よくプログラム化の検討に入ることが望ましいので大量の要求をため込んで、一度に発注することは推奨されません。また、一度に多くの要求を作り込もうとすると、ソフトウェアが複雑になりがちになります。ソフトウェアの量は少ない方がメンテナンスしやすいため、これもアンチパターンである理由の1つです。

長期間にわたって机上での検討を続けてはいけない

　机上での検討だけに時間をかけると、不必要な要求がたくさん盛り込まれる傾向にあります。また、長期間にわたればわたるほどコストが掛かりますから、その機能が不要であるかもしれないという判断がしづらくなります。机上の検討を進めるのではなく、動く価値であるソフトウェアを作りながら検討していく方が手戻りのコストを最小化させることができます。

開発に効果測定というフェーズがない

　従来のソフトウェア開発においては、十分な検討を行って、注文どおりの仕様でソフトウェアが開発されれば、開発は終了したことになります。しかしこのアプローチでは、もしも要求が目的を果たせなかった場合にそのリスクを発注元が全面的にかぶることになってしまいます。従って、その要求が本当に目的を果たせたかどうか効果を正しく測定できなければなりません。十分な効果が出るまで、継続してその機能を進化させるか、投資に見合う効果が得られないので中止するかは経営判断となります。そして1回の開発が終了したらITベンダとの契約を切ることはお勧めできません。望む効果が出るまで契約を切らない方がいいと思われます。

計画策定の根拠が希薄

　システム開発は、いついつまでに何を作らなければならないという計画を軸に進められていますが、その計画の根拠があまりに乏しく、計画する時間自体が無駄になることが多いのです。かといって計画をまったくしなくてもいいといっているわけではありません。計画しようとするから見積もらなければならなくなります。しかしこの見積もりはほとんどの場合当てになりません。それは実装してみて初めて分かってくる次の項目がやってみるまで予想できないからです。

• 思っていたより要求がシステムに影響する範囲が広いこと
• APIやフレームワークが思っていたよりも機能を備えていないこと、もしくはバグがあること

　これらの不確実性を完全に見積もることはできません。2番目は特に難しく、テクノロジの進化が与えた便利な機能たちがもたらす副作用ともいえるかもしれません。もしかしたら要求を若干変更した方が早く価値を提供できるものができるかもしれないという状況はよくありますが、一度仕様として決定されれば、どんなバグがあろうが、時間をかけて対処しなければならなくなり、その工数が本当は無駄になっているのかもしれません。

　このように要求の矛盾点がすべて解決していくという作業と、要求がプログラムコード化される作業の繰り返しにおいて、計画軸という考え方はあまり重要ではありません。検討する速度を保つために目標やマイルストーンの設定はした方がよいと思いますが、最終的にすべての要求が指示どおりに実装される時期、計画というものが主軸であるという考え方は長期的に見て重要ではありません。もっと長い目で見たときに、システムが将来にわたって機能拡張し続けられるように設計を繰り返すべきです。

　当たるか分からないシステム開発において、双方がリスクを抱え込まないようにするために本当に効果的な個所にIT化投資を行い続ける開発計画を考えていかなければなりません。1つのシステムを長期間にわたって進化成長させていくためにはソフトウェア開発技術は必要不可欠です。以下にはこのような継続進化型開発アプローチを取るために必要な技術について述べていきます。

技術的な裏付け

　ソフトウェアを作るという行為を取り巻く技術は多くの進化を遂げてきました。そしてその進化はいまでも進化し続けています。10年前の技術のままであれば、このような進化型アプローチが採用されることはまずなかったと思います。それは以下の理由によります。

• ソフトウェアの構造を整理するオブジェクト指向などの考え方が浸透していなかった
• 単体テストフレームワークが浸透していなかった
• CPUやメモリが高価で、コンパイルや動作検証に時間がかかった
• リファクタリングやデザインパターンなどの考え方が浸透していなかった
• 優れた開発環境がなかった
• 優れた構成管理システムがあまり普及していなかった
• インターネットでさまざまな情報が簡単に手に入るようになった

　このように開発を取り巻く環境は10年前に比べ飛躍的に進化しました。それに合わせて開発のやり方も変わっていかなければなりません。データベースの内容をWebで表示するという画面を1つ作るのに、以前はそれでも時間がかかりました。しかしいまの時代、その程度ならば検討しながらリアルタイムで作ることも不可能ではありません。

　単体テストフレームワークを上手に活用することで、機能的なテストを手で毎回行う必要性はなくなりました。その結果、機能を追加、修正するときに懸念されていたデグレードや副作用は最小限に食い止められます。これはソフトウェアの構造をその状況に応じて最適化するというリファクタリングを可能にしました。

　このようにさまざまなテクノロジとエンジニアリングの進化によって、機能の修正、追加の速度を低下させることなく、システムの成長速度を落とさないように進化させることが可能になりつつあります。技術力の乏しい開発者であれば、仕様変更におけるソフトウェア修正コストが高くつきますし、それを嫌がる傾向にあります。ソフトウェアをきれいに作るという行為はシステム進化の速度に大きく影響しますから、これを怠ると機能の修正追加コストが爆発的に増加してしまいます。二度と追加修正のない使い捨てのプログラムコードを発注するとき以外において、きれいにプログラムコードを書けない技術者にコードを書かせることは、発注元にとって大きな見えないリスクを潜ませる行為です。

妥当な報酬の支払い方

　私はさまざまなシステム開発の現場を見てきましたが、すべて予定どおりに完成品が納められ、予定どおりの効果が得られたというケースはまれです。不確実性に対する予測に基づく計画と実施は、その外れた部分について、必ずどこかが犠牲になっています。そしてこのような犠牲が表面化することはあまりありません。要求を発生させてからシステム化され、価値を生み出すまでの速度をいかに短縮させ、その効果を測定してシステムをさらに進化させるためにどのような要求を追加変更するかというサイクルに価値を置かなければなりません。

　この流れを低下させないよう、ITベンダは技術を持たなければなりません。技術力が低いと、あっという間にシステムの進化速度が低下し、IT化投資の効果を得られなくなってしまうからです。発注側は、ITベンダに対して長期的なシステム化速度に価値をどの程度支払うかを定める必要があります。これは発注側、受注側ともにフェアな取引といえます。

　技術力と業務知識 この2点を兼ね備えた技術者は発注側のシステム化に対して高い利益に貢献できる可能性が高いです。おそらくもうかるであろう機能を短期間で作れるわけですから、その利益に見合った報酬を設定すればよいです。業務知識だけが豊富でも、実装能力が不足していれば、形にできませんから価値はありません。一方で技術力だけに特化していたとしても、業務知識を全く備えなければ、そのような人は組織に数人いればよいでしょう。両方ともできない技術者には基本的にコードを書かせてはいけません。進捗（しんちょく）が遅いと考えるのではなく、長い目で見たときに発注元のシステム進化の速度を止めてしまうことにつながるからです。

　この期間にどんな機能を入れ込むかを考えるのではなく、経営上必要な機能ごとにパラレルに価値という名前のソフトウェアを進化させ、リリース状態になればそのときにリリースするが、その後も効果測定をしながら進化の手を緩めないという考え方は、ITがボトルネックとなる企業であれば市場競争力を絶えず失わず強めるということにつながります。システム進化の速度に経営戦略を合わせることが大切なのです。この考え方をサービスウェア理論と呼びます。

　このようなサービスウェア理論に基づくシステム発注と開発を行なうことで、開発期間は従来の方法に比べ半分程度にまで短縮が可能ですし、投資による効果は4倍にまで向上すると考えられています。それには、技術力だけが高くても、要求だけがきれいにまとめられても、部分的な効果しか生み出せないため、最終的な利益をもたらすことはできません。開発者側も、契約やドキュメントで線を引くのではなく、協調関係を積極的にもとめる努力が必要ですし、発注側も開発のリスクをよく理解したうえで信頼による協調関係を作り上げていかなければ、今後のシステム投資を成功させ、永続的な市場競争力を維持し続けることは困難となるでしょう。

筆者プロフィール

相馬 純平（そうま じゅんぺい）

1997年、富士ゼロックス情報システム株式会社入社。アーキテクトとして多くのシステム開発を改善。2005年現ケペル株式会社　CTOに就任。サービスウェア理論に基づく、情報システム投資の改善コンサルを実施している。アジャイルプロセス協議会アジャイルTOC分科会リーダーJava関連の寄稿記事多数。国内では先駆けてTDDのライブコード公演を実施。アジャイル/XP サービスウェア理論に関する公演多数実施。