製品開発部へのカンバン導入記(その2)

更新日

投稿日

 
  クレーム対応
 
 前回からの続きです。前回は製品開発部がカンバンを導入するに至った簡単な経緯と、最初の問題点(価値を定義する)について書きました。今回は次の段階『価値(物と情報)の流れ』について書いてみたいと思います。
 

2. 価値(物と情報)の流れ図 

 
 リーンでは、第二段階で『価値の流れを図形化(マッピング)しなさい』と教えているのですが、工程が標準化されていない製品開発部ではそう簡単にはいきませんでした。図形化する前に、『現工程を理解する』という大仕事が待っていたからです。
 

(1) インタビュー

 
 製品開発工程を標準化するためには、まず現在の製品開発工程を理解しなくてはなりませんでした。そのためエンジニア一人ひとりにインタビューを行い、①どのような作業を②どのような順番で行っているのか、③それぞれの作業にはどのくらいの時間がかかっているのか、④作業上の問題点と障害は何か、などといった情報を掻き集めました。集まった情報から製品開発工程の最大公約数や最小公倍数を見つければ、現工程を理解する手掛かりが得られ、さらにそこから標準工程を設計できると思ったからです。
 
 基本的な製品開発工程には、個々のエンジニア間でそれほど大きな違いはなかったのですが、詳細な設計作業レベルともなると、個々のエンジニアの個性(バラツキ)が見えてきました。注力するところが違うせいか、設計作業時間でもエンジニア間で大きな個性(バラツキ)の違いがありました(良い意味と悪い意味で)。
 

(2) 現製品開発工程の価値(物と情報)の流れ図

 
 インタビューで集めた情報をもとにして、現製品開発工程のプロセス・マップ(つまり価値ー物の情報ーの流れ図)を作りました。といっても、この段階では個々のエンジニアが同じ工程を取っていたわけではなかったので、最大公約数をもとにした大まかな価値(物と情報)の流れ図でした。それでも以下のような問題点を把握することができました。
 
  • 開発段階(フェーズ)の定義が曖昧であり、エンジニアによっても定義が異なる
  • 従って、個々の開発段階の工程時間(サイクルタイム)がバラバラで把握できない
  • 従って、管理職への報告内容にもエンジニア間で一貫性がない
  • 従って、インテグレーション・ポイント(設計開発工程上の結合タイミング)が予定通りにならない
  • インテグレーション・ポイントになって初めて各設計チームの進捗度のバラツキが明らかになる
  • それでもインテグレーション・ポイントに時間的にも、技術的にも間に合わせるため、管理職たちは後追い的な調整に走る
  • 後追い的な調整のため、ある工程はストップし(ムラ)、ある工程には無理が生じ、ある工程には”やり直し”が生じる(無駄)
  • 結果的に NVA(Not Value-Added Time)が増え、VA(Value-Added Time)が圧迫される
  • 結果的に全行程が遅れ、品質的な問題も生じてくる
 
 物(設計開発品)の流れは明らかにスムーズではありませんでしたし、情報(開発計画や設計情報)のやり取りもタイミングが上手くいっていないようでした。
 

(3) VA/NVA

 
 インタビューを通じて、エンジニアたちがどのくらいの時間を設計活動(VA: Value-Added Time)に充てているのかを調べました。大体の数字ですが、VA/NVA の比率は 13% でした。製品開発計画などを検討し、新しい製品開発プロセスは VA/NVA 比を 最低でも 17% になるよう目標を定めました。
 

(4) 標準化レベル

 
 それらの問題を解決するために、新しい製品開発工程(価値の流れ図)を設計する必要がでできました。しかしここで新たな問題がでてきました。それは”どこまで詳細に製品開発工程を標準化するか” ということでした。
 
 製造プロセスとは違って製品開発工程には厳密な作業の繰り返しがないので、詳細なレベルでの標準化は必要ありませんし、それがかえって知的作業の害となるからです。そのため以下のガイドラインに従って、製品開発工程の標準化レベルを決めました。
 
  • カンバン・ボードを使って現工程段階が視覚的に把握できるレベル
  • 経験豊かで技術力と教育レベルの高い弊社のエンジニアが自主性と創造性を発揮できるレベル
  • 中級マネジャーが把握しなければならない製品開発工程レベル
  • カンバンから統計情報をまとめるレベル
 

3. 価値の流れを作る

 
 リーンでは、第三段階で”価値を流す”と教えています。そこで、価値の流れ図を使って洗い出したこれまでの製品開発工程の問題点を解決するために、新しい価値の流れ図を設計しました。
 

(1) 新しい製品開発工程の価値(物と情報)の流れ図

 
 現在の製品開発工程の問題点を把握し、新しい製品開発工程の標準化レベルを決めた後は、実際に新しい製品開発工程(価値の流れ図)を設計しました。設計内容は大まかに以下のようになりました。
 
  • インテグレーション・ポイントをペースメーカーとする
  • プロジェクト・マネージャーはインテグレーション・ポイントに”引き取りカンバン”を発行する
  • ペースメーカー(インテグレーション・ポイント)から各設計チームに”仕掛けカンバン”を発行する
  • 全ての設計チーム(電気、機械、ソフトウェア)が①設計②組み立て③検証④テストという四段階(フェーズ)を取る
  • 詳細な設計作業については、各設計チームが段階(フェーズ)ごとに標準タスクを定める
  • ペースメーカーと各設計チームの間にはバッファ(スーパーマーケット)を用意する
  • NA/NVA 比の向上を図る
 

(2) 価値の流れをシミュレーションする

 
 本来のリーンであれば、カンバンを使う前に、新しく設計したプロセスが意図した通りに機能するかを、時間をかけて検証する必要があるのですが、製品開発プロセスにはそのような時間はありません。製品開発のリードタイムはほぼ一年を要します。新しく設計したプロセスが上手くいく...
 
  クレーム対応
 
 前回からの続きです。前回は製品開発部がカンバンを導入するに至った簡単な経緯と、最初の問題点(価値を定義する)について書きました。今回は次の段階『価値(物と情報)の流れ』について書いてみたいと思います。
 

2. 価値(物と情報)の流れ図 

 
 リーンでは、第二段階で『価値の流れを図形化(マッピング)しなさい』と教えているのですが、工程が標準化されていない製品開発部ではそう簡単にはいきませんでした。図形化する前に、『現工程を理解する』という大仕事が待っていたからです。
 

(1) インタビュー

 
 製品開発工程を標準化するためには、まず現在の製品開発工程を理解しなくてはなりませんでした。そのためエンジニア一人ひとりにインタビューを行い、①どのような作業を②どのような順番で行っているのか、③それぞれの作業にはどのくらいの時間がかかっているのか、④作業上の問題点と障害は何か、などといった情報を掻き集めました。集まった情報から製品開発工程の最大公約数や最小公倍数を見つければ、現工程を理解する手掛かりが得られ、さらにそこから標準工程を設計できると思ったからです。
 
 基本的な製品開発工程には、個々のエンジニア間でそれほど大きな違いはなかったのですが、詳細な設計作業レベルともなると、個々のエンジニアの個性(バラツキ)が見えてきました。注力するところが違うせいか、設計作業時間でもエンジニア間で大きな個性(バラツキ)の違いがありました(良い意味と悪い意味で)。
 

(2) 現製品開発工程の価値(物と情報)の流れ図

 
 インタビューで集めた情報をもとにして、現製品開発工程のプロセス・マップ(つまり価値ー物の情報ーの流れ図)を作りました。といっても、この段階では個々のエンジニアが同じ工程を取っていたわけではなかったので、最大公約数をもとにした大まかな価値(物と情報)の流れ図でした。それでも以下のような問題点を把握することができました。
 
  • 開発段階(フェーズ)の定義が曖昧であり、エンジニアによっても定義が異なる
  • 従って、個々の開発段階の工程時間(サイクルタイム)がバラバラで把握できない
  • 従って、管理職への報告内容にもエンジニア間で一貫性がない
  • 従って、インテグレーション・ポイント(設計開発工程上の結合タイミング)が予定通りにならない
  • インテグレーション・ポイントになって初めて各設計チームの進捗度のバラツキが明らかになる
  • それでもインテグレーション・ポイントに時間的にも、技術的にも間に合わせるため、管理職たちは後追い的な調整に走る
  • 後追い的な調整のため、ある工程はストップし(ムラ)、ある工程には無理が生じ、ある工程には”やり直し”が生じる(無駄)
  • 結果的に NVA(Not Value-Added Time)が増え、VA(Value-Added Time)が圧迫される
  • 結果的に全行程が遅れ、品質的な問題も生じてくる
 
 物(設計開発品)の流れは明らかにスムーズではありませんでしたし、情報(開発計画や設計情報)のやり取りもタイミングが上手くいっていないようでした。
 

(3) VA/NVA

 
 インタビューを通じて、エンジニアたちがどのくらいの時間を設計活動(VA: Value-Added Time)に充てているのかを調べました。大体の数字ですが、VA/NVA の比率は 13% でした。製品開発計画などを検討し、新しい製品開発プロセスは VA/NVA 比を 最低でも 17% になるよう目標を定めました。
 

(4) 標準化レベル

 
 それらの問題を解決するために、新しい製品開発工程(価値の流れ図)を設計する必要がでできました。しかしここで新たな問題がでてきました。それは”どこまで詳細に製品開発工程を標準化するか” ということでした。
 
 製造プロセスとは違って製品開発工程には厳密な作業の繰り返しがないので、詳細なレベルでの標準化は必要ありませんし、それがかえって知的作業の害となるからです。そのため以下のガイドラインに従って、製品開発工程の標準化レベルを決めました。
 
  • カンバン・ボードを使って現工程段階が視覚的に把握できるレベル
  • 経験豊かで技術力と教育レベルの高い弊社のエンジニアが自主性と創造性を発揮できるレベル
  • 中級マネジャーが把握しなければならない製品開発工程レベル
  • カンバンから統計情報をまとめるレベル
 

3. 価値の流れを作る

 
 リーンでは、第三段階で”価値を流す”と教えています。そこで、価値の流れ図を使って洗い出したこれまでの製品開発工程の問題点を解決するために、新しい価値の流れ図を設計しました。
 

(1) 新しい製品開発工程の価値(物と情報)の流れ図

 
 現在の製品開発工程の問題点を把握し、新しい製品開発工程の標準化レベルを決めた後は、実際に新しい製品開発工程(価値の流れ図)を設計しました。設計内容は大まかに以下のようになりました。
 
  • インテグレーション・ポイントをペースメーカーとする
  • プロジェクト・マネージャーはインテグレーション・ポイントに”引き取りカンバン”を発行する
  • ペースメーカー(インテグレーション・ポイント)から各設計チームに”仕掛けカンバン”を発行する
  • 全ての設計チーム(電気、機械、ソフトウェア)が①設計②組み立て③検証④テストという四段階(フェーズ)を取る
  • 詳細な設計作業については、各設計チームが段階(フェーズ)ごとに標準タスクを定める
  • ペースメーカーと各設計チームの間にはバッファ(スーパーマーケット)を用意する
  • NA/NVA 比の向上を図る
 

(2) 価値の流れをシミュレーションする

 
 本来のリーンであれば、カンバンを使う前に、新しく設計したプロセスが意図した通りに機能するかを、時間をかけて検証する必要があるのですが、製品開発プロセスにはそのような時間はありません。製品開発のリードタイムはほぼ一年を要します。新しく設計したプロセスが上手くいくかどうか検証していたら、カンバンを導入する前に数年かかってしまいます。
 
 そこで新しい製品開発プロセスを検証するために、ソフトウェアを使ってシミュレーションを行いました。使った手法はモンテカルロ・シミュレーションです。
 
 新旧の価値(物と情報)の流れ図を使って、以下の項目をモンテカルロ・シミュレーションで検証しました。
 
  • 待ち時間
  • サイクルタイム
  • リードタイム
  • NA(Value-Added Time)
  • NVA(Not Value-Added Time)
 
 モンテカルロ・シミュレーションの結果を新旧比べてみると、新しい製品開発プロセスの方が明らかに優れて(改善されて)いました。VA/NVAの比率も目標の 17% を確率的に十分満たすようにもなりました。一応の検証ができた後は、この新しい価値(物と情報)の流れ図をカンバンを使って実装するだけです。
 
 次回に続きます。

   続きを読むには・・・


この記事の著者

津吉 政広

リーンやシックスシグマ、DFSSなど、問題解決のためのフレームワークを使った新製品の開発や品質の向上、プロセスの改善を得意としています。「ものづくり」に関する問題を一緒に解決してみませんか?

リーンやシックスシグマ、DFSSなど、問題解決のためのフレームワークを使った新製品の開発や品質の向上、プロセスの改善を得意としています。「ものづくり」に関...


「技術マネジメント総合」の他のキーワード解説記事

もっと見る
クレーム率シングルppmをゼロに(9) 【快年童子の豆鉄砲】(その64)

  【連関図法で把握した原因に対する対策のまとめ】 【この連載の前回:【快年童子の豆鉄砲】(その63)へのリンク】 【連載記事】・新Q...

  【連関図法で把握した原因に対する対策のまとめ】 【この連載の前回:【快年童子の豆鉄砲】(その63)へのリンク】 【連載記事】・新Q...


設計部門のマネジメント【厳選記事紹介】おすすめセミナーもご紹介

  設計部門のマネジメント、厳選記事が無料でお読みいただけます!   ◆設計部門のマネジメント 多くの製品開発は、開発着手...

  設計部門のマネジメント、厳選記事が無料でお読みいただけます!   ◆設計部門のマネジメント 多くの製品開発は、開発着手...


技術企業の高収益化【徹底解説】

  技術企業の高収益化が無料でお読みいただけます! ◆技術企業の高収益化:競合比較はなぜ悪か? 研修に先立ち、その狙いや聴講者、習得を...

  技術企業の高収益化が無料でお読みいただけます! ◆技術企業の高収益化:競合比較はなぜ悪か? 研修に先立ち、その狙いや聴講者、習得を...


「技術マネジメント総合」の活用事例

もっと見る
擦り合わせ型と組み合わせ型、目指すべき開発体制とは(その2)

【目指すべき開発体制 連載目次】 目指すべき開発体制とは(その1)擦り合わせ型と組み合わせ型 目指すべき開発体制とは(その2)日本企業文化を引きず...

【目指すべき開発体制 連載目次】 目指すべき開発体制とは(その1)擦り合わせ型と組み合わせ型 目指すべき開発体制とは(その2)日本企業文化を引きず...


マトリクス体制での品質保証3 プロジェクト管理の仕組み (その32)

 前回のマトリクス体制での品質保証2に続いて解説します。    これまで説明してきたのは、プロジェクトごとに作成する品質計画(プロジェクト品...

 前回のマトリクス体制での品質保証2に続いて解説します。    これまで説明してきたのは、プロジェクトごとに作成する品質計画(プロジェクト品...


設計部門の課題と原因分析(その2)

【設計部門の課題と原因分析 連載目次】 1. 設計部門の現状を正確に特定する 2. 課題分析と課題の根本原因除去 3. 設計部門用に用意したコン...

【設計部門の課題と原因分析 連載目次】 1. 設計部門の現状を正確に特定する 2. 課題分析と課題の根本原因除去 3. 設計部門用に用意したコン...