選択と集中を促す振り返りフレームワーク「bmf」

bmf-san 開発プロセス
#振り返り#KPT

振り返りと言えば KPT（Keep / Problem / Try）が定番であるが、自分なりのオリジナリティ溢れるフレームワークを考えたくなったのでそのアイデアを記す。

bmfフレームワーク

bmf = Build / Miss / Focus の頭文字で構成される振り返りのフレームワークである。KPT に似た 3 枠構成を保ちながらも、「成果の可視化」「失敗の顕在化」「次の集中対象の明確化」という順番で思考を誘導する設計としている。

項目 説明 意図
B: Build（積み上げたこと） 期間内に達成・前進・改善できたことを列挙する欄である。 成果を言語化し、自己効力感と再現可能なプラクティスを抽出する。
M: Miss（うまくいかなかったこと） 想定通りに進まなかった事象、阻害要因、見落とし、未達成事項を挙げる欄である。 問題認識を共有し、再発防止・改善機会を確保する。
F: Focus（次に集中すること） 次サイクルで特に注力すべきテーマ・行動を絞り込む欄である。 Try を乱発せず、選択と集中によって実行確率を上げる。

なぜ KPT ではなく bmf なのか

KPT の最大の利点は簡潔さと普及度である。一方で運用してみると以下の課題が生じやすい。

  1. Try の過多 — 「やったほうがよいこと」が大量発生し、優先順位が埋没する。
  2. Keep と Problem の温度差 — Keep が形骸化し、Problem の羅列に偏るケースがある。
  3. 継続的トラッキングの負荷 — Tryの振り返りが十分に行われなくなる。

bmf はこの状況に対する次の設計原則にもとづく改良案である。

  • 原則A: 成果の言語化を先頭に置く。 成功要因を抽出し再利用する文化を醸成する。
  • 原則B: 課題を無検閲で出すが、列挙で終わらせない。 後段で集中対象を選ぶ前提で安心して曝露できる場を作る。
  • 原則C: Try を "Focus" に言い換え、量より質に振る。 次サイクルで確実に手を付ける項目を厳選する。

この 3 原則により、bmf は「振り返りから実行」までの距離を短縮することを狙っているのである。

実施手順

KPTと同様の手順で実施する。

  1. 前回の振り返り結果を確認する。
  2. 今回の振り返りを行う。
  3. 今回の振り返り結果を確認する。

記入時間に時間を設けたり、書き出したものをグルーピングするなどやり方は自由にアレンジして良い。

bmf のTips

Build（積み上げたこと）

  • 完了タスク数や速度よりも「再現したい行動」「仕組み化できるナレッジ」を書くと価値が高い。
  • 個人達成だけでなく、チーム連携で生まれた成果も記録する。

Miss（うまくいかなかったこと）

  • 事象（What）と影響（So What）を分けて書くと分析が容易になる。
  • 感情ログ（イライラした、詰まった）もヒントになるため捨てずに短く残す。

Focus（次に集中すること）

  • 「今期はこれをやらない」不採用リストを併記すると意思決定の透明性が高まる。
  • 行動単位と成果単位をセットで書く（例: "レビュー SLA 24h 化" → "PR 停滞時間中央値 30%削減"）。

導入時の落とし穴と対策

落とし穴 症状 対策
Build が少なすぎる ネガティブモードで開始し士気が下がる 直前に期間中の成果ログを読み上げるファシリ施策を入れる。
Miss が指摘合戦化 人ではなく現象にフォーカスできず心理的安全性が損なわれる ルール: 個人名ではなく事象・プロセスで記述する。
Focus が多すぎる 実行されず形骸化 上限を設けたり、優先度を決める。
フォロー忘れ 前回 Focus の結果確認が抜ける 毎回冒頭 5 分で前回分のステータスレビューを必須化する。

テンプレート

以下はテキストベースで実施する場合のテンプレート例である。

まとめ

目的に応じて最適なフレームワークを選択するのが良いが、一つのフレームワークを利用し続けると、慣れからそのフレームワークの制約に縛られたり、変化を見失ったりする。

新しい刺激を得るためにbmfを試してみてはどうだろうか。