Whiteboards for Jiraでレトロスペクティブを改善する

デジタルソリューション開発部 アプリチームの鈴木です。
アプリチームではJCBが提供する様々なサービスの開発・運用をしています。
サービスごとにチームを分けており、私はとあるWebサービスの担当をしています。

チーム全体の開発プロセスとして、スクラム開発を採用しています。
スクラム開発には毎スプリントごとにスクラムイベントと呼ばれる作業がいくつかありますが、今回はスプリントレビュー後に行う振り返りである「レトロスペクティブ」について、当チームで行ってきた改善の内容をご紹介します。

従来の方法

チームの立ち上がったタイミングでは、KPT法をベースとしたレトロスペクティブを以下の流れで行っておりました。

  1. あらかじめ、チームメンバはConfluence(Wiki)にKeep/Problemを記載しておく
  2. 今回のスプリントのふりかえり
    • 前回のTry内容をチェック
    • 記載されているKeep/Problemを確認
    • 議論したい事項に投票
  3. Tryのディスカッション
    • 投票数の多かった事項からフリーディスカッション
    • 次スプリントで改善したい内容を洗い出す
  4. Tryの具体的なアクションを決定
    • 洗い出した内容から、次スプリントで行う内容を決定
    • メンバ内で合意

具体的にはConfluenceにこのようなフォーマットを作成していました。
(Keepを例にしていますが、Problemも同様のものを作成して共同編集していました。実際は人数が多く、ひとつひとつの記載内容も長くなっていました)

この場合では投票数が最も多いBさんの「1. ●●勉強会が大変ためになった」から議論をしていきます。

課題点

この方法でもレトロスペクティブは行えるのですが、諸々の課題があります。

読みづらい

テキストベースで記載をするため、量が増えると読みづらくなってしまいます。
もう少し整理され、可能であれば直感的に見やすくできるとスムーズにレトロスペクティブが進むのではないか、と感じており、テキストベースではなくホワイトボードのような自由度の高いフォーマットが必要な状態でした。

投票数が分散してしまう

個人ごとに行を作成し、各々がKeep/Problemをレトロスペクティブ前に挙げていきますが、記載内容が被ってしまい、同テーマにもかかわらず投票数が分散してしまいました。
これにより「合計では投票数の多いテーマなのにディスカッションされない」事象が起きていました。

とはいえ、例えば「すでに他の人が書いている場合は同テーマで書かない」といったルールを追加するのは、活発な議論を妨げてしまうため、あまり適切ではありません。

議論が空中戦になりがち

口頭ベースの会話になってしまうため、論点の認識が合わなかったり、問題点が明確でないまま解決策を議論してしまい、より有効なTryを打ち出しにくい状況でした。

Whiteboards for Jiraの導入

このような課題を抱えるなかで、汎用的なホワイトボードツールとして、弊社の開発プラットフォームにWhiteboards for Jiraを導入しました。

Whiteboards for Jiraとは、ATLASSIAN Marketplaceで配布されているJira向けのホワイトボードツールです。
ホワイトボードツールの中でも高機能なだけでなく、弊社ではJiraを使ってプロジェクト管理をしていることから、Jiraとの親和性が高いことも魅力でした。

レトロスペクティブを改善する

Whiteboards for Jiraをベースにレトロスペクティブの改善をしました。

フレームワークを作る

現在では以下のようなフレームワークをもとにKeep/Problemを書いています。

利用イメージは以下のようになります。

サンプルをもとに改善点を解説していきます。

ジャンルと重要度の追加

今までのレトロスペクティブの内容から、Keep/Problemは大まかに「開発プロセス」「技術・スキル」「その他」の3つに分類ができました。
ジャンル分けを行うことで見やすいだけではなく、現状ではどのジャンルに課題があるのか直感的に把握できます。

また、同時に横軸には重要度を追加しました。
記入した個人の感覚で重要度を設定し、付箋の位置を変えています。
これにより重要度の高いKeep/Problemに集中しやすくなりますが、同時に「重要度が低いものでも記載しても大丈夫」といった心理的な安全性を生み出す効果もあります。
(実際「その他」の重要度が低めのものは昼食や最近の話など、雑談のタネとなるような個人のつぶやきが多く、盛り上がっている印象です)

同一テーマをまとめる

コメントや同じようなテーマを記入する場合は、すでにある付箋の下に対してWhiteboards for Jiraの「line」を使って関連付けをするようにしました。
下に追加をしていくため、横軸である重要度の影響は受けません。

同一テーマをまとめた上、投票の際は親となる付箋だけに投票するルールを決めることで、課題に挙がっていた投票数の分散を防ぎました。

議論用テンプレートの作成

議論が空中戦になってしまうのを防ぐため、このようなテンプレートを作成し、投票によって決まったテーマは各記入欄を埋めていく形でTry内容を検討していきました。

まずは「何が問題なのか」を定義し、その後に現状分析を実施して対応方針と具体的な内容を検討していきます。
論点が明確になるだけではなく、適切な課題解決プロセスを経ることで、問題明確化からTry実行へのロジックに筋道が通ります。
例えば長期的なTryを実践している際は、やることだけにフォーカスしてしまい「このTryはどうしてやっているのか」「そもそもの問題点は何だったのか」となる場合もありますが、その際に見返した際にも経緯が確認しやすくなりました。

実際に発生していた内容ですが、投票によって選択したProblemの「会議の実績がJiraに入力されていないことがある」には以下のように記載しました。

この場合はシンプルな記載内容になりましたが、問題が複雑な場合は「現状分析」や「課題明確化」がもっと長くなることが多いです。

アジェンダを改善する

作成したフレームワークをもとにアジェンダを再検討しました。

  1. あらかじめ、チームメンバはWhiteboards for Jiraの該当ボードにKeep/Problemを記載し、投票を済ませておく
  2. 今回のスプリントのふりかえり
    • できたこと、できなかったことを確認
  3. Keep/Problemの確認
    • 議論が必要ないレベルのものはその場でTryに追加
    • この間に再投票したい場合は票を動かす
  4. 投票数をもとに議論内容を最大3つ決定
    • 各メンバは議論したいテーマを選ぶ
  5. テーマごとにブレイクアウトセッションを設定し議論
  6. 各ブレイクアウトセッション内で議論した内容を全体に共有
  7. Tryを整理して合意
    • 場合によっては「タスク」として付箋からJiraのバックログに直接起票

改善前では時間の許す限り、投票数の多いテーマから議論をしていましたが、最大3つに絞ることによって少人数になり議論が発散しすぎず進みやすくなりました。

また、各メンバがテーマを自分で選択することによって、興味のある事柄に関して議論ができ、改善前よりも発言がストップせずに濃密な議論が行えています。

以上、当チームで行っているWhiteboards for Jiraを利用したレトロスペクティブの改善についてのご紹介でした。
このツールをベースにさまざまな改善をしていきましたが、なによりもホワイトボードと付箋がベースになっていることから、わちゃわちゃと楽しくふりかえりができるようになったことも大きな改善点かもしれません。

Whiteboards for Jiraはレトロスペクティブだけでなく、各課題の検討やロードマップの作成などにも利用しており、我々の開発に欠かせないツールとなっています。
興味のある方はぜひ導入を検討してみてはいかがでしょうか。

最後になりますが、JCBでは我々と一緒に働きたいという人材を募集しています。
詳しい募集要項等については採用ページをご覧ください。


本文および図表中では、「™」、「®」を明記しておりません。
Jira, ConfluenceはAtlassianの登録商標または商標です。
Whiteboards for JiraはSpartez Softwareの登録商標または商標です。
記載されているロゴ、システム名、製品名は各社および商標権者の登録商標または商標です。

©JCB Co., Ltd. 20︎21