6つの製品開発神話

ほとんどの製品開発マネージャーは、プロジェクトを予定どおりに予算内で実装しようとします。 彼らは決して十分なリソースを持っていないし、彼らの上司は彼らから予測可能なスケジュールと結果を要求します。 そのため、マネージャーはチームをより質素にし、詳細な計画を書き、スケジュールからの逸脱とリソースの浪費を最小限に抑えます。 しかし、製造工場で実施するための生命の権利を有するこのアプローチは、製品開発を損なう可能性があります。



多くの企業は開発を工業生産として扱っていますが、根本的な違いがあります。 物理オブジェクトの製造の世界では、タスクが繰り返され、アクションが予測可能であり、製造された製品は一度に1つの場所にしか存在できません。 ソフトウェアを開発するとき、多くのタスクは独特であり、プロジェクトは絶えず変化する必要があり、結果の製品は多くの場所に同時に存在できる情報です。



これらの違いを確認できないと、エラーが発生し、ソフトウェア開発プロジェクトの計画、実行、評価が困難になります。 このテキストの著者は、開発に関わる企業の調査と助言に50年以上を費やし、半導体、自動車、家電、医療機器、ソフトウェア、金融など、まったく異なる分野で同様のエラーに遭遇することがよくありました。 この記事では、これらの誤解とそれらが引き起こす問題を回避する方法について説明します。

誤解1：リソース利用率を改善すると生産性が向上します

多くの企業は、開発リソースを最大限に活用しようとしています。 平均的な製品マネージャーは、使用率を98％に保ちます。 論理は明確です-人が100％忙しくない場合、プロジェクトに時間がかかります。そのため、忙しい組織は、すべての人的資源をあまり使用していない組織よりも速く効率的に作業できます。



実際には、これは機能しません。 マネージャーが開発者に最大限の負荷をかけると、プロジェクトの速度、効率、品質がどのように低下​​するかを確認しました。 ワークロードが高いと、次の3つの理由でマネージャーによって過小評価される悪い副作用があります。

開発者のばらつきを考慮していません

開発の多くの側面は予測不能です-プロジェクトが登場するとき、プロジェクトが必要とするタスク、そのようなことを前に完了しなかった人々にかかる時間。 しかし、企業は、生産やトランザクション処理など、作業が変わらない反復プロセスに最も精通しており、驚きはほとんどありません。 このようなプロセスは予定通りであり、リソースの使用率は増加しています。 完了するには5％増加し、5％時間がかかります。



揮発性プロセスはまったく異なる方法で動作します。 リソース使用率が増加すると、遅延が劇的に増加します。 さらに5％の作業を追加すると、完了には100％の時間が必要になる場合があります。 しかし、これを理解している人はほとんどいません。 数百の開発チームとの経験では、ほとんどのチームが必要以上に機能していることがわかっています。 すべてのプロジェクトを期日どおりに完了し、予算を満たすために、協力した組織の中には50％以上のリソースが必要なものがあります。





リソースの使用率の完了を待つ時間の依存性



もちろん、規律の欠如が原因である程度の不整合が発生し、プロジェクト開発の一部のタスク（飛行機のコンポーネントの開発または薬物の臨床試験）は反復タスクで構成されています。 しかし、たとえ作業の一部が予測可能であっても、予測不可能な作業と組み合わせると、計画に関する問題が明らかになります。

彼らは、キューが経済効率に与える影響を理解していません。

リソースの使用率が高いと、必然的にプロジェクトからキューが作成されます。 目的のリソースのリリースを見越して未完了の作業がフリーズすると、プロジェクトの全体的な期間が長くなります。 キューはフィードバックを遅らせるため、開発者は非生産的な方法をより長く続けます。 企業が市場の高まるニーズに適応し、手遅れになる前に製品の弱点を見つけることは難しくなります。 皮肉なことに、これは管理者がリソースを100％利用することで回避しようとしているものです。



マネージャーがキューを作成していることを知っていても、マネージャーからの経済的損失を表すことはめったにありません。 すべてのコストを計算できますが、ほとんどの企業はこれを行いません。 マネージャーは、適切なバランスを実現するために、キューのコストと廃棄されたリソースのコストを比較する必要があります。

ソフトウェアを開発するとき、開発中のものは通常表示されません

生産ラインは物理的なアイテムを作成します。 倉庫が2倍になると、すぐに表示されます。 ソフトウェア製品を開発する場合、ウェアハウスは情報で構成されます-設計文書、手順とテスト結果、プロトタイプを構築するための指示。 倉庫を2倍にすると、これの物理的な兆候は見えません。 また、会計基準によると、この情報の値はゼロに等しいため、進捗状況は財務レポートにも表示されません。



見ることも測定することもできない問題に対処することは非常に困難です。 製薬会社を考えてみましょう。 数年前、新薬開発のディレクターはジレンマに直面しました。 彼は科学者をより革新的な道に変えようとしました。 彼は彼らに将来的に薬になる可能性のある新しい化学物質でもっと実験することを望み、同時に絶望的な候補を取り除きました。 同時に、動物実験は別の部門の責任の領域にあり、それは彼の部下ではありませんでした。 この部門は、テストのためにリソースをどれだけ効率的に使用したかによって評価され、リソースの高い使用率が必要になりました。 当然のことながら、医薬品開発部門の科学者は3〜4か月のテスト結果を期待していましたが、完了までに約1週間しかかかりませんでした。 テスト部門の「適切な管理」により、開発部門が機能しなくなりました。



このような問題の明らかな解決策は、断続的なプロセスのバッファー容量を作成することです。 一部の企業はこれを長い間理解しています。 3Mでは、数十年にわたり、開発者は容量の85％で関与しています。 Googleでは、エンジニアは20％の時間（毎日）に何でもできるようになっています。これは、プロジェクトが遅れた場合にいつでも追加の時間を利用できることを意味します。 しかし、そのような決定を整理することは非常に困難です。 従業員を100％誘惑する誘惑から逃れることはほとんどありません。 マネージャーは、ダウンタイムが発生した場合、新しいタスクを再帰的に提供します。



しかし、他の解決策もあります。

変更管理システム

製薬会社の場合、これは動物試験部門の目標を開発部門と調整することを意味する場合があります。 たとえば、リソースをリサイクルするのではなく、クエリに対する迅速な回答に対してテスト部門に報酬を与えることができます。

リソースを選択的に増やします。

リサイクル率が70％を超える領域にリソースを追加すると、待ち時間を大幅に短縮できます。 製薬会社が動物試験部門でこれを行った場合、新しい化合物の要求に迅速に対応できます。 コンピューターのシミュレーションとシミュレーションを使用してテストを行う場合、リソースのコストは比較的低くなります。これは通常、追加のハードウェアライセンスとソフトウェアライセンスの購入を意味するためです。

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

動物実験部門でリソースを増やすことができない場合、アクティブなプロジェクトの数を減らすことでリソースの使用率を減らすことができます。 製品開発パイプラインを厳しく制限するという規律は、多くの場合、より良い焦点と明確な優先順位につながります。

作業中のタスクの可視性を改善します。

方法の1つは、目視検査ボードです。 見た目は異なるかもしれませんが、重要な点は、作品を表すメモ用紙などの物理的なインジケータを用意することです。 ボードには、すべての作業とプロジェクトの各部分の状態が表示されます。 管理プロセスの中心にあるべきです。 これらの委員会から毎日15分の会議を収集して、作業を調整し、作業を進めることができます。





典型的な開発ボード



最初の列-複雑さがほぼ同じ新しいタスク。 2番目は作業中のタスクです。 数値は、同時に解決されるタスクの最大数を示します。 タスクのチェックマークは問題を意味します。 3つ目は、すぐにテストできる部品です。 リーフレットを回すと、マネージャーに介入する必要があります。 4番目-テスト済みのタスク。 数値は、両方の列で同時に解決されるタスクの最大数を示します。 5番目-テストされたタスク。

誤解2：タスクを大きなバッチで処理すると、開発プロセスの経済性が向上します

製品開発でキューが表示される2番目の理由は、ロットのサイズです。 新製品が200個のコンポーネントで構成されているとします。 テストを開始する前に、200個すべてを開発および構築することを決定できます。 しかし、代わりに20個のコンポーネントが開発された場合、ロットサイズは90％小さくなります。 キューは平均してロットのサイズに比例するため、これにより待機時間が大幅に短縮されます。



バッチ削減は、柔軟な生産の基本原則です。 作業を削減し、フィードバックを高速化し、生産サイクル、品質、効率を改善できます。 製品開発における小さなバッチはさらに重要ですが、これを理解している人はほとんどいません。



一つの理由は、彼らの仕事の流れの性質です。 処理された情報には物理的な表現がないため、当事者も同様です。 2つ目-開発者は大規模なパーティーを行う傾向があります。 おそらく彼らは、これにより規模の経済が可能になると誤って信じています。



適切に管理されたプロセスでは、バッチサイズによってトランザクションとストレージコストのバランスが取られます。 食料品店で卵を買うようなものです。1年前に卵を買うと、輸送コストは低くなりますが、ほとんどの卵は悪くなり、保管コストが増加します。 卵を1日購入しても劣化しませんが、輸送費は高くなります。







最適なロットサイズは、コストが最も低いもの（トランザクションとストレージ）です。 この点からわずかに逸脱しても、大きな問題は生じません。 たとえば、理想的なバッチサイズから20％逸脱すると、生産コストの変化はわずか3％になります。



この問題を理解した企業は、バッチのサイズを縮小し始め、驚くべき結果につながります。 いくつかは、90日ごとに大きなバッチをテストする代わりに、小さなバッチを1日に数回テストすることに切り替えます。 コンピュータ周辺機器の製造業者の1つは、ソフトウェアテストのサイクルタイムを95％（48か月から2.5）短縮し、効率を220％向上させ、欠陥の数を33％削減しました。 節約額は、会社が予想したものの2倍に達しました。

誤解3：素晴らしい開発計画があります。それらを厳守するだけです。

開発期間を通じて要件が一定であるプロジェクトに出会ったことはありません。 しかし、多くの組織は彼らの計画を神聖に信じ続けています。 逸脱は、管理と実行が不十分であることに起因し、それらを減らすために、すべてのステップを追跡します。 頻繁にステップを繰り返す生産プロセスの場合、これは良いアプローチですが、開発の革新には適していません。 新しい洞察は毎日来ることができ、状況は常に変化します。



技術的な問題を解決する古典的な研究は 、開発者の変化する性質を明らかにしています。 航空サブシステムを作成したエンジニアがオプションを開発し、最適なものを選択した方法を示しています。 その過程で、彼らの好みはしばしば変わり、彼らは解決策をチェックし、明確にしました。 これは革新的なプロジェクトの典型です。テストと実験により、何が機能し、何が機能しないかが明らかになり、価値と価値の暫定的な見積もりが変わる可能性があります。



ユーザーのニーズを定義することも問題になる可能性があります。 そして、当然のことながら、まだ存在しないソリューションの要件を顧客が正確に策定することは困難です。 製品の既存の特性に精通していると、人が新製品の要件を策定できなくなる可能性があります。 競合他社が新しいオファーを提示し、新しいトレンドが市場に登場するため、ユーザーの好みは開発プロセス中に劇的に変化する可能性があります。



したがって、元の計画を厳密に順守すれば、どんなにすばらしい計画であっても、完全に失敗する可能性があります。 もちろん、私たちは計画を信じています-製品開発は、調整と細部への注意を必要とする複雑なアクションのセットです。 しかし、計画は絶えず見直されている初期の仮説として考慮されなければなりません。

誤解4：早く始めるほど早く終わる

マネージャーはダウンタイムを嫌い、それらを使用して新しいプロジェクトを開始しようとします。 人々が最初に別のプロジェクトを完了する必要があるために新しいジョブを開始できない場合でも、マネージャーは、今日新しいプロジェクトでできることはすべて明日行う必要のない仕事になると全員に確信させます。 これにより、企業は実際に実行できるよりも多くのプロジェクトを開始せざるを得なくなり、リソースの浸食につながります。



これが起こると、会社は開発プロセス全体でつまずきます。 しかし、製品開発は腐りやすい製品であるため、このような減速は有害です。テクノロジーと市場は急速に変化し、廃品になります。 プロセスが遅いほど、方向を変える可能性が高くなります。 軍事開発部隊の1人は、プロジェクトの開発にかかる費用と遅延が、その開発期間の増加に伴い指数関数的に増加し、第4度になったことを発見しました。 プロジェクトのスケジュールを2倍にすると、コストとスケジュールからの逸脱は16倍になりました。



進行中の作業量を減らすことの重要性は、古典的なキューイング理論の式-リトルの法則を見れば明らかです。 平均して、サイクル時間は、キューのサイズを処理速度で割った値に比例します。 スターバックスで20人に直面しており、バリスタが1分あたり5人にサービスを提供している場合、4分でサービスが提供されます。 サイクル時間は、速度を上げるか、ジョブの数を減らすことで短縮できます。 通常、実際には2番目のオプションを実装できます。



一部の開発者は、新しいジョブを開始する速度を慎重に制御し、それを古い作業の速度と比較し、プロセス内のプロジェクトの数を制御し、プロジェクトを開始した後、それをサポートするのに十分なリソースがあることを確認します 彼らは、新しいプロジェクトにリソースを投入するために、作業中のプロジェクトからリソースを盗もうとする誘惑を避けます。

誤解5：製品の機能が多ければ多いほど、その人気は高まります。

開発チームは、多くの場合、機能を追加すると製品の価値が高まり、削除すると削除されると考えています。 これは、製品が非常に複雑になる理由を説明しています。 リモコンは使用できず、コンピューターは数時間セットアップする必要があり、車には飛行機のコックピットのように見える非常に多くのノブとボタンがあり、トースターでさえ指示とLCDディスプレイを使用します。



シンプルでエレガントな製品を生産する方が良いとは思わない企業。 デンマークのオーディオ機器、テレビ、電話のメーカーであるBang＆Olufsenは、顧客が音楽を聴くための最適な設定の組み合わせを見つけるためにイコライザーやバランスなどを演奏することを必ずしも好まないことを理解しています。 ハイエンドスピーカーは自動的に曲に合わせて調整します。クライアントに残されるのは音量を選択することだけです。



開発の2つの分野で努力をしなければならないため、「少ない」とは「より多く」を意味することがあると会社に納得させることは困難です。

問題定義

開発者が解決しようとしている問題を明確にすることは、イノベーションプロセスで最も過小評価されている部分です。 多くの企業がこれに費やす時間が少なすぎます。 しかし、これは重要なフェーズです。これは、チームが真の目標を理解し、検証および明確化できる仮説を述べる方法です。 問題ステートメントの品質は、チームが本当に重要なことに集中する能力に劇的に影響します。



ディズニーランドを計画するとき、ウォルトディズニーは他の公園のような新しい機能を追加することに急いでいませんでした。 彼は、公園への訪問者に彼の訪問の魔法のような印象をどのように提供できますか？ IDEOおよび他の企業は、製品開発の全フェーズを、製品またはサービスを見るコンテキストに没頭することに専念しています。 開発者は、市場に関するすべてを読み、ユーザーを観察してインタビューし、競合他社のオファーを研究し、新しい知識を写真、モデル、図に変換します。

隠せるものまたは放棄できるものの定義

多くの場合、チームは独創的な技術ソリューションで同僚や上司に感銘を与えたいと考えています。 ユーザーは、問題なく機能する製品を必要としています。 彼らの観点から見ると、最良のソリューションは、開発者が誇りに思っている作業を隠すシンプルなソリューションです。



これを理解している企業の1つがAppleです。 彼らの最大の利点は、問題の底に到達する能力です。 ジョブズは次のように述べています。「問題を検討し始めると、それは非常に単純に思えます。その複雑さを理解していないため、ソリューションは単純すぎます。 問題をより深く掘り下げると、複雑であることがわかります。 そして、あなたはさまざまな紛らわしい決定に至ります-これがほとんどの人がやめていることです。」 しかし、アップルではありません。 「本当に偉大な人は、問題の中心にある主要な原則を動き続け、見つけ出し、美しくエレガントな解決策を見つけます。」



どの機能を省略することができるかを決定することは、製品に含める必要があるものを決定することと同じくらい重要です。 残念ながら、ほとんどの企業は、顧客価値や使いやすさなどの重要なことを考慮せずに、考えられるすべての機能をヒープに投入しています。 そのような企業は、開発コストまたはスケジュールの遅れだけのために機能を削減しました。



マネージャーは、いずれかの機能を削除することで製品が改善されるかどうか、そしてそれによってチームが顧客にとって本当に重要なことに集中できるようになるかどうかに集中する必要があります。 これは、各機能の簡単な実験で確認できます。



開発者は、追加するものがなくなったときに製品が完成したと考えることがよくあります。 それらの論理は逆にする必要があります-それらを捨てることが何もないとき、製品は完全になります。 レオナルド・ダ・ヴィンチが言ったように、「シンプルさが最高の合併症です。」

誤解6：初めて成功すればより成功する

多くのプロジェクトは、予算、スケジュール、技術的義務を果たせません。 もちろん、貧弱な計画、柔軟性に欠けるプロセス、弱いリーダーシップがそれぞれの役割を果たします。 しかし、マネージャーは多くの場合、自分の要求が「最初にすべてを正しく行う」という要求によって実行されることを理解していません。 初めての成功により、チームは、リスクの少ない意思決定の領域に導かれます-顧客が以前の状態よりも大幅に改善されていると見なしていない場合でも。 チームは、ユーザーの問題に対する革新的なソリューションを開発するインセンティブを受け取りません。



ミスを避けるために、チームは各プロセスが調査「ゲート」で追跡される線形プロセスを好みます。 次のステップの作業は、プロジェクトが「ゲート」を通過するまで開始されません。 プロジェクトが線形パスに沿って移動する場合、多くの労力がそれに費やされ、新しいアイデアによるプロジェクト変更のコストは何度も増加します。 後の段階では、テストの成功が奨励され、非常に価値のあるものであっても、驚きは否定的と見なされます。 残念ながら、線形プロセスはプロジェクトの遅延につながります-フィードバックが遅くなり、チームは必要以上に悪いアイデアを持ち続け、ソリューションが高価になるまで問題の議論を始めません。



最善の戦略は、障害を初めて許容することです。人々が反復をより速く完了し、誤りからより早く学習できるようにします。



一般的な間違いを回避するための手順：

1. キューと情報フローを可視化する
2. 遅延のコストを見積もり、検討する
3. リソースを100％使用せず、非常に高い場合はリサイクルを省略します
4. 制御システムの注意を効率から応答時間に移す
5. トランザクションコストを削減して、より小さなバッチと高速応答で作業できるようにします
6. より小さいバッチを試してください。 いつでも元に戻すことができます。
7. 開発計画は、新しい情報とともに進化する仮説です。
8. プロジェクトのすべてのリソースに完全にアクセスできる場合にのみ、プロジェクトを開始します。
9. シンプルにチューニングします。 追加できるものだけでなく、削除できるものを考えてください。
10. より早く、より速く、より頻繁に実験してください。 コンピューターモデルと物理プロトタイプを使用します。
11. 重ねて反復する開発は線形よりも優れています
12. 最初に成功するのではなく、応答を高速化するように調整します。

カスタムチップを製造したチームから391チームを調査した結果、反復アプローチを使用し、テストをできるだけ早く、頻繁に他の人よりも頻繁に間違えた人がいることがわかりました。 しかし、安価なプロトタイピングの使用により、彼らは（時間と労力の点で）最初からすべてを正しく行おうとした人々から勝ちました。 プロトタイプの費用が高すぎるチームは、仕様、開発、およびテストにより多くの時間と労力を費やしました。 そして、それらの反復はプロセスの終わり近くで行われ、その数は少なかったため、それらの重大な問題の検出は長い遅延で発生しました。



さまざまなアイデアを使った実験は、イノベーションプロセスの重要な部分です。 もちろん、頻繁かつ迅速に実験するときは、多くのアイデアの失敗に対処する必要があります。 しかし、これにより、チームは不適切な決定を迅速に破棄し、より有望な決定に集中できます。



「より早く、より頻繁にミスを犯す」アプローチの利点の典型的な例は、1995年のヨットカップオブアメリカでのニュージーランドチームの予想外の勝利です。 キールの設計を改善するために、チームは2つの同一のボートを使用しました。1つは開発プロセス中に変更され、もう1つはコントロールのままでした。 毎日、チームはコンピューターで新しい仮説をシミュレートし、それらのベストを適用してから、コントロールボートでコンテストを手配し、結果を調査しました。



対戦相手であるデニス・コナーのチームはコンピューターがより強力で、数週間ごとに大規模なシミュレーションを実行し、同じボートで最高のソリューションをテストしました。 ニュージーランド人はより多くのサイクルを完了し、すぐに悪いアイデアを取り除き、レガッタを獲得しました。



実験に失敗しても、必ずしも失敗するわけではありません。 彼らは予見できなかった情報を提供します。 実験サイクルが短ければ短いほど、フィードバックを提供し、開発の新しい段階にすばやく組み込むことができます。



このような開発環境を作成することは困難です。 間違いは人々を混乱させ、知識のギャップを示し、その結果、自信を損なう可能性があります。 会社の貴重なリソースの早期の再配分が彼女にとって有益だったとしても、プロジェクトの死に至った問題の早期発見に対してマネージャーが昇進し、チームに報酬が与えられる頻度を考えてください。 「障害に対する許容度がゼロ」の組織では、この方向で作業することは特に困難です。



トーマス・エジソンはこれをすべて理解しており、彼の研究室では、研究者が労働者と緊密に協力できる迅速で頻繁な実験のためにすべてがセットアップされていました。 研究所には、簡単にアクセスできる情報を備えた大規模なライブラリ、必要な予備部品を備えた倉庫、および労働者からエンジニアや科学者までの多様な労働力がありました。 エジソンは、新しいアイデアの出現後すぐに、それをモデルまたはプロトタイプにすばやく変換できるようにすることを望んでいました。 彼は「成功は24時間で押し込められる実験の数によって測定される」と言った。



IT （コンピューター設計、モデリング、シミュレーション）の開発により、より少ない時間とお金で最高の製品を開発するための手段を講じることが既に許可されています。 しかし、多くの企業は、経営的思考がテクノロジーよりもゆっくりと発展するため、これらのツールの可能性をフルに活用していません。 彼らはまだ工場生産として情報製品の開発に近づいています。 情報技術の開発により、製品開発プロセスを改善する機会がさらに増えるでしょう。したがって、ソフトウェア開発と工場生産の違いを認識できなかった企業にとって、より多くのリスクがあります。