こんにちは、Backlogチームの小久保です。Backlogチームでは、約4年続いたBacklogをJavaからScala / Play Frameworkに移行するプロジェクトについて、2日間かけてふりかえりをしました。そのとき得られた知見を整理してみました。
長くやってきたプロジェクトを振り返ると、プロジェクトに大きな影響を与えた決断がいくつか必ずあります。その決断が正しかったのか、今後の自分たちの重要な意思決定をどう改善していけるか、しっかり考えるためにも効果的にふりかえりをすることが大切です。
本記事では、ITツールの活用方法や特定のプロセスの話は出てきませんが、Backlogチームがおこなった、長期プロジェクトを振り返るために役立ったことを整理してお届けします。
目次
プロジェクトの内容とふりかえりをした理由
Backlog Play化プロジェクトとは、Backlogの動作環境、コードベースをTomcat/JavaからPlay framework/Scalaへ移行するプロジェクトでした。
プロジェクトの期間は、2015年11月から2019年7月までの約4年です。そして、プロジェクトに参加したメンバーは、2015年の時点の1名から、最終的には7名まで増えました。プロジェクトメンバーが詳しく書いた記事もありますのであわせてご覧ください。
- 時系列でみる！4年の歳月をかけてPlay Frameworkで「大規模リプレイス」した話
- 開発チームが大規模リプレイスを成功させるために取り組んだ “7つの取り組みと反省”
- Backlogのコードメンテナンス性を向上させるために気をつけたこと
- JVM上で動くWebアプリケーションがリソースを食いつぶす原因を探るためにやったこと
- SREは大規模なリプレイスプロジェクトで発生した様々な問題にどう取り組んだか
- 約4年続いた長期プロジェクトに途中参加して学んだ反省と教訓
ふりかえりをすることになった理由
Backlogチームのプロジェクトの中でも特に期間が長く、規模も大きい大変なプロジェクトでした。ここで得た知見や教訓は、今後の別のプロジェクト運営に活かすためにも、きちんと振り返っておくべきだと判断して、関係者に集まってもらいました。
参加者
ふりかえりにはプロジェクトの直接の関係者7名と、マネージャーとして3名が集まりました。
制約
Backlogチームは国内では福岡、京都、東京に開発拠点があります。Backlog Play化プロジェクトは、これら3つの拠点にまたがって進行していました。
プロジェクト自体は、オンラインのコミュニケーションで成立していましたが、ふりかえりを目的として4年分の積もり積もった話をオンラインでするのは大変です。なので、ふりかえりとプロジェクトが無事に完了した打ち上げを兼ねて、福岡と東京の中間地点である京都オフィスに集合しました。
（本題とは関係ありませんが、普段はリモートでコミュニケーションを取って仕事をしていても、定期的にオフラインで顔をあわせることはとても大事です）
ふりかえり準備で意識したこと、やったこと
事前準備でやったこと
Backlog Play化プロジェクトをふりかえるために、以下の必要なことを準備していきました。
- 日時
- 場所
- 参加者
- 当日のスケジュール
- ふりかえりの目的とスコープ
- ふりかえりの手順
- コミットログなどから拾えるプロジェクトの歴史
事前準備のなかでも一番気を使ったのは、ふりかえりの目的を設定することでした。
長期で規模の大きいプロジェクトをやっていると、さまざまな個人的な感情が関係者の数だけ出てきます。しかし、それらすべてのケースをふりかえろうとすると、どれだけあっても時間が足りません。
限られた時間で有益なふりかえりができるように、自分たちがこの先もっと上手にプロジェクトを管理できるようになるための教訓と知見を得ることを目的に設定しました。そのため、プロジェクト中のチームコミュニケーションがどうだったか、悪かったところや遅れた原因を詳細に掘り下げることをスコープから外しました。
本記事の最後に「教訓」としてまとめていますが、ふりかえりではこの「なんのためにふりかえるのか」を明確にして、周知するふりかえりの場づくりが大事だとあらためて思いました。
さらに、コミットログからひろえる事実関係として、プロジェクトの歴史を誰かが時間を取ってあらかじめ用意しておくと円滑にふりかえりができます。いつからプロジェクトが始まっていたのか、いつ、どういう機能をリリースできたのか、事前に情報をひろっておくと当日の時間節約になります。
前日の準備
京都オフィスにプロジェクトメンバーが集結して、さっそくふりかえり！にはせずに、普段オンラインでコミュニケーションをしているメンバーが対面でも打ち解けられるように、以下のようなアイスブレイクなどを挟みました。
- アイスブレイクのインプロワークショップ
- A4用紙を200枚くらい用意
- 部屋のスペースをどう使ってふりかえりをするかシミュレーション
ヌーラボ代表の橋本も参加して、アイスブレイクのためにインプロ（即興劇）ワークショップをしました（昔劇団で学んだそうです。色んな過去のある人ですね）みんなで身体を動かしてワイワイできるワークショップでした。
その後に、翌日のふりかえりの準備をしました。
少人数で壁を使ってふりかえりをするときは、ふせんを使う場面が多いと思います。しかし、今回は10名という大所帯だったので、部屋を広く使ってみんなで見て回れるように、ふせんの代わりにA4用紙を使って、床（畳）に置くことにしました。
※実はヌーラボの京都オフィスでは10人くらいが集まってワイワイできる畳部屋が2階にあるのです。
ふりかえり当日にやったこと
前日の準備を経て、ふりかえりの当日を迎えました。
- みんな集まったらまずはふりかえりの目的をあらためて全員で共有
- 事前に準備したふりかえりの手順に従って進める
今回のふりかえりは以下の手順で進めていきました。自分たちがやってきたことを時系列に書き出したうえで 1.プロジェクトに良い影響を与えたこと、2.悪い影響を与えたこと、3.次回へ活かす教訓 をみんなで話し合いました。
- 床（畳）を使って時系列に出来事をA4用紙に書いて並べていく
- Backlog Play化プロジェクトでやったこと
- Backlog Play化以外のプロジェクトの動き
- プロジェクトメンバーの移動
- プロジェクトを進めるうえで重要だったイベント、判断をピックアップする
- 良い影響を与えたイベント、判断
- 悪い影響を与えたイベント、判断
- もっと早くプロジェクトを終わらせるために何ができたかを考える
- 終わったいまだから言える「あの時ああしていれば…」
- 次に同じようなプロジェクトをやるとしたら何を気をつけるか？
- 意見が出たらバッーっと紙に書いていく
- まとめ
- 結果を写真に撮る
- 反省点や次回に活かせることを整理する
終わった後はみんなでオフィス屋上でBBQをして打ち上げしました。 :beers:
ふりかえりの後日にした情報共有
2日間におよぶふりかえりは無事に終わりましたが、ふりかえりの目的である「学んだ知見や教訓を今後の別のプロジェクト運営に活かす」ために、以下のような取り組みで社内への情報展開をしました。
- 結果を要約してテキストにまとめる
- 全社ミーティングで社内に知見を共有
以上のようなフォーマットで、ふりかえり結果を整理して、テキストにまとめました。そしてこの結果を月一の全社ミーティングで全体に共有しました。今後の礎となることを願って。
今回のふりかえで教訓
よかったこと
今回のふりかえりでよかったのは、主に以下の2点です。
- 最初に目的と明確に設定した
- スペースを広く使ってふりかえりを進めたおかげで全員が意見を言い合えた
1つ目は、最初にふりかえりの目的（ゴール）を明確にして周知したので、2日間10人で話し合うという環境でも、話し合う内容が途中でブレることなく進められました。
2つ目に、畳部屋とA4用紙を使って、部屋全体を使ってふりかえったおかげでみんなで全体を眺めながら意見を言えたのもよかったです。壁は人間に対して横を向いてるので180度しか視野がありませんが、床を使うと、上下左右360度いろんな方向から見れるようになるので大人数でも割となんとかなることがわかりました。
この辺の話は弊社のアジャイルコーチが話している資料もありますのでご参考にどうぞ。
教訓
今回ふりかえりをしてみて感じた教訓です。
- 長くて大きなプロジェクトには必ず分岐点となる出来事が複数あるが、それを活かすも殺すも “ふりかえり次第”
- ふりかえりを始めるときに “目的を共有し、ふりかえりの場をつくる”
- 参加者が10人超えるような大きな話は “大きめの部屋を確保して広く使う”
まとめとプロジェクト管理の教訓
最後に、Backlog Play化プロジェクトを通して、Backlogチームが得た教訓です。当たり前のことを当たり前にやることの大切さと難しいさをあらためて思います。
- プロジェクトを開始するタイミングは時として曖昧になってしまう
- 何をどこまでやるのかゴールについての認識が関係者ですりあってないこともままある
- 物を作るエンジニアだけでなく、マーケやサポートなど関係者集めてキックオフしてゴールを決めよう
- プロジェクトメンバーが移動するとその度にチームビルディングが必要になる
- そのコストが嫌なら人を移動させない
- 必要コストならばそれをスケジュールに加味する
- できれば一つひとつのプロジェクトを長期化させない仕組みがチームにあると良い
- 例) チェックポイントをつくる
長くやってきたプロジェクトを振り返ると、いくつかプロジェクトに大きな影響を与えた決断が必ずあります。その決断が正しかったのか、今後の自分たちの重要な意思決定をどう改善していけるか、それをしっかり考えるためにも上手にふりかえりをする手法が大切です。
最後までお読みいただきありがとうございました。
Play化プロジェクトメンバーが執筆した他の記事もぜひご覧ください。
- 時系列でみる！4年の歳月をかけてPlay Frameworkで「大規模リプレイス」した話
- 開発チームが大規模リプレイスを成功させるために取り組んだ “7つの取り組みと反省”
- Backlogのコードメンテナンス性を向上させるために気をつけたこと
- JVM上で動くWebアプリケーションがリソースを食いつぶす原因を探るためにやったこと
- SREは大規模なリプレイスプロジェクトで発生した様々な問題にどう取り組んだか
- 約4年続いた長期プロジェクトに途中参加して学んだ反省と教訓
こちらもオススメ：
プロジェクト管理とは？目的や項目、管理手法について徹底解説！ | Backlogブログ
プロジェクト管理の基本や主な項目を紹介。CCPMやWBSなどのプロジェクト管理の代表的な手法やプロジェクト管理全体の流れを解説。これからプロ…
backlog.com