この記事は、アソビュー Advent Calendar 2025の19日目（表面）です。
はじめに
アソビューでアジャイルコーチ・エンジニアリングマネージャーをしている川又です。
皆様、2025年はどんな年でしたか？
私は担当するプロダクトが変わったり、アジャイルコーチに挑戦したり、はたまたエンジニアリングマネージャーになったり、今思い返せば色んな変化があった年でした。特にアジャイルコーチとして社内の様々なプロダクト開発チームと関わり始めたことで、各チームが大切にしている価値観や工夫、強みが見えるようになりました。一方で、チームを一歩引いた立場から見るようになったことで、個々の努力や工夫だけではどうにもならない「構造的な難しさ」も、同時に見えてくるようになりました。
今回はコーチングをする中で感じた、事業会社におけるスクラムの難しさと、スクラムマスターがどう多方面に支援を行えば良いのかについて解説したいと思います。
事業会社で取り組むスクラムの難しさ
私はアソビューに入社する前はSIerで、受託開発の現場でスクラムを実践していました。受託開発におけるスクラムは、発注者と受注者という契約と責任の所在が明確に分かれた関係性の中で進める必要があり、対等な協働が難しい環境でした。顧客に時間を作ってもらうことができず、きちんとプロダクトの価値に責任を持ったプロダクトオーナーを立てることができず、"スクラムの形をした顧客の移行推進プロジェクト"を繰り返し行なっていた状態でした。
その記憶があるため、きちんとプロダクトの価値に責任を持ったプロダクトオーナーや親身になってくれるステークホルダーが社内に在籍している事業会社で実践するスクラムは、とてもやりやすくアジャイル開発の恩恵を受けやすい環境だと思っていました。
しかし実際にやってみると、事業会社特有の難しさがありました。
様々な職種のステークホルダーがいること
事業会社におけるプロダクト開発には、営業・ビジネス企画・カスタマーサポート等、非常に多くの職種の方々が関わっています。それぞれが異なる専門性を持ち、日々追い続ける指標や目標も違います。
例えば
- 営業は短期的な売り上げや案件獲得数の数字が大事
- ビジネス企画は中長期の事業成長を重視したい
- カスタマーサポートはよりお客様の声が大事
- エンジニアは技術的負債や品質リスクに目が向きがち
みんな同じミッションを持っていても、その実現方法や優先順位が全く違います。だからこそ同じ課題を見ていても、以下のような様々な見え方になっています。
- 営業にとっては今期の数字に直結する案件対応に見える
- ビジネス企画にとっては中長期的に伸ばすべき事業の打ち手に見える
- カスタマーサポートにとっては今まさに困っているお客様の声に見える
- エンジニアにとっては避けられない技術的負債やリスクの温床に見える
誰も間違っていません。ただ見方が違うだけです。この多様性こそが事業会社の強みでもありますが、これらの意見を適切に吸い上げ検査・適応する環境づくりをスクラムマスターは行う必要があり、また吸い上げた意見をもとにプロダクトオーナーが的確な判断を下す必要があります。
同じ会社の仲間だからこそ生まれてしまう「おまかせ状態」
受託開発においては発注者は適切なベンダーを選んで予算を確保し、最終的には成果物に責任を持たなければいけません。また発注者は専門家として説明責任を果たす必要があり、方針やリスク、進捗を丁寧に共有しながら進めていきます。いわば発注者・受注者という関係そのものがコミュニケーションの強制力となっているのです。距離があったとしても対話せざるを得ません。
一方で、事業会社におけるプロダクト開発の関係者は全員が「同じ会社の仲間」です。お互いの確認・説明責任はありません。 そのため、営業・ビジネス企画・カスタマーサポートといったビジネス側からはこんな空気感が生まれてしまうことでしょう。
- 「技術のことはプロに任せた方がいい」
- 「忙しそうだから、細かいことは伝えない方がいいかな」
- 「開発に時間を割いて欲しいから、手前で考えるべきことは自分たちで考えてあげなきゃ」
- 「きっといいものを作ってくれるはず」
これらは信頼の現れでもありますが、おまかせ状態を生んでしまうことも少なくありません。 結果としてビジネス側は「今どんな判断が下されどんなふうに作っているのかわからない」と感じ、開発側は「ビジネス側が何を本当に求めているのかが見えない」と感じることでしょう。 事業会社においては、意図的にお互いのことを知って会話する機会を作らなければ、徐々に溝が生まれていってしまうのです。
孤独になりがちなプロダクトオーナー
この溝はビジネス側と開発側の間にあるだけではありません。この両者の橋渡しや、ビジネス側の中で揺れ動く優先度を調整するコストをプロダクトオーナーがすべて一人でかぶっている可能性があります。スクラムにおいてはプロダクトの価値最大化を担う意思決定者ですが、それに見合う決定権限が会社から必ず付与されているわけではないため、結果として板挟み状態となってしまうプロダクトオーナーは非常に孤独になりやすい役割なのです。
こういったビジネス/プロダクトオーナー/開発の溝が、事業会社におけるスクラムのやりづらさに繋がっているのではないかと思います。
溝ができた結果、どんな状態になってしまうのか
ビジネス/プロダクトオーナー/開発の溝が生まれると、プロダクト開発は表向き静かに進んでいるように見えて、実際には以下のような状態に陥りやすくなります。
- 社内受託化
- ビジネス側「いつまでにこういう機能が欲しい」
- → プロダクトオーナー「この画面にこの機能をこういう風に追加してほしい」
- → 開発側（手段の妥当性を検証することもなく）「わかりました」
- フィーチャーファクトリー化
- 開発側は何のためにこれを作っているのかわからない
- 作った量やスピードだけに注目がいってしまう機能工場
- 納期駆動開発チーム
- 生み出す価値がなんなのかは開発者だけではわからず、他の関係者に聞きに行かなければいけない
- 聞きにいく勇気がなく、目の前にある要求仕様と納期駆動で開発してしまう
- 本来は長期的な保守性を考慮した機能設計・実装方針を取るべきだが、間に合わせるために技術的負債となり得る選択肢を取ってしまう
- また開発チームが背景や生み出す価値を理解していないため、ユーザーが欲しているものとは違ったものが出来上がる可能性が高くなる
もちろん、事業ドメインや組織文化によって状況は大きく異なると思いますが、少なくとも私が関わってきたチームでは、このような構造が見えました。
溝にかけるべき「越境の橋」
ここまで述べてきたように、ビジネス/プロダクトオーナー/開発の溝は、誰か一人の責任で発生しているわけではありません。むしろ、それぞれが自分の役割を全うしようとするが故に自然と生まれてしまうもので、すべての溝を埋めることは難しいでしょう。
この溝は、スクラムガイドに書かれているスクラムイベントをただ回しているだけでは埋まりません。スクラムはあくまでも軽量なフレームワークであり、自分たちが取り組んでいるプロダクトやそのフェーズ、人間関係や立場を考慮してうまくスクラムを実践できる環境を作る必要があります。
では、この溝をどうすれば良いのか。
私はスクラムマスターが積極的に「越境の橋」をかけていくことが必要だと思います。
越境は、単に組織や役割の境界線を跨ぐことだけではありません。境界を超えた先にいる相手の気持ちや立場を知り、理解し、同じミッションに向かって努力するための関係性を結び直す行為です。ただ、関係者に対して「もっと越境していこう」と言うだけで、みんなが越境してくれるでしょうか？前述した、溝ができた結果の状態に陥ってしまっては、とても越境する勇気はないでしょう。
そこで必要なのが、スクラムマスターが積極的に越境しビジネス/プロダクトオーナー/開発に姿勢を示すことで、皆が「渡っても大丈夫」と感じられる越境の橋をかけることです。
どうやって橋をかけるか
越境の橋をかける行為は、ビジネス/プロダクトオーナー/開発それぞれの気持ちに寄り添い支援することです。多方面に対する支援については、スクラムガイドでも触れられています。
スクラムマスターは、さまざまな形でスクラムチームを⽀援する。
・⾃⼰管理型で機能横断型のチームメンバーをコーチする。
・スクラムチームが完成の定義を満たす価値の⾼いインクリメントの作成に集中できるよう⽀援する。
・スクラムチームの進捗を妨げる障害物を排除するように働きかける。
・すべてのスクラムイベントが開催され、ポジティブで⽣産的であり、タイムボックスの制限が守られるようにする。
スクラムマスターは、さまざまな形でプロダクトオーナーを⽀援する。
・効果的なプロダクトゴールの定義とプロダクトバックログ管理の⽅法を探すことを⽀援する。
・明確で簡潔なプロダクトバックログアイテムの必要性についてスクラムチームに理解してもらう。
・複雑な環境での経験的なプロダクト計画の策定を⽀援する。
・必要に応じてステークホルダーとのコラボレーションを促進する。
スクラムマスターは、さまざまな形で組織を⽀援する。
・組織へのスクラムの導⼊を指導・トレーニング・コーチする。
・組織においてスクラムの実施⽅法を計画・助⾔する。
・複雑な作業に対する経験的アプローチを社員やステークホルダーに理解・実施してもらう。
・ステークホルダーとスクラムチームの間の障壁を取り除く。
抽象的な書き方であまりイメージが湧かないと思います。例えば、私は以下のようなことを実践しました。
プロダクトオーナーと一緒にビジネス側と会話をする
ビジネス側の調整役をプロダクトオーナー一人が担う必要性はありません。まずは一緒になってビジネス側と会話する時間を設け、ビジネス側の目線を共有してもらったり課題をヒアリングします。例えば営業・プロダクトオーナーと一緒に商談に参加して同席したメンバーと意見交換をしてみたり、サービス運用を担うビジネスメンバーに日々の運用業務における課題を聞いてみると良いでしょう。これらを元に、プロダクトオーナーがプロダクトバックログアイテムを作成し並び替えるのを手助けしてあげましょう。プロダクトオーナーが開発者にプロダクトバックログアイテムの背景や目的を説明する際には、より分かりやすい言葉に噛み砕いて補足してあげると良いと思います。
またビジネス側が日々使う言葉（例えば営業だけが使う専門用語など）をできるだけ持ち帰り、開発者との会話で積極的に使ったり説明してあげると良いでしょう。ビジネス側と開発側に共通言語が生まれ、お互いが同じ目線で会話しやすくなります。
ビジネス側に開発について理解してもらうようティーチングする
ビジネス側からすると開発側がブラックボックス化しており、要求に対しどうやって開発しているのかわからないと思います。スクラムの細かな役割やスクラムイベントについて説明する必要はありませんが、「我々は不確実性の高い課題に対して変化に対応するためにスクラムという手法を選択しており、関係各所への透明性を保ちながら検査・適応を繰り返し開発を進めているんだ」ということをビジネス側に説明し理解してもらいましょう。
全員のゴールに対する目線をできるだけ揃える
全員が同じゴール（ミッション、プロダクトビジョン、事業目標等）を掲げていても歩み寄ることをせず各々で進めていては、お互いが違うゴールを追っているように見えてしまいます。定期的に全員が集まりゴールに対する進捗を確認する場を設けましょう。プロダクトゴールはスプリントレビュー内で進捗を確認するのが理想です。
また、ゴールに向かって取り得る選択肢が多くて悩んでしまう場合は、全員でインパクトマッピングを行うと目線が揃いやすく効果的です。インパクトマッピングについては「IMPACT MAPPING インパクトのあるソフトウェアを作る」という書籍が参考になります。ただし関係者が多い場合は1テーブルを囲えるくらいの人数になるようチーム分けを行うなど、工夫が必要です。
まとめ
事業会社で実践するスクラムの難しさは、プロセスやスクラムイベント運営だけではなく、ビジネス/プロダクトオーナー/開発の間にできる溝に原因があります。その溝は誰かのせいではなく、それぞれが真剣に役割を全うしようとするが故に自然と生まれてしまうものです。だからこそ、スクラムマスターが最初の一歩を踏み出し、越境の橋をかけ、全員が渡りやすくなる環境を作り出すことが重要になってきます。
チームに対しスクラムガイドの理解を促しスクラムイベントを良いものに改善していくことも大事ではありますが、プロダクト開発に関わる「仲間」に目を向け、相手の気持ちに寄り添い理解するところから始めてみてはいかがでしょうか。
私もアジャイルコーチとして、様々な組織間でできてしまっている溝に自分たちで橋をかけられるよう、もっと横断的なコーチングを行っていきたいと思います。
アソビューでは、一緒にプロダクト開発に取り組んでいただけるメンバーを大募集しています！カジュアル面談も実施しておりますので、少しでもご興味をお持ちいただけましたら、ぜひお気軽にご応募ください！
