設計部門の仕組み構築(その3)

更新日

投稿日

【設計部門の仕組み構築 連載目次】

 
 前回までで、解決すべき根本原因の全容が明らかになりました。次にやることは、これらの根本原因を解消することができる具体的な対策を選び、実際の効果を推定することです。この段階でやっと、ツールやシステム、手法・技法などの調査や検討が必要になります。図23は、根本原因を否定文ではなく肯定文にすることで、対策方針の表現にしたものです。対策方針にしたがって具体化した対策(例)も記述しています。
 
       R&D
図23.対策方針と実施する対策
 
 個々の対策について具体的な内容には触れませんが、どの開発工程の効率化に寄与するのかを図24に分類しておきます。また、これらの対策を実施することによって、開発現場がどのような状態になるのかを考えましょう。
 
        R&D
図24.実施する対策の工数削減効果
 
 ・試作回数が1回削減(2Sまでで顧客認定完了)
 ・設計開始時には直前の試作評価は完了している
 ・顧客対応技術者はほとんど客先常駐で仕様打ち合わせを実施
 ・プロジェクト管理者は複数の開発を同時に見ている
 ・再利用モジュールや技術情報の検索ノウハウが共有されている
 ・差分開発により設計、評価が効率化している
 ・製造からの指摘(製造性不具合)は大幅に減っている
 ・他モデル開発も含めて柔軟かつ混乱の少ないメンバーアサインが実施されている
 ・設計部門全体の開発状況をリアルタイムに把握している
 ・品質保証部門の管理下で改善活動が継続的に実施されている
 
 この段階で、考えた対策に適した使い方ができるかどうかの観点で、ツールやシステム、手法や技法などを特定します。「評価工数が大幅削減」「充実したプロジェクト管理機能」などのキーワードで判断したり、提供している機能や仕組みの豊富さで判断するものではないことは、いうまでもないと思います。対策効果は、これも詳細は省略しますが、図25の左側のグラフに示すように開発効率をほぼ2倍にすることが可能だと試算できました。もし、この段階で開発効率2倍が未達であれば、別の対策を検討する必要があります。また、右側のグラフは試作から量産までの各段階の工数がどのように減るのかを示しています。これで目指すべき開発の姿が明確になっています。
 
       R&D
図25.開発工数削減の期待効果
 
 この段階では、システムや技法などが特定でき、対策実施のために必要となる費用も概略把握できます。場合によっては、予算との兼ね合いで対策の取捨選択を検討する必要も生じます。その場合は、対策ごとの工数削減効果と必要になる費用とのバランスで取捨選択することになります。そのためには、図24の詳細データが必要になりますが今回は省略します。
 
 以上で、開発効率2倍という頂上まで行くことができること、そして、頂上までの概略ルート(実施すべき対策セット)が明らかになりました。しかし、登山するにはまだ危険です。道に迷う危険性をもっと減らすために登山ルート(コース)はできる限り具体化する必要があります。食料や天候のことも考慮してスケジュール(時間軸)も具体化する必要があります。さらには、登山パーティを見直す必要もあるかもしれません。具体的には、対策実施の体制作りや上位マネジメントとの関係構築なども並行して実施する必要があります。
 
 このように、登山ルートを具体化するという最後の段階は、「政治的」なことが要求される段階です。スケジュールを作成するためには、部署間・マネジャー間の力関係、設計部門あるいは事業部としての中短期方針、上位マネジメントの説得、対策実施メンバーの確保などなど、政治的な様々なことを考慮し、実行に移すことが要求されます。
 
 政治的なことについては次回に解説します。詳細を省略した部分も多いと思います...

【設計部門の仕組み構築 連載目次】

 
 前回までで、解決すべき根本原因の全容が明らかになりました。次にやることは、これらの根本原因を解消することができる具体的な対策を選び、実際の効果を推定することです。この段階でやっと、ツールやシステム、手法・技法などの調査や検討が必要になります。図23は、根本原因を否定文ではなく肯定文にすることで、対策方針の表現にしたものです。対策方針にしたがって具体化した対策(例)も記述しています。
 
       R&D
図23.対策方針と実施する対策
 
 個々の対策について具体的な内容には触れませんが、どの開発工程の効率化に寄与するのかを図24に分類しておきます。また、これらの対策を実施することによって、開発現場がどのような状態になるのかを考えましょう。
 
        R&D
図24.実施する対策の工数削減効果
 
 ・試作回数が1回削減(2Sまでで顧客認定完了)
 ・設計開始時には直前の試作評価は完了している
 ・顧客対応技術者はほとんど客先常駐で仕様打ち合わせを実施
 ・プロジェクト管理者は複数の開発を同時に見ている
 ・再利用モジュールや技術情報の検索ノウハウが共有されている
 ・差分開発により設計、評価が効率化している
 ・製造からの指摘(製造性不具合)は大幅に減っている
 ・他モデル開発も含めて柔軟かつ混乱の少ないメンバーアサインが実施されている
 ・設計部門全体の開発状況をリアルタイムに把握している
 ・品質保証部門の管理下で改善活動が継続的に実施されている
 
 この段階で、考えた対策に適した使い方ができるかどうかの観点で、ツールやシステム、手法や技法などを特定します。「評価工数が大幅削減」「充実したプロジェクト管理機能」などのキーワードで判断したり、提供している機能や仕組みの豊富さで判断するものではないことは、いうまでもないと思います。対策効果は、これも詳細は省略しますが、図25の左側のグラフに示すように開発効率をほぼ2倍にすることが可能だと試算できました。もし、この段階で開発効率2倍が未達であれば、別の対策を検討する必要があります。また、右側のグラフは試作から量産までの各段階の工数がどのように減るのかを示しています。これで目指すべき開発の姿が明確になっています。
 
       R&D
図25.開発工数削減の期待効果
 
 この段階では、システムや技法などが特定でき、対策実施のために必要となる費用も概略把握できます。場合によっては、予算との兼ね合いで対策の取捨選択を検討する必要も生じます。その場合は、対策ごとの工数削減効果と必要になる費用とのバランスで取捨選択することになります。そのためには、図24の詳細データが必要になりますが今回は省略します。
 
 以上で、開発効率2倍という頂上まで行くことができること、そして、頂上までの概略ルート(実施すべき対策セット)が明らかになりました。しかし、登山するにはまだ危険です。道に迷う危険性をもっと減らすために登山ルート(コース)はできる限り具体化する必要があります。食料や天候のことも考慮してスケジュール(時間軸)も具体化する必要があります。さらには、登山パーティを見直す必要もあるかもしれません。具体的には、対策実施の体制作りや上位マネジメントとの関係構築なども並行して実施する必要があります。
 
 このように、登山ルートを具体化するという最後の段階は、「政治的」なことが要求される段階です。スケジュールを作成するためには、部署間・マネジャー間の力関係、設計部門あるいは事業部としての中短期方針、上位マネジメントの説得、対策実施メンバーの確保などなど、政治的な様々なことを考慮し、実行に移すことが要求されます。
 
 政治的なことについては次回に解説します。詳細を省略した部分も多いと思いますが、今回までの話で、設計部門の仕組み構築の際の考え方ややるべきことはお伝えできたのではないかと思います。大切なのは、目標達成のための道は無数にあり、歩むべき道は自分たちの置かれた状況や条件で考えなくてはいけないため、自分たちが主体的にやらなくてはならないということです。製品の良し悪しを決めるのは大部分が設計であることと同様に、仕組み構築の良し悪しを決めるのも、進むべき道を決めるという「設計」作業なのです。
 
 次回は、「スケジュールの精度は政治的要因の検討で決まる」その1です。
 
 

   続きを読むには・・・


この記事の著者

石橋 良造

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

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


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

もっと見る
ロードマップの作り方

   別稿で解説した通り、ロードマップを作るに際して、技術ベースで考えるか(フォーキャスト型)、市場要求からの逆算型(バックキャスト型)で...

   別稿で解説した通り、ロードマップを作るに際して、技術ベースで考えるか(フォーキャスト型)、市場要求からの逆算型(バックキャスト型)で...


大学との連携の形態を考える、産学連携のあり方

 産学連携の例として、企業が製品開発において大学の技術を活用しようとした場合、どういった提携をするのが一般的なのかを解説します。通常、大学との連携の形態は...

 産学連携の例として、企業が製品開発において大学の技術を活用しようとした場合、どういった提携をするのが一般的なのかを解説します。通常、大学との連携の形態は...


製品設計における納入仕様書の役割(その1)

1.製品の納入側から受入側へ提出する「文書」とは  製品設計では、顧客や協力会社、自社内の部署間において、様々な「文書」を取り交わす必要があります。...

1.製品の納入側から受入側へ提出する「文書」とは  製品設計では、顧客や協力会社、自社内の部署間において、様々な「文書」を取り交わす必要があります。...


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

もっと見る
‐市場の観察から開発テ-マを得る‐  製品・技術開発力強化策の事例(その6)

 前回の事例その5に続いて解説します。新技術が社会に普及し始めると、それに関連した新商品を顧客の要求に即応して供給出来ないで、新技術搭載製品の供給不足が起...

 前回の事例その5に続いて解説します。新技術が社会に普及し始めると、それに関連した新商品を顧客の要求に即応して供給出来ないで、新技術搭載製品の供給不足が起...


QFD-TRIZを活用した革新的製品開発への挑戦

♦ 限られた人員、予算で効率的にヒット製品を 1. QFD-TRIZ導入の背景  今回は創業当初から電磁バルブなどの「機器事業」と、198...

♦ 限られた人員、予算で効率的にヒット製品を 1. QFD-TRIZ導入の背景  今回は創業当初から電磁バルブなどの「機器事業」と、198...


進捗管理可能なソフト開発計画 プロジェクト管理の仕組み (その6)

 前回のその5:ソフト開発計画の作成方法に続いて解説します。    製品機能に対するソフトウェアの各モジュールが実装すべき処理(内部機能)が...

 前回のその5:ソフト開発計画の作成方法に続いて解説します。    製品機能に対するソフトウェアの各モジュールが実装すべき処理(内部機能)が...