どうでもいい話題も、図にすればなぜか深く見えてくる。
この番組は頭の体操、時々悪ノリ。
見えるようで見えない構造をスッキリ整理する、そんな図解系ラジオです。
突然ですが皆さん。
僕って天才なんですよ。
自分で言うのもなんですけど、たまに「山本さんって天才ですよね」みたいな空気になることがあるんですよ。もちろん冗談っぽく言っている部分もあると思うんですけど、でも実際初めて聞く話でも「ああ、たぶんこういうことだな」と見えてしまう場面はわりと多いです。
じゃあそれって、才能？
生まれつきの勘の良さ？
ここ最近ずっと考えていたんですが、
ようやく自分の中でしっくりくる言葉が見つかりました。
それが、「1を聞いて10を知る」ということです。
僕はこれまで、システム開発の文脈で「要件推理」という言葉を使ってきました。
一般的には「要件定義」と言われるような場面でも、僕の仕事では、最初から情報がきれいに揃っていることのほうが少ないんです。特に災害現場に関わるような仕事では、状況は切迫しているし、関係者も多いし、そもそもITに詳しい人ばかりではありません。
だからこちら側が、相手の言葉をそのまま受け取るだけじゃなくて、
「この人は本当は何を必要としているんだろう」
「この背景には何があるんだろう」
と考えながら組み取っていく必要があります。
僕がやっていたのは、まさにそれ。
少ない情報から全体を想像し、足りない部分を補いながら前に進めていく。
つまり、「1を聞いて10を知る」ということだったんです。
じゃあ、そのために僕は何をしているのか。
整理してみると、すごくシンプルでした。
全体像をつかむ
「1を聞いて10を知る」と言っても、いきなり10が見えるわけじゃないです。
最初にやるのは、とにかく全体像をつかむこと。
10の状態が分からなければ、何が足りないのかも分からない。
だからまず、「どんな情報が揃えば全体が見えたことになるのか」を自分の中で作ります。
そのときに使っているのが、フレームワークです。
フレームワークというと難しく聞こえるかもしれませんが、要するに「考えるための型」みたいなものです。
たとえば、基本的なものだと5W1Hがあります。
誰が、いつ、どこで、何を、なぜ、どのように。
あれだけでも、かなり使えます。
たとえば「避難所の管理システムを作ってほしい」と言われたとします。
これだけだと、情報はほとんどありません。
でも5W1Hの形に当てはめると、
「誰が使うのか」
「どこで使うのか」
「何のために必要なのか」
「どういう場面で動くのか」
と、考えるべきことが見えてきます。
つまり、最初にやるべきことは、答えを出すことじゃないんです。
全体をつかむための枠を作ることなんです。
経験で埋める
枠ができたら、次は中身。
ここで使うのが、自分の経験や過去の事例。
たとえば災害対応のシステムの話なら、過去の地震や避難所運営の状況を思い出しながら、「おそらく今こういうことが起きているだろうな」と想像していく。
災害が起きた直後なら、避難所はすでに立ち上がっているかもしれない。
利用者の把握が必要かもしれない。
現場ではすぐ使えるものが求められているかもしれない。
そうやって、断片的な情報に経験を重ねていくことで、少しずつ輪郭が見えてきます。
ここで大事なのは、何もないところから勘で当てることじゃなくて、自分の中にある知見を使って仮説を立てることです。
この積み重ねがあると、話を聞いた瞬間に「たぶんこういうことだな」と反応できるようになります。いわゆる“頭の回転が速い”ように見える人って、こういうことを無意識にやっているんじゃないかと思います。
分からないことは、ちゃんと聞く
経験だけでは埋められないことも当然あります。
避難所は何箇所あるのか。
実際にシステムを触るのは誰なのか。
どの機能が本当に優先されるのか。
こういうことは、想像だけでは分かりません。
だから分からないことがあったら素直に聞く。
有識者に聞く。
現場の人に聞く。
詳しい人を捕まえて教えてもらう。
これは割と大事なポイントです。
仕事をしていると、「こんなこと聞いたら恥ずかしいかな」とか、「自分で考えないといけないかな」とか、そういう気持ちになることがあるじゃないですか。
特に若い人ほど、その感覚は強いかもしれません。
でも、考えても分からないものは分からない。
だったら、早く聞いたほうがいい。
僕はそこをあまり引きずらないタイプで、「いや、これ俺が考えても分からないし」と割り切って聞きにいきます。
プライドより、前に進むことのほうが大事だからです。
結果的に、その一回のヒアリングが次の理解にもつながります。
前に医師会でこういう話を聞いたから、今度別の団体から似た要望が来たときにも「あ、たぶん同じような背景だな」と想像できるようになる。
そうやって経験値がたまっていくわけです。
これが「要件推理」
こうして整理してみると、僕がやっていたことはすごく明確でした。
まずフレームワークで全体像をつかむ。
次に、経験や知見で空白を埋める。
最後に、分からないところはちゃんと聞く。
この流れがあるから、少ない情報でも前に進める。
僕の中では、これが「要件推理」の正体なんだと思います。
今まで「要件推理って何ですか」と聞かれても、うまく説明できなかったんです。
なんとなく感覚では分かっていたけど、言葉にできていなかった。
でも今回あらためて整理してみて、ようやく腹落ちしました。
僕はたぶん、最初から全部を知っているわけじゃない。
ただ全体を見るための型を持っていて、そこに経験を当てはめて、足りないところを埋めにいっているだけなんです。
そう考えると、「天才」と言うより、手順の問題なのかもしれません。
どうしたら「1を聞いて10を知る」に近づけるのか
僕は、最初の一歩としては5W1Hで十分だと思っています。
もちろん世の中にはいろんなフレームワークがあります。
ビジネスモデルキャンバスもあるし、カスタマージャーニーみたいな考え方もある。でも、最初から全部覚えなくてもいいです。
まずは5W1Hで考える癖をつける。
それだけでもかなり変わると思います。
たとえば「来週会食があるから、お店を押さえておいて」と言われたときも、ただ店を探すだけじゃなくて、
「誰と行くのか」
「どこがいいのか」
「予算はいくらか」
「個室が必要か」
「どういう場にしたいのか」
と考えられるようになる。
こういう小さな場面で練習していくと、だんだん「1を聞いて10を知る」感覚が身についてきます。
もっと難しいテーマになってきたら、その仕事に合った別のフレームワークを使えばいい。
でも入口としては、5W1Hで十分。
僕はコンサルの経験もあるので、フレームワークで情報を整理することに慣れているんだと思います。だから災害現場のように不確実性の高い状況でも、わりと落ち着いて全体を見にいける。
でもこれって、何か特別な能力というより、考え方の型を持っているかどうかなんですよね。
頭の回転が速い人。
察しがいい人。
仕事ができる人。
そう見える人たちも、実は頭の中で似たようなことをやっているんじゃないかと思います。
つまり、「1を聞いて10を知る」は、才能だけの話じゃない。
ちゃんと再現できる方法なんです。
最後に
今回、自分の頭の中を言語化してみて思ったのは、
分かる人ほど感覚で済ませないほうがいい
ということでした。
自分にとって当たり前になっている思考ほど、言葉にしてみる価値がある。
なぜなら、それが誰かにとってのヒントになるかもしれないから。
僕の中では、「1を聞いて10を知る」というのは、センスの話ではありません。
全体像をつかむこと。
経験で埋めること。
分からないことを聞くこと。
この3つを丁寧にやることです。
だからもし「自分は察しが悪い」とか「頭の回転が速くない」と思っている人がいたとしても、悲観しなくていい。
まずは5W1Hからでいい。
型を持つだけで、見える景色はかなり変わります。
そうして少しずつ「1を聞いて10を知る」に近づいていけるんじゃないかと思います。
