承認待ちが溜まると、作る側が止まる

🚦止まっていたのではなく、止めていた

未承認の下書きが上限（6本）を超えている間は新しく生成しない、という歯止めをあらかじめ自分で仕込んでいました。上限に達すると実行ログには毎回「今回はスキップします」とだけ残り、外からはエラーと見分けがつきません。

2026年7月26日に実行ログを見に行くと、直近の3回とも「未処理の下書きが28本（上限6）。今回はスキップします」と出力していました。エラーではありません。設計どおりの動作です。

歯止め自体は正しく働いていました。上限がなければ、承認されない下書きが際限なく積み上がっていたはずです。問題は、上限に張り付いたまま8日間誰も気づかなかったことのほうでした。ログには毎回「スキップしました」と書いてあったのに、その行を読んでいなかった。

🧮作る速度を上げても、出る量は増えない

律速（ボトルネック）は生成側ではなく、承認して外に出す側にありました。生成回数を増やしても、出口が詰まっている限り公開できる本数は増えません。

気づいた直後、私は「生成の頻度を上げようか」と考えました。完全に見当違いです。上限に当たって止まっているのだから、作る回数を増やしても1本も増えません。増えるのは、スキップの回数だけです。

進行中の作業量に上限を置く考え方は、カンバンの世界では明示的に定義されています。The Kanban Guide は、開始から完了までの作業項目の数を明示的に制御しなければならないと書いており、その効果として「引っ張る（プルする）仕組みが生まれる」と説明しています。空きが出たときに次を取る、という順序です。

つまり私がやるべきだったのは、押し込む量を増やすことではなく、詰まっている出口を先に開けることでした。

🔍在庫は「作った量」でなく「出せる状態か」で数える

在庫の本数を数えるだけでは、詰まりの正体は分かりませんでした。1本ずつ中身を確認すると、承認待ちではなく機械的な検査を通っていないものが大半でした。

在庫の中身を1本ずつ調べると、その多くは「作りかけ」ではなく「機械的な検査を通っていない」状態でした。完成の基準を満たしていないものは出せません。Scrum Guide も、完成の定義を満たさない成果物は「リリースすることも、レビューで提示することもできない」と書いています。

なので在庫を「何本あるか」でなく「そのうち何本が今すぐ出せる状態か」で数え直しました。この数え方に変えてはじめて、詰まりが承認の遅さではなく検査の不通過にあると分かりました。減らすべき対象が具体的になった瞬間です。

🧭まとめ: 出口から見る

• 上限に当たって止まるのは正常動作なので、エラーを探しても見つからない
• 律速が出口にあるとき、作る速度を上げても出る量は増えない
• 在庫は本数でなく「今すぐ出せる本数」で数える

自動化を足すときは「どれだけ作れるか」を先に考えがちですが、詰まるのはたいてい出口のほうでした。

📚参考・出典

• The Kanban Guide（May 2025）（開始から完了までの作業項目数を明示的に制御しなければならない、その効果としてプルシステムが生まれる、と記述されている）
• The 2020 Scrum Guide（Ken Schwaber / Jeff Sutherland）（完成の定義を満たさない成果物はリリースすることもスプリントレビューで提示することもできない、と記述されている）