内製開発サミット2025

What's this?

See https://inhouse-dev-summit.findy-tools.io/2025

トヨタのシステムソフトウェア内製化戦略〜ゲームOS開発者が挑む内製開発現場のリアル〜 by トヨタ自動車 沖野 直人さん

なぜトヨタ?

自分の技術･経験を活かして、社会問題の解決やよりよい社会を実現したい
right time at right place

トヨタ自動車
モビリティカンパニーへの変革

トヨタは世界ではトップのモノ作りの会社

車はシステムソフトウェア屋には魅力満載

• 多数のcomputer
• 車載ネットワークでつながり
• クラウドにもつながり
• 多数のセンサー
• データは膨大
• 機能安全が重要な自動車制御からエンタメまで網羅

チャレンジ

• 大規模分散リアルタイムシステム
• 組み込み制御システム
• 組み込みHMI
• エンタメ
• AI based system
• Infra (cloud/NW)

×

機能安全と関連法規

クルマのSWの変遷

• 電子制御の拡大
• 「つながる」機能拡大
  • CASE
  • telematics service
  • OTA (一部)
• ソフトウェアの急激な進化
  • IVI/ADASソフト規模の急拡大
  • 社会インフラ連携
  • BEV登場によるSW重要性増大
  • AI活用
  • OTA　SW更新の拡大

SWの急激な規模拡大、開発スピードへの適用が重要

トヨタのSW開発

お客様に価値のある機能をタイムリーに提供するために、
志を共にする仲間と共に開発する

グループ企業、仕入れ先、IT企業　×　トヨタでのソフトウェア開発

トヨタにおける内製化とは、
仕入れ先の各企業様と共同で、よりよいソフトウェアを素早く開発し、
継続的な進化も素早く行っていくSW開発の「手の内化」

手の内化で実現していくこと

• 物理構造・デバイスから独立し抽象化されたクルマのSWアーキテクチャ
• クルマ全体のSWを更新できるアップデートシステム
• データ収集・分析による素早いfeedback
• application sw eco systemの構築
  • SDK提供によるApp開発者の開発促進
  • APIの世代を超えたcompatibility
• OSSの活用と貢献

論理SW architecture

• cloud
  ^
  |
  v
• entertainment, 運行支援, 快適空間演出, 社会インフラ連携, 先進HMI
  ^
  |
  v
• Open APIs and closed APIs

物理システム構造への機能配置

何が貢献できる？

• 「SW設計や実装に関わる人材が少なかった」ので、そのあたりをどうすればよいのか困っていそう
• さらに速いスピードで進化を続ける「SW技術を急にそれも多数キャッチアップ」することになって困っていそう
• 単一部品で閉じていたものが、機能実現のために複数の部品をまたぐようになって、関係者の「コミュニケーションオーバーヘッド」で開発速度が落ちていそう

どう解決する？

• 解決手段を提示してもうまくいかない可能性が高い

  • 入ったばかりの外部人材でトヨタでの信用･実績は無い状態
  • 大きなカルチャーギャップ
  • そもそも解決手段が理解できるのなら困っていない

• やってみせる

  • 小さく初めて実績を積み重ね、信用を得る

• 先回りして動く物を素早く作る

  • 実際に動いている物は、資料や仕様よりはるかに説得力がある

何を作ろう？ targetは何？

クルマ全体のSWを更新できるアップデートシステム

[update runtime]

• 個別最適化されたアップデートシステム
  →多様なデバイス構成のアップデートを実現可能な分散管理システム

[配信パッケージ]

• 配信サイズ/アップデート時間増大, contents漏洩システム
  → 効率性・機密性に優れ、柔軟な独自配信フォーマット

[配信環境]

• 複雑ナップデートの実装･評価のコストの爆発
  → 動的なアップデート制御

全てのパターンではなく、評価工数を考慮したアップデート

データ収集・分析による素早いfeedback剥けsystem

トヨタの扱うconnected carやsmart city IoT deviceは今後ますます増加
NW接続状態が頻繁に変わるクルマなどをサポート可能な分散realtime PFを開発

runtime : 共通化されていない→多様なデバイスで動作する共通機能を提供

どう作る

ヒト・モノ・カネ

• ヒト

  • 少数精鋭
    • ある一定のスキルレベルは維持
      • チームの生産性を落とさない
      • 優秀なエンジンの離職防止
  • 徐々にプロパー弘津を高めていく
    • 短期：即戦力の準委任業務委託
    • 中期：即戦力のキャリア採用
      • どこもエンジニア不足
        • 対外認知・広報活動
          • intern
          • media取材
          • 大学講座
          • OSS貢献
        • 社内
          • SW bootcamp
          • 開発proj.を通した育成
        • SW engineer採用の精度を高める施策
          • technical challenge, coding面接
        • SW engineerのretaintion施策
          • チャレンジしたくなる開発Pj.
          • top talentがいる
            • 学び、刺激、憧れ
          • SW engineerのcultureの尊重
          • PC等は本人の嗜好を（可能な限り）尊重
            • keyboard, monitor等も
          • (いうまでもなく)待遇面
    • 長期：ポテンシャルのある新卒育成

• モノ

  • 開発PC/server
  • 各種開発環境
    • JIRA/confluence, github, coverity, artifactory, etc.
    • 各種pub cloud
    • 各種ref board

• 開発process/project management

  • 実績のある前職のモノをベースに開発チームにフィッティング
    • 一般的なglobal standardなものと同様

• 既存の開発との共存

  • 特区、治外法権、出島
    • 外部の実績ある開発手法の導入という位置づけで独立性・裁量性を任せる
  • 違う発想・カルチャーを尊重
    • 相互理解し、融合してさらなる高みへ

結果

• 2つのSW PF共に採用
  • 要因
    • 求められる機能を必要となるタイミングで準備ができていた
      • 自ら設計しコードもかける（外部）人材の登用
    • サポートいただき、まかせていただいた
• 人材育成（裏のメイン）
  • 開発を通して、若手にプロダクトレベルの開発手法・技術を伝える機会

まとめ

トヨタにおける「内製化」とは「手の内化」

仕入れ先の各企業も含めて

• 困りごととその対応
  • SW設計･実装にかかる人材が少ない
    • 登用
    • 育成
    • 採用
    • 定着
  • SWの急激な進化への対応
    • 抽象化され、継続的に進化可能なSW arch
    • 動く物を素早く作る、小さくリリース
  • 相互依存する部品が増えたことに伴う開発速度低下
    • プロセスやツールによるコミュニケーション

内製化で勝つ 〜エンジニア採用戦略やテックカルチャー構築ガイド〜 by 株式会社ゆめみ 片岡 俊行さん

• メッセージ: 内製化の成功にはカルチャーが重要
• ゆめみへの認識理解 : 内製化支援の会社
  • 社会の実験室
  • ティール組織
  • 開発者体験が良いイメージ：第4位
  • 自律分散型
  • 採用やマネージメントを60%の方が

エンジニアの採用戦略

• engineerの採用の好機

  • 転職：同じ規模の会社に転職したいという方が多い
    • 出社回帰もあるので、スタートアップよりも大企業が優位
    • 大企業は、テックカルチャーへの理解欠如があるのではないかと見られている
    • 将来性

• 意思決定：例：高額なMacを購入するとき

  • 機械的なプロセス
    • 申請側が理由を説明
  • インターネット的な組織カルチャー
    • 上司側が不要な理由の説明をする必要がある

• Z世代は、不安型成長欲求：会社がどうあれ、自分は成長したい

• 言語

  • go : 804.9万
  • daty : 754.0万
  • python(web) : 727.8万
  • ruby: 721.1万
  • kotlin : 710万
  • C++ : 706万
  • Python (ML) : 707万

rustのデータないね

• culture作りの基本

  • 採用：スタート地点
  • 成長：イノベーション創出
  • 定着：戦力化の仕組み
    • 心理的安全性
    • 学習と成長の機会
      • 社内勉強会
      • 技術ブログの運営
      • カンファレンス参加･採択応募支援＜−会社として後押し
      • 最新技術へのチャレンジ
    • エンジニア主導の意思決定
      • CTOがいるとか

• culture醸成

  • 徹底的な透明性: 皆による意思決定や参画 (vs top down型)、周りから突っ込みが入る、機動的変更
    • gitlab
      • handbook
      • SSOT: Single Source Of Truth
        • Single Source: singke masterとreference
        • 信頼性 = 正確性(Correct)+正当性(Right)+真実性(Truth)
        • 結果信頼性 (eventually reliability)
          • 単一性 (Single)
          • 真実性 (truth)
          • 変更容易性 (chagability)

• 認知の限界を超えると、AIフレンドリーになる

• 結果、人間にもフレンドリーになる

• people - role - responsibility

• role & responsibility - people assign

• 役割主導: matrix型組織

• 分散方式: 委員会組織

自律分散型の組織へ

「個の資質を活かす」ための仕組み→「分業」　と　「個に依存しないための仕組み」化

アウトプットカルチャー

• 書籍
• 勉強会
• qiita/slack

話すこともoutput
gamification : 楽しみ、キャンペーン、参加賞：100万円！？
勉強会の「開催」に貢献したヒトも、表彰

• まとめ
  • 採用だけでなく、定着と戦力化
  • 段階的な内製化
  • カルチャーの重要性

2年間で内製化率0%→95%を達成したイオンスマートテクノロジーの内製化組織の作り方 by イオンスマートテクノロジー 翁長 聡史さん、堀内 亮佐さん

engineering part

• ないないづくし

  • 仕様書や設計書などがないないづくし
  • ...

• どうしてこうなった？

  • リリース優先
  • 社内にエンジニアがいなかった

• どうすればよかったか

  • テックリード
    • 技術選定
    • 品質定義：coding rule, lintなども
    • 発注先選定：上記品質定義を満たせる発注先、エンジニアの採用も
    • 受け入れ：開発段階からレビュー

• document化：後からでも必要なモノは作る

  • 後から
  • 画面項目定義書
  • シーケンス図
  • magicpotなどによる自動テスト

• 内製開発チーム

  • コントロールできる
    • 開発優先順位
    • ノウハウ蓄積
    • リリース速度

パフォーマンス向上→心理的安全性の担保
→相互理解を促進する
ドラッカー風エクササイズ

アウトプットではなく、アウトカムを最大化したい
月1のリリースサイクルでアウトプットを最大化するリソース効率に倒しきった開発を行っている。

全案件のマージタイミングが遅く、テストが遅くなることで、リリースまでに不具合が潰しきれずリリー図が遅れる案件が生まれてくる

フロー効率

ビジネス優先の案件を小さくリリース

リアーキへの挑戦

scrum part

• roadmap

• 半年後のイメージ

• 何かあったら相談させていただく

• training

  • agile宣言から
  • しっかり8-10hかけて
  • 中途半端にならないように

• PBR: Product Backlog Refinement

  • PBRをイベントとして実施
  • Pre PBR
  • PBR活動もproduct backlogを作成して、見える化

• POをチーム制とした

• small start & 成功体験

  • 電子マネーWAONのiAEONアプリへの登録
  • 既知機能から初めて成功体験を得る

課題

• 黎明期の課題

  • Developerの人数が増えない（他の業務に回されていた・・・）
  • 社長に相談し、Devメンバーが5名に
  • 最初が肝心
    • 0から始めるに当たって、やる、続ける→リズムが生まれる
    • スクラムの不完全な部分を初期段階において如何に保管するか
    • 導入準備段階からスプリントを回した方が良い

• 2 team (LeSS導入)の実現

• 6名→3名*2になってしまうので、分割損が発生する可能性が高いので、

• partner会社のメンバーに参画して貰い、5名*2 teamにした

• 結果、4 sprint後には、velocityが2倍程度に

• 考慮すべき点

  • プロパー比率50%以上が良かった
  • joinしたpartnerが自走できた
  • PO-Pxの増員でより多くの要件を扱えた
  • LeSSのフレームワークは最初から全て採用した方がよりよかった
  • → LeSSのPBRの採用に時間を要した

• 3 team化

  • 統合バックログの仕組み化
  • 複数のPOやstakeholderから直接要件を持ちかけられていた
  • 全て私の要件が一番状態
    • こっそりとよろしく、も。
    • →副社長、CTO、COOによる統合バックログでの優先順位づけを行う運用へ
  • 「統合バックログ確認会」の開催

• 完全な内製化への一括シフトとせず、24年は原則キャパシティー内に。

  • 最低限の委託開発（現状、5%程度は委託開発）

• 今後

  • 一時しのぎの委託開発継続はやめたい
    • 技術的負債の増加の回避
    • 御認識である「委託＞内製」の認識をさせないようにしたい
  • プロパー比率を増やしたい
  • フロー効率
    • チームで的確な開発プロセスを考える
    • 統一的な優先順位の考え方に従う
    • 納期ロックを回避したリリース計画へ
  • 自己組織化

成AIを活用し、システム開発の内製化をアップデートせよ！ by トランスコスモス株式会社 所 年雄さん

transcosmosは、digital marketing, call centerの会社
SIer

生成AIによる社会変化

• これまで

  • ユニコーンは適材適所

• 今後：新たなユニコーンは湯集な創業者がAIとコンビを組む

  • 創業者1人と、AIでユニコーン

• コンタクトセンターは労働集約型だが、今後、大部分をAIが担う

  • 人間はAIが不得意な領域のみを担当
  • 数名の人間で、数百名規模のコンタクトセンターを運営する

企業のDXによる開発の変化

なぜ企業は内製開発を進めるのか？
経営の中心にテクノロジーがきた。

• 顧客価値：goods dominant logic -> service dominant logic
• ビジネス実態：モノ・機能→サービス
• 付帯する取り組み：サービス→モノ・機能
• 差別化の手段：テクノロジー→テクノロジー・ビジネスモデル
• 価値創造の源泉：ビジネスモデル→データ
• ビジネス基盤：統率・集中型・大規模→自律・分散型・小規模
• 企業の存在価値：Purpose,Vision,Passion

V時モデルによる品質管理とAI

documentを元にtest caseを作るが、AIを活用して、test caseを作成する。

• documentは属人化→AIでdocumentのreview→documentを高品質化
• 上の上で、test caseを生成AIで作成
  • AIによるテスト結果の評価: ヒトの作業が正しいかをAIがチェック

内製開発って何？

• 自社に必要なテクノロジーをコントロールすること

プロダクトの価値は始まりにすぎない！事業から組織へ拡がるダイキンのアジャイル化 ダイキン工業株式会社 谷尾 虎之介さん、角田 潤也さん

• JaSST'23 Kansai, '24 TTokyo, Scrum Fest Okinawa 2024などにも登壇

ダイキン情報技術大学 : 新卒の5−60名ほどを2年ほどダイキン情報技術大学で勉学の後、部署に配属される。

• Learning Day: 週1・半日
  • 各スクラムチームのproduct goalに剥けた取り組みを共有
  • 全員参加型の15分間チームLTを開催
  • 残りの時間の全ての時間を技術研鑽に確保
    • ペアプロ、モブプロ
• プロダクトを育てながら、チームを育成
  • 集合と解散を繰り返す組織体制からの脱却
    • チームメンバーは4人（立ち上げ時）から15人へ
    • 失敗や負債を糧として次へつなげる
• アウトプット生産性の向上と安定化
  • 品質に強い人が居ないから仕方が無いから脱却
  • POやSMを含めたチーム一丸での品質活動
• 価値観の共有
  • スクラムイベントの内容や目的
  • スクラムにおける三本柱や技術基準
  • スクラム＝スクラムチームとステークホルダーの共同作業
    • 例：スクラムの5つの価値基準「公開」

パナソニックコネクトのアジャイルジャーニー by パナソニック コネクト株式会社 榊原 彰さん

cash cowのcashを糧に、成長領域(SW)に投資

研究開発本部で開発した技術を、cloud engineering centerのcloud PFの上で、SaaS biz unitがSaaSとしてservice提供する、という戦略。

• Blue Yonder: 専業ベンダーとしては世界最大: digital fullfillment cloud PF
• シンガポール研: Asia剥けPoC, local academic collabo.
• ドイツ研: AI
• ベトナム研

なぜ、Blue Yonderを買収したのか？ - Autonomous SCMを実現したい

• CPS: Cyber Physical System

• お客様の現場と仮想空間を統合することで、問題を予見し解決するCPS技術と、それらの技術をBlue Yonderのシステムと連係した現場データの統合・全体最適化を目指す

• Blue Yonder PF : 現場データの統合･全体最適化

• sensing -> AI -> simulation -> deploy to roboticsのcycleをぐるぐる回す

• Blue Yonder Joint solution

  • Intelligent Shop
  • Digital Warehouse
  • Connected logistics

• velocityは安定化が重要。振れ幅が大きいのは問題。

• toolの導入だけではない。中身。

  • github actionsでのCI/CD

• Findy team+

• The Three Ways: DevOps3つの道

  • The First Way
    • IT Value streamのspeed up
    • 開発から運用を経て顧客接点のビジネスまでのスムーズな展開
  • The Second way
    • 逆方向でのfeedback processの有効化と迅速化
  • The Third Way
    • 第2の道までの展開の安定と継続の中で組織的に学習をしていくこと

• スローガン

  • THINK BIG
  • ACT FIRST
  • FAIL FAST