プロジェクト振り返りが嫌いな理由

何度かこのテーマについて記事を書いていますが、前回（およそ3年前）書いたモノを見直したところあまりに解像度が低すぎて恥ずかしい気持ちになったのでリライトすることにしました。 2024年は大きなプロジェクトに取り組むことになりそうなので、改めて現時点での考えを整理しておくものです。

本題に入る前に

この文章を書いた人間は、以下のような環境で働いています。

• 自社サービスのアプリケーション開発を行っている
• プロジェクト形式の（または定期的に振り返りの時間を設けるアジャイル）開発プロセスを採用している
• 振り返り手法としてKPT法を採用している（ことが多い）

一部当てはまらなくても準用できる考え方はあるかもしれませんが、ご利用はご自身の責任でお願いします。

こんなKPTは嫌だ

ソフトウェア開発のプロジェクトはなかなか理解が難しい生き物です。 それにも関わらず、少なくない開発現場においてあるプロジェクトで挙げられたKPTをそのまま次のプロジェクトで活かそうとするような動きが見られます。 型にはめようとしたプロジェクトマネジメントの有効性がおおよそネガティブに捉えられている現代において、あるプロジェクトにおけるKPTを別のプロジェクトにも適用しようとすることはナンセンスです。

まずはじめに、イマイチなKPTの例をいくつか挙げてみることにします。

再現できたときの価値が不明瞭なK

個々のプロジェクトはそれぞれ固有の特性やコンテキスト（成果物やゴール・ステークホルダー・ビジネス環境・投下可能なリソースetc...）を備えています。 したがって、あるプロジェクトにおいて有効だった取り組みが別のプロジェクトでも同様に有効であるという保証はどこにもありません。

という当たり前のことを理解せずに記述されるKは、だいたいチームにとっての呪いのように働きます。 Keepの妥当性=次のプロジェクトでも再現させるべきかについては、プロジェクトの特性を踏まえて検討しなければなりません。

大抵の開発チームには過去のプロジェクトのKeep項目をいちいち吟味するような時間的余裕は与えられませんし、そんな事にまで配慮してKeepを書こうという人もいません。

継続することが難しいK

根本的に継続するために必要なコスト（難易度）が高いKeep項目はあまり意味がありません。 そして、コストが高いか低いかはプロジェクトの特性に依存して決定するので、次のプロジェクトが始まってみないとわかりません。

とはいえ、幸いなことにKeep項目の継続可能性が問題になることはあまりありません。 論理的に考えれば、KPT法による振り返りを繰り返せば繰り返すほどKeep項目が増え、プロジェクトの制約がどんどん増えてつらくなっていきそうですが、現実はそうなっていません。 人間は興味・関心のないものを都合よく忘れるようにできているからです。 本来であれば無益なKeep項目を抹消するような儀式がセットで用意されているべきですが、有能な人類にはそのようなものは必要ありませんでした。

原因を人間に帰着させているP

いまさら言うまでもありませんが、人間はミスをします。 ミスの原因を環境やプロセスの問題として捉えて改善を試みるのであれば意味があるかもしれませんが、人間のミスをProblemとして挙げていたらキリがありません。 ということをみんな信じているはずなのに、Problem項目に人間のミスを挙げる事案が後を絶ちません。

真面目な人ほど「あのときの自分のアクションが良くなかった」みたいな話をして反省の意を表明しがちですが、その情報は他のプロジェクトメンバーにとってはさほど役に立ちません。 真剣に改善を促すのであれば「私があのとき<アクション>をしてしまったのはxxxのプロセスに問題があるから改善すべきだ」くらい強気なことを言ってほしいところですが、 奥ゆかしさを好む人間のコミュニティにおいてなんらかのやらかしをキメた人物がうっかりそんな発言をしようものなら、99％くらいの確率で白い目を向けられてしまいます。 このような環境要因が真に有益なProblem項目を書くことを妨げていますが、個人の努力でこれをなんとかすることは極めて困難と言わざるを得ません。

再現性がないP

Keep項目と同様ですが、Problem項目でも再現性の低さは問題となります。 プロジェクト固有の事情に起因するProblemや、偶発的な事情に起因するProblemは次のプロジェクトでは起こらない可能性が高いので、発生した事象そのものに言及することの価値は低いです。

発生した問題を抽象化・一般化して議論することが重要ですが、それができるなら我々が書いたコードに現れる抽象具象の設計はもっとエレガントになって然るべきであり、 書いたコードがそうなっていないという現実を踏まえるとやはりこれも人類には難易度が高すぎるということになります。

Kの維持やPの対策を目的とするT

これまでに書いてきたとおり、凡庸な人類が有益なKeep項目やProblem項目を記述することは困難なので、 「次のプロジェクトでもKeepできるように頑張ろう」とか「次のプロジェクトではProblemが起こらないようにしよう」とか考えてTryを設定するのも同様に避けたほうがいいでしょう。

むやみに高尚なT

振り返り会で出たTryを他人に強要するメンバーに共有することで、チーム全体の改善を試みようとするのは非常に危険です。 しばしば付箋のようなものにKPTを書く方式で情報共有が行われますが、1枚の付箋はTryを実践し、有益なものにするための数多くの前提条件を記載するには狭すぎます。

コンテキストの共有がないまま付箋に書かれたことだけを信じてTryしてしまうと、良い結果に繋がらないどころかプロジェクトに悪影響を与えることになるでしょう。 Try項目としてあげたものを元に他人に行動を要求すると大変なリスクを伴います。あくまで個人の責任の範囲でTryしましょう。

よくある振り返り会に意義を見出す

聡明な読者のみなさまはすでにお気づきかと思いますが、ここまでに書いてきた内容をうまく避けてKPTを書くのは非常に難しいです。 自分一人なら頑張ってなんとかなるとしても、振り返り会に参加するメンバー全員に理解を求めるのは酷でしょう。

つまり、根源的にKPT法による有意義な振り返りを実施することは人類には難易度が高すぎるのです。 「そんなこと書いたってどうにもならないじゃん」といいたくなるような数々のKPTと向き合いながら、なんとか意義を見出すしかありません。

本節では、いつものよくある振り返りをどうやって自分にとって実のあるものとするかを考えていきます。

変わらないものにフォーカスする

プロジェクトを構成する要素の中では、人間の思考が一番変わりにくいです。 これを踏まえて、振り返りに参加する際の基本的な姿勢としてはKPTの内容よりもそれらが吐き出された背景に思いを馳せると良いでしょう。

振り返り会では、他のメンバーが書いたKeep項目やProblem項目を読んでその人がプロジェクト中にどんなことを感じていたかを理解することに努めます。 Keep項目はそのプロジェクトに関わったメンバーが「再現したい」「よかった」と感じている話なので、 これはまさにプロジェクト成功のイメージそのものです。 Problem項目はその逆で、失敗イメージが具現化したものと言えます。

振り返り会を行う目的は次のプロジェクトを成功に導くことです。 そのためには、共にプロジェクトに取り組むメンバーへの理解を深めること、この文脈においてはその人が下した決断がどういう思考プロセスに基づくものだったのかを把握することが重要です。 「この人はこういう状態がハッピーなんだな」とか「こういう状態にツラみを感じているんだな」という情報をもとに自分が次に行動する際の判断基準を微調整しながら、 メンバーが幸せな状態を維持するための情報を得る場と考えると振り返り会が有意義なものになる気がします。

当たり前のことが当たり前にできていたらほめる

おすすめのKeep項目の書き方は、当たり前のことが当たり前にできているという事実を明示することです。

とりわけ高い目標を設定することを美徳としたり、謙虚が好まれる環境で暮らしていたりするとついつい忘れがちですが、当たり前のことを当たり前にこなせる人材はそれだけで希少なのです。 自分から「当たり前のことができました」と胸を張って主張できるメンタルつよつよマンはあまりいないので、敢えてやや大げさに周りから褒めてあげることが大事だと思います。

たぶん有意義な振り返りのためのKPTの書き方

以上を踏まえて、KPTを書く際のポイントをまとめると次の2つに整理できます。

すぐ書く

プロジェクトを進めている最中に感じたことをリアルタイムに、かつ素直に記録した飾りっ気のない情報が最も貴重です。 このように記録した情報をKeep項目とかProblem項目として振り返り会に持ち込みましょう。 プロジェクトが終わってから思い出そうとしても、イベントの印象はそのプロジェクトの成否や書くときのメンタルに引き摺られるのであまりよくないです。

自分本位に書く

自分がどう思っていたかを他のメンバーに理解してもらうことが目的なので、チームの役にたてようとか余計なことを考えてKeepやProblemを書く必要はまったくありません。 客観的な正しさを担保しようとする努力も必要ありません。誰が見ても画一的な解釈ができるようにしておく、といった配慮も必要ありません。 あくまで自分が思ったことを自分のために書いておけばOKです。どうせ何を書いたってあなたが思っていたことを正確に理解してくれる人なんていません。 そうすれば、あとは読んだ人が良いように解釈してくれます。

同様にTryについても意味があることが誰にでも容易にわかる改善を挙げる必要はありません。 他のメンバーが書いた内容に思いを馳せた結果、自分がやろうと思ったことを勝手に宣言するだけでよいのです。

KeepをKeepしようとしない

さて、振り返り会を終えて次のプロジェクトのキックオフがやってきました。

まずは過去の自分の発言から自由になりましょう。 律儀に過去のKeep項目をKeepしようとする必要はありませんし、余裕がないときにTry項目にTryする必要もありません。

仮に事がうまく運んで途中までKeepやTryに取り組んでいたとしても、うまくいかないことが明らかになったらその時点でサッとやめてしまいましょう。 柔軟性を損なうことこそがプロジェクトを失敗に導く最大の要因となります。

有言実行はすばらしいことですが、無能な働き者となってしまっては本末転倒です。 言ったことを変えるとか、やりはじめたことをやめるとかは一般に人間や組織が苦手とするところなので、日頃からそういうことがやりやすい空気を醸成しておくことが大事です。

「特に変わったことはしていないけれども、終わってみたら前回Keepに書いたことが今回も達成できてた」くらいを目指すのが幸せなのだろうと思います。