大規模組織でスクラム開発を成功させる鍵はステークホルダーと現場の期待値調整 - 大規模組織が取り組むべきLeSSを採用させる秘訣 | AEON TECH HUB開催レポート Session#2

多くの開発現場で採用されているスクラム開発ですが、複数チームを有する大規模な組織においてスクラム開発を実施する際はLarge-Scale Scrum（LeSS）と呼ばれるフレームワークの活用を検討する必要があります。

2024年5月に開催された「AEON TECH HUB」では、「大規模スクラム成功の秘訣」と題して、大規模組織におけるスクラムの重要性やLeSSを採用する上で留意すべき点、さらにフィーチャーチームの組成で抑えるポイントについて語るイベントとなりました。

今回は2回に分けてお届けする開催レポートの後編であり、パネルディスカッションの様子をお伝えします。

▼ Session#1の記事はこちら
https://engineer-recuruiting.aeon.info/aeon-tech-hub/interviewevent-reportATH-4_1

▼イベント詳細ページはこちら
https://aeon.connpass.com/event/313734/

【目次】

パネルディスカッション

LT終了後、5つのテーマをもとにしたパネルディスカッションが行われました。大規模組織におけるスクラムの重要性やLeSSを採用する上で留意すべき点など、各登壇者による有益な議論がなされました。

ディスカッションテーマ1： 大規模スクラム・LeSSって普通のスクラムと何が違うの？

そもそもチーム規模が変わることでスクラムのやり方を変える必要あるの？

池田ここからパネルディスカッションに入っていきます。今回のイベントにはスクラムを実施する方だけでなく、そうでない方も参加されているので、最初のテーマでは「なぜチーム規模が変わることでスクラムも変えていく必要があるのか」をお話いただければと思います。

貝瀬スクラムのなかには、プロダクトオーナー、スクラムマスター、開発者という役割があるんですが、スクラムとLeSSでは開発者の人数規模が異なってきます。スクラムの開発者は数名〜10名程度に対して、LeSS（LeSS Huge）では10名以上の開発者でスクラムを行うためのフレームワークとなっています。後者における人数の上限はない認識ですが、ちなみに荒瀬さんは過去に何人規模でLeSS Hugeを行っていましたか？

荒瀬140人くらいだったかと思います。今も持続してます。

貝瀬開発者が10名以上になったらLeSSを始めて、30〜50名規模になってきたら、LeSS Hugeの検討が必要になると考えてもらうとわかりやすいでしょう。また、スクラムにはプロダクトオーナーという役割も不可欠です。こちらはスクラムとLeSSでは共に1人配置する形になりますが、LeSS Hugeの場合はプロダクトオーナーのほかにエリアプロダクトオーナーも追加で存在することもあります。荒瀬さんは何人くらいエリアプロダクトオーナーがいましたか？

荒瀬エリアプロダクトオーナーは3人います。

貝瀬次はスクラムイベントのなかで「スプリントプランニング」というものがあるのですが、これはスクラムで一番最初に行われるもので、基本的にはスプリントと呼ばれる短い期間で成果を出すための打ち合わせだと思っていただくといいでしょう。スクラムの場合は関係者全員（プロダクトオーナー、スクラムマスター、開発者）がスクラムガイドで定義されている3つのトピックを扱うことになります。それがLeSS（LeSS Huge）になってくると、3つのトピックを全員で行うのではなく、パート1やパート2といった区切り方をし、二部構成でトピックを扱う形になります。

また、スプリントの一番最後にやる「スプリントレトロスペクティブ」では、関係者全員で品質と効果を高める方法を計画するスクラムイベントです。自分たちの働き方や働く環境を見直すことで、品質や効果を高める方法を考えていく目的があります。LeSS（LeSS Huge）の場合も同様にスプリントレトロスペクティブを実施しますが、スクラムチームが2つ以上存在しますので、各チームで行うスプリントレトロスペクティブ以外に、チームの代表者が集まって組織の課題と向き合う「全体レトロスペクティブ」も行うのが特徴です。

次はスクラムのなかにあるリファインメントです。こちらはスクラムガイドに文字は出てきますが、ルールとしては定まっておらず、スプリント期間で実施すべきタイミングも決まっていません。どのような活動かと言うと、関係者全員やステークホルダーが参加して、プロダクトバックログアイテム（何を開発するか、誰のためにどういう価値を提供するか）を小さくかつ詳細になるように分割したり、わかりやすく定義したりしていく取り組みです。一方でLeSS（LeSS Huge）になってくると、リファインメントが公式ルールとして定義されていて、一般的には3種類ほどのルールが定められています。

最後に、先ほど述べたプロダクトバックログアイテムを優先順位付けしたリストの「プロダクトバックログ」を説明したいと思います。スクラムでは、1人のプロダクトオーナーに対して、1つのプロダクトバックログというルールが設けられています。LeSS（LeSS Huge）に関しても、その考え方は基本的に変わりませんが、エリアプロダクトオーナーもいますので、その方が管理する「エリアプロダクトバックログ」も存在しています。

池田通常のスクラムとLeSSを切り替えず、無理して進めるとどう困ってしまうのかを教えていただけますでしょうか？

荒瀬私のなかでのスクラムとLeSSの選択基準は、「チームが自己管理しやすいか否か」で判断しています。スクラムを続けていくなかで、チームの規模が大きくなっていくと、自己管理が難しいと感じるフェーズが訪れるので、そのタイミングでLeSSに切り替えていくイメージですね。

貝瀬自己紹介LTで最初からLeSSを採用していたとのことですが、それはなぜだったのでしょうか。

荒瀬最初からLeSSをやるパターンというのは、プロジェクトに必要なリソースが最初から決まっている場合です。ロンチ日に向けてプロジェクトに必要リソースがプロジェクト開始までに確保されている場合ですね。一大イベントのプロジェクトや大きめの新規プロダクト開発にみられます。

池田あくまで、スクラムからLeSSへの切り替えが発生するのは、プロダクトが成長してチームが拡大していった場合ですよね？

荒瀬そのパターンもありますね。逆を言えば、スクラムを続けていても、自己管理ができるのであれば、LeSSへ切り替える必要はないと思っています。

貝瀬想像しやすいのがスクラムイベントで、そのほとんどはチーム全員が必須で参加するため、仮に人数が多くなったら、管理しづらくなるのが明白だと思います。

翁長当初は、スクラムチーム組成後、1年半位までは1つのチームだけで運用しようと考えていました。しかし、組成後1年弱位のタイミングで経営層から「開発量を増やしたい」という要望があったので、チーム分割を前提に開発者の人数を増やしました。すると、通常15分で開催しているデイリースクラムが、エンジニアが8名にもなると、時間内に収まらなくなることが増えてきましたし、一つひとつのスクラムイベントやチーム全体の管理に難しさを感じるようになりました。チームの分割に際しては、スクラムチームを2つ以上に分けても1つのプロダクトバックログで管理しなければならないこと等から、LeSSのプラクティスを取り入れるようにして、実際に運用するようになりました。

ディスカッションテーマ2： LeSSを採用する際の秘訣は？

大規模スクラム・LeSSのチーム組成はどうやって進めると良いの？標準化するところと個別化するところはどこ？また、継続する上での難しさは？

池田テーマの2つ目について移りたいと思いますが、実際にLeSSを採用するとき何に気をつけるべきなのか。チーム組成や標準化と個別化のバランス、継続する上で留意する点についてお話いただけますと幸いです。

菊池前提として開発者やプロダクトオーナーなど、チーム全体が「LeSSを採用したい動機」を持っていないと、スクラムからLeSSへ切り替えてもうまく運用していくのは難しいと思います。逆に、1つのプロダクトバックログで管理していくLeSSの合理性や妥当性が、チーム全体に浸透されているのであれば、問題なくLeSSを進めていけるのではないでしょうか。

ただ、「チーム全体に浸透させる」ことが最もネックになるのではと考えており、その辺りは実践されている登壇者の皆さんに伺ってみたいなと思います。LeSSを導入することでプロダクトの価値が最大化されるなど、そのような認識をチーム間で持つことができれば、組織全体でLeSSを採用していく流れになると考えていますが、そこにギャップがあるとLeSSを導入したとしても、期待される効果が得られないのではと思っています。

荒瀬アジャイル開発をしたい、組織の課題を解決したいといった形で最初に依頼がくるのですが、すごく大事にしているのは「この会社・組織の将来像です。」在り方や願いですね。

そこをまずは輪郭レベルでもいいので、明らかにすることを大切にしてます。会社や組織のトップの方とお話させていただき、将来像を実現する戦略と戦術としてのLeSSの活用事例をお話しします。私の経験上、大規模になればなるほど、上位レイヤーも横のステークホルダーも巻き込む必要性が高まります。それらの方々にLeSSを理解してもらうことが重要だと思います。

貝瀬お客さまにLeSSの導入を選択いただく場合に気を付けているポイントは、「ビジネス活用を高めていくために『選択』と『集中』をしたいのか」という観点から話すようにしています。

例えばLeSSでやらない場合、各スクラムチームに細かい範囲のプロダクトを持たせて、プロダクトバックログの優先順位を付けられますが、会社全体で見ると、スクラムチームの優先順位と会社の優先順位が前後してしまいます。LeSSにするメリットは、全チームでプロダクトバックログが1つなので、プロダクト全体や事業全体の優先順位を鑑みることができ、結果として会社のビジネス価値向上に効果があることです。

あとは現場レベルで起きる課題もヒアリングしつつ、「LeSSの場合はこうなる」というのを細かく丁寧に説明していき、LeSSの採用が決まった場合には導入支援させていく流れになっています。

池田お話を聞いていると、LeSSを経験したことがない人が始めようとするのは結構ハードルが高いのでしょうか。経験や知見の持っている人に支援してもらった方が効率的かとは思いますが、未経験者がLeSSを導入するのは難しいと考えていますか？

貝瀬前提として「スクラムの経験がないと難しい」と言えるでしょう。

翁長私は手探りでやっていますね。最初から完璧なLeSSを目指すよりも、LeSSで有効とされているプラクティスをうまく取り入れながらやっていくスタンスを大事にしています。いかに価値を順番に実現するための活動を阻害しないようにするかという考えのもとで、毎日模索しながら取り組んでいますね。

池田いきなりLeSSヘ切り替えるよりも、徐々に切り替えていくケースが多いんでしょうか？

貝瀬ケースバイケースですが、原則は下手にいじらずにそのまま導入する方がいいと思います。なぜなら、スクラム（LeSS）は理論や実験によって裏付けされたフレームワークだからです。

翁長弊社ではチームでのスプリント計画は二部構成でやっていますし、全体レトロスペクティブも行っています。そのなかで、LeSSのフレームワークに倣いきれていないのがリファインメントの実践です。ただ、リファインメントに関しても「チームとしてやるべきこと」と「全体でやるべきこと」は意識してやっているので、 LeSSの理想のあり方に早く追いつけるように頑張りたいと思っています。

ディスカッションテーマ3：大規模組織における期待値調整はどうすれば良いの？

上長や自分の手の届かないチームとの期待値調整（導入、拡大、継続的成果創出）の難しさは？

池田このテーマでは、上長や自分の手の届かないチームと、どのように期待値を調整していけばいいのかを深掘りしていければと思います。

荒瀬LeSSを導入することで、上長やステークホルダーとコンタクトしやすくなると私は思っています。ダイレクトコミュニケーションも頻繁に発生します、その結果、期待値も調整しやすくなるでしょう。私の開発チームのスプリントは1週間ですが、週1で上長やステークホルダーに集まっていただいて、同じプロダクトを見ながら対話してます。対話からチームとの期待値のずれを把握したり、お互いの認識や思いを理解したりしてます。

池田納得してもらうために、見るものや基準が同じというのは良いことですね。

荒瀬そうですね。頻繁に期待値や目標、ビジョンについてもメッセージしてます。ただし組織階層が増えるほど遠く感じ、期待値や目標についても上層部とずれが発生しやすくなるわけです。つまり、そのようなカスケードダウンした階層を設けない方がいいと私は考えています。かといって、レイヤーごとに意識することが違うので、一緒にはしない方がいいでしょう。

貝瀬少し補足すると、スクラムもLeSSも「ステークホルダーとの交渉や対話をしなさい」というルールになっているため、現場とステークホルダーの意思疎通が重要になってきます。最初のうちは「見学だけでもいいので来てください」と伝え、軽めのところからスタートして、徐々に現場の実態を理解してもらうように取り計らっていけば、期待値調整に関してはそこまで難しくないことなのではと思っています。

菊池活動としては、権限を持つステークホルダーから継続したフィードバックをもらう接点をもつことが大事だなと感じています。スクラムにおいても、価値を享受するステークホルダーが同席した上でレビューを行い、フィードバックをもらって次に活かすことをやらないと、いつまで経っても期待値のギャップは埋まっていかないでしょう。

「現場で考えるゴール」と「ステークホルダーが期待するゴール」のギャップが埋まらなければ意味がないわけで、継続的に両者で対話していくことが求められるのではないでしょうか。

貝瀬スクラムチームの役割としては定義されていませんが、LeSSのフレームワークにはマネージャーの役割が登場します。なので、LeSS導入においてはマネージャーを巻き込まないとうまくいきません。そもそも人数の多いチームを想定しているフレームワークなので、マネジメントレイヤーを巻き込むのが、まずやるべきポイントだと言えます。

翁長「いかにステークホルダーを巻き込むか」を考えたときに、具体的にどのような取り組みをされてきたのか皆さんへお聞きしたいです。私自身、最初に始めたときはビジネスサイドのプロダクトオーナーに来てもらうことすら、なかなか大変だったなと思っていて。さらに、その向こう側にいるステークホルダーをどう巻き込めばいいのかを考えるのが難しいと感じています。

荒瀬職種や組織が違っても、成し遂げたいことは共通しているはずなので、制約や時間の問題だと思うんですよね。そこをまずは整理していくことから着手してみるといいのではないでしょうか。

貝瀬一番わかりやすいのは、スクラムの説明ではなく実際に見ていただくことです。30分でもいいので、「1回だけ見てください」と伝えることが大事だと思います。ただ、うまくいっていない状況のなかでステークホルダーに見てもらっても、期待外れで終わってしまいます。そうならないように、まずは小さく始めて徐々に大規模スクラムやLeSSに移行していくのが一般的なアプローチ手法になっています。

ディスカッションテーマ4：リモートワークやツールの進歩に伴い、スクラムの進め方も変化してきた？

池田スクラムだとホワイトボードや付箋を用意して実施するイメージですが、リモートワークやツールの進歩に伴って、スクラムのやり方はどのように変化しているのでしょうか。

菊池僕が一緒に働いている開発メンバーは、日本の拠点に加えてインドの開発拠点も一緒になって、ひとつのチームを作ってスクラムを行っています。こうしたなか、進め方自体はそこまで変わっていないと思います。

例えば、デイリースタンドアップでやりたいことは何かを考えた場合、仮にタイムゾーンが違ったとしても、メンバーにとって知りたいのは「ゴールに対しての現在地」や「そのギャップ」なわけです。タイムゾーンが合わなくても、チーム自身が各イベントで得たいことやイベントに対する意義を理解していれば、特定の制約に縛られずに進められると考えています。

池田スクラムに対するマインドセットは国によって違うものなのでしょうか？

菊池国民性よりはスクラムのフレームワークを活用するうえで「どれだけ使うサービスが身近かどうか」がメンバーにとっては大事だと思いますね。メルカリは日本とアメリカのそれぞれでサービスを展開していますが、当然アプリが使えなければ、サービスの課題感を把握しにくいですし、「価値」に基づいて自分たちの在り方を判断しづらいわけです。

荒瀬私もベトナムのオフショア開発を経験しましたが、やはり海外のメンバーは日本のマーケットやターゲットユーザーのことがわからないんです。どうしても、日本とベトナム側で作りたいものの詳細な部分においては、ずれが生じてしまうので、そこは綿密に細かくプロダクトバックログアイテムを定義しなくてはなりませんでした。とはいえ、国は違っても協働していいものを届けたいという思いは同じだったと思いますね。

池田スクラムをやることでバックログに書き出せるので、認識合わせはしやすそうだなと思っていますがいかがですか？

荒瀬バックログに書く量や項目に差はありましたね。

池田その差を埋めていくのがプロダクトオーナーの役割ということですかね。

荒瀬ブリッジSEが間に入って、サポートしていたと思います。

貝瀬スクラムだとスクラムマスターがマインドセットの醸成や、良いプロダクトバックログの管理方法の教育に責任を担うことになりますね。

池田翁長さんはこのテーマについてどうお考えですか？

翁長内製チームを組成したときから、基本的にリモートで開発しているので、リモートワークでも利便性の高いツールを活用しています。前職と比較すると、当時の支援先はRedmineを使う以外はアナログでスクラム開発を行っていました。スプリントの最後に行うKPTとかの振り返りでは付箋を使用していました。その仕組み自体も、今はツールでできるようになっていますが、ツールはうまく活用するものであって、「どうやるか」という部分はオフラインでもリモートでも変わらないと思っています。

リモートの場合、近くにメンバーがいないので、相手が何をやっているかがわからないので、カメラオンにしたりチャットを使ったりと、できるだけ意思疎通できるように意識することが必要になるでしょう。

荒瀬私の会社もコロナでフルリモートになりましたが、それまでは壁一面を使って付箋を貼り、「ここを見れば全てがわかる」という状態で一元管理していました。そうした状況からオンラインに変わることで、最初はやりづらくなると思っていましたが、結果的にはかなり選択肢が増えたなと感じています。例えば日本全国からさらには世界から優秀な人材の採用も可能になりました。

弊社の場合はフルリモートでもオンサイトで集まってもいいので、チームビルディングやリファインメントをする際はオンサイトで集合するやり方もできるわけです。逆にスプリントレビューをする場合には、数百名を超えるメンバーが集まるので、オンサイトでの開催はハードルが高くなるので、オンラインで実施した方が集客しやすいと言えます。

壁も貼ってはいけない箇所もあったりと、何らかの制約があったわけですが、オンライン環境ではホワイトボードツールやレイアウトを自由に使うことができ、要所に応じて形態を変えていけるのは、大きなメリットだと思いますね。

翁長リモートワークが普及する前は、スクラムイベントを開催するための場所が取れなくて、時間をずらさなければならないこともありましたが、今ではそれが全くなくなりました。確実に決めた時間で実施できるのは、とても効率的になったと思います。みんなで会いたいときは、会いたいメンバーが対面で実施する自由度も向上しました。

荒瀬オンラインだとノンバーバルコミュニケーションがしづらく、相手がどういう感情なのかが読み取れないので、そこは工夫が必要だと考えています。オンライン上で気兼ねなく雑談できる場を作ったり、雑談時間を定期的に作ったり、チームビルディング回数を増やすなど工夫が大事になるでしょう。

貝瀬オンラインかオンサイトのどちらがおすすめかと言うと、圧倒的にオンサイトの方がおすすめです。ツールもアナログの方がいいでしょう。もし、オンラインになった場合はなるべくオンサイトでやりたいことを実現できるツールを選定するべきです。ツールにはプロダクトバックログを管理するツールと、スプリントバックログを管理するツールがあります。それぞれを別々のツールにするのがおすすめです。

特にスプリントバックログは可能な限り、チケット管理ツールではなくホワイトボードや付箋に近いツールを選ぶようにします。プロダクトバックログに関しては、プロダクトマネジメントツールやスプレッドシートで管理しても問題ないでしょう。

菊池スプリントバックログにおいて、チケット管理ツールよりもホワイトボードツールの方がいいのは、進捗状況の更新のしやすさや視認性の良さ、気軽に追加や分割の意思決定ができること。本質は結局、「ゴールに近づくためにどうしたいか」だと思うので、チケット管理ツールを管理するのが目的になってはいけないわけです。

ディスカッションテーマ5：「組織構造が文化を作る」というけど、実際に構造は変えられた？

構造が文化に与える影響にはどのようなものがあった？

池田最後は皆さんにとって、永遠のテーマかもしれませんが、「組織構造が文化を作る」ために取り組んでいることや現況において課題感を抱いていることがお聞きできればと思います。

荒瀬当社ではデザイナー部門や開発部門、企画部門、ビジネス部門といったコンポーネント単位の組織から「プロダクト開発本部」というフィーチャーの組織へと変わりました。あとはアジャイルコーチチームが新設されたり、スクラムマスターが専任でピボットできるようになったり、プロダクトオーナーの役割が会社全体で認知されるようになったりしています。

貝瀬組織構造を変えたことで何か変化はありましたか？

荒瀬セクショナリズムの考え方は消えてきましたね。個々の視座とか視野は変わったと思います。共通言語も職種間で閉じたものではなく、職種横断した共通言語が増え、コミュニケーションを取る相手や話す内容も変化してきていると実感しています。

菊池コンポーネントチームからプロダクト全体のフィーチャーチームへと移行する場合に、メンバー間でのハレーションは問題にならなかったのか気になります。弊社の場合だと、特定の職能にもとづいて分かれていたりするんですけど、その辺りいかがでしょうか。

荒瀬ベストプラクティスがないので、もちろん何か打ち手を打つと一定のリアクティブがありますが、コンポーネントチームからフィーチャーチームにするときのハレーションを気にするよりも、コンポーネントチームを維持した場合の課題の方が大きかったですね。

菊池弊社の場合は、コンポーネントチームから各プロジェクトへのフィーチャーチームへ組成され、プロジェクトが終わると消滅していく性質を持っています。個人的には安定したフィーチャーチームでやりたいと思っていますが、まだ組織全体では変えるための意思決定を醸成できていない状況だと感じていますね。

貝瀬フィーチャーチームについて補足すると、先ほどのコンポーネントを全てチーム内で完結できる多職能な組織体系です。エンジニアもサーバーサイドからフロントエンドまで全部できなくても良くて、チームとしてできればOKというチームになっています。

スクラムやLeSSを実施する場合、最初はクライアントエンジニアやサーバーサイドエンジニアと専門職能を持つ人が集まって組成される場合が多いですが、徐々にスクラムの文化や価値観が浸透していくと、自然と職能が異なる人同士でペアプログラミングが行われるようになってきます。お客さまへの価値提供を最優先することが共有されていくことで、一人ひとりが多職能化していくのも、フィーチャーチームの特徴だと言えます。

荒瀬コンポーネントチームでは課題が明確に出やすいと思っています。私が過去に担当したA社とB社の統合プロダクト開発では、両社でフロントエンドやバックエンド、デザインなどを分担していました。それらの統合を試みた時にたくさんの問題が明らかになりました。

それらの改善手段のひとつとして、フィーチャーチームが挙げられます。とはいえ、フィーチャーチームになったからといって、いきなり全てが変わるわけではありませんので、チームの成長に投資は必要です。

翁長コンポーネントチームからフィーチャーチームへ移行する過程で、例えばバーチャル的にチームを組成するやり方は有効なのでしょうか？

チームとしては別々だけど、関わる人を同じチームという扱いにして、その効果を見てもらってフィーチャーチームへと移行していくのもいいのではと思ったのですが、この辺りの有用性について教えていただければ幸いです。

菊池LeSSの最初の導入でも、パイロットチームを設けて、少しずつ価値を見出していくと思います。また、実際のチームは異なっていてもお互いがスクラムやLeSSの価値観を理解している状態で「一緒にやろう」という風に立ち上がりさえすれば、自然と他チームと比べてイテレーションサイクルが短くなりますし、相対的に成功が見やすくなるのではないでしょうか。

荒瀬バーチャルチームの方が圧倒的にイニシャルコストが低いため、私は翁長さんのいうやり方は全然やっていいと思っています。フィーチャーチームの経験のない組織がフィーチャーチームを作るのは意思決定のハードルも高く不安も大きいです。

ただ気をつけるべき点がいくつあるのでお伝えすると、従前のコンポーネントチームでは、コンポーネント単位でチームがあり、それぞれで期待値調整やチームビルディングを行っていると思います。そこからバーチャルでフィーチャーチームを作ったときに、チームの育成を疎かにすると、あまり上手くいかないんですよ。フィーチャーチームで何を成し遂げたいのか。どういうあり方をすべきなのかを丁寧に説明し理解していただかないと、単に職種間でタスクを引き継ぎだけしてスプリントゴールを達成するだけで終わってしまうんです。課題に対する当事者意識に差が生じたりします。

そのため、フィーチャーチームをバーチャルで作った場合は、ライン組織と同等の育成の投資をすると良いでしょう。

貝瀬バーチャルでフィーチャーチームを作ると、レポートラインが実質2つになってしまい、マネージャーとプロダクトオーナーで言っていることがずれるリスクがあると思っています。

例えば、メンバーと上長との1on1で決めた目標とバーチャルチームで定めた目標がずれてしまうと、「自分の目標に置かれていないからやらない」という事態を招く恐れもあります。その辺りの懸念や留意事項をあらかじめ、マネジメントレイヤーに理解いただき、ケアしておくのが望ましいでしょう。

荒瀬フィーチャーチームが増えていくと「この職能の人材が足りません」ということも起きるので、そのリソースに関しては採用して育成していく必要がありますね。

菊池学習する余地を残したり、チーム全体で開発スピードを上げたりするところの価値観があってさえすれば、徐々に知識的なギャップの解消は進むとは思うんですが、どうしてもフィーチャーチームを作ろうと思うと「（現在足りない職能の人材を）採用しなくてはならない」というメンタルモデルになってしまうなと感じています。マネジメントレイヤーでも、フィーチャーチームで得たいことに対して、密に連携が取れていないと、ワークしていかない組織体系だと考えています。

荒瀬コンポーネントチームをフィーチャー化したときに、スキルの足りないチームが出てきてしまった場合、短期的には採用したメンバーが成長するまでアウトソーシングの力を借りるのも一手です。

イオンが主催するAEON TECH HUB #4、今回は大規模組織におけるスクラム開発という話題をテーマにさせていただきました！今後も、様々なテーマを取り上げていきますのでAEON TECH HUBをよろしくお願いします。

AEON TECH HUB #4開催レポートのその他記事もございますので、ぜひご覧ください。

▼ Session#1の記事はこちら
https://engineer-recuruiting.aeon.info/aeon-tech-hub/interviewevent-reportATH-4_1

イオングループでは、一緒に変革に挑んでくれる方を募集中です。カジュアル面談も実施しておりますので、少しでも気になった方はお気軽にご連絡ください。まずはざっくばらんにお話しましょう。