製品プラットフォーム

一つの製品が成功したあと、別の用途や価格帯へ広げるには、何を共通に使い、何を作り替えるかを決めます。
製品プラットフォーム（Product platform）は、複数の製品に共通して使う部品、技術、接続条件、工程などの基盤です。
MIT Sloanの説明も、製品ファミリーを通じた構成要素や技術、工程の共有を扱っています。

派生製品の違いから基盤を決める

たとえば、屋内用と屋外用の監視装置を開発する会社を考えます。
映像処理と管理画面を共通にできても、防水、放熱、設置方法は用途に応じて変える必要があります。
先に一機種を作り、その設計をすべて共通基盤と呼ぶと、別用途の制約を後から押し込むことになります。
予定する製品群の共通点と違いを調べて、基盤の境界を選びます。

共通にする部分は、単なる部品の一覧では足りません。
映像データの形式、電力の供給、ソフトウェア更新の方法など、互いにつながる条件も含めます。
派生機種が守る条件と、自由に変えられる範囲を示すことで、担当者が独立して作業できる範囲が定まります。
条件を変えると、どの製品に再試験が必要かを追える状態にします。

共通化の費用を評価する

共通化には、重複開発の削減や調達の集約が期待できます。
一方、共通化に合わせる調整、不要な性能の搭載、変更の波及という負担もあります。
屋内機に屋外向けの高価な材料を使えば、基盤は一つでも価格の競争力を失うかもしれません。
機種数や部品点数の減少だけで成果を判断せず、開発、製造、保守を通した費用を比べます。

将来の製品数を多く見積もると、基盤への先行投資が合理的に見えます。
その製品が出なかった場合にも費用を負担できるかを確認します。
最初は確かな二用途で共通化し、実際の変更から拡張の必要を学ぶ方法もあります。
すべての将来用途を想像して備えると、使わない仕組みを増やしがちです。

共通基盤を維持する責任

基盤の担当者が派生機種の納期と無関係に仕様を変えると、製品側の計画が崩れます。
製品側が独自の修正を続ければ、共有していたはずの基盤が分裂します。
更新方針、互換性の期限、例外の扱いを合意し、実際の利用状況から見直します。

派生製品の基になる対象はプラットフォーム製品、要素の分割と関係は製品アーキテクチャ、投入時期の関係は技術ロードマップを参照してください。

参考資料