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

更新日

投稿日

 
  技術マネジメント
 
 製品開発部の複雑な開発業務の流れ整理し、迅速化し、可視化するために、リーンを製品開発部に導入しようとしています。”リーン開発”という言葉は聞こえが良いのですが、実際の製品開発部はその配下で、機械設計グループ、電気設計グループ、基板設計グループ、実験チーム、テストグループ、文書管理チーム、など多岐多様なグループやチームが複雑に絡み合っているので、その複雑で目に見えない業務の流れを整えることは大変です。それでもリーンを使ったプロジェクトを通じで、業務改善という目標に向けて、少しずつ進んでいます。
 
 リーンを使ったプロジェクトなので、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など、問題解決のためのフレームワークを使った新製品の開発や品質の向上、プロセスの改善を得意としています。「ものづくり」に関...


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

もっと見る
シックスシグマの概要 シックスシグマ (その1)

 シックスシグマとは品質管理面での対日本戦略として生み出され、顧客に対し、ほぼ欠陥の無いサービスを提供するというビジョンに基づいた経営管理体系です。シグマ...

 シックスシグマとは品質管理面での対日本戦略として生み出され、顧客に対し、ほぼ欠陥の無いサービスを提供するというビジョンに基づいた経営管理体系です。シグマ...


バリュー・ストリーム・マップを作る22のステップとは

   バリュー・ストリーム・マップは時にはプロセスを単純化し過ぎることもありますが、チームでプロセス全体を把握し、無駄を削減するためのアクショ...

   バリュー・ストリーム・マップは時にはプロセスを単純化し過ぎることもありますが、チームでプロセス全体を把握し、無駄を削減するためのアクショ...


リーンシックスシグマ・プロジェクト:測定フェーズと GQM パラダイム

   リーンシックスシグマのプロジェクトは、各フェーズの終わりにミーティング(Tollgate Review Meeting)を設けて、そのフ...

   リーンシックスシグマのプロジェクトは、各フェーズの終わりにミーティング(Tollgate Review Meeting)を設けて、そのフ...


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

もっと見る
スケールド・アジャイル・フレームワーク (SAFe) 初めての PI プランニング

        僕が勤める部門で導入を進めている スケールド・アジャイル・フレームワーク(SAFe)の初めて...

        僕が勤める部門で導入を進めている スケールド・アジャイル・フレームワーク(SAFe)の初めて...


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

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

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


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

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

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