一覧では見えない、仕事同士の関係を共有する
AI Work Governance｜仕事の関係 1/3 — 可視化
前の記事（Core 06）「AIの仕事をどう収束させるか」では、IssueやPull Requestが複数になったとき、単体タスクの完了だけではなく、複数の仕事をどう収束させるかを扱いました。
そのとき、最初に必要になるのが、仕事同士の関係を見える形にすることです。
一覧だけでは、仕事のつながりが見えない
IssueやPull Requestを一覧にすると、「Open」「Closed」「Draft」「Ready」といった現在状態は分かります。しかし、それだけでは次のような関係が見えません。
- このIssueが終わらないと、別のPull Requestを進められない
- このPull Requestは、別のIssueで決めた設計を実装している
- 二つのIssueは似ているが、片方がもう片方を妨げているわけではない
- ある作業の結果によって、別の作業の前提が変わる
つまり、一覧は「何があるか」を見るには向いていますが、「どうつながっているか」までは十分に表せません。
仕事を点ではなく、関係として見る
そこで、仕事を一つずつ独立した点として見るのではなく、関係を持ったまとまりとして考えます。
Issue A
│
├─ 妨げている ──> Pull Request B
│
└─ 関連している ─> Issue C
│
└─ 実装している ─> Pull Request D
この形にすると、「どれが重要か」だけではなく、今どの仕事を動かすと、どこへ影響するかを考えやすくなります。
関係には種類がある
ただし、線でつながっていれば全部同じ、というわけではありません。
たとえば、「関連している」と「妨げている」は意味が違います。
related-to blocks implements supersedes
システム内部では、このような短い表現を使うことがあります。しかし読者が理解すべきなのは英単語そのものではなく、関係の意味を区別する必要があるという点です。
「関連している」だけなら、同時に進めても問題ないかもしれません。一方、「妨げている」なら、先に解決すべき仕事が存在します。
AIが推測した関係を、そのまま事実にしない
大規模言語モデル（LLM）は、Issue本文やPull Requestの説明を読んで「この二つは関係していそうだ」と推測できます。
しかし、推測された関係と、実際に確認された依存関係は同じではありません。
確認済みの関係 ≠ AIが推測した関係
たとえば似たテーマのIssueが二つあっても、一方がもう一方を妨げているとは限りません。関係があるように見えることと、作業上の依存が存在することを分けて扱う必要があります。
「関係が見つからない」と「関係がない」も違う
もう一つ重要なのが、観測できなかったことを「存在しない」と断定しないことです。
関係が見つからなかった ≠ 関係が存在しない
検索範囲が狭かった、参照先を読んでいなかった、情報が古かった、といった理由で関係を見落としている可能性があります。
そのため、分からない状態は「不明」として残せる方が安全です。
関係図は正本ではなく、現在状態を見るための補助情報
仕事同士の関係を図にしたものは便利ですが、それ自体を唯一の正本にしてはいけません。
IssueやPull Requestなど、実際の仕事の状態を持っている場所が正本です。関係図は、それらを読み取りやすくまとめた観測・派生情報として扱います。
Issue / Pull Request
= 現在状態の正本
↓
仕事の関係図
= 理解・判断を助ける派生情報
高性能なAIなら、関係図は不要なのか
高性能なLLMは、複数のIssueやPull Requestを直接読み、仕事同士の関係をその場で推論できます。
そのため、仕事の関係図がなければAIが判断できない、という主張はしません。
それでも関係を外へ出しておく価値があります。AIだけでなく、人間、別のAI、別セッションでも、同じ仕事構造を確認・議論・修正しやすくなるからです。
実装するときに必要なのは、識別と根拠
仕事の関係を扱う仕組みを実装するときは、少なくとも次の情報を区別できる必要があります。
- 識別子 — どの仕事を指しているか
- 関係の種類 — 関連、妨げ、実装など
- 根拠 — なぜその関係だと判断したか
- 観測範囲 — どこまで確認したか
- 鮮度 — いつの状態を見ているか
識別子も、単純な番号だけでは不十分な場合があります。別のリポジトリに同じIssue番号が存在するからです。
リポジトリA / Issue #42
リポジトリB / Issue #42
│
└─ 同じ番号でも別の仕事として区別する
ここで重要なのは、特定の実装名や内部ファイルではありません。どの仕事・どの関係・どの根拠を見ているかを曖昧にしないことです。
関係を見えるようにすると、次の問題が出てくる
仕事の関係を一度可視化しても、その状態はすぐに古くなります。
- Issueが閉じる
- Pull Requestがマージされる
- 新しい問題が見つかる
- 前提だった設計が変わる
- 別の作業が新しい妨げになる
つまり、仕事の関係は一度作って終わりではありません。
次の記事では、状態が変わったとき、仕事の関係をどう再評価するかを考えます。
← 前の記事：06｜AIの仕事をどう収束させるか
次の記事：08｜状態が変わったら仕事の関係を再評価する
コメント