製品開発とテスト

概要

  • パラダイムシフト：派生開発とは異次元
    • デバッグ，
    • スピード，
    • 製品間連携
  • スクラム
    • 考え方
    • 実際

1 自動車産業
パラダイムシフト

1.1 技術やソフトだけでない変化

1.2 100年に１度の変化

  • 良く分からない変化だが
  • 少しずつ見えて来た（らしい）
  • 変化のスピードは？

2 普及とスピード

2.1 どんな理論

  • ロジャーズの普及理論
  • マーケティング理論で色々
  • EVとSDVについては

2.2 グループで共有

  • この変化について
  • 現在抱えている課題や
  • 持っている技術など
  • 変化やインパクトについて
  • 討論してください

Breakout Rooms
　5分

3 直近では

3.1 直近市場と技術の変化

  • 市場：中国＞米国＞欧州
    • 中国で拡大中，他地域の成長は低い
  • 競合企業：中国，欧州，米国
    • 中国の躍進
  • 技術：EV，ADAS，AD
    • 中国/米国の競争激化

3.2 組込みソフト構造の変化

  • ECUの変化：統合ECU,エッジAI
  • 制御基盤：OSやミドルソフト
    • ソフトリアルタイム制御：ROS2, Android Auto
    • 汎用リアルタイム制御：普通の制御
  • 開発環境：ワンストップ型IDE

3.3 ソフトリアルタイム処理

  • OS: Linux（PREEMPT_RT）、Android、ROS2
  • 特徴: 統計的保証、平均応答時間最適化
  • 例: 動画ストリーミング、ロボット制御
  • 車載系以外で以前から主流（マルチコアの活用）

3.4 パイプライン処理

  • 処理を複数段階に分割して並列実行
  • データを順次流すことでスループット向上
  • バッファでステージ間を接続

3.5 性能要件やテストの変化

  • パイプライン処理はマルチスレッド
  • スレッド間で同期処理が必要
  • RTOS時代のジッター時間とは異なる
  • 多重タスク実行の優先制御など
  • レビューだけでは対応できない
  • 大規模なシミュレーションテスト

3.6 テスト技術の変化

  • レフトシフト：より源流でテスト
    • unitテストやレビュー強化ではありません
    • 挙動レベルの品質に対して
    • テストドリブン，組み込まれた自動テスト

3.7 テストに個別投資できない

  • 開発のエコシステム化：製品や企業を超えて
    • 競争しながら協調する：標準化やプラットフォーム化
  • 競争は製品に主眼，開発スピード
    • 開発の効率化を製品固有には投資しない

3.8 ポストモダン

  • 製品分野別のAgent開発が進んでいる
  • 組込み系は市場規模が小さいので遅れ気味
    • Web 系や DX系 が激戦区
  • テスト，デバッグ，改修のフィードバックループが肝
  • UIデザイン系の評価にも使われている
    • ペルソナAgent

4 デバッグと改修

4.1 振舞いが主流

  • 製品要件がリアルタイム特性へシフト
    • 非機能要件が増え動作させないとテスト不可
    • 机上レビュー型品質管理の限界
  • 仕様の正しさと製品の特性に乖離
    • 動作させないと解らない
  • デバッグとチューニングが同居

4.2 速くビルドして速くデバッグ

  • このループを廻す能力が求められる
  • テストのために製品固有のタスクを追加しない
  • テスト，デバッグのプラットフォーム化
    • 過去：製品やプロセスに合わせてTool選択

4.3 ポストモダン

  • Agentによる自動修正，再評価
    • 三角形問題は簡単な例（先週）
    • マルチAgent で評価ループ高速化
  • 既に実用化時代に入っている

5 スクラム

5.1 スクラムの起源

原著：The New New Product Development Game - Stop running the relay race and take up rugby 著者：竹内 弘高、野中 郁次郎 （1986年）

  • 論文はここ
  • ホンダやキヤノンなどの製品開発を調査した結果から生まれた．

5.2 リレー方式からラグビー方式へ

  • 従来の製品開発：リレー方式 市場調査，製品企画，開発，評価・・・
  • ラグビー方式(スクラム)：6つの特徴
  1. 「内在する不安定性」、
  2. 「自己組織化プロジェクトチーム」、
  3. 「開発フェーズの重複」、
  4. 「マルチラーニング」、
  5. 「繊細なコントロール」、
  6. 「組織的な学習の移転」

5.3 自己組織化

  • スクラムのコア概念 組織やチームが、明確な指示が無くても
  • 環境の変化や課題に応じて、
  • 自律的かつ協調的に、
  • その構造、プロセス、行動パターンを
  • 自然発生的に形成・変更していく能力 メンバーのスキル，チーム力，リーダーシップ，モチベーションなどが必要

5.4 ソフト開発の「スクラム」

  • 開発のフレームワーク：ワークフローに近い
    • 野中理論は，経営学の概念・方法論
  • ソフト開発での「スクラム」提唱は
    • Jeff Sutherland、Ken Schwaber(1995年)
  • 『スクラムガイド (The Scrum Guide)』
    • その後書籍：サザーランド氏（2014年）

5.5 Scrum Inc. の設立

  • CEO: ジェフ・サザーランド氏 （2006年）
    • 現在のCEOは息子
  • スクラムに関するコンサルティング、
  • プロフェッショナル・トレーニング、
  • および認証
  • Scrum@Scale の開発:
    • 大規模開発向けに作成
  • 投資顧問:

Scrum.org の設立

  • 会長: ケン・シュワバー氏
    • スクラムの概念が商業主義で曲解されずに適用されることに注力
  • スクラムの教育、評価、
  • および認証の品質を統一・向上
  • 厳格なアセスメント
  • スクラムの原則の純粋性維持

5.6 スクラム・フレームワークとは

  • 竹内/野中 両先生のスクラム概念の継承？
  • フレームワークは
    • 具体的な役割、イベント、成果物
  • 実体は２つの合体
  • アジャイル開発
    • アジャイルソフトウェア開発宣言
  • リーン（Lean）思考
    • TPSから生まれたリーン（Lean）思考

5.7 方法論化

  1. 3つの役割（Roles）
    • プロダクトオーナー(Product Owner: PO)
    • スクラムマスター (Scrum Master: SM)
    • 開発者 (Developers)
  2. 5つのイベント（Events）
    • スプリント (Sprint)
    • スプリントプランニング (Planning)
    • デイリースクラム (Daily Scrum)
    • スプリントレビュー (Sprint Review)
    • スプリントレトロスペクティブ
  1. 3つの成果物（Artifacts）
    • プロダクトバックログ (Product Backlog)
    • スプリントバックログ (Sprint Backlog)
    • インクリメント (Increment)

5.8 実態は

  • チームや小規模プロジェクト
    • アジャイル開発の流れ
    • スクラム認証やコンサルとは別に
    • OSS開発などで一般化 自律的な導入が多い
  • 大規模プロジェクト
    • コンサル主導での導入が一般的
    • フレームワークに従った管理技法

5.9 スクラム ３つの側面

  1. 日本型の開発組織論:
    竹内/野中先生の経営学の理論
  2. アジャイル開発の実践形:
    ボトムアップ活動，新興企業やOSSで展開
  3. Scrum Inc. のフレームワーク:
    研修，資格認定，審査など一連のサービス
    方法論時代のアプローチ

次は，


トップページへ - 共有ノートへはここから