#マーケティング #問い #道具
ドラえもんとキテレツ大百科。
同じ藤子･F･不二雄の作品でありながら、主人公の ｢問題への向き合い方｣ はまるで違います。この違いは、ビジネスにおいても示唆に富みます。
今回のテーマは、漫画に学ぶ問題解決です。
のび太とキテレツ
一話完結で道具が登場する 2 つの漫画。｢ドラえもん｣ と ｢キテレツ大百科｣ は、問題解決のプロセスは対照的です。
のび太とひみつ道具
ドラえもんの漫画の単行本を思い浮かべると、たとえばこんな展開が典型的です。
のび太は学校から帰るなり、ジャイアンに殴られた、スネ夫にバカにされた、テストで 0 点を取った、といった不満を抱えて部屋に転がり込みます。｢どうしてボクばっかりこんな目に遭うんだ｣ と嘆きながら、最後は決まってドラえもんにすがりつきます。
ドラえもんは最終的にはひみつ道具を取り出し、のび太に渡します。
道具を手にしたのび太は、一時的に問題を解決しますが、のび太は次第に調子に乗ってしまいます。本来は一度きり使うべき道具を乱用したり、自分の都合だけで使い続けたり。その結果、道具は裏目に出てしまいます。
結局はジャイアンやスネ夫にまたやられたり、ママにこっぴどく叱られるなど、もっとひどい目に遭う、というオチがつきます。
キテレツと発明道具
一方で ｢キテレツ大百科｣ は、出発点から少し様子が違います。
日常生活の中で ｢これが不便だ｣ ｢もっとこうなればいいのに｣ という小さな問題が起こりますが、ここで主人公のキテレツは、誰かに泣きついたり、完成した答えを求めたりしません。
代わりに、｢これはなぜ起きているのか｣ ｢どこを変えれば解決できるのか｣ と自分で考え始めます。そして、先祖である奇天烈斎 (きてれつさい) の発明書を開き、過去の知恵をヒントとして参照します。
発明書に書かれているのは、発明品の説明なので、実際の完成品が目の前にあるわけではありません。キテレツはそれを読み解きながらどう作るかを考え、材料を集め、自分の手で発明品を作り上げます。
完成した発明品は、実際に問題を解決します。しかし同時に、想定外の副作用、例えば、便利すぎる道具が原因で周囲が怠惰になったり、騒動が大きくなったりします。また、ブタゴリラやトンガリたちが、キテレツの発明品を勝手に持ち出したり、本来の目的とは違う使い方をして状況を悪化させたりする事態が起こります。
そして、キテレツは単に ｢失敗した｣ で終わらせず、その都度立ち止まって ｢なぜこうなったのか｣ を考えます。ここには ｢作った経験｣ ｢失敗から得た学び｣ が残ります。
解決より前の問題設定
ビジネスで成果を分けるのは、派手な解決策そのものよりも、何を問題とみなすか、問題をどう切り取るかという問題設定にあります。
キテレツ大百科では、キテレツは次の順番で動いています。
まず、目の前の困りごとを現象として受け止め、次に ｢なぜ起きているのか｣ ｢どこを変えれば良くなるのか｣ という問題を構造化します。
興味深いのは、のび太の物語は ｢困ったら外 (ドラえもんのひみつ道具) から解決策がやってくる｣ という構造です。それに対してキテレツの物語は、困ったら自分が引き受け、考え、作ることから始まります。
ドラえもんのひみつ道具は手段がのび太の外から供給されるのに対して、キテレツの発明品は手段がキテレツ自身から生まれます。だからキテレツの物語は、成功しても失敗しても、経験が自分の資産として残ります。
逆に、のび太的な振る舞いがビジネスで起こるとどうなるでしょうか。
問題が起きた瞬間に、誰か (上司, 他部署, 外部ベンダー, AI ツール) にどうにかしてもらうことを前提に動くでしょう。確かに解決は早いかもしれませんが、次に同じ類の問題が起きたとき、また同じ頼り方をするしかなくなります。
キテレツの物語展開の本質は、問題を自分が主体的に引き受け、問題設定をすることから始め、その問題に合う解決策をつくるという、再現性のある問題解決を示している点にあります。
ビジネスへの応用
キテレツ的なアプローチは、3 つの形でビジネスに応用できます。
[応用 1] ｢困りごと｣ を ｢問い｣ に変える
ビジネスの現場では、｢売上が落ちた｣ ｢顧客が他社製品を買った｣ ｢安売りをしないと買ってもらえない｣ ｢クレームが減らない｣ などの困りごとが日々発生するものです。
ここで、もし ｢のび太型｣ に寄ると、いきなり道具 (施策) を求めてしまいます。しかし ｢キテレツ型｣ は、施策の前に問いを考えます。
たとえば売上が落ちたとき、いきなり広告予算を増やすのではなく、
- そもそも ｢売上｣ という数字のどの要素が変わったのか
- 新規顧客が減ったのか、既存顧客のリピート購入がされないのか
- どの顧客セグメントで売上が落ちているのか
- 客単価は下がっていないか
- 競合の動きか、チャネルの変化か、季節性か
こうした問いを立てて、売上減という事象を分解していきます。
キテレツ的にやるなら、困りごとをそのまま扱わず、必ず問いに翻訳します。良質な問いがあるからこそ問題設定が的確になり、問いが明確で鋭くなるほど、解決策は効くものになるでしょう。
反対に、問いが曖昧だと解決策は派手でも問題は解決しません。問題からズレた施策は、コスト増･疲弊･ブランド毀損という形で "オチ" がつきます。
[応用 2] 解決策を自らつくる
次に重要なのは、解決策のつくり方です。
キテレツは完成品を受け取ることはしません。発明書というヒントを参照し、自分で作り、試します。
ビジネスで言えば、過去の事例、成功パターン、フレームワーク、他社のベストプラクティスは、すべて奇天烈斎の発明書みたいなものです。参考にはなりますが、そのままコピペしても、同じように効くとは限りません。
キテレツ的なアプローチでは、自社の条件に合わせて組み替えることが必須です。フレームワークをただ当てはめるのではなく、現場の制約の中で機能する形に設計し直します。その結果として施策が生まれるわけで、施策はもらうものではなく、問題という固有の状況に合わせてつくるものです。
AI の活用も同じです。AI をドラえもん化させると、｢とりあえず答えを出して｣ で終わり、再現性が育ちません。キテレツ化させるなら、｢問いを磨く｣ ｢仮説を立てる｣ ｢検証設計をする｣ という、主体的な問題解決の一部として AI を使います。
同じ道具でも、使い方次第でのび太にもキテレツにもなれるわけです。
[応用 3] 小さく試して学習する
キテレツの発明品は、決して最初から完璧ではありません。想定外の副作用が出たり、周囲が使い方を誤まったりして、トラブルも起きることも普通にあります。
ビジネスでの現実の施策も同じです。完璧な計画を作ってから大きく実行するより、早い段階で小さく試し、想定外を回収していくほうが成功確率は上がることでしょう。
キテレツの発明品は、ビジネスの言葉で言えばプロトタイプです。プロトタイプは完成品ではなく、｢学習のための道具｣ です。発明品というプロトタイプを使うことで、問題設定が合っていたか、制約を見落としていなかったか、どこにリスクが出るかを考え、たとえ失敗をしたとしても学ぶことができます。
ビジネスへの示唆としては、施策を決定事項として扱うのではなく、学習するための仮説検証として扱うことです。
マーケティング施策でも、営業トークでも、プロダクト開発でも、小さくつくり、早く実行し、すみやかに改善することで、キテレツ的な学習サイクルが回り始めます。
のび太とキテレツに学ぶ問題解決
ここまでキテレツを持ち上げると、のび太のやり方は全然ダメに見えるかもしれません。しかし、のび太的振る舞いにも意味があります。
それでも、のび太的アプローチはダメではない
のび太は ｢困っている｣ ｢助けて｣ とドラえもんに言えるのです。問題をひとりで抱え込んで事態をただ悪化させるよりも健全です。ビジネスでも、SOS を出せる人は強いです。
ドラえもん的な外部サポート (上司･他部署･パートナー･ツール) に頼ること自体は悪いことではありません。重要なのは、頼り方が主体性の放棄になっていないことです。
のび太型の落とし穴は、解決策の獲得が目的化して、問題設定が育たないことにあります。それに対してキテレツ型は、｢問題設定 → 解決策 → 試作 → 学習｣ というプロセスが進み、経験が知見として蓄積されます。
ビジネスパーソンとして目指したいのは、ドラえもんに頼ったりひみつ道具を使わないことではなく、ドラえもんという存在をキテレツ的に使うことです。問いは自分が立て、設計も自分が担い、外部はその補助輪として使うのです。
困ったときに、いきなり ｢道具｣ か ｢問い｣ か
キテレツ大百科を、ビジネスのケーススタディとして読むおもしろさは、主体的な問題設定と問題解決が、毎回わかりやすい形で描かれる点です。
困りごとが起きたとき、解決策を探しに行く前に、まず問いをつくる。次に、その状況での制約下で機能する形に設計し直す。小さく試し、想定外を学びに変え、次の改善へつなげる。
仕事で成果を出す人がやっていることを一言で言うなら、派手な打ち出すよりも、そもそもの問題は何かを徹底的に掘り下げていることです。キテレツは、それを毎回やっていると見ることができます。
困ったときに、まず ｢道具｣ を求めるのか、それとも ｢問い｣ をつくるのか。困難な状況で、自分一人で抱え込まず ｢助けて｣ と言えるか──。ドラえもんとキテレツ大百科は、そんなことを教えてくれる作品です。
まとめ
今回は、のび太とキテレツの問題解決アプローチの違いから、ビジネスへの示唆を考えました。
最後にポイントをまとめておきます。
- 問題が起きたとき、すぐに解決策 (道具) を求めるのではなく、まず ｢何が本当の問題か｣ ｢問題をどう定義するか｣ という問いを立てることが大事
- フレームワークや成功事例は参考にしつつも、自社や自分の置かれた制約条件の中で機能する形に設計し直す
- 完璧な計画を待つより、小さなプロトタイプで早く試し、学ぶサイクルを回す。失敗や想定外を学習の機会と捉える
- 外部の支援に頼ること自体は悪いことではない。主体性を手放さず AI なども補助輪として活用する。問題設定と設計を自分が担う姿勢が重要
- 困ったときにいきなり ｢道具｣ を求めるか、それとも ｢問い｣ を掘り下げるかの選択が、長期的な成長と成果の差を生み出す
