ryokatsu.dev

解像度を上げるを読んだ

Twitterのタイムラインで話題になっていたので、読んでみました。普段何気なく使う「解像度が高い」「解像度が低い」という言葉ですが、解像度が高い状態というのはどういう状態か、解像度を高くすると何がいいのか、解像度を上げるにはどうすれば良いかが丁寧にまとまっている本でした。ビジネス本ですが、エンジニアが読んでもとてもためになる本でした。

解像度をあげる4つの観点

書籍の中では、「深さ」「広さ」「構造」「時間」の4つに分解しています。特に「深さ」に関しては他の観点より特に需要で、解像度が低いと感じたらまずは「深さ」からはじめるのが良いとされています。

解像度が低い状態は、例えばお客さんと話している時に顧客像がぼんやりしていたり、話がふわっとしていたりという状況のことで解像度が高い状態だと「顧客像がはっきりしている」「話が具体的」などになります。「ReactのuseEffectの挙動を理解して人の説明できる」「JavaScriptの配列を操作するmapメソッドのアルゴリズムを理解して人の説明できる」なども解像度が高い状態だと思います。

深さ

原因や要因などをより深くまで調査して、掘り下げ把握することができていると解像度が高い状態と言えます。普段コーディングする時も、まずはコードを読んだり、書籍で調べたり、ドキュメントを読んだり、技術記事を読んだりする思います。これがレベル1。次に実際に書いてみる（写経も含めて）これでレベル2。そのあと不明点を人に聴いたり、レビューに出してレビューを受けたりして、知見を得たりするのがレベル3というように階層が深くなるにつれ解像度が上がっていきます。書籍の中でも「情報量を増やす」「サーベイをする」「インタビューをする」のように深さのレベルをあげていくことが書かれています。

広さ

先程の深さを深くしていく中で、別の観点を見つけることがあります。これが広さです。言葉そのままで、「視野を広げる」ということでしょうか。エンジニア的に言うと、技術選定時に「どのフレームワークを使うべきか」「ライブラリの比較」「色々なコードの書き方がある」などですかね。広さを知ると様々な選択肢ができ最適な判断ができます。少し深さに関わっている部分もありますが、広さの解像度が低いと適切な判断ができなかったり、競合に負けたりすることが起きそうです。

構造

深さ、広さの観点でみえてきたものをグルーピングしたり構造化することです。関数をまとめたり、ディレクトリ構成を見直したりみたいな作業もここに入りそうです。書籍でもディレクトリ構成の話は出てきます。MICEを使った分け方なども紹介されています。（久しぶりに聴いた）また、構造化の中で図を書くことも解像度を上げるのに良いと書かれていました。確かに技術記事の中で分かりやすい図を見かけてると解像度が高い記事を書けているなと感じます。

ちなみに最近こんなツイートがバズっていましたが、これも構造の解像度が高いなと感じます。

時間

最後に時間です。これは、時間に経過によって変化する物事を適切に捉えることです。フロントエンドの文脈だと、よく言われるのが「変化が激しい」です。日々変化をチェックして解像度を高くすることが重要そうです。身近な所だとコードも時間が経てば負債になっていきます。その時にどのような意図で変更があったのかなどを適切に捉える能力が高いと解像度が高いと言えます。

感想

普段何気なく行っていることもありましたが、改めて解像度について理解できる一冊でした。たまにはビジネス書もいいね。