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

更新日

投稿日

 
 リーンシックスシグマで使うツールの多くは意思決定を助けます。優先順位をつけて意思決定を助けたり、システマチックな思考順序が意思決定に導いたりします。例えば典型的な例は Pugh マトリックスです。与えられた規準を使っていくつかの選択肢の中から一番良いもの客観的に選ぶことができます。他にも意思決定ツールとしては、コンセプト FMEA やデシジョン・ツリーなど、色々とあります。
 
 的確な意思決定をプロジェクトの早い段階で行うことができれば、プロジェクトを最短距離で進めることができるため、プロジェクトの迅速化とコストの削減につながります。そのためリーンシックスシグマでは、プロジェクトの早い段階(Define/定義、Measure/測定、Analyze/分析フェースなど)で色々な意思決定ツールを使ってきました。
 
 しかし、プロジェクトの早い段階で正しい意思決定をすることなど可能なのでしょうか。意思決定が早ければ早いほど、かえってリスクが多くならないでしょうか。例えば、「早い段階で意思決定を行って最短距離でプロジェクトを進めていたとしても、プロジェクトを進めるに従って新しい情報が入ってきて、その意思決定の誤りに気付き、プロジェクトを再び一からやり直す」ようなリスクです。
 
 そのため、正しく十分な情報が得られるまでは、かえって意思決定などしない方が良いのではないでしょうか。意思決定を遅らせれば遅らせるほど、やり直しのリスクが減らせるのではないでしょうか。アジャイルなどのソフトウェア開発手法はこの「意思決定を遅らせる」という考え方を基本にしていますが、ソフトウェア開発以外にも同じような考え方を当てはめることができないのでしょうか。
 
 そのようなことを考えるようになったきっかけが最近二つありました。一つは UX デザイン(User Experience Design)の中で使う SUM(Single Usability Metric: 利便性の尺度)の説明をしていた時に、ある人に「選択するいくつかの設計アイデア同士で、もし SUM の値が近かった場合はどうするのか?」と質問されたことです。二つ目は別の場面で Pugh マトリックスを意思決定のために会議の中で使っていたとき、選択するアイデア同士で結果がとても近くなってしまい、会議の中で「どうする?」と聞かれたことです。取り合えずその場を取り繕うつもりで、「アイデア同士の違いがはっきりするように、もう一度評価し直しましょう」と答えましたが、改めて考えると、それも違うように思えたのです。
 
 今、同じ状況で同じ事を聞かれれば、きっと「似たような結果が得られたのであれば、現時点ではそれらはすべて採用しましょう」と答えるでしょう。
 
 少し前の時代は、意思決定を遅らせれば遅らせるほど、コストが高くなりました。例えばプロセスの改善にしろ、製品の設計にしろ、焦点を一つに絞りきれずに資源が分散してしまうからです。機械設計を例に取ると、いくつものアイデアを同時に設計することは、それだけでコストが2倍、3倍となってしまいます。そのために早い段階での意思決定が重要でした。
 
   シックスシグマ
 
 今はどうでしょうか。機械設計の殆どは CAD などを使ってコンピュータ上で行われます。いくつものアイデアを同時に設計しても、それほどコストに違いが出てきません。プロセスの改善といったプロジェクトでも、ビジネス・プロセス・モデリング・ソフトウェアで簡単にプロセスの設計とシミュレーションができるようになりました。いくつかのプロセス改...
 
 リーンシックスシグマで使うツールの多くは意思決定を助けます。優先順位をつけて意思決定を助けたり、システマチックな思考順序が意思決定に導いたりします。例えば典型的な例は Pugh マトリックスです。与えられた規準を使っていくつかの選択肢の中から一番良いもの客観的に選ぶことができます。他にも意思決定ツールとしては、コンセプト FMEA やデシジョン・ツリーなど、色々とあります。
 
 的確な意思決定をプロジェクトの早い段階で行うことができれば、プロジェクトを最短距離で進めることができるため、プロジェクトの迅速化とコストの削減につながります。そのためリーンシックスシグマでは、プロジェクトの早い段階(Define/定義、Measure/測定、Analyze/分析フェースなど)で色々な意思決定ツールを使ってきました。
 
 しかし、プロジェクトの早い段階で正しい意思決定をすることなど可能なのでしょうか。意思決定が早ければ早いほど、かえってリスクが多くならないでしょうか。例えば、「早い段階で意思決定を行って最短距離でプロジェクトを進めていたとしても、プロジェクトを進めるに従って新しい情報が入ってきて、その意思決定の誤りに気付き、プロジェクトを再び一からやり直す」ようなリスクです。
 
 そのため、正しく十分な情報が得られるまでは、かえって意思決定などしない方が良いのではないでしょうか。意思決定を遅らせれば遅らせるほど、やり直しのリスクが減らせるのではないでしょうか。アジャイルなどのソフトウェア開発手法はこの「意思決定を遅らせる」という考え方を基本にしていますが、ソフトウェア開発以外にも同じような考え方を当てはめることができないのでしょうか。
 
 そのようなことを考えるようになったきっかけが最近二つありました。一つは UX デザイン(User Experience Design)の中で使う SUM(Single Usability Metric: 利便性の尺度)の説明をしていた時に、ある人に「選択するいくつかの設計アイデア同士で、もし SUM の値が近かった場合はどうするのか?」と質問されたことです。二つ目は別の場面で Pugh マトリックスを意思決定のために会議の中で使っていたとき、選択するアイデア同士で結果がとても近くなってしまい、会議の中で「どうする?」と聞かれたことです。取り合えずその場を取り繕うつもりで、「アイデア同士の違いがはっきりするように、もう一度評価し直しましょう」と答えましたが、改めて考えると、それも違うように思えたのです。
 
 今、同じ状況で同じ事を聞かれれば、きっと「似たような結果が得られたのであれば、現時点ではそれらはすべて採用しましょう」と答えるでしょう。
 
 少し前の時代は、意思決定を遅らせれば遅らせるほど、コストが高くなりました。例えばプロセスの改善にしろ、製品の設計にしろ、焦点を一つに絞りきれずに資源が分散してしまうからです。機械設計を例に取ると、いくつものアイデアを同時に設計することは、それだけでコストが2倍、3倍となってしまいます。そのために早い段階での意思決定が重要でした。
 
   シックスシグマ
 
 今はどうでしょうか。機械設計の殆どは CAD などを使ってコンピュータ上で行われます。いくつものアイデアを同時に設計しても、それほどコストに違いが出てきません。プロセスの改善といったプロジェクトでも、ビジネス・プロセス・モデリング・ソフトウェアで簡単にプロセスの設計とシミュレーションができるようになりました。いくつかのプロセス改善案を同時に検討することも可能です。
 
 シミュレーションを使ってコンピュータ上でアイデアの評価ができるのであれば、なにも急いで意思決定をする必要はありません。正しく十分な情報が整うまで意思決定を遅らせれば良いだけです。遅らせれば遅らせるほど、意思決定を失敗するリスクが減らせます。
 
 しかし人の心とこれまでの経験がそうはさせてくれないようです。会議でも「結論ありきの人」や、「結論を急ぐ人」が多く見受けられます。いくつものアイデアを平行して進めることをムダと考える人も多くいます。これほどシミュレーション・ソフトウェアが発達しても、なかなか人の心は変わらないものです。
 

   続きを読むには・・・


この記事の著者

津吉 政広

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

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


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

もっと見る
リーンシックスシグマ:計測の反復性と再現性の分析

        今回は、少し技術的なこと、データ測定について解説します。    シックスシグマ...

        今回は、少し技術的なこと、データ測定について解説します。    シックスシグマ...


DFSS(Design for Six Sigma)のリスキリング 【厳選記事紹介】

  リーンシックスシグマは聞いたことがあっても、DFSS(Design for Six Sigma)はあまり耳慣れない言葉かもしれません。...

  リーンシックスシグマは聞いたことがあっても、DFSS(Design for Six Sigma)はあまり耳慣れない言葉かもしれません。...


DFSSとは何か 【連載記事紹介】

  DFSSとは何かの連載が無料でお読みいただけます。   リーンシックスシグマは聞いたことがあっても、DFSS(Desig...

  DFSSとは何かの連載が無料でお読みいただけます。   リーンシックスシグマは聞いたことがあっても、DFSS(Desig...


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

もっと見る
TRIZ を使用した DfSS事例 (その2)

   前回のその1に続いて解説します。   5. D/O(Design and Optimize/設計と最適化)フェーズ &n...

   前回のその1に続いて解説します。   5. D/O(Design and Optimize/設計と最適化)フェーズ &n...


問題の具現化が解決への近道

 『シックスシグマ』の問題解決サイクルDMAICは、一番最初に問題を定義するDefineフェイズから始めます。改善対象を出来るだけ具現化し、目的を明確にす...

 『シックスシグマ』の問題解決サイクルDMAICは、一番最初に問題を定義するDefineフェイズから始めます。改善対象を出来るだけ具現化し、目的を明確にす...


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

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

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