要件定義後の見積作業の進め方について整理したい。
見積もり用語3点セット(RFI、RFP、RFQ)
見積もりで出てくる用語は、下記の三点だ。順番に説明する。
RFI(Request For Information)：情報提供依頼
RFP(Request For Proposal)：提案依頼
RFQ(Request For Quotation)：見積依頼
RFI
RFIは、ベンダが、プロジェクトの遂行能力についての情報を収集するための文書のことだ。ベンダ各社にプロジェクトの目的や概要を伝え、課題解決のためのソリューションを提示してもらう。過去実績や自社技術について紹介してもらい、このベンダは何ができるのか？を確認する。家を建てるときの時のカタログ資料請求みたいなものだ。 ベンダをリストアップし、さすがにこのベンダは無理だなというのを層別するために使う。
RFP
RFPは、システムの実現手段の提案依頼書のことだ。発注側が要件定義書を出してベンダがそれをどのように実現するのかを提案してもらう。この提案内容を見て、実現手段を確認する。
RFQ
RFQは、システムの実現にかかる費用見積依頼書のことだ。発注側の要件に対して、それをいくらでやるのかを見積もってもらってもらう。
見積もりの流れ
見積もりプロセス概要
上記用語を踏まえて、見積もりのプロセス下記図に示す。
発注側は、要件定義書の作成を進めるとともに、RFIも作成し、ベンダ側に情報提供依頼を行う。ベンダ側がそれらへの回答を作成し、発注側が受領する。それらの情報も踏まえ、発注側は要件を検討し、内容を詰めていく。この段階で、発注側は、システムが実現できそうなベンダを絞り込む。その後に、RFQとRFPを作成し、各ベンダに対して、システムをどのように実現するのか？実現しようとするといくらかかるのか？を問いかける。ベンダ側は、要件を実現するための手段と金額を検討し、発注側へ回答する。それらの情報を踏まえ、発注側は、最終的にどのベンダに開発を依頼するのかを決める。その後は、契約の内容を詰めていき、発注をする。RFQとRFPを同じタイミングで出している点については、違和感があるかもしれない。筆者の個人的な考えとしては、実現手段を検討する際に、かかる工数(金額)も見積もれているはずなので、RFQとRFPは同じタイミングで実施してもよいと考える。システムというのは、QCD、即ち、品質、価格、納期をワンセットで考えなければならないので、どう実現するのか、いくらで実現するのかは、まとめて比較検討されるべきである。長々と説明したが、やることはシンプルである。発注側が要件を決め、その要件を、いくらで、どのように実現するのかを受注側が見積もるだけだ。
見積もりにおけるポイント
見積もりにおけるポイントは、２つある。要件を明確化することと、複数の業者に見積もりを依頼することだ。
1点目：要件を明確化する
見積もりにおいて重要なことの一つは、要件を明確化することだ。システム開発が難しいのは、これから作り上げるシステムが、世の中に一つしかない点だ。大量生産されているモノを購入する場合は、要件を明確化してベンダに提示する必要はない。モノはすでにできあがっているので、自分たちの要件にマッチするかどうかを吟味するだけだからだ。要件を明確化できないまま見積もりをすると、見積もりのブレは大きくなるし、すでに出来上がったシステムを改修するときに、元の要件が不明確だと、設計当事者しかわからないので、ベンダーロックインが発生する。そうならないように、要件を明確化しよう。
2点目：複数の業者に見積もりを依頼する
複数の業者に見積もりを依頼することも大事なことだ。見積もりをする側は可能な限り高値で見積もりを出してくる。競合他社がいなさそうであれば、価格はさらに高額なものになる。別記事でも紹介したが、ベンダーロックインという状態になると、相見積もりはできなくなる。価格を抑えるために、相見積もりをしよう。引っ越し業者を選ぶ際に、相見積もりをとるようなものだ。その時その時で、提示価格は変わりうるものなので、相見積もりを行い、高い値段で発注してしまわないようにしよう。
見積もりにおいて注意すべきこと
システム開発プロジェクト進行において考えておかねばならないのは、要件は変更される可能性があるということだ。要件が変わると、やることは変わるし、金額も変わる。再見積もりとなるのだ。あらかじめ変更を意識して要件を管理できていなければならない。そのような変更の可能性というのを考慮すると、必然的に、要件ごとの金額を管理する必要があるということに気づくはずだ。システム開発というのは、どんぶり勘定で見積もりがなされるイメージがあるが、実際は、要件変更に備えて、要件ごとの見積もり金額を細かく管理しておかねばならない。
要件の変更に備える
要件を変更する方法は3つ存在する。要件を追加する方法、要件を削除する方法、および、要件を変更する方法だ。新しい機能が必要になった場合は、要件追加となる。逆に、機能が不要になったときは、要件削除となる。機能を少し変更したいというようなときは、要件変更となる。
要件の追加は、比較的対応が容易だ。一方で、要件の変更や削除は、その変更や削除により影響を受ける要件要件を調査せねばならない。もし仮に影響があるのであればそれらの要件を変更したり削除したりしなければならない。なるべくなら要件を変更せずに、プロジェクト開発を進めたいところである。仮に要件を変更するとしても、小さな要件変更で済ませたい。そのためには要件定義書をしっかり書く必要がある。
ベンダの見積もり不足に備える
また業者側の見積もりが甘いということもありえるので、要件をどのように実現するのかを見積もり根拠としてしっかりと提示してもらう必要がある。いざ作ろうとなったときに、見積もりが甘かったというのはよくある話だ。見積もりが甘く、作業が追加となり、追加費用として請求された場合は協議をしなければならない。費用の話だけで済むのなら良いのだが、実際に作業追加は発生するので、スケジュールにも影響が出てくる。プロジェクトというのは人を投入して加速するようなものでもない。作業追加になったら、その分スケジュールの遅延は発生する。遅れ分を損害賠償請求するという方法もあるが、そもそもこんなことにならないよう、要件をしっかり定義し、その要件の実現手段をベンダがしっかり検討しているかどうかを、しっかり確認するようにしよう。
