合同会社makigai（マキガイ）の貝瀬です。2024年6月からスクラムマスターとして、介護/障害福祉事業者向け経営支援サービス「カイポケ」に関わる組織やプロセスの改善を支援しています。

カイポケリニューアルプロジェクトでは、LeSS（Large Scale Scrum：大規模スクラム）を導入しています。本記事では2025年1月に実施した座談会の続編（Part2）をご紹介します。

Part1については以下の記事をご参照ください。

人物紹介

キムダソム（以下、キムPO）
- エリアプロダクトオーナー
田村恵（以下、田村PO）
- エリアプロダクトオーナー
原野誉大（以下、原野EN）
- エンジニア
伊達大晃（以下、伊達EN）
- エンジニア
福田尚亮
- スクラムマスター兼ファシリテーター
貝瀬岳志
- 全体のスクラムマスター兼本記事の執筆者

チームの自律性向上のための役割廃止

—— 10月にはマネージャー酒井さんから、プロジェクトリードを廃止するという働きかけがありました。プロジェクトリードはLeSS導入以前に、「チームを跨いだコミュニケーションでお見合いが発生することを避けるため、また、マネージャーやプロダクトオーナーの負荷を分散するために定義した役割」でした。自律的なクロスファンクショナルチーム(注: プロダクト開発に必要なスキルを保有している、または習得できるチーム)を目指すことが目的でこの役割を廃止することになりましたが、当時どのような印象や期待があったのかを聞かせてください。

キムPO：長期的な目標から見て、ワンチームで取り組んでいくことを目的に役割を減らすというのはポジティブに感じていました。反面、これまではプロジェクトリードがチームとの窓口を担ってくれていたので、当面は結構カオスになるのではないかという懸念もあり、期待半分・不安半分といった印象でした。

田村PO：私もほぼ同じ印象でしたね。これまでだと、プロジェクトリードにとりあえず依頼しておけばいい感じにやってくれていたのですが、チーム全体に投げかけたときにボールがちゃんと拾われるのかという不安は大きかったと思います。中長期で目指していく姿を考えればこのタイミングで廃止しておくべき、ということも理解していたのでネガティブではなかったものの、めっちゃ不安でしたね。

伊達EN：私は田村さん管轄のプロダクトを担当しているチームですが、すでにプロジェクトリードの役割が薄れてきていたので、そこまで何かが大きく変わることはないだろうと思っていました。酒井さんの働きかけより前から、個人というよりチームとして仕事を進めていたので、不安は特に感じていませんでした。

原野EN：9月ごろにミーティングが増えたなと思っていましたが、会話の内容は、チーム分割に関するものだったり、リリースまでのスコープに関するものだったので、プロジェクトリードの役割は想定よりも重い役割に変わっていった印象でした。元々のプロジェクトリードは当番制でも良いくらいの薄い役割で、チームの全責任を担うような重い役割ではなかった認識だったため、その役割をなくしていくことにポジティブでした。個人的な意見であってもチームの代表としての意見として捉えられる可能性があったので、チームの合意をとった方がいいかなとか、悩みながら発言していた記憶もあります。ただ、プロダクトマネージャーやプロダクトオーナーの立場からすれば、プロジェクトリードを廃止することには不安があるんだろうなとも思っていました。

キムPO：スプリントプランニングの1部でも、私からの質問に対してプロジェクトリードの方が回答してくれることが多いので、チーム全体のことを把握しているんだろうなという前提でコミュニケーションを取っていました。それがチーム全体に窓口が広がることで、時間がかかるのではないか、責任の所在が曖昧になるのではないか、といった不安がありました。

原野EN：キムさんのいうような問題が起きて、また元に戻るんじゃないかという懸念もありました。長期的には賛成でしたが、いきなりガッと変化できることでもないので、短期的にはやり方考えないとね、という気持ちが強かったです。

—— 10月から変化が始まって、責任の所在が曖昧にならないか、必要以上に時間がかならないかといった懸念があったかと思いますが、現時点では当時感じていた懸念に対してはどういった状況でしょうか。

原野EN：各チームで代表をローテーションするような折衷案を試したり、いい感じの塩梅を探していく形を取っていった結果、懸念していたような問題は起きなかったと思っています。また、自分自身のGitHubのコミットグラフをみてみたんですが、10月くらいからコミットが増えたなという結果になっていました。そういう意味では、コードを書く時間がかなり増えて、ミーティングが結構減ったなとも思います。

キムPO：私も当時の懸念に関する課題は、顕在化せずにここまで来ていると思います。例えばSlackではチーム宛にメンションしていますが、ボールが落ちたりスルーされることもなく、どなたか必ず回答してくれているので今は安心感があります。ただ気持ち的には、こんなに広範囲でメンションしちゃっていいのかな、ゾーンに入っている時に邪魔しちゃ悪いかな、みたいなことは感じています。気にせずにやっちゃっていますが（笑）。

—— エンジニアのお二人からみて、チーム宛のメンションが飛んでくることへの悪影響や懸念はあったんでしょうか。

原野EN：自分は元々気にならないタイプですし、そもそも変化の前から自分宛にメンションが来ていた状況だったので感覚は変わっていないですね。

伊達EN：同じく気にならないタイプですが、特定の誰かに依存しすぎていること自体が良くないと思っていたので、チームに投げかけてもらった方が当事者意識も出てきますし、むしろその方がポジティブだなと思っています。

原野EN：そうですね、自分は普段から全部知っておきたいというか、気になってSlackを堀り漁っているくらいなので、メンションが飛んできた方がむしろ楽だなとも思います。

—— ちょうど私もスクラムマスターとして支援に入ったタイミングでしたが、責任の所在やコミュニケーションに関する部分は、チームの皆さん自らが課題として捉えられていることを感じていました。自分たちでやり方を決めるところから活発に議論されていて、実行に移していたことが印象的でした。当事者意識という言葉が出ましたが、従来から当事者意識の高い方が多い組織なんだろうなと感じています。10月に関して他のトピックはありますか？

原野EN：9月の段階ではチーム編成など組織に関するトピックがあるとプロジェクトリードが巻き込まれていましたが、徐々にその役割がマネージャーに移っていったのかなと思います。

—— ちょうどこの時期に、マネージャーの酒井さんからLeSSにおけるマネージャーの役割に関する課題提起をされていましたね。

コンポーネントチームからクロスファンクショナルチームへ

—— 11月に入ったタイミングでも、大きな変化があったかと思います。キムさん、原野さんたちの組織ではLeSS導入以前、バックエンドとフロントエンドが別々のチームで分業していましたが、フロントエンドチームがバックエンドタスクを学習しながら取り扱い始めた時期だったかと思います。大きな問題もなく取り扱えていた印象ですが、何か工夫した点はあったんでしょうか？

原野EN：フロントエンドチームがバックエンドタスクとして最初に扱ったのは、既存のコードに対して細かい修正で済むような内容でした。まずはバックエンドエンジニアも交えたモブプロで環境構築して、後はまあひとまずやってみようぜ、というくらいの気軽なノリで始めた記憶があります。私が前職でKotlinを扱ったこともあったので、個人的にもなんとかなるのではないかと思っていました。分業していた時は、ここから先はバックエンドなので自分たちフロントエンドチームはここまでで・・といった遠慮や線引きの意識から、気まずさを感じていたので、自分たちが一貫してコントロールできるように変化することは、チームとしてポジティブだったかと思います。

キムPO：フロントエンドチームはまさに期待していた通りの変化が起きたかなという印象です。当時扱っていたプロダクトバックログアイテムは不確実性が低いものでもあったので、移行がスムーズにいったのかなと思います。結果として、他のチームもクロスファンクショナルチームにしていきたいということを考えるきっかけにもなりました。

—— 11月の変化としてもう一つ、田村さん、伊達さんの組織ではチーム分割の検討がされていました。当時の狙いとして、コミュニケーションコストの低減とチームが取り扱う領域の変化への対応があったようです。分割するときに気にした観点や、最終的にどのように意思決定したのかを聞かせてください。

田村PO：チームの人数が増えてきたことによるコミュニケーションの取りずらさとコミュニケーションコストの増加がきっかけで、チーム分割を検討し始めました。さらにチームが扱うドメインも増えていくことが見えていたので、当初はドメインに対してチームを割り当てて分割する方法を考えていました。一方その分割の方法では、元々フロントエンドエンジニアの人数が少なかったのでうまく分割できるのかという不安もありました。そういった事情があり、酒井さんと貝瀬さんにどういうチームの分割の仕方が良いのかというところから相談していたのですが、最終的にはドメインに紐づかない2チームに分割するという形に落ち着きました。各チームが取り扱うドメインが複数になるので、「ドメイン知識のキャッチアップが大変になるのでは？」といったところが気になりましたが、チームが1つだった時からやっていたことではあったので、悩みながらも意思決定しました。チーム分割は10月頃から考え始めて、分割後のチーム編成が決まったのは12月頃だったかと思います。チーム編成は全員参加のワークショップで決めたのですが、その取り組みは非常に良かったですね。

伊達EN：当時は「フロントエンドエンジニア」「バックエンドエンジニア」という職種で入社したメンバーが多かったのですが、フロントエンドエンジニアが少ない状況の中で、適切にチームが分割できるのかという不安はありました。田村さんと同じように、今後扱うドメインが増えていったときに適切に対応できるかという点が特に気になっていたところです。

—— 1月からは分割後のチーム活動が始まっているかと思いますが、結果的に当時の懸念は解消されているでしょうか？もしくは解消されていないでしょうか？

田村PO：まだ動き始めたばかり*1なので変化が見えきっていないですし、課題はこれから出てくるかもしれないのですが、先ほどもお話したチーム分割のワークショップができたこと自体、非常に良かったと思っています。個々人のスキルを全員で見える化して、どういうふうに組み合わせていけばフィーチャーチームになれるのか？個々人のスキルを伸ばしたり補完し合うにはどうすべきなのか？といった会話をしながら、メンバー全員でチーム編成を決めていけていけたのが本当に良かったです。チームの名前をメンバー自身で決めたのも良かったですね。今後については、チーム単位のスクラムイベントの他にチーム横断のLeSSイベントもやっていくことになるので、チーム横断でも補完しあえる部分が出てくることを期待しています。

伊達EN：チーム分割のワークショップは本当に良かったですね。新チームでの活動は1月から始まったばかりですが、スキルを可視化してお互いへの期待も話し合えたことで、事実、フロントエンドエンジニアとして入社した方がバックエンドのKotlinをキャッチアップし始めていたりします。それ以前は個人的に、「フロントエンドエンジニアとして入社された方にバックエンドの仕事を期待していいのか？」みたいな懸念を感じていました。ワークショップを通じて個々人の得意領域は尊重しつつも、より価値提供・課題解決にフォーカスしていけそうな動きが見え始めているのですごくポジティブな印象を持っていますね。ドメインが増えた時に期待通りに適応できるかというのはこれからですね。

原野EN：伊達さんがフロントエンドエンジニアにバックエンドのことを期待していいのか？という話をされるのは非常に面白いですね。

伊達EN：私はフロントエンドエンジニアとして入社したんですけど、昨年の6月くらいに当時所属していたチームの人数が一時的に減ったことがきっかけで、今はフロントエンドもバックエンドも両方やっているという感じなんですよね。

原野EN：伊達さんは、「自分ができているんだからみんなできたっていいでしょ？」というスタンスでいっても面白かったんじゃないかと思いますが（笑）

伊達EN：もしかすると、私の動きを見てくれていたので、他のチームメンバーも近い動きをしてくれたのかもしれないですね（笑）