プロジェクトの工程表を、条件を確かめながら進めるには？

工程表は、すぐに予定で埋まります。

第1週に準備、第2週に実行、第3週に完了。各行に日付があり、担当者も決まっている。これで進め方が明確になったように見えます。

もう少し問いかけると、仕事の中身が具体的になります。実行前に必要な資料は何か。前の工程がどこまで進めば、次を始められるのか。成果物の完了を誰が判断するのか。重要な条件が整わなければ、元の日付はまだ成り立つのか。

答えが曖昧なままだと、工程表は希望の一覧になりがちです。日付は近づき、みんな忙しくしていても、プロジェクトが実際に進んだとは限りません。

使える工程表には、目標日、次に進む条件、完了を確認できる根拠を一緒に置く必要があると私は考えます。

日付は仕事の段取りを支えます。条件は、次の工程へ進める理由を示します。証拠があれば、その工程が本当に終わったのかを確かめられます。

この三つをつなぐことで、工程表が実際の管理に役立つようになります。

1．日付を決める前に「完了」を明確にする

計画では、資料の準備、案の協議、テストの手配、納品の推進といった行動を先に並べがちです。

それらは必要ですが、実施したことと完了したことの間には、まだ確認すべき点があります。

「資料準備の完了」は、ファイルが届いた状態でしょうか。それとも、関係者が確認し、次の判断に使える状態でしょうか。「テスト完了」は、誰かが画面を開いた状態か、合意した重要な操作を確認して結果を残した状態か。

同じ作業名でも、人によって受け取り方は異なります。

重要な節目ごとに、まず確認できる一文を作ることを勧めます。この段階の最後に何ができていて、どの条件を満たし、誰が確認するのか。

例えば「要件の打ち合わせを終える」を、この段階のサービス範囲、必須の操作、今回扱わない事項を一覧にし、定めた責任者が版を確認した状態、と書き換えます。

「テスト完了」も、確認済みの範囲に沿って重要な操作を点検し、結果と残課題を記録し、事前に定めた試用条件を満たしたうえで、確認担当者が承認する、と具体化できます。

こうすると日付は、単に行った活動ではなく、確かめられる成果物に対応します。

2．前提条件を書き出して、仕事の順序を見えるようにする

ある節目を先に進められるかどうかは、前の条件に左右されることが多いものです。

範囲の確定が必要な仕事、資料が必要な仕事、資源の確保が必要な仕事、権限のある人の判断が必要な仕事があります。

こうした関係が一部の人の頭の中にしかなければ、工程表には「並行実施」が増えます。実行段階で初めて、後工程の人が前工程の成果を待ち続けていたと分かることがあります。

私は重要な節目から前にさかのぼり、三つ確認します。

• この仕事を始めるために、どの入力が必要か。
• この段階の完了基準を満たすために、どの条件がまだ足りないか。
• 入力や条件を誰が用意し、誰が確かめるか。

そのうえで、依存関係を図にします。

順番に進める仕事、並行できる仕事、前工程の一部ができれば着手できる仕事を分けます。条件に基づく進行は、すべての仕事を一列に並べることではありません。 依存しない仕事は進め、止まっている仕事は、その理由を見えるようにします。

「資料を持っている」と「今回の仕事を支える資料である」も区別します。対象、範囲、日付、版が合わなければ、ファイルが多くても条件は満たされません。

図1は段階を進める基本関係です。日付を追跡しながら、次に進む前に実際の条件と成果物を確認します。該当する基準は、その仕事を始める前に明確にします。

図1をSVGでダウンロード

3．三種類の日付を分けて、進捗を混同しない

日付にも意味の違いがあります。少なくとも次の三種類を分けて記録することを勧めます。

三つの日付が同じ場合もあれば、途中から差が出る場合もあります。その差も確認すべき情報です。

見込み日が目標日より遅ければ、どの条件が変わり、後工程に何が影響し、誰の判断が必要なのかを担当者が説明します。古い日付を後ろへずらすだけでは、問題は残ります。

実際の完了日も、「ファイルを送った」という理由だけで記入しません。確認が必要な段階では、提出と確認済みは別の状態です。

外部の協力者や他の条件が未確定なら、根拠のある見込み期間、その前提、次の確認時点を記録します。見積もる根拠がなければ、確認待ちと明記します。表を埋めるためだけに日付を作りません。

確定した期限も引き続き管理します。間に合わない見込みになったら、影響を速やかに伝え、資源、範囲、連絡、変更を扱います。「条件が整っていない」は、具体的な問題と行動につながる必要があり、説明だけを繰り返す状態にしません。

4．重要な節目に、確認できる関門を置く

小さな作業まで何段階もの承認を通すと、進行が遅くなることもあります。次の段階に本当に影響する節目で確認するのがよいと考えます。

関門の内容は、まず五つで整理できます。

前提条件、成果物、確認の証拠、実行責任者、確認担当者。

実行責任者が仕事を進め、確認担当者が事前の基準に沿って確かめます。小さなチームでは簡潔な運用でも構いませんが、誰が何を根拠に完了としたかは残します。

証拠は厚い報告書に限りません。確認済みの範囲一覧、再確認できるテスト記録、受入記録、双方が合意した納品版なども使えます。何を示し、今回の完了基準に対応しているかが大切です。

確認作業にも処理時間を設けます。提出後、誰がいつ見るのか。問題はどう差し戻すのか。確認が遅れたら誰に相談するのか。決めなければ、「納品待ち」が終わっても「確認待ち」が続きます。

状態は、未着手、進行中、確認待ち、停滞、完了といった普通の言葉で示すことを勧めます。中断が必要なら、その決定と次の対応も残します。

「80％完了」も使えますが、何に対する割合かを説明します。簡単な作業がいくつか終わっても、重要条件が達成間近とは限りません。残った項目のうち、何が次の工程を止めるのかを見えるようにします。

5．条件が整わないときは、不足、影響、判断を分ける

確認で問題が見つかっても、すぐに工程表全体を組み直す必要はありません。

私はまず三つに分けて見ます。

一つ目は、資料や成果物が足りない場合です。

不足を具体化し、誰がどの水準まで補い、いつ再確認するかを決めます。テスト記録がなければ記録を補い、重要な操作に問題があれば成果物を直します。説明書を一つ出しても、本来必要な作業を終えたことにはなりません。

二つ目は、当初の方法や範囲を変える必要がある場合です。

後工程の依存、資源、費用、対外的な段取りへの影響を先に評価します。権限のある責任者が確認してから、作業、条件、見込み日を更新し、変更前後の関係を残します。

三つ目は、重要な条件が現時点で満たせない場合です。

条件を整える作業を続けるのか、進め方を再設計するのか、中断するのか、終了するのか、明確な判断が必要です。それぞれ結果が異なるため、根拠と影響を判断権限のある人に示します。

省略できない条件は、日付の変更や内部の意思表明では代替できません。範囲を調整できる場合も、必要な権限で確認し、適用する完了基準を書き直します。黙って要求を下げ、「完了」に変えてはいけません。

一部の依存関係が止まっても、他の仕事は続けられる場合があります。独立して進められる範囲を見つければ、無駄な待機を減らせます。同時に、未確認の重要な前提に、さらに作業や資源を積み上げないようにします。

図2は停滞への対応方法の一例です。補充、変更、中断には別々の入口があります。日付を更新しても停滞は自動的に解消せず、変更後の条件も確認が必要です。

図2をSVGでダウンロード

6．予約サービスの試行で、工程表の変化を考える

以下は方法を説明するための仮想例で、実在の企業やプロジェクトを示していません。

小さなチームが予約サービスを用意し、第3週の終わりまでに外部での試用を始めたいとします。

「第2週に開発、第3週に公開」としか書かなければ、画面ができた時点で、ほぼ完了したように見えます。

試用条件を展開すると、確認すべき事項が分かります。範囲は確定したか。デモ環境は整ったか。予約と取消の重要な二つの流れは事前基準を満たしたか。例外を受け付けて処理する担当者は誰か。

確認の結果、予約を取り消しても時間枠が正しく解放されないと分かりました。次の予約に直接影響するため、当初の外部試用条件はまだ満たせていません。

この場合、具体的な行動に分けられます。

1. 開発責任者が修正し、新しい版を提出する。
2. 確認担当者が該当の流れを再テストし、結果を残す。
3. プロジェクト責任者が、目標日、現時点の見込み、後工程への影響を説明する。
4. この問題に依存しない試用案内や人員準備は進める。

小さな範囲で手動での対応を併用して始めたいなら、実行可能性、制約、責任を別途評価します。権限のある人の確認を得て、承認された範囲を改めて検証します。予定日になっただけで、元の問題が受け入れられたと考えてはいけません。

「開発提出済み」「再テスト中」「試用可能」は異なる状態です。状態と証拠を分けて残すことで、協力者は次の作業を始めてよいか判断できます。

7．段階の確認表に、まずこの情報をそろえる

最初から複雑な工程表にする必要はありません。重要な一段階を明確にし、前後の関係を少しずつつなぎます。

未確定事項は、その内容と確認を担う人を記録します。資料が足りなければ不足を明確にし、根拠が整ってから判断します。

役に立つ進捗報告は、今どこまで進み、なぜ止まり、次に誰が動き、元の段取りをどう変える必要があるかを伝えます。

結び

工程表で特に確かにしておきたいのは、一つひとつの日付の背後にある、進めるための根拠だと私は考えます。

目標を保ち、責任を明確にし、条件の変化には速やかに対応する。前提条件、成果の証拠、確認をつなげることで、順序が見え、変更も根拠を持って議論できます。

次に工程表を見るときは、一つの重要な節目に沿って聞いてみてください。次へ進むには今何が足りず、誰が補い、誰が確認するのか。

答えが明確になれば、仕事を前へ進めやすくなります。