１．自己紹介

新卒で4年間のSIer勤務を経て転職。
転職先で3人月の業務支援アプリ構築プロジェクトを1人で担当。

今回、確定させた仕様に対して追加要望やリリース後の質問が多かったので
今後そうならないための反省をメモします。

２．読んでほしい人

　- 新米Webディレクター、上流担当のSE
　- システム構築を初めて外部に委託する方
　- 要件定義ではOKだったのにリリース直前・リリース後の追加要望で困っている方

３．やるべき4つの事

　- 工程、スケジュール表を作成し、まずは顧客レビューで承認してもらう
　- 各工程の成果物を決める　例）要件定義ならばシステム要件、画面一覧
　- 必ず工程毎に成果物レビューを実施し、クライアント承認結果を残す
　- 期限超過後の依頼は変更管理（追加見積）とするルールをクライアントに示す
　例）仕様案に関する質問で返答期限を超過したものは仕様書に落とし込む。
　　　　仕様書のレビュー打診し、仕様確定のエビデンスとする

４．これだけは伝えたい

「やるべき4つの事」ではルールを盾にするような印象を与えたかと思います。
しかし要望通りのシステムが出来上がらないのに、クライアントに対して「ルールなので」と
一蹴するディレクションをすることは目的ではありません。（今後の仕事が無くなるので）

クライアントの要望とシステムにギャップが無いようにレビューを実施し、
クライアントが意欲的にプロジェクトへ協力できるような関係作りのために、
事前にルールを伝え、お互いに不幸にならないようにプロジェクトを進めましょう。
（ルールを盾にするのは最後の手段です）

NGシナリオ（序盤編）

①「あれもこれもやりたい」状態

　⇒ヒアリングに問題あり。要望を聞き出せていないか、こちらの認識が間違っている。
　　要件定義、設計の期限延長を考慮すべき

②何を説明しても「わかりました。」状態（目安は9割以上

　⇒そもそも理解していない。システムの仕様について確認テストをすべき。
　　クライアント承認を受けても後でもめる危険性大
　　（あと、仕様書の書き方見直そうね）

NGシナリオ（中盤）

③レビュー依頼出したが興味なし。「ま、いいんじゃない？」状態

　⇒当初のルールをもう一度説明しよう。+興味を持ってもらえるようにアプローチ
　　仕様が合っていなくても承認してしまうと以降の修正は変更管理扱いですよ？と

④レビュー依頼出してるのに無視

　⇒上に同じ。

NGシナリオ（終盤編）

⑤緊急、いいから早くやれ状態

　⇒リリース後に多い。炎上案件に認定。
　　ここまで来たら当初のルールやドキュメントを盾にするしかなくなる。
　　（今後の取引を考えて、顧客満足度を下げないために泣く泣く無償で対応する判断も。）