仕様検討会議と仕様凍結
システム開発プロジェクトでは、ITベンダーやソフトウェア開発会社と大小様々な打合せを行います。
特に、仕様検討のための会議に多くの時間を割きます。仕様検討会議では、システムの機能仕様を検討と確定を繰り返していきます。全ての仕様について確定できたら仕様を凍結（仕様凍結）します。
仕様凍結とは、これ以降の仕様変更は（基本的には）受け付けませんよ、という状態とすることです。
つくる方からすれば、二階建ての和風の家を建てている途中で、「やっぱり洋風がいい」だの「実は平屋が良かった」と言われても困りますからね。どこかで（一時的に）仕様を固めてしまうわけです。
ここのところは、ウォーターフォールだろうがアジャイルだろうが同じだと思います。その凍結期間や凍結対象の規模が違うだけで。
ITベンダーが主導する仕様確認の落とし穴
ITベンダーは仕様凍結に向けてどんどん仕様を固めていきます。
例えば、機能仕様について説明する場合、よほどアレなITベンダーでない限りは、「その仕様ではできないこと」「その仕様では完結しないこと」についても説明してくれます。
更には「その仕様ではできないこと」を理解した上で、「業務的にはどのようなやり方をするのがよいか」「他社はどうしているのか」などについても説明してくれます。
その上で発注側の企業に問うのです。「…というわけで、このような仕様としたいと思います。よろしいですか？」と。
仕様検討会議が、ITベンダーと発注側企業との間の、建設的かつ知的な格闘の場となっていればよいのですが、残念ながらそうではないケースも多々あります。
そうではないケースとは、例えば、ITベンダー側の丁寧でわかりやすい自信に満ち溢れた説明を聞いているうちに、思考停止してしまうケースです。
「ふむふむ。なるほど確かにそうだ。それに他社の事例もよく知っているようだし、この仕様で問題ないだろう。」
と安易に考えてしまうのです。
実際、それで問題ないこともあるのですが（ここはITベンダー担当者の実力に大きく左右されます）、どんなにITベンダーが注意深く丁寧に検討しても、ITベンダーは利用者ではないのですから限界があります。
ですので、「本当に問題ないのか」「問題があるとしたらどのようなことが考えられるか」「その場合どのような対処方法が考えられるか」「そもそもITベンダーが言っていることは本当なのか」「ITベンダーの言っていることをこちら側は本当に理解できているのか」「こちら側が言っていることをITベンダーは本当に理解できているのか」などの問いをもっておくべきなのです。
その上で仕様を確定していくべきです。
主導権をITベンダーに渡してはいけない
最終的な意志決定は発注側企業にあります。こればかりはITベンダーだけが孤軍奮闘してもどうにもなりません。
ITベンダーが、要件定義や基本設計などの上流工程を「請負契約」ではなく「準委任契約」として行おうとする理由はこういうところにあるのです。意志決定の主体は発注側企業にあるのですから「請負」うことができないのです。まさに安請け合いできない。
ところがいまだに、「請負契約とか準委任契約とか言われてもよくわからない」「とにかくITのプロに任せたんだからちゃんとやってくれないと困る」「常識的な範囲で、うまいこと、失敗しないように」と考えてしまう企業が多い。
気持ちはわからないではないですが、それじゃダメなんです。うまくいかなった場合、最後に痛い目に会うのは発注側企業なんです。
本当にITをうまいこと使って経営をよくしたいと思っているのなら、主導権をIT企業に渡してしまってはダメです。
プロスポーツ選手が、自信の業績不振をトレーナーやコーチのせいにはしないでしょう。それと同じです。トレーナーやコーチの知見には耳を傾けるべきですし大いに活用すべきです。しかし、それをどう判断するかは自信の責任です。