はじめに

Global Design Group所属の山本です。

フューチャーに新卒入社してこれまで、ウォーターフォール開発のプロダクトにいくつか携わっていましたが、この度はじめてアジャイル開発に関わりました。

その中で、チーム内での「振り返り」の大切さを感じたのでどんな振り返りがよいのか、個人的に考えたことをまとめます。

また、「振り返り」のひとつのアプローチとして、「タイムラインふりかえり」を主催してみたらいい感じだったのでそれについても書きます。

システム開発ライフサイクルについて

そもそも、ウォーターフォール開発やアジャイル開発とはなんなのでしょうか？

どちらも、システム開発をいくつかの段階に定義して行うプロセスである、システム開発ライフサイクル（Systems Development Life Cycle）の手法の1つです。

このシステム開発ライフサイクルの分類や定義、メリット・デメリットもいくつかあるので、詳細はこの記事では触れません。

1つ大きな分類を上げると、
ウォーターフォール開発に代表されるような、ひとつひとつのステップを完了させて次のステップに進む「シーケンシャル開発モデル」と、
アジャイル開発に代表されるような、システムをいくつかの単位に分けて、単位ごとに一連のステップを徐々に開発する「インクリメンタル開発モデル」

の2つに大別するものがあります。

私が今まで関わったプロジェクトは、「シーケンシャル開発モデル」の中でも、「V字モデル」に分類されるものが多かったです。

要求定義、要件定義からはじまり、基本設計->…->コーディング->単体テスト…とステップごとに進むもので、基本的には次のステップに進んだ場合には前のステップに戻らないことを前提としています。

一般的にウォーターフォール開発として想像されるものですね。

両者を比較すると、大きな違いとしてはステップサイクルの単位や期間が異なることが挙げられます。

インクリメンタル開発モデルと「振り返り」

今回、私ははじめてアジャイル開発でのプロジェクトに参加しました。ウォーターフォールとリリースサイクルや動き方が大きく変わるため、良い経験になりました。

その経験の中で、「振り返り」という文脈で考えると、1つの大きな特徴として「キリが良い」ということが挙げられると思います。数週間単位でサイクルを回すので、自然と1つのサイクルが終わったときに振り返りをしやすいんですね。また、類似したステップを次のサイクルでも回すことになるので、作業内容自体の振り返りがダイレクトに活用できるということがあります。

スクラム開発の著名なガイドラインである「スクラムガイド¹」でも、スクラム開発の1サイクル(スプリント)の終了時に、レトロスペクティブ(振り返り)として「スプリントレトロスペクティブ」を行うことが定義されており、振り返りがサイクルの中でも重要なポジションを占めています。

「スプリントレトロスペクティブ」の章については、以下のように記載されています。

スプリントレトロスペクティブの⽬的は、品質と効果を⾼める⽅法を計画することである。
スクラムチームは、個⼈、相互作⽤、プロセス、ツール、完成の定義に関して、今回のスプリントがどのように進んだかを検査する。多くの場合、検査する要素は作業領域によって異なる。
スクラムチームを迷わせた仮説があれば特定し、その真因を探求する。スクラムチームは、スプリント中に何がうまくいったか、どのような問題が発⽣したか、そしてそれらの問題がどのように解決されたか（または解決されなかったか）について話し合う。
スクラムチームは、⾃分たちの効果を改善するために最も役⽴つ変更を特定する。最も影響の⼤きな改善は、できるだけ早く対処する。

スクラム開発に限らず、振り返りとして行いたいコンテンツとしては他の開発モデルにも共通する物があるのではないでしょうか？

今回の経験を通して、短期間で振り返り・フィードバックを行うことは、アジャイルに限らず有意義なことと感じました。では、ウォーターフォール開発などのスプリント単位がない場合ではどうなるのでしょうか？

シーケンシャル開発モデルと「振り返り」

次に上の図のような、典型的なウォーターフォール開発とチーム内での「振り返り」について考えてみましょう。
メンバー目線での上記の特徴としては、「要件定義」や「コーディング」の1つのステップに数ヶ月、大規模なシステムでは年単位の時間がかかることが挙げられると思います。

「振り返り」の目線ではどうでしょうか？

1つ悪い特徴としては、ステップ単位でとらえると「キリが良い」と感じるタイミングまで数ヶ月〜数年単位で時間がかかるということです。また、ステップ単位で振り返りを行っても、次のステップと作業内容自体はダイレクトにはかぶらないこともあります。

他にも、受注や要件定義のタイミングで全体のスケジュールを決定してしまうため、(トラブルが発生した場合の)後半のテストフェーズなどでは、期日通りに仕事を終わらせることで頭がいっぱいで「振り返り」をしている場合ではない！ といった心情になりやすいと感じています。

実際に自分が今まで参加したウォーターフォール開発のプロジェクトでは、個人に対しては定期的な1on1、360度フィードバックなどの実施はありました。(これは会社としても取り組んでいます。良いことですね)

一方で、チーム単位での「振り返り」としては受け入れテストまで完了した時点でKPT法での全体の振り返りを行う事が多かったです。

この振り返りを行うことで、個人的な学びはありますが全く同じチームではすぐに仕事はしないので悩ましいものがあると感じていました。

ウォーターフォール開発でいつ振り返りをすればよいのか問題

チームでの振り返りをする目的の大きなひとつとして、チームレベルでの課題を洗い出し、対応・改善して次に活かすといったことが挙げられると思います。

その視点で考えると、「ステップの終了時」「すべてのステップの終了時」に行うのはそこまで良くない気がしてきますね。

例えば、基本設計終了時に、基本設計フェーズに関する課題や学びが得られても、工程自体に依存するものであった場合は次にメンバーが関わる・活かせるのは数年後とかになりかねません。
(※もちろん、課題が次のステップに関連があり有用なケースも考えられます)

また、振り返りの対象の期間が長くなるため、粒度としても大きくあいまいなものになりがちです。

そのため、ステップやプロジェクトの「キリの良さ」にとらわれず、数週間〜数ヶ月に1回の定期的なイベントとして組むことが1つのアプローチとして考えられます。

どのような振り返りをすればよいのか？

さて、個人的にはアジャイル開発でも、ウォーターフォール開発でも「振り返り」を行いたいわけですが、実際にはどのような方法を行えばよいのでしょうか？

「振り返り」のフレームワーク・手法については山のようにあります。有名なものを上げるだけでも、以下のようなものがあります。

• KPT(Keep Problem Try)
  Keep(継続すること)・Problem(課題)を洗い出し、Try(次に取り組むこと)を検討する
• Good & New
  良かったこと（Good）と新しい発見（New）を発表して共有する
• FDL(Fun/Done/Learn)
  Fun(楽しかったこと)・Done(アウトプットしたこと)・Learn(学んだこと)で振り返りを行う
• SSC(Start Stop Continue)
  Start(はじめること)・Stop(やめること)・Continue(続けること)で振り返りを行う
• Elephants, dead fish & vomit
  象(大きく、無視されている問題)・死んだ魚(放置すると問題があるもの)・吐瀉物(蓄積された考えを吐き出す)の3つの観点から課題を考える

特徴・振り返りの目的に応じて選択するべきだとは思うのですが、自分のこれまでの関わりや経験上では、知名度とシンプルさから「KPT」が第一選択肢とされることが多かったです。

「KPT」で振り返りをするとどうなる？

KPTで振り返りをした個人の感想としては、以下のようなものがあります。

■メリット

• シンプルでわかりやすい。チームメンバー全員が認識している可能性が高い。
• 振り返りの成果として、次に繋げる(Try)ことを明文化しやすい

■デメリット

• 議論が発散しやすい、ファシリテーターの質に依存しやすい
• Problemに集中していまい、反省会のようなムードになりやすい
• チームメンバーが何をしていたのか分かりづらい

手法の選択肢としては良いところもありなのですが、個人的にはデメリットの部分が気になってしまいます。
特に、Problemに話題が集中してお通夜のような雰囲気となってしまえば、「振り返り」自体にネガティブなイメージを持つことに繋がりかねません。

この課題については、チームメンバーやファシリテーションに大きく依存してしまう部分であるため、安定した解決策を求めることが難しいのではないか…？ と個人的には感じてます。

なので今回チームとしては、フレームワークを変えて、「タイムラインふりかえり」 + 「KPT」での振り返りをトライしてみました。

タイムラインふりかえり + KPT

「タイムラインふりかえり」については、以下書籍²に記載されていたものを参考にアレンジして取り入れました。

https://www.shoeisha.co.jp/book/detail/9784798165387

• 社内やチームの出来事を時系列で付箋に書き出す
• メンバーごとに時系列に対する「感情グラフ」を書き出す

ことが大きな特徴です。今回は会議室でホワイトボードでやったのですが、イメージとしては以下のようなものとなります。

この「感情グラフ」の部分がユニークなポイントで、実際にやってみると盛り上がりやすいので、ポジティブなムードの醸成といった意味でも良かったです。

具体的にやった手順

「振り返り、次につなげる」「反省会のようなムードにしない」「チームメンバー間でのタスク内容を共有できる」ことを目的に、いくつかアレンジして振り返り会を実践しましたので、その手順などを紹介します。

■前準備

• 振り返り会の前日、チームメンバーに時系列で発生したイベントをざっと書き出してもらう(スプレッドシートを使用しました)
• 振り返り会の開催直前、ホワイトボードにチーム単位/時系列の枠を書き出す。また、時間節約のためわかっているイベントは付箋として張り出しておく

■実施手順

1. 説明：アイスブレーク・振り返り会の方法を紹介する
2. ワーク：それぞれ思いつくイベント・個人の感想などを付箋に書き出し貼ってもらう
3. ワーク：感情グラフを記入してもらう
4. ディスカッション：感情グラフについての簡単な雑談、タイムラインでカードが少ない部分や感情グラフの起伏に対応したイベントが有る場合には、追加で付箋を貼ってもらう
5. ワーク：メンバーで議論しながら、付箋をGood/Badに分類してもらう。
6. ディスカッション：作成された付箋や感情グラフを見て、ディスカッションを行う
7. ディスカッション：ディスカッション内容をもとに、KPTを抽出する
8. まとめ

実施手順ごとの成果物のイメージとしては、以下の図のようなものとなります。

最初はタイムラインでイベントや感想を洗い出し、次に分類し、最後にKPTとしてまとめるといった寸法ですね。

やってみた感想

さて、実際に上記の方法で振り返り会を実施してました。

単純にKPTで振り返りを実施することと比較すると、以下のようなGood/Badがあったと感じてます。

■Good

• 時系列で振り返ることで、イベント・メンバーの感想を網羅して洗い出すことができた
• 感情グラフを作成することで、チームのモチベーションを高く維持するためにはどうすればよいのか？ ということまで検討できた
• 関わりが少ないチームメンバーについても、タスク内容やモチベーションを共有できた
• 振り返り会の中で、極端にネガティブな雰囲気とならなかった(※実施したチームメンバーが良かったこともありますが)

■Bad

• 事前準備が必要になる
• 実施自体に時間がかかる。とくに、タイムラインのレンジが広いほど実施時間がかかる

こうして考えると、チームメンバー間の共有や雰囲気作り、モチベーション設計の検討についてはかなり有意義な手法ではないかと思いました。

今回はアジャイル開発を行っているチームで採用したのですが、開発サイクルにとらわれず実施できる方法であると感じたので、ウォーターフォール開発でも数週間単位で積極的に取り入れたいですね。

また、Badについては、数週間単位で定期的に実行していればある程度緩和できるものとも思います。

まとめ

この記事では、チームの「振り返り」という部分に焦点を当てて、アジャイル開発とウォーターフォール開発での個人的な経験や取り組み、感想を紹介しました。

どうしても仕事が忙しいときには、目の前のタスクで頭が一杯になってしまい、視野が狭まりがちです。

そのような状況でも、チームでの「振り返り」は開発サイクルに関わらず、チームの改善や個人の成長につながる重要なことで、可能であれば数週間単位のスパンで取り入れたいものだと思ってます。

「振り返り」の手法・フレームワークについてはいろいろなものがありますが、今回実施した「タイムラインふりかえり + KPT」はやりやすくメリットも多いものでした。

まだまだ自分が知らない「振り返り」のフレームワークもあるので、今後どのような開発サイクルに関わる場合でも、チームの振り返りについては有意義なものとすべく勉強し続けたいものです。

最後まで読んでいただきありがとうございました。
※アイキャッチ画像はDALL-Eで生成しました

参考文献