この記事は、ニフティグループ Advent Calendar 2023 9日目の記事です。

こんにちは。会員システムグループの三浦です。とあるプロダクトの開発チームリーダーを担当しています。
今回は、チームで行ったふりかえりで特にやって良かったと感じた、フォースフィールドアナリシスについて紹介します。
チーム背景の詳細についてもある程度書いています。ぜひあなたのチームが同じ状況に陥っていないか、その時どうすればいいのか、参考にしていただければと思います。

ふりかえりをする前のチームの現状

私たちのチームは、開発メンバーが自分を含め4人。当時、新規プロダクトのWEBシステム開発にアサインしていました。
元々の見積もりでは開発開始から約1ヶ月程度経ったタイミングで「そろそろWEB、API、データベースの最低限の機能は構築して、開発用のインフラも作ってみて、申込は試せるかな？」くらいのペースだったのですが・・・。
実際にはようやく1つ目のAPIがローカルで動くかという頃で、インフラ構築も、WEB画面も用意できませんでした。
この進捗遅れについてはバーンダウンチャートを作っていたおかげで気づくことができました。

青色の線が順調に作業ポイントを消化できていた場合の線、赤色が自分たちの消化した作業ポイントの線です
どうみても青色の線と赤色の線が乖離しています。消化予定のポイントとはかなりの乖離がありました。明確に見積もりから進捗が遅れている状況です。

ふりかえりの場を作る

さて、バーンダウンチャートによってチーム内で「これは遅れているという状況なんじゃないか？」という認識ができたところで、チームのふりかえりの時間になりました。
メンバーは皆なんとかして遅れを取り戻さなければ！と思っていましたが、こういった悪い状況を改善するアクティビティをやる前には、チーム全員でとある認識が必要です。

ふりかえりでは課題に対しての改善を探しますが、その時に「もっとこうしていれば」という発想がどうしても生まれます。
この発想のよくないところは、他人に対しても自分に対しても、過去の原因に目を向けさせてしまうところです。私たちは今開発の遅れを取り戻したいと考えており、それは未来の話なのです。

まず最初に読み上げたのは、森 一樹氏が作成・公開された「ふりかえりカタログ」の1番目の項目にもある「Norm Kerthの最優先指令」です。

その後、「非難をしないこと」というルールに賛同できるかを全員に問いました。
儀式的なものに感じられるかもしれないですが、この確認を行うことで、課題に対する原因探しから未来を改善させることに意識を集中できるようになります。

フォースフィールドアナリシスの実施

振り返りをやる場を設定したら、次にメインのフォースフィールドアナリシスを行います。

フォースフィールドアナリシスは、チームが置かれている現状、課題に対して何が改善の要因となるのか、何が抑制の要因となるのかを列挙して分析する手法です。
列挙した要因は矢印の太さによってその要因の強さを相対的に表現し、どうすればより改善の要因を強め、どうすればより抑制の要因を弱めることができるのかを考えます。
実践した手順は以下の通りです。かける時間についても設定していますが、多少のブレはあります。全体の時間は40~50分程度ですが、余裕を持って1時間確保してもよいでしょう。

1. テーマ(現状)を決定(3min)
   この場で分析したい現状を決める。
2. 改善を促進する要因を書き出す(8min)
   この現状を改善したい、となったときに、現状を変えるようなきっかけ、要因、行動、理由を書き出す。
3. 書き出した要因の重みづけ(4min)
   書き出した要因に対して、どれがより効果が高いかを上から順に並べてみる。
4. 改善を抑制してしまう要因を書き出す(3min)
   この現状を改善したい、となったときに、現状を維持、悪化させてしまう要因、行動、理由を書き出す
5. 書き出した要因の重みづけ(4min)
   書き出した要因に対して、どれがより影響が大きいかを並べてみる。
6. 最も促進する要因・抑制してしまう要因を改善するアクションのアイデアだし(13min)
   • 改善を促す要因については、それをどうすれば引き起こすことができるか
   • 改善を抑制する要因については、それをどうすれば止めることができるか
7. アクションの決定(5min)
   • 出てきたアクションに対してドット投票を行い、次のアクションを決める

私たちのチームが書き上げたフォースフィールドアナリシスは以下の通りです。ツールはGoogle Jamboardを使用しました。

全体の進捗が遅れていることを改善すべき現状と置き、まずはそれに対しての改善要因と抑制要因をカードで列挙します。その後、緑やオレンジのカードで出てきた要因をさらっと確認しました。
太さの違う矢印を引いていくことでどの要因が強いのか、どの要因が弱いのかを可視化するのが本来の手順なのですが、カードで列挙したため、カードを上から影響度が強い順で並べてみました。
すると複数のカードが同じ「知らないこと・不確定なこと」に関する要因になっていることがわかってきます。

今回では、開発が始まってから分かる不確定な要素が多く、それを出てくるたびに再検討し直してチームで合意を取る、というのを繰り返していて、それによって開発の進捗が遅れていた・・・ということがアクティビティで浮かび上がりました。

そのため、不確定要素の多さを強い要因としてグルーピングし、それに対する改善行動をピンクのカードで深掘りしていくようにします。
ふりかえりでは実現確率を高めるためになるべく具体的な行動を1つ決めることを目指します。
今回は、私たちが忙しさを理由に出来ていなかったリファインメント(プロダクトバックログアイテムに対する見直し)を実施し、タスクのゴールや詳細を詰めることを決めました。
時間についても2時間を制限とし、次のプランニングから早速組み込みました。

ふりかえりの効果

リファインメントを実施することにより、開発チーム内にあった知識の偏りがある程度解消され、メンバーそれぞれが主体的に実装方法やテストを検討することができるようになりました。またプロダクトバックログアイテムに詳細な情報が集約されるようになり、作業量の見積もり制度も向上しました。
結果的に、元々見積もっていた作業量からはタスクの詳細化によってさらに作業量が増加しましたが、その詳細をチームメンバーが把握できていることによる案件全体のポイント消化効率が上がったことにより、チームの生産性は確実に上がりました。

青色の計画を示す線の角度がなだらかになっているのは作業量が増加している兆候ですが、赤色の実作業の線がその作業量を超える角度で緩やかになっているため、良い兆候が見えるようになりました。

ただこれだけで全てが良くなるというものでもなく、実際にはこの後にもステークホルダーとのコミュニケーション不足による手戻りや突発的な他案件との調整など、さまざまな課題に立ち向かうことになるのですがそれはまた今度の話とします。

さいごに

チーム開発はうまくいかない場面も多々ありますが、それを乗り越えるのもまたチームです。課題のないチームなどないですが、少しずつ行動を変えていくことでチームは成長していける、それを改めて感じられる出来事でした。ブログを読んでいる皆様のチームも多かれ少なかれ課題があると思いますが、こうした解決事例を参考にして、よりよいチーム開発を作っていただければと思います。

ニフティではスクラム開発が主な開発手法として浸透しています。こうしたチーム活動などに興味のある方に対して技法を教え合うような場も設定されていますし、手助けができる環境です。こうした事例に興味を持った方がいらっしゃいましたら、ぜひ以下のリンクからお気軽にご連絡ください。