ソフトウェア開発の革命：ソフトウェア開発の匠（最終回）（1/3 ページ）

匠Lab 代表取締役の萩本順三氏が、既存のソフトウェア開発プロセスにメスを入れる！

[萩本順三，匠Lab]

　前回（第4回 アジャイル開発と反復開発の落とし穴）は、ウォーターフォール開発に代わるべく登場した、反復開発（*1）やアジャイル開発の問題点、課題、そして落とし穴についてお話しした。最終回は、ここまで説明してきた問題について、IT企業やITエンジニアたちがどう立ち向かうべきなのか、自分なりの考えを述べることとする。

（*1）反復開発とは例えばRUP（Rational Unified Process）やUP（Unified Process）のこと。

ユーザー企業とIT企業の不幸な関係

　ユーザー企業の求める真の要求は、業務要求がその根拠となる。業務をどのようにデザインするかでシステム要求が決まり、また、システムをどのように活用するかによって、業務に新しいイノベーションを起こせる。業務とシステムの有機的な結びつきが企業の業績に大きな影響を及ぼすのである。しかし、現状は、業務とシステムが分断されたままである。

　ユーザー企業とIT企業の契約の仕方を観察すれば、業務とシステムの不幸な分断状況を俯瞰できる。

　通常、ユーザー企業はIT企業にシステムに関する（開発）提案を求める。IT企業は提案を行い、その提案がユーザー企業に採用されれば、短い期間でユーザー企業からヒアリングを行い、システム要件を固め、ユーザー企業の合意を得て、開発作業に着手する。実は、このステップに多くの問題がある。

　まず、要件定義段階で獲得できる要求は、要求を点でとらえることが多い（*2）。この場合、要求の根拠が業務にあるはずなのに、業務が見えないままシステム化してしまう。

（*2）点としてとらえた要求とは、ユースケースが発端となるような要求のこと。一方、面としてとらえた要求とは、業務フローなどを「見える化」し、その中でITとして必要とされるユースケースが紐付いているもののことである。連載第1回で説明している。

　仮に、要求を面で捉えていたとしても、その業務はAsIs（現状）であることが多く、改善すべき点が数多く残ったままシステム化されてしまうことになる。

　改善しようにもIT企業はユーザー企業の業務に口出しをすることができず、また、改善提案をする能力もない。なぜなら、いままで“システム開発の牢屋の中から要求を待ちわびる日々を送っていた”からだ。さらに根深い事情として、そもそもユーザー企業の業務に口出しをして、業務改善・効率化を図り、IT化につなげること自体にIT企業がメリットを感じていないことが多い。業務改善を加えない方が、システム規模の増大につながる可能性が高く、結果的にシステム開発費を多く獲得できるからである。

　しかし、いまこそこの問題をIT企業自身が改善していくべきなのだ。

　業務改善提案が盛り込まれていないシステム開発案件は、余分な要求の山のために肥大化し、その結果、IT企業にとっては、手に負えないシステム開発プロジェクトが増大することになる。このような状況では、多くのプロジェクトは失敗に終わる。仮に“成功”したとしても、開発期間が予想以上に長期化していることが多く、開発が終わった段階で当該システムの存在価値がほとんどなくなっている、ということも少なくない。

　これらのことが、IT企業の「企業力」や「技術力」をどれだけ低下させているか。このようなビジネスの仕方は、市場のIT企業への信頼感を失墜させる。IT投資に疑いの目が向けられ、ビジネスチャンスも減少するだろう。

図1　ユーザー企業とIT企業の関係を改善する