あなたの会社が設計・開発に失敗する理由――ツール？ 組織？ それともデータ共有？：設計部門ごとの違いを無理に統一しない（1/6 ページ）

製品を企画し、販売に至るには開発・設計フェーズと製造フェーズが欠かせない。日本には製造技術に優れた企業が多いが、開発・設計はどうだろうか。一部を見ると優れているが、全体の最適化に失敗した製品を見たことがないだろうか。米Texas Instrumentsと米Mentor Graphicsで開発・設計の問題に長年取り組んだ人物はこの問題をどう捉えているのか。「7つの解決手法」とあわせて紹介する。

[畑陽一郎，MONOist]

なぜ協力できないのか

　「製品の全体設計をうまく最適化できないのはなぜか。個別の部門では可能な最適化がなぜ部門をまたがると難しくなるのか」。設計に関する問題をこのように捉えたのは、米Mentor GraphicsのChairman兼CEOであるWalden C. Rhines氏だ（図1）。

　Rhines氏の結論は明快である。開発・設計フェーズの課題における最大の課題――部門単位での最適化には問題がないにもかかわらず、システムレベルで設計を最適化できないという課題の原因は、開発・設計に関係する部門間のさまざまな壁にある。講演では、この壁を取り除く「7つの手法」を紹介した。

　2012年9月7日に東京で開催された半導体・基板設計者向けのセミナー「Tech Design Forum 2012」の基調講演「製品開発最適化の秘訣」で、同氏は、「企画、開発・設計、製造、販売」というモノづくりの流れのうち、開発・設計フェーズに横たわる課題を掘り下げた。

図1　米Mentor GraphicsのWalden C. Rhines氏　同氏は米Texas Instrumentsに21年間勤務し、同社のバイスプレジデントを務め、その後、1993年からMentor GraphicsのCEOの職にある。

省電力設計には成功したのに

　開発・設計フェーズでシステムレベルの最適化ができないとは、そもそもどのような意味なのだろうか。同氏は約10年前に直面した実例からシステムレベルの最適化ができないと何が起こるのかを紹介した。

　当時のMentor Graphicsは、消費電力と性能を最適化するハードウェア合成技術や設計技術を顧客に提供していたという。半導体設計、システム設計では必要な処理性能をなるべく低い消費電力で実現することが強く求められる場合が多い。折良く、消費電力の問題で困っていたコンシューマ製品の大口の製造企業を顧客として迎えた。

　顧客の目標はデータ処理部分の回路の消費電力を4.5mWまで引き下げること。ところが3人年をかけて開発しても8.47mWにとどまっており、目標を全く達成できていなかった。顧客企業と共同で消費電力低減に取り組んだところ、プロセッサの動作周波数を下げ、消費電力を絞るという方針が有効なことが分かった。組み込みソフトウェアのソースコードを調べ、ソフトウェア処理の一部を置き換えるコプロセッサを設計する。置き換える前のコードは2カ所でボトルネックを作り出していたからだ。その結果、性能はそのままにプロセッサの動作周波数を半減でき、消費電力を目標以上の4mWに削減できることが分かったという（図2）。

図2　消費電力を引き下げる試み　消費電力を当初の8.47mWから4.5mWに減らすことが目的である。プロセッサの動作周波数を77MHzから33.6MHzに引き下げることで消費電力を3.696mWまで引き下げた。性能を維持するためにソフトウェア処理のボトルネック部分をハードウェア（コプロセッサ）として実装すると、その部分で0.387mWを消費する。結局、両方を合計して4.083mWまで低減できることが分かった。出典：Mentor Graphics（以下同じ）

　「顧客は非常に喜んでおり、興奮していたことを覚えている。これほど最適化できることを示したのだから、必ず大口注文につながると考えていた。当社の技術者も希望に燃えていた。その後、奇妙なことが起こった。当の顧客が何も言ってこなくなったのだ。当然あるべき技術的な問い合わせもこなくなった」（Rhines氏）。

　何が起こったのか調査を始めたところ、共同で開発に成功した後、6カ月たっても顧客が意思決定できていないことに気が付いたのだという。意思決定とはこうだ。Mentor Graphicsの製品をソフトウェア部門が担当すべきなのか、あるいはハードウェア部門が担当すべきかという決断だ。ハードウェア技術者に聞くと「チップ上に追加するハードウェアをソフトウェア技術者に設計（合成）させるわけにはいかない」と言う。ソフトウェア技術者は、「組み込みソフトウェアのコードをハードウェア技術者に変更させるわけにはいかない」と言う。これでは合意は無理だ。

　どちらの部門の技術者も、最適化の結果を取り込んで製品化できれば当初の狙い以上になるということには同意した。が、実際に技術者がどう動けば実現できるか意見の一致を見なかったのだという。「結局、顧客はMentor Graphicsの技術を採用しなかった。顧客が製品に見切りを付けてしまえば、当社ができることは何もない」（同氏）。

　この話を聞くと、極端な例なのではないかという疑問がわくだろう。残念ながらそうではないという。技術的な課題よりも、部門間の調整の問題の方が、製品の改善には妨げになる。これはよくある課題であり、例えばハードウェア技術者とソフトウェア技術者が参加する共同開発でもよく見られるという。ハードウェア技術者はソフトウェア技術者の仕事が壁にぶつかっていないかどうか気に掛けることはほとんどない。逆も同じだ。