はじめに
システム開発で発生する仕様変更は正しく管理しないとプロジェクト破綻につながります。
作業量が増えるだけでなく手戻り作業の発生、他機能の仕様整合性、メンバのモチベーション低下などの影響が考えられます。
プロジェクトの当初想定していた要件が完璧で変更の余地がないケースは、まず無いでしょう。
仕様変更自体ではなく、変更要求を適切に管理してプロジェクト推進できないところに問題があります。
ここでは仕様変更とは何かを振り返り、変更要求が発生したときの管理方法について解説します。
仕様変更を回避する方法については、別記事「変更要求の大量発生を抑止するための７つのポイント」を参考にしてください。
仕様変更の定義
仕様変更とは、一度合意されたシステム要求事項や仕様を開発途中で変更することです。
そこには要求事項や仕様の削除も含まれます。
つまり顧客と合意したシステム要求事項や仕様を変えることです。
逆に言うと顧客側と要件定義や基本設計などのレビューが行われておらず、承認を得ていない状態では「これは仕様変更だ」と言うことは出来ません。
仕様変更扱いの是非で揉めるプロジェクトでは、往々にして上記の承認や合意がされていない場合が多いです。
承認されないのは、顧客側に要求事項や仕様を確定する自信がなかったり、責任を取れないなどの思惑があったりします。
このような場合、承認が曖昧なまま工程完了するのではなく顧客側と交渉する必要があります。
もし進展の目途が立たなければ、ステアリングコミッティを開催して経営陣を巻き込むことも視野に入れます。
それで揉めるようなら、むしろ開発を進める方が危険というものです。
しっかり承認を得て、仕様変更の基準値となるベースラインをつくります。
仕様変更の管理方法
要件追加／変更の発生
仕様変更と思われる要求追加や変更依頼が発生した場合、仕様変更になるかは後で考えるとして仕様変更管理表に事象を記載します。
※仕様変更管理表サンプルは、こちらで無料提供しているので活用ください。
変更依頼の発生時は基本情報となる起票日や発生日、件名などを入力します。
抜け漏れで検討されない事態を避けるため、仕様変更でなくても記入します。
対応方法の検討
仕様変更扱いの判断
要件定義書や設計書を確認して、仕様変更に該当するか確認します。
ベースラインである要件定義書や設計書を変更する場合、仕様変更となります。
判断が難しいのは要件定義書や設計書に記載されていない要求事項や仕様の取り扱いです。
明らかに顧客側から言われないとわからない要求事項は仕様変更扱いと判断できますが、ベンダが考えれば必要とわかる機能は微妙です。
例えばシステムのバックアップ機能など、顧客からは言われなくてもベンダ側としては要件を確認して当然の機能などです。
「顧客から言われなかったから入れてない」では開発者としてお粗末で、非機能要件の中で開発側がイニシアティブをとって確認すべき事項です。
ただDBデータを出力して格納する程度であればよいですが、機器手配や大がかりな仕組みが必要になる場合もあります。
そのようなときは、顧客側も背景を開発側に説明する必要もあるため、一概に開発側の責任というわけでもないと思います。
このように仕様変更扱いなのか微妙な変更依頼はあります。
その時は変更内容の重要度を見ながら顧客とベンダで対応できる範囲を模索してwin-winになるように調整することが望ましいです。
win-loseになると、lose側に負担が発生してプロジェクト全体に悪影響を与える可能性があるので注意です。
影響範囲の確認
仕様変更の影響範囲を確認するときは、マクロとミクロの視点で検証します。
マクロ視点では業務影響やシステム要求事項の視点から影響がないか確認します。
この視点で影響が出る場合、影響範囲が非常に大きくなる可能性があります。
規模見積もり作業も労力がかかるので、見積もり作業前に変更の重要度や緊急度など顧客に確認すると良いでしょう。
ミクロ視点では設計やプログラムレベルで影響確認します。
影響範囲に調査漏れがあると、その後の規模見積もりが正しく算出できません。
不具合などのトラブルにもなるため、メンバに調査依頼を出すときは任せきりにするのではなく、調査方法や結果確認を十分に行う必要があります。
これらの調査結果は関係者に共有し、認識合わせと他の抜け漏れがないかの確認も行います。
規模見積もり
仕様変更の影響範囲を確認したら、仕様変更対応するための規模を見積もります。
この見積もりは工数と費用の両方を算出するのですが、ここにプロジェクト管理費やリスク費を忘れずに含めます。
仕様変更の内容によっては他システムも影響があることがあり、そちらの内部調整や規模見積もりなど時間がかかる場合があるので、規模見積もりを急いでいる場合は注意しましょう。
対応要否の判定
最初に顧客と依頼内容が仕様変更扱いなのか認識合わせを行います。
仕様変更扱いで合意できた場合、影響範囲と見積もりの費用、仕様変更の重要度をもとに対応するのか顧客と調整します。
もちろん顧客側も限られた予算内に納めなければいけないため、変更内容を見直したり、他のシステム要求事項を取り下げることも視野に入れて検討します。
また費用だけではなくスケジュールも考慮する必要があります。
要員数により対応できる作業量は決まっているため、仕様変更を対応すると納期に間に合わない場合があるため、マスタスケジュールを見ながら、どのタイミングで取り込むのか検討します。
もし納期に間に合わない場合は、２次リリースなどスケジュールを分けて対応することも視野に入れます。
費用やスケジュールについて、リスク費やバッファ期間を使用することがあります。
その際、プロジェクト本体でリスク発生時に使用するリスク費やバッファは残しておく必要があります。
間違っても全ての予備を使い切らないように注意しましょう。
仕様変更の注意点
システム開発をしていると、何かしら仕様変更の話は出てきます。
中には対応規模が軽微であったり、何かのついでに対応できるような仕様変更もあります。
こういった変更依頼についても担当者の独自判断で取り込まれることがないように注意しましょう。
理由として、主に次のような問題につながるためです。
- 軽微な変更も積み重なって無視できない規模に膨れ上がる
- 担当者では気づかない他機能への影響の可能性
- ベースラインの管理ができなくなる（何が正しいかわからない）
- 顧客の変更依頼に対する敷居が低くなる
仕様変更の取り込み
仕様変更を取り込むことになったらプロジェクト計画書の見直しから始めます。
見直すのは以下３つのベースラインです。
- スコープ・ベースライン
- スケジュール・ベースライン
- コスト・ベースライン
上記の計画見直しを行ったら、WBSにアクティビティ（タスク）を追加して日程と担当者を設定します。
仕様変更で修正した要件定義書や設計書、プログラムなどの成果物はベースライン。
今後、新しく仕様変更が発生する場合は、このベースラインと見比べながら仕様変更の有無を検証します。
