株式会社ラフティ | Time Craft Consulting
Chapter 1 Backlog＝判断コミュニケーションの正本
― 会話と判断を分離し、行動を自動連動させる運用設計
この Chapter では、
運用を止めないために「判断をどこに集約するか」を明確にします。
多くの現場では、
判断は口頭、チャット、会議、DMなどに分散しています。
その結果、
-
判断がどこで確定したのか分からない
-
誰の責任で決まったのか追えない
-
後から経緯を確認できない
-
行動が止まる、または二重化する
という問題が、運用フェーズで必ず発生します。
本 Chapter では、
判断を伝達・固定・追跡するための「正本」をどこに置くべきかを整理します。
1-1. Backlogはタスク管理ではない
Backlogは、
単なる「やることリスト」や「進捗管理ツール」ではありません。
本運用においてのBacklogの役割は、
-
誰が
-
何を
-
どの判断として
-
どの責任で
-
どう進めるか
を 一か所に固定するための装置です。
つまり、
判断コミュニケーションの正本として扱います。
1-2. 会話に判断を置くと、必ず運用は壊れる
会話は、思考を整理するためには有効です。
しかし、会話は 判断を残す場所ではありません。
会話ベースの運用では、
-
判断が流れる
-
文脈が失われる
-
発言者が曖昧になる
-
記録が断片化する
結果として、
「結局、どう決まったんでしたっけ？」
という確認が、必ず発生します。
これは人の問題ではなく、
会話という媒体の性質によるものです。
1-3. Slackは会話、Backlogは判断
Slack（や類似のチャットツール）は、
会話のためのツールです。
-
検討
-
相談
-
意見交換
-
思考の発散
これらには向いています。
しかし、
-
判断の確定
-
責任の固定
-
行動の指示
-
後追い可能な記録
には向いていません。
そのため本運用では、
会話はSlack、判断はBacklog
と明確に役割を分離します。
1-4. Gitだけでは判断は残らない
Gitは、
コードの履歴を管理するための仕組みです。
-
何が変わったか
-
いつ変わったか
は分かります。
しかし、
-
なぜその判断に至ったのか
-
他に選択肢はなかったのか
-
どこまで影響を想定していたのか
といった 判断の背景 は、
Gitだけでは残りません。
そのため、
-
Git：結果（コード）
-
Backlog：判断（背景・責任・方針）
という役割分担が必要になります。
1-5. Jootoやタスク管理ツールが片手落ちになる理由
一般的なタスク管理ツールは、
-
作業の割り当て
-
進捗の可視化
には適しています。
しかし、
-
判断の粒度が粗い
-
責任と判断が分離されやすい
-
背景や経緯が流れやすい
という特徴があります。
その結果、
「タスクは終わっているが、なぜその形になったのか分からない」
という状態が生まれます。
1-6. なぜBacklog的思想が運用に合うのか
Backlog的思想が運用フェーズに適している理由は、
-
課題単位で判断を固定できる
-
コメントで判断の変遷を残せる
-
責任者が明確になる
-
後から経緯を追跡できる
点にあります。
重要なのは、
Backlogというツールそのものではありません。
この「判断を一単位に束ねて残す思想」が重要です。
現時点では、それに最も適している例が
Backlogである、という位置づけです。
1-7. 判断が確定した瞬間に、行動が決まる構造
判断がBacklogに集約されると、
-
誰が判断したか
-
何をするか
-
次のアクションは何か
が明確になります。
その結果、
-
確認が不要になる
-
相談が減る
-
行動が止まらない
という状態が生まれます。
これは人が頑張っているからではなく、
構造がそうさせている結果です。
まとめ
運用を止めないために必要なのは、
ツールを増やすことでも、
コミュニケーションを増やすことでもありません。
判断をどこに置くかを決めることです。
-
会話は会話の場に
-
判断は判断の正本に
-
行動は自動連動させる
この分離によって、
運用は「勝手に進む」状態になります。