設計部門の仕組み改革(その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. 国際財務報告基準とは    国際財務報告基準(International Financial Reporting Standards)...

1. 国際財務報告基準とは    国際財務報告基準(International Financial Reporting Standards)...


設計部門の課題と原因分析(その1)

【設計部門の課題と原因分析 連載目次】 1. 設計部門の現状を正確に特定する 2. 課題分析と課題の根本原因除去 3. 設計部門用に用意したコン...

【設計部門の課題と原因分析 連載目次】 1. 設計部門の現状を正確に特定する 2. 課題分析と課題の根本原因除去 3. 設計部門用に用意したコン...


マトリクス体制での品質保証2 プロジェクト管理の仕組み (その31)

 前回のマトリクス体制での品質保証1に続いて解説します。品質計画は、製品開発に必要となる手順やリソースが誰によっていつ適用されるかを明確にした個別製品の開...

 前回のマトリクス体制での品質保証1に続いて解説します。品質計画は、製品開発に必要となる手順やリソースが誰によっていつ適用されるかを明確にした個別製品の開...