要件が増えるほど、「誰の仕事か」が見えなくなる

要件が増えること自体は、悪いことではありません。問題は、増え方が誰の合意を経たかを残さないまま積み上がることです。tugiloの支援先でも、機能追加のメモは増えるのに、「最後に誰がYesと言ったか」がログに残っていない——この状態が続くと、リリース後の運用は誰も主語になれないままになります。

見えなくなるのは、役割の怠慢ではなく、決定の履歴が要件に吸い込まれるからです。仕様書には「やること」は書かれるが、「誰がビジネス上のトレードオフを引き受けたか」が書かれない。あとから読む人は、文面だけを見て全員の合意だと誤解します。合意という語は気持ちよいですが、合意の主語が一人に残らないと、増えた行はだれの期待か分かりません。

一度起きた失敗：リリース後に「誰が決めたの」が火種になった日

たとえば、受託で業務システムを作っていた案件で、リリース後にこんなことがありました。現場から「あの画面、こう動いてほしい」と追加要望が続き、都度オンラインで「了解です」と返っていました。仕様書の末尾には箇条書きが増え、誰がビジネス上の追加費用と納期のズレを引き受けたかは、どこにも一行も残っていませんでした。納品の三週間後、経理と開発のあいだで「そんな改修、誰が承認したの？」「いや、現場が急ぎって言ったから」——責任の押し付け合いが始まります。

悪いのは個人ではなく、Yesが記録に残っていない設計です。炎上は、コードの品質より先に、決定のログから起きることがあります。

なぜ人はYesを残さないのか

心理の話からいきます。会議の場では、全員が納得したように見えます。でも「誰が名前を出して引き受けるか」は、衝突を避けたい脳にとって重い。だから議事録には「検討した」「方向性は一致」まで書かれ、最後の一行が抜けることがあります。あとから読む人は、空気まで読み取れません。

組織の話もあります。フラットに見えるチームほど、「決め役」を書くことに抵抗が出ます。合意は美徳ですが、合意のまま要件だけが増えると、誰も「私が決めた」と言えないまま積み上がります。JiraやNotionにチケットは増えても、オーナー欄が空欄のまま——これも同じ構造です。

議事録に責任が書かれない理由は、時間がないからだけではありません。書いた人が後で詰められると感じると、動詞は増えても主語は増えません。「決定」という語を避けて「共有」に寄せる——そういう言い換えは、安心のためであり、同時にログを薄くします。

また、誰が書くかが曖昧な会議ほど、議事録は「全体の空気」で終わります。空気は責任を運びません。書記の名前があっても、承認者の名前がないと、あとからの読み手は迷います。

境界が溶ける三つのパターン

一つ目は、「とりあえず載せる」文化です。会議の宿題がそのまま仕様の箇条書きになり、優先順位より長さが増えます。システムは「作る前」に8割決まっているという話で触れたように、8割は「誰が何を捨てるか」です。捨てた記録がないと、増えた要件は全員の期待に見えます。

二つ目は、承認と実装のあいだに「曖昧な預かり」が挟まることです。「現場に聞いておいて」で終わると、聞いた人のメモが仕様になる。メモの持ち主が退職すると、誰の解釈かが消えます。

三つ目は、運用が始まってから初めて争点になることです。作る前は「できる」で通り、使う段階で「そういう意味じゃない」が出る。これはコミュニケーションの問題というより、意思決定の所有者が記録にいないことが多いです。

Yesが残ると、現場はどう変わるか

エスカレーションが速くなります。障害や仕様の疑義が出たとき、「誰に聞けばいいか」が会議室を一周しなくて済みます。最終承認者が一行で残っていると、判断の待ち行列が短くなります。

保守の温度も下がります。「なぜこうなったか」を調べる作業が、ログの奥のチャット探索ではなく、議事録の末尾の一行に着地します。心理的安全性とセットで語られるべきですが、ログがないときに起きるのは、安全ではなく疲弊です。

要件の増え方も変わります。「誰がYesと言ったか」が見えると、追加は勇気のいる操作になります。勇気が要るぶん、増え方は少し遅くなります。遅さは、だいたい取り返しのつく遅さです。

見積と契約の話にも効きます。「仕様変更です」と言える根拠が、チャットの断片ではなく承認者の一行に寄ると、数字の話が短く済むことがあります。正義の話ではなく、手戻りの単価の話に戻せます。

要件を運用に残すフレーム（指でなぞれる版）

要件が増える現場では、tugiloでは次の一本線で見ます。

要件 → 検討 → Yes → 記録 → 実装 → 運用

検討だけが長く、Yesが空欄のまま実装に入ると、運用はいつも誰かの記憶頼みになります。記録は、完璧な議事録より先に、誰がYesと言ったかの一行でよいことが多いです。

実装が始まってから「あれも足す」ほど、Yesの行が効きます。足すほど誰かの時間が動くからです。時間が動くなら、名前が一行あるのが自然です。

戻すための三つの問い（会議の冒頭でよい）

難しいRACI表の前に、次の三つだけでも違います。

1. この追加は、誰の業務のどの痛みを減らすか（主語は一人でよい）
2. 捨てた選択肢は何か（何をしなかったかを一行でよい）
3. リリース後、誰が数を見るか（測り方の所有者）

これが揃うと、要件の増え方がログ付きになります。

設計レビューの議事録が長いほど、あとから読む人ほど「全部やる気だ」と誤読しやすいです。長さの問題ではなく、Yesを言った人が一行に残っていない問題です。一行あれば、長い議事録は「背景」として読めます。一行ないと、長い議事録は全員の期待に見えます。

まとめ：要件は増えてよい。ただし所有者は一つに残す

要件が増えるほど見えなくなるのは、自然な現象です。だからこそ、決めた人と捨てたことを仕様と同じ場所に残す——これが設計の保守です。いきなり体制を変えなくてよい。一行だけからで構いません。

今週やるのは、これだけ

次に開催する「要件・仕様・優先度に触れる会議」について、チームがもう使っている議事録の正本（オンラインドキュメント1つに決まっているもの）の、本文の最終行の直後に、空行を1つ入れ、そのあと1行だけ追加する：最終承認：フルネーム。（括弧書きの役職は任意。名前は必ず。それ以外の行は増やさない。）
どこに書くか：その議事録の最下部（テンプレート末尾に「最終承認：」があれば、その直後の1行だけ）。チャットの要約・Slackスレッド・口頭のあいづちにはこの週は書かない。会議が複数ある場合でも、今週触るのは次の1回の議事録だけにする。

合言葉：決定は書かなければ存在しない。