内製開発サミット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