遅延が発覚した日 ― 本システムでの対応の一日

この記事でわかること

どんなに丁寧に計画しても、プロジェクトでは遅れが起きます。大切なのは、遅れが分かったその日に、落ち着いて正しい順番で手を打つことです。この記事では、ある架空のシステム導入プロジェクトを例に、遅延が発覚した一日を本システムでどう過ごすかを紹介します。

状況

一日のタイムライン

9:30 課題を起票する

まずは事実を記録します。「結合テスト環境の構築が5日遅れる」という課題を起票し、主管チーム（インフラチーム）と予定完了日を設定します。この時点では、原因や対策が分からなくても構いません。分かったことをすぐ記録することが最優先です。

10:00 WBSで影響を確かめる

課題を「環境構築」のWBSタスクと関連付け、そのタスクの予定完了日を5日後ろにずらします。続けて、WBSの「管理者ツール」から「スケジュール計算」を開きます。先行・後続の関係から、次のことがすぐに分かります。

スケジュール計算は、画面で結果を見るだけでは予定日を書き換えません。後続タスクの日程を更新するときは、管理員が結果を確認して「計算結果を反映」を押します。反映は手入力の日付も上書きするので、対象を絞って実行します。

11:00 リスクを見直す

「ベンダーの作業遅延」がリスクとして登録されていれば、ステータスを更新し、今回の課題と関連付けます。予測していたことが起きたと記録に残すことで、対応策が役に立ったかを後で振り返れます。

14:00 変更要求を起票し、承認を依頼する

フロートでは吸収しきれず、本番稼働日を3日ずらす必要があると分かりました。計画を変えるため、変更要求を起票し、影響範囲と工数見積を記録します。課題と関連付けておけば、判定する人が経緯をすぐに確認できます。

変更の詳細画面の「承認」欄で、責任者を承認者に選んで承認を依頼します。承認者には通知が届き、承認されるまでは、変更を「完了」にできません。

16:00 関係者へ周知する

判定の予定と現在の状況をニュースで全体に周知します。課題や変更要求をウォッチしているメンバーには、更新のたびにシステム通知が届くため、個別に連絡して回る必要はありません。外部連携でSlackやTeamsに通知を流している場合は、タスクの更新もそちらに届きます。

この日に作られた記録

この流れのコツ

• 「記録→影響確認→判断→周知」の順番を守る：影響を確かめる前に周知すると、情報が何度も変わって混乱します。
• つなぎながら記録する：新しい記録を作るたびに関連設定をしておくと、夕方には「なぜ本番稼働日が変わるのか」を一つの流れで説明できます。
• 数字で話す：クリティカルパスとフロートを使えば、「たぶん大丈夫」ではなく「あと2日までなら吸収できる」と具体的に説明できます。

まとめ

遅延そのものは避けられなくても、対応の質は仕組みで高められます。本システムでは、課題・リスク・WBS・変更・通知がひとつにつながっているため、遅れが分かったその日のうちに、影響の把握から関係者への説明までを終えることができます。