はじめに

本記事ではログラスにおけるスクラムマスターの考え方、そして専任化についての取り組みの現在地点をお伝えできればと思います。

なぜこのテーマを選んだか？というと、この1年を振り返る過程において、スクラムマスターという役割が改めて重要な役割を果たすのではないか？と考え、直近で専任スクラムマスターを置く取り組みを実施しておりました。
こちらの取り組みから、どんな仮説を立てたか？現在どんな状況か？などをまとめることで、同じくスクラムマスターの位置付けについて悩んでいる企業があれば参考にしていただけるのではないかと考えたためです。

この記事では私がエンジニアリングマネージャー（以下EM）として、スクラムマスターとEMの責務の切り分けをどうすればお互いがパフォームできる状況を作れるのか？という視点から話を進めていきます。

ログラスのスクラムについて

ログラスでは創業時の1チームのスクラムチームが源流となって事業拡大・組織拡大に伴いながらチーム分割を進めてきました。

現在はMonorepoで開発しており、機能領域ごとにチームが組成されていますが、Domain層のコードの独立性が高いため各スクラムチームが独立して動けるような状況を作れていました。

チーム分割以降は全体のプロセスの統率についてはリリース前のQAを各チームでしっかりとやりきるところのアラインメントくらいで、それ以外のプロセス改善は各チームの自律性に委ねていたという状況です。各チームでのプロセス改善についてはQAも大きく貢献しており、テストプロセスとスクラムのプロセス改善双方を担っているというのがログラスの特徴です。

この体制にはメリットデメリット双方あり、チームの自己組織化を促せる一方で、各チームでプロセスが独自進化していくことでチーム横断で関わりを持つような人からするとプロセスの差異に混乱するようなシーンも発生していました。またQAも全チームに入れているわけではなく、全チームのプロセスのアラインなどはまだやりきれていない部分があります。

現在の課題について

現在の開発の課題として大きくなってきているものは、機能領域を跨ぐような大きな開発をどう進めるとよいか？というものです。
イメージとしては全ての画面に影響があるような新しい概念をシステムの中に取り込まなければいけないような開発項目のことを指しています。

一方で技術的複雑性は比較的各チームが持っている機能領域に閉じているため、小さなプロジェクトチームを組成してそのチームがすべての開発を行うということも現実的には難しい（各チームのレビューが必要）という状況があります。

こうしたシステムの複雑性とそれをうまく扱うための組織的なプロセスを整えていく必要がある、ということが現在の大局的な課題感となります。

専任のスクラムマスターはログラスに必要か？

EM視点での組織的な課題としては顕在化しているもの・潜在的なものそれぞれ細かいものを洗い出すと以下が挙げられます。

現在顕在化している課題
- 開発組織全体の運営コストが上がっている
  - 現在EMの稼働のうち大きな割合を占めているものは以下
    - 日常的な1on1
    - 目標設定・評価プロセス
    - 採用
    - 各チームの戦略議論
  - カバーしきれていないものは以下
    - チーム横断のプロセス最適化
    - チーム横断の交流の場
潜在的な課題
- S@SやLeSSの導入推進に対してオーナーシップを持てず、開発プロセスが進化していかない
- 事業戦略、組織戦略、品質戦略の乖離に対して後手にまわりアンコントローラブルになってから問題対処に奔走する状況を生み出してしまう懸念

ログラスは現在組織拡大中のスタートアップであり、採用業務の優先順位が非常に高いフェーズとなっています。それに加えて事業の伸びに比例してデータ量も大きくなり、パフォーマンスなど技術的課題も増えていくことが予想されます。したがってチームとしても想定外の課題に直面するシーンが多くなり、その負荷をどう切り抜けるか？という人的な支援も重要になってきます。

人や組織に関する短期的な課題に多くの時間が割かれるようになると、組織全体のプロセス改善のことを考えていくことができなくなり、結果としてゆるやかに生産性が落ちていってしまうことが最大のリスクだと考えています。いわゆる組織のプロセスに関しての斧を研ぐ活動ができなくなるということです。

これらを考慮するとスクラムマスターにそうした組織のプロセスに関しての斧を研ぐ活動を担ってもらうのは分担としてはわかりやすいのではないかと考えました。

具体的な組織運営の課題

直近発生していたものでは、オーバーオールレトロの運営が挙がっていました。

ログラスではLeSSを実施しているわけではないですが、チーム内の学びや課題をチーム横断での学び・課題として扱えるようにするため、オーバーオールレトロという形で各チームから参加者を募りレトロを実施していました。

といっても、レトロというよりは課題を起票するNotionがあり、その議題について議論していくような固い場になってしまっていたのが実態です。

レトロのレトロをしたところ以下のような課題が挙げられました。

ここから読み取れることをまとめると、オーバーオールレトロの位置付けや目的が実態とズレてきている課題に対して誰かが手を打たなければいけないが、オーナーシップを持ちにくい状況がある、と言えます。

組織フェーズに合わせて組織のコミュニケーション設計を都度リファクタリング・リアーキテクチャしていく必要があるがこれは誰のオーナーシップのもとで推進すべきか？という観点です。

本来的には非常に深く考えなければいけない領域かつこまかく状況モニタリングして推進すべき領域なのでかなりパワーが必要で片手間でできるものではありません。

しかし、投資対効果を説明することも難しい領域ではあるのでなかなか気合いだけでは進まない領域でもあります。その状況・姿勢が将来の開発生産性を下げる要因となる可能性はあると考えました。

組織運営の課題はEMの責務なのでは？という問いについて

おそらく、こうした組織運営の細かいものから大きなものまでEMがカバーしている組織もありますし、EM的には拾いに行った方が自己効力感も得やすいと思います。

改善を推進することでピアボーナスの感謝をもらえているところ

しかしながら、組織全体のアーキテクチャを考えていくという営みは専門的な深みが必要で、他社事例を聞いたり、試行錯誤が必要な営みなので愚直にやるとキャパオーバーになります。

OKR的に劣後されてしまって達成できなかったけどまあ仕方ないよねーという扱いになってしまうのが最悪ですが、そうなりやすい領域のものでもあるかと思います。

スクラムマスターへの期待

スクラムマスターというとまずはひとつのチーム内のスクラムのプロセスをより良いものにしていくことに取り組みます。

ZuziのScrumMasterWayで言うレベル1です。

しかしながらログラスにおいては、もちろんひとつのスクラムチームのプロセスをいいかんじにする、という期待はある前提で、チームを超えた組織全体の運営に課題がある状況です。

この抽象度においてはこれまでトップダウン的にはEMがカバーし、ボトムアップ的にはQAがカバーしてきたのが実態ですが、それぞれ別の責務もある中で抽象度が高い組織的なプロセスの改善にオーナーシップを持つ人がいてもいいのではないかというのが私の考えていることです。ZuziのScrumMasterWayではレベル2以上が相当します。

ログラスでどんな期待値をかけられるとよさそうかを想像すると、

チーム横断の開発プロセスの最適化、そしてアップデート
実験的な取り組みの推進と全体への適用を繰り返す
- その知見をまとめ外部に発信する、ブランディングしていく
新たな運営体制を作り、スケーラブルにしていく
- 組織が大きくなっても形骸化せず効力を発揮し続ける仕組みを作る
職種間の連携プロセスについて第三者の視点からフィードバックしていく。個別のチームのコンディションにも目を向け、必要な情報提供をしていくなどのイネーブリング活動をしていく。

といったことを取り組めるとよさそうなのではないかと考えます。

チーム以上の抽象的な価値に向き合う例として、サイボウズさんの例が素晴らしいと思っています。

このような、組織の中で機能するチームの型を作っていくことや再現性を作っていくことをログラスでも取り組みたいと考えています。

EMとの棲み分けについて

上記のイメージから縦軸に個人・組織、横軸に短期・長期で4象限を作ってみると以下のようになります。

基本的には個人に関するピープルマネジメントをEM側に、組織横断のプロセスマネジメントをスクラムマスターに寄せるのがわかりやすいのではないか？と考えました。

長期の戦略的な議論や人事に影響する議論はスクラムマスター・EMで双方で持って進めるものもある、というかんじです。

EMとしての事業貢献をどう考えるか？

EMとして社内の等級・グレードを上げようとすると、より大きな範囲の組織に対して責任を持ちマネジメントしていく必要があります。しかし、表面的には組織運営や設計の議論をスクラムマスターが持つのでEMは何をするのか？という疑問が出てきます。

...しかしながら実際にはそうでもありません。

EMの最も大きな責任を個人のピープルマネジメントに置いた時^[1]、シニアなEMのアウトカムとしてはよりシニアなスペシャリストの持続的な活躍を支援し続けられるか？は重要なポイントだと言えます。

スクラムマスターもスペシャリストではあるので、その人としっかりと目標を握り、組織に対していい影響を与えることができればそれはスクラムマスターの成果であり、EMの成果でもあると言えます。

ということで、EMとしてキャリアアップを目指す過程においても、配下のEMのマネジメントやシニアなスペシャリストのマネジメントというところでEMの事業貢献は説明できそうです。

以上から、「スクラムマスターを置いたとしてもEMのやることがなくなるわけではないし、むしろフォーカスする対象が明確化されることで長期的には良い影響がある」と結論づけました。

ログラスのスクラムマスターが向き合っていくテーマ

中にはアジャイルコーチの領域と言えるものもあるかもしれませんが、抽象度の高いものまで書き出してみると以下のようになりました。

自己研鑽、探究
- いいチームとは？に答え続ける、模索し続ける
- プロセスの質に対する模索
  - どう扱うべきか？どう計測すべきか？
- スクラムマスターとしての価値の模索
  - 組織フェーズに対して変化していくべきか？
  - 自身がどう変わったら価値を出し続けられるのか？
プロセスの質をあげる
- チーム内プロセス
- チーム外プロセス
- チーム間連携
- 社内のコミュニティを育てる
- プロセスの価値を上げる
  - 時間・人数に対して得られるアウトカム
- 健全な議論の場づくり
  - 中立的なポジショニングで場をつくる
  - 中立的な観点から議論を活性化させる
- 組織課題のアラーティング
イネーブリング
- スクラムのロールの役割・責務
- スクラムのプラクティス
- 技術的プラクティス
  - テクニカルエクセレンスのための支援
- プロダクトマネジメントの支援
- コーチング
- いいチームになるよう導く
  - チームの熟達を促す
  - プラトーを認識させる
  - プラトーを越えさせる
- マインドセットのインストール
- 社外の知見を持ち込む
自己組織化するために戦うこと
- 経営・Mgrに対するフィードバック・提言
- チームに対するフィードバック・提言
- 組織全体に対するフィードバック・提言
ブランディング
- 社外に知見を発信する
- 社外のコミュニティに貢献する

一言でまとめると、「組織（チーム）をより良い状態に進化させるリーダー」と言えるのではないかと考えています。

実際取り組んでみてどうだったか？

ここまでの記事の流れとして、チームを超えたより大きな範囲に対してのプロセスにアプローチする存在としてスクラムマスターを置きたいという話を書いてきていますが、一方で初手の取り組みとして小さく始めることは重要だと考えており、まず1チーム内での専任化でいたほうがいいという結論に至るのか？から検証している段階です。

これについてはEMがトップダウンで決めてもチームとしていい！という状態に至らなければ形骸化してしまいます。したがって現場の納得感も重要視して進めているところです。

足元の取り組みとして @bonotake さんにまずは1チームのスクラムマスターとして参画していただいているので、ここまでの感想をヒアリングしました。ここまでの意図をお話しして依頼させていただいているため非常にプレッシャーも大きいかと思いますが、一緒に取り組めていることをとても感謝しております。

Q.参画する以前の印象でログラスのスクラムマスターとしてどんなことができるとよさそうと考えていましたか？

A.ジョインするチームのメンバーと事前に面談させていただいて、既にスクラムでの一定以上の経験を積んでいて、既にある程度完成しているチームだな、と感じました。だから、自律性や問題解決能力は既にあるはずで、その能力を押し上げるようなことができれば、と考えていました。

Q.参画してから上記は変化しましたか？変化している場合どのように変化しましたか？

A.事前の想定通り、特に自己組織化の面では既に高いレベルにあるチームでした。ただ、そのレベルの高さに比して知識が追いついていなくて、それで上手く回っていない部分があると感じました。（といっても、A-CSMやCSP-SMの研修で教わるような、割と高度な知識の話です）
問題解決能力は元々あるので、あとは知識の底上げと、チームの状況を俯瞰しての指摘をしていけば自然とレベルアップするのでは、と感じています。なので自分は今のところ、いわゆる 9 Coaching Rolesでいう "Teacher" と "Reflective Obzerver" をやっていけばいいのかな、と思っています。

Q.現在のチームの課題について教えてください。

A.一番の課題に感じたのは、PBI/タスクの管理の仕方が、開発状況全体の見通しがしづらく、またプロダクトゴールやOKRとの紐付きがわかりにくい形になっていることでした。なのでOKRを達成するという観点からは効率が悪そうだったし、特に比較的新しいメンバーにとってはプロダクトの理解を阻む要因になっているのでは、と推測しています。

Q.今後チームはどんなことに取り組めるとよさそうでしょうか？

A.上の繰り返しになりますが、自己改善と問題解決能力は既に高いレベルにあるので、あとは個々の判断がより正確になるよう、スクラムや組織設計への理解をより深めてもらえれば、自然とレベルアップしていけるように思います。

以上の指摘の通り、現状弊社の開発チームはいいところもありつつ課題も多くある状況です。

チームメンバーからも以下のようなコメントをもらっています。

これまでチームメンバーが業務の片手間でスクラムイベントを実施していたところに、専任でしっかり時間をとって準備していただけることでスクラムイベントのクオリティが大きく向上した
チーム内ではこれまで出せなかった視点をもたらしてくれている
利害関係の小ささから課題をフラットに相談できる

言葉にするとそうだろうなと思われるかもしれませんが、実際に専任化することでこれらの点が顕著に感じることができているのは良い滑り出しになったなとEM視点でも感じているところです。

というわけで、ログラスでは今後も開発プロセスの進化に様々な角度からアプローチしていきたいと考えています。

We Are Hiring

現在スクラムマスターの募集も開始しました。まだ組織としても手探りですが、その辺りも含めてディスカッションさせていただけたらとてもうれしいです！

脚注

EMのスコープとしてはテクノロジーマネジメントやプロジェクトマネジメント、プロダクトマネジメントも含まれますが、成熟したスクラムチームではチーム内でテクノロジー・プロジェクト・プロダクトをマネジメントすることができ、個々人に対する支援のみが残るという理想状態を指しています。 ↩︎

Discussion