システム開発において、そろそろ見直すべきと筆者が思っていることの一つに、「RFPによるコンペ」がある。これまで、ユーザー企業がシステム開発を行う際、提案依頼書（RFP）を提示し、複数のシステム会社から提案を受けて発注先を選定することが推奨されてきた。これはシステムのオープン化の初期、技術基盤や言語が多様化する中、妥当な費用を探りつつ、提案力のある発注先を選定するのに有効な手段だった。公共機関では公平性という観点から今後も主要な手段であり続けるだろうが、民間企業ではもうその歴史的役割は終わったのではないだろうか。
RFPによるコンペの最大の功績は、ユーザー企業から見ると競争原理によって開発費用の相場を大幅に引き下げたことだ。しかしその代償として、発注者と受注者の信頼関係をズタズタにし、責任を回避し合う構図を作ってしまった。受注者は、コンペで勝つために低価格を約束し、不十分な体制で無理な納期での仕事を強いられる。一方で発注者は、追加要望を一切受け入れない受注者の態度に不満を募らせる。そしてプロジェクトが破綻し、相互不信を招いてしまう。
提案書の出来が素晴らしいことと、プロジェクトが納期通りに終わってシステムが無事完成することとは関係がない。提案書から分かるのは、技術営業力だけだ。プロジェクトの成否は技術営業力では決まらない。むしろプロジェクトマネジャーをはじめとする個々の要員の力量こそが成否に直結する。しかし、要員の力量が分かるのは、プロジェクトが開始して後戻りできなくなってからだ。
後戻りができないウォーターフォール型開発を続けていることもプロジェクト破綻のリスクを高めている。ウォーターフォール型は要件定義、設計、実装という開発工程を1回づつ行ってシステムを完成させるので、初期工程に誤りがあっても気づくのが難しく、気づいたときには手遅れとなる。
こうした問題を解決するために考案されたのが、アジャイル開発をはじめとする繰り返し型開発である。繰り返し型では一連の開発工程をイテレーションと呼んで繰り返す。初期のイテレーションで見つかった問題点を次回以降で修正できるので、本当に必要なシステムを納期内に確実に作ることが可能になる。
これほどのメリットがありながら、繰り返し型開発は一向に普及しない。なぜか。技術的な難易度が高いからという説明を聞くことがあるが、筆者はいくつもの繰り返し型開発の提案と実施を通じ、真の原因は他にあると思うようになった。
繰り返し型では丸投げができない。イテレーションを繰り返す中で発注者と受注者の合意の下で要件を見直していく。新要件を追加すれば、代わりに他の要件を削る。それがルールだ。柔軟に開発できる半面、うっかり必須要件まで削る可能性もある。そうなったとき、責任は受注者だけでなく発注者にもある。これが、多くのユーザー企業にとって繰り返し型開発の採用に立ちはだかる壁になっている。
この壁を乗り越えるのに必要なのは信頼関係である。受注側メンバーには十分な技術力があり、手を抜くことなく全力を尽くしてくれる。抜け漏れが無いかどうかを、発注者の立場でチェックしてくれる。発注者は受注側メンバーの力量と努力を正当に評価し、無理な要件を押し込んでこない。当事者として開発が円滑に進むように尽力してくれている。こうした信頼が醸成できれば、繰り返し型開発でプロジェクトを成功に導く好循環が生まれる。コンペで決まった1回限りの相手にそこまで求めるのは難しい。
今後、発注先の選定方法や開発手法をどうするかは、ユーザー企業側にボールがある。受注側となる技術者は、信頼関係を築くために何ができるかを考えておきたい。
