シニアエンジニアに必須な「構造化」の話

若手エンジニアだった頃、上司からよく「設計方針を決めたいので、まず状況を整理してほしい」と言われました。

当時の私は、整理することを「情報を見える形にすること」だと思っていました。

とりあえずFigmaで画面や処理の流れを図にし、関係ありそうな情報を並べていました。

しかし、上司からはよく「まだ構造化できていない」と言われました。

上司が作り直した資料を見ると、自分の資料とは明らかに異なり、「何が問題で」「何を決める必要があり」「どの選択肢を比較すべきか」が分かるものでした。

この経験から、エンジニアに必要なのはコードを書く力だけではないと気づきました。

複雑な状況を、意思決定できる形に構造化する力も必要なのです。

構造化で勘違いしがちなこと

構造化と聞くと、いきなりマトリックスやフロー図を作ろうとする人がいます。

もちろん、それ自体が悪いわけではありません。

熟練者であれば、頭の中で目的や論点を整理したうえで、いきなり図に落とし込めるかもしれません。

しかし、私は図にすれば整理できると思っていました。

その結果、整理されているように見えるものの、設計方針を決めるための材料としては使いづらい資料になっていました。

構造化とは、単に図を作ることではありません。

構造化とは

定義の説明は色々ありますが、今回は『構造化思考のレッスン』という本の定義を紹介します。

定義にあるように、構造化は目的に合った形で整理することです。ここが、重要です。

つまり、きれいな図を作ることではなく、誰が何を判断するための整理なのかを明確にすることです。

目的が変われば、必要な情報も、まとめ方も、見せ方も変わります。

構造化の5P

構造化する際に、分かりやすいフレームワークがあります。

それが、構造化の5Pです。

この5Pは、PurposeからPresentationに向かって考えることが重要です。

まず考えるべきなのは、Presentationではありません。マトリックスにするか、フロー図にするか、ツリーにするかは、最後に考えることです。

最初に考えるべきなのは、Purposeです。

ここを先に決めることで、集めるべき情報や、まとめるべき単位が見えてきます。

Purpose、Piece、Perspectiveを可視化すると、以下のようになります。

Purposeの解像度を高める

Purposeは、「何のために構造化するのか？」を考えることです。

ただし、Purposeをざっくり置くだけでは不十分です。

たとえば、「設計方針を決めるため」と書くだけでは、まだ少し粗いです。

設計方針を決めるといっても、『誰が』『いつ』『誰と』『何をするために』使うのかによって、整理すべき情報は変わります。

だからこそ、Purposeはさらに分解して考える必要があります。

Purposeの解像度が上がると、何を整理すべきか、何を省くべきかが見えやすくなります。

最後に

構造化は、まず目的から考えることが大切です。

ただし、目的を整理できれば終わりではありません。

その後も、情報の断片を洗い出し、視点を決め、まとめる単位を考え、最適な表現に落とし込む必要があります。

このような構造化の進め方については、『構造化思考のレッスン』で分かりやすく解説されています。