強い開発チームを作るためのコツ〜課題の抽出・可視化・共有のプラクティス〜

こんにちは。Ubieでソフトウェアエンジニアをやっているtatsuroroです。

いきなりですが、チームでサービス開発って難しくないですか？
特に不確実性の高い目標を達成しようとした取り組んでいく場合。
チームワークの良し悪しによって、得られる成果は大きく違ってきますよね。

この記事では、自分がエンジニア兼スクラムマスターとして関わった開発チームにて、課題を抽出・可視化してチームが成長するきっかけを作っていった事例を紹介します。

新チームのミッションは、サービスの回遊体験を通じて新たな価値を生み出すこと

今年の秋頃に新しいチームが編成され、スクラムマスターを担当することになりました。
このチームのミッションは、「症状検索エンジン ユビー」ならびに「ユビー病気のQ&A」を利用する様々なユーザーが、一人一人のニーズを適切に満たせるような新しい回遊体験を作ること。

ユビーのプロダクト開発チームでは原則スクラムを導入しています。
今までも見習い程度にスクラムマスター業を嗜んだことはあったものの、今回は全社的に期待の大きいミッションで、素早い成果を求められる環境。
チームの生産性を上げるために何をしたらいいのか？
確実なアイデアは手元になく、ただただファシリテートする状況からスタート。完全に手探り状態でした。

どうしたもんかなと悩んでいたのをチームのプロダクトマネージャーを担当していた@shikicheeが察知。彼はスクラムマスター経験も豊富で、毎週1on1を実施して立ち上がりをサポートしてくれることになりました。

初期の1on1メモ

チーム編成当初は課題だらけ。その課題もぼんやりしていてスピードが出ない

ユビーのプロダクト開発組織は、こちらの記事などにあるようにややユニークな構造をしています。意思決定権は一定チームに委ねられ、そのうえでメンバーそれぞれが主体的に活動し、組織目標の達成を目指す。チームのあるべき姿としては、いわゆるHigh Alignment High Autonomyを志向しています。

有名なHigh Alignment High Autonomyの図

いざチームは立ち上がり、上図の右上の状態を当然夢見るものの、いきなりそんなにうまくはいかず。編成当初はどちらかというと右下の、High Autonomy but Low Alignmentな状態でした。
スクラムのサイクルは回しているものの、なんとなく形だけなぞっている状態。自覚はしているけど解決作がわからない。なんだかモヤモヤして、なんだかしんどい。
自分がもっと頑張って状況を把握して、情報をまとめて、適切なサポートやアドバイスをできればいいのか？なんて考えていました。
でも「あれをやるべき！こう行動すべき！」とか言い出すのは、図でいうと左上に行っちゃう気がする、、、

ぼやいている1on1メモ

そんなことを1on1でポツポツ話していたら、PdMしきちがおもむろにスクラムガイドのPDFを開きました。そして 「スクラムマスターは、スクラムの透明性・検査・適応を達成するために自分があれこれやるというよりも、チームが課題に気づいて行動できるように支援するイメージじゃないすかね。チームに還元するというか」 と一言。

自分の認識を変えてくれたアドバイス

からの学びメモ

目から鱗ぼろぼろです。それまであったモヤモヤが晴れ、良いイメージが湧いてきました。
「チームに還元する」にフォーカスすればHigh Autonomyへのとっかかりを得られる。
そこで、まずは課題の可視化と共有に力を入れ、チームの状況を皆で認識できるようなアクションを積み上げることにしました。

ここまで背景です。お待たせしました。以下に3つの事例を紹介します。

スプリントレビューで施策→検証サイクルを数字と共に振り返る

スクラムのセレモニーのうち、スプリントレビューはプロジェクトの状況を可視化する目的で行うものです。主眼はそのスプリントで達成した成果の検証ですが、より詳細にプロジェクトへの影響を共有できるよう、フォーマットを決めて運用しています。

スプリントレビューのテンプレート

この場でチームに還元したい情報は 「スプリント中に検証したことによって、プロジェクトにどのような影響があったか。チームの活動は目標達成に結びついているかどうか」 です。

特に変わったことはしておらず、シンプル。ですが、上記の還元したいことにフォーカスしながら複数人で同期的にメトリクスを確認したり、施策から得た示唆をもとにアイデアを突き合わせることは、チームがHigh Alignmentな状態になっていくのにとても効果的でした。

進行フローはだいたい以下のようになります。

• スプリントゴールの確認と、達成できたかどうかの振り返り
• プロダクトデモの共有、ならびにリリースした内容の効果検証を共有
  • 検証内容によって、次にフォーカスする施策のアイデアを練る
• メトリクスをチェック。リリース内容の影響や、外部影響の有無などを確認
• 全社で追っているOKRの確認。チームが達成したい目標に対して、このスプリントでどの項目にどれくらいアプローチできたかを振り返る
• 振り返りとディスカッション中に出てきたアイデアをまとめ、次のスプリントでやることの検討材料にする

いまいちうまくいってない状態のチームは、たとえ個々のメンバーにやる気があっても目指す方向・得ようとしてる成果の認識が微妙にずれているため、結果的に「欲しいのはこれじゃなかったんだよな、、、」になりがちです。

編成したばかりのチームも同じ状態でした。スプリントレビューのたびに「ぼくらはつまるところ何を目指していて、プロダクトがどういう状態になればいいのか？そのために明らかにすべきデータはなんなのか？」といった議論を重ねていきました。
みんなでアイデアを出していくと、たびたび認識のズレが見えてきます。ズレを修正して共通の認識をアップデートしていくことで、だんだんと生産性が高まりチームが活気づいてくるのを実感できました。

週次のレトロスペクティブを工夫し、チームの状態を可視化・共有

レトロスペクティブは、チームの状態を可視化することを目標に定期的に行われる振り返りです。
ここでチームに還元する情報は 「チームは健康かどうか、不満や困りごとがないか。前進を助ける、または妨げる要因があるか。あるならばそれは何か」 です。
いわゆるKPTですが、ポストイットを貼り付けるボードに「Sailboat Retrospective」フレームワークを利用して工夫しています。

ある週のSailboat Retrospective。下部の黄色いポストイットには各項目の補足やTryを書き出している

詳しい内容や運用の説明はぜひこちらの記事をご覧いただければ。
自分たちのチームでは、まず”SUN”エリアで良いニュースを祝ったり良い仕事を称え、次に”WIND”エリアでチームの目標にとって有用な事柄、”ANCHOR”エリアで今あるブロッカーやお困りなどを共有して現状の認識を揃えた後、最後に”REEF”エリアで今後の不安や懸念を洗い出しています。
”ANCHOR”、”REEF”の項目に関しては、Tryを出せるものはTryを出してネクストアクションを可視化。今すぐTryを出すのが難しいものは、ひとまず課題として共有しておき、折りに触れ再検討します。
ユビーの先輩社員が以前別のチームで導入していたのを「なんだか良さそう」の直感で採用・運用しはじめましたが、船=チームが進むメタファーと、その周りで起こっていることのポジネガのカテゴライズは思った以上に効果的でした。
このフォーマットでの振り返り会を毎週30分継続することで、チームの現状や課題、皆の不安や懸念、不満に思っていることなどが可視化され、意識の共有が進むようになりました。

妨害リストを運用しはじめたら、広く活用されるようになった

レビューとレトロスペクティブを毎週繰り返すことで課題は見えてきたものの、日々忙しくタスクを進めるなかでうっかり忘れられてしまったり、ポストイットにしか書いてないために書きっぱなしになってしまい、「そういえばあの課題のTryって誰か手つけた？」「先週のレトロと同じ課題をまた書いてる、、、」といった状況がちらほら起こるようになってきました。

そこで、これもスクラムのプラクティスである妨害リストを導入。

レトロスペクティブで出た”ANCHOR”・”REEF”の項目や、日々のコミュニケーションの中で見えてくる課題からプロジェクトの障害・妨害になるものをピックアップしてリストにしています。
このリストは、スクラムセレモニーの余った時間やスクラムマスターとしての作業時間などを使ってこまめに状況をアップデートし、随時共有します。

運用中の妨害リスト。PdMしきちの記事より引用

これ自体はただのリストですが、皆の目に留まる場所に情報が集約され、随時対応状況や詳細が可視化されることの効果はとても大きく、チームが前に進むためにやることがいつでも明確になりました。
また、このリストは運用開始後にホラクラシーのタクティカルミーティング（週次のプロダクトマネージャーMTGのようなもの）でも共有されるようになり、隣のチームのマネージャーなどにも課題が共有されるようになりました。その結果、ものによってはチームの課題を素早く組織の課題として扱うことができるようになり、人的リソースの配分調整やデータの共有などがスムーズに行われるように。
リストに置いた課題感をもとにプロダクトマネージャーが組織に問題提起し、リリースまでに時間がかかっていた課題をスピーディに改善することにもつながりました。

細かい工夫は他にも色々ありますが、主にこの3つの取組みを通じて課題の可視化を繰り返し、スクラムの軸である「透明性・検査・適応」の改善サイクルを回しています。
その結果、チームはHigh Alignment High Autonomyな状態を得られてきました。着実に探索を重ね、成果を積み上げることができています。

ある回遊行動の指標を改善した例

まとめ

「良いプロダクトを生み出す良いチーム」になっていくためには、まず課題を可視化して焦点を合わせられるようにすることがとにかく大事。
それを実感できた数ヶ月でした。

弊社の先輩スクラムマスターかつデザイナーのはたけ氏も言ってます。

“スクラムマスターは、「見えていないものは何か」を見ようとする”
多くの場合、顕在化している課題を解決するのは優秀な人が集まったら簡単にできます。
一方、何が見えていないかに自覚的であることは、本当に難しいことです。

https://note.com/hatakejp/n/n2e084f2ba8d7?magazine_key=me260d3df472a

もしあなたが今のチームに課題を感じていて、でもそれが何かモヤッとしてるんだよな〜といった状況にあるなら、まずはとにかく可視化・言語化してチーム全員で共有してみることをオススメします。
気づいたことを即座にテーブルにあげていきましょう。

以上、スクラムマスターの活動を例にしたチームビルディングのプラクティス紹介でした。

明日の Ubie Engineering Advent Calendar 2023 は @guchey による「SEO周りのLLM活用事例」です。お楽しみに！

https://x.com/ShingenTaguchi/status/1734929848039338183?s=20