機種横断プラットフォーム化の投資判断と適用範囲の決め方
産業用ポンプ向けインバータ制御基盤を手がける中堅メーカー（開発者15名、年商80億円）では、12機種の制御ソフトを機種ごとに個別開発してきた。年間出荷は合計8万台、1機種あたりの平均製品寿命は5年である。次期ファミリでは、RTOSと共通ミドルウェアによるプラットフォーム化案（NRE 1億2,000万円、開発工数30%削減見込み）が提案されている。一方、最上位2機種は表示器とネットワーク監視のためLinux SoCが必要で、下位10機種はCortex-M7クラスで足りる。上位2機種は台数では全体の15%だが、売上では40%を占める。現行では市場不具合の横展開に平均3か月を要し、同一原因の不具合が別機種で年2〜3件再発している。顧客の1社は年1回の機能追加要求を出しており、その都度10機種分の回帰テストを手作業で実施している（1機種あたり2人週）。経営層は「工数削減効果だけでは投資判断できない」と難色を示し、さらに遠隔ファームウェア更新（セキュアブート必須）と機能安全規格への準拠が求められている。競合A社は共通プラットフォームを3年前に導入し、機種展開を年2機種から年5機種に増やした実績がある。開発部長は、プラットフォームの適用範囲と、共通化で失う機種別最適化の評価方法で悩んでいる。
1. プラットフォーム化のGo/No-Goを判断するために、どの定量指標を揃えるべきか。工数削減率以外の指標を3つ以上挙げ、算出方法と判断の目安を示せ。
Read the worked answer
揃えるべき指標
| 指標 | 算出方法 | 判断の目安 |
|---|---|---|
| 5年TCO | (機種別の開発・保守工数 + 不具合横展開工数 + 回帰テスト工数) × 単価 と、(NRE + 共通部分の保守工数) の比較 | 投資回収3年以内 |
| 不具合横展開コスト | 1件あたり工数（調査＋修正＋全機種回帰）× 年間再発件数（現状2〜3件） | 共通化で横展開が1回で済む前提の効果を金額化 |
| 回帰テスト工数 | 現行1機種2人週×10機種/年 = 20人週 → 自動化前提で何割減るか | CI投資とセットで評価する |
| 機能追加リードタイム | 受注からリリースまでの日数、機会損失額への換算 | 競合A社の機種展開ペースに対する劣位の解消 |
| セキュリティ対応工数 | 脆弱性1件あたりの全機種対応工数が、共通化で1回になる効果 | 遠隔更新・セキュアブート要件では必須 |
削減率だけでは足りない理由: 分母が新規開発に偏り、横展開・回帰・セキュリティ・部品共通化による調達スケールメリットが含まれない。さらに、機種別最適化を失うことによる下位機種のメモリ増・部品コスト増が分子に出てこない。したがって「工数削減率」ではなく「5年間のキャッシュフロー差」に換算して判断する。削減率30%という数字は、母数の取り方で同じ提案が黒字にも赤字にもなるため、意思決定の土台にならない。
2. 上位2機種（Linux SoC）と下位10機種（MCU）を単一アーキテクチャに統一する案と、2階層に分けて共通ミドルウェアで束ねる案を比較し、適用範囲の決め方を論じよ。
Read the worked answer
比較
- 単一アーキテクチャ（全機種Linux SoC）: 共通化率は最大になるが、下位10機種でBOM増（SoC、DDR、PMIC、基板層数）、起動時間、リアルタイム応答、消費電力が悪化する。台数の大半が下位機種であるため、損失は台数倍で効く。
- 2階層（上位2機種=Linux SoC、下位10機種=MCU）: OS層は共有できないが、その上のアプリ層・通信・診断・ロギング・セキュリティを共通化できる。共通化の便益は「共有できるコード量×その部分の不具合密度」に比例するので、まずどの層を共有するかを決めるのが先。
決め方
- 共有境界を「HAL/OS抽象化APIより上」と定義し、上位・下位の双方が同じAPIで実装できるかを2機種のプロトタイプで確認する。
- 判断基準は (a) 共通層のコード共有率（目安60%以上）、(b) 抽象化による性能オーバーヘッドが制御周期に収まるか、(c) 下位機種のBOM増加額×年間出荷台数 vs 共通化便益、(d) 売上40%を占める上位機種のリリース速度を落とさないこと。
→ 2階層＋共通ミドルウェアが妥当。単一化は下位機種のBOMとリアルタイム性で正当化できない。上位機種の共通化率が低くても、売上の大きい側の開発速度を守ることを優先する。
3. 共通モジュールに不具合が生じた場合の影響範囲を、どう管理すればよいか。プラットフォーム化の副作用として論じよ。
Read the worked answer
共通モジュールの不具合は全機種に同時に波及する。これはプラットフォーム化の最大の副作用であり、便益と表裏の関係にある。
- 変更管理: 共通層はセマンティックバージョニングで管理し、各機種は特定バージョンを固定参照する。共通層の更新時には「適用機種マトリクス」で影響機種を明示する。
- CI: 全12機種のビルドと回帰を1パイプラインで回し、共通層への変更PRの時点で全機種テストを必須にする。回帰テストの自動化投資が、プラットフォーム化の前提条件になる。
- リリース判断: 共通層の変更を含むリリースは、影響機種すべての検証完了を出荷条件とする。緊急修正は機種別ブランチを切らず、共通層にパッチを当てて全機種へ配る運用をあらかじめ決めておく。
- 供給: 共通部分のSBOMを維持し、脆弱性公表時に影響機種を即座に特定できるようにする。
これらの運用コストを見積もらずに導入すると、横展開工数は減るどころか増える。特に「夜間ビルドを朝に見る」程度のCI能力しかない状態では、全機種回帰が回らず、共通層の変更が事実上できない運用に陥る。