製品開発業務が価値を生み出している時間とは

更新日

投稿日

 
  技術マネジメント
 
 製品開発部の複雑な開発業務の流れ整理し、迅速化し、可視化するために、リーンを製品開発部に導入しようとしています。”リーン開発”という言葉は聞こえが良いのですが、実際の製品開発部はその配下で、機械設計グループ、電気設計グループ、基板設計グループ、実験チーム、テストグループ、文書管理チーム、など多岐多様なグループやチームが複雑に絡み合っているので、その複雑で目に見えない業務の流れを整えることは大変です。それでもリーンを使ったプロジェクトを通じで、業務改善という目標に向けて、少しずつ進んでいます。
 
 リーンを使ったプロジェクトなので、VA(Value-Added Time: 価値を生み出している時間)と NVA(Non Value-Added Time: 価値を生み出していない時間)を測定して、その VA と NVA の比率(VA/NVA)を高めることを目標にしています。
 
 価値とは、顧客にとっての価値です。簡単に言えば、「顧客がお金を払っても良いと思えるもの」が価値であり、そうでないものは無価値です。その定義に従えば、製品開発部の設計業務の殆どが価値であり、エンジニアがその価値を生み出します。設計業務に携わっていないマネジャーは無価値です。もちろん僕の業務(リーンシックスシグマのプロジェクト管理)も無価値です。顧客は製品に価値を求めるものであって、マネジメントやリーンシックスシグマにはまったく興味がないからです。
 
 しかし製品開発部の設計業務の殆どが価値だと言っても、エンジニアが 100% の時間を使って価値を生み出している訳ではありません。なぜなら仮に 100% の勤務時間を働いていたとしても、顧客が本当にお金を払っても良いと思える設計業務を行っている時間は限られたものだからです。
 
 工場などの生産現場であれば、各工程に掛かる時間(サイクルタイム)を測定することで、VA と NVA を割り出せます。しかし複雑に絡み合った目に見えない製品開発業務で VA と NVA を直接測定することは、個々のエンジニアを監視しない限り不可能です。
 
 VA と NVA を直接測定することは不可能なので、その代わりに、このプロジェクトでは間接的に、大雑把に、しかも簡単に VA と NVA を把握しようと試みました。プロジェクトの目標は VA と NVA の比率を高めることなので、精密なデータを収集するために時間とお金をかける必要はありませんし、仮に精密なデータを収集したところで、そのデータの信頼性には疑わしいものがあります。何事もバランスが大事です。そこでこのプロジェクトでは、先の投稿でも書いたように、アンケートによって VA と NVA を捉えようとしました。
 
 リーンや、リーンシックスシグマを知らないエンジニア達に「あなたのValue-Added Time、即ち、価値を生み出している時間はどれだけですか?」と聞いたところで、まともな回答が得られるとは思いません。それどころか、顧客から見た「価値」を定義してもらうだけで大変なことです。
 
 そこで今回のアンケートでは、プロジェクトの内容に沿って、
 
  • VA の割合 = 開発業務を行っている割合 – 開発業務を行っている割合
  • (業務やり直しの割合 + サポート業務の割合 + 待ち時間の割合 + 計画に入っていない仕事の割合) 
  • NVAの割合 = 100% – VA の割合
 
 としました。そしてエンジニア達には、それぞれの要素(割合)について個別に回答してもらいました。
 
 つまりエンジニア達は開発業務を行っているつもりでも、実際は、設計のやり直しであったり、同僚や他部署の手助けだったり、何かを待っている時間であったり、計画に入っていない仕事だったりするわけです。sそのためエンジニア達が仕事だと思っている時間から、価値の創造に関係のない時間を引いたものを VA としたのです。
 
 アンケートの調査によると
 
  • 開発業務を行っている割合 67.8%
  • 業務やり直しの割合 12.7%
  • サポート業務の割合 14.9%
  • 待ち時間の割合 15.5%
  • 計画に入っていない仕事 12.0%
 
 という結果が得られ、VA の割合は 13.0%、そして NVA の割合は 87.0% となりました。
 
 一般に、オフィスワークでの VA と NVA の比はそれぞれ 5% と 95% と言われています。このアンケート結果の 13.0% という数字は、一般的なオフィスワークのデータと比...
 
  技術マネジメント
 
 製品開発部の複雑な開発業務の流れ整理し、迅速化し、可視化するために、リーンを製品開発部に導入しようとしています。”リーン開発”という言葉は聞こえが良いのですが、実際の製品開発部はその配下で、機械設計グループ、電気設計グループ、基板設計グループ、実験チーム、テストグループ、文書管理チーム、など多岐多様なグループやチームが複雑に絡み合っているので、その複雑で目に見えない業務の流れを整えることは大変です。それでもリーンを使ったプロジェクトを通じで、業務改善という目標に向けて、少しずつ進んでいます。
 
 リーンを使ったプロジェクトなので、VA(Value-Added Time: 価値を生み出している時間)と NVA(Non Value-Added Time: 価値を生み出していない時間)を測定して、その VA と NVA の比率(VA/NVA)を高めることを目標にしています。
 
 価値とは、顧客にとっての価値です。簡単に言えば、「顧客がお金を払っても良いと思えるもの」が価値であり、そうでないものは無価値です。その定義に従えば、製品開発部の設計業務の殆どが価値であり、エンジニアがその価値を生み出します。設計業務に携わっていないマネジャーは無価値です。もちろん僕の業務(リーンシックスシグマのプロジェクト管理)も無価値です。顧客は製品に価値を求めるものであって、マネジメントやリーンシックスシグマにはまったく興味がないからです。
 
 しかし製品開発部の設計業務の殆どが価値だと言っても、エンジニアが 100% の時間を使って価値を生み出している訳ではありません。なぜなら仮に 100% の勤務時間を働いていたとしても、顧客が本当にお金を払っても良いと思える設計業務を行っている時間は限られたものだからです。
 
 工場などの生産現場であれば、各工程に掛かる時間(サイクルタイム)を測定することで、VA と NVA を割り出せます。しかし複雑に絡み合った目に見えない製品開発業務で VA と NVA を直接測定することは、個々のエンジニアを監視しない限り不可能です。
 
 VA と NVA を直接測定することは不可能なので、その代わりに、このプロジェクトでは間接的に、大雑把に、しかも簡単に VA と NVA を把握しようと試みました。プロジェクトの目標は VA と NVA の比率を高めることなので、精密なデータを収集するために時間とお金をかける必要はありませんし、仮に精密なデータを収集したところで、そのデータの信頼性には疑わしいものがあります。何事もバランスが大事です。そこでこのプロジェクトでは、先の投稿でも書いたように、アンケートによって VA と NVA を捉えようとしました。
 
 リーンや、リーンシックスシグマを知らないエンジニア達に「あなたのValue-Added Time、即ち、価値を生み出している時間はどれだけですか?」と聞いたところで、まともな回答が得られるとは思いません。それどころか、顧客から見た「価値」を定義してもらうだけで大変なことです。
 
 そこで今回のアンケートでは、プロジェクトの内容に沿って、
 
  • VA の割合 = 開発業務を行っている割合 – 開発業務を行っている割合
  • (業務やり直しの割合 + サポート業務の割合 + 待ち時間の割合 + 計画に入っていない仕事の割合) 
  • NVAの割合 = 100% – VA の割合
 
 としました。そしてエンジニア達には、それぞれの要素(割合)について個別に回答してもらいました。
 
 つまりエンジニア達は開発業務を行っているつもりでも、実際は、設計のやり直しであったり、同僚や他部署の手助けだったり、何かを待っている時間であったり、計画に入っていない仕事だったりするわけです。sそのためエンジニア達が仕事だと思っている時間から、価値の創造に関係のない時間を引いたものを VA としたのです。
 
 アンケートの調査によると
 
  • 開発業務を行っている割合 67.8%
  • 業務やり直しの割合 12.7%
  • サポート業務の割合 14.9%
  • 待ち時間の割合 15.5%
  • 計画に入っていない仕事 12.0%
 
 という結果が得られ、VA の割合は 13.0%、そして NVA の割合は 87.0% となりました。
 
 一般に、オフィスワークでの VA と NVA の比はそれぞれ 5% と 95% と言われています。このアンケート結果の 13.0% という数字は、一般的なオフィスワークのデータと比べても、また実際のエンジニアの様子と比べても十分納得できる数字です。
 
 アンケートによって良いデータが入手できたと思っています。後はプロジェクトを通じて、
 
  • 業務のやり直しを減らす
  • 突発的な他部署や同僚のサポート業務を減らす
  • データや部品、フィードバックの待ち時間を減らす
  • 計画に入っていない不要な仕事を減らす
 
 だけです。プロジェクトの完了後は、VA と NVA の割合が変わっているはずです。つまり、顧客にとっての価値を創造する時間が増えていることと思います。
 
 このプロジェクトは、複雑で目に見えない製品開発業務を、VA と NVA を導入することで数値化し、改善の目標にすることができたと思います。
 

   続きを読むには・・・


この記事の著者

津吉 政広

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

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


「シックスシグマ」の他のキーワード解説記事

もっと見る
導入の 4 段階 スマートファクトリとリーンシックスシグマ (その1)

   スマートファクトリ(またはインダストリアル IoT)の話題が盛り上がっています。産業関連のウェブサイトを見ても、ここ数年の間にスマートフ...

   スマートファクトリ(またはインダストリアル IoT)の話題が盛り上がっています。産業関連のウェブサイトを見ても、ここ数年の間にスマートフ...


DFSSの典型的な型(設計フェーズと確認フェーズのみ抜粋)

   リーンシックスシグマ(DMAIC)や DFSS (DMADV)は問題解決のためのフレームワークです。そのフレームワークの中で様々なツール...

   リーンシックスシグマ(DMAIC)や DFSS (DMADV)は問題解決のためのフレームワークです。そのフレームワークの中で様々なツール...


DFSS 導入の難しさ DFSS とは何か(その3)

       【DFSS とは何か、連載目次】 1. DFSS とは何か(その1) DFSS は強力な...

       【DFSS とは何か、連載目次】 1. DFSS とは何か(その1) DFSS は強力な...


「シックスシグマ」の活用事例

もっと見る
あえて意思決定を遅らせるとは

   リーンシックスシグマで使うツールの多くは意思決定を助けます。優先順位をつけて意思決定を助けたり、システマチックな思考順序が意思決定に導い...

   リーンシックスシグマで使うツールの多くは意思決定を助けます。優先順位をつけて意思決定を助けたり、システマチックな思考順序が意思決定に導い...


DPMOとは何か

 DPMOとはDefects Per Million Opportunityのイニシャルを取ったものです。DPMOを百万個当りの欠陥数(製品百万個当りの不...

 DPMOとはDefects Per Million Opportunityのイニシャルを取ったものです。DPMOを百万個当りの欠陥数(製品百万個当りの不...


TRIZ を使用した DfSS事例 (その1)

        今回は事例として TRIZ を実際に使用した DfSS(Design for Six Sig...

        今回は事例として TRIZ を実際に使用した DfSS(Design for Six Sig...