変更要求を抑止する仕様変更管理 – 大量の変更要求が発生する理由と対策７選

はじめに

ウォーターフォール型では、プロジェクトの初期に行った要件定義をもとにシステム開発が進みます。
どれだけ慎重に検討しても仕様変更は発生するのですが、大量発生するとプロジェクト失敗のリスクが非常に高くなります。
プロジェクト失敗にはつながらなくても、要求事項に対する調査対応や、突発的な要求機能の取り込み対応、戻り作業などにより品質、コスト、進捗に悪影響を与えることになります。

ここでは、仕様変更を抑止するためのポイントについて解説します。

仕様変更が発生した場合の管理については、別記事「仕様変更でプロジェクト失敗しないための変更管理手順」で解説しているので参考にしてください。

変更要求発生の対策

変更要求の発生を抑止するためのポイントを７つあげます。
変更要求をゼロにすることは難しいですが、正しく対策をすることで大量の変更要求が発生する事態は回避できます。

要件定義を中途半端に終わらせない

要件定義の検討が不十分だと、当然ながら変更要求の発生につながります。
どのプロジェクトも要件定義を完成させるために努力しているのですが、次のようなケースの場合に検討不足が発生することがあります。

設計工程の中で要件検討する

全ての要件検討がスケジュール通りに完了するとは限りません。
要件定義工程の完了時点で一部の検討が完了していない場合、未検討の要件を残課題として設計工程に着手することもあります。

このとき要件定義を完了させず、要件検討は要件定義として進めることが大切です。
設計工程と並行になってしまうのですが、それでも要件検討を設計工程で行うことは避けるべきです。

設計工程の中で要件検討すると、どうしてもシステム都合を意識することになり、業務観点が手薄になるケースが多いためです。

「クライアントの合意を得られれば良い」という考え

要件定義ではクライアントの要求事項を明確化し、それを実現するための対策を検討します。
しかし、クライアントの満足度ではなくシステムを無事に稼働させることだけにフォーカスしているケースがあります。

例えば、クライアントに「この仕様で良いですよね」と要件を押し付ける場合があります。
システム開発のプロジェクト経験が少ないクライアントの場合、「専門家が言うのだから」ということで、言われたまま進むこともあります。
その結果、後から業務として使えなかったり、プロジェクト背景に合わないシステムになる可能性があります。
開発チームとしては「クライアントから合意を得ている」であり、変更要求が起きるのはクライアント側の都合であり仕様変更ということになります。

しかしクライアントから正式に承認を得た仕様だとしても、業務が回せないシステムでは使い物になりません。

開発チームはシステム開発のプロとして、要望を引き出せるようにクライアントをエスコートすることが求められます。
要件定義を進めるにはスキルが必要ですが、何より大切なのはクライアントの求めていることを引き出すことです。

初期からユーザを参加させる

仕様検討を進めるには業務を熟知しているユーザの協力は必要であるため、プロジェクト初期から参画してもらうことが望ましいです。
具体的にはプロジェクトのキックオフミーティングに参加してもらい、ユーザの参加目的や重要性、役割を共有します。

ユーザは自部署の通常業務を抱えながらシステム開発のために時間を作って対応します。
プロジェクトへの参加目的が曖昧なままでは「余計な仕事が増えた」程度に考えられる可能性があります。
積極的にプロジェクト参加してもらうため、参加の動機付けが重要です。
具体的には、次のことをユーザに理解いただきます。

• プロジェクトの目的と狙い
• プロジェクト成功により得られるメリット（会社の利益）
• ユーザ部門の役割と期待されていること
• プロジェクトの要員計画（いつ、どのような要員が必要か）

キーパーソンを見極める

仕様検討において重要なのは、ユーザ部門の中で誰の意見が強いのか、また決定権を持っているのか見極めることが重要です。
それは仕様検討の打ち合わせに参加していないメンバも考慮する必要があります。
例えば、打ち合わせに参加しているユーザの上司などが該当します。

決定権のないメンバが集まって仕様を決定したとしても、例えば現場を取り仕切っている責任者が「業務で使えない」と言うかもしれません。
そうならないためにも、誰に仕様を確認するのか、また理解を得るのか確認したうえで仕様検討を進める必要があります。

そこで利用できるのがステークホルダー登録簿です。
プロジェクトにどのようなステークホルダー（利害関係者）がいいるのか整理します。
詳細については、別記事「ステークホルダー登録簿の作成」を参照してください。

仕様変更ルールの合意

どれだけ注意深く仕様検討しても考慮不足や認識齟齬により仕様変更が必要になることもあります。
もし変更要求が発生してもトラブルにならないように、事前に変更管理計画を策定してクライアントと合意を取ります。

仕様変更で取り込めるのは次の内容です。

• 仕様変更と仕様不具合の定義
• 仕様変更取り込みの承認ルール
• 変更管理ルール（変更管理方法、見積）

仕様変更の定義がないと、クライアントは仕様不具合と仕様変更の区別がつきません。
すると自分が思ったものと違うものは全て仕様不具合となります。
せっかく要件定義で検討した内容でも、後から参加したクライアントに「あるべき論」を言われて仕様がひっくり返る、ということもあります。

そのような事態を防ぐためにも、仕様変更の線引きは明確にする必要があります。
これはプロジェクト計画の時点で検討し、プロジェクトのキックオフミーティングで全体合意を取ります。

これは現場で担当者とクライアントが独自の判断で仕様変更を決めてしまい、気づいたら作業ボリュームが発生するような事態を防ぐ効果もあります。

ベースラインの明確化

要件定義や基本設計など上流工程の成果物が合意されたら仕様凍結を行います。
つまり作成した成果物がベースライン（基準点）となります。
仕様変更とは、このベースラインを変更することを指します。

もしベースラインがなかった場合、仕様の基準点がないためクライアントから「これは仕様不具合だ」と言われても反論することができません。
結果、クライアントと水掛け論をするか、クライアントからの言い分は全て取り込むことになります。

議事録などを掘り出し、相手を丸め込むための理論武装を整えて議論をしたとしても、お互いに気分のいいものではありません。
そのような事態を回避するためにも 「ここから先は仕様変更となる」というベースラインが重要になります。

異常系の仕様検討

異常系の仕様検討不足で仕様変更が発生する場合が多いです。
異常処理については顧客側のシステム要求事項に出てこないケースも多く、後から「やって当たり前だから仕様変更に該当しない」と言われます。
確かに顧客は要件定義やシステムの仕様検討のプロでもないので、顧客から提示されるのを待つのではなく開発者側から要件を引き出す必要があります。

そして異常系の検討は設計工程に入る前、システム要求事項の中で方針を定義するのが有効です。
例えば外部システムにファイル送信する機能は失敗時に何回までリトライを実行するなどの方針を決めておきます。
その方針をもとに仕様することで要件の抜け漏れを減らすことができます。
また仕様変更に関する責任の所在が分かりやすくなるのもメリットです。

用語の統一

プロジェクト内で使用する用語について、顧客とベンダで認識齟齬が出る場合があります。
使っている単語は同じでも顧客ごとに意図が違う場合があり、後から仕様違いに気づくなどです。
もし会話でかみ合わない、違和感がある、という点が出てきたら、すぐに確認していきましょう。
その一言で防げる仕様変更もあります。