こんにちは、内藤です。

皆さん、プロジェクトが終わったら、その後の振り返りはどのように行っているでしょうか。 シナップでは、プロジェクト毎にKPTというフレームワークを使った振り返りを行い、プロジェクトで得た知見と反省点をチーム内で共有し、次のプロジェクトで活かしていこう！という取り組みを積極的に行っています。

また、KPTでプロジェクトを振り返るだけでなく次のプロジェクトに活かすためのIRKというのも行っています。KPTは聞いたことがあるかと思いますが、IRKは初めての方も多いのではないでしょうか。

IRKはKPTの拡張として、2005年に平鍋健児さんがオルタナティブブログで紹介していたものです。KPTとIRKを合わせてKPTIRK（ケプターク）と呼びます。

今回は、このKPTIRKとシナップでどのように活用しているのかをご紹介したいと思います。

KPTとは振り返りをするためのフレームワーク

KPTは、「Keep（よかったこと、今後も続けること）」、「Problem（困ったこと、問題点）」、「Try（今後の活動で試したいこと）」の頭文字をとったもので、チームまたは個人で振り返りをするためのフレームワークです。シナップでは主にサイトや運用案件の新企画リリース後、また運用サポートしている案件も、振り返り、改善をするための取り組みとして定期的に行っています。 検索するとたくさんの情報が出てくるので、ここではこのくらいの簡単な紹介に留めておきますね。

KPTの拡張IRKは、KPTを抽象化したもの

IRKは、「Issue」、「Risk」、「Knowledge」の頭文字をとったもので、KPTの抽象化したものです。詳細の説明は、平鍋さんの説明を引用したいと思います。

• Issue：Problem の本質化。問題を見つめ、本質的「課題」としたもの。「５回のなぜ」などで到達できるもの。「アンチパターン」や「AntiPractices」では、root causeと呼ばれている。
• Risk：リスクに感じること。これは、問題予備軍、future problem と考えられる。これを「口にしておく」ことは重要だろう。
• Knowledge：Keep の結晶化。Keepの中には、ナレッジとして抽象化できるものがある。ナレッジの表現形式としては、「名前付け」がまず必要。そして、それを表現する形式としては、Pattern、新しいPractice、AntiPractice、Tips、FAQ、注意書きとして、壁に貼るなどが考えられる。

KPTに対してIRKだと何と何がセットなのか混乱しますが、KeepはKnowledgeへ、ProblemはIssueへ、TryはRisk、と頑張っておぼえてください。

シナップでのKPTIRKの進め方

シナップでは、KPTは以下のように進めることが多いです。

1. まずは個々人で、Keep、Problem、Try を考える

各チームメンバーに個々人の思う、プロジェクトに対するKeep（良かったこと）、Problem（反省、課題）、Try（次回試すこと）を各項目で2〜3つほど挙げてもらいます。この時、プロジェクトに対する進行や技術的な課題だけでなく、シナップの行動指針に対して個々人がどうだったのか、という視点でも反省をします。 例えば、大きな問題がなくリリースができてプロジェクトを終えられたとしても、行動指針の「スピード重視」という点で考えると、追手の対応になってしまったな、など思い浮かぶことがあります。

2. 集めたKPTをチーム内でレビュー

チームメンバーがKPTにそって振り返りが終わったら、ファシリテーターが同じような意見をまとめます。その後、メンバーを集めてみんなの意見をレビューします。シナップでは、ファシリテーターはディレクターが行うことが多いです。必ずしもディレクターである必要はないと思いますが、プロジェクトには様々なフェーズがあるため、全体像を知っている人が適任だと思います。

3. メンバーからコメントをもらってディスカッション

意見をまとめると、同じようなものが複数あるため多くのメンバーが課題に感じているものなど分かりやすいのですが、それだけだと意見の重要度が測りきれないので、各メンバーからも特に気になった点などについてコメントをもらいます。それに対して他の人はどう考えているのか、少し意見を交わして良い所、課題点についての理解を深めます。

4. Knowledge、Issue、Riskをチーム内で考える

3でプロジェクトの振り返りが終わり理解が深まりました。ここで達成感があるのですが、まだ終わりではありません。次のプロジェクトへ活かすために、今回の経験を抽象化して、Knowledge、Issue、Riskにする作業があります。 プロジェクトというのは唯一無二であるため、反省点がプロジェクトに依存していると次に活かしづらくなってしまいます。そのため、抽象化して汎用的にしておく必要があります。
この抽象化する作業は慣れないと中々大変なのですが、3のディスカッションの部分で「どうしてそれがそうだったのか」というのがチーム内でうまく共有でき理解が深まっていれば、この経験を次のプロジェクトにどうやって活かすのかを考えるのは難しいことではありません。 また、実際にプロジェクトで同じ経験していないメンバーにも、知見として共有しやすいというメリットがあります。

5. Tryをタスク化する

複数出てきたTryの中からすぐに行動に移すことのできそうなものを選んでタスク化します。これを実行すれば、小さいかもしれませんが、成長へ一歩近づきます。

6. メンバーの健闘を讃え合う！

今回出たKPTIRKの意見をもう一度さらっと振り返り、プロジェクトお疲れ様とメンバー間でお互いの仕事を讃え合いましょう！　この後、打ち上げしてもいいですね。ちなみにシナップではクローズアップミーティング（この振り返りミーティングのことです）をしないと、プロジェクトの打ち上げをしてはいけないことになっています。

KPTIRKのいいところ

振り返りのいいところを、敢えて言葉にしてまとめてみました。

自身のプロとしての行動、意識を見つめなおす

いつでもベストな行動、モチベーションを持つことができるとは限りません。そのため、定期的に行動や意識にブレがないかを確認することが大切です。シナップではその軸を会社の行動指針としています。うまくできなかった点に関しては、どうしてできないのか、を考えることによって次の成長につなげることができます。

成長を感じることができる

プロジェクト毎、定期的にKPTIRKを行うと、前回はできなかったけど今回はできたね、という部分が見えてきます。成長を感じることは次へ成長するモチベーションに繋がります。これは自身だけでなく、メンバーやチームとしての成長も同じですね。

次のプロジェクトに経験を活かすことができる

これについては上記で繰り返して説明したので割愛しますね。

プロジェクトの中で得たストレスの発散

チームで動いているため、プロジェクト中にお互いがお互いの動きに不満を持つことも少なくありません。また、自身がうまく立ち回れなくてメンバーに迷惑をかけているけれど、特に指摘されることもなくプロジェクトが進行して、いたたまれない気持ちをずっと引きずってしまうこともあります。どちらも精神衛生上良くないですね。
でも、こういった振り返りがあると「ここはこうするべきだったのではないか」とか「あの時に助けてくれたことには本当に感謝をしている」など、メンバーに想いを伝える機会を得ることができます。
気持ちの部分も大きいので改善点がうまくまとまらないこともありますが、想いが誰かに伝わるだけで割りとスッキリするのではないでしょうか。
一番もったいないのは、話し合いを行わずにお互いが仕事のやりづらさを引きずったまま次のプロジェクトに入ることですね。このタイミングでぜひ解消したいものです。

まとめ

KPTIRKいかがでしたでしょうか。振り返りの方法は会社やプロジェクトによって様々違うと思いますが、うまく振り返りができない、振り返りがうまく次に活かせない、というお悩みをお持ちの方はぜひ、KPTIRKを試してみてください！