自律的な改善サイクルは「個」から始まる 〜 形骸化したチーム振り返りへの処方箋
こんにちは！グロービスで法人向け研修事業における学習管理システム（GLOPLA Solution）のプロダクトオーナーをしている成木です。
みなさんは、振り返りをうまく回せていますか？
プロダクト開発における振り返りは、多くのチームにとって難しく、終わりのないテーマだと思います。どのチームも一度は「形骸化してきたな…」と感じた経験があるのではないでしょうか。
振り返りがうまくいかなくなると、つい「やり方」を変えたくなります。ツールを変えてみたり、時間帯をずらしたり、ファシリテーターを持ち回りにしてみたり。
ただ、実際にはそれだけではあまり状況が変わらないことも多いはずです。
この記事では、チームの振り返りがマンネリ化してしまう構造的な要因を整理した上で、その解決策として、まず「個人の振り返り」に立ち戻ることの重要性と、具体的にどう評価するとよいかについて書いていきます。
そのKPTは「儀式」になっていないか
金曜日の夕方、チーム全員が集まる振り返りの時間。
「今週もKPTやりましょう」と始めてみるものの、どこか空気が重い。出てくるのは「〇〇の実装が終わった」「××のバグが出た」といった事実の共有ばかり。
Try（改善策）を出しても、「今回はタスクが多かったので、次は頑張ります」「早めに相談します」といった、少し抽象的な話で終わってしまうことはないでしょうか。
こうしたやり取りが続き、毎回同じメンバーだけが話し、他のメンバーはうなずくだけ。もし思い当たる節があるなら、それは振り返りが「形骸化した儀式」になっているサインかもしれません。
正直に言うと、私自身もこうした振り返りを何度も経験してきました。「これ、やる意味あるんだっけ？」という空気が流れるあの時間は、リーダーとしてもメンバーとしても、あまり居心地の良いものではありません。
なぜ、チームの振り返りは形骸化するのか
多くのチームがぶつかる「振り返りの形骸化」には、いくつか共通する構造的な理由があります。ここでは大きく3つに分けて整理してみます。
1. 「誰かが言ってくれるだろう」という当事者意識の低下
全員で集まる場では、無意識のうちに依存が生まれます。「リーダーがまとめてくれるだろう」「あの人がいつも課題を出してくれるから大丈夫」といった空気です。
その結果、メンバーは「改善の当事者」ではなく「場に参加しているだけの人」になりがちで、出てくる意見もどうしても表層的になります。
2. 課題を考えるための準備時間が足りていない
スプリントの終わりに集まって、いきなり「課題を出してください」と言われても、思い浮かぶのは直近の出来事や印象に残っているトピックくらいです。
自分の行動や判断を整理する時間がないまま話すため、課題の粒度は粗くなり、結果として「抽象的で実行しづらい改善案」になりがちです。
3. Try（改善策）に対するオーナーシップの弱さ
自分の中で腹落ちしていない課題に対して、場の流れで決まったTryに本気で責任を持てるでしょうか。
「みんなで決めたこと」は、裏を返せば「誰のものでもない改善」になりやすく、実行されないTryが積み上がっていきます。
これらに共通しているのは、チームという構造の中で「個人の主体性が薄れている」という点です。この状態を抜け出すために必要なのが、「自律」という考え方だと思っています。
「自律」とは、自分で問いを立てられる状態のこと
自律的なチームとは、単に自由に動いているチームのことではありません。
メンバー一人ひとりが、自分の行動や成果を客観的に振り返り、「次に何を改善すべきか」を自分の言葉で語れる状態。これが自律だと考えています。
私がこれまでの経験を振り返ってみて、「今日は良い振り返りだったな」と感じた場面を思い出すと、ツールや進め方が理由だったことはほとんどありません。
印象に残っているのは、誰かが自分自身の強い課題感や、悔しさ・迷いを正直に言葉にした瞬間でした。
個人の中でしっかり考え抜かれた課題意識は、チーム全体の思考を一段深いところに引き上げます。
つまり、質の高いチームの振り返りは、 質の高い「個人の振り返り」 があってこそ成り立つ、ということです。
個人パフォーマンスを分解する4つの視点
では、質の高い「個人の振り返り」とは何でしょうか。
単なる「やったことの列挙」ではなく、自分の行動をどう解釈し、どう評価するかが重要です。そのための一つの整理として、私は個人のパフォーマンスを次のように捉えています。
パフォーマンス評価の考え方
成果を生み出す3つの要素と、それを阻害する1つの要素。この4つの観点に分解して、「何がどうだったか」「なぜそうなったか」を考えてみてください。
1. 能力（Skill & Knowledge）
アウトプットを出すためのスキルや知識は足りていたでしょうか？
• 技術的な実装力不足で詰まったのか、ドメイン知識不足で手戻りが発生したのか。
• あるいは、新しい技術スタックへの適応がスムーズで、予想以上の速度が出せたのか。
2. 時間（Capacity & Efficiency）
タスクをこなすためのリソース配分は適切だったでしょうか？
• 物理的な時間は確保できていたか（割り込みタスクや会議過多ではなかったか）。
• 確保した時間を効果的に使えていたか（集中力の維持や、ツールの活用など）。
3. 方向性（Alignment & Priority）
向かっている先は正しかったでしょうか？
• チームのゴールやスプリントの目的と、自分のタスクの優先順位は合致していたか。
• 重要度の低いタスク（「やりたいこと」や「簡単なこと」）から着手し、本質的な価値提供が後回しにならなかったか。
• POやステークホルダーとの期待値調整（ゴールの認識）にズレはなかったか。
4. 調整コスト（Coordination Cost）
成果を出すうえで、無駄な摩擦や待ちが発生していなかったでしょうか？
• 必要な情報は、必要なタイミングで、必要な相手にスムーズに共有されていたか。
• 誰が何を担うのかが明確で、判断や作業が滞る場面はなかったか。
• 作業の依存関係による「待ち」やブロックが発生し、手を止める時間はなかったか。
• 不明確な伝達や確認不足によって、他のメンバーの時間や思考を奪っていなかったか。
これら4つの観点すべてにおいて言語化することで、「なんとなく忙しかったけど終わらなかった」という曖昧な結果が、「能力は足りていたが、方向性の認識ズレによって手戻りが発生し、結果として時間を浪費した」という具体的なイシューへと分解されます。
個からチームへ、質の高いインプットが議論を変える
この4つの視点で整理すると、KPTのProblemやTryの質が大きく変わります。
これまでの振り返り
- Problem: 実装が終わらなかった。
- Try: 次はもっと集中して頑張る。
パフォーマンス評価の考え方を踏まえた振り返り
- Problem: 実装が終わらなかった。技術的な能力は足りていたが、仕様確認の調整コストで2日分の時間をロスしてしまった。
- Try: 仕様不明点はSlackではなく、毎朝のデイリースクラム（同期コミュニケーション）で解決し、待ち時間をゼロにする。
それは、精神論ではなく、「どこに構造的な問題があったのか」が見えるようになるからです。
個人としてここまで分解した状態でチームの振り返りに参加すると、議論の景色は確実に変わります。
• 議論の深さ：「進捗が悪かった」という報告ではなく、「方向性の認識合わせが不十分（方向性 × 時間 の課題）」という構造的な問題提起が可能になります。
• 多様な視点：エンジニア、デザイナー、QA、それぞれの専門領域における「能力・時間・方向性」の葛藤が共有されることで、チーム全体のボトルネックが可視化されます。
• 実行力のあるTry：自らが深く分析した末に出た改善案には、強いオーナーシップが宿ります。「次は気をつけよう」ではなく、「デイリースクラムで必ず優先順位（方向性）を確認するフローを追加しよう」といった具体的なアクションに繋がります。
まずは一人からでも始めてみよう
「チームワーク」という言葉は、ときに個人が考えなくていい理由になってしまうことがあります。
ですが、本来のチームワークは、自律した個人同士が考えを持ち寄り、ぶつけ合い、補い合うことで生まれるものだと思っています。
チームの振り返りがうまくいっていないと感じたら、まずは自分自身の振り返りの質を見直してみてください。
15分で構いません。「能力・時間・方向性・調整コスト」の観点で、自分の一週間を振り返ってみる。その積み重ねが、チーム全体の振り返りを変えるきっかけになります。
自律的な改善は、いつも「個」から始まります。
次回のレトロスペクティブの前、少しだけ自分と向き合う時間を取ってみてください。その一人分の本気が、チームの空気を変える起点になるはずです。
最後に: グロービスでは一緒に働く仲間を募集しています！
日本発、世界をリードするEdTechカンパニーを目指すGLOBISでは、一緒に働けるエンジニアを探しています！ まずは、カジュアル面談を通して、あなたに合う組織かどうか確かめてみませんか？
Discussion