皆さんこんにちは、パーソルP&Tの永井です。
 
コロナ禍におけるリモートワーク推進によってチーム内のコミュニケーションが大きく変化した昨今。システム開発に携わる方は特に、プロジェクトを運営するうえで難しさを感じることは少なくないと思います。

特に、プロジェクト内のチームビルディングや振り返り、皆さんどうやっていますか？試行錯誤の日々ではないかと思います。
 
私がこれまで所属してきたプロジェクトでは、コロナ禍以降フルリモートで業務を行ってきました。そこでこの記事では、私たちのプロジェクトチームが実践してきたチームビルディング/ふりかえりの手法を紹介していきます。

ドラッカー風エクササイズ(*1)

所要時間：1〜2時間
実施タイミング：
　　…1回目：チーム発足時、新メンバー加入時
　　…2回目以降：プロジェクトの節目(設計・製造工程完了後など)
使用したツール：Excel
ドラッカー風エクササイズは、『アジャイルサムライ』の著者ジョナサン ラスムッソン氏が提唱したチームビルディングのためのフレームワークです。

 進め方

1. チームメンバー全員が以下の4つの質問に対してExcel上で事前に回答する。

   1. 　自分は何が得意か?

   2. 　自分はどのように仕事をするか?

   3. 　自分が大切に思う価値観は何か?

   4. 　チームメンバーは自分にどのような成果を期待していると思うか?

2. 回答内容を各々が共有する場を設け、メンバーの発表に対して他のメンバーがフィードバックをする。

実施のポイント

メンバー間でお互いが得意としていることや価値観を共有することで相互理解を深め、チームの心理的安全性を確保することを目的にしており、主にチーム発足時や新メンバーが参画するタイミングで実施するのが効果的とされています。

 工夫したこと

基本的な内容は以上ですが、私たちのプロジェクトではさらに3つの要素を加えてアレンジしています。

1.   「他のメンバーが実際に期待していること」を質問に追加(*2)

上記4つの質問は自分自身についてのものですが、これ対し他のメンバーからはどう見えているのかをフィードバックすることでより深い相互理解、期待のすり合わせができます。
実際にやってみて、私自身も自分では想定していなかったような期待が他のメンバーから挙げられていて、プロジェクト内での立ち回りについて考え直すきっかけになりました。

2.  「自分が不得意なこと」などの「ネガティブ面」についても共有する

『カイゼンジャーニー』の著者である市谷 聡啓氏によって紹介されている手法を参考にしました。(*3)通常のドラッカー風エクササイズを「A面(ポジティブ面)」とし、それとは逆の「B面(ネガティブ面)」について自分自身の所感、フィードバックを共有します。

-       自分は何が不得意なのか?
-       自分はどのような(よくない)仕事をしてしまうのか?
-       自分の地雷(踏み込まれると爆発すること)は何か?
-       チームメンバーの期待に応えられなかった事件は?
-       チームメンバーがフォローできること (A面の「他のメンバーが実際に期待していること」と対応するよう独自に追加)

自分が陥りそうなミスを自覚し、お互いがフォローできるようにすることが狙いです。
私たちのチームではA面とB面の両方を実施しました。ちなみに、私自身の回答がこちらです。

3.   過去の自分の回答内容と現在の自分を比較する

先述の通り、ドラッカー風エクササイズはチーム発足時に行うのが効果的とされていますが、一方で実際に一緒に働くなかで分かるメンバー/自分自身の新たな強みや弱み、変化もあるでしょう。そのため、設計完了・製造完了などのタイミングでこのような変化や気づきを全体にフィードバックする機会をつくることで、お互いの成長や改善点を相互理解で一層深まることが期待できます。
 
我々のチームでは、Excel上に自分自身の変化や新たな気づきを赤文字で事前に追記し、後述するふりかえりの場などで追記内容の発表→フィードバックをする時間を設けていました。

タイムラインを使用したふりかえり

所要時間：1.5〜3時間(前回の振り返りから2か月以上スパンがある場合、3時間以上確保するのが好ましい)
実施タイミング：1ヶ月に1回程度
使用したツール：Miroなどのホワイトボードツール

タイムラインとは「時系列」を示す言葉ですが、私たちはその時々の出来事や感情を付箋で一覧化しておき、主に中長期のスパンでふりかえりに活用するということをしていました。実施タイミングに「1ヶ月に1回程度」と記載しましたが、実際には設計・製造など各フェーズの真ん中と終わりで最低2回は実施するイメージです。

進め方

以下の手順で行います。私たちのチームではMiroを使ってタイムラインを作成しました。以下に実際の画面キャプチャを載せますので、併せて参照いただければ幸いです。

1.  (事前準備)時系列の線を引き、プロジェクトのマイルストーンとなる出来事を順番に書き出しておく。(画像内の黄色い付箋)

2. その時系列の中で起きた「良い出来事、良い感情」をGood(ピンク)の付箋に、「悪い出来事、悪い感情」をBad(青)の付箋に書いて、各メンバーに貼り出してもらう。

3. 貼りだされた付箋から良かったこと、悪かったことの分析を行う。その際、皆が挙げた事象のうち付箋の数が多いものについて、ドットシールなどを活用して可視化し、深堀する項目の優先順位を決める。(画像では👀のシールを使用)

4. 分析した結果を「続けたいこと」、「改善したいこと」、「改善策」に落とし込み、以降の業務に生かす。

この手順でふりかえりを進めると最終的にこのようなタイムラインができます。

工夫したこと

 1.   重複/類似した付箋同士をまとめておく

自分が書こうとしている内容について、すでに付箋が貼られている内容と重複/類似があった場合にも付箋を貼ってもらうようにしました。重複数、類似数がそのままその話題に対するチームの関心度として表現されるためです。Miroであれば付箋を自由に動かせるので、各付箋の関連度合いや興味度を可視化できるというメリットがあります。

2.   「改善したいこと」と「改善策」の関連性を線でつなぎ、因果関係を可視化する

改善したいこと(Problem)と改善策(Try)の関係は1:1とは限らず、1つのProblemから複数のTryに繋がることもありますし、逆もまた然りです。ProblemとTryの因果関係を可視化することで各Tryの取り組みがどういった効果を生むのかが整理され、プロジェクト内での共通理解が深まります。

 3.   次の振り返りで前回の「改善策」が機能したかどうかを確認する

ふりかえりは1回きりで終わらせず、冒頭で書いたようにプロジェクトの各フェーズの中間地点、終了地点の少なくとも2回行うことでカイゼンのサイクルを回すことを大切にしていました。

前回のふりかえりで決めた改善策をやってみて効果があったかどうか、効果がない場合はその施策を続ける必要があるかなど、次のふりかえりの冒頭で確認することをお勧めします。

このとき、2番のポイント(ProblemとTryの因果を線でつなぐ)をやっておくことで、Tryに紐づく各Problemが解決できているかどうか細かくチェックできます。 

4.   優先度の兼ね合いで「改善したいこと」として拾いきれなかった課題を忘れ去られないようにする

ふりかえりを行った結果出てきたチームの課題について、時間内に全て検討することが難しいケースも出てくると思いますが、優先順位が低く議論できなかった項目については、Backlogなどのチケット管理ツールやTrelloにまとめておき、次のふりかえりの際に参照することで課題が滞留するのを防ぐことができます。

 カンバン形式のふりかえり

所要時間：30分〜1時間
実施タイミング：1〜2週間に1回
使用したツール：Trelloなどのカンバンツール

前章のタイムライン方式よりも比較的短い期間のスパンでふりかえりをするなど、もう少しライトに実施する際にお勧めなのがこの「カンバン形式のふりかえり」です。
カンバンとは、もともとトヨタ自動車発祥の生産管理方式ですが、ソフトウェア開発の管理によく使用されるフレームワークです。お互いの作業項目やキャパシティ等を視覚化し、皆が状況を確認できることが特徴です。
進め方は時系列順を使わないこと以外概ねタイムライン方式を同じです。

 進め方

1. (事前準備)「前回のアクションの確認」「良かったこと」「悪かったこと」「ネクストアクション」のグループを作る。

2. 各メンバーにその週の良かったこと、悪かったことを付箋（カード）に貼りだしてもらう。

3. 深堀したい付箋（カード）にドットシールで投票、投票数が多い順に並び変えて優先順位を可視化する。(Trelloの場合は「ラベル機能」の活用がお勧めです)

4. 優先度の高い順にネクストアクションを決める。

5. (次回ふりかえり時)前回のネクストアクションに効果があったか確認する。

さいごに

今回は私が経験してきたプロジェクトにおけるチームビルディング/ふりかえりの手法についていくつか紹介してきました。

これらの手法は「アジャイル（スクラム）開発、プロダクト開発」の文脈でよく出てきますが、かといってその他の形式では流用できないということでは全くないです。

「アジャイル」と「ウォーターフォール・受託案件」を対の概念として捉えられることがありますが、「アジャイル」は柔軟に効率よく開発サイクルを回すための”アティチュード(態度)”なので、ウォーターフォール/受託案件のプロジェクトでも取り入れることはできると実感しています。

この記事が、みなさんのチームが成果を最大限発揮できる少しもの手助けになれたら幸いです。

※永井さんが所属する、DXソリューション統括部 NewITソリューション部の記事はこちらから

弊社のTechコミュニティにご登録頂いた方には、今後もこのようなエンジニアブログの情報や、イベント開催情報をいち早くお届けいたします。SNSをフォローする感覚でお気軽にご参加ください。