【内製開発Summit 2025】エレキ組込みソフトウェア内製開発現場の課題と改善。3つの改善策はチーム編成がカギ

ソニーグループの組織と内製開発の現状

まずソニーグループの組織を紹介させていただきます。スライドの左がソニーグループ株式会社、いわゆるホールディングス会社です。その右側に上から「ゲーム」「音楽」「映画」と続き、4つ目がいわゆる昔ながらの「エレクトロニクス」であるソニー株式会社があります。

その他、「半導体」「金融」なども展開しており、本当にさまざまな領域を手掛けているグループです。4つ目のエレクトロニクスをもう少し細かくすると、右側の細かな事業に分かれます。本日は、「ビデオ・サウンド」の立場からお話をさせていただきます。

ソニーのパーパスは「クリエイティビティとテクノロジーの力で、世界を感動で満たす」で、先ほどの主要な会社群、つまりメディアから金融まで、すべてこのパーパスのもと活動しています。さまざまな商品やサービスの実現にはソフトウェアの力が不可欠であるため、私たちのようなソフトウェアエンジニアは、ソフトウェアの力でパーパスに貢献すべく、日々仕事をしています。

一般的な大企業の開発イメージは、「企画や資料を作ったら、実装は外部委託に任せる」というものかもしれません。ところがソニーはほぼ全てを内製開発で大規模に実施しています。一部委託することはありますが、全行程をリードしています。IT系企業は、もともと委託から始まり内製化する場合が多いため、創業当初からずっと内製開発をしている点で、IT系とも異なります。



こちらのスライドのように、主要4社が全方位的にソフトウェア開発をしていますが、私が本日話すのはエレクトロニクスの組込み系となります。

私は、95年にソニー株式会社に入社してもう30年になります。ソフトウェアエンジニアとして、最初は車載機器であるカーオーディオやカーナビなどを作っていました。その後、ウォークマンを担当し、Androidウォークマンの初号機のプロジェクトリーダーや、組込み系の耳かけ型を担当。

サウンドプロダクトに移ってマネジメントの立場になり、プラットフォーム開発やクラウド開発環境などにも取り組みました。現在は品質CSセンターで品質戦略担当をしています。プライベートではフットサル、その後にビールと焼き肉、という生活です。

オーディオ製品の現場とクラウド開発環境

オーディオ製品の現場とクラウド開発環境を紹介します。スライドの左側はトランクベース開発とプロダクトラインを表しています。ベースとなるソフトウェアのトランクがありリリースする時に短期の安定化ブランチを作る運用です。

サウンドバーやAVレシーバー、ホームシアターシステムなどをワンベースラインで作っており、変更が必要になった時にはプルリクエストを上げ、全製品に対して1カ所で修正できます。2015年ごろから、各種製品向けのフィーチャーフラグで切り替えられるようにしました。

その前は製品ごとに個別ブランチが存在しており、10機種あればブランチが10個。つまり、1つの不具合を修正するのに10回のチェックインが必要でした。抜け漏れのチェックが非常に大変でしたが、改善してからは余計なコピーがなく、エンジニアの集中力が高まりました。その代わり高い品質で作らなくてはなりませんが、1カ所直せばすべての製品がよくなります。

ただし、課題もあります。年々機種が積み重なっていくため、1つのプルリクエストで10機種以上の確認をしなくてはなりません。その解決のために、スライド右側にあるクラウド開発環境の整備も同時に進めました。

ポイントは、クラウドでのビルドと自動テストです。「開発者数×プルリク数×製品数×ビルド＋テスト時間」という、かなりの規模でマシンを回さなくてはならず、ピークは数百台ほどのバーチャルマシンを起動します。つまり、課題をお金で解決したのです。

クラウド開発環境では、Dockerビルド、インフラストラクチャー・アズ・ア・コードなどを採用しています。面白い取り組みとして「機種別バイナリー差分検出」があります。プルリク前と後のビルドを両方回し、バイナリーのコードセクションやデータセクションを取り出し、md5sumチェックで差分を検出します。差分がない機種はテストの必要がないため効率化でき、また、フィーチャーフラグの間違いなども検出できます。他に、オンプレのJenkinsを用意し、実機自動テストも回しています。

ハードウェア製品のソフトウェア開発

ここからは内製の割合を説明します。ハードウェア製品のソフトウェア開発でよく言われるのが垂直統合と水平分業の話です。垂直統合の場合は、スライド左側のようにソフトウェアもハードウェアも内製となります。右側の水平分業になると一部調達や委託が入ってきます。

垂直統合で内製が多いほど開発コストは大きくなり、優位性も作りやすくなります。ただし開発コストがかさむ分、ビジネス規模が大きくなければなりません。右側に行くにつれ、開発コストは減りますが、優位性も減ります。ただし、製造を外部に任せたとしても、規模を大きくすることで「規模の経済」が効き、優位性を持つこともできます。

今日お話しするのは真ん中の列の「バランス型」の内容です。ハードウェアとソフトウェアを独立して選べず、ハードウェアの作り方に応じて、ソフトウェアをどこまで内製化するかで製品の出来が決まります。いずれにしても、最終製品は自社で品質保証する必要があります。



水平分業の組込み開発をチームトポロジーで表現するとこのスライドのようになります。『Team Topologies』という本によるとチームは4種類に分けられますが、昔は2～3種類のチームで十分作れていました。

現在はソフトウェアの規模が大きくなり、チームの数も増大しています。システムに至っては、例えば、自分たちでも作るAOSPのソフトウェア群、SoCベンダーのもの、自分たちで内製したものが存在すると、3段ほどのプラットフォームが積み重なる場合もあります。規模が大きくなるにつれて、非常に難しいチーム体制になります。

スケールするに従い、コミュニケーションコストが増大

チーム数がスケールすると、コミュニケーションコストが増えます。多数の専門家チームをまたがる要求の場合、要求1つで3チームほど、2つで6チームほどが絡み、コミュニケーションパスがどんどん増えていきます。

放っておくと、”偉い人”から「ソフトウェアの開発って、お金と時間がかかる割にできる要件が少なくない？」という指摘が入るでしょう。中を紐解くと、開発人数が増えるに従い全体の総工数は増えますが、「正味開発工数」と「コミュニケーションに費やされる工数」を比べると、前者の割合がどんどん減っていきます。

「会議をして、メールのやりとりをして、1日が終わる」という人が増えていきます。特に、社員と業務委託の方がいる場合、多くの場合”できる社員”がコミュニケーションを担当します。不具合チケットなど、開発用のチケットを投げ合ったり、何をするにも誰かにお伺いを立てなければならなくなったりして、開発人数をスケールしてもoutputがスケールしないことが課題になるのです。

ハードウェア製品では不具合対策がボトルネックに

次に、正味開発の部分をValue Stream Mapという手法を使って分析しました。典型的な組込みの場合、開発設計し、その後試作機を作り、テストし、不具合対策を経てリリースします。試作機生産はコストがかかるタスクですが、最初の評価のために多くの投資が必要です。投資回収は販売後になるので、投資回収期間をできるだけ短くしたいところです。品質の担保に必要な最小の期間でリリースするのが理想です。

ただ実際には、第三者テストの段階で、複雑に積み重なったソフトウェアの不具合が多数顕在化してきます。「アジアから調達したソフトウェア」「複雑なコミュニケーションで作られたソフトウェア」「前提の食い違い」などにより、不具合対策でデスマーチが起こります。この部分がボトルネックとなり、全体の生産性が決められてしまいます。

ボトルネックを最大限に活用させるために、十分に在庫を溜めようと考えます。この場合は未評価のソフトウェアが在庫となります。ところが、在庫が溜まると不具合の調査が非常に難しい。未評価のソフトウェアの不具合がお互いに関連して複雑性がN乗になり、対策工数が増えるという別の課題が生まれます。

長期の見積もりでサバを読む分、outputが減少

ソフトウェアの在庫をたくさん溜めるためには長期の見積もりが必要になります。「完成の確率分布」によると、「最速でできる期日」「最頻値」「50%の確率でできる期日（中央値）」「80%の確率でできる期日（現場の見積もり）」などバリエーションがあります。

ラインマネージャーは90～95%の確率でできる期日を採用し、最頻値の3倍ほどが妥当な見積もり期間になると言われています。ここには基準や正解が不明確な「サバ」が多く入っています。

ソフトウェアの見積もりは「約束」になりがちなので、大量のソフトウェア要件に対してはサバを読まざるを得ません。ところが、長期の見積もりでサバを読む分、outputが減ることになり、これも課題として考えます。

これまでの課題をまとめましょう。「開発人数をスケールしてもoutputがスケールしない」というチーム体制からくる課題が1つ。加えて、投資回収期間を短くすべきという制約に対し、「ソフトウェアの在庫が不具合対策の効率を下げる」「長期のソフトウェア見積もりでサバの分outputが減る」という課題がありました。

不確実性の高い場面でもコミュニケーションの爆発を防ぐ「多能工チーム」

ここからは改善の方向性を考えていきます。ひとつ目の課題は、コミュニケーションコストの増大でした。Complicated Subsystem teamに専門家たちが集まり、1つの要件に対する不具合対策をみんなでやらなくてはならず、かつ、それぞれが多数の要件を掛け持ちしているため共倒れになるのが従来型の組織です。

サッカーに例えると「ポジショニングサッカーはリスクに弱い」ということです。でこぼこのピッチでラグビーボールのようなボールを扱う場合、ポジショニングサッカーではうまくいきません。

ここで有効なのが「多能工チーム」です。つまりはStream-aligned teamのことで、さまざまな専門性を持つ少人数からなります。要求からリリースまでチームで閉じて活動するため、コミュニケーション量の爆発を防げます。

サッカーで例えると「団子サッカー」。私は子どもの試合の審判をしていたこともありますが、ボールの行く先が読めない場合、団子サッカーは強いのです。

多能工チームの編成によってコミュニケーションコストを下げる際、明日から、例えば20のStream-aligned teamに分けるのは無理です。書籍『Team Topologies』にも書かれていますが、岩を割るときのように、楔を打つとパカッと割れる面を分析する必要があり、さらに最初は1チームか2チームほどの規模から始めなくてはならないでしょう。

ここで、ぜひ紹介したいのが、『世界一流エンジニアの思考法』という書籍にある、優先順位についての項目です。優先順位をつけると、1番目も大事だが2～5番目も大事で、「できるだけ多くやる」という考えになりがちです。

ところが実は、「これしかやりません」「これ1つだけをやりましょう」という意識が非常に大事。Stream-aligned teamが、最も重要なものを1つだけやるように心がけた方が良いでしょう。

多能工チームの利点に戻ると、チームの中で「自分はあまりこの要件に関係ない」という人がいる場合もあります。それでも、同時にその1つに集中して一緒に取り組むことで、暗黙知の共有といったメリットもあります。

ボトルネック回避のためにソフトウェア自体の価値を上げる要件を増やす

2つ目の課題であるボトルネックには、「従来コース」のほかに「ボトルネック回避コース」を設けます。弊社でいう高画質や高音質、スタミナなど、ハードウェアの機能性能の価値を届けるソフトウェアを作る場合は、従来コースになります。

一方で、ハードウェアに依存せずソフトウェア自体の価値を届ける要件は、ボトルネック回避コースで進めます。例えば、ネットワークサービスやゲーム、リワード機能など。これらの要件を増やすことでボトルネックを回避して素早く価値を提供でき、結果的に生産性が上がります。

要件を1つずつ完成させる体制で決定を遅らせる

3つ目の課題は「長期のソフトウェア見積もりでサバの分outputが減る」です。見積もりにサバが入るのは事前に決めることが原因なので、スコープの決定を遅らせて見積もりを不要にすればサバは必要ありません。ただ、従来組織のままでは多くの人が掛け持ちで仕事をしており、要件の完成が締め切りぎりぎりに集約してなかなか上手くいきません。

そこでStream-aligned teamの作り方にすると、仕掛かり作業は必ず1つになり、リニアに要件が完成していきます。ただこの場合、“偉い人”から「決定を遅らせると周りが困るんじゃない？」という指摘が入るかもしれません。例えば、製品のカタログやウェブサイトの制作などです。

これらは最後に決まってから取り掛かるのではなく、1つずつ決まるものに対して一緒に動いてもらいましょう。大事なものから決まっていくので、ウェブサイトの下書きを先に作っておいてもらう、といった方法です。そのような動き方で決定を遅らせることが、課題に対する対策となります。

最後に、これまでの話をまとめます。

・課題１：開発人数をスケールしても、outputがスケールしない
・課題２：ソフトウェアの在庫が、不具合対策の効率を下げる
・課題３：長期のソフトウェア見積もりでサバ分のoutputが減る

・対策１：多能工チームの編成でコミュニケーションコストを下げる
・対策２：ソフトウェア自体の価値を上げる要件を増やし、ボトルネックを回避
・対策３：要件をひとつずつ完成させる体制で、決定を遅らせる

対策1ができていないと、2と3はおそらく止まります。1のチーム編成は、現場だけでなくトップやミドルのマネジメントのリーダーシップが不可欠。ぜひマネジメント層に本日話した構造を話していただき、内製開発をスケールして生産性を向上させていただければと思います。

アーカイブ動画はこちら

https://findy-tools.io/events/149e656bb2d7886e53f2