ソフト開発における受発注契約慣習の弊害と対策：市場競争力を持つためのIT投資の考え方（2/2 ページ）

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

リスクへの対処

　アジャイル型開発は開発におけるリスクを最大限にカバーしてくれます。しかし要求が外れるというリスクを回避するためには、すべての検討を先立って行うのではなく、作りながら効果を見極めつつ必要に応じて投資を行うという考え方が効果的です。システム開発は1つのモノを作るという考え方から流れを作るという考え方にシフトしなければなりません。一度に多額の投資を行うことは大変なリスクですから、流れを作り上げ、価値がないと判断したならば、流れの中で都度修正を行うか、中断するという判断をしなければなりません。

図4 サービスウェア的アジャイル型開発モデル

　一度に大量の要求を作るのではなく、効果測定の結果を経て、必要に応じて要求をIT化していくことで、開発におけるリスクと要求におけるリスクを解消します。

　1つのモノを作るという考え方ではなく、お金、技術力という有限リソースを時間という「流れ」で管理し、要求される品質を作り込むという考え方にシフトすることが望まれています。本稿では詳細は述べませんが、このような流れという発想でIT化投資効率を最大化するための考え方がサービスウェア理論です。

プロジェクトは終わらない

　完成形が最初に決定できないシステム開発において、プロジェクトが終わるということはありません。要求は、運用して得られる効果測定に基づいて再度検討され、修正を繰り返していくのです。インターネットを通じてサービスを提供するような企業では、他社の動向を見て、より優れた機能に変更を繰り返さなければ競争に勝ち残れません。それはパッケージ商品を開発販売している企業でも同じです。プロジェクトを終了するという判断をするならば、市場競争力を失うリスクを背負わなければなりません。数年後に状況が悪化してから、膨大な費用を払って最初からシステムを再構築すればよいと考える経営者が多いのですが、そのような時間とコストをかける企業は、アジャイル型を採用した企業に効率性で勝つことはできません。

　IT投資はそのときの競合企業の動向や世の中の状況、その企業のキャッシュフローの状態、技術力や業務のノウハウの蓄積度に応じてトレードオフを考えながら継続していくことが求められます。システムは建築物などと違い、完成して終わるということはまれです。実際は新たな要求が次々とわき上がり、機能追加や拡張が発生します。それは企業が常に進化している証しであり、改善や成長によってシステムが姿を変えることはごく当たり前なのです。

システムをきれいに作ることの重要さ

　システム開発を流れとしてとらえ、投資対収益率を向上させるためには、システム開発の技術力は必要不可欠です。汚く作られたシステムは、それを解析修正することが困難です。なぜなら価値を増加させるためのシステム追加修正作業の効率を著しく低下させてしまうからです。ソースコードは誰が読んでも分かりやすくなければなりませんし、設計は常に最適でなければなりません。構成管理や不具合管理システムが導入され、自動化テストが常に動作する状態でなければ、開発速度は低下し、同じ要求を実現するための投資額は増加してしまいます。最終的にはシステムの拡張が困難になり投資収益率は低下し始めるでしょう。このような事態を招かないためにも技術者への教育を徹底し、きれいにプログラミングすることが必要です。

　トップダウン型開発のような、設計してから実装し、レビューするような流れで作業する場合は、後でコードが汚いと感じても動いているからよいと片付けられることは当然だと思います。すべての要求は最初に検討されているはずですし、設計を行うことでコードの作りの確実性も保証しているはずです。ですからコードが汚かろうが、動いていれば良いという考え方になることは理解できます。従ってトップダウン型開発でリファクタリングを行うというのは無駄だと思います。

　一方、アジャイル型開発は常に機能追加修正という考え方です。一度書いたコードをクローズせずに拡張を繰り返すためにはテストが自動化されている必要があります。テストを自動化できない個所も多々ありますが、その辺も最先端なアジャイルの現場では克服するための努力が繰り返されています。コードはチームの共有物にしなければなりませんし、コードはきれいに書かれなければなりません。もちろんテスト駆動開発は無駄のない設計技法として有効ですし、リファクタリングによってソフトウェアの構造は常に見直されていなければなりません。

---

　最初に大量の要求を発注するという考え方は、不確実な見積もりをしなければならない受注側にとっても大変なリスクですが、実は発注側にとっても大変なリスクとなります。一度決めたら仕様変更が受け入れられないという制約は発注側にとっては酷です。しかし現状の受発注システムにおいては契約上、作るシステムの内容を決定してから見積もりを行い、発注するという流れになってしまっています。

　発注側も受注側もまともな技術や知識があるならトラブルになるのは不幸です。しかし実際は実力うんぬんではなく、契約の仕方や運によってプロジェクトの成否が左右されるのが実情です。いまの技術は20年前の技術と比べると面影も残さないくらい進化したにもかかわらず、受発注の契約システムはそのままという点についてとても疑問に思いますし、このままでは誰一人として幸せになれないと感じるのです。

筆者プロフィール

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

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