One for All, All for One の振り返りを目指して

こんにちは！夫家族の影響で万博にハマり、気がついたらなんだかお財布が軽くなってしまったこまっちゃんです。お財布もウキウキ楽しんで、お口が緩んでしまったのかもしれませんね。

さて、今回はDWSに入社して３年半、これまで行ってきたチームの振り返り経験を元に、現在行き着いている振り返り方法をご紹介したいなと思います。

振り返りのタイミング

さて、振り返りはどのタイミングで行うのがいいでしょうか。

私たちのチームは複数プロジェクトを１チームで回しているため、チームの振り返りとプロジェクトの振り返りは別々に行っています。具体的には以下の通りです。

チームの振り返り

• レトロスペクティブ：２週間に１回実施
• 褒め合い：１週間に１回実施

プロジェクトの振り返り

• プロジェクト期間中は、プロジェクト朝会中に現状の課題を整理
• プロジェクト終了後に全体の振り返りを実施

それぞれお話しできればと思います。

チームの振り返り

レトロスペクティブ

では、まずはチームの振り返りですが、スクラム開発の「レトロスペクティブ」を実施しています。2週間を1スプリントとして、直近の2週間をチームとして評価していきます。

チームの結束力をより強く・心理的安全性を高く、結果的にパフォーマンスを良くしていくことを目的としているので、簡単なルールを決めています。

• 自分や他者を責めるような場ではない。チームをより良くしていくための振り返りとアクションを決める場であるという意識を持って臨む
• 個人の課題はチームの課題。チームでシステム的に解決できたり、実は他の人も同じことで悩んでいることもあるので、まずはオープンマインドで臨む

やり方は非常にシンプルです。次のKPTA（Keep Problem Try Action）テンプレートを利用して、枠内に意見を書いた付箋を貼っていきます。

私たちは毎回1時間かけて実施しています。

1. 前スプリントで決めていたアクションが実施できていたかの振り返り（5分）
2. 直近の２週間で実施してよかったこと、継続したいことの洗い出し（15分）
3. チームとしての改善点の洗い出し（15分）
4. 議論したい改善点に対して投票する（2分）
5. 改善点に対するアクションのアイディアを出し合う（15分）
6. 次スプリントに向けてのアクションの決定（8分）

まずは前スプリントで決めたアクションをきちんと今スプリントで実施できていたか？を振り返ります。できていないものがあれば、例えばアラームを設定したり、必ず毎日見る場所に記入して忘れないようにするとか、システム的な対策を講じます。

次に、今スプリントでのよかった点や改善点について出し合います。相手の意見を否定せず、ガンガン感じていたことを書き出していきます。

時間が限られているので、❹では❸の中から、❺で話し合いたい改善点を投票で決定します。そして、❺では決定した議題（2〜3個）についてアイディアを出し合い、❻でアクションを決定します。なお、特に改善点についてとことん話し合った方が良い場合は、別枠でミーティングを設定することもありますよ。

最後に、改善に向けてアクションを決めて、レトロスペクティブは終わりです。

褒め合い

こちらは以前別チームで実施していて、なかなか良いなと思って私たちのチームでも最近導入しました。

金曜日に１週間を振り返り、「できるようになったこと」「チームメンバーに感謝したこと」「継続できていること」「すごいと感じたこと」などを自他問わず書き出していきます。

こちらもテンプレートを使用していますが、縦列が自分のレーンにです。
私は緑色ですが、自分の列に3個、他の方々の列にもそれぞれ褒めポイントを1〜3個書き込んでいます。仲が良いチームだったので、私生活での改善点まで書いて和気藹々と振り返っていました（笑）

新人さんや社歴が浅い方など、チームに貢献できているか不安を感じている方や、今後のキャリアを見つめ直すために自分のいいところを客観的に振り返りたい方に向いています。

私自身なかなか自分に自信が持てず、エンジニアとしての立ち位置が中途半端に感じて不安を抱えた時期が長かったのですが、この会を通して思っていたよりも皆に貢献できていたことを知ることができました。現在は当時とは別のチームにいますが、自分を客観的に捉えられるようになったので、以前よりもずっと楽しく仕事できていますよ。

そうした個人の良い変化というメリットもありますが、何より「いざ褒める！」となるとすごく気恥ずかしいです。褒める方も、褒められる方も。そこをあえて文字や声で伝えることで、チームメンバー同士の少し距離が縮まるので、雰囲気がとても良くなりますよ。

レトロスペクティブでも、忌憚ない意見が出てきやすくなるので相乗的に効果があると思います。

プロジェクトの振り返り

プロジェクトの振り返りは、プロジェクト中・プロジェクト後に分けて実施しています。

１チーム１プロジェクトであれば、上記のレトロスペクティブ（ウォーターフォールであれば定期的なチームミーティング）でスプリントの振り返りをするのが良いと思いますが、私たちのチームは複数プロジェクトを抱えているので、プロジェクト固有の改善はプロジェクトの朝会で行っています。具体的には、

1. クライアントを含むプロジェクトの朝会に参加
2. ❶で得られたFBや意見、今後のタスクを踏まえつつチーム朝会を実施

という流れです。進捗は❶で話しますが、さらに踏み込んだ会話を❷で行います。大体15〜30分程度で、以下のような流れで実施しています。

1. 進捗と課題点の詳細報告
2. クライアントミーティングを踏まえた作業分担の見直し
3. 潜在的リスクの洗い出し
4. プロジェクトの健全性についての見直し

最後の１点が特徴的かと思うので、少しご説明します。

私たちは受託でプロジェクトを受けているのですが、それはクライアントと上下関係という立場ではなく、「パートナー」という立場でクライアントの皆様と協奏することを理想としています。そのため、クライアントが求める以上の質やスピードでサービスを提供するべく、日頃から課題がないかアンテナを張っています。

それにはチームの健全性向上も含まれています。クライアントの皆様もチームとして考え、プロジェクトがより良く回っていくための提案事項や課題点をまとめて、翌日以降の朝会で議題としてご提案差し上げることもあります。

今後は、この活動の結果同一のタスクのパフォーマンスがどの程度改善したか、ポイント見積り等で測っていけるといいなと考えています。

QCD（Quality Cost Delivery）

ポイントの話が出たので、ここでQCDの話をしたいと思います。

プロジェクトの終わりには、KPTおよびQCDを用いて振り返りを行います。KPT（Keep Problem Try）はレトロスペクティブで実施しているKPTAとほぼ同じなので割愛しますね。

QCDも有名な指標です。「品質」「コスト」「納期」について、可能な限り定量的（難しい場合は定性的）に振り返りを行います。

品質

品質は言わずもがなですね。最も大切で優先されるべき要素です。以下を中心に評価しています。

• クライアントからの評価や、可能であればユーザーの評価
• 各スプリントでのポイント遷移を振り返り、見積りの甘さや品質への影響を評価
• 機能要件以外の要素（＋α要素）の実装程度
• テストの品質（網羅性ややり方）

私は今SaaSエンジニアなので、特にポイントでの振り返りは大切だと考えています。SaaSの場合はゼロイチ開発よりも経験値を積みやすいので、同様のタスクであっても経験を経るごとにポイントの値が小さくなることが想定されます。逆に小さくなっていない場合は、課題の特定と今後のアクションを策定していく必要があります。

コスト

コストは固定されているため、残業期間の程度（有無）で評価することが多いです。また、実装内容に対するコストの妥当性も評価して、次回以降のプロジェクトへの反省に繋げることもあります。

納期

こちらはシンプルに、納期を遵守できたか/早期達成できたかで評価しています。

今のチームはまだ歴史が浅いチームなので、上記のやり方のほかにも創意工夫しながらより良いチームを目指して動いていければと思います！

なぜチームの振り返りを行うのか

最後締める前の余談として。皆さんはチームの振り返りは何のために行うと思いますか？

私はDWSに入社するまで、プロジェクトの進捗のためだと思っていました。きっとそれは間違いではないです。しかし、プロジェクトや数字ばかりが目的になってしまうと、弊害があるようにも感じています。

そう思うようになったきっかけは前職にありました。

当時私は新薬開発に従事していて、治験を実施する病院のサポートを実施していました。治験薬の有効性や安全性を確認するためには、一定数以上の患者さんのデータが必要です。そのため、治験を実施する各病院は、契約時に提示した患者数以上の患者さんを治験にアサインする必要があり、我々はそのサポートを行います。

チームの振り返りはいつもこういう内容でした。

「今週はチーム全体で２名アサインできました」
「しかし、今の時期の目標数からは５名足りません。６月までに後２人、いえ、１人でいいのでアサイン可能な病院はありませんか？」

チーム会議ではチームの改善点は議論されないので、各々が我流で試行錯誤しつつ病院をサポートしていました（共通のテンプレート等はありましたが）。皆が病院をサポートするやり方に悩み、最悪チームリーダーと病院間の圧力に挟まれていくことになります。焦って開発サイド都合のサポートをした結果、病院側の不興を買って他部署に異動した人もいました。

もし、チームの振り返りで成果以外の視点が議論されていれば、メンバーの充実感や自信、質が向上し、結果的に治験を実施するチームの品質も上がっていたのでは、と思わずにはいられません。

最後に

いかがでしたでしょうか？

レトロスペクティブの結果、ナレッジ共有会を実施することになりチーム内のナレッジが向上したり、腹を割った話ができてきて、少しずつチームの団結力が高まってきている今日この頃です。

少しでも振り返りについて参考になる部分がありましたら幸いです。

koma

エンジニア

元々製薬業界で働いており、スクールを経てDWSに入社。主にgolangを使用したバックエンド業務に携わっているが、触ったことのない技術にも楽しく挑戦していきたいと考えている。趣味はスキューバダイビング。