ソフトスキル on blog.kyu08.com

『解像度を上げる』を読んだ

Wed, 11 Feb 2026 13:00:41 +0900

おすすめしていただいて気になっていた『解像度を上げる――曖昧な思考を明晰にする「深さ・広さ・構造・時間」の４視点と行動法』を読んだ。

起業家に向けて書かれている記述が多かったが、いちソフトウェアエンジニアとしても非常に参考になる部分が多かったので自分に刺さったポイントを書いていく。

なお、引用は特別に断りがない限りすべて同書からのものです。

「解像度」の構成要素

解像度の高さが何によって構成されているかを考えたときに見えてきたのが、「深さ」「広さ」「構造」「時間」の４つの視点です。

解像度の構成要素を「深さ」「広さ」「構造」「時間」の4つと整理する視点を得られたのが本書を読んで一番良かったポイントかもしれない。

この視点があると「なんか解像度が低いぞ…」となったときにどの要素が足りていないかを考えることで効率的に再現性高く解像度を上げることができそう。他の人のアウトプットへのFBにもかなり便利に使えそう。

4要素は以下のように理解した。

深さ: 具体性を上げたり、因果関係を深堀りしたりする
広さ: 網羅性（幅広さ）を上げる
構造: 「深さ」と「広さ」のステップで出した各要素を構造化する（要素を分解したり整理したりする）
時間: 「過去」「現在」「未来」のような時間軸の観点を盛り込む

情報をツリー構造で整理する

ここまで、深さ、広さ、構造、時間の４つの視点で解像度をチェックしてきました。こうしたチェックをやりやすくする一つの方法としてお勧めなのが、一度自分の理解をツリー構造で整理してみることです。　

本書でも幾度となくツリー構造で分析を整理した図が紹介されていた。

ツリー構造で書いていくと色々なメリットがあって良さそうので取り入れてみようと思う。

たとえば思考の現在地が把握しやすくなることでかなり効率よく思考を深めやすくなる気がする。（今自分は仮説1の解決策2について考えているんだな〜みたいなのが一目でわかるので狭くなりがちな思考を広げられたり、他の要素と行ったり来たりしながら思考を深めやすそう。）

あとは目的意識なく深さと広さを広げすぎるとノイズが増えそうなので構造化するのを忘れないことも大事そう。（このあたりは実際にやってみて調節するのがよさそう）

解像度を上げる対象

上げるべきは、課題と解決策の解像度

ビジネスの文脈では特に課題と解決策の解像度を上げることが重要。

（文字にするとそれはそうという感じにはなってしまうが）「解像度が足りない」と感じたときに足りないのが課題の解像度なのか解決策の解像度なのか両方なのかを分けて考えられるとよりスムーズに成果に繋がりそう。

（直感的には課題の解像度が上がらないと解決策の精度や解像度は上がらなそうに思えるので前者が前提になりそう。）

課題の選び方

このように課題や問いが重要視される理由は、良い課題を選べるかどうかで生み出される価値がほぼ決まると言っても過言ではないからです。

『イシューからはじめよ』でもイシュー度が高い課題を解くことの重要性が説かれていたのを思い出した。

そういう意味でもまずは課題の解像度を上げることが重要かもしれない。（緊急度が高く重要度が低い課題とかはぱっと解決して早く次に行きたい種類の課題なので例外かもしれないが）

書くことで考える

まず取り組んでほしいのは、「今、何が最も重要な課題だと思っているのか、それはなぜなのか」を仮説で良いから最初に書くことです。

考え抜いた「結果」を書くのではありません。書くことは思考の「過程」です。書くことで私たちは考えることができます。

ブログに記事を書いたり（まさにこの記事とかがそう）チームで何か意思決定をする際に会議資料を書いたりすることで自分が考えていることがクリアになったり、思考が深まったりすることがよくあるので最後の2文にはすごく共感した。

文字にすることの効果はかなり感じているので今後も悩んだら（というか何かを考えたいときは）書くことで思考を深めていこうと思った。

書くときの留意点

課題の解像度を「深さ」の視点で上げるための方法として「現時点での自分の課題認識を書き出す」という方法が紹介されていた。

その際のポイントとして以下のような点が挙げられていた。

（他の人に読んでもらうための）わかりやすい文章を書くという観点でも非常に参考になりそうだったので一部を引用して紹介する。

最初の書き出しは箇条書きでも構いません。ただし、より詳細に課題を検討するときには、文章として長文で書くことをお勧めします。箇条書きを使うと、論理の飛躍や矛盾などに気づきづらいからです。

箇条書きだと論理的にわかりやすい文書になるかはかなり書き手に依存すると思っているので頷けた。（自分は箇条書き自体がダメだとは思ってないが注意深く使わないと読み手の解釈が一意にならないので気をつけて使おうと思っている派）

よくあるパターンでいうと以下のようなケースがあると思う。¹

（「なので」「とはいえ」「しかし」などの接続詞が省略されることが多く、）論理的なつながりがわかりづらい
列挙された項目がシーケンスなのか選択肢なのか、AndなのかOrなのかがわかりづらい

Amazonでも会議資料に箇条書きだけで構成されたスライドを使うのは禁止らしい。²（さすがに社員全員が同一のルールを実践してるとは限らないと思うが）

なんにせよ読み手が疑問を感じたり2パターン以上の解釈ができてしまうような文章を書かないことを心がけるのがよさそう。

主語が明確な文にする　

これも抜けがちだがクリティカルな齟齬につながりやすいので気をつけたい。（自分の場合はどちらかというと口頭で話してるときに抜けがちかも）

動詞を入れる　──　体言止めではなく、動詞を入れるようにしましょう。

体言止めも読み手に解釈の余地を与えがちなので注意したい。

たとえば「データ移行の切り戻しは手動。」とドキュメントに書かれていた場合、「手動で行う予定」なのか「手動でしか行えない」（制約の共有）なのか「手動で行った」（完了報告）なのかが明確ではなかったりする。³

スタートアップに関するエッセイで有名なポール・グレアムも、エッセイを公開する前には必ず声に出して読み上げて、友達に話すような言い回しになっているかを確認しているそうです（４）。

普段会議資料を書くときに最後は声に出して読んでみて詰まるポイントがないかチェックしているのでこの点も共感できた。うまく話せないところは論理が飛躍していたり変な結論になっていたりするのことが多いので、仕上げとして声に出して読むのは大事そう。

ことこのブログに関しては書いた後に声に出して読んだりはしていないが良さそうなので試してみようと思った。

深める

事例のサーベイが十分できているかどうかの閾値は、関連事例を「１００」程度知っているか

（起業ではなく）ソフトウェアエンジニアリングの場面では必ずしも100個必要とは限らないが、他社の事例を知っておくと引き出しが増えるので、知っておくに越したことはないと思う。

たとえばソフトウェアアーキテクチャのパターンやディレクトリ構成などは書籍やテックブログ、登壇資料で数多く紹介されているのでそういったアウトプットから学べるとよさそう。普段自分が仕事で関わっている領域ではゼロから何も見ずに自分で考えることに価値があるというよりは、効果的な施策や判断に価値があることが多いので重要な意思決定をする際には適切な情報収集をできるとよさそう。

また、そうしたネット上の資料は無料で公開されていることが多く、そうした環境にかなりお世話になっている自覚があるので自分もアウトプットを続けて少しでも業界、エコシステムに恩返しをしていければなと思う。

不慣れな分野のキャッチアップ

本屋に行って、端から端まで本を買う　事例のサーベイがある程度終わったら、次は大きめの書店に行き、自分の課題に関連する業界の本を端から端まで買うことをお勧めします。

著者によって異なる視点から同じ物事を見ることができますし、重複しているのなら、その情報は誰の目から見ても重要だということが分かります。そうして業界の構造やトレンドを深掘りしていくのです。

特に不慣れな分野に飛び込むときにはこのような方法は効果的そう。

同じような内容の書籍は1冊読めばいいのでは？と思っていたが複数の著者で共通した内容がある場合はその内容の重要性が担保されるという観点はなるほどと思った。

教える

教える　対話や質問のさらに一歩先の言語化として、教えるがあります。今考えている課題について、よく知らない人に教えるつもりで話してみましょう。

自分がブログを書いている理由の1つ。あまり人に教えられるような書き方まではできていないが、先の引用でもあったように書くことを通して理解や思考を深められている。社内外の勉強会での登壇などもこれにあたりそう。

コミュニティに参加する

コミュニティに参加すると、深く考えるためのヒントや、情報をもらえます。それに、誰かが近くにいることで、必然的に言語化や壁打ちの機会が生まれます。

これまであまりコミュニティには参加してこなかったが、今年はGoの知識を深めたいのでチャレンジしてみようと思った。（さっそく2/21のGo Conference mini in Sendai 2026に行ってみることにした）

まとめ

主に起業家や起業家を志す人に向けて書かれているように感じたが、いちソフトウェアエンジニアとしても参考になる部分が非常に多く、読んでよかった。

解像度を上げるための4つの視点「深さ」「広さ」「構造」「時間」は非常に有用なフレームワークだと感じたのでしばらくは意識的に使ってみようと思う。

この箇条書き複数パターンの例示であることが伝わっている…と信じたい。 ↩︎
https://forbesjapan.com/articles/detail/38119 ↩︎
文脈を読めばわかるだろという意見もあるかもしれないが、可能な限りローコンテキストに記述することで読み手の認知負荷低減に繋がり、結果としてコミュニケーションコストを下げられると考えています。 ↩︎

『コンサル一年目が学ぶこと』を読んだ

Sat, 25 Dec 2021 16:15:48 +0000

コンサル一年目が学ぶことを読んだ。

何を期待して読んだのか

これまで技術の勉強はしたことがあったが、社会人として普遍的なスキルである

問題解決能力
仕事を円滑に進めるためのコミュニケーションの取り方

あたりをちゃんと学んだことがなく、一度入門書的なものに触れたいと思っていたので読んでみた。

学び

印象に残っているのは以下。

端的に話す
仮説を持って行動する
重要なことに時間を使う
期待値のすり合わせを怠らない
Quick and Dirty

それぞれ簡単に補足していく。

端的に話す(Talk Straight)

聞かれたことに対してストレートに答える。具体的には

端的に喋る
素直に話す

ことが重要。

これは相手の立場に立ってみれば当然で、質問をしたのにその答えがなかなか返ってこないと「結局何がいいたいんだ？」となってしまう。

とは言いつつも、自分自身も自分の思考が整理できていない時は特にだらだらと喋ってしまいがちなので、そういう時はいいチャンスだと思って一旦思考を整理するようにしたい。

仮説を持って行動する

1から10まで調査しきっていては時間が足りない。最低限の調査をして仮説を立てたら、検証 -> 仮説の修正のループを高速で回していくことで限られた時間で精度の高い結論を導くことができる。

仮説思考を身につける第1歩として、仮説を持つクセをつけるためにあらゆる事象に対して「自分はどう思うのか」「なぜそう思うのか」というスタンスを持つことを心がけたい。

重要なことに時間を使う

使える時間は限られているので費用対効果を常に意識して時間の使い方を決める。

仮説思考の話とも繋がるが優先順位を設定して重要な課題から手をつけていきたい。

自分に振ってきたタスクどうしの優先順位だけでなく、もう一段上の視座で自分/自チームが今本当に取り組むべきことは何なのか、という思考を心がけたい。

期待値のすり合わせを怠らない

求められていないことに時間を使っても成果には繋がらない。まずは自分が何を期待されているかを正確に把握することが重要。

自分の認識がズレていて後になって手戻りが発生することが稀によくあるので、タスクを振られた際などにその場で

そのタスクの目的
求められているアウトプット

を明確にするように心がけたい。

Quick and Dirty

3日間かけて100% のアウトプットを出すのではなく、まずは3時間で30% のアウトプットをだすべき。

こまめにアウトプットを行ってフィードバックを得ることができれば間違った方向に進んでしまって時間を浪費する前に軌道修正できる。

まとめ

この本を読んだことの収穫としては、自分の中でぼんやりと課題感としてあった

ただがむしゃらに取り組むのではなく効率よく問題を解決するにはどうすればいいのか

というイシューへの回答の1つである、

重要思考・仮説思考を用いる
Quick and Dirty
期待値のすり合わせを怠らない

という考え方に出会えたことが挙げられると思う。

また、コンサルタントのプロフェッショナリズムに触れて自分も周囲の期待を越え続ける存在でありたいと思った。

おまけ

「仮説思考をやっていこうと思いました」(意訳) という話を上長にしたところ『イシューからはじめよ』をおすすめされたのでこちらも読んでみようと思う。