営業の皆さん、本日も営業活動お疲れ様です！
最近とあるプロジェクトのユーザー受入テストでエラーが発生し、出戻りが起きました。
エラーの原因を確認すると要件定義におけるユーザー側の仕様漏れによるもの、、、
私自身も本題材である”仕様凍結“というプロセスは非常に重要なものであるとひしひしと感じている次第です。。。
本記事ではシステム営業・SI営業を行っている人にとっては非常に重要な”仕様凍結”について熱く語っていきます！
仕様凍結とは？
最初に仕様凍結の意味や役割を確認いきましょう。
仕様凍結は、システム開発プロジェクトの中で実施される1つのプロセスになります。
実際にどのようなことを行うのかというと、発注者とシステム開発者の両者の間で「要望が出尽くしてこれ以上仕様が追加・変更されることはない」と合意を取る・仕様を確定させることを言います。この仕様凍結後に設計や開発といった後続工程に入っていきます。※参考)EnterpriseZine「仕様凍結って意味あるの？」
仕様凍結をしないとどうなる？
仕様凍結をしていないと、利用ユーザーが関わってくる後続のテストフェーズにて綻びが生まれる可能性があります。
特にユーザー受入テスト(UAT)のようなプロジェクト終盤になって「仕様を変更してほしい」「このままでは使えない」といった話が出てくると、両者ともに満足度の低いままプロジェクトを進めることになってしまいます。
そのため、基本的なプロジェクトの中では仕様凍結というプロセスは必ず存在すると言っても過言ではないでしょう。
しかし、この仕様凍結を言葉だけ理解しても意味はありません！
その重要性やタイミング、仕様凍結に対する両者の意識合わせといった”仕様凍結の意義”を真に理解してほしいと筆者自身も思っています。
仕様凍結と過去の裁判
システム開発訴訟が世の中には存在しており、実際に過去に複数件の裁判がありました。
| 裁判例 | 内容 |
|---|---|
| スルガ銀行×日本IBM | 勘定系システムの大規模開発プロジェクトの失敗を受けた責任問題の裁判。最終的には議事録を証拠として日本IBMの敗訴。 |
| 旭川医大×ＮＴＴ東 | ベンダーのプロジェクトマネジメント義務とユーザーの協力義務を争点とした仕様凍結の問題であり、NTT東の勝訴 |
| 文化シヤッター×日本IBM | PaaSを用いた大型のシステム開発紛争において、ベンダの開発手法・方法論の選定や、プロジェクトマネジメント違反等による損害賠償責任が認められた。 |
それぞれの裁判の中では仕様凍結に対して論じられています。改めて仕様凍結1つで何十億円もの賠償金が変わると思うと非常に恐ろしいですよね。
そして、基本的には裁判所の判決では仕様凍結後にユーザーから仕様の追加要望が上がってくることは仕方がないといった判決例もあります。
しかし、仕様凍結後に追加要望が上がってくることは開発ベンダーとしても避けたいところであるため、仕様凍結時に念押ししたり何か変更があればスコアリングコミッティーを行ったりといった工夫が必要になります。
仕様凍結の重要性
仕様凍結は会社の利益を守るために非常に重要になります。この仕様凍結の重要性を確認していきましょう。
1．顧客の要望に対して断る名目ができる・・・仕様凍結後は基本的に追加での要望や仕様変更は行わないルールとなります。スケジュール上、対応が難しい場合やパーフォーマンスを考慮したときにカスタマイズをこれ以上しない方がいい場合などに説明できる1つの材料となります。
2．正当に報酬をもらうことができる・・・ビジネス上お金のやり取りは大切なものです。数十万〜数百万円の追加報酬をしっかり受け取れるだけでも赤字になるか黒字になるか変わってきます。仕様凍結を行ったことを理由に、対応する場合にはこれだけ費用が発生すると正しく説明することができます。
3．仕様凍結後の出戻りを減らすことができる・・・要件定義にて仕様が確定する、この後の仕様凍結後では追加要望を基本的には受け付けられないといったことをしっかりお伝えすることで、お客様側でも真剣に要件定義に臨んでくれます。それにより極力、要件が出尽くし追加要望が出にくくなります。
このように仕様凍結は売上・利益を確保するための非常に大切なプロセスだと理解できますよね！
仕様凍結時に気をつけるべきポイント
ここまでで仕様凍結の重要性をご理解いただけたと思います。
最後に仕様凍結にて気をつけるべきポイントや工夫をお伝えしていきたいと思いますので、日々の営業活動の参考にしてみてください。
ポイント1：仕様凍結は複数回行う
「仕様凍結と仕様変更のバランス」にも記載がありますが、仕様凍結を複数回設けるという工夫があります。タイミングとしては前工程である要件定義と基本設計時になります。
ユーザー側でも要件を網羅できていないことはどうしてもあります。そのため、業務フローを把握しやすい要件定義を行ったタイミングやデータ処理プロセスがわかる基本設計のタイミングで確実に情報を提示して仕様凍結を行います。
ユーザー側への配慮もあり、私自身も非常に参考にしたいと思いました。
ポイント2：議事録を作成して共有する
先述の裁判でも決定的な証拠として扱われた議事録は仕様凍結を正当づける非常に重要な証跡でした。
もちろん、営業マンが全ての打ち合わせに参加している訳ではないと思いますが、仕様凍結が行われる場では議事録を作成して、両者の合意が取れている痕跡を残しましょう。
後々のトラブルを避ける意味でも非常に重要です！
ポイント3：仕様追加・変更を見越したスケジュールを確保する
仕様凍結を行ったとしても抜けや漏れがありユーザー側から追加要望が上がってきます。
もちろんそれを全て跳ね除けるという方法もありますが、顧客満足度が下がってしまい、継続的なビジネスにはならないでしょう。
そこで重要なのが、仕様の追加・要望が上がってくることを見越したスケジュールの策定です。お客様自身も自分が網羅できていると思いがちで、ふとしたイレギュラー対応が抜けていることもあります。お客様にもスケジュールに対して理解してもらいながらこの予備日を設けることをおすすめします。
まとめ
いかがでしたでしょうか。
筆者自身もまさにこの仕様凍結の重要性を近々で感じていた次第です。
単純なソリューション営業では経ることのないプロセスのため、SI営業・システム営業を行う方はこの仕様凍結の真の意義を理解して、会社を・あなた自身を守るものとして実践していきましょう。
