MMRCDISCUSSION PAPER SERIES

No. 315

統合型ものづくり IT システム事例シリーズ（4）―設計マネジメントに関する事例―
株式会社
渡辺

D社

和幸

東京大学ものづくり経営研究センター
朴英元

東京大学ものづくり経営研究センター
阿部武志

2010 年 7 月

東京大学ものづくり経営研究センター
Manufacturing Management Research Center (MMRC)
ディスカッション･ペーパー･シリーズは未定稿を議論を目的として公開しているものである。
引用・複写の際には著者の了解を得られたい。
http://merc.e.u-tokyo.ac.jp/mmrc/dp/index.html

Integrated Manufacturing Information System Case Series (4):The Case of Design Engineering Management

Watanabe, Kazuyuki
Company D
Park, YoungWon
Abe, Takeshi
The University of Tokyo

Abstract

To make clear the IT system which fits Japan, Integrated Manufacturing Information
System (IMIS) study group began which is based in the University of Tokyo. In thisstudy group, we discussed the concrete solution for realization of IMIS in the 21st
century.
This paper presents a concrete case study on IMIS as one of the results of this study
group. This article is a case study of the audio system design engineering managementof D company. Through this case analysis, we find that the design engineering
management as well as design engineering task is an important issue that IT system are
expected to support.
Keywords

Integrated Manufacturing Information System (IMIS), audio design engineering, design
management, design field統合型ものづくり IT システム事例シリーズ（４）-設計マネジメントに関する事例-

株式会社 D社
渡辺 和幸
東京大学ものづくり経営研究センター
朴 英元
阿部 武志

概要
日本に合ったものづくりITシステムを明確にする狙いから、東京大学をベースにして、統合型
ものづくりITシステム研究会が始まった。この研究会では、21世紀の統合型ものづくりの実現のための具体的な解決策を提示することを目指している。
本稿はこの研究会の成果として統合型ものづくりITシステムの具体的な事例としての意味をもつ。本稿の事例は、D社のオーディオ設計マネジメントに関する内容である。本稿では、設計現場がITに求めることは、設計作業だけでなく、マネジメントも重要な支援対象であることとそれを管理する仕組みが必要であることを示した。

キーワード

統合型ものづくり IT システム、オーディオ設計、設計マネジメント、設計現場

1

1.

はじめに

本稿は D 社のオーディオ設計マネジメントの事例である。著者は設計現場の経験が長く、現在は設計マネージャをしている。今回は、設計現場で使用している CAD の話
しではなく、日頃、設計マネージャとして設計現場で試行している内容（どうやったら設計改革が出来るか？など）について説明する。
設計現場に IT を導入する場合、社長などトップに対して起案（プレゼンテーション）を行うのだが、経営者は忙しくて通常 5～10 分くらいしか時間がもらえないので、中々詳細を伝えることができない。本稿では普段は説明出来ない設計現場の IT の現状（CAD、PDM、ERP、SCM など）の中でも、PDM や PLM にフォーカスをあてて説明している。設計現場が IT に求めることは、設計作業だけでなく、マネジメントも重要な支援対象である。また、BOM（設計 BOM）によるコンテンツ（データ、図面など）構
造化よりも、仕様や設計ルールがアップデートされる仕組みが必要である。
本稿は口頭での質疑から起稿したものだが、近年は以前ほどオーディオ製品に接する人が減ったためか、製品や市場に関する質疑が比較的多かった。論旨から外れる部分もあるが、一般的な関心事に答える機会も少ないので、多くをそのまま残した。
著者が内容の校正作業をしている間にリーマンショックが起きて、組織の大幅な改変が行われた。これによりシステムを新たに一から構築し直すことになってしまい、
ここに紹介している方法は現在中断している。新たに構想中のシステムも基本は変わらないが、さらにシンプルなものを目指している。様々な事を試した結果、最も使い勝手が簡単なものしか定着しなかったためである。ツールは空気のように何も考えずに使えるものでなくてはならない。誰もが使い慣れている Excel を採用したという、
ブリヂストン社の FOA のアイデアには本当に感心した。

2.

事例紹介

2.1

製品の概要

同社の製品はオーディオ製品であり、製品アーキテクチャはオープンインテグラル型（音技術のすり合わせ設計）に近い。主力製品のライフサイクルは、２年くらいであり、短いほうである。生産台数は、年間数十万台であり、数量は多くないビジネスで
ある。
2.2

事例内容
2

2.2.1

ケース企業の背景と概要

設計現場で使う目的で PDM システムを導入したが、出来あいの PDM システムのままでは中々使えない（使いこなせていない）。設計現場が抱えている問題を解決すべく高価な PDM を導入した。しかし、システムを導入する過程で、(1)ファイルサーバーでデータ管理していたため共有すべきデータが整理出来ていない(2)設計担当者のレベル（スキル）が異なるので、設計の（成果物の）出来がバラバラ(3)QCD を確保するための設計ルールがない(4)スケジュール通りに設計が出来ないなど新たに別の問題を露見した。
購入した時点では、PDM システムそのものが良くわかっていなかったのである。実際に、PDM システムを触って、管理して初めて PDM システムで何が出来るかがわかった。一般的に、どこのベンダーの製品でも、ほぼ同じことができるが、現在使用している機能は次のようなものだけである。
(1)ファイル管理：バージョン管理機能にて常に新しいデータを共有(2)ルールの標準化/トレーサブル：ワークフローに設計ルールを組込み、電子承認などの機能を使って仕事をさせる(3)進捗管理：仕事のタスク（WBS）を作成し MS プロジェクトにて編集／レポート(4)BOM：製品の部品管理(5)検索エンジン：検索属性による検索

主力の商品は我々が設計している商品は D 社ブランドのオーディオ製品（AV アンプなど）で、同社の売上げの 50%をしめている。また、D 社ブランド製品の中で AV アンプは売上げの 50%をしめている。AV アンプはホームシアター用のアンプで、家の中で映画を見るために使用されていて、音声出力（スピーカー出力）が 5.1 チャンネル用意されている（フロント；3 チャンネル、両サイド 2 チャンネル、スーパーウーハー；1 チャンネル）。
10.1 チャンネルの AV アンプ
現在、ハイエンド（高機能）の AV アンプは出力（スピーカー）が 10.1 チャンネル対応となっている。10.1 チャンネル対応のコンテンツソース（音データ）を作るのは簡単には出来ないが、10.1 チャンネル対応の AV アンプを作るのはそんなに難しくない。10.1 チャンネルなどという AV アンプの仕様が出てくるのは次のような背景があ3る。すなわち、映画会社（コンテンツソース製作会社）は、コンテンツ（映画コンテンツ）を売るため、より臨場感のある（映画館に近い）ものを作りたいが、コンテンツ側だけではそれは出来ないので、（Dolby のような）規格を作る会社とハードウェ
アを作る会社と組まないと実現が出来ない。そのため、コンテンツ企画前に、D 社のようなオーディオメーカと一緒になって、規格作りを行う。このため、2008 年は 9.1
チャンネルに対応し、2009 年は 10.1 チャンネル対応と年々エスカレートしてくる（ハード企業とソフト企業のすり合わせによって）。なお、このハード企業とソフト企業のコラボは D 社だけではなく、競合会社（ヤマハやパイオニアなど）も参加している（業界が一体となっている）。
他の商品としてはブルーレイや DVD などのプレーヤー、プリメインアンプ／チュー
ナーなどがある。中には高額な商品も存在する（D 社ブランド製品の例）。ユニバー
サルブルーレイディスクプレーヤーは、定価 50 万円であり、プリメインアンプは、80 万円である。一般的には、価格が 80 万円プリメインアンプは大変高額に思えるが、競合他社の同じグレード（仕様）のプリメインアンプは 130 万超える価格設定である。
それと比較すると（性能面で）かなりコストパフォーマンスが良いものを作っていると自負している。一方、D 社は、こうした高級オーディオの他にも同じジャンルの高級オーディオやカーオーディオなどを主力製品とする８つのブランドから形成されて
いる。

2.2.2

設計現場の問題取組み

オーディオ製品の技術と設計者
高級オーディオ製品（例えば、80 万円の AV アンプや 50 万円のブルーレイプレー
ヤー）を設計しているような職場は、外部の人からは楽しい職場のようによく言われるが、実際はそうおだやかでない。開発スケジュールが予定期間をオーバーするなか、多くの場合、設計者の力技で乗り切っているのが実態である。
スケジュールの展開（計画、実行、検証など）をどのようにしたらよいかは、常に課題の上位に挙がっている。オーディオ製品の多くは、常に新たな技術を投入するといった製品ではなくて、約 90%は流用設計できる成熟した製品なので、本来プロセスを効率化するのには向いているはずである。
我々が生産するオーディオ製品は、量産を前提とした普通の工業製品であり、基本
技術はデジタル家電のような電子機器と何ら変わらない。設計者は純然たる電子機器としてのパフォーマンスの追求と安全性の確保、各国のコンプライアンス対応に殆ど
4

の時間を割いている。オーディオの設計とは、これらの基礎的な技術力が無くては成立しない。
オーディオ設計の特徴
アマチュアやマニアがイメージしているものとは少し次元が異なるが、オーディオ製
品独自の設計について簡単に説明する。
オーディオ製品の設計に求められる性能をかなり大雑把にまとめると、･音声信号にノイズを乗せない･ごく微少な情報（音）もノイズに埋もれさせずに再生する
この単純なことを実現するために、設計者は普通の電子機器では問題にされないような、信号の経路の作り方に細心の注意と相当な執着を求められる。
設計者がこれらオーディオ機器独特の設計スキルを身につけるには、忍耐力が要求される。アナログ回路の設計法は特に大切である。また、開発・設計のほとんどが自動化出来ないので、設計者への負荷は大きい。この仕事を『趣味』や『生きがい』にしないとやっていけない。
回路技術には大きな進歩は無いが、現在の製品と 10 年前の製品を比較すると、確
実に音は変わっており、良くなっているといえるだろう。どんな些細なことでも、あきらめずに工夫を重ねれば成果が出るものである。
オーディオ製品の市場
オーディオの市場ニーズにおいては、一歩先を見た品ぞろえをするのではなく、半歩先を見た品ぞろえが必要となると言われている。このことは、オーディオの市場においてもビジネス戦略的な切り替えしないと生き残ることは困難であることを示しており、多くの企業が事業を縮小したり撤退したりして無くなっていった。
D 社の製品の中では、中高価格帯のホームシアター製品（ハイエンド製品は価格約70 万円）の売れ行きが良く、利益を生み出している。マーケットはアメリカ市場がメインターゲットである。

国によって聴こえる音が違う？
日本とヨーロッパでは、2 チャンネルオーディオは今でもメイン商品となっている。
アメリカ（アメリカ人）は、日本人と比べて音の好みが異なる。高い周波数の音を聞き取る能力は高いが、反面低域がもの足り無く聞こえるらしく、低域側を持ち上げて使うユーザが多い。その背景には言語の影響があると言われている。英語圏の人は高い周波数の音を聞き分けられる。アメリカ人に比べ、ヨーロッパ（ヨーロッパ人）の5

音の好みの傾向は日本人と近い。生音に近い音を好む傾向がある。ヨーロッパ向けのスピーカは能率があまり良くない柔らかい音の製品が多い。彼らは残響の多い家に住んでいる場合が多いので、日本のスピーカは合わない。音楽ソースに録音されている
残響の音が、原音再生に忠実な日本のスピーカだと、きつい音に聞こえてしまうと言われている。

開発要素が多い案件としては、ディスク系（DVD や BD など再生メディアの進歩に対応するための開発）やネットワーク系（アメリカではラジオがデジタル化されネッ
トワークラジオが主流になっている）がある。米国市場に対応した製品開発には欠かかせない技術である。アメリカは億万長者が何万人もいるが、彼らは自分で直接オー
ディオ製品を選んで購入するのではなく、設備工事業者に任せている。業者はオーナーの要求に合わせて、ホームシアターなど家電設備全体を制御するシステムを作って提供する。一例を挙げれば、夕方、自動でカーテンが閉まるとオーディオ設備からお気に入りの曲が流れるといった具合で、オーディオを日常生活に組み込む仕事をしている。
また、アメリカ人には映画マニアが多く、自宅に映画館とほぼ同じ環境を実現した
いというリクエストが多いらしい。

オーディオ製品における技術のトレンド
ネットワーク系の開発として、大げさに言えばソフト開発量は以前より（10 年前より）100 倍増えている。プレーヤー系もアナログ→CD→DVD→ブルーレイとメディ
アが進化するにつれて、ソフト開発の量は爆発的に増加している。
BD プレーヤーを開発したとき、プラットフォームである組込みシステムの言語がJava に変わるなどで、非常に大きな負荷がかかった。再生媒体が替わるたびに、ソフト開発の負荷も増え続けてきていることも問題である。製品全体において、ハード（メカ設計、エレキ設計）の占める割合は 20-30%、ソフト（ソフト開発）の占める割合は 70%となっている。
従来 AV アンプは音の増幅機能がメインであったが、現在は映像がメインなのでDVD の映像処理（きれいな映像を再生する）など多くの機能を搭載しなければいけなくなった。単なるセレクター付きアンプからマルチメディア対応型アンプに変わった。
それに対応できるか出来ないかが生き残る重要なポイントとなっている。
80 万円のプリメインアンプの製品ライフサイクルは 2 年で、生産台数は初期ロッ6

ト 2000 台（国内生産）で半年に１回くらい生産（補充）する。高価格帯のオーディ
オ製品であっても、最近は量販店（ヨドバシカメラなど）の店頭に製品を品ぞろえする必要がある。それは、近年オーディオ専門店などで、他メーカーと音を聴き比べてから量販店で安く購入するお客様が多いためである。
全国の量販店の店頭（棚）を埋めるには、合計すると延べ 1000 台くらいは必要になる。したがって、初期生産台数 2000 台は、決して多くない。また、生産規模が 50～100 台くらいに合わせた生産システムでは、量産製品として価格と品質を両立させることが出来ないので、最低限のロット数量と言えるかもしれない。

2.2.3

設計現場の特長製品としては、昔から世の中にあるものを作り続けているので、設計では、同じような回路をベースにアイデアや思想をいかに入れ込むことが出来るかが重要となってくる。音はアナログであり、パラメータが多く複雑なため、パラメータを絞った設計が困難である。特に付帯音（ふたいおん：スピーカから聞こえてくる音にはソースに記録されている音の他に、装置が発生する微少振動に起因する音が加わっている）をいかにコントロールするかが重要な課題である。このことは、いかにノイズをコントロールできるかにかかっているのだが、デジタルアンプの登場により、従来より付帯音の少ない音が聴けるようになった。
（ただし、これは研究開発レベルのアンプのことで、実は市販の「デジタルアンプ」と呼ばれている製品の多くは、名前は同じでも性能は全く異なる）
デジタルアンプの音は、ユーザが聴きたい音とは違うかもしれないが、記録されている原音との差が判るようになったということは大きい。これで本物の音に近づける可能性が広がった。デジタルをベースにし、ノイズ制御などデジタルの良い技術を使って（デジタルを道具として）、アナログを制御（音の質をコントロール）できるよ
うになってきた。

高価な製品の基板は自社で製造しているが、それ以外は韓国の ODM ベンダーに出している。これらのベンダーとは昔から長くつきあっている。新しい ODM ベンダーにすり合わせが必要な基板を発注すると、打合せや修正で時間を費やすので効率がわるい
ため、どうしても長い付き合いになってしまう。パターンの幅や長さ、ワイヤの種類で音が変わってしまうため、アンプの基板レイアウト設計者（Amp 設計者）などは、最初から出る音をイメージして基板レイアウトの設計を行う。
7

こういうノウハウは韓国の設計者にも少しづつ伝わっているらしく、最近は最初からある程度のレベルの（音質を考慮した）設計をしてくれるようになってきた。
ODM ベンダーは競合他社にも製品を供給しているので、敵に塩を送っている感じもする。我々にとってはそこからがスタートラインだが、普通の AV 機器としては、そのままでも十分な性能だからである。
具体的には、オーディオ設計では、グランド（＋電源と－電源の中間点で、信号の入力と出力の基準点）のレイアウト設計が重要となっている。設計の初期段階にグランドのレイアウトを決める。また、不要輻射を抑制するためにアース廻りや電源廻りについては、念入りに DR(デザインレビュー)を行っている。こういった設計内容を盛り込み、韓国の ODM ベンダーに仕事を依頼する。
基板設計（回路設計～レイアウト設計）の 90%が類似設計となっているが、設計内
容は、基板のパターンなどアナログに関する設計が主流なので、標準化（プラットフ
ォーム化）することが困難な状況となっている。逆に、標準化（プラットフォーム
化）することが困難な領域で、他社（海外企業）と勝負しているので、設計は大変だ
が、利益を上げることができている。
これは、日本のものづくりにとって必要なことである。90%が類似設計であっても、設計業務が類似しているのか、技術が類似しているかで設計標準の取組みが異なってくる。たとえば、東芝の場合、設計者に標準化のことを話す時、標準化するターゲッ
トが部品および業務（プロセス）なのか？それとも技術なのか？によって反応がことなる。部品やプロセスは標準化することが出来るが、技術（ノウハウ、ナレッジ）の標準化は困難である。技術（ノウハウ、ナレッジ）を体系的（回路、レイアウトなど）にまとめることが出来るが、それらを活用するときすり合わせが必要になる。ア
イデアや思想がないと技術（ノウハウ、ナレッジ）は使い物にならない。技術（ノウハウ、ナレッジ）をまとめる方法として、製品にひも付けするのではなく、機能単位にひも付けするようにしている。そのことで、ハード設計とソフト設計の整合がとれるようになった。
設計者が音決めの設計に向いているかどうかがわかるのには時間がかかる。そのため、音を決める設計者を育てるのに 2 年以上かかる。どんな設計でもへこたれずに、
なおかつ困難なすり合わせ設計が行える設計者は貴重な存在である。D 社において、80 万円レベルのハイエンド製品の音作りは現在 3 名で行っている。設計者（音決め専門家）は、設計者でありながら、音が趣味で、技術が好きだから、音（アナログ）に関する解に到達することができる。
8

2.2.4

設計現場の課題

ハード／ソフト設計と機能 BOM の導入
ソフト開発のマネジメントをどのようにしたらよいか？（どうすべきか？）悩んでいる。ソフト開発を構成で管理（CSM）する場合、品質をつくりこむために、必要なドキュメント作成やモジュールのつなぎ部分の設計に多くの工数（コスト）がかかる。
リソースを投入しても製品コストとバランスしない。また、現在それらをルール化することが困難である。その理由は、文書化されない仕様が多くあるため、抜けや漏れを発生させてしまうからである。
また、ソフト設計は仕様が決まっていないと進めないが、ハード設計は現物が在った方が評価し易いので、どんどんすすんでいく。このために、どんなスピードで開発を進めていくべきかという『感覚』を開発チーム内で共有できない。
仕様で構成された BOM（機能 BOM）で設計情報を管理しないと、ソフトとハードの整合をとることができない。これは、機能単位にソフトとハードの最新の仕様を管理して、お互いの進み具合（変更具合）を確認しながら製品開発をすすめるという方法である。最近、EBOM（設計 BOM）で設計情報を管理するのではなく、仕様 BOM で設計情報を管理することが重要であるという企業が増えている。
多くの PDM で使われている EBOM＝Engineering BOM というと名前は良いが、これを最初に作った時点では、必要な情報が不足しているため、すり合わせ設計を行うことが出来ない。メンテが可能な段階では、既に設計作業がかなり進んでしまっていて、手遅れになっている。毎回一から仕様を書き出す方法は、過去の製品で作った仕様書に手を加えた程度の、ページ数は多いが内容は薄い、誰も読みたくない分厚いコピーを作り出す。設計にとっては機能 BOM が命なのに、今の PDM からは誰も機能や仕様をキーにハードとソフトの最新情報を取り出すことができない。
自動車などのように、生産台数が多く、高価な製品で、流用設計（差分開発）が主流となっている製品では、ソフトを構成で管理してもペイする（コストに似合う効果がみこめる）。構成で管理するとは、仕様を全てドキュメント化してから、開発に着手するという意味である。オーディオ製品は 90%の技術が類似設計なので機能 BOM を導入することは問題ないのだが、構成で管理する方法は、コスト上ぺイしない可能性がある。
仕様のドキュメント化の替りの手法として、仕様（機能）BOM を捉えている。仕様
BOM を導入しても、ソフトウェアを構成管理するために必要な情報を揃えることはできないが、製品特有の仕様と暗黙知の仕様とが分離してしまう状況からは卒業できる。
9

開発を進めながらリアルタイムにソフトの担当とハードの担当がそれぞれ、仕様の不足部分を書き込んでいけるようにした。これを GoogleApps をベースにした社内イン
フラのサイト上で実現した。大げさなことを説明したが、実際の機能はきわめて単純で、複数の人間が同時に web ページに書き込めるようになっているにすぎない。
GoogleApps はシンプルで良く出来ている。アクセス権の設定が簡単にできる上、ユーザが書き込むと自動保存される。はやりの iPhone などの SmartPhone があれば、どこからでも思いついた時に書き込める。低コスト（１ユーザ当たり 6000 円／年、しかも Gmail など全てのサービス込みの価格）で実現出来る。また、使い慣れた
Google の検索機能が使えるメリットも大きい。

実はそれぞれの仕様には、実現できたかどうかの判定をするための基準が必要である。これは PMBOK でいうところの WBS 辞書に当たる。この基準が明確になっていて、進捗管理に取り込まれるようになると、設計品質の実現状況がトレース出来る。この情報を「見える化」することが、次のステップの目標テーマである。

マネジメントが抱える問題
現在、設計部において一番重要な課題はマネジメントである。今のマネジメントは、
設計グループ内の面倒をみるとか、組織管理的なマネジントが主体となっており、本来やるべき「技術マネジメント」を行っていない。いろいろな場面（設計 DR など）
で課題に対し素早い判断を下さなくては、技術の進歩についていけない。
昔は、設計者（ベテラン設計者）が過去の失敗や生い立ちなどを良く知ったうえで設計を行っていたので、そんなに組織管理的なマネジメントは必要ではなかった。今は、オーディオのなんたるかを知らない設計者が作成したスケジュールを、スケジュール法など勉強したことも無い、マネージャが管理するために多大に無駄な時間を費やしている。
マネージャから、IT を使って設計者（若手設計者）の日常の仕事の進め方（進捗状況など）をマネジメントしたいとの要望があった。若い設計者は、誰からも訓練されていないので、スケジュールを計画する習慣もノウハウも持っていない。例えば、
1 週間で何らかのタスクを達成しようとした時、決められたマイルストーンを自分のカレンダーに書き込むだけで、どのように必要な仕様を達成するかをイメージした（段取りを考えた）スケジュールになっていない。
したがって、同じことをやらせても、設計者によって成果はマチマチである。
10

悪いことに、マネージャも若手設計者と同じ感覚（カンと経験）でマネジメントしている。例えば、ある設計上の問題を解決するという仕事に対して、必要な手順がある
程度理解されていないと進めないはずと判っていても、安易に仕事を任せてしまう。
実現したい仕様とタスクとのつながり（タスク間の関係）を明確にしないまま仕事をスタートさせてしまうため、任された設計担当者もどんな手順でアプローチしたら良いかをイメージ出来ない。このようなことが度々繰り返されているうちに、数手先まで読みながら設計する設計者がいなくなった。

ユーザ側の変化に対応したい設計を行う中で、顧客ニーズの追加や競合他社差別化などの要因で、仕様変更（追加）がバンバン発生する。インターネットと接続できるようになって、ユーザの人種が変わったのと同時に使い方が変わってきた（ラジオをインターネットで聞くようになった）。昔はオーディオ機器の世界だけを考慮した設計を行っていたが、今は普通の生活スタイルや裕福層の使い方（価値）を考慮した設計を行わないといけない。最新のデジタル家電やインターネットなどを通じて、そういった設計に必要な情報を毎日入手しないといけないのに、誰も出来ていないのが問題である。オーディオの使い方（録音する、聞く）は変わらないのだが、その手順や手法（リモコンのボタンや操作）が変わって来ている。「iPod」が標準化しているので、それと接続出来なくてはいけないし、使い勝手も考慮しなくてはならない。仕様が設計者の手に届かないとこ
ろで決められるので、常にアンテナを高くしないといけない。
昨年 D 社では、設計を詳細なタスクに落とし、標準となる WBS を作成した。しかしながら標準の WBS はスケジュール上に作業（タスク）を展開するだけなので、行ったり来たりする作業が発生したことによる影響（仕様変更により設計作業に手戻りが発生する）が見えない。作業を工程で管理する（PERT 工程管理）のほうが設計にあっている（ベテラン設計者の意見）。タスクの概念（スケジュール管理）ではすり合わ
せ設計を見える化することは難しい。

2.2.5

設計のマネジメントとツール

2.2.5.1

設計のマネジメントとは

マネジメントとは何をすることかをヒアリングした所、多くの人は人材育成などを挙げたが、設計活動においては、どういうことを、どういうスピード感で行うかをマネ
ージャは部下に伝えなくてはならない。昔は、部下の設計者達に何かが起きると誰か
11

があわてるので、その空気を読み取り設計がうまくいっているか判断していたが、今はそういったことが出来ない状態である。
さらに、これまでの半分の期間で設計を行った場合はどうなるか？などといった新たな課題が課せられたときもマネージャは同時に解決しないといけない。それらのインパクトを正確に把握するためには、フィードバックの仕組みが必要である。それは、
設計ナレッジや設計ゴールを活用・決めるために重要なキーとなる。この問題を解決するための手段として、行動分析（ある行動がどういった結果に連鎖するか？を分析する手法）のアプローチを採用した。
この考え方によると最終結果のみを評価しても次回も必ず同じ成果が得られる保証はなく、その結果をもたらした行動（連鎖行動）の管理が必要である。ただ単に結果を評価するのでは無く、その結果に結びついた行動を評価しないといけない。正確に目的を達成するタスクの手順を精査することや行動したことで設計者を評価するようにした。だが、このしくみにはいくつかの準備が必要である

2 つの情報の管理方法
従来のように設計者が計画したタスクに対してマネージャがうるさく DR を行っても良い結果を得るかどうかがわからない。確実に結果に結び付くピンポントの行動を評価し設計者をタイムリーに評価することの方が重要である。
成果（目的を達成）を出すために取った行動の履歴がナレッジとして構築できる仕組みが必要である。
システム上に、ある成果（目的を達成）を得るために行った行動と情報（データ）がセットになって管理されていないといけない。どんなシステムでもプロジェクトが進行している時は、設計者は記憶を頼りにして行動と情報がセットになったナレッジがどこにあるかを容易に探し出せる。だが、通常プロジェクトが終わると、そういったナレッジを探し出すのは困難となってしまう。設計者本人の頭の中に記憶されている分類情報を、時がたつと忘れてしまうためである。
ナレッジ管理を行うには、機能 BOM に製品仕様を達成させるためのプロセスのルー
ルや情報を成果として登録しておくことが必要である。単にデータを蓄積するのではなく、良い結果をもたらした行動やプロセスの情報が常にアップデートされないといけない。
ナレッジ管理では、製品開発が終わるまでは設計活動に適した使い易い形で行動やデータを管理し、製品開発が終わった時には、機能 BOM にその成果としての設計仕様
12

や行動ルール（プロセス）などが残っている（フィードバック）仕組みとしたい。
また、開発を行っている最中の検索スタイルと開発が終わった時の検索スタイルは異なってくる。開発途中では、その時点の状況で頭に残っている検索キーでナレッジが検索できるようにしないといけない（ディレクトリ検索）。仕事が終わったあとのナレッジ検索には、複数の検索キーが必要となる（タグ検索）。
自動車会社では、予め設計情報を検索するための論理だてを行い、それをタグとしてファイルやデータの登録や検索をおこなっている。
コンプライアンス情報などは、体系化した（論理化した）入れ物のみで対応できるが、設計で活用するノウハウ情報は、ただ単に登録情報だけでなく、登録した情報を仕様や作業手順にフィードバックした情報とセットでないと活用することはできない。
作業項目や仕事の手順／進め方の登録や登録した内容にコメントできる仕組みを構築している（日報システム）。日報情報（仕事の手順や進め方）やコメントをセットとして、ナレッジ管理している。
Outlook と Gmail（WEB2.0 の世界）良く知られている Outlook というメーラ（Microsoft 社が提供している電子メールのアプリケーション）では、届いたメールは自分が予め作っておいたフォルダに自動で振り分けられる機能を持っている。この機能は、メールの件数が少ない時には便利だが、件数が増えてくるとだんだんと整理が出来なくなってくる。また、分類するための属性（フォルダに付ける名前）は１つの概念でしか出来ない。
「A さんから届いたメール」、「B さんから届いたメール」という分類は出来るが、「A さんと B さんから届いたメールでかつ XX の案件」などという分類は出来ない。
一方 Google 社が作った Gmail というメーラがあるが、これは全く使い方の概念が異なる。原則として最初から固定した分類を行わない。とりあえず受信 BOX に全部のメールを取り込み、その後に、自分が探したい分類のフィルタを作成して、届いた全部のメールからそのフィルタを通して検索結果を得るというもの。よって色んな角度から見たいだけの複数のフィルタを作っておいて、ワンクリックで表示させることが出来る。
このしくみを使えば、開発途中であろうと終了した後であろうが、それぞれに必要なフィルタを容易して分類（タグ付け）すれば良い。この方法をタグ方式という。

2.2.5.2

マネジメントとナレッジのためのツール：日報システム

従来、設計者が設計する場合（流用設計含む）、最終成果物である図面や仕様書は13残るが、そこに至った経緯や思考などは残らない。したがって、本来なら、最終成果
物が本当に良いものか検証できないし、それらを流用することもできないはずである。
こういった問題を解決したいと考えている。
日報システムは、下記内容の項目を、Google を使って運用している。
①まず、設計者に仕事の手順を書かせるところからスタートさせた。
②次に、マネージャやレビュー担当者に記載された仕事の手順に対してコメントを記載させる。
（もっと良い手順などのアドバイス）
PDM ツールでなく Google を採用した背景には、コストの面もある（Google は使用料が無料である）。ただし、今回は、Google にドメイン使用料を払っている（前述、6000 円／人・年）。日報システムの良いところは、いつでも、誰もが、気軽にその情報を見たり、コメントを書いたりすることができるので、設計者やマネージャを含め設計に関連する担当者への広がりが大きくなることである。マネージャは、この日報とスケジュール（ガントチャート）の両方をみて設計に問題がないか把握することができる。
設計者に失敗したことを書かせるようなルール作りは、まだ行っていないが、既に、失敗したことを登録する仕組み（課題管理）はどこにでも在るので、ルールさえつくれば問題なく運用できるだろう。
しかし、逆に、成功したことを登録する仕組みがない。行動分析によると、失敗経験などネガティブな体験（取組み）を評価されると、同じことを繰り返す（同じ間違いを繰り返す）といわれている。この日報システムで、成功した設計手順ややり方（こういった取組みでうまく目標を達成できたなど）が登録され、マネージャや DR
担当者から誉められるといったことが出来るように目指している。
誰でも、困難を克服して成果を挙げたことは詳しく説明したくなるはずである。逆にうまくいかなかった事について、自ら進んで説明したい人などあまり居ないであろう。
どんな会社でも、課題管理のしくみはあるだろうが、このしくみを続けていくと失敗事例だけがどんどん蓄積されていく。本当に必要なのは失敗する方法では無く、うまくいく方法である。80%の成功事例でも、課題管理のしくみでは残りの 20%の情報だけが蓄積されていく。大事なのは 80%の成功の手順であって、これが繰り返されれば、常に 80%は成功することになる。残りの 20%の失敗事例だけを集めた少ない情報から改善するのは容易ではない。
この日報システムは設計者を含めて 100 名くらいで運用開始している。
（※現在は、
リーマンショックの影響で組織の大幅改定があったため、しくみの再構築中）設計者
14

は自分のページをもっていて、それに日報やスケジュールなどを記載している。以前、
PDM システムを導入したが、費用の制限もあったため設計者の運用フォローができなかった。設計者が楽しく設計できる環境を用意することは、とても重要である。
マネージャはこの日報を見て、何に反応するか？試されている。いまのマネージャ
は大人数の設計者をマネージすることは出来ない。これまでの設計者は、日々、こんな設計を行いましたと、結果のみを報告してきた。したがって、どうやって設計したか、それが良いのか悪いのかわからない。
設計者によって日報内容にバラツキはあるが、まずは、記録するところから始めな
いと前に進むことができない。これは、設計業務にブログを活用しているようなものである。人によって書き込む内容や量が異なり、それにより、コメント内容も異なっている。運用を始めたばかりなので、設計者によって、書き込むレベルは異なるが、書き込む頻度は高くなっている（毎日書き込む設計者も居る）。異なるブランド間の設計者の共通な言語はないが、それぞれ設計者はリアルタイムな設計の独り言やメモ的なことを記載している。この日報システムの運用管理は 2009 年現在１人で行っている。100 名が登録したナレッジの検索には、Google エンジンを使用している。設計者は頭の中に検索したいキーワードを持っているので、必要なナレッジを無理なく取り出しているようである。
課題としては、この日報システムはセキュリティの問題で外部ドメインからはアクセスすることができない（OEM／ODM 製品への展開）。日報システムには、仕事の手順を中心に記載させている。また、仕事の手順にデータ（ドキュメントなど）をひも付けできるようになっている。マネージャや DR 担当者は、仕事の手順に対してコメントを記載する。一般的に、仕事の手順や方法に対しては、マネージャがコメントを記載し、仕様や設計内容に対しては全員でコメントを書き込んでいる（役割を分けている）。
マネージャは設計者が日報を登録したすぐ後に、タイムリーに必要なコメントを記載できるか？が重要なポイントである。日々、設計状況が変わる中、設計者の最新の取組み（悩み）は変わっていく。日報内容とマネージャのコメントの間に時間が空くと、行動管理にならないので、システムの目的を満たさないおそれがある。こういったネガティブなコミュニケーションを発生させない運用の工夫が今後の課題である。
これだけはツールやシステムでは補うことが出来ない。人は人によってしか満たされないからである。

15

2.2.6

設計ナレッジの管理

ユーザが自由に使用方法を考えることが出来るシステム
設計作業を効率的に行うには新しい設計をなるべくしないで流用設計を活用する必要があるが、それを支援する重要なナレッジツールとしての日報システムがある。
D 社の設計者（100 名）の設計ベテラン度はバラバラである。実際、彼らが記載している内容も当初考えていた内容とは様々な点で異なっている。例えば、ハード設計者
だと、実際にやったことではなく、事前打合せ（ヒアリング）を元に、頭の中で分かる内容を組み立てて、記載したりしている場合もある。
他にも日報システムの使用法としては、例えば、ハード設計者やソフト設計者が集まって問題解決方法を話し合い、その内容や具体的な取組みを記載する方法や、日々の設計業務に中で、暗黙知化している情報（実際はちゃんと残さないと分からない情報）を記載する方法などが出来るように、システム管理者が支援している。この取組
は本社が旗を振って行っているものではない。D 社の開発／設計サイドがメインとなって行っている。ハード（サーバー）は Google のデータセンター（クラウド）を使用しているので、初期費用がかからないため、それぞれの部門で自分たちの目的に合わせて自由に活用できる。
実際によくある使い方として、設計管理で標準化（ナレッジ化）を行い、それを元に（それをひっぱってきて）設計したり、あるいは、標準化された設計資料では使い勝手が悪い場合、自分で使い易いものに編集したり、設計者は様々な工夫をしている。
設計者にとっては、設計手順として標準化（ナレッジ化）されている作業（タスク）が系統立てて在る場合、『この作業（タスク）はとばしたら良い（問題ない）』、とか、『この作業（タスク）をやることで目的が達成した』といった情報が反映できて、いつでも簡単に検索できれば、重要なツールになり得る。
標準化（ナレッジ化）を行う上で二つの問題がある。
(1)設計を進めるにあたり、日報情報（ナレッジ情報）がどんどん増えてくる。残す
情報と捨てる情報をどのように切り分ければよいか？
(2)日報情報（ナレッジ情報）に記載している言葉は、設計者によってバラバラである。例えば、電源ひとつとっても、デンゲン（カタカナ記載）、電源（漢字記載）、パ
ワー（英語記載）様々である。ナレッジとして検索する場合、検索できない場合がある。どこかのタイミングで検索できるように、同類文字への統一／修正しないといけない。
この問題を解決しないと、ほしいナレッジが検索できなくなるので（何千件と検索さ16れるので）、設計者は使わなくなる。単なるネットワークシステムとなってしまう。
こういった問題を解決するためには、日報情報（ナレッジ）のクリーニングが必要である。日報情報（ナレッジ）をタグ方式でクリーニングするなどの作業が必要になってしまう。
D 社では、まずは設計者に日報情報（ナレッジ）を記載させることに重点をおいている。会社の文化にもよるが、マニュアルとかデータの中にナレッジ情報を入れ込むと、設計者は、忙しい中、それを取り出して（検索して）、自分の作業（タスク）にすり合わせて設計することが出来ない。それよりも、設計の仕組み（例えば、設計
DR、検証など）に設計情報（ナレッジ）が活用できるように組み込むことが重要である（設計者がナレッジをうまく活用できる）。
これは仕様 BOM と同じ考え方で、例えば「ルール BOM」みたいなものを作ってクリーニングされた（うまくいった）情報だけをどんどん書き込むようなしくみを作っていくことで解決出来るのではないかと考えている。80%のうまくいった成功例の方を残していきたいのである。
現実問題として、単なる設計標準化（ナレッジ化）はつかえない（定着しない）。
しかし、自動車においては、設計標準化されている業務規程を熟読して、設計を行っている。会社の文化によって、標準化（ナレッジ化）の運用は様々である。新規に設
計標準（設計ナレッジ）を構築する重要なキーとして、①設計標準は存在するが、設計者の何人の頭の中にあるか？②設計標準がいまの設計の中で生きているのか（使われているのか）、死んでいるのか（使われていないのか）などがある。したがって、
新たな設計標準が必要かどうかは、日報システムを立ち上げ、まずは設計者に記載させることでそれは直ぐに分かる。
D 社においても、設計標準や内部規定のドキュメントは存在するが、あまり細かく
その基準に作り込んでしまうと、アップデートの手続きなどの制約があるため（しばられるため）、設計標準はあまり使われていない。設計者は設計の手順や手法（Todo
リストなど）を Excel に記載して管理している。ただ単に、Excel で管理している状
態だと、その内容を設計者で共有することはできないので。これからは、ガントチャ
ートに、設計の手順や手法を記載した Excel をひも付けて管理していくことを構想している。ガントチャートで早く終わった（うまくいった）設計がわかるので、若手の設計者は、問題が起こった時、そのうまくいった設計をキーに、誰に聞けばよいか？
とかどのような手順や手法でやればよいか？といった情報を引き出すことが出来るよ
うになる。
17

設計現場では、設計検討の内容が増え、また、新たな要素が追加されるので、仕事（作業）の手順を変えない限り設計目的を達成することができない。ガントチャートに設計手順や手法をひも付けすることで、うまくいった設計や仕事（作業）の手順や手法を取り出し、進化させていくことで時間情報との連携も可能になってくるのではないかと期待している。まずは、設計の手順や日報の標準化（ナレッジ化）を定義し、設計者は必ず標準化（ナレッジ化）を元に設計をスタートさせる仕組みが必要（設計
テンプレート）である。標準化（ナレッジ化）したものよりも、さらに良い手順や手法があれば、現状の標準化（ナレッジ化）した手順や手法を置き換える必要がある。
この場合、置き換えるためのルールが必要となる。効率よく設計を進めるにあたり、１本幹が通った設計標準化（ナレッジ化）した手順や手法が存在し、設計チャンピオンの系列として管理することが重要である。逆にいえば、それ以外の情報は区別して管理したら良い（検索時に区別できるようにする）と思われる。
設計標準がほんとうに死んでいるのなら、それを持っている（管理する）必要はない。設計者が新たに記載した手順や方法を暫定標準として運用し、その中からチャン
ピオンとなる設計標準（設計ナレッジ）を精査したら良い。D 社では、標準化（ナレッジ化）した手順や手法をどのように設計者やマネージャの行動に落としこんだらよ
いか？が課題となっている。ナレッジ管理を行うには、PDCA サイクルループが重要なキーとなる。マネジメントで何を管理するかが問われている。例えば、スケジュー
ルの遅れをリカバーすることはしょせん無理なことが多い。スケジュールされたスタート日程が遅れた場合、いろいろな要因が混在するが、その計画は失敗することが多い（50%の割合で失敗すると言われている）。これを防ぐためには、マネージャが、『誰が』『今』『何をしようとしているのか？』を把握し、負荷がないか管理することが重要となる。しかし、WBS ではうまく管理することが困難な状況である。
日本式の工程管理（インライン管理）とリソース管理を一体としたもので負荷管理をおこなっている。タスクやパートとリソースを別に管理し、クリティカルパスの責任者の負荷がすぐにわかるように工夫した。仕様 BOM をつかってソフト開発の仕様や機能などを管理している。しかし、ソフトの場合、複数のモジュールから機能を生成しているため、ブロック割りとかマッピング情報などといったものもセットで管理しな
いといけない。現状では、そういったソフト特有のものは管理できていなく、今後の課題と思っている。
設計変更など、複数の設計者に変更内容を共有する道具としてグーグルドキュメン
トを使用している。グーグルドキュメントでは、変更点（変更内容）をリアルタイム
18

に、共有ドキュメント（変更要求／変更検討）として複数人で共有し、同時に編集を加えることができるため、操作が簡単で設計者ニーズにあっている。通常の PDM では、変更内容を検索して、取り出して、編集してなど設計者にとって操作が多く使えにくい。したがって、中々定着しない。しかし、グーグルドキュメントは、ワイガヤできる環境をそなえたものである。また、必要ならそれらの情報（ドキュメントの内容）
を Excel にエキスポートできる。プロジェクトを管理するうえで、全てのプロジェク
トが見える（把握できる）仕組みが必要である。例えば、当初、重要でないと思っていたプロジェクトが、設計が進むにつれて重要視されることが良くある。
通常、問題・課題を解決するために、関係部門が集まり、設計 DR、進捗、工程会
議などを行う場合があるが、この日報システムではそれらの会議で打合せた議事録を登録する運用をとっていない（そういった仕組みやルールを取り決めていない）。そもそも、日報システムでは、そういった設計 DR、進捗、工程会議にて、打合せする
問題/課題を、日々の設計の中で解決するために運用している。狙いとしては、すり合わせ型の開発をうまく廻す方法として運用したいと思っている。
タスクが終わる条件をどのように設定しているのか？何をもってタスクが終わったことにするか？は悩ましい。以前は、2～3 日で終わるものを、余裕をもって 1 週間と申請していたが、現在はそういったことはなくなった。タスクは、成果物（仕様書、図面）と関連させて、それらが完成したときをもって終了するようにしているが、本来は仕様の達成基準を決めて、何パーセントその基準を達成したかを管理しないと設計品質を担保出来ないと考えている。次の課題。

3.

事例分析

3.1

開発の背景

ケース企業の開発マネジメントの取り組みの背景は、下記のことがある。第一に、オーディオ市場のパラダイムが激変したことがあり、市場ニーズや業界仕様が設計者の届かないところで決められることがあった。それに加えて、一般顧客の生活スタイル
や裕福層の生活価値を考慮した設計が求められることも背景にあった。第二に、開発
スケジュールの展開（計画、実行、検証）の課題が挙げられる。すなわち、音の設計
はアナログ的な要素が多いので、音の技術を標準化できないことと、開発スケジュー
ルがオーバーする中、設計者が力技で設計を行っている（設計負荷大）ことがある。
第三に、ハード開発とソフト開発の同期をとるのが困難であったこともある。ハード
19

開発はどんどん先に進んでいくが、ソフト開発は中々先に進めない。その結果、ハード・ソフト開発の設計者にとって重要な機能や性能の仕様書が共有出来ていない課題などが露出されていた。第四に、マネージャが開発案件を管理するために多大な工数を費やしていたことも背景にある。すなわち、多くの設計者はスケジュール計画の習得や技術を持ち合わせていない（訓練されていない）場合があった。また、設計者は結果のみを報告するが、はたしてその結果が良いかどうか判断できない状況が発生した。とりわけ、設計結果で問題が分かってもどうにもならなく、かえって問題対応に工数がかかる場合が多かった。

3.2

取組みの目的同社の開発マネジメントの狙いは、市場にあった半歩先の商品を製品化し、企業の生き残りを図ることにあった。具体的に、スケジュールの遅れを無くすために、開発
マネジメントに注力したり、技術（ノウハウ、ナレッジ）を有効活用（すり合わせ）出来る人材（設計者）を育成したりする取り組みを打ち出した。また、開発マネジメ
ントの質を向上し、設計のムリ、ムラ、ムダを排除することを試みた。たとえば、設計結果の評価ではなく、設計行動（設計手順、問題のきずき）の評価を重視することと、IT を活用し、スケジュールや設計行動（仕事手順、問題の気づき）を公開（ブログ化）することを試みたのである。

3.3

商品開発プロセス[図１] 開発マネジメントのスタイル

20同社の開発マネジメントのプロセスは、図１に示すとおりである。基本的な開発プロ
セスでは、成熟している製品を開発しており、アイデアや思想の取り込みが重要であり、基本に忠実な設計ができるマネジメントを構築した。つまり、役割を担当する設計エンジニア（マネージャーなど）が設計行動（手順、気づき）を評価することで、次の開発で有効活用できる設計行動のナレッジ(設計標準化)を図るマネジメントプロ
セスを構築した。

3.4

成功のポイント

同社の製品開発マネジメントの結果、売上高に占める営業利益率が１０％以上となり、高い利益率を実現するようになった。こうした成果を可能にした要因をまとめてみよう。

[図 2] 開発マネジメント

第一に、同社は企業を存続させるために、市場にあった半歩先の商品開発を実施した
ことが大きかったのである。具体的に、(1)設計者は、アイデアや思想の取り込みが21

できるように、基本に忠実な設計スタイルを実施した（基本に忠実な設計スタイル確立）。(2)構想設計の上流段階から、仕様書の中にピンポイントで価値を作りこんだ設計を行ったことである（ピンポイントでの製品価値の作りこみ）。(3)同じ製品でも、市場先（アメリカ、ヨーロッパ、日本など）で音の好みや生活スタイルが異なるため、市場先のニーズに合わせた設計を行ったことが功を奏したのである（顧客情報を設計にフィードバック）。
第二に、設計のムリ・ムダ・ムラを排除するためのマネージメントスタイルを確立したことである。たとえば、(1)設計者が、日々の設計行動（計画、プロセス、仕事手順）を記載し公開（設計ブログ）した。(2)マネージャや設計リーダーが、日々の設計行動（計画、プロセス、仕事手順）をレビューし、設計行動に対するコメント（良い所、改良点など）を記載した。(3)設計者は、設計行動のコメントをもとに、設計を進めた。(4)日々の設計行動やコメント（計画、プロセス、手順）は、設計ルール（設計者ノウハウ）やマネージメントルール（マネージャーノウハウ）として活用したことが挙げられよう。

4.

まとめ

本稿の事例は、D 社のオーディオ設計マネジメントに関する内容である。本稿では、
設計マネージャとして設計現場で思考している内容について説明し、PDM や PLM にフォーカスをあてている。設計現場が IT に求めることは、設計作業だけでなく、マネジメントも重要な支援対象であることとそれを管理する仕組みが必要であることを示した。
日本人の設計者は、怒られるのがいやなので、スケジュールの遅れを報告しようとしないし、苦手である。例えば、設計者がスケジュールの遅れを報告しないで、そのままの状態で、他の作業をしているケースが良くある（タスクの進捗度が 90%でとまっている状態のままで）。設計者本人は、優先度が低いあまり影響を及ぼさないものと判断していても、全体をみると、そのところがボトルネックになり、スケジュールに大きな影響をおよぼすことがたまになる。
一方、T 社では、新規開発スタート時期に前回の開発者を交えた事前打合せを行っている。当初は、新規開発に関する打合せを 2 時間おこなっていたが、現在は、前回の開発者を交えて、新規開発に関することや、前回の開発での設計手順や方法などの交流を 4 時間かけて行っている（若い設計者対応）そうだ。その会議に出席している若22

い設計者は、前回の開発での設計手順や方法をもとに、新規開発で自分が何をどのようにやらないといけないのか？イメージできる。また、何か問題が起こった時、誰に聞けば良いか？とか、怒られずに設計するにはどうしたらよいか？といったことも事前にわかるので、好評となっている。
若手設計者とベテラン設計者の知識（ノウハウ）の差はあるが、設計の手順や手法といった進め方のバラツキはなくすことができる。N 社のソフト開発では、若手のソフト開発者に、最初の 1 年目は誰に何を聞けばよいか？という設計ネットワークを構築する作業をさせているようだ。設計ネットワークが構築されていないと、ソフト開発の見える化はできない。
プロジェクト管理の中で一番難しいのは、設計リーダーが作業（タスク）の終了を的確に判断することである。信頼している部下から作業（タスク）が終了していると報告をうけていても、ふたを開けてみると、その作業（タスク）がまだ終わっていない
ケースが何度もあった。通常、山積みの限界が近付くと、設計の諸先輩が山崩しを手伝ってくれていた。設計内では自然と師弟関係によるめんどうみが行われている。
『めんどうみ』をポイント化して、クリティカルパスを回避することができないか？
山積みの限界を想定した、『めんどうみ』のタスクをつくり対処しても良い。ただし、『めんどうみ』に対する人事評価制度もセットにしないといけない。
ハード設計の山積みの単位は、だいたい 1 週間となっている。だいたいの作業（タスク）は 1 週間で廻るようにしている。ソフト開発の山積みの単位は、バラツキが多くマチマチである。というのも、必要な機能を開発するとき、複数のモジュールをすり合わせて開発しているので、賞味の工数を洗い出すことができない。個々のモジュー
ルを修正する作業は簡単なのだが、それが正常に動作するかは別問題である。ソフト
開発者は徹夜に近い作業を行い、スケジュール確保させている。
本稿は、設計者のマネジメントの視点で、ハードとソフトの開発設計における統合管理の問題や評価のための相応しいツールを探索してきた。開かれたものづくり環境における顧客のニーズに合った統合型ものづくりを実現するための設計プロセスのマ
ネジメントは、今後ますます重要になっていくと思われる。D 社の事例はこうした理想的な設計マネジメントの構築のための代表的な試みのケースであり、同じ悩みを持っている設計リーダーたちにも良い示唆を与えると確信する。

23