はじめに
プロジェクトを終えるとき、ふりかえりをやっていますか?
ふりかえりでなくても、クロージングといった何かしらの締めくくりのイベントを立てていますか?
先日、『世界一流エンジニアの思考法』(牛尾剛、文芸春秋、2023)を読んでいたときのことです
その本でやり方が良くなくて成果があまり出せなかった話が書かれていて、「ふりかえりは、イマイチなやり方を発見できるし、そのやり方を別のやり方に変えられるチャンスだよな」とかぼんやり考えていました
当たり前のことを書きます
ふりかえりのサイクルが短いと、ふりかえりの頻度は高くなります
ふりかえりのサイクルが長いと、ふりかえりの頻度は低くなります
頻度の低いふりかえりを実施し忘れたら、どうなるでしょうか?
もっと良いやり方があるかもしれないのに、気付けないかもしれません
やり方を変えるチャンスを見失うかもしれません
プロジェクトもどちらかと言えば、ふりかえりのサイクルが長いです
弊社では3ヶ月から6ヶ月くらいのプロジェクトが多いですが、場合によっては6ヶ月を超えるプロジェクトもあると思います
タイミングを逃すとふりかえり損ねてしまいます(もったいないです)
そこで今回は、2023年12月時点での、弊社PHONE APPLIの開発プロジェクト体制を踏まえつつ、プロジェクトのふりかえりの実例を紹介します
開発プロジェクトの体制
弊社におけるPHONE APPLI PEOPLEの開発は、6つのチームで構成されています
1チームはおおよそ8−9人で機能横断的なメンバーが集まっています
ほとんどのチームが、Scrumを採用しており、2週間Sprintで回しているケースが多いです
リリースの頻度は、月に1度あるかないかくらいで年10回ほどです
2023年5月から、ミッションチームという新たなチーム体制でスタートを切っています
各ミッションチームは、ミッションを持ち、ミッションの達成に向けてチームで取り組みます
ミッションチーム体制以前と比較して表にまとめる以下になります(著者調べ)
2023年5月以前 | 2023年5月以降 | |
---|---|---|
チームの解散頻度 | プロジェクトごと | 実質なし(人の入れ替えはある) |
チーム人数 | 5−9人程度(プロジェクトごとに異なる) | 8−9人が多い |
チームの役割構成 | プロダクトオーナー、スクラムマスター、開発者 | プロダクトオーナー、スクラムマスター、開発者 |
チームごとの機能分担 | 実質なし(プロジェクトチームが解散するため) | あり |
プロジェクトごとの学習コスト | 高い(初めて触る機能の開発もありうる) | 時間が経つにつれて低くなる |
機能横断的 | 開発者は、プロジェクトごとに必要なスキルをもったメンバーで構成される | 開発者は、Web、iOS、Android、QAエンジニアのスキルを持ったメンバーで構成される |
プロジェクトの優先度 | 開発組織全体で優先度が決まる | ミッションチームごとに優先度が決まる |
チームの解散が実質なくなった点と機能分担ができている点で、各チームの機能に対するノウハウや専門性を高めることができています
一方で、一つのミッションチームでプロジェクトを同時並行で動かすことが多くなり、プロジェクトの区切りがなくなってきているようにも思えます(プロジェクトの同時並行の是非は本題から外れるので触れません)
1つのプロジェクト(ここではプロジェクトAとする)が終わった時には、別のプロジェクトに従事する必要があり、プロジェクトAのふりかえりをする時間を逃してしまう😢といった状況が考えられます
(この状況を少しでも回避できることを願って、この記事を投稿しています)
プロジェクトのふりかえりの実例
ここからは、ミッションチームで以前スクラムマスターとして参加していたプロジェクトのふりかえりを紹介したいと思います
3ヶ月前の話になるので、私も思い出しながら書きます
プロジェクト概要
プロジェクトの概要は以下です
項目 | 説明 |
---|---|
プロジェクトの目的 | スマートフォンアプリの社内電話帳詳細画面のUI刷新 |
プロジェクト期間 | 2023/05-2023/10 |
ステークホルダー | UI/UXデザイナー2人、カスタマーサクセス2人 |
プロジェクトメンバー構成 | プロダクトオーナー1人、スクラムマスター1人、iOSエンジニア1人、Androidエンジニア2人、Webエンジニア4人、QAエンジニア1人 |
「社内電話帳詳細画面とはなんぞや???」となっていると思います
リリースした機能については、弊社カスタマーサイトにて記載がありますので、ご参考にしてください ↓↓↓
ふりかえりの実施
ふりかえりは、リモートで行いました
概要は以下に記載しています
項目 | 説明 |
---|---|
ふりかえり参加メンバー構成 | プロダクトオーナー1人、スクラムマスター1人、iOSエンジニア1人、Androidエンジニア2人、Webエンジニア1人、QAエンジニア1人 |
ふりかえり期間 | 2023/06-2023/09 |
開催日 | 2023/09/28 |
開催時間 | 50分 |
開催場所 | Web会議、ホワイトボードツール |
ふりかえりは、タイムラインとKPTのKとPの亜種とプロジェクトを漢字1字での表現を組み合わせた独自の手法で行いました
※ ホワイトボードのスクリーンショットは、実施したものを土台に再編集しています
タイムテーブル
進行順序と大まかな所要時間はこんな感じです
最後に大喜利みたいな項目が入っているのは、開催した私の好みです
項目 | 所要時間 | |
---|---|---|
1 | タイムライン | 5分 |
2 | タイムライン | 30分 |
3 | KPTのKとP | 10分 |
4 | プロジェクトを漢字1字で | 5分 |
タイムラインでのふりかえり
所要時間30分
タイムラインは、横軸は時系列、縦軸は今回はプロジェクトの進捗度(感覚値)の2次元でプロットして行いました
バーンアップチャートのように、右上に向けて対角線にあたる矢印を引いています
ふりかえり参加者は、各々グレーの付箋に出来事を書いてマッピングをします
- 矢印より上にある場合は、プロジェクトの進捗度に対してよりポジティブな影響を与えている出来事をおきます
- 矢印より下にある場合は、プロジェクトの進捗度に対してよりネガティブな影響を与えている出来事をおきます
- 矢印上にある場合は、プロジェクトの進捗度に対して見合った出来事をおきます
出来事のマッピングが終わったら、今度は出来事に対してコメントをつけていきます
今回は、「感じたこと」と「学んだこと」にピックアップしてコメントを書いてもらいました!
マッピングしたものが1枚目の画像で、出来事に対して、感じたことや学んだことを付け加えたものが2枚目の画像です(丸枠は編集で追加しました)
今回のプロジェクトの大きなポイントとしては、以下だと思います
- 早い段階でお客様とコンタクトをとっているカスタマーサクセス部門のメンバーにデザインのフィードバックをもらえた
- リリースの前段階で社内検証を実施し、社内フィードバックを通して改善が行えた
- (書かれてはないですが)リリースのタイミングをずらさず、代わりにリリースの機能を減らしてスコープを調整した
- PRレビューのリードタイム短縮に向けたプロセス改善をボトムアップで実行できた
- Sprintの期間変更をチームで決断した
KPTのKとP
所要時間10分
タイムラインの後に、KPTのKとPを使ってふりかえりをしました
KEEPを「今後も継続していきたいこと」、PROBLEMを「改善したいこと」とラベリングをして実施しました
ここで何もアイデアが出てこなかったらどうしようと思っていましたが、参加者全員が書いてくださいました(ありがとう)
プロジェクトを漢字1字で
所用時間5分
さいごに、PJを漢字1字に思いをこめていただきました
ミッションチームが始まってすぐプロジェクトが開始したため、このチームで最初のプロジェクトだったメンバーも多く、それに関連する漢字が多く選ばれていました
ふりかえりのふりかえり
今回のふりかえりは、開催してみてアジェンダの量とタイムボックスが合っていないことに気づきました
ふりかえりのタイムボックスを調整して、2時間程度を予定して開催しても良さそうだなと思いました
また再編集で割愛したのですが、タイムラインに将来のビジョンのマップをさらに右上に用意していたました
ただ、記入時間が足りなく手が回っていませんでした
将来のビジョンの部分は、最初からカットしていてもよかったかなと思います
KとPに関しても、深掘りしたい内容だったので、時間が許せばTまで含めたほうが良さそうです
(やはりふりかえりはTryで締めくくりたい)
最後のPJの漢字1字は、参加者全員が付箋を出してくれて嬉しかったです
まとめ
まとまりのない文章を最後まで読んでくださってありがとうございます
プロジェクトのふりかえりをする機会は限られていると思いますので、やってないよって方がいましたら、この機会に始めてみるのはどうでしょうか?
実は、今年2度目のアドカレ投稿です
よろしければ、前回投稿記事もご一読いただけると嬉しいです!
では〜