Blog 考え方

エンジニアの考え方 #2 - 「要するに?」と「たとえば?」を往復する

思考シリーズ第2回は、分解とセットで効く「具体と抽象の行き来」。例え話のうまい人が頭の中でやっていること、抽象的な指示に手が止まる理由、認識合わせが速くなる2つの質問について。

5 min read

例え話のうまい人は、何をしているのか

難しい話を、身近な例にすっと置き換えて分からせてくれる人がいます。あれは話術というより、頭の中である運動をしているのだと思っています。話の本質だけを抜き出して(上り)、それを聞き手の知っている世界に着地させる(下り)。

前回は「課題の分解」の話をしました。今回はその分解とセットで効いてくる、この上り下りの運動——具体と抽象の行き来を正面から扱います。

抽象とは「詳細を捨てる」こと

まず言葉の整理からです。「抽象的」というと「あいまいでふわっとした」という悪口に聞こえますが、本来の抽象は違います。抽象とは、目的に照らして詳細を捨てることです。

地図を思い浮かべてください。実物とまったく同じ、実物大の地図があったとしたら、完璧に正確で、完全に役に立ちません。道の細かい凸凹や建物の色を「捨てて」、道のつながりだけを残すから、地図は使い物になります。電車の路線図はさらに極端で、駅間の距離も方角もほぼ捨てて、「どの駅とどの駅がつながっているか」だけを残しています。距離を測りたい人には使えませんが、乗り換えを知りたい人には最強です。

つまり、何を捨てて何を残すかは目的が決めます。抽象化がうまい人は、あいまいにするのがうまい人ではなく、目的に合わせて捨てるのがうまい人です。

上りの質問 —「要するに?」

抽象への上りは、複数の具体を並べて共通の形をくくり出す動きです。合言葉は「要するに?」。

実は前回、郵便受けの例でこれをやっていました。人感センサー・開閉センサー・重量センサーという具体の候補を比べているうちに、「本当に知りたいのは、人が来たことでもフタが開いたことでもなく、中身が増えたことだ」がはっきりした——あれは候補という具体から、要件という抽象をくくり出す「上り」だったわけです。

仕事の場面でも同じです。たとえば不具合の相談が立て続けに3件来たとします。「画面Aの表示が遅い」「帳票Bの出力が失敗する」「夜間処理が朝までに終わらない」。個別に見れば3つの問題ですが、「要するに?」と一段上ると、「月末でデータ量が増えると耐えられない」という1つの構造が見えたりします。3つをバラバラに直すのと、共通の原因を1つ潰すのとでは、仕事の量がまるで違います。

上りは、構造をつかむための動きです。

下りの質問 —「たとえば?」

一方で、抽象のままでは何も動きません。「品質を上げよう」「AIを活用しよう」。方針としては何も間違っていないのに、翌日の自分が何をすればいいのかは1ミリも決まらない。抽象的な指示に手が止まるのは、あなたの理解力の問題ではなく、具体に降りていないからです。

そこで下りの合言葉、「たとえば?」を使います。「AIを活用する」→「たとえば?」→「会議の録音をAIに要約させて、人は確認だけする」。ここまで降りて、はじめて手が動きます。

下りにはもう1つ、大事な使い方があります。理解の検算です。人の説明を聞いたら、「たとえば、こういうケースはこうなるってことですか?」と自分の具体に置き換えて返してみる。合っていれば理解は正しいし、ズレていればその場で修正できます。分かったつもりのまま持ち帰るのが、一番高くつきます。

行き来して、はじめて役に立つ

大事なのは、上りと下りのどちらが偉いという話ではないことです。片方しかできないと、それぞれ典型的な失敗になります。

  • 上りっぱなし — きれいなまとめは作れるのに、実行に落ちない。評論になってしまう
  • 下りっぱなし — 目の前の個別対応はこなすのに、同じ問題が形を変えて何度も来る。モグラ叩きになってしまう

前回の「探す → なければ割る → また探す」のループも、よく見ると上下運動です。割るのは抽象のピースを立てる上り、探すのは世の中の具体的な道具を当てにいく下り。課題解決が進むときは、たいていこの往復が回っています。

会話でも同じで、認識合わせはほぼこの2つの質問でできています。指示を受けたら「要するに○○ということですか」と束ねて確認し、「たとえば△△の場合はどうしますか」と降ろして検算する。往復1回で、だいたいのすれ違いは潰せます。

まとめと次回

  • 抽象とは、目的に照らして詳細を捨てること。あいまいにすることではない
  • 上り「要するに?」で構造をつかみ、下り「たとえば?」で実行に落とし、理解を検算する
  • 片方だけでは評論かモグラ叩きになる。行き来してはじめて役に立つ
  • 前回の分解は「上ってから下る」の応用だった

ところで、この上り下りは、頭の中だけでやるには少し忙しい運動です。次回は、これを紙の上で目に見える形にする方法——連想をノードと枝でつないで、頭の中を地図にする話をします。ただの思考整理に見えて、その地図はやがて、オブジェクト指向という考え方の入り口につながっていきます。

※ 本記事の内容は執筆時点の情報であり、正確性を保証するものではありません。ご利用の際は免責事項をご確認ください。

Series / 連載

エンジニアの考え方

  1. 01 エンジニアの考え方 #1 - 課題を「分解」するところから
  2. 02 エンジニアの考え方 #2 - 「要するに?」と「たとえば?」を往復する(この記事)
  3. 03 エンジニアの考え方 #3 - 連想をノードでつないで、頭の中を地図にする
  4. 04 エンジニアの考え方 #4 - ノードの地図に関係の名前を付けると、オブジェクト指向が始まる
Share

Related / 関連記事

関連記事

Comments / コメント

コメント