エンドユーザー企業が、システム開発を発注するとき、最も注意すべきトラブルは、意図したシステムができないことだと思います。
有効な回避策はたった１つだけです。
「発注前に仕様が明記された資料をベンダーとユーザーで共有すること」
これにつきます。
【どうして意図したシステムができないトラブルが発生するのか】
意図したシステムができないトラブルは、ユーザーの期待とベンダーの予定がかみ合わないときに発生します。この状況に陥ったプロジェクトのほとんどは、見積もりが大きく不足しています。
「見積もりが大きく不足したシステム開発」ほど最悪なプロジェクトはありません。予算も期間も不足するため、様々な問題が発生します。
ベンダーの企業体質やプロマネの資質が良好ではない場合、実際に予算と期間が不足すると、ベンダーはコストを下げるために躍起になります。開発途中で気が付いた課題があっても、わずかでもコスト増になりそうな提案は行われず、安価かつ安易な解決方法が選択され続ける場合すらあります。
プロジェクトの途中で抜本的な対策が行われれるか、小手先の手法でまっとうな品質のシステムが完成するなら、まだ運が良いほうです。ただただ無理を押し通して、品質の悪いシステムが完成するケースを実際に見かけます。
「ベンダーが悪い」といえばその通りです。しかし、システム開発は事業目標の達成手段であることが普通で、計画どおり進まないのは何としても避ける必要があります。
【要件定義と提案書】
まっとうなベンダーであれば、システム開発を受注する際、システム規模が大きければ「要件定義」と呼ばれるシステム要件を明確化する作業フェーズを提案してきますし、逆に規模が小さければ「提案書」と呼ばれる資料を作成します。一般に前者は有償で、後者は無償で提供されるサービスです。
この要件定義書、または提案書で、ある程度荒い「仕様」を整理することになります。要件定義も提案書も決まったフォーマットはなく、作成者が個別に形式を吟味して作成するものです。
要件定義書、提案書は、「(1)どのような仕様のシステムを作るのかを明らかにすること」と、「(2)システムの開発規模を固定すること」の2つの目的を達成するために作成します。これに価格や納期の情報などが加わることで、以降の開発契約が可能になるのです。
ユーザーは、要件定義あるいは提案書の仕様案を確認することで、安心して発注することができます。
仮に上記を端折った場合、発注側からみれば要望通りのシステムが完成するかが曖昧であり、受注側からみれば、開発規模が不明であることになります。
【仕様不明確のまま見積もりを入手した場合】
たとえベンダーが仕様未確定で見積書を出してきても鵜呑みにせず、仕様案を要求すべきかと思います。要求すべきは、見積もり根拠等ではなく仕様案です。もし、無償で提案書を作成するベンダーが見つからなければ、有償でも作成すべきです。
システム開発フェーズの上流工程である要件定義あるいは提案書作成は、単に構想をシステム化するための初期作業というだけではなく、契約のために必要不可欠なフェーズなのです。
【要件定義/提案書の内容】
ここで一つ絶対に避けるべきパターンがあります。要件定義書あるいは提案書に、要求事項が書かれていて、どう具体化するかが書かれていないケースです。
ベンダーに提案を依頼するときの文書（いわゆる提案依頼書）であればそれでいいのですが、要件定義や提案書に要求事項だけが書かれている場合、「どのような仕様のシステムが完成するのか」も「開発規模」も明らかではないことになります。
例えば「在庫を的確に把握できること」は単に要求事項であり仕様案ではありません。
- 単に在庫の一覧が表示できれば良いだけかもしれません。
- 適切な分類ごとに数量と、平均の滞留期間をグラフ化する必要があるかもしれません。
- そもそも在庫を正確に把握するために入出庫を把握する仕組みから見直す必要があるかもしれません。
適切な要件定義書や提案書では、「在庫を的確に把握するための具体的な方法」が明らかにされます。詳細な設計書である必要はありません。少々荒くても画面の簡易スケッチと機能の説明が書かれていれば、大トラブルは避けられます。
一般に提案書は要件定義書より精度が劣りますが、この点については、提案書を受け取ったときに、打ち合わせで提案書をめくりながら細かく質問して埋める方法が良いでしょう。質問の大部分は「後から決定しても大丈夫」等の答えが返ってくるはずです。もちろん、質問の内容次第では、要件定義書や提案書の手直しが必要になるケースもありますが、それは必要な作業です。焦らず資料の更新を待ってください。