こんにちは。スタンバイで Engineering Manager を担当しているステファンと高原です。
今回は、先日開催された「スクラムフェス仙台」で紹介させていただいた私たちの活動についてお伝えしたいと思います。
登壇の背景
2022年8月26日〜27日に開催されたスクラムフェス仙台のキーノートスピーチにOdd-e Japan代表の江端様が登壇するにあたって「スタンバイの事例も紹介したい」とのお声掛けをいただき、私たちもゲスト登壇してお話しさせていただきました。
Odd-e Japan社にはスタンバイのアジャイルコーチ・アドバイザーをお願いしています。
代表の江端様は本稿執筆時点で日本でただ1人、国内に限定されない Certified Scrum Trainer® として認定されているアジャイルコーチで、スタンバイのスクラム導入にも手厚いご指導をいただいておりまして、その熱さは当時を知るメンバーの語り草になっているほどです。
今回の江端様のキーノートスピーチのタイトルは「Various Scrum Teams」。
主催者さんからの「ソフトウェア開発以外での活用事例、活用方法を話してほしい」という要望に応えて数社のスクラム活用事例を紹介するものでした。その一社として参加させていただいたかたちです。
スクラムフェス仙台 www.scrumfestsendai.org
スクラムフェス仙台2022 - 江端様キーノートスピーチ概要 confengine.com
事例紹介の概要：私たちCTO室〜EM室の業務をスクラムで進めています
そのなかで私たちが紹介したのは、日々私たちが所属チームで行っている業務の進め方に関してでした。そんな話の何が面白いとされたのか？まず私たちのチームの立ち位置や業務についてご説明したいと思います。
チーム名称
CTO室（2021年4月〜）→現在は EM室（2022年4月〜）
チームの立ち位置
私たちのプロダクト開発組織では、プロダクトロードマップを達成するための各テーマ＝技術ドメインごとに開発チームを構成しています。
私たちのEM室はこれらの開発チームを横断的に支援する存在です。
チームのミッション
エンジニアリングパフォーマンス発揮のための環境整備・組織運営施策・技術課題の解決促進、人材成長促進などを実施する
業務内容の例
・OKR導入支援（既に手離れしています）
・エンジニア行動基準「Engineering Belt」の定義・導入・改定（関連記事）
・プロダクト組織のアセスメント
・開発チームのプロセス改善支援
・プロダクト開発組織共通会議体の運営（OKR進捗会議、TechLead会議、マネージャ会議、表彰イベント 等）
そんな私たちのチームは、一般的なスクラムチームと次の2点が異なると言えそうです。
・プロダクト開発ではなく、組織開発をミッションとするチーム
・プロダクトオーナー（Product Owner：PO）含めメンバー全員が100%専任じゃないチーム
補足：私たちはEM室のミッションとは別に、EMとして得意分野や担当範囲ごとに開発チームの支援（例えばメンバーとの1on1、開発チームのTechLeadとの協働、開発チームのPOやマネージャーとの協働など）を行っています。
私たちがスクラムを導入した背景
現在の組織体制になる以前、スタンバイでは大規模スクラム（LeSS）を採用していて、高原を含むスクラムマスター3名体制で取り組んでいました。それぞれに所属チームも持ちつつ、LeSS全体もみていて、POもサポートするというかたちでした。その当時、次のような理由で、スクラムマスター3名もスクラムチームとして活動することにしました。
・スクラムマスター間で協力して対応するべき課題も相当数あり、課題管理・タスク管理などチームワークが求められる
・自分たち自身もスクラムを実践してカイゼンを繰り返すことで、開発チームの支援に繫がるような事例や知見を蓄積したい
その後、上記スクラムマスター2名を加えて発足したCTO室（現EM室）でも、この流れを汲んでスクラムを継続しました。
私たちのスクラムで行っている工夫
このような流れで現在に至り、足かけ2年以上スクラムを続けていますが、やはり問題も生じて、カイゼンを加えてきました。私たちがカイゼンしてきたポイントを二つご紹介したいと思います。
1.ステークホルダーの考慮
2.Scientificなふりかえり
それぞれを簡単にご紹介したいと思います。
1．ステークホルダーの考慮
RefinementとPlanningを中心に、ステークホルダーを考慮して行ってきたことがいくつかあります。
POのアサインはやはり最重要だった
CTOが多忙だったため、当初それに配慮するかたちで、当初はEMの合議制でPOを代行するという体制を取りました。ところが、課題の背景を捉え切れていなかったり、ゴールに対する優先順位判断が不十分だったり、レビューを受けても個別断片的になったりと問題が噴出しました。この時点では、私たちの業務の司令塔であるCTOが、チーム外のステークホルダーと変わらない状態でした。
その反省から、改めてスケジュール調整をお願いするなどして、（ちゃんと）CTOをPOに迎えてチームを再始動しました。その後はベロシティがカイゼンしました。
複眼でのPlanning・Refinementの確保
チームのふりかえりで「毎スプリント積み残しが続いている」問題について話し合ったところ、「検討不足と指摘を受けたところは別のEMが見たら気付けていたはず」とか「ステークホルダーとの会議設定が遅れて確認が間に合わなかった」などの、いわゆる段取り不足が理由で完了できなかったという共通要因が浮かび上がってきました。言い換えると、「完成の定義を満たすために必要十分なサブタスクを作成できていない」という状況が見えてきたのです。
そこで、割り込み対応が入りがちで揃いにくかったEM間で「Planningを揃って行えるよう時間を確保する」、「Refinementは関係するEM2人以上で時間を合わせて行う」というWorking Agreementを追加しました。以降、完了率が格段にカイゼンしています。
相対見積りの観点の共通認識
先に会議設定が遅れた例を書きましたが、私たちが価値を提供するステークホルダーは、各開発チームのマネージャ・PO・Tech Lead、プロダクトマネージャ、部長陣、CTO、COO、さらに人事や広報なども加わることがあり、バックログアイテムごとにステークホルダーが大きく異なりします。また、プロダクト開発全体がスコープの課題では全開発チームのリーダーとコミュニケーションが必要だったりするので、相当な人数になるケースも多いです。
そこで、私たちの相対見積もりでは「ステークホルダーの数」が一つの軸として定着しています。プロダクト開発の相対見積りでは「技術の不確実性」と「要求の不確実性」とを軸に行なっているのですが、ステークホルダーの数は後者に該当するという整理をしています。
最後のポイントはCTO室・EM室という私たちのチームならではの特徴的なものかもしれませんが、同じように社内に対してサービスを提供するチームでスクラムを実践されていたら、似たエピソードがあるかもしれませんので、情報交換してみたいところです。
それ以外の2つは、どんなスクラムチームでも共通して当てはまる話だろうと思います。
2．Scientificなふりかえり
私たちは、月一回、客観的データを使ったふりかえりを行って、チーム活動をカイゼンしようとしています。
元々は、1でも挙げた「完了率が低い」という課題に向き合うためだったり、兼務メンバーばかりなので作業時間の認識をメンバー間で合わせておく必要があったり、といったきっかけで始めた取り組みです。
データを使うことで、次のようなメリットがあると考えています。
・客観的事実を振り返ることができる
バイアスを少なくできる
・全員が同じ対象に対して振り返ることができる
同じ対象をみて別の気付きが出たときは、他人の視点を知ることができる
データの解釈は在籍経験やキャリアに依存しないので、誰でも気付きを挙げられる
この「Scientificなふりかえり」については、登壇時に複数の方からご質問をいただいたり、その後のネットワーキングタイムでも何人もの方が話しに来てくださるなど、多くの反響をいただいたため、補足情報として共有させていただこうと思います。
fact を使ったふりかえり！
科学的なふりかえり、良い響きだ
スクラムマスターが自動化されそう＞Scientificなふりかえり
Q：Scientificなふりかえり。どんな指標をお使いですか？
A：コミットしたストーリーポイント／完了したストーリーポイントの差分、価値提供できるユーザーストーリー／そうじゃないタスクとのアイテム比率、などをみています。Q：的を射たデータを取るためにしている工夫は？どうやって指標を選定した？
A：Jiraのレポートで自動的に出ているようなものから始めて、自分達が課題を感じたものをどう測るか？で次のふりかえりまでに指標を作ったりもする。ふりかえりのふりかえりで、気付きが出ないデータは一旦お休みするなどして入れ替えも試みています。Q：全部が全部 fact ベースになるとちょっと窮屈になるのでは？
A：ご指摘のとおりだと思います。先ず、実際には私たちも、各自の「もやもや」を書き出すスペースとかも設けていて、Hybridで使っています。
また、データを使うふりかえりは実施間隔を少し空けて、それ以外のふりかえりと組み合わせて行うのがよいと考えています。
ちなみに、私たちは「月1回」データで振り返っています。というのも、毎スプリントのレトロスペクティブでデータの推移をみても大きく変化しないので、傾向が変わる可能性がある3-4スプリントくらい空けてみるくらいが、適切なサイクルではと考えています。
また、このように「先に事実から問題認識をしてからその時の感情を思い出す」という流れも、逆に「先に感情を認識してから問題となる事実を思い出す」という流れも、どちらもふりかえりとして有効だと思っていますし、以降の「要因を掘り下げて→対策を考えて→TRYする」という流れは共通すると考えています。
今後について
というわけで、今回ありがたい機会を得て、自分たちの活動のふりかえりと整理にも繫がりました。今後に向けた野心（will）を書いて締めくくりたいと思います。
開発チームのScientificなふりかえりを支援したい
各チームの状況や扱うテーマによって見るべきデータも異なると思われるので、それぞれのチーム目標や開発スタイルなどに寄り添って、示唆や気付きを得られそうな指標やデータを探すところから伴走していければと考えています。
開発チームの good practice を紹介し合い、生かし合える機会や文化を作りたい
今回、私たち自身が事例を紹介させていただいたことで、社内でもチーム活動の工夫を共有しあえる場を作っていければ、と思いました。
私たちは各チームの「自立型組織」化を目指しているので、画一的ではない様々な取り組みがTRYされています。それらの「こんなことをやってみた」「やってみてどうだった」をお互いに共有して学び合う意義があるように感じます。
定期的に、俯瞰的な組織分析も行いたい
私たちはPO的に自分たちで仮説立ても行うべき立場なので、バックログに並んでいる既存の課題だけに視野を固定されてしまわないよう、半期や四半期ごとに組織全体をふりかえって俯瞰的に分析する機会を設けたいと考えています。
ひとまず、そのこと自体をバックログに積んでおいて、実施をリマインドされるようにしておこうと思います（笑）。
以上、お読みいただきありがとうございました。
スタンバイのプロダクトや組織について詳しく知りたい方は、気軽にご相談ください。 www.wantedly.com
