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


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

もっと見る
普通の組織をイノベーティブにする処方箋 (その22)

 前回は形式知の問題点の解説しましたが、今回はイノベーションを起こす上で必要となる5つの要素についてです。 ◆関連解説『技術マネジメントとは』 &nb...

 前回は形式知の問題点の解説しましたが、今回はイノベーションを起こす上で必要となる5つの要素についてです。 ◆関連解説『技術マネジメントとは』 &nb...


普通の組織をイノベーティブにする処方箋 (その180)妄想とイノベーション創出 

・見出しの番号は、前回からの連番です。 【目次】 妄想はネガティブに捉えられがちですが、私は妄想はイノベーション創出において、極め...

・見出しの番号は、前回からの連番です。 【目次】 妄想はネガティブに捉えられがちですが、私は妄想はイノベーション創出において、極め...


ビジネスモデルの欠落 『価値づくり』の研究開発マネジメント (その22)

    オープンイノベーションに取り組む日本企業に欠けている重大な問題に、『ビジネスモデルの欠落』があります。今回はこのテーマについて解...

    オープンイノベーションに取り組む日本企業に欠けている重大な問題に、『ビジネスモデルの欠落』があります。今回はこのテーマについて解...


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

もっと見る
仕組みの見直しに成功する組織1 プロジェクト管理の仕組み (その25)

 この連載では、仕組みの見直しをテーマに様々な考え方や事例を紹介しているわけですが、実際にコンサルタントして仕組みの見直しに取り組んだ組織の中には成功して...

 この連載では、仕組みの見直しをテーマに様々な考え方や事例を紹介しているわけですが、実際にコンサルタントして仕組みの見直しに取り組んだ組織の中には成功して...


製品設計におけるトレードオフのコントロールとは

        今回は、次のような想定で、製品設計におけるトレードオフのコントロールをどう考えればよいかを解...

        今回は、次のような想定で、製品設計におけるトレードオフのコントロールをどう考えればよいかを解...


進捗の見える化:第3回 プロジェクト管理の仕組み (その12)

 前回の進捗の見える化:第2回に続いて解説します。    最後は、プロジェクトの入力である開発工数です。これで、基本メトリクスセットすべてに...

 前回の進捗の見える化:第2回に続いて解説します。    最後は、プロジェクトの入力である開発工数です。これで、基本メトリクスセットすべてに...