0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

内製開発サミット2025

Last updated at Posted at 2025-02-27

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
0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?