なぜ開発は失敗するのか ー開発ごっこの特徴ー

日本の電機業界で各社が行き詰まっているのが多く、集中投資を行なった分野でも事業としては失敗していることが多い。
その理由の一つに次のような要因があるのではないかと、私は疑っている。

開発ではなく、開発ごっこになっていないか

この文章では、開発ごっこの特徴を述べ、どうして開発ごっこでは、製品の開発に成功しないのかを述べようと思う。
開発に関わっている人々の仕事への取り組み方を変えて、実際に開発に成功してほしいと願う。

開発ごっこの特徴：

• 「実現できたらすばらしいことをやっている」、「成長分野として積極投資されている分野で仕事している」とかで満足している。
  • 本当は、どうやったら達成できるのかについて、考え行動し続けなければならない。
• 実験室レベルの成功と、製品化の間のギャップに思いをはせることができていない。
  • 機器による特性のばらつきの影響を考えていない。
  • 耐久試験のことを考えていない
• 既にある技術・製品を購入すればいいものでも、自分達で意味もなく作りたがる。
• 市場への無関心
  • その技術・製品ができたとして、それが市場で価値を持つかどうかについて十分な裏付けをとろうとしない。
  • 事業として成功させることへの執着を、持ちあわせていないメンバーの存在が多い。
  • その技術を使った製品を市場に投入した時に何が起きるかへの想像力がない。
• 「失敗を恐れず」などという言葉を容易に口に出してしまう。

こういった傾向が多数あったら、それは開発ごっこです。

開発を成し遂げるためには、成し遂げたい開発への情熱がなくてはならない。それを達成したいという想いは、それを達成するまで満たされることがない。達成できるまでの時点で満足することはありえない。
経験を積んできたエンジニアであれば、実験室レベルで成功しても、製品化への障壁が大きいことを知っているだろう。しかし、開発ごっこの場合には、実験室レベルでのトップデータをだけに目を向けてしまい、それがそのまま製品にできると思い込んでしまう。（あるいは、製品化のための地味な検討は、考えなくてもよいと思ってしまっている。）
開発ごっこの場合には、開発を成功させるために何をしなくてはならないのかを組織として考えることが少ない。そのため、現場のエンジニアに十分な市場の情報は届けられることも少ない。

開発ごっこを許してしまう理由

• 自分達が本当に開発したいと思っていないテーマで開発予算がついてしまう。そのテーマに運悪く割り振られてしまう。
  • 自動ハンコロボットなんて、本当に作りたかったものですか？
• 開発テーマを設定した人が、その開発が「成功した」という結論を得ることを重視していて、開発の進め方について担当者の自由度はない。
• 開発の目標を、自分事とすることができていない。
• 開発が可能だということと、それを開発すべきだということの差はとても大きい。
• 開発すべきテーマならば、どうやってその開発に成功し、市場で価値を得て、他社に対して勝ち抜くかを考えつづけなければならない。
• 外部的には上手にPRできてしまっていたりして、開発の実情を口に出すことが許されない。
• うまくいっているように見せかけた方がいいという管理職の個人的な動機
  • 成果主義のため、うまくいっているように見せかけた方が、待遇が確保される。
  • うまくいっているふり、なんとかなるふりをし続けた方が、その開発を決定した上級の管理職に対する忖度になる。
    
• なまじしっかりしたものができて、「それを投入するから」などと決断されるよりは、開発ごっこで終わってくれる方がいいと、技術の中身や状況に関係なしに考える一部の人。
• 技術者と非技術者を分断した組織運営
• 組織内の透明性の欠如・組織内の対話の拒絶
• 自分達の組織の存在価値を定義しようとしない組織運営
  • 世界で流行っている技術をしているということだけで自己満足してしまう組織。
  • 開発に失敗しても、アメリカなどで前例のある失敗なら、独自のアプローチでの失敗よりも大目に見てもらえる。

難しい開発をすればいいのではない。

• ビジネスとして意味のあるものを、少ない開発で作りあげるのがよい。

  • 実用最小限の製品
  • 製品として成立する最小限をMVP（実用最小限の製品： minimum viable product）として明確化できているか。

• 問題を必要以上に難しくしない。

• 達成したレベルが少ない段階でも、意味のあるリターンが得られるものになっているのが望ましい。

  • 推薦システムの場合には、完成度が高くない状況でもそれなりのリターンは得られる。
  • 改善すれば改善しただけ、価値が出るようにできているか。

• 100%の精度（100%の再現率、100%の適合率）でなければ使えないというなら、製品として成立することはできない。

  • ビジネスモデルを考えなおせ。

意味のある開発の条件

開発目標の製品・サービスのMVPが明確になっても、それが開発できることとを意味しない。その製品・サービスを実装するための技術として何を用いるのか。その技術の選択、もし既存のものでそれを満たすものがなければ要素技術の開発をする可能性を考えなくてはならない。

ここで得てしてやってしまうことが、いたずらに自社で開発する技術を増やしてしまうという失敗だ。事業として成功させることが目的の開発の場合、自社で開発するのは少なくて済む方がよい。なるべくなら、枯れていて実装が安定していて、部品として見た時には供給が安定しているものを使いたい。

おそらく、他社からの部品・ライブラリを購入しても、それだけでは、達成できない機能があるはずだ。その部分に集中して、開発をすすめることだ。

要素技術Aを購入すればよさそうだとなったときに、要素技術Aの技術者は社内に不要だと考えてしまう人がいるかもしれない。実際には、要素技術Aを適切に購入するには、要素技術Aの技術者が社内にいてこそ、適切な部品・ライブラリの購入ができる。その分野の技術者が社内にいれば、購入予定業者の言いなりになることは避けられる。ふっかけられて高く買わされることも減るだろう。

• 開発を成功させるためには、どうやったら開発を成功させることができるかを本気で考えぬくことが必要だ。

「実現できたらすばらしいことをやっている」、「成長分野として積極投資されている分野で仕事している」とかで満足している人は、どうやったら開発を成功させることができるかに執着できているだろうか。
開発は遊びではない。開発が失敗したらどういう経営へのインパクトが生じるのかが、怖いのが本当だ。

既存製品の改良しかしていない人は、新規開発とは何かを知らない

既存の大手企業だからといって、今までにない製品を作ることに関しては、必ずしも得意なわけではない。新製品の開発に関わる人は限られるし、その経験は特定の人に限られて、組織として引き継がれることはまずないからだ。
多くの場合、新製品の開発は、その開発者の個人的な力量とその開発者たちを支えるチーム運営にあって、そのチームが崩壊したときに、完全に失われてしまう。

既存の製品に機能を追加するだけの開発をしている場合には、以下に述べるMVP（実用最小限の製品： minimum viable product）という考え方が必要になることもない。
顧客はどこにいるのかをリサーチする必要も少ない。
新しい製品を製造するためのEMSにはどこを選択したらよいのか、どのようにそのEMSをマネジメントしたらよいのか。
販売を促進するためには、どのような売り方をしたらよいのか。
そういったもろもろを組織として引き継ぐことはほとんどできていない。

既存製品の改良しかしていない人がしてしまいがちなこと

• 開発中の技術に対して、枯れた技術と同じ水準の要求をしてしまい、単純に使えないと判断して、その利用を拒絶する。
• あるいは、逆に検証できていないことまで、実現できているだろうと勝手な思い込みでプランを立ててしまう。
• 今までの自分の経験や判断能力では、判断を間違えそうな部分があることに気づかないのが、人によって生じる。 これらは、担当した人によっていろいろであり、既存製品の改良しかしていないことによる自分の判断を間違える可能性について意識している人は、間違いをはまり込まないように行動するだろう。

既存製品の改良しかしていない組織がしてしまいがちなこと

• 新規のカテゴリの製品の開発は、既存製品の改良とは違った開発の運営のしかたをしなければならないと理解しないで行動する。
• あるいは逆に、過度にルーズな体制で運営してしまって、開発を失敗させてしまう。
• 既存製品の改良以上のことをするには、組織内の更に小さなチーム内で完結することではない。新しいものが本当に市場に受け入れられるのか、どのようにプロモーションをするのか、新しいものが十分な耐久性を持つか。単に技術を開発して、設計すれば十分なわけではない。
• そのためには、組織内の異なる職能の人と対話し、可能性を発見していかなくてはならない。そのことに気づかないまま開発をすることによって失敗してしまう。

失敗する可能性に対策し続けることができない人にまかせれば失敗する。

新規のカテゴリーの製品には買い手がつくかどうかわからない

あたらしい価値は何なのか

あたらしい価値をわかりやすく伝えること。体験させること。レンタルによる体験をしてから購入することもできるとか。購入までの不安を減らしていくことが重要だ。

意味のある開発テーマだからといって成功するわけではない。

意味のある開発テーマを成功させるには、マネジメントが重要だ。
新しい分野の技術・製品の開発は、既存技術の改良だけの場合とはまったく異なる。
そのため、何が成功させるための必須要件なのか考えて、それを実現できる人員を集めて、条件を整えることができる人にしか、マネジメントをまかせてはいけない。
開発の現場ででてくる課題に対して、真摯に向き合えない人の場合には、そのマネジメントを任せてはならない。
ある専門分野のノウハウが必要ならば、そのノウハウをもった人をチームに招き入れよう。

失敗した場合のリスクだけに目がいって、失敗させないために工夫をすることなしに、挑戦を否定する。

大企業の場合の新製品のプロジェクトは、得てしてこの状態に陥ることがある。

自分達が成功しやすいようにルールを変えろ

本当に成功する製品が必要なときに、方式１と方式２を別々に開発し続けて、別々に製品として出荷するのは得策ではない。いかにユーザーが望むからといって２つの方式を開発してはならない。方式が違えば、一方で生じた課題を解決しても、それは他方には展開できない。開発・製造に対して２倍の投資をするはめになっているということだ。ただでさえ、新製品の開発をして利益を上げるのは難しいのに、開発費・設備投資を２倍にしてビジネスを成功できると思っているなら、必ず失敗するだろう。

顧客の希望を変えさせろ

開発する技術・製品を１つの方式に限るようにするため、顧客の側を変えさせることだ。方式を１つにすれば、開発費も設備投資も絞り込めるので、顧客Aと顧客Bに別々に開発するよりもはるかにいい。その結果は顧客の側にもやってくる。だから、条件の交渉をして顧客の希望を変えさせろ。それができずに、言われたまま引き受けるなんて、それがプロの仕事か。

技術的な問題を解決するには、技術的な誠実さが必須なのに、技術的な誠実さは軽視される。

開発を成功させるための組織運営

えてして開発を自分事にしていないメンバーが多数いる。

開発を自分事にしていない場合、自分の仕事があるだけで満足してしまって、それ以上の課題意識を待たない。
なるべく、自分の担当範囲に枠をつくり、その範囲の中では責務を果たすが、それ以上のことには事なかれ主義になる。
他の部分に大きな問題があっても、それに対して目をつぶって、困っているメンバーのことを助けようとしない。
開発を自分事としていないメンバーは、ときとしてチームのリーダーである場合さえある。自分があと数年良い待遇を得られればよいと思っている人の場合だ。かつていい結果を仕事で出してきた人であっても、今そのテーマに対して本気で取り組んでくれているかは、手放しではわからない。
リーダーの立場に応募してくる人には、すくなくとも２通りある。待遇や権限を志向している人と、結果を出すためにメンバーが働きやすくすることを考えている人だ。

アピールが上手すぎる人をリーダーに選んでいないか？

世の中には、アピールが上手な人に２通りある。アピールも上手だし結果を出すことにこだわり続けられる人と、アピールが成功し役職を獲得してしまうと満足してしまう人だ。アピールが上手な人は、「この人に任せれば成功できると思い込ませることのできる人」である。
世の中には、「この人と一緒になれば幸せになれると思い込ませることのできる人」がいる。そして、徹底していい人であって、信頼できる人であって、そして最後の最後に裏切る人がいる。そう、結婚詐欺だ。アピールが上手な人は、相手が何を欲しがっていて、どう伝えれば相手の心にひびくか知っている。しかも、自分の利害を達成するためには、何が手っ取り早いか知っている。役職を求めて、出世競争する人は、極めて挑戦的で野心的で、しかも組織の中で協調性があるように見えて、まさに非がないように見える。

チーム内のコミュニケーションをよくすること

しかし、あえて問う。
開発を成功させるための資質は何ですか？
開発を成功させるためには、何を解決する必要があるのか、

• 社長の肝いりのプロジェクトであるから、「成功している」ということにしなくちゃいけない。
• 上司への忖度が重要になる。
• 適切な指摘ならば、だれが言ったものであった受け入れる態度を持ち合わせていない。
• 市場で成功するためには何が必要なのかを問い続けることをしない。

自然は忖度することがない。

市場は、あなたの上司のために忖度などしない。
実験事実も、あなたの上司のために忖度などしない。
開発は、市場に対して、さまざまな実験事実に基づいて、製品を作り上げていく作業だ。市場も、実験事実も、あなたの上司のために忖度などしない。市場や実験事実と誠実に向き合うことだけが、開発を意義のあるものにしていく。

たとえ宣伝重視であっても

開発の途中では、未解決の問題があることは珍しくない。その未解決の問題を解決するまでの時間稼ぎのために、その問題になるべくふれたくない状況もあるだろう。それでも、内部的にはその問題に対して誠実に対応し続けることだ。
技術的な問題は、かってに解決することはない。
誠実に対応していけば、その問題を解決できて、しかるべき段階で、きちんとした結果をずっと前から解決してたのかのように振る舞うこともできるだろう。

技術的な誠実さを失えば、それは開発ごっこだ。

市場への誠実さをもたなければ、技術者の自己満足で終わる。

市場はどうなっているのか、数年後にはどうなっているのかを予想しよう

どういうかたちで購入されるのかを意識しよう。

部品となるハードウェア・ソフトウェアはどのようにして、その部品を利用したい設計者にとどくのか

• 旧来の営業主体、NDA重視のやり方では、今の開発速度・開発スタイルにはそぐわなくなっている。
• 楽なやり方の営業ができないくらいならば、売れないほうがマシだと思っている人はいないか？

「成長部門・積極投資部門」にいることで満足してしまって、成功への執着がない。それじゃ成功するわけがない。

ある事業を成長分野と見定め、積極投資を行なっても、それだけでビジネスが成功することはありえない。
ものごとを成功させるためには、どうやったら成功するのか考えぬいて、失敗する要因を排除していって、少しでも成功しやすく活動を続ける必要がある。
とあるベンチャー企業の倒産事例の中で、耐久試験を軽視してきたことが取り上げられていた。まともな感覚の開発リーダーであったら、耐久試験の重要性はわかっていて、なにがしかの手は打っておくだろう。耐久試験の重要性を述べるメンバーはいなかったのか。いても聞き入れなかったのか。どちらにしても残念なことだ。

たいがいの開発は、失敗しないための工夫をどれだけきちんと積み重ねることができるかで、やっと実用に耐える水準になる。
「この部分は、予め対策を打っておかないと大変なことになるぞ」ということをわかる人が、対策を積み重ねていることで実用になっている。そのことをわからないのであれば、その分野の開発マネジャーを引き受けてはならない。
自分の無知を自覚して、勉強することが必要だし、わかっている人に教えを請うことは大切だ。

---

医療機器分野で成功したいのであれば、医療機器分野では何が必要なのかをわかっている人をそろえることだ。

かつては家電メーカーであった面影はなく、ヘルスケア事業に完全移行し躍進が続いています。
現在のような事業構造になったきっかけは、2011年にフランス・ファン・ホーテン氏がCEOに就任してからと言われています。
ホーテン氏の最初の仕事はテレビや音響事業の売却をすることでした。
さまざまな分野に広がりをみせるフィリップスの事業を大胆に事業整理したのです。
そして売却益を元手にヘルスケア関連の企業を次々に買収していきます。
こうして2018年ごろになると、ほぼ全ての事業をヘルスケア関連へと様変わりさせることに成功しています。

「選択と集中」リストラによって復活した欧州企業

すべきだった判断の例：　その事業に適した人・組織を買収することをすべきだった。

間違った判断基準：経営陣に対して”忠実"すぎる人を選んではいけない。
　このときの判断をする人は、自分の個人的な利害や、仲間内の利害を重視する人を選んではいけない。個人的な利害や、仲間内の利害を重視する人は、企業にとって損失がでる選択であっても、実行にうつしてしまう。経営陣に対して忠実すぎる人は、それが経営陣に気に入られるという個人的な利害を優先している可能性が高い。忠実すぎる人は、既にいる人ではできないような判断基準や視点を持ちあわせていないので、いなくてもなんとかなる場合がある。

その事業の進め方に必要な人の資質について適切に判断ができていること

仕事をする場所を選ぶ際には、その事業を行うのに適した資質の人を集めている場所で働くのがよい。
あなたが何事かを成し遂げるためには、同僚も力があるのが頼もしい。
その会社の事業を成功させるためには、少しでも成功しやすいように、会社自体が行動できているかどうかだ。
適切な判断ができる人が増えていけば、物事がうまく進みやすくなる。
人を選ぶ際に、好き嫌いで選んではいけない。その職種の仕事を成し遂げるために必要な物事の考え方をしているかどうか、自分の力では解決しきれないことに、まわりの人々に力を求めて解決していけるかどうか。
大手企業の人事の残念な事例は、自分達の属している企業の中では、どの分野でどのような資質と才能を持った人を必要としているかを理解していない人を採用担当にあてている場合があるということだ。

　とくに、「あと何年持てばいい」といった発想をする人は、個人的な利害を優先させている人であり、経営判断をまかせてはいけない。

選んだ事業を進めるために必要な資質は何か

間違えている事例：　何度もリストラと称して人員の削減を進めている事例。

残すべき人員と別な分野で活躍してくれることを期待する人員とを区別する明確な事業戦略を持っていない。

「自分達のアプローチはこれでいいのか」と進みながら、問い続けることが必要
あなたがしたいのは、開発ごっこなのか、開発なのか。

現場の開発チームメンバーへのアドバイス

• 開発チームの外のメンバーと交流を持つ機会を大事にしよう。
• 製品のユーザーの声を聞ける機会を大事に使用。
• 自分は何を実現したいのかを明確に持とう。
• 自分の中に２つの価値観を持ってみよう
  • １つは、技術自体の可能性の軸に基づいた価値観
  • もうひとつは、ユーザーに送り届けられ製品・サービスに基づく価値観 この２つの価値観の中で、自分がその時々の業務の中で達成させようとするのが何かを考えよう。チームとしては、２つの価値観も大切に思ってもらいたい。しかし、１つめの価値観を重視しなければ、次の技術の可能性を閉ざしてしまうことも明らかだ。

　開発チームのリーダーへのアドバイス

• 開発を成功させるための執念を持とう。
• 開発が成功すると誰がどのようにうれしいのかを明確にしよう。
• 開発メンバーが、その分野の開発で生きていけるだけの力量を持てるように配慮しよう。

- 現行の方針の問題点があれば、それを克服する別案を考えよう。

開発を行なっている企業の開発チーム以上の上司の方々へのアドバイス

• 自分にとってうれしくない直言を聞く力量を持とう。
• 外部環境についての認識とか、開発の技術的な内容についての事実認識は、「うれしくない直言」ほど大切にしよう。
• 権限を持つ人ほど、引き起こす失敗の悪影響が大きいことを自覚すること。
• 権限を元に押し通すのではなく、明快な論理によって話を通そう。
• 時間を無駄に失うことが、どれだけ人々の生活を台無しにしていまうのかを忘れないこと。
• 世の中にある失敗の事例から学べ。
• 事業が消えてなくなるときでも、どうやったら人々が生活できるようになるかをしぶとく考えようよ。
• 製品を出荷できればゴールではない。製品が世の中に定着して、事業が安定になるのが開発のゴールだ。

最後に

まだまだ、考えが十分整理されきっていない文章を読んでくださってありがとうございます。

---

開発に向かない人

• 成功させることに対して執着がない人
• 自分が失敗するかもしれない要因に対して対策を打ち続けるという努力ができない人
• 事なかれ主義の人
• 自分達が生み出すものに魅力を感じられない人
• 同じ失敗を繰り返しても気にしなさすぎる人。

追記

開発エンジニアに必要な情報を伝えよう。

• ビジネス上価値があるのは何なのかを伝えよう。
• ビジネスとして成功するための条件を伝えよう。
• 何は重要でないのかを伝えよう。
• 市場での価格の将来の予測を現場の開発エンジニアに伝えよう。
• 競合製品との中で、どう自分達の優位を創りだすのかを、開発エンジニアとともに考えよう。

本当に必要なものを見誤らないようにすることが大事だ。
DRAMの開発では重要だったもの。
☓：ウェハーあたりの製品の歩留まり
◯：投入する資本あたりの良品の数。

開発するべきものを間違えて伝えて開発をしていたのだから、競合の会社にやぶれたのは、後知恵の私には、不思議がないように思える。

さらに追記

他の方式に比べて15%から20%もコストが低くなるという程度の改良は、現行の方式を捨ててまで乗り換える価値を生み出すだろうか？
仮に、その方式が安定して量産が可能になったとしても、設備をことごとく入れ替えなくてはならないことを考えると、乗り換えを生じることはないように思う。

開発に失敗することを恐れるあまり必要な開発をしなくなってしまう。
その事業を継続させようとすれば、常に先に進みに続けなくてはならない。
にもかかわらず、役職者は失敗することを恐れて開発を行うことを自体を恐れるようになってしまっていないか。

さらに追記２：欠けているものは何か？

「いま、◯◯の技術・製品が各社競い合っている。我が。社も◯◯の分野で果敢に挑戦していこう」などというのは、たいがい失敗する。
自分たちが創り出すものが価値を生じるためには何を突き詰めなければならないのかを考えていないからだ。
たいがいの技術には、後になって考えるとなぜ、それが長いことそのままだったのだろうという技術がある。缶詰の発明が1810年であるのに缶切り が発明されるのは1858年とのことである。着目している分野の現状の中で「欠けているピース」があるということに多くの人間が気づかなかった。
同等な技術で競い合えるのは2社までである。1社しか存在しない技術は、その会社の圧倒的な独占を避けたいという思惑から2社目が存在することがある。でも選択肢の確保には2社あれば十分であって、3社目には、同等な技術・同等な製品で生き残る場所は用意されていない。
同じ目的のためにさまざまなフレームワークがある場合でも、その分野で淘汰が進む。そのため、新規に加わろうとするものは、十分に明確な新しい価値を届けなければならない。
その十分に新しい価値は、今の技術の状況での「欠けているピース」であることだろう。
それを見つけて、勝利するための作戦を描けないうちに投資をしてしまうことが、開発投資の失敗につながる。

きれいすぎる問題の定式化は見落としがある（と思った方がよい）

サターンロケットなどで有人月探査を行った時代、ロケットを毎回使い捨てることが経済的でないと考えられるようになっていった。
そのため、スペースシャトルが開発・運用されて、シャトルの本体は繰り返し使われるようになった。
「甘すぎた予測と膨らんだ費用と危険性」と書かれている。

この例では、「再使用すれば、新しく作るよりも安くなるはずだ」という裏付けのない仮説にしたがって、「本体を再使用することで安く運用できるシステムを作り上げる」というきれいすぎる問題の定式化をしてしまっている。

実際には、大気圏再突入という過酷な温度・振動条件を経た機体を、次の打ち上げで事故の起きない機体にするためのコストがとても高くつくものになってしまった。

機体の再使用については、次のようなアプローチがなされてきている。
「かつてスペースシャトルでは軌道上に到達するオービタと呼ばれる上段部分が再使用されたのに対して、ファルコン9では1段目のロケットとフェアリングを再使用する。」

宇宙空間に達して大気圏再突入をしない第１段ロケットこそ、再使用の価値があることを見出し、実現したことが、運用コストを下げることにつながっている。

きれいすぎる問題の定式化は問題の本質に対して十分に踏み込むことなく、「◯◯とされている」という裏付けの乏しい仮説を安易に受け入れてしまうことにつながってしまう。

事業として成功させるための課題は常に変化し続ける。

あるコンセプトにしたがって、従来なかった価値あるものが開発に成功したとしよう。
それでも、事業として成功させるには、解決すべき課題が常に出てくる。
しかも、その解決すべき課題は、変化をし続ける。
販売量もしくはサービスの量を拡大するとともに、それを遂行できる組織の運営が必要になってくる。