どもども、
Shinshin です。
突然ですが、みなさん、仕事でプロジェクトの振り返りはちゃんとしていますか？
Fusicではプロジェクト終了後には可能な限り振り返りをやるようにしています。Slackでも以下のように促されます:
当然僕も例外ではなく、関与したプロジェクトに関してはよく振り返りを実施しています。その多くで僕が用いるのが、みなさんご存知KPTと呼ばれる手法です。
皆さんの間でも馴染みのあるやつだと思います。以下のような感じで、シンプルにKEEP（継続したいこと）、PROBLEM（問題・課題）、TRY（改善したいこと）を洗い出すといった手法です。
ただ、僕個人これがイケてる手法だとは思ったことがなく、いっつも上部っツラな振り返りにしかならないことに個人的に課題感を抱いていました。
ということで今回は、先日終了したプロジェクトの振り返り会のフレームワークとして、KPTならぬ僕考案の改造版KPT - FFT - を使って振り返り会をした話について書きます。
Table of Contents1. KPTの課題点1.1. コントロールできるものとできないものを区別する 1.2. 振り返りに意思表明を入れない人間はモチベーションでは動かない。習慣でのみ動く。1.3. 振り返りに必要なのは今スグ始められるアクションプラン単なる意志表明を、アクションまで要素分解する 2. 僕がデザインした新KPTフレームワーク、その名もFFT！ 3. フレームワークの進め方、実例とともに3.1. Factをとりあえず並べる3.2. FeedBack（Whyで要素分解）FeedBackで実際に話し合ってみた結果 3.3. Try（直ぐにでも実行できるアクション策定）4. フレームワークの実用性 5. まとめ
1. KPTの課題点
まず、そもそもなぜ既存のKPTがイケてないのかについてお話しします。
（KPTはちゃんとやれば素晴らしいフレームワークになるという前提のもと！）
KPTは、実施者・非実施者両方のリテラシーの高さが問われます。両者がそれぞれ”問題の本質”とそれを解決するための”具体的な施策”を考える力が必要で、これらを高いレベルで備えていると感じる人は僕個人も殆ど知りません。
そんな使う人/使い方依存なKPTですが、主に以下の2つの問題に陥ります:
1. 結果主義: 最終結果（KPI/KGI）だけで物事を語って、実行したアクションの良し悪しの判断を怠る
2. 不透明な着地点: 上記のアクションの分析が中途半端なため、次回以降実行可能なアクションの策定まで辿り着かない/策定できても関連性が薄かったりする
例えばですが、以下のKPTを見てください:
これを見てもらうと分かるように、
Keep・Problem:
- 個人（またはチーム）が実行したアクションではなく最終的な結果しか振り返っていない
- 偶発的な要素も成果（Keep）・課題（Problem）に含まれており、運ゲー的な感じにも映る
Try:
- 意思表示だけしているだけで、具体的なアクションが定まっていない
- やって効果があるのか分からない（因果関係が不透明な）アクションプランになっている
- "結果"でしかないようなものまで、Tryの中に組み込まれている
といった感じで、実質単なる最終結果の記述と実行性に欠いた意思表示しかしていません。
ここで必要なのは、Keep, Problemがどういった因果関係で発生していて、それをTryするためには何を実行しなきゃいけないかの分析です。
そこで僕は、以下の2つの要素をちゃんと組み込んだフレームワークが作れないかと考えました:
1.1. コントロールできるものとできないものを区別する
僕はStoicismの考えが大好きです。Stoicismの中で最も有名なコンセプトで、"自分がコントロールできないものには執着しない"という考え方があります。これがすごく好きです。
僕がプロジェクトで沼る時とは、往々にしてコントロールできないものに執着して、目の前のコントロールできるもののコントロールを失っている時です。なので、自戒の念も込めて、よく自分に言い聞かせています。
これは上述のKPTにも同じことが言えます。
例えば、Problemの「受注率が前月比80%」「新卒の受注率が異常に低い」とかは、極論コントロールできないものです。
いくら徹夜で頑張っても到達できない時はできないです。気にするだけ無駄です。
逆にここで意識したいのは、その中でもコントロールできる部分があるところです。
例えば、「受注率が前月比80%」「新卒の受注率が異常に低い」とかは色んな物に依存するためコントロールできないですが、それらを達成するために自らが実行する"アクション"の内容/質はいくらでもコントロールしようがあります。
Keepに書かれていることも同じことが言えます。
「アポが前月比で150%上昇」という結果をKeepするのは自分のコントロールの外に存在します。明日世界恐慌が起こったら、一瞬でKeepもControlもできなくなります。
ただ、仮に世界恐慌下でも、150%上昇するために行ってきたアクションをKeepすること自体は自分の中でコントロールできます。
このように、振り返りをするときに、"自分でコントロールできるものか否かを識別すること"は、非常に重要な意味合いを持っており、最終的には振り返りのクオリティに直結します。
なので、振り返りではコントロールできるものだけを書くようにしたいと思いました。
1.2. 振り返りに意思表明を入れない
KPTのTry Partでよくあるのが、意思表明だけしているだけで、Action Planの策定に全く繋がっていないパターンです。
よくある表現として、「次から〇〇をやる」みたいな表現が散見されます。
これは、ただただそのActionの意思表示をしているだけで、僕個人は後述の理由で嫌いです。
人間はモチベーションでは動かない。習慣でのみ動く。
僕の人間観として、”人間は感情（モチベーション）の生き物ではない、習慣の生き物である”という価値観を持っています。
賛否両論あると思いますが、類似の意見を持っている研究者は沢山います。一番有名なところだと、James ClearのAtomic Habitsが挙がると思います:
著書の中で、以下の表現をしています:
何か特定の事象やそこから得る感情（モチベーション）が次の結果を生むわけではなく、それを踏まえて”起こしたアクションの積み重ね”でしか変わらないのが人間です。
なので、”行動が伴わない、意志だけに頼るような振り返り”は基本全て無駄だと思っています。
1.3. 振り返りに必要なのは今スグ始められるアクションプラン
前述の理由で、振り返りでは、”最終的には今スグ始められるアクション”まで考え抜くことが理想だと思っています。
それを踏まると、「次から〇〇をやる」「〇〇を考える」などの表現は意志表明をしているだけなので完全なアンチパターンです。その場限りのモチベーションに依存する形でアクションプランを組むべきではないです。
じゃ、どうすべきなのか。「メールを送る」という例を用いて解説します。
単なる意志表明を、アクションまで要素分解する
「メールを送る」という作業自体も分解すればどれだけの検討ステップが挟まるのか容易に想像がつきます:
1. いつ・どのタイミングで誰にメールを送るべきなのかを決める
2. メールの内容を決める
3. そのメールに必要な情報を揃える
4. そのメールの後の展開を読んで、動ける準備をする
5. メールの送り忘れを予防する方法を決める（タスクリストに追加とか）
6. 送る前に内容を確認する
とザッと並べるだけでも、以上のようにbreakdownすることができます。
Willの要素しか持っていなかった「メールを送る」という作業も、丁寧に要素分解することにより、When・Where・Who・What・How（+ 必要に応じてWhy）の要素が生まれます。
WhenやWhereがトリガーとなり、WhatやHowが決まってくる、といった感じでそれぞれの作業が自動的かつ連鎖的に動き出すようなレベルまで分解することで、アクションに繋げやすくなります。
なぜここまでやる必要があるかというと、人は抽象的なタスクを避け、簡単なタスクをやりがちです。
これを英語では、”The Principle of Least Effort”といいます。人は無意識にEffort（労力を伴わない）を選ぶ傾向があるという認知バイアスです。
メールひとつでも、「メールを送る」という抽象的でボリューム量の分からない表現から、上記のようにbreakdownをすることによって、作業1個1個のボリュームが小さくなる + 作業イメージがしやすくなり、よりActionに繋がりやすくなります。
KPTで振り返りをする時間でも同じことがいえます。Tryに書く内容を出来る限り細かな粒度（まさにAtomicな粒度）まで分解することで、振り返り後に速攻でActionに繋げれるような状態を作ることに繋がります。
2. 僕がデザインした新KPTフレームワーク、その名もFFT！
上記の2点を既存のKPTに組み込んでみたものが以下となります:
自分がやったこと・やれなかったことを、
Fact（事実）→ FeedBack（原因特定）→ Try（アクションの定義）
といったフェーズで分析できる形にしました。
「できなかったこと」= Problem、「できたこと」= Keepとして記載。それぞれ”Why”で要素分解。
既存のKPTのコンセプトを維持しつつ、個人のActionレベルでの考察 + Whyでしっかり要素分解できる形にしています。
また、最終的なTryフェースでは、自分の強み+αで改善できる点をActionベースで意識することができるデザインが施されているところです。
3. フレームワークの進め方、実例とともに
試しにプロジェクトメンバーとやってみました。以下、進め方を解説しています。
3.1. Factをとりあえず並べる
とりあえずやれたこと/やれなかったことを、FACTベースで書き出してみました。抽象的なことでも、些細なことでもなんでも、思いつく限りで出してみました。
その後、10分くらい時間をとって、それぞれでやれたこと/やれなかったことを解説。
3.2. FeedBack（Whyで要素分解）
実はここが結構おもしろかったです。
まず、以下の2つのStepで、FACTに貼られていた付箋をいくつか選別しました:
1. 自分の出来なかったことの中で、"仮にできていたら一番インパクトが大きかったもの"をピックアップ
2. 他人の出来ていたことの中で、"何故その人がそれができるのか聞きたい/自分の後学のためにその人に改めて要素分解してほしい"ものをピックアップ
従って、「Why できなかった」には、自分ができなかったことで、インパクトが大きい + メンバーから改善案を出して欲しいもの、
「Why できた」には、メンバーがやっていたことで、自分ができるようになるためにコツや考え方を教えて欲しい/そのメンバーがどういった思考なのか知りたいことが並びます:
前者は、”インパクトが大きい”がキーワードです。これは、必ずしも自分のやりたことや工数やコストがかかるものとはイコールではありません。
“お客さんのミッション実現に一番インパクトがあったアクション”の一軸でピックします。
後者であえて自分以外のメンバーに自分のnoteをピックさせているのにも重要な意味合いがあります:
プロジェクトメンバーそれぞれ特別な能力がある中で、その能力が何によって構成されているのかを自分で言語化することは、自分の強みをatomicレベルで把握するいい機会になり、ひいては自己肯定感の向上につながります。
FeedBackで実際に話し合ってみた結果
「Why できた」→ それぞれ特色的な強みがあった
参加メンバー間で、それぞれに対して思う「なんでこれできるの！？」をピックアップ。それぞれで特色のある強みがあることが分かりました:
- メンバーA: お客さんを意識した資料作成能力がここ2ヶ月で飛躍的に伸びた
- メンバーB: セキュリティに関する幅広い知見・経験 + メンバー・お客さんへの安心感の提供
- Shinshin: 俯瞰的に空間を読む能力、Customer Obsessionで動ける能力
これらの「Why できた」を書いた本人で言語化も試みました。
もちろん、"経験"や"センス"といった言葉でしか片付けられない事象だったりはあったりしますが、できるだけそこもbreakdownしつつ（その経験やセンスはそもそもどこからきたのか）
例えば僕の
俯瞰的に空間を読む能力、Customer Obsessionで動ける能力で言うと、みたいな感じで回答しました。ここは、別に他人に理解されなくてもOKだと思っています。自分で自分の強みがどこから来ているのか分かるだけでも十分な成果です。
「Why できなかった」→ それぞれ共通の課題感を感じていた
これがまたまた興味深く、「Whyできなかった」に関しては、それぞれ記載内容に違いはありつつ、最終的な着地点は同じだったことです。
すなわち、数ヶ月間の支援を通して、3人とも同じ課題感を抱えながらプロジェクトを進めていたということです。
このアクティビティを通して、改めて課題に感じていることがあれば怖がらずにちゃんと言うべきだと改めて実感しました（一種の認知バイアスだぁ）
潜在的な課題を持ち出すのはいつだって勇気がいるし、特にプロジェクトの途中などで大きな軌道修正が伴うような課題に関しては、より提起のハードルが高くなるものですが、もしかしたら他のメンバーも同じ課題感を持っているかもしれません（お客さんも然り）。
しっかり課題だと感じた部分に関しては言う！改めて大事なことを学んだなぁ〜という気分です。
3.3. Try（直ぐにでも実行できるアクション策定）
実は時間切れでTry Partまで進められませんでした（笑）
まあ本来であれば、
1)
FeedBackフェーズで上がったのものをアクションレベルまで要素分解
2)
「Why できた」をbreakdownした要素が、Tryフェーズの「自分の強み」 （すなわち今後も継続すること）
3)
「Whyできなかった」の中で上がったアクションが、次回以降「自分の強み」プラスαで実行すべきアクション
といった形までまとめる流れでした（以下の図で言うと、赤枠のところ）:
今回はそこまでは時間が足らずできませんでした。
ですが、自分ができたこと/できなかったことをメンバーと打ち明ける経験そのものは、確実に今後の自分の働き方の中で意識する部分になると思いますし、メンバーそれぞれで今後の具体的なアクションにも繋げていく"きっかけ"くらいにはなったかと思うので、試験運用としては十分な成果が出た気がします。
4. フレームワークの実用性
個人的には現状考えうるベストなフレームワークが作れた気がします。大満足です！！！
ただ、結構脳みそ使います。Whyを深掘れば深掘るほど、脳のCPUが枯渇していきます。
また、時間も沢山使います。
時間の見積もり大甘で3人60分で時間を確保しましたが、正直120分くらいでちゃんと考えたいくらい内容の濃い話になった気がします。
人数が増えるとよりその傾向は強くなるので、大規模な振り返りの時はもしかしたらメンバーを複数の小さなチームに振り分けてやったりしなきゃいけない気がします。
5. まとめ
以上、素晴らしすぎるフレームワークデザインをしてしまって自分でもちょっとビビってるShinshinでした。
「これ、使ってみたい！教えて！ファシって！」とかあれば、是非是非お気軽に！
Want to know more about what we do? Check out the articles below!
Fusic News
Fusicってなんしようと？
Fusic Tech Blog
Fusicオープン社内報へ戻る
