今回は、システム受注後の要求仕様の確定にからむ話である。いかに見積もり条件（金額、納期）に合う仕様に確定するか、いかに仕様の膨張を抑えるか、そして確定をいかに早く実現するか。これらの課題の解決方法を考えてみる。
 |
プロジェクト成功の鍵は、あいまいなスコープ（要件）の早期明確化である。本来なら派遣契約でスコープを明確にすべきであるが、すべてをまとめた一括契約が結ばれる場合が依然多い。いかに早くスコープの霧を晴らし、要件のあいまい性をなくすかが、プロジェクト運営最大の課題である。
納期を守るために、仕様が決まったところから手を付けることがよく見られるが、これは失敗の大きな原因になる。少なくともシステム稼働に絶対不可欠な骨格機能については、その全体の仕様を確定してから開発に入ることが大事である。
特に規模も大きく、高い信頼性が求められるシステムでは、きちんと仕様を固めてからでないと、途中からの仕様変更や仕様追加がなかなか収まらない。当然、品質にも影響し、最悪は途中で挫折してしまうことにもなる。
 |
システム仕様は本来、契約時に固まっているべきものである。だが、現実には仕様の明確化に必要な時間が契約前に充分取れず、詳細は契約後に決めざるを得ないことが多い。
とはいえ、契約後の打ち合わせで、「仕様をゼロから決めるのが当然」と錯覚するのは問題である。「システム仕様の打ち合わせ」という言葉を使うこと自体が「システムの仕様はどう決まっても仕方がない」というようなあきらめや、甘さを生んでいると思われる。
受注者側の、「システム仕様は契約時に確定済みで、念のために仕様の再確認や確定をやっているのだ」という基本姿勢の堅持が重要である。しばしば起こる問題は、受注者が仕様の確定を「発注者から仕様を詳細に聞くこと」と誤解し、発注者は「仕様は契約後に決めればよい」と誤解することである。
 |
システム仕様を早期に確定するためには、見積もり時にベンダーが想定した仕様をまず提出し、これを説明しながら顧客の意図との差を明確化してゆく努力が必要である。どうせ詳細は顧客に聞かない限り分らないのだからとあきらめ、受注後に「早く仕様を決めてください」と顧客に迫り、自らは待ちの姿勢に入るのは間違っている。
何らかの見積もりをした以上、想定したシステム・イメージはあるはずだから、「我々が見積もったシステムは、このようなものです」と極力詳細な仕様を提示する義務がある。顧客の考えとズレる個所があっても、比較材料を用意することで、どこにどれだけのズレがあるかが明確になる。ベンダーと顧客の間の認識のズレ、つまり「馬鹿の壁」は受注後極力早く除去すべきだ。
 |
顧客との仕様確認のためには、ベンダーが想定した仕様をまず提示しなければならい。ところが契約時の時間不足で確認すべき仕様が手元になければ、顧客に仕様打ち合わせを少し待ってもらってでも、想定仕様を急いで用意したほうがいい。受注した業種・業務に詳しい人材を急いで集め、組織を挙げて仕様の準備をすべきである。
また、自分たちが提案したつもりの仕様書をできるだけ短時間に用意できるように、業種・業務別に経験済みシステムの仕様を日頃からそろえておくことも大事だ。確認すべき仕様書が手元にないからといって、契約後すぐに顧客との打ち合わせに走り、「早く仕様を決めてください」と請願するだけでは、とかく仕様は膨れ上がってしまう。
