この記事は Sansan Advent Calendar 2023 の11日目、および【R&D DevOps通信】の連載記事のひとつです。
こんにちは、研究開発部 Architectグループの辻田です。去年の12月頃にランニングを始めて早1年、年間の走行距離は2114kmとなりました。 フルマラソンデビュー戦では4時間9分で無事に完走できました。来年は4時間切りを達成したいです。
そんなことはさておきこの1年間、私たちのチームは挑戦と協力の中でさまざまなチームビルディング施策に取り組みました。この記事では、具体的な取り組みである「チームラーニング」「Value Stream Mapping」「強マッチ/弱マッチ」「死亡前死因分析」に焦点を当て、それぞれの成果や学びについて共有します。
またこれらの取り組み以外にもチーム開発合宿も行いました。合宿についてはこちらの記事で弊チームリーダーが詳しく紹介しています。
チームビルディングに対する考え
まずわたしがチームビルディングを重要視する理由についてです。仕事で最大のパフォーマンスを発揮し成果を出すには、メンバー一人ひとりが自分らしく振る舞える環境が無くてはならないと考えています。自分らしさを出せず他メンバーの顔色を伺うようなコミュニケーションしかできていなければ、建設的な議論も生まれません。その結果良いものが作れない、いわゆる心理的安全性が低い状態と言えます。
ただし、心理的安全性とは仲良しこよしのことではありません。仕事で成果を出すための集団ですから、仲良しすぎても厳しいフィードバックや反対意見などを言い辛いという状況になりかねないので、適度な緊張感と安心感が必要です。
チームビルディングでメンバーのバックグラウンドを共有したり、課題解決のためにそれぞれのアイデアを出し合い議論することで、お互いの人となりを理解し自分らしさを発揮できる環境作りへ繋がると考えています。
これらの理由により、チームで最大の成果を出すためにチームビルディング施策は有効な手段と考えています。
チームラーニング
働き方のスタイルや自分の得手不得手など、プロジェクト開始前にお互い知っておいた方が良い情報を共有して、チームで働きやすい状態を作ろうというものです。
マッキンゼー社でプロジェクト開始時に行われるイベントらしく、実際のやり方などについては以下をご覧ください。
McKinsey Careers: Inside the team learning – one tool to create balance - YouTube
目的
- チームで働きやすい状態を作る
- メンバー同士の理解を深めプロジェクトの成功確度を高める
取り組み内容
実際の発表で使用したスライドをいくつか紹介します。
人によってさまざまな仕事のスタイルや好みがあるので聞いているだけで面白い内容でした。ちょうど新卒メンバーが参画したタイミングだったので、相互理解に役立たったのではないかと思います。
低コストでさくっと取り組みやすく、弊チームでの実施後は研究開発部のさまざまなチームに広がったものです。
Value Stream Mapping
ソフトウェア開発サイクルのモノと情報の流れを可視化し、無駄を見つけて効率化していくための取り組みです。オフラインで集まる貴重な機会を利用し実施しました。
マイクロソフト社の資料を参考にしながら事前準備〜実施をしました。
目的
- プロセスの可視化
- 開発サイクルにおける無駄の存在をチームで認識する
- プロセスの最適化
- 開発リードタイムの削減
取り組み内容
「研究員から相談を受けてからCircuit*3上にAPIをリリースするまで」というお題で実施し、完成した図がこちらです。
なんとなく自覚していた無駄や、あまり認識できていなかった無駄が浮き彫りになりました。そして小さな無駄の積み重ねで全体のリードタイムは約10週にもなることが分かりました。
そこからさらに改善案をだしてみて、改善後は半分の約5週まで短縮できる見込みとなりました。あくまでざっくりとした計算ですが、かなり大きな効果です。
ここで出した改善案は、実際に現在取り組み中のものや、以降のOKRに載せようとしているものなど次の行動に繋がっています。
強マッチ/弱マッチ
強マッチとは、ストレングスファインダー*4やエニアグラム*5といった手法を使って共通言語で強みを語り合う取り組みです。弊社では新入社員が既存メンバーに対して強みの共有をしていますが、チームで共有し合う機会がありませんでした。
弱マッチは完全にオリジナルの取り組みで、弱みや失敗もうまく自己開示することでコミュニケーションに役立てていこうという取り組みです。
目的
- 強マッチ
- お互いの強みを理解し、それぞれの強みを掛け合わせることでチームとして最大のパフォーマンスを出す
- 弱マッチ
- 弱さや失敗も認め合い、個人の成長、チームの成長に繋げる。ミスを早めに共有する文化を作る。
取り組み内容
実際の発表で使用したスライドをいくつか紹介します。
入社後2年経過しているメンバーはストレングスファインダーを再受験したのですが、結構変わっていたのも面白かったです。また、チーム全体の傾向から「他部署を巻き込む」ことが苦手なメンバーが多いことがわかりチーム体制の参考になりました。
注意したい点として、このような診断はバイアスを生む可能性もあるため、あくまで傾向を把握する参考程度に活用するのが良いと思いました。
死亡前死因分析
プロジェクトのリスク管理として「すでに悪いことが起きてしまった」という前提のもと、「原因は何か？」を問うものです。SRE活動でよく実施されるポストモーテムと逆の視点です。
目的
- 大きな手戻りを発生させるリスクを事前に洗い出し、対応策を検討することでプロジェクトの成功確度を高める
取り組み内容
Notionのダッシュボードで実施しました。
具体的なリスクに対して重要と思うものにメンバーが投票し、対応策を出すことができました。
ここで出した案は実際にタスク化して取り組み、大きな遅延なくプロジェクトを終えることができました。
タスク化したもの以外では、週1回モブプロの時間を取っていてその場で実装に悩んでいることを解消していけたのも良かったです。
最後に
これらの取り組みによってチームの生産性に変化があったのかを4keysのメトリクスで見てみます。
デプロイ頻度
デプロイ頻度はmainブランチにマージされた数を集計していて、中央値を前Qより1pt以上引き上げることを目標にしています。
6月~8月時点では中央値が12.5でしたが、9月~11月では14.5に引き上がりました。
2023/06~08
2023/09~11
変更のリードタイム
変更のリードタイムは「マージされた時間 - コミットされた時間」の75パーセンタイルを集計していて、3営業日以内を目標としています。
6月~8月時点では303時間オーバーでしたが、9月~11月では272時間でした。目標には届きませんでしたが31時間削減することができました。（プロジェクトによってブランチ戦略が異なるため、このグラフにはリリースブランチなどのノイズも入ってしまっています。これらを除外できたらもっと実態に近い結果になると思います。）
2023/06~08
2023/09~11
変更障害率、サービス復元時間はまだ正式な運用に乗せられていないため対象外としました。
チームビルディングの活動はこれらの定量的な指標に少しは影響しているのでないでしょうか。また、他チームのメンバーからも弊チームはメンバーの発言が活発だとフィードバックをもらうこともありました。 今後もこれらの手法を継続的に活用しながら、新たな挑戦に向かっていきます。
番外編
チームメンバーがオフラインで集まるときのランチは焼肉に行くことが多いです。1つの網を囲いながら肉を焼くことでコミュニケーションがより活発になる気がしています。
*2:Geek Seek スキルアップや業務効率化に必要な費用を補助する制度。
*3:アプリケーション基盤のことです。
