優れたカンバンボードは進捗確認MTGを不要とするか

こんにちは。ウェビナーマーケティングSaaS「Bizibl」で開発エンジニアをしている金井です。

みなさんのチームでは「進捗確認ミーティング」、実施していますか？
「あの機能、今どうなってる？」「デザインレビューは終わったんだっけ？」
そんな会話に多くの時間を割いていないでしょうか。

今回は、Notionを使ったカンバンボードの再設計によって「進捗確認のためのMTGを不要にした」お話を紹介します。

Bizibl開発チームの前提：柔軟性重視のカンバン運用

まずは、私たちの開発フローの前提についてお話しします。
弊社では機能開発チケットをNotionのボードビューを用いたカンバン方式で管理しています。

開発フローの基本構造

• チケット単位： 基本的に「1チケット＝1機能開発」。
• アサイン： 1つのチケットに対し、チケットリーダー（PM的役割）、デザイナー、エンジニア、テスターがアサインされます。
• ステータス遷移：
  Backlog → 要件定義 → デザイン → 実装 → テスト → デプロイ → 顧客周知 → 完了

「あえて」厳密なスケジュール管理をしない

私たちは月単位で開発チケットを生成し、基本的には当月内でのリリースを目指します。しかし、ガントチャートのような厳密なスケジュール管理は行っていません。理由は大きく2つあります。

1. 優先度変更への対応： スタートアップの宿命として、差し込み案件や緊急度の高い技術的負債の解消など、優先度は頻繁に変更されます。変更のたびにスケジュールを引き直すコスト（管理コスト）が見合わないと判断しました。
2. 品質と健全性の担保： 「スケジュールを守ること」自体が目的化すると、納期優先で品質が低下したり、特定のメンバーに負荷が偏る可能性があります。また、PM専任がおらずエンジニアがマネジメントを兼務しているため、管理工数を最小化したいという意図もありました。

この「ゆるやかな管理」によって、変化への強さとメンバーの精神的な健全性をある程度担保できていました。

課題：柔軟性の裏で生まれた「管理のための管理」

しかし、この運用を続けていくうちに、ボディブローのように効いてくる課題がありました。

1. 「今、誰がボールを持っているか」がわからない

ざっくりとした月次目標しかないため、各ステータス内でチケットが停滞していてもボード上では気づきにくい状態でした。「実装中」になって3日経つけど、順調なのか止まっているのかが外からは見えません。

2. カンバンマスター（私）の負担増

結果として、全体の進行を見る役割（カンバンマスター）である私が、週次のMTGで各チケットリーダーに「これ大丈夫？」「遅れてない？」と全てのチケットについてヒアリングして回る必要がありました。人間が監視しないとワークしない仕組みになっていたのです。

3. 入れ子構造のタスク管理

特に「レビュー」や「デザイン」のフェーズでは、カンバンボードの粒度が粗すぎるため、別途「デザイナー用タスク管理ボード」「QAチーム用ボード」が存在していました。
レビューと一口に言っても、コードレビュー、デザインレビュー、動作レビューがあり、それぞれ誰のボールなのかがメインのカンバンからは読み取れなかったためです。

これらの課題に直面した時、こう思いました。

カンバンボードが正しく設計されているなら、こんなに人間が進捗報告とかタスク管理を頑張らなくてもいいんじゃないだろうか。

そこで、「進捗報告MTGをゼロにする」ことを目標に、Notionカンバンの再構築に着手しました。

解決策：Notionカンバンの再設計

目標はシンプルです。「誰かに聞かなくても、ボードを見れば全てわかる」状態を作ること。
そのために必要な情報は以下の4点ではないかと考えました。

1. チケットの現在のステータス（進捗率）
2. 現在の担当者
3. 現在のステータスがいつまでに完了する予定か
4. オンスケジュールか、遅延しているか

これらを実現するために実装したNotionの構成（プロパティ・オートメーション・ビュー）を紹介します。

1. プロパティの設計

ここでのポイントは、チケットのオーナー（責任者）とは別に、「今、手を動かすべき人（ボール保持者）」を明確にすることです。

プロパティ名	種類	役割
現在の担当者	Person (複数)	「今誰がボールを持っているのか」を表す。ステータスごとに動的に変化する。
ステータス完了予定日	Date	チケット全体の納期ではなく、「現在のステータスが完了する予定日」を入力する。
ステータス進捗	Formula	完了予定日と本日を比較。「あと2日」のように表示し、超過すると🚨 1日超過とアラート表示する。

2. オートメーションによる「ボール」の自動受け渡し

人間が手動で担当者を書き換える手間をなくすため、Notionのオートメーション機能をフル活用しました。

• ステータス変更時の自動アサイン：
  ステータスが「デザイン」に移動したら、あらかじめアサインされているデザイナーを「現在の担当者」に自動セット。「実装」ならエンジニアをセットします。
• 完了予定日のリセット：
  ステータスが変わったら「ステータス完了予定日」をクリアします。新しいフェーズに入ったら改めて期限を設定させるためです。
• 【重要】レビュー完了の自動化：
  レビューステータスでは、コード・デザイン・動作の各レビュアー複数名が「現在の担当者」に自動セットされます。
  ここでの運用ルールは「自分のレビューが終わったら、自分のユーザーを『現在の担当者』から外すこと」。
  そしてオートメーションで「現在の担当者が空になったら、自動で『デプロイ』ステータスへ移動」という設定を組みました。これにより、「誰のレビュー待ちなのか」が明確になり、全員が終われば自動で次へ進むフローが完成しました。

3. ビュー（View）の使い分け

管理者とメンバーで見たい情報は異なるため、２つのビューを用意しました。

A. メインカンバン（管理者・全体俯瞰用）

従来のボードビューですが、カードには「現在の担当者」「ステータス完了予定日」「ステータス進捗（🚨表示含む）」を表示します。
管理者はこれを見るだけで、「誰が何をやっていて、いつ終わるか、遅れていないか」が一目瞭然です。

運用イメージ

B. 個人別タスクリスト（メンバー用）

全チケットを「現在の担当者」でグルーピングしたリストビューです。グループ内は「完了予定日」の昇順でソートされます。
メンバーは毎日このリストを見るだけで、「自分は今、どのチケットのどのフェーズを対応すべきか」が優先度順にわかります。

運用イメージ

運用ルール

ツールだけでは機能しません。以下の最低限の運用ルールを設けました。

1. ステータス遷移と日付設定はチケットリーダーがセットで行う：
   ステータス変更は必ずチケットリーダーが行うようにします。ステータスを変更すると自動的に完了予定日がクリアされるので、次のステータス担当者に対してコミュニケーションをとり、ステータスの完了期限を設定します。
2. 完了予定日のサイレント修正の禁止：
   完了予定日を延ばす場合は、必ず「現在の担当者」と合意を得ること。「遅れそうだから伸ばしとこー」はダメ。
3. レビュー完了時の担当者リリース：
   レビューが終わったら、速やかに「現在の担当者」から自分を外す。

ポイントは、「チケット全体の納期（月末）」ではなく「ステータスごとの直近の納期」を都度決める点です。これにより、従来の応じた柔軟性を損なうことなく、全体の進捗を管理できるようになりました。

結果：MTGが「報告の場」から「改善の場」へ

このカンバンボードを導入した結果、開発チームには大きな変化が生まれました。

• 「管理のための管理」が消滅：
  デザインやQA専用の別ボードが不要になり、全員が同じNotionボードを見るようになりました。
• 週次定例MTGが60分→30分に半減：
  進捗報告が不要になったためです。「Aさん進捗どうですか？」「オンスケです」という不毛な会話がなくなりました。
  ※進捗報告は不要ですが、「遅延中」のチケットについてはチケットリーダーに対して「遅延理由と対策」をヒアリングして最低限のヘルスチェックは実施しています。
• MTGの質の変化：
  短縮された30分のMTGは、進捗確認ではなく「開発フローの改善提案」や「開発方針の目線合わせ」など、より建設的な議論に使えるようになりました。

終わりに

この仕組みは「メンバーがルールを守って入力してくれること」を前提とした性善説で成り立っています。また、個人の細かいタスク管理（TODOレベル）まではNotionでカバーしていないため、そこは個々人の管理能力に委ねられています。そのため、「人が何もしなくても進捗管理ができる」わけではないですが、「優れたカンバンボードは進捗確認MTGを不要とするか」という問いに対しては、現時点では「YES」と言っていいんじゃないかなと考えています。

ツールに使われるのではなく、ツールを使い倒して、人間は人間にしかできない創造的な仕事に集中する。Bizibl開発チームでは、これからもそんな開発環境を作っていきたいと考えています。