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
- 動く物を素早く作る、小さくリリース
- 相互依存する部品が増えたことに伴う開発速度低下
- プロセスやツールによるコミュニケーション
- SW設計・実装にかかる人材が少ない
内製化で勝つ 〜エンジニア採用戦略やテックカルチャー構築ガイド〜 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)
- gitlab
- 徹底的な透明性: 皆による意思決定や参画 (vs top down型)、周りから突っ込みが入る、機動的変更
-
認知の限界を超えると、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の道までの展開の安定と継続の中で組織的に学習をしていくこと
- The First Way
-
スローガン
- THINK BIG
- ACT FIRST
- FAIL FAST