システム活用法
仕様変更要求が来たら ― ケーススタディ
この記事でわかること
「この画面に、もう1つ項目を追加してもらえませんか」。開発の途中で、利用部門からこうした要望が来るのはよくあることです。この記事では、架空のプロジェクトを例に、仕様変更の要望を受けてから、判定・承認・計画への反映・周知までを、本システムでどう進めるかを追いかけます。
状況
| 項目 | 内容 |
|---|---|
| プロジェクト | 受注管理システムの刷新（開発工程の中盤） |
| 要望 | 営業部から「受注入力画面に『希望納品時間帯』の項目を追加してほしい」 |
| 要望の理由 | 配送センターから、時間帯指定の依頼が増えているため |
| 前提 | 要件がまとまった時点で、WBSをベースライン「要件合意時」として保存してある |
ステップごとの記録
| ステップ | 本システムでの操作 | 記録の例 |
|---|---|---|
| 1. 起票 | 変更管理で変更要求を起票（起票者：営業部の窓口） | 変更したい内容と理由、発生日 |
| 2. 調査 | 開発チームが影響範囲と工数見積（時間）を記録 | 影響：画面1、データ項目1、帳票1、配送連携1。工数見積：96時間（12人日） |
| 3. 判定 | 週次の判定の場で結論を記録。判定結果を入れる | 今回対応。ただし帳票は次の段階へ（コメントに残す） |
| 4. 承認 | 詳細画面の「承認」欄で、承認者（予算・日程の責任者）を順番に選んで依頼 | PMOの課長 → 事業部長の順。承認コメントが履歴に残る |
| 5. 対応 | WBSに作業を追加し、変更要求と関連付ける。スケジュール計算で、日程を再計算して反映 | 「時間帯項目の追加（画面・データ・連携）」を追加し、先行・後続を設定。結合テストの開始日が3日後ろにずれる |
| 6. 周知 | ニュースと、関係する課題へのコメント | テストチームにテスト項目の追加を依頼 |
| 7. 完了 | 起票者が動作を確認して、ステータスを完了にする | 営業部が確認済み |
承認のところで起きること
- 承認を依頼すると、1人目の承認者に通知が届きます。承認すると、2人目に回ります。
- 全員が承認すると、変更の判定結果が「承認」、承認日が入ります。
- 途中で却下されると、そこで終わり、判定結果が「却下」になり、却下理由にコメントが入ります。
- 承認が終わるまで（および却下されたままでは）、この変更を「完了」にはできません。
- 事業部長が出張などで不在のときは、依頼者または管理員が「この承認者を外す」で、その人だけを外せます。
計画への反映：スケジュール計算とベースライン
- 追加した作業に、計画人日、担当者、予定期間、先行・後続を入れます。
- WBSの「管理者ツール」から「スケジュール計算」を開き、結合テストの開始がどう動くか、クリティカルパスに入るか、フロートで吸収できるかを確認します。
- 日程を更新すると決めたら、管理員が「計算結果を反映」を押します。反映は自動では行われません。
- 「ベースライン」の画面で「要件合意時」と比べると、完了予定が何日遅れたか、予定人日が何人日増えたか、追加された作業が何かを一覧できます。
変更の根拠（承認記録）と、計画へのインパクト（ベースラインとの比較）を並べて示せば、後から「なぜ日程が変わったのか」を誰にでも説明できます。
判断のポイント
| 考えること | 見る場所 |
|---|---|
| 終了日に影響するか | スケジュール計算：追加した作業がクリティカルパスに入るか、フロートで吸収できるか |
| 誰の負荷が増えるか | WBSの負荷分析 |
| 一部だけ対応できないか | 影響範囲を分けて、今回やる部分と次に回す部分を検討 |
| 後回しにした部分はどうするか | 判定結果と理由を記録し、次の段階の候補として残す |
| 計画全体にどれだけ響いたか | ベースラインとの比較 |
この流れのコツ
- 口頭で「いいですよ」と言わない：小さく見える変更でも、まず起票して影響を調べます。
- 「全部やる／やらない」以外の選択肢を持つ：この例のように一部だけ対応する判断も有効です。
- 変更要求とWBSを必ずつなぐ：日程が変わった理由が、後から誰にでも説明できます。
- 承認者は最初に決めておく：誰が決めるのかを決めておくと、承認待ちで止まりません。
まとめ
仕様変更は、プロジェクトが現場の役に立とうとしている証拠でもあります。本システムの変更管理・承認ワークフロー・WBS・ベースラインをつないで進めれば、要望に前向きに応えながら、計画と品質を守ることができます。