複数プロジェクトが完成してもサービスを開始できない：依存関係の管理

予約画面は完成した。顧客データも移行した。問い合わせ窓口の準備も終わった。各プロジェクトの報告は緑なのに、新サービスの開始日には予約を受けられない。顧客番号の意味がシステムごとに違い、窓口には例外処理の権限がなかったからだ。

これは、個々の完了と、組み合わせて使える状態が異なることを示す仮想例である。会議を増やして各担当へ「連携を密に」と求めても、何を受け渡せば使えるのか、誰が条件を変更できるのかが曖昧なままなら解決しない。

本稿の提案は、案件内で解ける作業調整は現場へ残し、他案件の利用条件や共通の日程を変える判断を、影響を引き受けられる場へ上げることだ。その境界を、報告の色ではなく受け渡しの条件で決める。

完了日を並べるだけでは、依存関係にならない

プロジェクトAが金曜に終わり、Bが翌月曜に始まると書いても、Bが使える成果物をAが渡す保証にはならない。Aの「完了」が開発者の試験終了で、Bの「開始」に必要なのが本番データの承認なら、予定表の間に仕事が抜けている。

まず、受け取る側が次の作業を始められる条件を言葉にする。データなら項目の形式だけでなく意味、更新方法、例外、利用の許可まで関係する。窓口の引き継ぎなら、資料の送付だけでなく、判断できない案件の渡し先が必要になる。

米国会計検査院の2015年の工程評価ガイドは、複数プロジェクトを含む全体工程と個々の工程のクリティカルパスを区別している。全体の完了を左右する経路と、各案件で重要な経路は同一とは限らない。遅延や実績の更新で関係が変わるため、両方を見る必要があるという整理だ。

この資料は、主として米国の公共プログラム等で使う工程管理の実務指針である。日本の開発現場で、統括担当を置けば納期が何％短くなるという比較実験ではない。それでも、各案件の約束を守ることだけでは、全体の利用開始を説明できない理由を理解する助けになる。

統括担当が引き受けるのは、すべての細部ではない

先ほどの仮想例で、画面の色やボタン配置を変えても、他案件の受入条件に影響しないなら、担当プロジェクトの判断で進められる。すべてを全体会議に掛ければ、統括担当そのものが待ち行列を作る。

一方、顧客番号の付け方を変えるなら、移行データ、画面、窓口の検索方法が変わる。画面側だけが変更を決めると、別案件で作り直しが生じる。必要なのは、影響を受ける側が条件を確認し、費用や開始日が変わるなら、その変更を決める権限のある責任者へ上げる仕組みだ。

NASAのインターフェース管理の説明は、接続する当事者の間で責任と変更手順を定め、変更の影響や承認の理由を記録する考え方を示す。対象は宇宙システムなどの技術管理であり、その組織や書式をそのまま小規模な業務改善へ持ち込む必要はない。

借りたいのは、接続の片側だけで共有条件を変えないという原則である。専門的な内容は当事者同士で確かめ、共通の費用・範囲・開始日の選択は、責任を持つ人が決める。連絡を取る役と、取引条件を変更する役は同じとは限らない。

同じ遅れでも、上げる判断が変わる

架空の二つの案件を考える。Aが提供するデータの完成が遅れたが、Bの試験には合意済みの試験用データを使え、最終確認の時間も残っている。この場合、まず当事者間で試験を進め、受け渡し予定を更新する案を検討できる。遅れたという事実だけで、全体の開始日を変える必要はない。

条件を変え、Aの実データが届かなければ、Bの重要な例外処理を試験できないとする。仮データでは問題を再現できず、受入れ後に必要な試験時間も足りない。ここでBを予定どおり完成扱いにするのは、未確認の仕事を消しただけだ。

この場合、利用範囲を限定して先に始める案と、必要な確認が終わるまで開始を延ばす案を比較する。限定案には、除外する利用者、扱わない処理、後から追加する条件を置く。安全性や整合性の前提を満たせないなら、形式上の開始日を守るために範囲を曖昧にしない。

「誰かが調整する」を、一件の約束へ変える

受け渡しごとに、渡すもの、受け取る側の利用条件、必要な時点、両側の担当、条件を変えるときの決定者をそろえる。大量の管理帳票を作るためではなく、変更が起きたときに誰へ何を相談するかを特定するためだ。

担当者に決定権がない案件では、上位へ送る内容を絞りたい。「Aが遅れています」ではなく、「利用範囲を狭めるならこの開始日、全範囲ならこの確認が必要」と選択肢にする。費用と利用上の影響を引き受ける人が、何を選ぶのかを明確にできる。

完了したファイルでも、相手の入力にはならない

予約サービスの接続でも、利用側の試験時間と判断期限がなければ受け渡しは終わりません。作成側の納品報告に加え、相手の業務で使えることを受け入れる必要があります。両案件が予定どおりでも、その確認点がなければ統括担当が共有条件と決定権を整えます。稼働後の効果は便益の診断として別に追います。 便益の診断

共有試験環境は、先に準備できた順なら早いか

GAOのガイド57～61頁は、資源の利用可能性に合わせて作業の開始や割当を調整し、日程への影響を確かめる必要を説明する。接続経路が並行でも、試験環境が一つで同時使用できなければ試験は直列になる。加えて、先行試験後に共通IDや接続版を変えるなら、その変更が先行試験の証拠に及ぶ範囲も見る。

説明用に、試験環境と担当者を一組だけ使う二つの接続試験を仮定する。Aは今から試験でき、3時間かかる。Bは4時間後に実データがそろい、試験に2時間かかる。どちらも次の試験へ渡す際のデータ復元に1時間が必要で、途中の中断や他案件はない。Bの希望期限を優先して枠を空ける案と、準備済みのAを先に試す案を比べる。

後者で、Bが共通の接続版を変えず、Aの確認がそのまま使えるなら6時間で終わる。条件を変え、Bの試験は変更後の接続版で合格する一方、Aの先行試験の証拠だけが使えなくなるとする。Bを先にする案では、Aもその変更後の版で試験する。両案を同じ最終構成で比べ、Aを先にする案の再準備・再試験の合計をr時間として、終了は6＋r時間になる。rが4時間未満なら前者より早く、4時間なら同着、4時間を超えれば遅い。例えば全面的なAの再試験3時間と再準備1時間が必要なら、先に試したAも含めて10時間となり、順番の変更だけでは短縮していない。

この境界は仮定の工程計算で、実案件の短縮実績や遅延確率ではない。NASAの6.3.1.2.3節は、接続の管理資料と承認済み変更を検証・妥当性確認の入力として扱う。本稿ではそれを参考に、試験済みの構成を固定し、後続変更によってどの確認が使えなくなるかを判定してからrを置く。早く一度通ったことを、変更後の全体合格へ読み替えない。

未確認の接続が先行する利用範囲にも必要なら、共通の開始日を見直す。独立して切り離せるなら、除外する業務と後日の接続確認を定めて先行利用を比較する。決めるべきは「締切順か準備順か」という標語ではなく、待ち・復元・再試験を含めた順序と、その順序で利用可能になる範囲である。

報告を増やさず、つながりの弱い箇所を確認する

全案件の全作業を一つの表で細かく追うことが、常に有益とは限らない。GAOのガイドも、詳細を追う便益が負担に見合わない場合には中間的な工程表を使う考え方を示している。全体に強く影響する箇所は具体化し、比較的独立した仕事は必要な粒度へまとめるという使い分けだ。

本稿の提案では、全体報告の中心を、受け渡し条件が未合意のもの、使う時点に間に合わないもの、決定者が不明なものに置く。件数を減らすだけを目標にすると未解決を隠すため、解決した内容や、どの選択で条件を変えたかも追う。

運用後には、資料がそろったかだけでなく、受け取った相手が次の作業を始められたかを確認する。開始できたのに本番で誤りが出たなら、受入条件で重要な例外を落としていなかったかを見直す。担当者の連絡回数ではなく、約束した接続が機能したかを評価したい。

案件内の改善で受け渡し条件を守れるなら現場へ任せる。共有条件を変えるなら両側で合意し、全体の開始日や費用へ及ぶなら責任者が選択する。「全体を見る人」を増やすより先に、全体へ上げる判断を定義する。それが、緑の進捗報告を、使い始められるサービスへつなぐ方法である。