製品開発にまつわる6つの神話

ほとんどの製品開発マネージャーは、プロジェクトを時間通り、予算通りに進めることにいつも苦労しています。 仕事をこなすのに十分なリソースはなく、上司からは予測可能なスケジュールと成果物を求められます。 そこでマネージャーは、チームにもっと効率的な仕事をさせたり、より詳細な計画を書いたり、スケジュールの変動や無駄を最小限に抑えるように働きかけます。

多くの企業は、製品開発を製造業と同じように考えていますが、両者は大きく異なります。 モノを作る世界では、作業は繰り返し行われ、活動はある程度予測可能で、作られるものは一度に一つの場所にしか存在しません。

このような決定的な違いを理解していないために、製品開発プロジェクトの計画、実行、評価を弱めるいくつかの誤りが生まれています。 半導体、自動車、家電、医療機器、ソフトウェア、金融など、さまざまな業界において、50年以上にわたって製品開発に関する調査やアドバイスを行ってきた私たちは、これらの誤解に遭遇してきました。

Fallacy 1: High Utility of resources will improve the performance.

私たちの調査やコンサルティングでは、大多数の企業が製品開発のためのリソースをフルに活用しようとしています。 私たちの一人であるドナルドは、カリフォルニア工科大学のエグゼクティブコースで行った調査により、平均的な製品開発マネージャーは98%以上の稼働率を維持していることを明らかにしています。 人が100%働いていないと、プロジェクトに時間がかかる。だから、忙しい開発組織は、人の使い方が下手な組織よりも、より速く、より効率的になる、という論理です。 どんなに優秀なマネジャーであっても、マネジャーが製品開発担当者の皿を埋め尽くすと、必然的にプロジェクトのスピード、効率、アウトプットの質が低下することがわかっています。

開発作業の本質的な変動性を十分に考慮していない

製品開発の多くの側面は、プロジェクトがいつ発生するか、どのような個別の作業が必要か、そのような作業に取り組んだことのない従業員がどれくらいの時間がかかるかなど、予測できません。 一方、企業が最も得意とするのは、製造業や情報処理などの反復的なプロセスであり、仕事の内容があまり変わらず、サプライズもほとんどない。 このようなプロセスでは、リソースの利用率が高まるにつれて、秩序立った行動をとるようになります。

変動性の高いプロセスでは、挙動が大きく異なります。 利用率が高くなると、遅延は劇的に長くなります。

変動性の高いプロセスでは、その振る舞いが大きく異なります（図表「稼働率の高さがもたらす遅延」参照）。 しかし、この効果を理解している人はほとんどいません。 私たちは何百もの製品開発チームを見てきましたが、ほとんどのチームが大幅にオーバーコミットしていることがわかりました。

確かに、いくつかのばらつきは規律の欠如の結果であり、一部の製品開発タスク (飛行機のプロトタイプのコンポーネント設計や臨床試験の実施など) には、より反復的な作業が含まれています。 しかし、一部の作業が予測可能であっても、それが他の予測不可能な作業と組み合わされると、待ち行列の問題が発生します。

待ち行列が経済的なパフォーマンスにどのように影響するかを理解していない

リソースの高い利用率は、必然的にプロジェクトの待ち行列を作ります。 部分的に完了した作業が、容量が空くのを待って放置されると、プロジェクト全体の期間が長くなってしまいます。 また、キューはフィードバックを遅らせ、開発者が非生産的な道を辿ることになります。 このような状態では、企業は進化する市場のニーズに適応したり、手遅れになる前に製品の弱点を発見したりすることが難しくなります。

皮肉なことに、これらの問題はまさに、マネージャーが高稼働率によってチームが回避できると考えている問題です。 このコストは定量化できるにもかかわらず、大半の企業が計算していないことがわかりました。

製品開発では、仕掛かり在庫はほとんど目に見えません。

製造業の待ち行列は物理的なもので構成されており、工場の在庫が2倍になれば、それは明らかです。 しかし、製品開発の現場では、設計書、テストの手順や結果、試作品の作り方など、情報が主な在庫となります。 エンジニアリングプロセスで在庫が倍増しても、物理的な兆候はありません。 さらに、会計基準では、ほとんどの R&D 在庫をゼロ価値で計上することになっているため、財務諸表では、製品開発における深刻な在庫過剰を示すことはできません。

目に見えない、あるいは測定できない問題に立ち向かうのは非常に困難です。 ある大手製薬会社の場合を考えてみましょう。 数年前、新しく就任した創薬部門の責任者は、経営上のジレンマに直面していました。 大規模なR&D組織を運営する他の上級幹部と同様に、彼は科学者をより革新的にする方法を見つけようとしていました。 彼は、有望な新薬を生み出せるような新しい化合物の実験を増やし、同時に、有望でない候補をできるだけ早く排除してほしいと考えていました。 しかし、生物を使った実験は動物実験部が担当しており、彼の管理下にはなく、コストセンターとして運営されていた。 実験資源をいかに効率的に使うかが評価の対象となり、自然と稼働率が高くなった。 その結果、創薬に携わる科学者たちは、1週間ちょっとで済む試験の結果を3〜4カ月も待たなければならなかった。

このような問題に対する明らかな解決策は、変動の大きいプロセスに容量のバッファーを設けることです。 このことを長い間理解していた企業もあります。 3Mでは何十年もの間、製品開発者を定員の85%でスケジュールしてきました。 また、Googleは「20%タイム」で有名です（エンジニアが週に1日、好きなことに取り組むことを許可し、プロジェクトがスケジュールに遅れた場合には追加のキャパシティを確保しています）。 しかし、私たちの経験では、この種のソリューションを実行するのはかなり難しい。 これから説明するように、利用可能なキャパシティを余すところなく使いたいという誘惑に勝てる組織はほとんどありません。

しかし、他にも実行可能な解決策があります。

管理制御システムの変更

製薬会社の場合、動物実験部門の目標を発見部門の目標と一致させるための措置を講じることが考えられます。

選択的に能力を高める

稼働率が70%以上の領域にリソースを追加することで、待ち時間を大幅に短縮することができます。 製薬会社が動物実験でこれを行えば、新しい化学物質のフィードバックをはるかに早く得ることができるでしょう。 コンピュータによるモデリングやシミュレーションを用いてテストを行っている環境では、コンピュータ機器やソフトウェアのライセンスを追加購入するだけなので、キャパシティの増加は比較的低コストで済みます。

アクティブなプロジェクトの数を制限する

もし製薬会社が動物実験のキャパシティを増やせなかったとしても、新しい化学物質を探索するアクティブなプロジェクトの数を減らすことで、稼働率を下げることができます。

仕掛かり品の在庫を見やすくする

1つの方法は、視覚的なコントロール ボードを使用することです。 これにはさまざまな形式がありますが、重要なのは、ポストイット メモのようなある種の物理的なトークンが開発作業を表していることです (展示品「典型的な仕掛かり品の管理ボード」を参照)。 コントロールボードは、すべてのアクティブな作業を表示し、プロジェクトの各部分がどのような状態であるかを示す必要があります。 これは、チームの管理プロセスの中心となるべきものです。

誤り2: 作業を大規模なバッチで処理すると、開発プロセスの経済性が向上する。

製品開発における待ち行列の第2の原因は、バッチ サイズです。 例えば、新製品が200のコンポーネントで構成されているとします。 200個の部品をすべて設計・製造してからテストすることもできます。 もし、20個の部品だけを設計・製造してからテストを開始したとしたら、バッチサイズは90％小さくなります。

バッチサイズの縮小は、リーン生産方式の重要な原則です。 小ロットにすることで、メーカーは工程内での作業を削減し、フィードバックを加速させることができ、その結果、サイクルタイム、品質、効率が向上します。

その理由の一つは、開発者のワークフローの性質です。

理由の1つは、彼らのワークフローの性質です。ここでも、彼らが作成している情報はほとんど目に見えないため、バッチサイズも同様です。

うまく管理されたプロセスでは、バッチ サイズは取引コストと保有コストのバランスをとります (展示「最適なバッチ サイズを決定する方法」を参照)。 これは、食料品店で卵を買うのに似ています。 12ヶ月分を一度に購入すると、取引コストは低く抑えられますが、ほとんどの卵が腐ってしまい、保有コストが高くなります。 一方、1日分をまとめて買えば、腐る量は少なくて済みますが、取引コストは高くなります。

この仕組みを理解している企業は、ITの進歩を利用してバッチサイズを小さくし、しばしば驚くような結果を出しています。 以前は90日ごとに大量のコードをテストしていたソフトウェア会社が、今では1日に数回、はるかに小さなバッチでテストしているところもあります。 あるコンピュータ周辺機器メーカーでは、ソフトウェアグループに同様のアプローチを採用したところ、ソフトウェアテストのサイクルタイムが95％（48ヶ月から2.5ヶ月）短縮され、効率が220％向上し、不具合が33％減少しました。 コスト削減効果は、同社が予想していたよりも2倍高かったという。 これらの結果は例外的なものでしたが、私たちは、バッチサイズを小さくすることで、ほとんどの開発プロジェクトが大幅に改善することを発見しました。 同様に、コンピュータ化されたモデリングおよびシミュレーション ツールは、物理的な製品を開発する企業において、実験やテストの最適なバッチ サイズを劇的に下げました。

Fallacy 3: 開発計画は素晴らしいので、それを維持すればよい

これまでのコンサルティングや調査では、設計プロセスを通じて要件が安定している製品開発プロジェクトに出会ったことはありませんでした。 しかし、多くの組織では、計画を過度に信頼しています。 しかし、多くの企業では、計画を過度に信頼し、その逸脱を管理や実行の不備に起因するものとし、それを最小限に抑えるために、中間目標やマイルストーンに照らし合わせてすべてのステップを慎重に追跡しています。 このような考え方は、確立された製造プロセスにおける反復性の高い活動には適しています。 しかし、日々新しい洞察が生まれ、状況が絶えず変化する製品イノベーションでは、このような考え方では良い結果は得られません。

MITのトーマス・アレンが行った技術的問題解決に関する古典的な研究は、開発作業の流動的な性質を浮き彫りにしています。 この研究では、航空宇宙のサブシステムを開発していたエンジニアたちが、いくつもの設計案を考え、評価した上で、最適と思われるものを選択していることを発見しました。 しかし、その過程では、競合する技術的な解決策をテストし、改良していくうちに、彼らの好みは頻繁に変わっていきました。 これは、イノベーションプロジェクトの典型的な例です。

お客様のニーズを定義することは、製品開発プロジェクトの初期段階では難しいものです。 考えてみれば、それは当然のことです。 考えてみれば当然のことで、まだ存在していないソリューションに対するニーズをお客様が正確に把握することは容易ではありません。 実際、既存の製品の属性に精通していると、新しい製品に対するニーズを表現するのが難しくなることがあります。

これらの理由から、当初の計画に固執することは、その構想がどれほど優れていて、どれほど巧みに実行されたとしても、災いの元となります。 私たちは、計画を立てることを否定しているわけではありません。 製品開発は、細部に至るまで慎重な調整が必要な、複雑な活動の集合体です。 しかし、計画は最初の仮説として扱われるべきであり、証拠の展開や経済的前提の変化、機会の再評価に応じて常に修正されるべきものです。 (「The Value Captor’s Process」 Rita Gunther McGrath and Thomas Keil, HBR May 2007参照)

Fallacy 4: The sooner the project is started, the sooner it will be finished.

先ほど説明したように、マネージャーにとってアイドルタイムは嫌なものです。 彼らは、新しいプロジェクトを開始することで、どんなダウンタイムも利用する傾向があります。 別のプロジェクトに戻らなければならないためにタスクが完了しなくても、新しいプロジェクトで達成したことは、後でやらなくてもいい仕事だと考えるからです。

この希釈化は危険です。 リソースが不足している状態でプロジェクトに着手すると、開発プロセスが停滞してしまいます。 問題なのは、製品開発の仕事は非常に短期的なものだということです。 技術や市場についての想定がすぐに崩れてしまうからです。 プロジェクトの進行が遅れれば遅れるほど、プロジェクトの方向性を変えなければならない可能性が高くなります。 実際、ある軍部では、コストとスケジュールのオーバーランは、プロジェクトの期間に指数関数的（4乗）に比例することがわかった。

仕掛かり品の量を減らすことの重要性は、待ち行列理論の古典的な公式の1つを見ると明らかです。 リトルの法則」です。 これは、平均して、サイクルタイムは、待ち行列のサイズを処理速度で割った値に比例するというものです。 つまり、スターバックスであなたの前に20人が並んでいて、バリスタが1分間に5人にサービスを提供している場合、あなたは4分でサービスを受けることができるということです。 サイクルタイムを短縮するには、処理速度を上げるか、進行中のジョブの数を減らすことができます。

製品開発者の中には、仕事を開始する速度を厳密にコントロールすることで解決している人もいます。

Fallacy 5: 製品に機能を追加すればするほど、顧客に気に入ってもらえる。

製品開発チームは、機能を追加すると顧客にとって価値が生まれ、機能を削除すると価値がなくなると信じているようです。 この考え方は、製品が複雑になる理由の一つでもあります。 リモコンは使いこなせないし、コンピュータは設定に何時間もかかるし、車にはスイッチやノブが多すぎて飛行機のコックピットのようだし、地味なトースターにさえ説明書や液晶ディスプレイが付いている。

「多ければ多いほど良い」という考えに挑戦する企業は、シンプルな中にもエレガントな製品を生み出しています。 Bang & Olufsen（デンマークのオーディオ、テレビ、電話機メーカー）は、お客様が必ずしもイコライザーやバランスなどのコントロールをいじって、音楽を聴くのに最適な設定の組み合わせを見つけたいとは思っていないことを理解しています。 ハイエンドのスピーカーは、楽曲をできるだけ原曲に忠実に再生するための調整を自動的に行います。

企業が「Less can be more」という原則を受け入れ、実行することは、製品開発の2つの分野で特別な努力を必要とするため、困難です。

Defining the problem.

開発者が解決しようとする問題を明確にすることは、イノベーションのプロセスで最も過小評価されている部分です。 あまりにも多くの企業がこの段階に時間を割いていません。 しかし、この段階は重要です。なぜなら、チームが自分たちの目標を明確に理解し、実験によって検証・改良できるような仮説を生み出すところだからです。

Walt Disneyがディズニーランドを計画したとき、彼は他の遊園地よりも多くの機能 (乗り物、食べ物の種類、駐車場の数) を追加することを急がなかった。 それよりも、もっと大きな問いを立てることから始めました。 どうすれば、お客さまに魔法のような体験をしていただけるか？ 一朝一夕に答えが出るわけではなく、綿密な調査と絶え間ない実験、そしてディズニーとその顧客にとっての「魔法」とは何かを深く洞察することが必要でした。 IDEO社などでは、製品やサービスがどのような状況で使われるのかを徹底的に調査するフェーズがあります。 開発者は、市場に関するあらゆる情報を読み、未来のユーザーを観察し、インタビューし、新製品と競合する製品を調査し、学んだことを絵やモデル、図にまとめます。

何を隠すべきか、省略すべきかの判断

チームは、同僚や経営陣を驚かせるような素晴らしい技術的ソリューションを生み出して、自慢したいと思うことがよくあります。 しかし、多くの場合、お客様は何の問題もなく動作する製品を望んでいます。 顧客の視点から見ると、最高のソリューションは、最もシンプルな方法で問題を解決し、開発者が誇りに思っている仕事を隠してしまうものです。

このことを理解している企業のひとつがAppleです。 革新的な製品、スタイリッシュなデザイン、巧みなマーケティングなど、さまざまな分野で知られていますが、おそらく最大の強みは、問題の核心に迫る能力を持っていることでしょう。 4月号のウォルター・アイザックソン著「スティーブ・ジョブズの真のリーダーシップ・レッスン」を参照）。 故スティーブ・ジョブズは、「問題を見始めたときに、それがとてもシンプルに見えるとき、あなたは問題の複雑さを本当には理解していない。 そして、その解決策はあまりにも単純化されすぎている。 そして、その問題に取り組んでみると、実に複雑であることがわかります。 そして、複雑な解決策を考え出すのです。….、ほとんどの人はそこでやめてしまいます。” アップルは違います。 アップルは、ひたすらやり続けます。 “

どの機能を省略するかを決定することは、どの機能を含めるかを決定するのと同じくらい、あるいはそれ以上に重要です。 残念なことに、多くの企業は革新的であろうとするあまり、顧客にとっての価値や使いやすさなどの重要な要素を十分に考慮せずに、ありとあらゆるベルやホイッスルを投入してしまいます。

むしろ、マネージャーは、提案された機能を削除することで、特定の製品が改善され、チームが全体的なカスタマー エクスペリエンスを真に高めるものに集中できるようになるかどうかを見極めることに集中すべきです。 これは、提案された要件を仮説として扱い、見込み客を対象とした小規模で迅速な実験で検証することで判断できます。

開発チームは、これ以上機能を追加できなくなった時点で製品が完成したと考えがちです。 しかし、本来はその逆でなければなりません。 逆に言えば、これ以上機能をなくすことができなければ、製品は完成に近づくということです。

Fallacy 6: We will be more successful if we get it right at the first time.

多くの製品開発プロジェクトは、予算、スケジュール、および技術的なパフォーマンスの目標を達成できません。 もちろん、計画の不備やプロセスの硬直化、リーダーシップの弱さなどが原因であることは間違いありません。 しかし、意外と見落とされがちなのが、「最初からうまくやれ」というマネージャーの要求です。 最初の一回で成功しなければならないということは、たとえお客様がそれを既存のものよりあまり改善していないと考えていたとしても、チームは最もリスクの少ないソリューションに偏ってしまいます。

失敗を避けるために、チームは直線的なプロセスに従います。そこでは、各段階 (指定、設計、構築、テスト、スケール、発売) がレビューの「ゲート」で注意深く監視されます。 ゲートを通過するまでは、次のステージの作業を開始することはできません。 プロジェクトが進むにつれ、重要なコミットメントがなされ、新しい洞察に対応するためのコストは桁違いに増加します。 後半のテストの成功は祝福され、サプライズは、それがどんなに価値のあるものであっても、挫折とみなされます。 残念ながら、このような直線的なプロセスフローは、テストのフィードバックが遅れたり、チームが必要以上に悪いアイデアに固執したり、解決に費用がかかるまで問題が発見されなかったりするため、プロジェクトのオーバーランを引き起こす可能性があります。

人々が迅速かつ頻繁に反復し、失敗から素早く学ぶ限り、「最初に間違ったことをする」ことに対する寛容さは、より良い戦略となり得ます。

シミュレーションとラピッド プロトタイピング テクノロジーの進歩により、この方法での作業は非常に簡単で、コストもかかりません。 反復的なアプローチをとり、初期段階で頻繁にテストを行ったチームは、途中でより多くのエラーを出しました。 しかし、彼らは低コストのプロトタイピング技術を使用していたため、最初から正しい設計をしようとするチームよりも、必要な時間と労力の面で優れていました。 一方、試作コストが高かったチームは、仕様策定、開発、検証に多くの労力を費やした。

イノベーションプロジェクトでは、さまざまなアイデアを試すことが重要です。 頻繁に実験を行えば、もちろん多くの新しいコンセプトは失敗します。 しかし、このような初期の失敗は、チームが劣悪な選択肢を迅速に排除し、より有望な代替案に集中できるという点で、望ましいものです。 自動車の設計が安全ではないことを示す衝突テスト、毒性があることが判明した薬の候補、顧客を混乱させるソフトウェアのユーザー インターフェイスなどは、すべて望ましい結果です。