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

更新日

投稿日

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

 前回のその1に続いて解説します。システムやツールの導入を伴う設計部門の仕組み改革について、事例を使って解説します。仕組み構築を計画している場合、ゴール設定はできているはずですから、現在地点の確認と頂上までのルート設定を中心に考えましょう。ゴールは開発効率2倍と仮定します。
 
 開発効率2倍をゴールとしているわけですから、まず現在の開発効率を把握する必要があります。繰り返しになりますが、最初にシステムやツールを選ぶ、もしくは他社事例で判断するという姿勢では、そこに目標達成のためのロジックは存在せず、開発効率2倍というのは単なる努力目標でしかありません。ゴール目指してがんばって、期限にできた結果がゴールになるという「できた成り」の開発と同じです。ゴール設定に加えて、現在位置の把握とゴールまでのルート設定を行うことが、目標達成のロジックを持つということにつながります。現在の開発効率を把握するための最初のステップは、典型的な製品開発における工数の使い方を可視化することでしょう。図20は、ある設計部門での典型的な製品開発プロジェクトにおける工数の使い方です。
 
                R&D
                    図20.製品開発における開発工程ごとの工数推移
 
 少し製品開発の背景を説明しておきます。この製品は最初にモックアップレベルの試作機を製作してこれにより受注が確定します。その後、顧客サイドで評価や進捗確認を行うために、ほぼ3ヶ月ごとにサンプル製品を顧客に渡す必要があります。この例では3回のサンプル出荷を行っています。サンプルの評価結果を確認しながら社内では量産準備に入り、最終認定のためにプリプロ機を顧客に渡します。スケジュールとしてはこのような流れになりますが、実際の工数の使い方は図20に示すスケジュールのように段階的に進んでいるわけではありません。
 
 図20を見てまず気づくのは、設計者の本来業務である設計作業、試作のための部品手配や製作依頼、評価環境準備などの試作関連作業、そして、品質や完成度を確認するための評価作業が、開発期間を通じて常に並行して行われているということです。これに加えて開発後半になると、製造のための各種指示や図面作成(支援)、トラブル対応などの工場関連作業が並行作業として加わります。さらに、リーダークラスの技術者は、並行作業にプロジェクト管理や顧客対応作業も加わります。
 
 このような並行作業状態になっている主な原因は次のようなことが起きているからです。1S の設計完成度が低いために評価が長引いてしまい、1S の評価が完了しないまま 2S の設計を開始せざるをえない。そして、1S の評価で見つかった不具合は 2S に反映させることができなくなり、3S で反映させることになる。さらに、3S の設計中にはやはり 2S の評価をやっている最中である。このような状況でサンプルの完成度が低くなり、顧客からのクレームや仕様変更要求が増えてしまい、設計変更や試作依頼の調整作業が長引いている。このような状況になっているのです。
 
 実際は現状調査と分析をさらに進める必要がありますが、この時点でも、例えば、電気設計と機構設計のツール間の連携、設計ナレッジの共有データベース、テスターによる評価時間短縮といったツールやシステム主導のソリューションでは十分とはいえないでしょう。もちろん、図20 を見てもわかるように、設計や評価作業の工数は大きなものですから、これらのツールやシステムが役立つことは間違いありません。しかし、開発効率2倍というゴールまでの『最適ルート』になっているかどうかの検証が必要なのです。
 
 現状がこのように把握できれば、ゴール達成のためにどのようなルートを設定しなければならないのかを考えることができるようになります。いろいろなことが考えられると思いますが、た...

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

 前回のその1に続いて解説します。システムやツールの導入を伴う設計部門の仕組み改革について、事例を使って解説します。仕組み構築を計画している場合、ゴール設定はできているはずですから、現在地点の確認と頂上までのルート設定を中心に考えましょう。ゴールは開発効率2倍と仮定します。
 
 開発効率2倍をゴールとしているわけですから、まず現在の開発効率を把握する必要があります。繰り返しになりますが、最初にシステムやツールを選ぶ、もしくは他社事例で判断するという姿勢では、そこに目標達成のためのロジックは存在せず、開発効率2倍というのは単なる努力目標でしかありません。ゴール目指してがんばって、期限にできた結果がゴールになるという「できた成り」の開発と同じです。ゴール設定に加えて、現在位置の把握とゴールまでのルート設定を行うことが、目標達成のロジックを持つということにつながります。現在の開発効率を把握するための最初のステップは、典型的な製品開発における工数の使い方を可視化することでしょう。図20は、ある設計部門での典型的な製品開発プロジェクトにおける工数の使い方です。
 
                R&D
                    図20.製品開発における開発工程ごとの工数推移
 
 少し製品開発の背景を説明しておきます。この製品は最初にモックアップレベルの試作機を製作してこれにより受注が確定します。その後、顧客サイドで評価や進捗確認を行うために、ほぼ3ヶ月ごとにサンプル製品を顧客に渡す必要があります。この例では3回のサンプル出荷を行っています。サンプルの評価結果を確認しながら社内では量産準備に入り、最終認定のためにプリプロ機を顧客に渡します。スケジュールとしてはこのような流れになりますが、実際の工数の使い方は図20に示すスケジュールのように段階的に進んでいるわけではありません。
 
 図20を見てまず気づくのは、設計者の本来業務である設計作業、試作のための部品手配や製作依頼、評価環境準備などの試作関連作業、そして、品質や完成度を確認するための評価作業が、開発期間を通じて常に並行して行われているということです。これに加えて開発後半になると、製造のための各種指示や図面作成(支援)、トラブル対応などの工場関連作業が並行作業として加わります。さらに、リーダークラスの技術者は、並行作業にプロジェクト管理や顧客対応作業も加わります。
 
 このような並行作業状態になっている主な原因は次のようなことが起きているからです。1S の設計完成度が低いために評価が長引いてしまい、1S の評価が完了しないまま 2S の設計を開始せざるをえない。そして、1S の評価で見つかった不具合は 2S に反映させることができなくなり、3S で反映させることになる。さらに、3S の設計中にはやはり 2S の評価をやっている最中である。このような状況でサンプルの完成度が低くなり、顧客からのクレームや仕様変更要求が増えてしまい、設計変更や試作依頼の調整作業が長引いている。このような状況になっているのです。
 
 実際は現状調査と分析をさらに進める必要がありますが、この時点でも、例えば、電気設計と機構設計のツール間の連携、設計ナレッジの共有データベース、テスターによる評価時間短縮といったツールやシステム主導のソリューションでは十分とはいえないでしょう。もちろん、図20 を見てもわかるように、設計や評価作業の工数は大きなものですから、これらのツールやシステムが役立つことは間違いありません。しかし、開発効率2倍というゴールまでの『最適ルート』になっているかどうかの検証が必要なのです。
 
 現状がこのように把握できれば、ゴール達成のためにどのようなルートを設定しなければならないのかを考えることができるようになります。いろいろなことが考えられると思いますが、たとえば、以下のようなものです。
 
・設計目標設定の仕組みとそれに合わせた設計進捗の可視化試作におけるフィードバックの即時伝達やそ
 の設計ルール化
・評価容易化設計のツール化
・開発状況把握とサンプル日程調整のための手法導入
・メンバーのスキルと負荷状況を把握する進捗管理の仕組み化
 
 それぞれの詳細については説明しませんが、いずれにしても、ここで考えたものがゴール達成のためのルート候補となります。次回は、仕組み構築は山登りをテーマに解説を進めます。
 
 

   続きを読むには・・・


この記事の著者

石橋 良造

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

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


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

もっと見る
ものづくり、表と裏の競争力とは

1.ものづくりとは  「ものづくり」とは何か、いろいろな定義が示されていると思われます。筆者は、「もの」と「つくり」を分けて考えることを提唱しています。...

1.ものづくりとは  「ものづくり」とは何か、いろいろな定義が示されていると思われます。筆者は、「もの」と「つくり」を分けて考えることを提唱しています。...


開発生産性向上施策 開発生産性向上(その3)

【開発生産性向上 連載目次】 1. 生産性向上の必要性 2. ビジネスの質的変化への対応 3. 開発生産性向上施策 4. 改善活動のポイント ...

【開発生産性向上 連載目次】 1. 生産性向上の必要性 2. ビジネスの質的変化への対応 3. 開発生産性向上施策 4. 改善活動のポイント ...


1400件の顧客特許を読んだらどうなるか~技術企業の高収益化:実践的な技術戦略の立て方(その17)

【目次】 今回は、ある技術者の変身のお話です。半年前まで営業の下請け的に開発するのが仕事だと思っていた技術者が、顧客の潜在ニーズを先...

【目次】 今回は、ある技術者の変身のお話です。半年前まで営業の下請け的に開発するのが仕事だと思っていた技術者が、顧客の潜在ニーズを先...


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

もっと見る
技術資源の有効活用: 事例紹介 (その1)

 今回から2回に分けて、TRMによる活動の事例紹介をいたします。TRM(Technical Resource Management)は自社が保有する潜在的...

 今回から2回に分けて、TRMによる活動の事例紹介をいたします。TRM(Technical Resource Management)は自社が保有する潜在的...


基本の仕組みを進化・深化させるとは プロジェクト管理の仕組み (その1)

 前回は、リスク管理が重要であることと、その反面、リスク管理の仕組みを運用しているところでもリスク管理シートを書いているだけという、表面的な仕組みになって...

 前回は、リスク管理が重要であることと、その反面、リスク管理の仕組みを運用しているところでもリスク管理シートを書いているだけという、表面的な仕組みになって...


開発者が意識したい1日のスケジューリング(午後~夜編)

  前回の記事では一日の業務を有意義なものにするため、就業前の朝の時間と午前中の脳がフレッシュなうちにアイデア創出やメンバーとのコミュニケ...

  前回の記事では一日の業務を有意義なものにするため、就業前の朝の時間と午前中の脳がフレッシュなうちにアイデア創出やメンバーとのコミュニケ...