ユニファ開発者ブログユニファ開発者ブログユニファ株式会社プロダクトデベロップメント本部メンバーによるブログです。プロダクトマネージャーさいしょにはじめまして、プロダクトデベロップメント本部で副本部長をやっています西川です。UniFaアドベントカレンダーの23日目、メリー・クリスマス・イブイブの記事をお届けします。宮本茂さんの名言のひとつに、アイデアとは複数の問題をいっぺんに解決するものという言葉があります。2008での)初接触から今に至るまでずっと深い共感を覚え続け、また、仕事の仕方に強い影響を受け続けてきた、私にとっていわゆる「座右の銘」のひとつです。「なぜ、そうなのか?」「だからどうすればいいのか?」を明確な言葉にすることができないままでいました。それが先日、散歩中に何の脈絡もなく突然、「あ、これだ」と自分なりの理解が急にクリアな言葉・論理・映像として浮かんできました。どこかでいつか文章としてまとめておきたいな...と思っていたところで、社内で今年もアドベントカレンダーやるよという声が上がってきました。いうわけで本日のテーマは、宮本さんの名言への自分なりの解釈を記したいと思います。茂さんのアイデアについての考え方は、本家・本元の任天堂さんが糸井重里さんをインタビュワーに招く豪華体制で記事化されています。そちらもぜひご覧ください。ユニファでは今、モノづくりの仲間を大絶賛募集中なので、こちらもぜひご覧ください。「その時」になってからの本気、では遅い。「なぜダメなのか」の理由を整理して、引き出しにしまっておく。さいごにアイデアはなぜ複数の問題を一気に解決するのか?さて、最初にシンプルな状況を考えてみましょう。シンプルな状況:1つの動機に1つの計画ある動機が1つあり、その動機を叶えるための計画が1つあったとします。ここでの動機aから計画Aの発想は、「当然」と言っていいレベルの単純なもので、この計画Aをアイデアと評する人はあまりいないのではと思います。基本的に考慮しなければいけない動機が1つしかない場合は、動機からシンプルに考えついたことを実行するだけでよく、そこにアイデアは必要ありません(現実ではあまりない状況だと思います)。次にもう少しだけ複雑な状況を考えてみましょう。シンプルでない状況:2つの動機からそれぞれ出た計画が互いに矛盾この状況だと、それぞれの動機からシンプルに考えついた計画を実行するだけでは問題が発生してしまいます。計画Aと計画Bの間にジレンマ、矛盾が生じています。この状況で、動機aも動機bも満たすような計画Cがあるなら、その計画Cはアイデアと呼べるのではないでしょうか。アイデアが生まれた状況:動機aと動機bの両方が満たされる計画Cの例としては「海外ゲーマーが多数参戦するオンラインゲームで会話を楽しみつつ遊ぶ」などが挙げられると思います。矛盾の存在はアイデア存在の必要条件シンプルに考えついた計画を実行するだけで、何の矛盾もなく満たしたい動機すべてを満たせるのであれば、アイデア自体の必要性がありません。なく、現実世界の多くの状況でそうであるように、動機が複数あって、それらを満たそうとした時に何らかの矛盾が発生してしまうからこそ、アイデアが必要になります。そのような「矛盾」は、"矛"側と"盾"側それぞれに最低1つずつの(相手方に対する)問題点の主張を必然として持っています。ものでなければなりません。動機に対して計画が思いついてない場合も考えられますが、そのような場合、制約事項を一切考慮しなくて良いのであれば計画の発案はすこぶる簡単なはずです。動機に対して計画が思いついてない場合のほとんどは、複数の動機をうまく満たすような動機が見つかっていないか、単に知識不足のいずれかになる...というように(自分の中で)整理しています。すればアイデアが出るのか?アイデアがなぜ複数の問題を一気に解決するのかについては自分なりの理解が確立できたとして、関心事としてはやはり「そのようなアイデアはどのようにすれば出るのか」だと思います。これは短く語るのが難しいテーマですし、何より、必ずいつもアイデアが出るのであれば苦労はありません。「アイデアを出すこと」を「矛盾を解消すること」と捉えると、ひとつの指針は見えてくると思います。矛盾が生じているという状況は、上のようなベン図で表現できると思います。aが成立しないさて、この図を立体的に捉えて立つ場所を変えると、下図のような視野を手に入れることもできます。矛盾の発生を回避した視野これです。この図が、今回お話したいことの肝1です。Observe.アイデアを生みだす最良の方法は「どうすれば良いか」を考えることではないかもしれないと、最近感じています。動機が満たされる条件と問題の発生条件をなるべく厳密化・明確化しながら視点を様々に考えながら「問題の発生条件を回避しながら動機を満たせる」領域を執念深く探す...という行為が、実は良いアイデアを世に出す(実装やうまく行かなかった時の再挑戦コストも計算に含めた場合の)最短ルートなのではないかと。解決方法よりも問題の発生条件の方がより重要で、発生条件が分かれば解法自体は自然でシンプルな発想が割と勝手に浮かんでくる...という考え方です。上記は私が勝手にたどり着いた個人的な考えでしかないのですが、実は今回のブログ執筆にあたって改めて宮本さんのインタビュー記事を読んでみると、宮本さんも同じように考えている(かもしれない)と思しき発言を見つけました。なにかを考えるときに、ぼくは、まず、「できないことリスト」をつくろうとする傾向があるんです。ファミコンっていうハードでは、なにができて、なにができないのか。「なにができないか」っていうことを、たくさん知ってることはすごく、ぼくにとっては大事なんです。茂ファンとしては、勝手に「ああ、宮本さんも俺と同じように考えている(かも)」と悦に入っています。くどいかもしれない註釈ですが、上記は私なりの解釈であり、宮本さんが「解決方法よりも問題の発生条件の方がより重要」とか仰ったわけではありません。矛盾が発生しないところを見出すためには、さまざまな視点で問題を見てみる必要があります。状況突破力の鍵となってきます。すればそのような”使い物になる”視点を数多く自分の中に蓄積できるのでしょうか。「その時」になってからの本気、では遅い。最初に語らせていただくのは視点の量の話です。(量が質を作るという言葉が、私は好きです)下図は、「視点」を獲得していく量を時間の経過の中でグラフに描いたものです。時間経験の中での「視点」獲得量これです。この図が、今回お話したいことの肝2です。注目して欲しいのは、赤(R)の領域と緑(G)の領域の違いです。緑はグラフ終盤でものすごい本気を出して視点の獲得量を増やしており、その期間での視点獲得量は赤を大きく突き放しています。アイデアの創出力)は赤の方が圧倒的に多いという点です。仮に一時的に常人の3〜4倍のがんばりを見せたとしても、コツコツと積み重ねた鍛錬から見れば何分の1かの視点(アイデア創出力)しか発揮できません。それに普通、人は3〜4倍もがんばることはできません(8時間労働の3倍は24時間労働です。一方で、「その時が来たらがんばる」ことに比べて「コツコツと視点を増やす努力をし続けておく」ことの利点は時間を長く取れることですが、かけた時間は3倍にも4倍にも、10倍にも20倍にもすることができます。時間をかけるだけで毎回の視点獲得量が少なければ青(B)のグラフのようになってしまい、これは赤(R)の人にすら負ける視点の量しか出力できません。継続は力なりという言葉がありますが、私としては「継続したものしか力にならず、といって継続していれば力になるというわけでもない」と考えています。「その時が来てから急にがんばる」でもなく「単に自然に経験が積み重なるのを待つ」でもなく、意図的にコツコツと視点の獲得に務めることがアイデアの創出力を高めるのに重要だと思います。「なぜダメなのか」の理由を整理して、引き出しにしまっておく。次に視点の質の話、どうすれば良質で使い物になりやすい視点を自分に入力できるのか?です。(考えてない練習は嘘をつくって言葉が、私は好きです)これまで見てきたような「アイデア」の創出に役立つ視点とは、言い換えれば「問題Xの発生条件と問題Yの発生条件の間をすり抜ける穴が見える」ような視点とも言えます。そのような視点を使い物になる形で自分の中にたくさん持っておくには、「なぜうまく行かないのか」「どういう問題がなぜ起こるのか?」という知識を蓄積する必要があります。実際、このことについては宮本さんご自身が後進への助言として次のように語られています。すると、やっぱりね、「自分のアイデアはなんでダメなんですか?」って若い人に言われたときに、「それは自分で考えんと、ほんとはあかんやろ」と思うんですね。自分のアイデアがなぜダメなのか、自分で考えて、自分でダメな理由が整理できて、きちんと把握できると、それはいつか必ず使えるっていう。昔は「引き出しにアイデアを貯めなさい」ってよく言ったけど、最近は、「引き出しに、ダメだったアイデアを、『なぜダメだったか』という理由をつけてしまったらいいのちゃうか」と。ラベルにダメな理由を書いてね。いうものをいっぱい持っておくと、いつか、どこかの局面でラベルが剥がせるときがくるんですよ。「あ、いまはルールが違うから大丈夫」とかね、「昼間はダメだったけど夜ならこれでいける」とか。矛盾に遭遇した時に「つまり、アイデアを生み出す機会があるということだな」とタフなマインドで挑戦することができてその挑戦を支えるに十分なコツコツとした研鑽の蓄積が苦でないどころかむしろ趣味...といったモノづくりの仲間を、大絶賛募集中です。09:00関連記事2023-04-28ノーコードでマッチングサービスを作ってみたこんにちは、プロダクトマネージャーの田嶋です。(入門)研究開発部の浅野です。最近シフトスケジューリング問題に興味...2019-06-12自動計画器がねこを動かすこんにちは、サーバーサイドエンジニアのいいだです。12引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。