トヨタ製品開発システム｜プロセス編

本記事は以下の書籍をベースに、リーン開発やプロダクトマネジメントの源流となったトヨタ製品開発システム（TPD）のプロセス編をまとめました。プロセスエンジニアリングの観点も書き足しています。

トヨタ製品開発システム

Table of Contents

原則１ 付加価値とムダを分離できるように顧客定義価値を設定する

原則２ 選択肢を十分に検討するために、製品開発プロセスをフロントローディングする

原則３ 平準化された製品開発プロセスの流れを作る

原則４ 厳格な標準化を使ってばらつきを減らし、フレキシビリティと予測どおりの結果を生む

原則１ 付加価値とムダを分離できるように顧客定義価値を設定する

顧客定義価値｜顧客観点での価値。この原則が一番最初であることに意味があります。

なお、CEはプロダクトマネジメントの文脈ではプロダクトマネージャに相当します。

Chief Engineer（CE)の条件

• 第一に顧客に共感できること（顧客の自分事化／インストール）
• ビバリーヒルズに行ったこともない技術者はレクサスを設計すべきでない
• 顧客を自分事化できる人がリーダーとなるべき
  →チーフエンジニア（CE／主査）制度。スタートアップにおいては、CEOやプロダクトマネージャ

R&R |Role & Responsibilities

主査（Chief Engineer）

1. 顧客に価値をもたらすこと（顧客の声の代表となること）
2. 顧客の価値観とその価値観が車両性能特性にどのように噛み合うかを理解（VPの定義、PRDへの落とし込み）
3. プロジェクト中のあらゆる開発チームに伝達する（MTG／ワークショップ）
4. 開発チームの各人が実行できる特定の行動に結びつき、価値特性と整合性のとれた定量的な目標を導入する（Key Metrics）
5. コンセプト書（指示書）の作成（Product Charter）
6. プロジェクト期間を通じて、目標をトラッキングする（OKR）
7. 目標と社員の人事考課をアラインメントする

例｜価値観の把握

• Rav4の主査：主査はターゲット顧客のGenXのライフスタイルを理解するために、南カリフォルニアの若い家族の家に下宿
• シエナの主査：アメリカ、カナダ、メキシコの全域8万キロを走破し、北米ドライバーにとって何が重要か、肌で感じる

Activities

1. 顧客の価値感を理解する（➡記憶探索型インタビューによる自分事化）
2. コンセプト書（プロジェクトの基本方針）を使い、顧客定義価値と車両レベルでの性能目標を開発チーム全体に伝え整合性を取る
3. コンセプト書を用い、各開発チームに、具体的な定量目標を決めさせる
4. この過程で現地現物を確認し調査する
5. 主査と開発チームの各リーダーで整合性、フィージビリティ検証し、ストレッチゴールを設定する（個別最適を避け、全体最適化する）

コンセプト書（指示書）の内容例

• 25ページ程度で、数ヶ月かけて作成
• 車両特性の定性的、定量的目標
• 性能
• コスト
• 品質

Tools

プロダクトコンセプト、プロダクトビジョン、ジョブ理論、R&R、RACI、体制図、Project Charter、仮説バックログ、OKR、ワークショップ、MTGデザイン

Memo

Product Charter（プロダクトの憲法）を作るといいかも。PRDよりも上位の文書として。

Product Charter TOC (Preliminary)

1. コンセプト
2. プロダクトビジョン
3. ジョブマップ
4. ビジネスモデル（キャッシュ＆ベネフィットフロー）
5. カスタマージャーニーマップ
6. リーンキャンバス
7. 体制図
8. R&R

Bad Case Checklist

• プロダクトのコンセプト、ビジョンが言語化されていない
• 顧客を自分事化できておらず、ただ自分たちの考えを押し付けていることに気づいていない
• そもそもプロダクトの目標が定性的・定量的に明文化され共有されていないのに、人事考課制度を作ろうとしてしまう（採用も同じ）
• R&Rが言語化されていない、明確でない
• プロセスが言語化されていない
• プロダクトマネージャや開発リーダーに目標設定するCapabilityがない
• 経営陣にそもそもこれらを理解するCapabilityがない、R&Rを合意・実行できない
• 上位のOKRのKey ResultsがKGI/KPIになっており、顧客のベネフィットになっていない

原則２ 選択肢を十分に検討するために、製品開発プロセスをフロントローディングする

※フロントローディング：前段階に注力すること

Objectives

• 問題を初期段階／早期にその根本原因から解決する（後半では変更できないorコストが大）

Activities

1. アーキテクチャ、プロセス、具体的な活動を標準化し、非常に具体的な実績目標を設定する
2. 製品開発プロセスの初期に検討段階を設け、問題を解決し、対立を解消し、ばらつきの根本原因に対応し、それを製品開発と他の部分と隔離する。これにより、参加者は自分たちの仕事に集中できる
3. 目標を実現するための案を、セットベース・コンカレント・エンジニアリングで対応する（複数案を並行して検討）

Tools

• 仮説バックログ（As-IS→プロダクト→To-Beのそれぞれを検証する仮説。分類の仕方はPEST/3C/4Fなどの既存のストラテジーF/Wも活用）
• 仮説検証ミーティング（広義のグロースミーティング）
• KPT
• トレードオフ曲線（創造性を損なわないようにする）、チェックリスト、パラメトリック設計
• MDT(モジュール開発チーム）を横断する会議等のコミュニケーション設計
• 構造計画｜K4（PRD、ユーザーストーリー）
• 製品カテゴライズとカテゴリーごとの製品開発戦略（革新的新製品、派生製品、Innovative Improvement（Architecture/Platform開発・変更を含む）、Incremental Improvement）
  ・Innovative Improvement: 顧客価値とのアラインメントが指標
• 先端技術導入計画：事業革新チームがプリウスのコンセプトを開発。既存技術を最大限に活かした先に先端技術を検討する。ゼロベースではない。
• スタイリング＋現地現物＋関係者の意見＋セットベース・コンカレント・エンジニアリング（スプリント・リファインメントよりも前の工程）

R&R

CE

• プロダクトのポジショニングに合わせたプロセスの設計
• スタイリング（デザイン）、技術などの意見を現地現物で収集し、決定する
• 問題はなるべく早期に取り除く
• 根回しする（意外と肯定的。コミュニケーションの促進という観点と意思決定の効率化）

MDTの各リーダー

• 目標に対するアイデアを複数案出し検討する
• 他ののMDTを支援する

TBC

• この段階のグロースミーティングのデザイン

原則３ 平準化された製品開発プロセスの流れを作る

ソフトウェア開発においてはScrumである程度カバーされているので省略

原則４ 厳格な標準化を使ってばらつきを減らし、フレキシビリティと予測どおりの結果を生む

ソフトウェア開発においてはScrumである程度カバーされているので省略

トヨタ製品開発システムの組織開発編のまとめはこちらです。

トヨタ製品開発システム｜組織開発編