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

いまの技術は20年前の技術と比べると面影も残さないくらい進化したにもかかわらず、受発注の契約システムはそのままという点についてとても疑問に思います

　ITによる業務の効率化は大企業だけのものではなく、中小企業経営の基盤をも支えるようになった昨今、市場競争はますます激化しています。少ない投資で大きな利益を上げるためにはIT投資の仕組みを正しく理解し、そのリスクの少ないIT化戦略を取らなければなりません。テクノロジの進歩はインターネットへ接続可能なPCと携帯端末の普及をもたらしました。いままでITと無関係だった人たちにも（ITは）身近な存在となったことにより、ITをベースとしたサービスの市場は拡大傾向にあります。

　その一方で、いくら良いアイデアやサービスを思い付いても市場への投入が遅れればすぐに競争力を失うことになります。そのため迅速に価値のあるシステムを構築することが望まれています。IT投資において重要な点は高い確率で市場から望まれる仕様を確定し、迅速にサービスの提供を開始することです。

企業のIT投資において、最初から市場に望まれる仕様を検討することはとても難しいというのが現状です。そして、検討し過ぎや検討内容が本来の目的から外れることによる無駄が生じ続けています。このような無駄な投資を極限に抑えるには、システム開発には検討しながら完成品を作り上げていくという考え方で挑む必要があります。そのためには、システムは奇麗に作られていなければそれを実践することはできません。本稿では、現代におけるIT投資のリスクを軽減するための考え方について述べます。

IT投資におけるリスク

　IT投資は何かの目的を果たすために行うわけですが、最終的に投資する側が望むような効果を手に入れるまでにはさまざまなリスクに立ち向かっていかなければなりません。IT投資においてシステム開発という行為のリスクは大きく次の2つに分類できます。

• 納期内にプログラムが完成せず、資金が尽きる（開発におけるリスク）
• 納期内に動くソフトウェアができても、目的が果たせない（要求におけるリスク）

　1つ目のリスクは開発におけるリスクです。仕様の取り違いなどによって、仕様どおりに出来上がってこないことや、さまざまな技術的な問題やリソース確保の問題などにより、開発が予定どおりに進まず、結果として資金がショートするリスクです。使用する技術や環境においてオープンソースや安価に入手可能な開発環境が出そろい、多種多様な実現方法がインターネットを通じて簡単に手に入るようになりました。これらの技術や情報を正しく用いると、飛躍的に生産性は向上しますが、一方で、正解にたどり着くための手段の組み合わせは膨大で、その中から最善と思われる方法を初期の検討だけで見極めることは困難です。

　2つ目のリスクは、仕様どおりにシステムが完成し、開発が終わったとしてもシステムに望む結果が得られない場合です。仕様自体が複雑過ぎてユーザーから受け入れられないとか、完成したときには他社が先に同じようなサービスを開始していたとか、想定していたよりも多くのユーザーからのアクセスによってシステムが機能しないなどが挙げられます。

　これまで存在しなかったアイデア、インターネットや携帯電話などの新たなインフラを使ったシステム化による業務改善や、サービスの提供は、どのような仕様であれば効果的に目的が果たせるのかを何もない状況で検討することは難しいものです。単純で分かりやすい仕様のシステムはすでにIT化されているか、パッケージ商品やASPとして市場に存在するため、わざわざ投資をして新規に開発する必要性はなくなってきています。企業のシステム開発では、世の中にすでに存在するものは開発する必要がないわけですから、その仕様や効果を最初に正確に把握することはできません。その要求が確実に予定していた目的を果たすかは分かりません。

ウォーターフォール型開発モデルとアジャイル型開発モデル

　上記で述べたようなリスクがなぜ軽減できないのかという問題は、ソフトウェア開発エンジニアリングの時代の流れが解決の鍵を握っていると考えています。

　従来のウォーターフォール型開発（図1）では、どのようなシステムにするのかを最初に検討し、完成形を定義するところから始まります。すでに存在する業務をITに置き換えるような業務では最初に完成形を描くことが容易です。その大きな理由はすでに運用されているシステムの中で人が手作業などでやっていた業務をIT化するわけですから、何をどのように作ったらよいかが明確だからです。そして、人手での作業がどのくらい短縮されるのかが計算で求められるので投資による効果も明確です。従って、最初に完成形を仕様として定義し、仕様に沿ってプログラマがシステムを作れば望むシステムが作られました。15年前は実現する手段（技術）の選択肢も多くなく、決められた範囲の技術を使って作るので、見積もりもしやすく、ウォーターフォール型で工程表管理のシステム開発が主流でした。

図1 ウォーターフォール型開発モデル

　その後に、開発におけるリスクを抑えることを目的として反復型開発という流れが登場します。検討された設計に基づいて実際にプログラムしてみると、計画したとおりの処理性能が出なかったり、技術的に困難な問題にぶつかったりすることがあります。また、半年〜数年のプロジェクトでは計画どおりに進ちょく管理することは困難です。そのため、反復開発は技術検証のための開発をしたり、要求を分割して小さなプロジェクト（イテレーション）として開発を管理したりすることによって、技術的なリスク、見積もりのズレを修正するなどの対策を講じてリスクをカバーするというモデルです。

図2 反復型開発モデル

　反復型開発はウォーターフォール型に比べれば見積もりの誤差は少ないですが、それでもイテレーションのサイズによっては見積もりより大きく外れるリスクは高まります。また、イテレーションごとに見積もりの見直しが可能なケースもまれなのが実情です。反復型開発モデルはウォーターフォール型開発同様に要求の大半を確定してから、開発工程について反復します。結局のところウォーターフォール型の繰り返しですので、筆者は反復型もウォーターフォール型の仲間（トップダウン型開発）として考えています。

　それに対して、システムとして作る機能の全貌を最初に決定せず、そのときに必要な最低限の価値を機能に分割して、技術的リスクを考慮しながら動作するシステムを構築していく方式をアジャイル型開発としています。アジャイル型開発では、どのように作るのかといったソフトウェアの設計を最初に決定しません。開発を進めるに当たって必要であれば、そのような実現方法が妥当かを検討します。見積もった期間に合わせるのではなく、価値のある順に実装していくという考え方ですから、最終的に何もできていないという状況は基本的にあってはいけません。一方で開発者には高い技術力が求められますので、大量の優秀な技術者を確保することが難しいという問題もあります。

図3 アジャイル型開発モデル