👋自己紹介

こんにちは、ふりかえりマイスターを目指している佐々木です。
KINTOテクノロジーズでプロジェクトマネージャ（PjM）をしています。
前職ではPLをしており、アジャイル開発（スクラムやカンバン）にチームで取り組んでいました。

私はふりかえりがとても好きです。前職では、ふりかえりを通じてミニマムな設計ドキュメントを整えたり、CIを推進したり、はたまた新人さんとシニアの間のわだかまりを取り除いたり･･･と、開発にもメンタルケアにも使えてとても助けられました。

はじめに

入社して1年経ち、プロジェクトマネージャとしていくつかリリースとふりかえりを行いました。

イテレーティブな開発サイクルの中で行うスクラムチームのふりかえりと違い、プロジェクトのふりかえりはメンバが毎回違う有期での開発・リリースになります。スプリント単位のふりかえりに比べ、実施タイミング、観点やゴール設定が難しいなと感じました。

また、チームメンバほどの関係性が構築できていない状況でいかに本音を引き出すか、参加メンバにフィットするふりかえりで使用するツールは？フレームワークは？面着でやるの？といった運用面でも気を遣う必要がありました。

今回は、複数のチームが横断で取り組む「プロジェクトのふりかえり」に採用した手法とその理由、および具体的なふりかえり手順と得られた結果について言語化していきたいと思います 🙌

目次

1. プロジェクトのふりかえり
2. ふりかえりのカタ
3. ふりかえりの設計
4. ふりかえりの実践

プロジェクトのふりかえり

KINTOテクノロジーズにおける“プロジェクト”

KINTOテクノロジーズには、お客さん向けのフロントを担うプロダクト、車を注文する販売店向けのプロダクト、カスタマーセンターを支えるプロダクトなどなど、エンドユーザー向け・バックオフィス向けの様々なプロダクトが存在しています。

契約プランに関わる変更、取り扱いブランドの追加など複数のプロダクトが横ぐしで協調してリリースする必要があったり、ステークホルダーが多いような開発の場合、KINTOテクノロジーズではプロジェクトという単位で開発を進めます。

プロジェクト進行

各プロダクトはスクラムなどチームごとに違ったスタイルで日々の開発を行っています。
プロジェクトとしては大きな工程・マイルストーンを計画し、要求分析、要件定義など固めたうえで、設計・開発工程はアジャイルに作りこみを実施します。
俗にいう、ハイブリッド開発手法（ウォーターフォール+スクラム）の進め方でプロジェクトを進めていきます。
プロダクトとしてはイテレーティブな開発サイクルで日々の開発を行い、大枠はウォーターフォールでマイルストーンごとの品質や期限を担保するイメージです。

引用元：ハイブリッド開発とは何か？ “アジャイル型”との違いや推進体制を解説

今回のプロジェクト

これまでKINTO ONEの解約金フリープランでは、契約途中で解約をお申込みする際、電話でのお申込みとなっていました。お客様の使い勝手向上のため、こちらをWEBから申し込みできるようにします。

これとは別にバックオフィスのプロダクトでは、ハンドで行っていた中途解約業務を半自動化して改善するプロジェクトを1年がかりで行っていました。

WEBから解約申し込みできるようになると受付数が増大するため、自動化がセットで必要です。
今回はこの2つのテーマの開発を1つのプロジェクトとしてリリースします。

期間は4か月で、直接関係するチームリーダーや企画メンバ（KINTOメンバ）は総勢20名程度です。

https://corp.kinto-jp.com/news/service_20240219/

🧙‍♂️ふりかえりの「カタ」

より効果的なふりかえりにするために、私の大好きな本「アジャイルレトロスペクティブズ」で推奨されているやり方を参考にしたいと思います。以下の5つのセクションにわけてふりかえりを進めていきます。

1. 場を設定する
アイスブレイク、グランドルール読み合わせなどで意見を出しやすくする

2. データを収集する
ふりかえりのもととなる情報を読み込む、ホワイトボードに付箋を貼る

3. アイディアを出す
ブレーンストーミングなどのエクササイズでアイディアを言語化する

4. 何をすべきか決定する（アクションアイテムの決定）
ドット投票など用いて、参加者で何のアクションに取り組むべきかを決定する

5. クロージング
アクションアイテムなどについてまとめ、感謝を伝えてふりかえりを終了する

ざっくり内容

ざっくり要約すると、話しやすくしてホワイトボードなどで感じたことを伝えてもらい、それらについてディスカッションしてアクション・改善につなげます。これをなぞる形で当日は進行します。

この”カタ”は主にアジェンダ作成に用いられますが、この本には「開発期間に応じた時間設定」など、ふりかえりに関する細かいTipsなどが載ってるので、要所要所で参考にしながらふりかえりの設計を進めていきます。

興味を持った方は、ぜひアジャイルレトロスペクティブズを読んでみてください！
アジャイルレトロスペクティブズ（Amazon）

🏗️ふりかえりの設計

ふりかえりの内容はプロジェクトの性質や参加メンバなどコンテクストにも応じて変えていく必要があります。 私のふりかえりの設計過程を順番に言語化してみます。

1. 前提・制約の確認
2. 目標の設定
3. 進め方の設計・検討

1.前提・制約

まずはふりかえりの前提・制約を整理します。本プロジェクトにはさまざまなチームが参加しています。進行が滞らないようにポイントを整理します。

• チームごとのふりかえり文化の違い

  • ふりかえりは定期的に実施してるチーム、そうでないチームがある
  • KPTはやったことがあるがほかのやり方はしらない人もいる

• ツールの習熟度の違い

  • ホワイトボードを使い慣れていないチームもある
  • Miroを知らない人もいる
  • コンフルなど新たに権限追加が必要な人もいる

• 参加者の拠点の違い

  • 東京、名古屋、大阪

• その他

  • 有期のチーム横断開発となり、プロジェクト後は解散する

💭思ったこと

ふりかえり文化の違い

会議予定など見ると、スプリントふりかえりを実施してるチーム/実施していないチーム等、それぞれの文化の違いが顕著でした。以前のプロジェクトではKPTを実施したそうなので、KPTに関しては皆さんご存じのようです。

ツール選定

複数のチームが参加するため、チームによってはツールの習熟度に違いがありました。よくわからないまま参加する会議は心地いいものではありませんから、全員がツールの操作で滞ったりせず、前向きに参加できるようにしたいです。

会議時間の設定

会社全体はわからないですが、前職から比べると私の関係者は会議時間が短めな気がします。
長くて30分で、1時間を超える会議は長いと感じる方が多そうです。

また、チームによっては、プロジェクトのふりかえり自体に積極的じゃないメンバがいる可能性もあるかもしれません（チームでやってるし…的な）。これらを考慮するとなるべく必要最低限でハレーションがおきにくい時間に設定したいです。

実施場所（オンサイト・オフサイト）

拠点が違う方もいるので、面着でやるのかオンラインでやるのかも重要です。面着でやる場合はオンラインのメンバが疎外感を感じないようにする必要があります。
社内のアジャイルチャンネルで質問したところ、皆さんが過去に経験したやり方とその際の注意点を共有してくれました（ハイブリッド開催、Jamboard利用などなど。皆さんありがとう！）

心理的安全性

また、心理的な面の不安もあります。チーム横断で参加するメンバ同士はコミュニケーションが醸成されていないため、本音を引き出すのが難しいです。心理的な安全性をなるべく確保したいと考えました。

さてどうやってすすめよう。

2.目標の設定

自分がPjM・ファシリテーターとしてこのふりかえりで達成したい目標を設定します。

💭思ったこと

私は、ふりかえりを通じて組織を超えた改善につなげたり、サービス自体の横断的な機能改善ができたらいいなと考えていますが、まだまだ関係者との信頼関係を作り始めたところなのでむやみに風呂敷を広げにくいなと思いました。

そこで、今回はプロジェクトとしての成果の共有や、自分でコントロール可能な範囲（プロジェクト運営）の課題解決にフォーカスしたふりかえりを行っていこうと思います。ディスカッションの中で出た組織横断的な課題・問題点については、いつかの改善のため共通認識とするのにとどめようと思います。

他、組織全体としてインタラクティブなふりかえりに慣れていきたいので、ホワイトボードは絶対に使いたいと思いました。

メインミッション

• プロジェクトの成果を確認・共有する
• プロジェクト運営としての改善タスクを確認する

サブミッション

• 主語の大きい課題に対して企画・開発間で共通認識を得る
• ホワイトボードを使ったインタラクティブなふりかえりの導入

3.進め方の設計・検討

前述の制約を考慮して目標を達成するため、当日のふりかえりの進め方を考えてみます。

1.場を設定する

心理的安全性

ふりかえりは多数のメンバが参加するため、ある程度決まった流れにそって進めていきます。
それらの説明と、この場の心理的安全性を確保するために冒頭にグランドルールを宣言します。
少しずつ伝えたいので、さりげなくホワイトボード上の目に入るところにも置いておきます。

時間設定

アジャイルレトロスペクティブを参考にすると、リリースふりかえりの場合は1日～4日近くの時間を使ってもよいとされていますが、前述の通り1時間だと長く感じる人が多そうですので、めちゃ圧縮して45分程度に設定したいと思います。

2.3　所要時間の決定
レトロスペクティブにはどれだけ時間をかけるか？それは、場合によりけりである。
～ 中略 ～
1週間のイテレーションを行うチームなら、1時間のレトロスペクティブで十分だろう。
30日間のイテレーションを行うチームなら、半日で十分だ。
時間を短くすると、いい加減な結果になる。
（リリースおよびプロジェクトのレトロスペクティブは少なくとも1日はかかる。場合によっては4日かかることもある。）
引用：アジャイルレトロスペクティブ 2章より

2.データを収集する

ふりかえり文化の違い / ツール選定

KPTはKTC内でもポピュラーな手法であったこと、業務上の基本ツールとしてコンフルを使うことが多いので、アカウントなど準備の手間をクリアしてるコンフルのホワイトボードを使います。

データを収集するエクササイズとしては以下の2つを使用します。
タイムラインについては聞きなれない方もいるでしょうか。それぞれの内容について、詳しく説明します。

• タイムライン
• KPT

タイムライン

準備無しでふりかえりをした場合、直近で印象深いことに注目が向くことが多いのではないでしょうか。
タイムラインは過去にあったことを思い出すためのエクササイズです。
期間内で起きた事実やその時の感情を時系列に並べることで当時の状況を思い出せるようにしておきます。

引用：タイムラインとは
https://anablava.medium.com/a-timeline-retrospective-easy-guide-6385fce0affd

今回、タイムラインはがっつり記載してもらうのではなく、あらかじめPjMが書いたものをさりげなく置いておき、思うところがあれば追加で付箋を貼ってもらうことにします。ドットも使わないことにします。
※タイムラインを置いておくのは、アジャイルチャンネルのきんちゃんのアイディアを拝借しました。

リリースレトロなので、本当はもっとしっかり感情の情報を集めたいところではありますが、45分という限られた時間なのであっさりめとします。

KPT

やったことがある人が多い＆仮にやったことが無い人がいてもわかりやすいので、KPTで実施します。

学生時代のオリエンや企業の集合研修などなど、どこかで触れた方が多いのではないでしょうか。
Keep、Problem、Tryを上げていき、それぞれのトピックについて改善点を探すフレームワークです。それぞれの頭文字をとってKTP（ケプト／ケーピーティ）といいます。私はケプトと呼びます。

• Keep / できたこと・継続したいこと
• Problem / 課題・問題点・改善したいこと
• Try / 挑戦したいこと

KPTの注意点

ふりかえりの手法として最もメジャーなKPTですが、主語が最初から"問題点"になるのでカドが立ちやすく、ちょっとしたモヤモヤが出しづらかったりします。
また、個人的な意見がハナっから問題点として扱われてしまったりします。

私は、KPTのファシリをする際にはいつもに増して客観的＆言葉遣いに気を付けて実施しています。

※完全に個人的な好みですが、デモなど自分たちの成果のお披露目後に使うなどがおすすめです！
（プロダクト機能観点の問題点が開発メンバ自身から出やすくなるため）

4.アイディアを出す

KPTのTryでアイディアを出してもらいます。
忙しい人が多いので、事前に書いてもOKとします。

事前に書いておいてもらう場合、KPとTryの関連性が薄れる可能性がありますのでふりかえり当日にも確認する時間を設けてTryの内容を深堀するようにします。

5.何をすべきか決定する（アクションアイテムの決定）

スクラムチームのふりかえりではドット投票などでコミットメントを得ますが、今回は限られた時間（45分）で行いますので、ファシリテーションしながらアクションアイテムを選別します。
プロジェクト範囲外の組織課題なども議題に上がるかもしれません。

主語の大きい課題は受け止めつつ、プロジェクト運営としての改善を具体化するように心の準備をします。

🎯ふりかえりの実践

上記の設計を経て、実際におこなったふりかえりをまとめます。
※ ちょっと細かいですが、新たにふりかえりを導入したい方向けに心がけたことも書いておきます。

1. ふりかえり開催の案内・フォロー（事前準備）

• 今回のプロジェクト成果の収集についてのお願い
• ホワイトボードを使う旨の周知、お断り
  ※ 個別に席で話せたり、会議終わりに頭出しできるならしておくようにします。
• 忙しい人、事前に書きたい人向けにホワイトボードを事前展開しておきます。

2. 場の設定

• グランドルールをあっさり読みあげて話しやすい雰囲気を作ります。
  ※ 「ちくちく言葉はだめで～す！」のように、やんわりと注意を呼びかけます。

グランドルール
ここは、フィードバックを共有できる安全なスペースです。
- チクチク言葉はつかわない
- 共有してもよいと思うものをすべて共有する
- 非難ではなく改善に焦点を合わせる
- 誰かの付箋を真似したり、付け足すことを歓迎します

3. データの収集

各部署から、プロジェクトとしての具体的な成果を発表していただきました。
電話で受け付けていた解約がWebで申し込めるようになったため、相当な工数削減になったようです！

a. タイムラインの記載

モヤモヤしたことやその時の感情について、タイムライン上に任意で記載をお願いしました。
感想としてリリース後も大変だったことがわかります。
こうしたフィードバックはKPTでは出にくいので拾えてよかったです。

b. Keep、Problem、Tryの記載

事前に書いてくれた方、その場で書いた方様々ですがいろいろな意見が集まりました。
忙しい方が多いのでTryまで書いてOKとし、KeepとProblemとセットでTryを書いてもらいました。

※業務に関わる内容が多いので字をつぶしています

4. アイディアを出す

全ての付箋を簡単によみあげ、あらためてこれまでにあがったKPTの印象を参加者の方に聞きます。
印象を話す中でディスカッションが発生しますので、ファシリしつつ、新しくtryにつながるアイディアがあればふせんにまとめて貼っていきます。

5. アクションアイテムの決定

PjM運営で改善できること・次のプロジェクトで取り組めるようなTryをアクションに落とします。

※ 業務上見せられるものを抜粋しています

6. クロージング

上記をまとめ、感謝を伝えて解散します。

今回のふりかえりの成果

ふりかえりを通じて以下のような収穫が得られました。

プロジェクトとしての成果

• プロジェクトの効果について、関係者で具体的な数値で工数削減を実感できた。
  • プロジェクトリリースを参加者で喜び合うことができた。
• プロジェクトの課題について改善アクションが生まれた。
• 組織を跨いだ課題（デザイン資料の扱い方など）について共通認識を得ることができた。

その他の成果

• 結構勇気をだしてホワイトボードを提案したが、すんなり受け入れてもらえた
• タイムラインでリリース後の苦労などがうかがえ、リリース後運用の安定の重要度を再確認した

上記から、ファシリテーターとして計画していた目標を達成できました 🎉

メインミッション

• プロジェクトの成果を確認・共有する：達成
• プロジェクト運営としての改善タスクを確認する：達成

サブミッション

• 主語の大きい課題に対して企画・開発間で共通認識を得る：達成
• ホワイトボードを使ったインタラクティブなふりかえりの導入：達成

今後に向けて

やってみたらホワイトボードやタイムラインなど、皆さんにすんなり受け入れてもらえました。
タイムラインもお披露目できましたので、しばらくしたら4Lなど取り入れてみたいと思います。

時間の制約については、もしかしたら私が遠慮してただけで長めに設定できるかもしれません。
もしくは、リリースのふりかえりだけでなくプロジェクトの節目でふりかえりをとりいれると、時間は45分のままでも程よいタイミングでふりかえりを設定していけるかもしれません。問題が起きたタイミングで改善できるしね！

感想

今回はプロジェクトでのふりかえりについて、私の考えや実施方法をまとめてみました。
同じようにプロジェクトのふりかえりで悩まれてる方がいれば、お力になれると幸いです！
ふりかえりはイテレーティブな検査・適応を体現したアジャイルの申し子のような存在です。

みなさんもよいふりかえりライフを！