エンジニアの考え方 #1 - 課題を「分解」するところから

このシリーズについて

言語の入門記事やツールの使い方は、世の中にいくらでもあります。このブログでも書いています。

ただ、実際に仕事をしていて「これがあってよかった」と感じるのは、技術の知識そのものより、その手前にある考え方のほうでした。課題をどう捉えるか、どこから手をつけるか、どう整理するか。誰も体系立てて教えてくれないのに、効き目だけは一番大きい。しかもこの考え方は、エンジニアの専売特許ではありません。

なので、自分の頭の整理も兼ねて、考え方の話を何回かに分けて書いてみることにしました。エンジニアではない人が読んでも分かるように書くつもりです。第1回は、その全部の土台になる「分解」の話です。

エンジニアの仕事はコードを書くことじゃない

いきなり身も蓋もないことを言いますが、エンジニアの仕事は「コードを書くこと」ではなく「課題を解決すること」だと思っています。コードは手段の1つでしかなく、実際、設定の変更や運用ルールの見直し、既にあるサービスの組み合わせで解決する課題もたくさんあります。コードを1行も書かずに終わる解決が、一番よい解決だったりする。

そう考えると、大事なのは「書く力」の前に「課題を扱う力」で、その最初の一歩が分解です。

課題は、そのままでは大きすぎて解けない

たとえば「家のネットが繋がらない」。誰でも経験があると思いますが、このままでは大きすぎて何をしていいか分かりません。「繋がらない」に対して「繋げる」とは返せないからです。そこで、ネットが繋がるまでの道筋を区間に割ります。

graph LR
    A[スマホ] --> B[Wi-Fiルーター] --> C[回線] --> D[見たいサービス]

割った瞬間、「どこまでが生きているのか」を1区間ずつ確認できるようになります。

• スマホ側？ — 機内モードになっていないか。そして「他の端末では繋がるか」。他の端末で繋がるなら、犯人はスマホです
• ルーター？ — ランプはいつも通りか。再起動したら直るか
• 回線やサービス側？ — 障害情報が出ていないか。これなら自分には直せないので、待つのが正解だと分かる

無意識に「他の端末で試す」をやっている人は多いと思いますが、あれはエンジニアがトラブル対応で使う「切り分け」そのものです。大きな1つの謎が、確認できる小さな質問の列に変わる。これが分解の効果です。トラブルに強い人は特別な勘を持っているわけではなく、この「解ける大きさに割る」動作が速いのだと思います。

ただ、これは「直す」場面の分解です。本当に効いてくるのは、むしろ「作る」場面です。

作るときの分解 - 郵便受けのスマホ通知

今度のお題はこうします。「自宅の郵便受けに郵便が届いたら、スマホに通知が来るようにしたい」。

最初の一歩は、実は分解ではありません。まず「そういう商品が既にないか」を調べます。「ポスト 通知 スマホ」あたりで検索すれば、投函されるとスマホに知らせてくれるポストや後付けのセンサーが見つかるかもしれません。それで満足できるなら、買って終わり。冒頭で「コードを書かずに終わる解決が一番よい」と書いたのと同じで、作らずに済むなら作らないのが、一番速くて確実な解決です。

ただ、既製品には不満が残ることもあります。値段が高すぎる。欲しい機能が微妙に足りない——通知は来るけれど「いま何通たまっているか」は分からない、とか。うちの郵便受けの形だと取り付けられない、とか。そうなって初めて、「作る」の出番です。そして、作ると決めた瞬間に必要になるのが分解です。

作ったことがなければ「そもそも何から考えればいいのか想像もつかない」となるはずですし、少し経験があると今度は「どのセンサーを買おうか」と、いきなり具体的な内容に飛びつきたくなります。実はどちらも最初の一歩は同じで、まず大まかに割る。この課題は、突き詰めると2つのピースしかありません。

graph TD
    A["検知する<br>郵便受けに何かが入ったことを、何らかの方法で知る"] --> B["伝える<br>それを、何らかの方法でスマホに届ける"]

「何らかの方法」のままでいいのがポイントです。全体の形が決まったら、「検知する」の具体候補を並べて比べます。

• 人感センサーで、郵便受けの前に人が立ったら検知 — 通りすがりの人でも反応します。知りたいのは「人が来たこと」ではないので、誤検知だらけになりそうです
• 開閉センサーで、投入口が開いたら検知 — だいぶ近づきました。ただ、いたずらで開けられただけかもしれません。「開いた」は「入った」の代理でしかない
• 重量センサーを底に入れて、重さが変わったら検知 — 重さが増えたなら、中に何かが入った可能性が高い。知りたい事実に一番近いのはこれです

面白いのは、候補を比べているうちに「自分が本当に知りたいことは何か」がはっきりしてくることです。欲しかったのは「人が来た」でも「フタが開いた」でもなく、「中身が増えた」でした。分解して具体を当てる作業は、同時に要件を磨く作業でもあります。

「検知する」が決まれば、残った「伝える」は調べ物です。「重量センサー Wi-Fi 通知」あたりの言葉で探せば、重さの変化をスマホに知らせてくれる製品が見つかります。

——お気づきでしょうか。これ、最初にやった「まず既製品を探す」と同じ手順です。課題まるごとで探し、ちょうどいいものがなければ割って、ピースごとにまた探す。ピースでも見つからなければ、さらに割って（「重さの変化を通知する方法」など）検索したりAIに聞いたりする。課題解決の実態はこの「探す → なければ割る → また探す」の繰り返しで、どこかで世の中の道具がはまったら、そこでループを抜ければいいのです。

そして、このループを回せるのは、割るたびに「探すための言葉」が増えるからです。既製品を探す段階では「ポスト 通知」と、課題の名前でそのまま検索できました。でも作る側に回った瞬間、「郵便が届いたら通知したいんだけど」のままでは、検索窓にもAIにも入れる言葉がなくなります。「重さの変化で検知して、Wi-Fiで通知したい」まで割れていれば、検索も質問も相談も刺さる。課題を塊のまま抱えていると、拾えるはずの情報を取りこぼして視野が狭くなっていきます。

このブログも、分解と道具でできている

実は、このブログも同じ作り方をしています。「継続が苦手でも続けられるブログを作る」という課題を「記事の管理・Webページ化・置き場所・公開の自動化」に分解して、それぞれのピースに既製の道具（Markdown、静的サイトジェネレーター、ホスティングサービス、CI/CD）をはめる。ゼロから作ったものはほとんどなく、やったのは分解と、ピースに合う道具の当てはめだけ。

この感覚は、パズルに近いと思っています。ピースの形（=分解した課題）が分かれば、はまる道具を探せる。この「道具のパズル」の話は、それだけで1回分になるので、シリーズの後のほうで書く予定です。

分解のコツを1つだけ

分解の仕方に正解はありませんが、迷ったときの軸を1つだけ挙げるなら「流れで割る」です。何かが入ってきて、変わって、出ていく。ネットの例はスマホからサービスまでの道筋、郵便受けは「入る → 検知する → 伝える」。たいていの課題はどこかの流れに乗っているので、まず流れを書き出して、その切れ目で割ります。

逆に、いきなり「原因はこれかも」「これを買えばいけそう」と1点に飛びつくと、外れたときに振り出しに戻ります。先に全体を割っておけば、外れても「じゃあ次はこの区間」と進めます。

まとめと次回

• エンジニアの仕事は課題解決で、その考え方は誰でも使える
• 課題はそのままでは解けない。確認できる大きさに「分解」する
• 作る前に、まず既製品を探す（作らずに済むのが一番速い）。なければ割って、ピースごとにまた探す——課題解決は「探す → 割る → 探す」の繰り返し
• 割ったら具体の候補を比べる。比べるうちに「本当に欲しいもの」が磨かれる
• 分解すると「探すための言葉」が手に入り、既製の道具も見つけやすくなる（全部自作しなくていい）
• 迷ったら「流れ」で割る

次回は、この分解とセットで効いてくる「具体と抽象の行き来」について書く予定です。郵便受けの例でやった「大まかに割ってから具体に降りる」という動きを、もっと正面から扱います。「それって要するに何？」と「たとえばどういうこと？」の往復の話です。