はじめに

2019年7月、国際規格ISO 56000シリーズに新しい企画が追加されました。ISO 56002:2019 [INNOVATION MANAGEMENT --INNOVATION MANAGEMENT SYSTEM – GUIDANCE]がそれです。ついにイノベーションを既存企業において起こすためのシステムについての心得が、激しい議論の末とは言え各国の合意のもとに「規格」になったのでした。
これは今、産業界の関心が従来とは異なる、柔軟で反復的な開発方法に明示的に向かっていることを示しているのではないでしょうか。
作れば売れる時代が終わり、顧客が欲しいものを言語化できなくなってからすでにかなりの時が過ぎました。
少し前に、打ち手に困った既存企業が期待したのは「デザイン思考」に代表される"作法"でした。
そして、現在、イノベーションが起きない、デザイン思考が使い物にならない、という意見があちこちで見られるようになったのはどうしてでしょうか。
既存企業の求める、新たな欠落機能の本質とは何なのでしょう。関心の推移から、この外形を描くことで、求められている機能の概要を推測してみます。

シフトする要求

開発プロセスに見る時代の要求の変化
長らく効率化商品開発を進めてきた企業は、時代の流れに応じてその開発プロセスを改善してきました。効率化が目的であった時代に発達したステージゲート法はウォーターフォール型開発に特化されたものでした。この後様々な方法論が検討されるようになるのは、社会や組織の要求、すなわち関心の移り変わりに沿ったものだったのだろうと思います。
ここでは開発プロセスに影響を与えた関心の推移について俯瞰してみます。

1.技術充足から差別化へ

戦後しばらくは、技術そのものが未発達でした。何が必要かは明確であり新規技術を開発すれば、ビジネスができました。この頃はシンプルな開発プロセスがあればよかったのです。そして20世紀半ばになると、マーケティングの概念が広く普及します（Kotler, Philip (1967). Marketing Management: Analysis, Planning and Control. Englewood Cliffs, N.J.: Prentice-Hall。競合他社の技術開発も進み、市場の中で勝ち続けるためにはマーケティングの概念が必要になってきたのです。このため開発プロセスではマーケティングあるいは企画と言う段階が重要視されます。

図1. 技術開発イコール新ビジネスだった昭和の時代

図2. 競合に勝たなくてはビジネスにならなくなった

「不足を埋めること」だけではなく、「より良いもの」に移行したこの頃人々の関心に対応するため、開発プロセスのより早い段階に新しい機能が生まれたわけです。

2.更に新たな価値を探して

21世紀にかけて技術が十分に供給されるようになると、ユーザは欲しいものを言語化できなくなり始めます。ユーザに次に作るもの(WHAT)を設定されて、いかに作るか(HOW)に専念してきた企業は困惑します。
これは、関心の多様化が進むB2Cビジネスではもちろんのこと、効率化(HOW)一辺倒の価値観で進んできたB2Bビジネスの現場ではより大きな問題になったのです。実際に営業担当者と、顧客との間での会話は変化しました。例えば「こういうものが欲しい」と言ってくれていたお客様が、今は「ところで次は何をするのか。貴社はどう考えるのか」とベンダーに尋ねるようになっています。これは国内メーカの現場においても国内SIerにおいても、海外のユーザとの関係においても同様です。
ユーザの関心は「より良いもの」ではなく、「新しい価値」の提供に移り始めました。既存企業は、従来のやり方だけでは方向性を決めかねるようになったのです。
ユーザが声に出していなかったにもかかわらず、iPhoneというイノベーションやってのけたスティーブ・ジョブズ氏は例外ですね。既存企業で常時彼のような人材を望むことは難しいでしょう。またまだ既存企業では個々人の発想に頼ることが難しい仕組みにもなっています。
そこで企業に提供されたのが「デザイン思考（的アプローチ）」でした。

麗しき誤解
デザイン思考の本質は徹底的なユーザ中心主義とFail Fastの精神です。これが企業で流行った理由は、実はIDEO社の巧みなマーケティング戦術によるところが大きいかもしれません。しかしもうひとつは、個々人に頼れない既存企業において手法が「手順・フレームワーク」に落ちているように見えたことに大きな意味があったからでしょう。
HOWにこだわる厳格なプロセスを持つ組織が、掴みどころのない「新しい価値」探しに直面した時、掴みどころのないユーザの真のニーズ探索を手順で示してくれる（と考えた）デザイン思考的アプローチは、渡りに船、銀の弾丸に見えたのです。

我々は、組織というものの裏の関心を知るため、とあるメーカの開発現場の各種階層にDepth Interviewをかけさせてもらったことがあります。

まずオモテの関心とは次のようなものです。
経営層と開発マネージャーらは、自分たちのミッションは効率経営にあり、そのためには開発は一定の手順になっていなくてはならない、と考えていました。手順通りに正しく物を作ることにかけては卓越しているからです。また現場は手順を与えない限り動かないと考えていた経営層もいました。
当初デザイン思考を流行らせたオモテの関心からくる誤解とは次のようなものであったと考えています。

オモテの関心が見たかったもの：
1. 手順に落ちているから実施できる（実は欠けているピースがあった）
2. 「イノベーション＝他社を凌駕する何かすばらしいもの」を起こす手法である（誤解。イノベーションはプロセスでは起こせないし、元来デザイン思考はそのための方法論ではない。）
これは、自分が見たいように状況を見る、オモテの関心が引き起こした誤解でした。

図3.デザイン思考でイノベーションが起きると信じようとした

そして、運用に入った後、ウラの関心が、一気に期待の方法論にネガティブな評価を与え始めるのです。

商品開発企画部門および開発部門の裏の関心
前述のとおり、我々は以前老舗メーカの商品企画開発部門の人々の関心を探り、彼／彼女らの目線を手に入れるための深いリサーチをかけました（Depth Interviewやそれに続くPERSONA法による）。
Depth Interviewでは、個人の想いにフォーカスして、設定したテーマ周辺の関心がどこにあるのかを事後に解析します。また、対話の論点を引き出すため、独自のカードによるワークなども行なっています。

図4. 欠落が感じられるリアルな現場観から見えた欠落

ペルソナの制作過程から浮かんできた現場マネジメントのオモテの関心とは、顧客理解の重要性とその分野のスキル不足の認識や、プロダクト品質至上主義、学習機会の重要性でした。しかし同時に解析から見えた現場のウラの関心は、スケジュール死守であり、様々な調整業務こそが重要、そして学習はOJT以外ありえないという感覚でした。原因の解析はここでは省きます。より不確実性の高い創造的な活動にリソースを割く余裕がなく、オモテの関心からは、魔法のツールに見えたデザイン思考的アプローチも、ウラの関心からはスケジュールを遅延させる外乱に見えてしまったのです。
オモテの関心は欲していながら、ウラの関心がこれを嫌う、という状態の中、藁をもすがる思いで導入実施しようとしたのがデザイン思考的アプローチだったと言えます。
このような形ばかりのユーザ中心主義が長く続くことは、現場にどのような影響を与えたでしょうか。

3. デザイン思考の否定と、迷い再び

デザイン思考的アプローチは、方法論になっていたために20世紀型の効率重視開発と、その後の新しい価値観との橋渡しになる可能性を持っていたと思います。
そこで、国内でも大手メーカ各社では、デザイン思考を活用しようという人たちが早くから活動をしてきています（仮にデザイン思考家と呼ぶ）。しかし、この数年、彼／彼女らデザイン思考家が集まると、いつも同じ問題が話に出てくることに気付きました。問題定義はこう移り変わったのです：

①デザイン思考の理解を進めるには？
②デザイン思考の導入を進めるには?
③デザイン思考をうまく実施するには？
④そもそもデザイン思考を使える状態であるには？

プロジェクトメンバーがデザイン思考的アプローチを使える状態にない、というのがデザイン思考家らの、当時(2年ほど前)の驚くほど共通の認識でした。
デザイン思考の根底にあるのは徹底したユーザ中心主義とFail fastの精神であることは前述したとおりです。ユーザの真の関心に共感することでユーザの目玉（視点）を得て、その目線での価値を探るアプローチです。方法論を導入をしている組織ではその点には合意していたはずです。
ただ、前述の調査結果のような矛盾する関心の中で、形だけのユーザ中心を強いられた結果、現場から何かが失われていたように思えます。

実は、開発者あるいは価値提供者側に「軸」がない、というのが方法論導入推進者共通の認識でした。「ところであなたは何がしたいんですか」という問いに答えられなくなくなっていました。これが、前項で記述した、困惑する現場が失ったもの；「軸」、「ビジョン」あるいは「意志」と言ってもいいものです。失われつつあったのは「自分」を出す機会や意志でした。
これは、佐宗邦威氏が「直感と論理をつなぐ思考法」や「ひとりの妄想で未来はかわる VISION DRIVEN INNOVATION」[*6] で指摘した「妄想」と重なる概念だと思います。
デザイン思考のさらに手前で、それを使いこなせる状況を整える必要が出ていたのです。

そこにはユーザーの考えに共感し、開発者の想いに迫るフェイズが改めて必要です。私はそれを、立場の異なる二者を深く探索するフェイズ"Creative Research™"と呼び、今最も必要とされている機能だと考えています。

（Episode IIへ）
(本稿は、2019年の夏にEssential Management School で書いたものをnote用に転載したものです)