製品開発部へのカンバン導入記(その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など、問題解決のためのフレームワークを使った新製品の開発や品質の向上、プロセスの改善を得意としています。「ものづくり」に関...


関連する他の活用事例

もっと見る
トレーサビリティの保証 プロジェクト管理の仕組み (その44)

 前回のその43に続いて解説します。    ハードウェア設計も、ソフトウェア設計ほど明確ではありませんが、同じように開発工程ごとに関連する設...

 前回のその43に続いて解説します。    ハードウェア設計も、ソフトウェア設計ほど明確ではありませんが、同じように開発工程ごとに関連する設...


ソフト開発の手戻りを小さくするには プロジェクト管理の仕組み (その8)

 前回のその7:ソフトウェア開発スケジュールと結合テストに続いて解説します。     この数回はプロジェクト管理をテーマにお話ししていますが...

 前回のその7:ソフトウェア開発スケジュールと結合テストに続いて解説します。     この数回はプロジェクト管理をテーマにお話ししていますが...


プロジェクトの計画策定 プロジェクト管理の仕組み (その3)

 前回のその2:CMMIの要件管理に続いて、プロジェクトの計画策定について解説します。CMMIでは次のことができている必要があります。   ...

 前回のその2:CMMIの要件管理に続いて、プロジェクトの計画策定について解説します。CMMIでは次のことができている必要があります。   ...