「わからない」にぶち当たったときの分解チートシート
この記事はミライトアドカレ 14 日の記事です。
日々直面する「わからない」
どんなひとにも毎日いくつかの「わからない」があると思います。
わからないにぶち当たってしまったとき慌てず不安にならず着実に進むため、この記事ではわからないを分解するテクニックをまとめました。
自分が 10 年くらいなんとなくやってきたことを、それなりの形に言語化・構造化できたんじゃないかと思います。
わからないから抜け出せないひとの一助になれば幸いです。
巨大な「わからない」には立ち向かえない
わからないものを巨大なよくわからないものと捉えている限り、そのわからない感は払拭できません。
「Laravel わからない」
「弊社のレガシーシステムわからない」
「会議に出たけど何言ってるかわからない」
そうは言っても、いきなりわかるようには当然なりません。
じゃあどうするか。
わからないを「分解」しましょう。
というわけで、いくつかの分解方法と例を紹介します。
「わからないに立ち向かう具体的なテクニックというのがあるんだなぁ」と思ったら、ひとつでもいいので試してみてください。
自己解決の分解
闇雲にやってしまいがちな調査や学習をいくつかの観点で分解します。
必ずしも常にこういう流れでやるわけではないですが、考え方や前後関係はなにかの突破口になるかもしれません。
わからないにぶち当たっても動揺しないひとのひとつの例として、眺めてみてください。
どれを使ってみてもいいですし、同時にいくつか使ってみるのも可能です。
もちろん全部覚える必要はありません。
理解範囲で分解する [ わかる / わからない ]
どんな巨大なわからないでも、必ず「わかる」要素と「わからない」要素に分解できます。
たとえば「Laravel わからない」というサイズ感のままでは、輪郭や関連要素を捉えられません。
そんなときは、どんなに小さくてもいいのでわかる要素とわからない要素に分けていきます。
わからないところは自力で分解できないので、この段階での分解結果は完全な二分ではなくグラデーションがかかっています。
それでも、やってみると意外に「実はまず MySQL なんじゃね」のような当初の感覚とは違うポイントが見つかることも珍しくありません。
分けたあとのわかる要素は、次のわからないにぶち当たったとき活かすためいくつかの軸で分析します。
次の分解
- → 知識の領域で分解する
- → 知識の抽象度で分解する
わからないほうの要素は、本格的に手をつける前に概要を調べてラベリングしておきます。
次の分解
- → 期限で分解する
ひと呼吸おいて「これってあれの仲間なのかぁ」とワンクッション挟むだけで、そのあと記事を読んだりするときのイメージが格段にしやすくなります。
僕はこの分類作業を「地図を作る」と勝手に呼んでいます。
期限で分解する [ いまやる / いまやらない ]
地図を作ったあとの話です。
ラベリングしておいたわからない要素の関係を整理します。
関係とは包含関係や新旧関係、対立 ( 比較 ) 関係などです。
それらが見えてくると、要素をさらに「いまやる」と「いまやらない」に分解できます。
これを決めることが、地図を作る目的のひとつです。
常にすべてのわからないを解消する必要は、実はありません。
そもそもそれは不可能です。
安心してやらない選択をしてください。
そして、いまやらないは「いつでもやれる」と「やらない」に分解します。
限られた時間でより優先されるべきことを選び、どんなに小さくても着実にクリアしていく構造を作れます。
なによりいまやらないを明確に決めると、めちゃくちゃ気持ちが楽になります。
僕はこの学習方針を「学習の遅延化」と勝手に呼んでいます。
地図作りと遅延化については、自分自身が数年前にやったものがあるので具体例として置いておきます。
( このときは時間が足りずに地図とか言っておきながら絵や図はないですが... 脳内では枝葉状に整理されていました )
インプットを分解する [ 調べる, 整理する, 考える, 理解する / 悩む ]
いざやるとなったときのため「調べる」「整理する」「考える」「理解する」「悩む」という単語について分解します。
- 調べる: 情報 ( の断片 ) を集める行為
- 整理する: 情報を考えられる形にする行為
- 考える: 整理された情報から仮説を立てる行為
- 理解する: 考えたことが自分の既存知識と統合され頭の中で再現可能になっている状態
- 悩む: 停滞している状態
こうして捉えると、悩む以外は一本につながっています。
| 単語 | 頭の中 | 具体例 | 成果物例 |
|---|---|---|---|
| 調べる | まだ煩雑 | コードを読む ログを見る 用語を検索する |
情報 ( 事実やデータ ) |
| 整理する | 情報の関係を把握する | 関係ある情報をまとめる 検索結果を取捨選択する 比較対象を見つける |
関係付けられた情報 |
| 考える | 答えを推論している | 何をするとどうなりそうか検討 何を用意すれば検証できるか模索 |
仮説 検証方法 具体的な対応策 |
| 理解する | 自分の知識に統合される | 説明できる 類似の別問題に応用できる |
再現性のある知識 自信 |
| 悩む | 明確な思考がない | あてもなくエラーを眺める なんとなく検索する |
なし |
「ずっと調べているのに全然わかった気がしない」と思ったら、整理に進みましょう。
理解はその先にあります。
「うーんどうしたらいいんだろう、なにをしたらいいんだろう、うーん」となってしまったら、調べましょう。
悩むは調べると整理するをすっとばして考えるに入ろうとすると陥りやすいです。
何を調べればいいかわからないときは、小刻みに調べると整理するを往復すれば着実に前進できます。
厳密にフェーズわけをする必要はないですが、インプットには段階があると知っているだけでかなり時間的・心労的な負荷が下がります。
知識の領域で分解する [ 一般的 / 独自的 ]
わからないことを「一般的」か「独自的」かという観点で分解します。
一般的な知識とは業界の慣例や技術として広く共有されているもので、ネットや書籍で知識を得られる領域です。
たとえば「Java の文法」とか「MySQL の操作方法」とか。
これらはネットや書籍を使って自力で探索可能です。
一方で独自的な知識とはプロダクトやチームに溜まってきた固有のもので、外部情報が存在しない ( 少ない ) か当てはまらない領域です。
たとえば「自プロジェクトにおける Java と Kotlin の使い分け」とか「このテーブルを参照するときはこのフラグをチェックしないとだめ」とか。
これらは正解を持っているひとに聞かないとどうしようもないみたいなことが多いです。
技術要素が絡んでいるからといって、一般的であるとは限らない点に注意が必要です。
このふたつは完全な二択ではなくある程度グラデーションがあるものの、おおむね「ネットで調べられそうか」で判断できます。
一般的なものはある程度自力で調べるのも大事です。
しかし独自的なものは、軽く社内ドキュメント検索をして解決しなければさっさと「だれか知りませんかー」って聞いちゃいましょう。
知識の抽象度で分解する [ 概念的 / 具体的 ]
一般的 / 独自的とは違う切り口として、わからないことを「概念的」か「具体的」かという観点で分解します。
概念的というのはたとえば「MVC モデル」とか「認証」とか。
一方で具体的な知識とはたとえば「Laravel」や「Spring Boot」とか「Auth0」や「Cognito」など。
この切り口も完全な二択ではなくある程度のグラデーションがありますが、おおむね「具体的な固有名詞があるかどうか」で判断できます。
概念的なものと具体的なものを往復できると、なんとなくどういうものかを把握するのがとても楽になります。
自分が持っているわかる要素を活用できます。
知識の領域と抽象度で２軸に分解する [ 一般的 / 独自的 / 概念的 / 具体的 ]
領域と抽象度の２軸分解はかなり実用的です。
この４象限のどの辺か一瞬考えるだけで、その後の行動が見えてきます。
- Transaction というのは時間をかけてじっくり学んでみよう
- とりあえず Git は最低限のコマンドだけ使えるように調べよう
- 今度プロジェクトの方針をリーダーに聞いておこう
- 運用手順はどこかにあるはずだからパスをさっさと聞こう
この２軸分解ができるだけで格段に迷いが減ります。
僕自身も 10 年くらいこのような判断基準を持ってやってきました。
マジでおすすめです。
アプローチで分解する [ 自分でやる / 自分でやらない ]
一般的と独自的の切り口に似ているところもありますが、少し違う角度から「自分でやる」と「自分でやらない」について分解してみます。
自分でやることが望ましいのは、たとえば以下のような状況のときです。
- 思考や行動自体に価値がある
- 本質的な理解に価値がある
- 明確な正解がなく、正解ではなく案を出す
一方で、自分でやらないと即決してしまうほうがいい状況もあります。
- 明確な正解があるが、再現性はない ( 背景の残っていない他人の決定など )
- 調べることと聞く ( 聞かれて答える ) ことのコスト的に、明らかに聞いたほうが楽な場合
過程と直接の答えどちらが本質的に価値のあるものか、と考えてみるといいでしょう。
もちろんこれも完全な二者択一ではないので、時間や２軸分解とセットで考えてみてください。
極端な一例として「さっき会議で画面共有されていた資料の保存場所がわからない」なんてときは、さっさと聞いちゃいましょう。
そりゃ共有ドライブの全ディレクトリを開けば自分で見つけられるでしょうが、何分何時間もただカチカチディレクトリだけ開いても得るものがないですね。
コミュニケーションの分解
誰かと話すときの要点のまとめかたをいくつかの観点で分解します。
セルフチェックの章に通じる部分も一部ありますが、話す相手は自分でもいいです。
「困っている自分が自分に相談してどうすんだよ...」と思うかもしれませんが、声に出したり文字で書いたりすれば十分な効果を得られます。
質問を分解する [ 問題, 現状, 目標, 要求 ]
質問にもテクニックがあります。
「エラーが直らず困ってる」というアラートを「問題」と「現状」と「目標」と「要求」という形に分解してみます。
まず問題として「ビルドができない」と具体的な困っていることをはっきりさせます。
沼にハマっているときは意外とできていないこともあります。
次に現状として「QR コードを表示したくてライブラリを追加した」と背景やこれまで検討したことなどをはっきりさせます。
聞かれたほうの考察が捗ったり、同じ検証の繰り返しを減らす効果があります。
それから目標として「ビルドを通して表示確認をしたい」と目指す状態をはっきりさせます。
調べ物に夢中で当初の目標を見失ってしまう、なんてことも結構ありがちです。
最後に要求として「一緒にエラーを見て解決してほしい」とやってほしいことをはっきりさせます。
「答えがほしい」「ヒントがほしい」「答えはわかるが理由を知りたい」「議論をしたい」など、実は望むアクションはまちまちです。
ふたつの「たすけてー」を並べてみると、見違えるようです。
- 「エラーが直らず困ってる」
- 「QR コードを表示したくてライブラリ入れたらビルドできなくなったので一緒に見て解消方法教えて」
これが上手にできるとものすごいスムーズに望む対応を引き出せるので、時間的・心労的にぐっと楽になります。
これは決して「かしこまれ」「事前準備をしろ」「気安く聞くな」という話ではありません。
聞かれたほうも優先度や内容の重さなどがわかるので、いつどうやって回答しようか決めやすくなります。
そうすると「ちょっといそがしいけど、それくらいなら今答えちゃうか」なんて対応をしてくれるかもしれません。
結局自分のためなんです。
きっちり説明できなくても、どれかひとつだけからでも大丈夫です。
アウトプットを分解する [ 事実 / 自説 ]
驚くほど自分でも混じっていることに気付きづらい「事実」と「自説」について分解します。
事実は誰でも同じように観測できる情報です。
- エラーやログ
- Slack のメッセージ
- 公式ドキュメント ( 一次情報 )
事実に無意識で混じりがちなのが自説です。
自説はさらにある程度客観的な情報にもとづいた「推測」と、主観や思い込みにもとづいた「憶測」にわけられます。
推測
- メソッドの引数を変えたら結果がこう変わったからここが怪しい
- Windows と macOS で試したら結果が違ったからファイル読み込みが気になる
- この発言とこの数字から、こちらの案がよさそう
憶測
- 自分のさっきのコミットのせいだと思う
- 普通はこうする
- 昨日までは動いていたから今日のデータが悪いはず
話を聞くひとは当然として、自分自身も事実を元に考える必要があります。
その事実に憶測が混じっていると、あらぬ方向に検討が進んでしまいます。
ひと呼吸おいて「ここまでの内容に憶測はあるか」と考えてみましょう。
もちろん憶測もあって大丈夫です。
ただ事実とは分けて扱いましょうということです。
セルフチェックの分解
最後にもう少しだけ、セルフチェックについて分解してみます。
セルフチェックが機能すると、ひとりでできることが爆増します。
状況を分解する [ What, Why, Who, When, Where ]
いわゆる 5W1H の 5W です。
これは自問自答にも使えます。
「What」は、何が起きているか。
自分が事実をどう認識しているか確認できます。
「Why」は、なぜそうなっているか。もしくはなぜそれが必要か。
自分が現状をどう認識しているか確認できます。
「Who」は、誰が関係しているか。
自分が確認するべき相手や助けを求める相手を認識できているか確認できます。
「When」は、いつからか。もしくはいつまでか。
自分がどれくらいの時間を使っていて、残り時間はどれくらいだと認識しているか確認できます。
「Where」は、どの環境・集団においてか。
自分が疑問をどの領域の問題と認識しているか確認できます。
たとえば「サーバのログイン方法がわからない」ときに、この 5W で自問自答してみます。
- What: サーバの SSH 接続情報がわからない
- Why: ログが見たい
- Who: 接続情報を知っている先輩か、構築したインフラのひと
- When: 今朝のエラーを調べなければならないので、なるはや
- Where: バックエンドシステムの共通基盤部分
ログが見たいなら Amazon CloudWatch Logs で見られるかもしれないので、そしたら What が変わります。
SSH コマンドを聞くのにわざわざインフラのひとを頼るのは大仰かもしれません。
共通基盤システムは問い合わせ窓口があり、ログを見るより担当者を探すことが優先かもしれません。
5W がすべてが整理できなければ、言い淀むところにヒントや突破口があるかもしれません。
セルフチェックをするときは、脳内でやると淀みなくできた気がしてしまうので口か手を動かしましょう。
ラバーダッキング法 [1] というのがあるように、ひとりごとやメモ ( アナログデジタル問わず ) の効果はばかにできません。
学習段階を分解する [ 無意識の無能, 有意識の無能, 有意識の有能, 無意識の有能 ]
学習の４段階と呼ばれる分類があります。
| 名称 | 状態 | 例 |
|---|---|---|
| 無意識の無能 | 知らないし、できない | Web FW が巨大な魔法に見えている エラーが出たなぁ以上を読み取れない |
| 有意識の無能 | 知ってるけど、できない | Web FW のある機能が気になる エラー原因がなんとなくわかる |
| 有意識の有能 | 意識すれば、できる | 疲れたり遅くても自力でコードが書ける 丁寧にたどればエラーを解決できる |
| 無意識の有能 | 意識せずとも、できる ( 当然のようにできる ) |
初見の技術でもすぐ応用できる エラーを類似の事象に応用できる |
意識せずともできるというのは「なんとなくやったらできちゃった」という意味ではありません。
自転車に乗るとき頭を使わないのと同じで、考えなくても当然できるという状態です。
こうして並べてみると、自走が成立しているのは有意識の有能からということになります。
つまり時間をかけるとある程度比例した効果が得られるのは、実は有意識の有能に片足をつっこんだくらいからなのです。
もちろんケースはさまざまですし無駄になるわけではありませんが、それより前の段階は時間をたくさん使うことが必ずしも解決や自信に直結するとは限りません。
逆に時間をかけて達成感が得られないと「こんなにがんばっているのに」「いくらやってもわからない」「不安が拭えない」といった焦燥感になってしまいます。
悩むの状態ですね。
有意識の有能にシフトするためにこそ、実はまずテクニックを使って自分の土台を作る必要があるのです。
- 悩みがちなひとは、調べるにシフトしてみる
- あれもこれもと手一杯になってしまうひとは、やらないことを決めてみる
- なんでもかんでも抱え込みがちなひとは、ひとに聞いてみる
- 沼にいると思ったら、たまにはひと呼吸つけてセルフチェックをしてみる
何度も繰り返しますが、この記事は「できるひとがやること」や「ただでさえ大変なのにさらなる負担を強いること」ではありません。
わからないにぶち当たって困っているひとこそ、ぜひ試してほしいテクニックとしてまとめています。
ちょびっとでも自分のために取り入れてみてください。
おわりに
数年なんとなく思っていたことを、重い腰を上げて図とテキストにしてみました。
AI と壁打ちできなければまとまらなかったと思います。
本文は自分で書いていますが、電車で何度も ChatGPT とドラフトを作り直してブレイクスルーを得たのは例年にない執筆体験でした。
次は弊社の tomo さん です。
-
アヒルのおもちゃにコードや問題を話しかけて説明すると無意識に抱えていた前提や論理の飛躍に気づけるというデバッグ手法 ↩︎
Discussion