設計部門の仕組み改革(その3)

更新日

投稿日

【設計部門の仕組み改革 連載目次】

 前回のその2に続いて解説します。理想追求型アプローチは、本質的にリスクを抱えています。それは、システムベンダーなどが紹介する事例や成果が、自分の組織に合うかどうかがわからないという点です。あくまでも他社の例なのですから、システム機能の一つひとつについて有益かどうかは判断できても、自社の設計部門全体から見たそのシステム機能の期待効果や、導入コストまではわかりません。コンサルタントとしていくつもの設計現場を見てきましたが、設計部門全体で見るとその仕組み(開発プロセス)は様々です。どの設計部門も、長年の知恵や工夫が詰め込まれた固有の仕組みを持っています。したがって、紹介された理想型をそのまま導入できるかどうかも、他社事例を参考にできるかどうかも、費用対効果をしっかりと見極めないと大きなリスクを抱えたままの投資となってしまいます。どうして、このようなリスクがあるにもかかわらず理想追求型アプローチを採るのでしょうか。これは、設計部門における仕組み構築に対する認識の問題だと考えられます。

 理想追求型アプローチを採る設計部門の方と話をすると感じるのですが、仕組み構築の行程は、ゴール(あるべき姿)に向かう一本道を、多少の障害があるものの、とにかく前進してゴールを目指すものと考えているようです。しかし、私は、設計部門における仕組み構築は下表のように山登りだと考えています。
 
                          R&D
   
 仕組み構築の目標(ゴール)は開発効率2倍、開発期間 1/2 などと様々ですが、上表ではそれを頂上とし、開発効率 20% アップ、40% アップなどの途中の段階を(標高)レベルとしてあらわしています。現在の状態は山の麓のレベル1で、仕組み構築とは、レベルを一つひとつ上げていき、最終的に頂上にたどり着くという活動です。
 
 設計部門といっても作っている製品や、技術者、設備、規模、歴史など様々です。先ほども、設計部門全体で見るとその仕組みは固有で様々だと述べました。したがって、現時点(レベル1)におけるポジションは様々です。そして、同じ頂上を目指すとしても、そこまでのルートも様々なのです。ひとつ上のレベルに登るのでも、その位置取りには選択の余地があります。東側を目指すのか、南側を目指すのか、選択の余地は小さくありません。さらにその一つ上のレベルに登るときも同じです。つまり、現在地点からゴールまでのルート選択には非常に多くの選択肢が存在しているのです。時には、他社事例という他の登山隊が通ったルートを選択することができるかもしれませんが、また別の時には、ルートそのものを開拓しなければならない場合もあります。

 製品、技術、スキル、マネジメント、歴史など様々な要素から成り立っているのが設計部門なのですから、その仕組み構築とは一本道を進む活動なのではなく、頂上を目指す山登りなのです。そして、ゴール設定も重要ですが、ゴールまでのルート選択が成功と失敗を決めることになるのです。

 以上、ある製品開発事例を使って、開発効率2倍をゴールとして、製品開発の現状を工数という視点から定量化して、そこから現状の課題を明らかにして、その課題解決のためのルート候補をリストアップしてみました。次にやるべきことは、このルート候補を評価してどのルートがゴールまでの最短ルートなのかを評価することです。
 
                       R&D
                                       図20.製品開発における開発工程ごとの工数推移
    
 ところで、図20 の例では、構想設計に大きな時間がかかっていること、開発試作と2Sにピークがあることも気になる点です。次回は、これらの気になる点に加えて、個別の開発プロジェクトだけではなく、設計部門全体の現状についても把握した上で、ゴールまでのルート候補の評価を行う過程についてお伝えしたいと思います。ゴールを開発効率2倍と設定するということは、その達成のためのロジックを考える際に、今回のように定量的に現状を把握する必要があることを忘れないでください。仕組み構築の最初のステップは、仕組み構築のプランニングに必要となる定量把握の仕組み...

【設計部門の仕組み改革 連載目次】

 前回のその2に続いて解説します。理想追求型アプローチは、本質的にリスクを抱えています。それは、システムベンダーなどが紹介する事例や成果が、自分の組織に合うかどうかがわからないという点です。あくまでも他社の例なのですから、システム機能の一つひとつについて有益かどうかは判断できても、自社の設計部門全体から見たそのシステム機能の期待効果や、導入コストまではわかりません。コンサルタントとしていくつもの設計現場を見てきましたが、設計部門全体で見るとその仕組み(開発プロセス)は様々です。どの設計部門も、長年の知恵や工夫が詰め込まれた固有の仕組みを持っています。したがって、紹介された理想型をそのまま導入できるかどうかも、他社事例を参考にできるかどうかも、費用対効果をしっかりと見極めないと大きなリスクを抱えたままの投資となってしまいます。どうして、このようなリスクがあるにもかかわらず理想追求型アプローチを採るのでしょうか。これは、設計部門における仕組み構築に対する認識の問題だと考えられます。

 理想追求型アプローチを採る設計部門の方と話をすると感じるのですが、仕組み構築の行程は、ゴール(あるべき姿)に向かう一本道を、多少の障害があるものの、とにかく前進してゴールを目指すものと考えているようです。しかし、私は、設計部門における仕組み構築は下表のように山登りだと考えています。
 
                          R&D
   
 仕組み構築の目標(ゴール)は開発効率2倍、開発期間 1/2 などと様々ですが、上表ではそれを頂上とし、開発効率 20% アップ、40% アップなどの途中の段階を(標高)レベルとしてあらわしています。現在の状態は山の麓のレベル1で、仕組み構築とは、レベルを一つひとつ上げていき、最終的に頂上にたどり着くという活動です。
 
 設計部門といっても作っている製品や、技術者、設備、規模、歴史など様々です。先ほども、設計部門全体で見るとその仕組みは固有で様々だと述べました。したがって、現時点(レベル1)におけるポジションは様々です。そして、同じ頂上を目指すとしても、そこまでのルートも様々なのです。ひとつ上のレベルに登るのでも、その位置取りには選択の余地があります。東側を目指すのか、南側を目指すのか、選択の余地は小さくありません。さらにその一つ上のレベルに登るときも同じです。つまり、現在地点からゴールまでのルート選択には非常に多くの選択肢が存在しているのです。時には、他社事例という他の登山隊が通ったルートを選択することができるかもしれませんが、また別の時には、ルートそのものを開拓しなければならない場合もあります。

 製品、技術、スキル、マネジメント、歴史など様々な要素から成り立っているのが設計部門なのですから、その仕組み構築とは一本道を進む活動なのではなく、頂上を目指す山登りなのです。そして、ゴール設定も重要ですが、ゴールまでのルート選択が成功と失敗を決めることになるのです。

 以上、ある製品開発事例を使って、開発効率2倍をゴールとして、製品開発の現状を工数という視点から定量化して、そこから現状の課題を明らかにして、その課題解決のためのルート候補をリストアップしてみました。次にやるべきことは、このルート候補を評価してどのルートがゴールまでの最短ルートなのかを評価することです。
 
                       R&D
                                       図20.製品開発における開発工程ごとの工数推移
    
 ところで、図20 の例では、構想設計に大きな時間がかかっていること、開発試作と2Sにピークがあることも気になる点です。次回は、これらの気になる点に加えて、個別の開発プロジェクトだけではなく、設計部門全体の現状についても把握した上で、ゴールまでのルート候補の評価を行う過程についてお伝えしたいと思います。ゴールを開発効率2倍と設定するということは、その達成のためのロジックを考える際に、今回のように定量的に現状を把握する必要があることを忘れないでください。仕組み構築の最初のステップは、仕組み構築のプランニングに必要となる定量把握の仕組みかもしれません。
 
 

   続きを読むには・・・


この記事の著者

石橋 良造

組織のしくみと個人の意識を同時に改革・改善することで、パフォーマンス・エクセレンスを追求し、実現する開発組織に変えます!

組織のしくみと個人の意識を同時に改革・改善することで、パフォーマンス・エクセレンスを追求し、実現する開発組織に変えます!


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

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

  【この連載の前回へのリンク】 現在「切り取った知識の重要部分を発想するフレームワークを使って、イノベーションを発想する」にむけて、日...

  【この連載の前回へのリンク】 現在「切り取った知識の重要部分を発想するフレームワークを使って、イノベーションを発想する」にむけて、日...


知識・経験を物理量で整理する 普通の組織をイノベーティブにする処方箋 (その67)

 前回までは、知識や経験を時系列で整理するという話をしてきましたが、当然時系列以外の物理量という軸があります。今回からは「知識・経験を物理量で整理する...

 前回までは、知識や経験を時系列で整理するという話をしてきましたが、当然時系列以外の物理量という軸があります。今回からは「知識・経験を物理量で整理する...


普通の組織をイノベーティブにする処方箋 (その173) 擬人化体験とは

【目次】   【この連載の前回:普通の組織をイノベーティブにする処方箋 (その172)へのリンク】 前回は無生物の物に自分がなった...

【目次】   【この連載の前回:普通の組織をイノベーティブにする処方箋 (その172)へのリンク】 前回は無生物の物に自分がなった...


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

もっと見る
システム設計4 プロジェクト管理の仕組み (その36)

 前回はシステム設計を、開発工程上はシステムエンジニアリングと、ハードやソフトなどのサブシステムのエンジニアリングの両方と定義しました。ここで、システムエ...

 前回はシステム設計を、開発工程上はシステムエンジニアリングと、ハードやソフトなどのサブシステムのエンジニアリングの両方と定義しました。ここで、システムエ...


プロジェクトの問題を見極める1 プロジェクト管理の仕組み (その23)

 進捗管理のための基本メトリクスセットのひとつである開発工数メトリクスについて解説していますが、前回は、プロジェクト構造(WBS)軸とアクティビティ軸のそ...

 進捗管理のための基本メトリクスセットのひとつである開発工数メトリクスについて解説していますが、前回は、プロジェクト構造(WBS)軸とアクティビティ軸のそ...


進捗管理の精度を上げる:第3回 プロジェクト管理の仕組み (その15)

 回路図や実装図からは、端子数以外にも標準部品、後付部品、自動実装機部品などをカウントすることも可能です。図45 は、これらについて見積もり(計画)を作成...

 回路図や実装図からは、端子数以外にも標準部品、後付部品、自動実装機部品などをカウントすることも可能です。図45 は、これらについて見積もり(計画)を作成...