システムの“直感的なイメージ”ができたら、ベンダに見積もりを取る前に、スケジュールとコストの概算を求める。これは「システムを発注するスキル」を身に付けるために欠かせない作業だ。
構築しようとしているシステムの概要が決まったならば、スケジュールやコストのめどを立てます。
ベンダが開発に必要とする時間や本番環境での運用テストに必要な時間を予想し、ベンダをいつぐらいまでに決めなくてはいけないか、機能要求仕様をまとめるにはどれぐらいの時間が必要か、プロジェクトチームをいつごろまでに編成する必要があるかなどを検討します。たいていの場合、システムの稼働開始時期は決まっているので、各作業の時期は運用開始時期から逆算して求めることになります。また、サーバーやパソコンなどハードウェアの台数を見積もり、ソフトウェアとハードウェアを含めて、費用がどれぐらい掛かりそうなのかも概算してみます。
規模が同じ程度のシステムを開発した経験があれば、比較的精度の良い値を出せますが、そうでなければ、雑誌やWebでの情報を参考にしたり、知り合いのベンダや同じようなシステムを構築した他社・事業所などから意見を聞いたりして値を出すしかありません。この場合、予想の部分が多分にあるので精度は良くありません。
プロジェクト立ち上げ段階でのスケジュールやコストの見積もりは、ベンダに見積もりを要求するための仕様を作成する以前の段階であり、「これでいいのか」と不安になりますが仕方がありません。この段階はあくまで大まかな仮定で数値は直感的なものと割り切り、不必要に時間をかけることを避けて次の段階へ進みます。
実際のシステム開発はベンダに依頼します(本連載は社外発注するパターンを想定しています)。そのベンダを決定する際には、プロジェクトチームを組織し、より明確な機能要求仕様を記述した見積もり要求仕様書を作成します。出来上がった機能要求仕様を複数のベンダに配布し、各ベンダはその回答として見積もり回答仕様書を提出することになります。それらを比較する段階で、各ベンダの提案内容を吟味し、スケジュールやコストの交渉をすれば、適当と考えられるスケジュールやコストが分かります。ある程度精度の高いスケジュールやコストを見積もることは、この作業を経験するうちにできるようになります。
ベンダから見積もりを受け取ったらそこから受ける感覚と、先に自分たちがスケジュールやコストを見積もったときの考えを比較することを忘れないでください。比べてみると驚くような差、ギャップがあるかもしれません。感覚的に驚くとともに、ベンダの考える機能の種類やボリュームとスケジュールやコストの相関を意識してください。インパクトの強いことはしっかりと身に付きます。
この段階でスケジュールやコストを想定・比較するのは、ベンダの見積もりとのあまりの差異に驚くことによって、仕様変更が発生した際のスケジュールやコストへの影響を予測できるようにしておくことが狙いの1つです。なお、システム開発経験が蓄積されているユーザーであれば、ベンダの見積もりから、そのベンダの力量を測ることもできます。
スケジュールやコストを考える際にリスク分(不確実性)を確保しておくことは不可欠です。そのためにシステムの規模を小さく始めることは、プロジェクト成功の鉄則です。特に大規模システムの開発経験がない場合、段階的に規模を拡大するアプローチは必須だといえます。
プロジェクトの最中には何らかの不測事態が必ず発生します。どんな事態が発生するかを完全に想定することは不可能ですが、何かが起こるということは必ず想定しておかなければならないということです。
誤解のないように注意してほしいのですが、リスク分を確保するということは、各作業に余裕を持たせることではありません。むしろ逆に想定外の作業に対応するため、あらかじめ想定されている各作業のスケジュールやコストをより厳しく管理することになります。プロジェクトは期限が限られているので、個々の作業を効率よく実施するか、短期間に多くの作業を実施することになります。費用の面でも、ベンダに依頼する作業を削減し、その分をユーザー側で実施するなどの措置を検討・計画することになります。
なお、ベンダの見積もりにもリスク費は含まれています。その割合は、あるベンダによると1%のケースもあるとのことですが、多くのユーザーは20〜30%程度あると感じています。一般的に、原価:利益:リスク費の比率として「4:4:2の法則」がいわれているようです。ユーザーサイドでしっかりとプロジェクトの管理をすれば、ベンダのリスク費を下げることができます。
Copyright © ITmedia, Inc. All Rights Reserved.