技術ロードマップ

製品の発売予定があっても、その前提となる技術が間に合うとは限りません。
技術ロードマップは、市場や事業の必要、製品の機能、その実現に使う技術を時間軸で結びつける計画です。
Cambridge IfMのT-Planは、市場、製品、技術を対応させる方法として整理されています。
新技術を列挙するだけでなく、何のためにいつ必要かを示します。

製品から必要な技術へたどる

たとえば、屋外で使う測定端末を、通信が不安定な地域にも提供する計画を考えます。
顧客は通信技術の名称より、現場で記録が失われず、戻ったあとに報告を終えられることを求めます。
その便益に必要な機能を、端末内の保存、再送、状態の表示などに分けます。
次に、電力や記憶装置、同期処理について満たすべき条件を置きます。

各技術には、調査、試作、実機での確認、量産や運用への準備という状態があります。
論文で原理が示されたことと、製品の条件で安定して動くことを同じ進展として扱わないようにします。
誰が何を試し、どの結果が出れば次へ進むかを決めます。
外部の部品やサービスを使うなら、相手の供給計画と自社の検証期間も含めます。

時間のつながりを確認する

端末の発売前に長時間の動作試験が必要なら、その試験期間から逆算して部品の選択時期を置きます。
選択を遅らせると性能は上がるかもしれませんが、試験の余裕がなくなります。
早く固定すれば検証は進めやすくても、新しい部品の便益を使えない可能性があります。
選択の期限と、変更できる範囲を同じ図で確認します。

一つの技術を複数製品で使うなら、共通基盤の準備と各製品の試験を分けます。
共通技術が遅れた場合の代替策も用意します。
旧方式で一部市場だけ先に提供する、機能を限定する、発売を遅らせるなど、顧客への約束と費用を比べます。
線を引いたことで技術の完成が保証されるわけではありません。

根拠が変わったら更新する

顧客の条件、技術の実測結果、外部の供給時期が変われば、ロードマップも変えます。
更新するときは、日付だけでなく、どの製品や事業目標に影響するかを示します。
担当する専門家だけで完結させず、販売と運用の担当者も前提を確認します。

製品の目標を示すプロダクトロードマップ、将来の複数の可能性を調べる技術フォーサイト、共有部分を設計する製品プラットフォームと結びつけて使います。

参考資料