数字で決めきれない新製品開発を、どう前に進めるか

将来の利益を計算できないと、戦略は実行できないのか

新しい製品を開発するとき、既存の部品や技術を複数の製品で使えるようにすれば、次の開発を速く進められるかもしれません。ただし、最初に共通の仕組みを作る費用は増えます。将来どんな製品へ展開するかが決まらない段階では、その投資の利益を正確に計算するのは難しいものです。

この論文は、そのような不確実な状況で、企業が会計情報と戦略をどう組み合わせて開発を進めるかを調べています。中心にあるのは、戦略を日々の会話や判断で具体化し、作り直す営み（strategising）です。

経営陣が方針を決めれば、その後は決まった通りに実行される、とは考えません。どの設計が戦略に合うかを社員が議論する過程そのものが、戦略の具体的な意味を形作ると捉えます。

開発現場に入り、二つのプロジェクトを追った

調査先は、食品・農業・医薬品などの成分を調べる分析装置のメーカーです。企業名は匿名で、研究の中心となった開発・製造部門も「Division」と呼ばれています。同部門はデンマークとスウェーデンに拠点を持ち、研究者はデンマークの拠点で調査しました。

2004年9月から2005年12月までの16か月間、研究者の1人が隔週でおよそ週3日滞在し、会議だけでなく日々のやり取りも観察しました。面接は2回の調査で19件と9件の計28件です。開発の承認資料、戦略文書、社内の検討報告書も照合しています。

重点的に追ったのは、開発終盤のAlphaと初期段階のBetaです。Alphaは複数の分析装置を共通の部品で構成する最初の試みで、Betaは農家向けの比較的低価格なワイン分析装置でした。同じ戦略が、異なる開発段階や顧客層でどう具体化されるかを読める設計です。

最初の製品だけで計算すると、共通化の利益が見えない

会社が進めていたのは、機能を持つ部品のまとまりを組み合わせて製品を作るモジュール化（modularisation）です。牛乳用の分析装置をワイン向けなどへ展開してきた経験から、技術や部品を繰り返し使えば、小規模な市場にも対応できるという構想が生まれました。

しかし、既存の採算計算用の表は、製品を一つずつ評価する設計でした。共通のモジュールを開発する費用を最初の製品に全額負担させると、後続の製品で得られる開発費の節約が反映されにくくなります。多くの用途へ対応する部品は、単独の製品だけに最適化した部品より高くなる場合もありました。

CEOは最終的に、売上拡大や新製品投入の加速という戦略上の期待も踏まえて、モジュール化とAlphaを承認しました。これは採算を無視した決断というより、既存の計算だけでは構想の価値を十分に表現できないなかで、事業上の理由を組み合わせた判断でした。Alphaを通じて学ぶことも、前へ進む理由になっていました。

「モジュール化に賛成」でも、作りたいものは違う

方針が承認された後、何を一つのモジュールにするかが問題になります。再利用や組合せの自由度を重視すれば、小さく単純な単位が望ましくなります。一方、単独で品質を試験し、交換しやすくするには、別の機能や構成が必要になります。期待された便益をすべて同時に実現できるとは限りませんでした。

Betaでは、技術者が有力案と、モジュール数を少なくした案・多くした案を用意し、関係部門と比較しました。開発側は柔軟性や開発の手間、生産側は組立時の扱いやすさや試験、営業・サービス側は顧客の保有コストや修理しやすさを問題にしました。

最終的に選ばれたのは、各部門が具体的な仕事に照らして納得できる案でした。全要素を一つの数式へ変換して最適解を出したわけではありません。また、最初に合意しても、物理的な部品へ落とす段階で調整が再び必要になります。戦略の共有と、設計上の優先順位の共有は、同じではないことが分かります。

数字は、開発の節目でも日々の仕事でも効いていた

この会社では、開発を段階に分け、重要な節目で継続を承認するステージゲート方式（stage-gate process）を用いていました。経営陣は、利益への貢献割合や、5年間の予想貢献利益を開発費で割った比率などを確認します。後者はこの会社で用いた評価比率で、投資回収までの年数を意味するものではありません。

会議では数値そのものに加え、販売価格は現実的か、予定した機能を顧客が必要とするか、製造やサービスの準備ができているかなどを尋ねました。すべての詳細を確認できないため、いくつかの問いを通じて、責任者が計算の背景と開発全体を理解しているかを確かめていました。

節目と節目の間も、次の承認で説明する必要があることが、技術者やプロジェクト責任者の判断に影響します。日常業務の中心は技術的な問題の解決ですが、費用・売上・顧客との関係を無視してよいわけではありません。上位の財務目標と現場の裁量が、部門間の対話を通じて結びついていました。

引継ぎで露呈した、原価の範囲の食い違い

Betaを構想段階のチームから次の開発チームへ渡すとき、受け取る側が原価見積りの詳細を求めました。先行するAlphaで予算超過を経験していたため、実現できない目標原価を引き受け、後で責任を問われることを避けたかったのです。

そこで明らかになったのが、間接的に発生する変動製造費の扱いでした。後工程で部品表（bill of materials: BOM）を基幹システムへ入力すると、直接変動費に一定割合の間接費が自動的に加算されます。しかし構想側の技術者は、この加算を知らず、初期の原価見積りに含めていませんでした。

問題は関係者の会議へ持ち込まれ、検討チームを通じて、以後は初期見積りにもこの費用を含めることになりました。「原価の目標値を共有した」だけでは、原価に何を含めるかまで共有されたことにはなりません。数値の詳細を求める行為も、この場面では協働を成立させ、責任の範囲を明らかにする役割を持っています。

サステナビリティの開発案件なら、何を持ち帰れるか

ここからは本サイトの実務への応用です。修理・再使用しやすい製品を開発するなら、初期の製造費が上がっても、後の保守費や部品交換費が下がる可能性があります。単独の製品や初年度だけで評価する方法が、その便益を捉えているかを確かめる必要があります。

また、「循環型にする」という方針の下でも、設計は分解のしやすさ、生産は品質や作業時間、サービスは故障診断や修理費、営業は顧客の購入価格を重視するかもしれません。これらを具体的な設計案で比べ、どの判断にどの情報が必要かを話し合う場が重要になります。

ただし、原研究はサステナビリティ施策の効果を検証したものではありません。修理した中古モジュールの販売も戦略上の可能性として言及されますが、資源使用や環境負荷が減ったことを示す結果ではありません。財務面の検討と環境成果の確認は、それぞれ必要です。

不完全な数字を認めることは、改善を諦めることではない

現場では、共通化や開発期間の費用対効果をより適切に計算する道具や専門性を求める声もありました。著者も、この会社の進め方を最適な解決策とは位置づけていません。よりよい原価情報があれば、調整を効率化できた可能性が残ります。

また、事例では異なる戦略目標が最終的には収益性へ寄与すると理解されていました。社会・環境面の価値を、利益に還元できない理由から守ろうとする場面まで、この説明だけで扱えるとは限りません。単一企業の過程を丹念に読む価値と、そのまま一般化できる範囲を分けて考えたいところです。

原著は、設計の比較と引継ぎの場面から読む

まず事例分析のモジュール化の経緯を読み、図3で部門ごとの関心の違いを確認します。次に図5で開発の節目を押さえ、「Accounting during the stages of a project」の原価見積りと引継ぎの場面を読むと、数字が使われる状況が具体的になります。

最後にDiscussionへ戻ると、会計が正式な評価規則として働く場面と、収益性を意識する共通理解として働く場面の違いを理解しやすくなります。自社の案件でも、判断に使った数字だけでなく、数字を補った説明や、異論から見直された前提を記録すると、この論文の視点を活用できます。