back check の開発組織拡大にスクラムマスターとして向き合った話
こんにちは！
株式会社 ROXX の back check サービス事業部でスクラムマスターをやっている山口です。
今回は事業部からスクラムマスターとしてチームの成長を促進した行動について評価いただいた際に、それらの行動に至った経緯をプレゼンした内容をまとめます。
経歴
高卒から6年間の工場勤務を経てエンジニアに転職し、その後複数社を経てROXXにジョインし現在2年目という状況です。
ROXXへジョインした当初はエンジニアでしたが、現在は専任のスクラムマスターにキャリアチェンジして活動しております。
混乱の半年間
大幅なエンジニア人員増
これまで back check 事業部は、プロダクト力向上のために開発組織の強化に注力しておりました。
そのための施策として、大幅なエンジニアの増員を行なってきました。
その結果、私がジョインした当初に8人だったエンジニアメンバーの数は倍の人数になる程大きなインパクトをチームに与えました。
SM兼エンジニアに移行
そんな中、私個人としてはエンジニアとして活動していたところから、新たにスクラムマスター（SM）を兼務することになりました。
背景として、元々SMをしていた方がPMに転向したことによりSMを引き継ぐ形としてキャリアチェンジすることになりました。
兼務始めたての当初は、スクラムマスターとしてなにをすればいいか右も左もわからない状態でした。
とはいえエンジニアの時からサポーター的な立ち回りをしていたことと、先代のSMや、社内の別の事業部でもSMとしてのキャリアの長い方がいらっしゃり、情報交換をする場が整備されていたため、安心してSMのキャリアをスタートすることができました。
大型チーム運営の混乱
チームとしても組織規模が大きく代わり、個人としても新たな役割に挑戦していた矢先に徐々にチームは混乱期に突入していきました。
というのも、プロダクトの立ち上げ当時から少人数での開発で進めてきたため、メンバーが倍に増えた back check の開発チームには大型チーム運営のナレッジがなかったのです。
その結果、少人数でなんとなくコミュニケーションが取れていたプロダクトの運用が通用しなくなったり、チームのコミュニケーションパスが増えたことで発言がしづらく、現場の意思決定速度も徐々に低下していくことを体感しました。
チームは混乱し、SMとしてもなにをしていいかわからない
そんな中、SMとしての立ち回りもおぼつかない私はこの状況に対してどうアプローチしてよいかわからず、唯一の手段として1on1の場でメンバーに現状の課題感をヒアリングしては一緒に悩むということをひたすら行っていました。
ただし、悩んでもどうしても解決できない問題もあり、なんとかせねばと焦っていました。
ただただあたふたしていた状況で私は、先代のSMや開発マネージャー、社内の別事業部のSM、はたまたRegional Scrum Gathering Tokyoのイベントをきっかけに知ったアジャイルコミュニティに参加しては先輩のアジャイル戦士達にとことん現状打破の壁打ちに付き合ってもらいました。
壁打ちしていただく中で、問題は複雑に絡み合っていて、ひとつずつ解決していかなければならないという現状をようやく認識することができました。
着実に進めていくということに意識が向いたところで、チームとして、そして個人として解決に向かうためのアプローチを行いました。
着実に解決に向かうための些細なアプローチ
チームとしての解決のアプローチ
まずはチームによるアプローチとして、次のことに取り組みました。
丁寧なオンボーディング
当時チームはメンバーの増員によって人数が多い状態が原因でチームの機敏性が落ちてしまっているのではないかと焦っていました。
しかし事象を紐解いた結果、ジョインして歴の浅いメンバーが業務に慣れていないことが原因だとわかりました。
それ以降、なるべく早く業務に慣れてもらえるよう、頻繁な1on1の実施やスクラムガイドの読み合わせ、チームとしてビジネスロジック周りのペアプロなどメンバーに慣れたと感じてもらえるまでサポートを行うようにしました。
チーム分割
人数が増えチーム内のコミュニケーションパスが増えたことにより、チーム活動の節々で発言がしづらい雰囲気に陥りました。
また、全体の議論の効率も落ちてきたことを体感しました。
そこで、段階的にプロジェクトの1部からはじめ、プロジェクト全部、それからチームごとの分割という流れで各担当者が責務を狭め、作業に集中しやすくするためにチームの分割を行いました。
SMとしての解決のアプローチ
それからスクラムマスターとして次のことに取り組みました。
社内勉強会で共通言語を作る。
チームとしてアジャイルなマインドを深ぼるために、メンバー間やPOとSMの集いなどそれぞれの部分集合で読書会を開催しました。これらを通してチーム内の共通言語を作ることで、普段の活動の原則となる共通認識の獲得やスキルアップを図りました。
ひたすら対話する。
コミュニケーションパスが増えたことで意思疎通がとりづらい環境において、認識や課題感のズレは軌道修正がコミュニケーションがとりやすい少数組織より大変になります。
そこでメンバーと認識のズレや課題感を感じたら少しでも早く対話の機会を設けてすり合わせることを徹底的に行いました。
社外コミュニティとの交流
大人数チームの組織運営という未知の課題に対して、チーム内のナレッジだけでは課題解決の視野が狭まります。
そのため、積極的に社外のコミュニティに参加して同じ問題に向き合っている方や、既に経験してきた方達と情報交換を行いました。
専任のスクラムマスター
人数も多くなったことでチームに向き合うための時間が大幅に要するようになりました。
その結果、開発業務とチームに向き合うことの両立が難しくなり、どちらも中途半端になってしまうことが気になりました。
そこで、業務時間をスクラムマスターにフルコミットしてチームの成長に全力投球することとしました。
今チームとして実現できていること
時間の経過によるチームの練度の向上とあわせて前述の施策を行なってきたことで、今 back check の開発組織としては以下のことが実現できている状態となりました。
安定したチームを作る土台
プロジェクトを完了する実行力
開発プロセスの理解
まずチームを2チームに分割した状態の運用がスタートしたことで安定したチームを作っていく土台の準備ができました。
次に、チームの分割に踏み切るに至った要因のひとつでもありますが、実現難易度の高い施策をやりきれるだけの実行力が得られました。
そして、チームとして開発プロセスを改善していくために必要な現状の開発プロセスの理解を、イテレーションの積み重ねによる経験の蓄積や勉強会を通してまぁまぁ得られているのではないかと思います。
今後の取り組み
今実現できていることを踏まえたスクラムマスターとしての今後の取り組みとして、以下の部分をチームが実現できるようにサポートしていきたいと考えています。
分割したチームの安定
顧客への価値提供におけるパフォーマンスの可視化
開発プロセスの改善
まずは分割したそれぞれのチームが安定して組織運用できるように全力で注力していきます。
そしてチームの安定化を図りつつ、徐々に顧客への価値提供におけるパフォーマンスの可視化をすることで、自分達が属するチームの成長を見える形で実感できるような状態になれることを目指します。
最後に、開発のプロセス面でも継続的に学習と改善を行っていきます。
おみやげ ~読んでいただいた方へ~
以上の経験を通して皆さんに持ち帰っていただけるプラクティスを3つピックアップしました。
社内勉強会で共通言語を作る。
ひたすら対話する。
社外コミュニティとの交流
チームの強化したい部分を題材に社内勉強会を行いましょう。
みんなが課題感を持てているため、学習後実務の改善に活かしやすいのでおすすめです。
改めて認識のずれは大きな無駄を産みます。
そしてテキスト上の非同期なやりとりと比べて対話は短時間で非常に多くの情報量を扱うことが可能です。
社外のコミュニティに積極的に参加してみてください。
カンファレンスの参加や、お手軽なものならconpassで業務系のイベントが頻繁に行われています。
普段関わらない人、知識、空気感にたくさん触れて、毎日のお仕事をより働きやすい、成果のでやすい仕組みに変えていきましょう。
以上をふまえて、小さな改善活動の積み重ねがチームの成長に繋がります。
ハードルの低いところから、みなさんもぜひTRYしてみてはいかがでしょうか？