プログラムで最も多いトラブルは、技術の難しさではありません。プロジェクトとプロジェクトのつなぎ目で起きます。

「Ａさんのチームが作ると思っていました」「いや、こちらは受け取る側です」。この会話が出てきた時点で、すでに数週間が失われています。

■ 依存は「渡すもの」で書く

依存関係を「PJ1のあとにPJ2」と書いても、何の役にも立ちません。前後関係だけでは、何が起きたら問題なのかが分からないからです。

図のように、矢印の上に「何を、いつまでに渡すか」を書きます。これだけで管理できる形になります。

このリストを「依存一覧」として1枚にまとめ、毎回の定例で見ます。項目数は多くても20件程度です。それ以上になるなら、プロジェクトの切り方を見直したほうがいいかもしれません。

■ 見落としやすい依存が3種類ある

成果物の受け渡しは、比較的気づきやすい依存です。問題は残りの3つです。

人の依存。同じ業務担当者が、複数のプロジェクトのレビューに必要なケース。線表上はどのプロジェクトも問題なく見えますが、その人の予定を重ねると破綻しています。プログラム側でしか気づけません。

意思決定の依存。PJ1で「データの持ち方」を決めると、PJ2とPJ3の設計が変わります。決定が1か月遅れると、2つのプロジェクトが同時に止まります。だから、影響範囲の広い決定ほど、早い時期に置く必要があります。

外部の依存。法改正の施行日、製品のバージョン提供時期、他部署の組織改編。自分たちでは動かせないので、早く知ることしかできません。四半期に一度、外部要因を棚卸しする時間を取ります。

■ つなぎ目は「両方に名前を書く」

依存の管理で一番効くのは、仕組みより名前です。

渡す側と受け取る側の両方に、担当者の名前を書きます。そして、その2人が直接やり取りする関係を作っておきます。プログラムマネージャーを経由させると、伝言ゲームになって遅くなります。

プログラム側の役割は、間に入ることではなく、2人がつながっているかを確かめることです。

■ 期日は「渡す日」ではなく「使える日」で書く

よくあるずれが、これです。

「渡す」ではなく「使える」で書くと、受け取る側の確認作業が計画に入ります。この一手間が、後半の混乱をかなり減らします。

■ 依存が遅れたときの動き方

遅れは必ず起きます。大事なのは、起きたときの動きです。

• 遅れが分かった時点で、受け取る側に直接伝える（プログラム定例を待たない）

• 受け取る側が「暫定で進められる方法」を出せるか確認する（一部だけ先に、仮データで、など）

• 暫定策がなければ、プログラム全体の線表に影響が出るので、その日のうちに記録する

2つ目がうまくいくかどうかが、プログラムの粘り強さを決めます。「完成品が来るまで待つ」しかない設計だと、1つの遅れが全体に波及します。

■ まとめ

依存関係は、前後関係ではなく「何を、誰が、いつまでに、誰に渡すか」で書く。期日は「使える日」で書く。そして、人・意思決定・外部という見えにくい依存を定期的に棚卸しする。

いま関わっているプログラムで、依存の一覧があるか確認してみてください。なければ、まず成果物の受け渡しだけでも書き出してみると、つなぎ目の穴が見えてきます。