こんにちは！ 二人しかいないアジャイル推進室のメンバーの一人、エンジニアの森住（@t_morizumi）です。
アジャイル推進室とはなにか、については @kissy による以下のブログをご参照ください。
（当初はアジャイル推進室（仮）でしたが、「もう（仮）いらないんじゃね？」との声を受けて現在は（仮）が外れています）
今回は表題の通り、アジャイル推進室としてリモートでのタイムライン振り返り実施をお手伝いしたので、そのときの事前準備 → 実施 → 事後について書いていきます。
一ヶ月ほど前に出た「コロナの時代の付箋ワークショップ」という CTO の芹澤によるブログで、タイムライン振り返りについて軽く触れられているのですが、今回はより踏み込んだ内容となっています。
経緯
上記の芹澤によるブログに、大型機能開発がひと段落したタイミングでタイムライン振り返りを開催した、という記述があるのですが、ちょうどその一ヶ月後にべつのチームから大型機能がリリースされました。
その開発を行ったチームから、当該機能の開発プロセスに課題を感じたため振り返りをしたい、タイムライン振り返りという手法を試してみたいという相談を受け、実施の手伝いをすることになりました。
そもそもタイムライン振り返りとは
タイムライン振り返りとは、長期に渡るプロジェクト等の振り返りで情報を収集するために使われるものです。
プロジェクトの時系列に「事実」や「感情」をマッピングして、まさしくタイムラインを作り上げていくことで、そのプロジェクトでなにが起こっていたのかという全体像を描き出す助けとなります。
事前準備編
事前準備はタイムライン振り返りを行うチームのマネージャーと協力して進めました。 それでは早速、やったことを書いていきます。
目的とゴールの設定
まずはファシリテーションを行うマネージャーと参加者全員の目線を合わせるために、タイムライン振り返りの目的とゴールを設定しました。
今回は以下のように設定しています。
- 目的
- 時系列で出来事を振り返ることにより、今後も続けていきたいこと（Keep）と課題（Problem）を事実ベースで収集する
- ゴール
- 今後も続けていきたいこと（Keep）が収集されていること
- 課題（Problem）が収集されていること
目的、ゴールともに「収集」に主眼を置いています。
手がかりとなる情報から連想することで記憶を活性化して思い出すことができる、という人間の特性を利用して、比較的長期に渡るプロジェクトの振り返りであっても十分な情報を集められる、というのがタイムラインの特徴です。
そのため、タイムラインが得意とする「収集」にフォーカスする場であることを参加者全員に理解してもらうことを意図した目的とゴールを設定しています。
タイムライン振り返り実施後のアクションの設定
タイムラインを作っただけでは振り返りとしては片手落ちです。収集した情報を改善へとつなげていく必要があります。
今回は以下のように設定しました。
- 収集した今後も続けていきたいこと（Keep）が継続されるようにする
- 収集した課題（Problem）に対する改善策（Try）を策定し、実施する
時系列の収集
先ほどタイムラインの特徴として、手がかりとなる情報から連想することで記憶を活性化して思い出す、と書きました。
その「手がかりとなる情報」としてタイムライン振り返りを行う対象となる期間の大まかなイベントをあらかじめ収集しておきます。
例えば、以下のようなイベントを収集します。
- 12/E 仕様共有
- 01/09 設計開始
- 01/21 デザイン共有
- 01/31 実装開始
Miro にタイムライン振り返り用のボードを作成
タイムライン振り返りはオンライン開催を予定していたため、ホワイトボードの代替ツールとして Miro を利用しました。
実際に参加者が作業をする前の、まっさらな状態は以下の通りです。
真ん中がタイムライン振り返りを行うメインとなるスペースで、横軸が収集した時系列、上半分によかったこと（Good）、下半分によくなかったこと（Bad）を分類できるようにしています。
一番下は Good / Bad に分類する前のできごとをストックしておくスペース、一番上はプロジェクトの進行に合わせてメンバーの気持ちがどのように変化したのかを描くためのスペースとしました。
Miro に時系列ごとのできごとを収集
参加者全員に、上に貼った画像の一番下のスペースに思い出したことを書き出しておいてもらうよう依頼しました。
実際に出てきたものは、例えば以下のようなものでした。
- API I/F とデータモデルの設計を分けて実行できた
- ロジックのレビュー会で理解が進んだ
- 時系列計算に関する抜け漏れ
- 計算の軸が PdM と認識合ってなかったことが判明
実施編
それでは、実施の際にどのように進めたのかを書いていきます。
参加者
- PO（プロダクトオーナー）
- エンジニア
- QA
- デザイナ
ツール
- Miro（ホワイトボードの代替として）
- Zoom（ビデオ会議ツールとして）
タイムテーブル
- 目的とゴール / 進め方の共有（10 分）
- できごとを Good / Bad にふりわける（30 分）
- ふりわけた Good / Bad から Keep / Problem を洗い出す（60 分）
- メンバーの気持ちの変化をグラフにする（15 分）
- 次のアクションについて共有 / まとめ（5 分）
最終的なアウトプット
文字で書いてもわかりづらいと思うので、先に最終的に Miro がどういう状態になったのか、という画像を貼っておきます。
一番上に参加者の気持ちの変化（モチベーションが上がった / 下がった、など）を表した線が、真ん中にふりわけられた Good / Bad とそこから洗い出された Keep / Problem が貼られています。
付箋から付箋へと伸びる線はできごと同士の関連を表しています。
付箋の色についてはそれほど厳密な運用をしてはいなかったのですが、ざっくり黄色が Good / Bad 、水色が Keep 赤色が Problem となっています。
一番下のできごとを書き出すための場所は、すでに Good / Bad にすべて分類しているため空となっています。
それでは以下、実施に際して行ったことです。
目的とゴール / 進め方の共有
はじめに事前準備編で作成した、タイムライン振り返りの目的とゴールを改めて共有しました。
あくまで改善のための情報を「収集」する場であることを共通認識とします。
できごとを Good / Bad にふり分ける
次に、事前に Miro の一番下のスペースに書き出しておいてもらった時系列ごとのできごとをひとつずつピックアップして、参加者で話し合いながら Good / Bad にふり分けていきます。
ふり分けるにあたって、このできごとは Good / Bad 両面あるよね、ということもあると思いますが、その際は付箋を新しく作って Good / Bad それぞれによかった面、よくなかった面を書いていきましょう。
Good / Bad から Keep / Problem を洗い出す
時系列ごとに Good / Bad をふり分けることができたら、今度はそれらを概観しながら続けたいこと（Keep）と課題（Problem）を洗い出していきます。
この時点で色々な Good / Bad が視覚的に捉えられる状態になっているので、例えばプロジェクト中盤にあるこの Bad と終盤にあるこの Bad は関連していて、抽象化するとこういう Problem だよね、というような議論ができるようになっています。
メンバーの気持ちの変化をグラフにする
プロジェクト中にメンバーの気持ちがどのように変化していったのか、ということをグラフにして表現してもらいます。
言葉で説明するよりも絵を見た方が早いと思うので、画像を再掲します。
左端がプロジェクト開始時で、右端がリリースのタイミングです。
それぞれに線を描いてもらったら、一人ずつ自分の気持ちの変化について共有してもらいます。ここで下がったのはこういう理由で、ここで上がったのはこういうできごとがあったから、というようなイメージです。
一緒に仕事をしていても、意外とチームメンバーの気持ちがどのように変化しているのか、ということを知る機会は少ないものです。それを知ることで、次回チームとしてよりよく働くために必要なことはなにかを発見するきっかけにもなりますし、気持ちの変化からプロダクト作りそのものへの課題が見つかることもあります。
たとえば、上の画像の赤線は PO が描いたものなのですが、プロジェクト序盤に高かった気持ちが、終盤になるにつれて下がっていき、リリースのタイミングで急に上がっています。
その理由としては、プロジェクト全体を通して UI を伴った、動く状態のプロダクトを触れる機会が少なかったから、というものでした。
アジャイルソフトウェア開発宣言には、
動くソフトウェアこそが進捗の最も重要な尺度です。
という原則があります。
それに照らして考えてみると、進捗の最も重要な尺度である動くソフトウェアを終盤まで触ることができなかったことは課題として捉えることができそうです。
今回タイムライン振り返りを行ったチームでは以前にアジャイルに関する勉強会を行っていたこともあり、プロダクトの可視性に関する以下の画像のことを思い出した、という声も上がりました。
Agile vs. Waterfall: Product Visibility | #Agile #Scrum pic.twitter.com/aYN9PNCEGX
— Marc Hemerik (@MarcHemerik) June 19, 2016
次のアクションについて共有 / まとめ
最後に、Keep / Problem を収集したら終わりではなく、
- 収集した今後も続けていきたいこと（Keep）が継続されるようにする
- 収集した課題（Problem）に対する改善策（Try）を策定し、実施する
これらをやっていきますよ、という共有をしてまとめ。
以上が今回開催したタイムライン振り返りの流れです。
感想
できごとを Good / Bad にふり分ける際は、ある人が Good だと思って書いていたものが話し合ってみたら Bad になる、というようなことが何度か発生して、様々な役割を持った参加者全員で色々な側面からできごとを見てみることの意義を感じられました。
Good / Bad から Keep / Problem を洗い出す、のセクションでは、
色々な Good / Bad が視覚的に捉えられる状態になっている
プロジェクト中盤にあるこの Bad と終盤にあるこの Bad は関連していて、抽象化するとこういう Problem だよね、というような議論ができる
と書いたのですが、視覚的に捉えて関連性を見出す、ということができるのはやはり付箋とホワイトボードというツールの強みだと感じられました。オンラインであってもその恩恵は受けられるので、Miro のような仮想的にホワイトボードが作れるツールを利用するとよいのかなと思いました。
また、タイムラインの特性上様々な時点で発生した問題を俯瞰して見ることができるため、実は一つの Problem が様々な Bad の元になっている、ということも把握できました。
具体的には、今回振り返りを行ったチームのプロダクトを「小さく作りづらい」という Problem で、それが Pull Request の肥大化やエンドツーエンドで触れる機能を少しずつ作ることが難しい、といった Bad の元になっていました。
その Problem については、技術顧問の @willnet さんとも協力して「小さく作れる」プロダクトにすべく鋭意改善中です。
We are Hiring!
SmartHR では急なリモート移行などの環境変化があってもテクノロジーと創意工夫でハックしていける方を募集しています！
選考フローも全てオンラインに対応されていますので、安心してご応募いただければと思います。
◆PdM採用HP
◆エンジニア採用HP
