＜明日から実践できる、効果が出る＞リーン製品開発の手法の基本・理解と製品開発プロジェクトマネジメントの劇的な改善

　リーンとは、英語のleanのことで、「やせた」、「細い」、「筋肉質の」、「脂肪のない」という意味です。リーン生産方式 (lean manufacturing / lean product system)は、1980年代に、アメリカのマサチューセッツ工科大学で、ジャストインタイムなどのトヨタ生産方式の研究が始まりました。見える化の手法を基に、製造の現場におけるムダを徹底的に排除し、継続的に改善していくというものです。欧米の製造業中心に、リーン生産方式は広がり、大きな成功を収めました。
　製品開発は、生産現場とは大きく異なる点があります。生産現場では、仕事が繰り返しされます。不良品や仕掛品のムダが比較的わかりやすくなっています。しかし、製品開発では、ほとんど繰り返しがありませんので、ムダが分かりにくいのです。
　リーン製品開発では、製品開発でのムダを見える化し、それを削減します。そして開発のスピードや生産性を劇的に改善します。開発スケジュールの見通しが良くなり、開発期間が短縮され、マーケットニーズの変化に対して迅速に対応することができるようになります。その結果、会社のバランスシートが改善されるのです。リーン製品開発では、開発のワークフローを見える化し、ボトルネックを見つけ出します。ボトルネックは、開発のスピードを決するところです。それを緩和するように、チームで協力して対処します。リーン製品開発は、開発チームの行動様式を変えていきます。そして、会社のカルチャーを変えていきます。各々のコミットを基に、クロスファンクションでの共同作業を推進します。ワークフローを見える化し、それぞれのタスクを誰が責任を持っているのか、そしてマイルストーンをチームでいかに成し遂げていくのかを明らかにします。また、問題となる前に、リスクを回避します。
　上記のようなリーン製品開発の手法を、演習を交えてご紹介し効果を体験いただきます。そして、セミナーの翌日からそれを使い始めることができます。

１．イントロダクション
　1.1 コンサルタント　西村裕司　経歴
　1.2 新製品開発で、お困りになっていませんか？
　1.3 Biography of Ron Mascitelli, PMP

２．リーン製品開発 (Lean Product Development)の概略
　2.1 リーン (lean) とは何か?
　2.2 リーン製品開発(Lean Product Development)とは何か?
　2.3 製品開発のムダ、トップテン
　2.4 無駄を認めないこと
　2.5 基本原則：早いことはいいことだ！
　2.6 基本原則：ファンクション間の協力と、個々の責任
　2.7 基本原則：コミュニケーションの見える化
　2.8 基本原則：ナレッジベースの開発
　2.9 リーン製品開発、それは行動様式を変えるためのもの
　2.10 リーン製品開発手法 vs. 典型的な製品開発手法

３．イベント駆動LPDプロセス (Event-Driven LPD Process)
　3.1 イベント駆動LPDプロセス (Event-Driven LPD Process)の全体像
　3.2 アジャイル・ソフトウェア(SW)開発と同期したイベント駆動型ハードウェア(HW)開発
　3.3 実例　－　開発期間を半年短縮！

４．可視化ワークフロー管理 (Visual Workflow Management)
　4.1 ワークフロー管理の統合システム
　4.2 チームのスタンドアップ ミーティングを計画する
　4.3 ビジュアル・プロジェクト・ボード（Visual Project Board）
　4.4 短期タスクの完了やその受渡を付箋で把握
　4.5 2週間アクションプラン（Two-week Action Plan）に展開
　4.6 2週間アクションプラン（プロジェクトがひとつの場合）
　4.7 パーキングロット
　4.8 演習
　4.9 複数のプロジェクト対応ボード

５．マーケット要求イベント (Market Requirements Event)
　5.1 マーケット・ポジショニングとは何を意味しているのか？
　5.2 差別化要因ランク付けツール
　5.3 エンジニアリングの要求項目を導くツール
　5.4 優先順位付けした要求項目

６．リスク低減イベント (Risk Mitigation Event)
　6.1 プロジェクト計画の策定と、リスク低減イベント - リスクマネージメントのための重要な機会
　6.2 スケジュールリスクに対するトリガーリスト（参考例）
　6.3 プロジェクトリスクの優先順位付け
　6.4 簡便なアクション実施要否決定法

７．可視化プロジェクト計画イベント (Visual Project Planning Event)
　7.1 可視化プロジェクト計画イベント (Visual Project Planning Event) - アジェンダ
　7.2 成果物を担当ファンクションに割り当てる
　7.3 タスクに要する期間と、依存性
　7.4 クリティカルパスが要する時間を見積もる
　7.5 可視化プロジェクト計画(Visual Project Planning)の実例
　7.6 階層構造を用いたリーン・プロジェクト・プランニング

８．ラピッドラーニングサイクルイベント (Rapid Learning Cycle(s) Event)
　8.1 ナレッジ・ギャップ Knowledge Gap
　8.2 ラピッドラーニングRapid Learning 手法
　8.3 学習優先順位図（Learning Precedence Diagram）
　8.4 ラーニングサイクルイベントLearning Cycle Event(s)
　8.5 リスクを開発初期に軽減する
　8.6 ナレッジ・ブリーフ Knowledge-Brief
　8.7 問題の解析
　8.8 代替案の評価
　8.9 ピュー・メソッド　Pugh Method

９．設計 3P イベント (Design 3P Event)
　9.1 製造可能性と、コストや品質を統合する
　9.2 ２つのクリティカル「Critical」の定義
　9.3 改善アクションを優先順位付け
　9.4 システム思考で、プロダクトラインの利益率改善　-　実例

１０．プロジェクトの優先順位と開発リソース管理
　(Project Prioritization and Resource Capacity Management)
　10.1 開発プロジェクトの優先順位付け、そして選択
　10.2 今後の売上や利益は、リソースによって制約される
　10.3 戦略的な製品ロードマップ　－　プログラム・ベース
　10.4 月次人員計画表を用いて、キャパシティを最大利用

１１．LPDの適用を成功させるための提案
　11.1 開発現場では？
　11.2 リーン製品開発改善イニシアティブの進め方
　11.3 長期的なＬＰＤの適用ロードマップ

１２．参考文献

　　□質疑応答□

※上記のセミナーを通じて、以下のような開発現場での典型的な問題点を取り上げ、その対策案をご提供します。
・問題例 その１：「 開発の途中に、自分に関係しそうな問題が起こったら、隠しておいたほうがいい。まわりがうるさいだけ。誰も助けてくれない。」 透明性が乏しく、チームで協力する環境が整っていない。
・対策案
　リーン製品開発の手法、可視化ワークフロー管理 （Visual Workflow Management ）の適用を試みる。チームとして、障害や問題に対処する環境が整う。

・問題例 その２： 「 新製品開発の出荷日は、幹部のお気に召すまま、製品責任者が決めればいい。技術屋は、情熱をもって、それに従うだけ。」 ファンクション（機能開発部門）に属するエンジニアのコミットが製品開発計画に反映できていない。技術の成熟度に対するオーナーシップはあるが、製品計画に対するものが欠如しがちとなる。
・対策案：リーン製品開発の手法、プロジェクト・プランニング・イベント（Project Planning Event）の適用を試みる。チームとして、製品計画を策定し、製品出荷予定日をコミットする。

・問題例 その３： 「 新製品開発は、やってみないと、うまくできるかどうか分からない。はじめる前に、自信があるか尋ねられても、答えられるはずがない。」 実現可能性が低い技術を製品開発にいきなり適用してしまうと、いつプロジェクトが完了するのかが予測できなくなる。
・対策案：リーン製品開発の手法、ラピッドラーニングサイクルイベント (Rapid Learning Cycle(s) Event) の適用を試みる。技術の成熟度を高めてから、製品計画のなかに取り込む。

・問題例 その４： 「割込みばかりで開発プロジェクトのタスクは遅々として進まない。」 直接開発チームに顧客対応などの問題がインプットされて、開発効率が低下している。
・対策案：リーン製品開発の手法、プロジェクトの優先順位と開発リソース管理 の適用を試みる。プロジェクトの優先順位を明確にして、それをリソース配置に反映させる。

・問題例 その５： 「これも、あれもと要求項目が増えて、とても開発スケジュールは守れない。」 プロジェクトスコープが崩壊してしまっている。
・対策案：リーン製品開発の手法、マーケット要求イベント (Market Requirements Event)の適用を試みる。お客様の声を製品要求に変換して、それらの重要度を明確にし、プロジェクトスコープに反映、維持管理する。重要度の低い要求項目を、スコープから除外することで、開発スケジュールを守る。