「考えが浅い」を卒業したエンジニアが教える、思考の深さを変えたメモ術の習慣

「この人の発言、なんでいつもこんなに鋭いんだろう」と思ったことはないだろうか。設計レビューで的確な問いを出す先輩、ミーティングで本質を一言でまとめるプロダクトマネージャー。彼らとの差は、知識量や経験年数だけではない。思考を整理する「習慣の差」が、アウトプットの質を分けていることが多い。

私は入社から3年間、「考えが浅い」という指摘を繰り返し受けていた。コードレビューでの設計コメント、ミーティングでの発言、技術提案書の構成。どこか表面的で、一段深く掘り下げられていないと感じていた。ツールやフレームワークは学んだ。本も読んだ。しかし何かが足りなかった。

転機になったのは「ゼロ秒思考」と「メモの魔力」という2冊のメモ術の本だった。どちらも「メモを取る」という行為を、記録のためでなく「思考を深めるツール」として位置づけている。この視点の転換が、自分のアウトプットの質を根本から変えた。

メモ術に関する書籍はAudibleでも人気のジャンルだ。通勤中に「メモの魔力」を聴いて、翌日のミーティングで即実践する。そのサイクルを作ることで、知識が行動に変わりやすくなる。今なら1冊無料で試せるので、まず聴いてみることをすすめたい。

※ 30日間の無料体験。いつでも解約可能。

「記録するメモ」と「思考するメモ」の違いとは

「メモはちゃんと取っています」と言うエンジニアは多い。議事録を書き、コードのコメントを残し、Confluenceに仕様をまとめる。しかし「メモを取っているのに思考力が上がらない」という悩みも多い。その原因は、メモの使い方が「記録」に偏っているからだ。

記録するメモと思考するメモは、根本的に目的が異なる。記録するメモは「情報を保存する」ことを目的とし、情報の再現性を高める。思考するメモは「思考を深める」ことを目的とし、自分の頭の中にある曖昧な考えを言語化して、思考のスピードと質を高める。

優れたエンジニアがやっているメモは、多くの場合「思考するメモ」だ。仕様の議論を聞きながら「なぜそうなるのか」「別の選択肢は何か」「このアプローチの弱点は何か」を素早くメモに書き出している。このメモが、鋭い発言の源泉になっている。

なぜメモを取っても思考力が上がらないのか

メモを取っているのに思考力が上がらない人に共通するパターンがある。まず「聞いたことをそのまま書く」という受動的なメモだ。議事録として優秀でも、自分の思考が介在しないため、頭には何も残らない。情報を記録することと、情報を自分のものにすることは別の行為だ。

次に「後で見返すためのメモ」という発想だ。丁寧に整理されたノートを作ろうとするが、整理に時間がかかりすぎて続かない。また、「後で見返す」ことが前提なので、その場での思考が浅くなりがちだ。メモの目的を「後で読む」ではなく「今の思考を深める」に変えることが重要だ。

さらに、デジタルツールへの依存が思考を停止させることもある。Notionのデータベースを整備することに満足し、思考そのものが進んでいないケースだ。ツールの設計は手段であり目的ではない。どんなツールを使うかより、何を考えながら書くかのほうが、思考力向上には重要だ。

思考を深めるメモの3つの特徴

思考を深めるメモには、共通する3つの特徴がある。1つ目は「問いかけの形で書く」こと。「Aだ」と書くより「なぜAなのか」「AでなくBにする場合は何が変わるか」と問いかける形で書くと、自分の頭が動き始める。

2つ目は「感情や違和感を書く」こと。「なんか違う気がする」「これは自分にはできそうにない」という主観的な反応を記録することで、自分の価値観や前提が可視化される。論理的な分析だけでなく、直感を言語化する習慣が思考の幅を広げる。

3つ目は「具体から抽象へ動かす」こと。「今日のバグ修正でAの手法を使った」という記録に留まらず、「Aの手法はどんな場面に有効か」「この原則はどこに転用できるか」という抽象化・転用の問いを加える。この操作が「メモの魔力」でいう「知的生産性」を高める核心だ。

• 問いかけの形で書く：「なぜ？」「どうすれば？」を書くと脳が動き始める
• 感情・違和感を書く：主観的な反応を記録することで前提が可視化される
• 具体から抽象へ：事実に「どこに転用できるか」を加えて知的生産につなげる
• スピードを優先する：完璧な文章より荒削りな思考の断片を素早く書く

「ゼロ秒思考」メモ書きの実践法

赤羽雄二氏の「ゼロ秒思考」は、シンプルだが実践的なメモ書きメソッドだ。A4の紙（またはノート）に、タイトルを1行書いて、その下に関連する考えを4〜6行、1分以内に書き切る。この「1枚1分」のサイクルを1日10枚継続することで、思考の速度と質が同時に上がるという。

赤羽氏はマッキンゼーで14年勤務した後、スタートアップの支援や人材育成に関わってきたビジネスコンサルタントだ。「ゼロ秒思考」は2013年の発売以降、累計34万部を超えるロングセラーになっている。シンプルな方法にもかかわらず効果が高い理由は、メモ書きという行為が脳の「言語化」と「整理」を同時に強制するからだ。

「思考のスピードが遅い」と感じているエンジニアの多くは、頭の中で考えすぎて言語化が後回しになっている。考えてから書くのではなく、書きながら考えることで、思考が外に出てループから解放される。このサイクルを繰り返すことで、徐々に「ゼロ秒（考える前に答えが出る）」に近づくのが、このメソッドの目指すところだ。

この本はAudible（オーディブル）で聴くこともできます。 今なら1冊無料でお試し →

A4メモ書きの具体的なやり方

ゼロ秒思考メモ書きのフォーマットはシンプルだ。A4横書きで、左上にタイトル（問い）を書く。「なぜ私はミーティングで発言が少ないのか」「この設計の問題点は何か」「今週の最優先タスクは何か」など、自分が考えたいテーマを問いの形で書く。その下に、思いついたことを4〜6行、箇条書きや短文で書き出す。制限時間は1分だ。

ポイントは「考えてから書くのではなく、書きながら考える」ことだ。完璧な答えを出してから書こうとすると手が止まる。不完全でも構わないので、思い浮かんだことを素早く書き出す。このスピードが脳の「考えること」への抵抗を下げ、継続につながる。

1日10枚というノルマは、最初は多く感じるかもしれないが、慣れると15〜20分で完了する。仕事の前に5枚、昼休みに3枚、帰宅後に2枚、という分割でも構わない。重要なのは毎日続けることだ。3週間続けると、明らかに「頭の中の整理速度」が変わる体感が得られる。

エンジニアの仕事場面への応用

ゼロ秒思考メモ書きは、エンジニアの日常業務に特に効果を発揮するシーンがある。まず「バグの原因仮説出し」だ。「このバグの原因として考えられることは何か」というタイトルで1分間書き出すと、思いつく仮説が一覧化され、調査の優先順位が立てやすくなる。頭の中で考えているだけより、紙に書き出すほうが仮説の数と質が上がる。

次に「設計のトレードオフ整理」への応用だ。「AアーキテクチャとBアーキテクチャの違いは何か」というタイトルで書き出すと、自分が何を重視しているかが可視化される。設計レビューで「なぜそのアーキテクチャを選んだのか」と聞かれたとき、メモ書きしておいた内容が即座に言語化できる。

また「1on1の準備」にも使いやすい。「今週のマネージャーへの相談事項」「今自分が感じている課題」というタイトルで書き出すと、面談での発言密度が上がる。多くのエンジニアが1on1で「特にないです」と答えてしまうのは、事前の思考整理が足りていないからだ。

「メモの魔力」が教える抽象化・転用の技術

前田裕二氏の「メモの魔力」は、メモを「知的生産の最強ツール」として位置づける。SHOWROOM社長・前田氏のメモ術の核心は「ファクト→抽象化→転用」という3ステップのサイクルだ。このサイクルを習慣にすることで、日常の出来事や情報から「汎用的な知識」を抽出し、新しい状況に応用できる思考力が身につく。

「メモの魔力」が多くのビジネスパーソンに支持される理由は、メモを「記録」から「思考の器」に転換している点だ。ただ書くのではなく、書いた内容から「なぜそうなのか」「どこに使えるか」を引き出す。この一手間が、読んで忘れる読書と、読んで変わる読書の差を生み出す。

前田氏は1冊のモレスキンノートに年間数千のメモを書くことで知られており、そのメモが事業アイデアや人生の意思決定の源泉になっていると語る。メモは「書くこと」が目的ではなく、「書くことで思考を動かし、行動につなげる」ためのエンジンだという考え方は、忙しいエンジニアの仕事観を変えるきっかけになる。

この本はAudible（オーディブル）で聴くこともできます。 今なら1冊無料でお試し →

「ファクト→抽象化→転用」の3ステップ

前田氏のメモ術の具体的な流れを見てみよう。まず「ファクト」として、起きた出来事や読んだ情報を書く。例えば「コードレビューで『変数名が分かりにくい』と指摘された」という事実だ。

次に「抽象化」として、そのファクトから教訓や原則を引き出す。「変数名の適切さは、書いた本人より読む人の視点で判断すべきだ」「コードは書く行為より読まれる行為に最適化すべきだ」という形で、1段階高い視点からの知識を言語化する。

最後に「転用」として、その抽象化した知識を他の場面に当てはめる。「メールやドキュメントも、書く人の都合より読む人の視点で書くべきだ」「プレゼン資料も聴衆の理解スピードを優先すべきだ」という形で、コードレビューの教訓がコミュニケーション全般の改善につながる。

このサイクルを繰り返すと、日常の仕事上の出来事が「知的資産」に変わっていく。コードレビューの指摘1件から、仕事全般に使える原則が抽出できるようになる。これが前田氏の言う「メモの魔力」だ。1冊の手帳が、思考の変遷を記録した「自分の知的辞書」になっていく。

エンジニアの仕事に「ファクト→抽象化→転用」を使う

エンジニアの日常業務でこの3ステップを実践すると、仕事の質の向上が実感できる。技術的なトラブルシュートを例にすると、「本番環境でNullPointerExceptionが発生した（ファクト）」→「外部APIのレスポンスはnullを返す可能性があり、defensive codingが必要（抽象化）」→「今後の実装では外部依存のインタフェース設計時にnullケースを先に定義する（転用）」というサイクルだ。

このサイクルをGitのコミットメッセージやデイリーのメモに記録すると、自分のエラーパターンと改善のログが蓄積される。同じミスを繰り返さないだけでなく、類似パターンを事前に予測できるようになる。「転用」の欄に書いた内容が、設計レビューでの先読みコメントとして活きてくる。

エンジニアが陥りやすい「メモの罠」

メモ術の本を読んで「よし、始めよう」と思ったのに続かなかった経験がある人は多いはずだ。メモ習慣の挫折には、エンジニアに特有のパターンがある。意識することで、同じ失敗を繰り返さずに済む。

完璧なシステムを作ろうとする罠

エンジニアはシステム設計が好きだ。その習性がメモ術にも出てしまう。「完璧なNotionデータベースを設計して、タグ・カテゴリ・ステータスを整備してから始めよう」と考え、準備に1週間かかる。そして実際に書き始めると、管理の手間が大きくて続かなくなる。

メモ習慣の本質は「書くこと」であり、「管理すること」ではない。ゼロ秒思考のA4用紙は、その日の終わりに全部捨ててもいい。メモの魔力の著者・前田氏も「メモは残すことより書くことに価値がある」と言う。完璧な管理システムより、毎日書く習慣が先だ。ツールはシンプルなものから始めて、続けられると分かってから改良する。

ツール選びで時間を消耗する罠

「Notion vs Obsidian vs Roam Research、どれが最強か」という議論が好きなエンジニアは多い。しかしツール比較に10時間かけるより、どのツールでも1日10分書く習慣を作るほうが、思考力向上には100倍効果的だ。ツールは思考の器であり、器を選ぶことが目的ではない。

最初の1ヶ月は、手元にある最もシンプルなツールで始めることをすすめる。テキストエディタ、紙のノート、iPhoneのメモアプリ、どれでも構わない。大切なのはフォーマットでも機能でもなく、「考えながら書く習慣」そのものだ。習慣が定着してから、自分の使い方に合わせてツールを最適化する順序が正しい。

「読み返し」に時間をかけすぎる罠

書いたメモを定期的に読み返してまとめ直す「リライト作業」に時間をかけすぎるパターンもある。リライト自体は有益だが、書く量が減るほど時間をかけてしまうと逆効果だ。ゼロ秒思考メモは「書いたら捨てる」でも思考力は上がる。書くプロセスに価値があるからだ。

メモの魔力流の「転用」メモは残す価値が高い。「このファクトからこの原則を引き出した」という転用の記録は、自分の思考スタイルの変遷を示す知的資産になる。すべてのメモを永久保存しようとするのではなく、「思考プロセス系のメモは捨てる、転用・知見系のメモは残す」という使い分けが現実的だ。

今日から始める思考を深めるメモの5つの習慣

メモ術は一度理解しても、実践しなければ意味がない。以下の5つの習慣を1つずつ取り入れることで、「思考するメモ」が日常に定着していく。最初は1つだけ選んで、2週間続けてみてほしい。

習慣1：朝5分のA4メモ書き

1日の始まりに、その日の最重要課題や気になっていることをA4用紙に書き出す。「今日、最もやっかいなタスクは何か」「昨日の設計レビューで解決しきれなかった問題は何か」「今週の優先度の判断に迷っている点は何か」。テーマを1つ決めて、1分で4〜6行書く。これを3〜5枚繰り返すと、朝の思考の霧が晴れて、その日の仕事の方向性が見えてくる。

朝のメモ書きは、「タスクを消化する前に、自分が何に集中すべきかを確認する」という目的にも使える。週次レビューで方向性は決めていても、毎朝のメモで「今日の最重要タスク（ハイライト）」を再確認することで、一日の仕事の質が安定する。

習慣2：会議中の「問い」メモ

会議中のメモを「何が言われたか（記録）」ではなく、「何が疑問か、何が決まっていないか（問い）」で書くようにする。「この仕様の根拠は何か？」「この優先度の判断基準は何か？」という問いを書き留めておくと、発言のタイミングを逃しても後で確認できる。また、問いを書く行為が思考を能動的にし、会議への関与度が上がる。

会議の内容をすべて記録しようとすると、書くことに集中して考えることができなくなる。議事録は後で別途まとめるか、AIツールに任せる。会議中は「自分の思考」に集中することのほうが、チームへの貢献につながる発言を生みやすい。

習慣3：コードレビューの「ファクト→転用」メモ

コードレビューで指摘を受けたときや、良いコードパターンを発見したときに、「ファクト→抽象化→転用」の3行メモを残す。「AパターンのSQLが遅かった（ファクト）」→「JOINの順序は内側テーブルのサイズが小さいほうが速い（抽象化）」→「次のレビューで同様のパターンを指摘できるようにする（転用）」という形だ。

このメモを積み重ねると、自分の「コードレビューの観点リスト」が育っていく。6ヶ月後に振り返ると、自分がどんな問題パターンをよく見落としていたかが分かる。このリストはオンボーディング時に後輩に共有できる資産にもなる。

習慣4：読書・学習の「1行転用メモ」

技術書・ビジネス書を読むとき、各章読み終わったら「この章から自分の仕事に転用できることを1行書く」というルールを設ける。5行でも3行でも構わない。重要なのは「転用」の視点を持って読むことで、インプットの質が変わる。「へぇ〜面白い」という受動的な読書から、「これを使うとしたら何に使えるか」という能動的な読書に変わる。

Audibleで本を聴きながら、気になった部分でアプリのブックマーク機能を使って印をつけ、後で転用メモを書くという方法も効果的だ。通勤中に聴いて、昼休みに転用メモを5分書く。このサイクルが知識の定着率を高める。

習慣5：週次レビューへのメモ統合

週次レビュー（毎週30分の振り返り）の中に「今週のベストメモ1枚を振り返る」時間を5分追加する。その週に書いたメモの中で、最も思考が深まった1枚を選び、そこから引き出された「転用できる知見」を1文にまとめる。これを週次レビューのログに記録すると、半年後に「自分の成長の地図」が見えてくる。

メモ習慣と週次レビューを組み合わせることで、インプット（メモ）とアウトプット（週次レビューへの統合）のサイクルが回り始める。単発の気づきが、継続的な成長の記録になっていく。仕事術の習慣は単体で実践するより、相互に連動させることで効果が増す。

よくある質問

まとめ：メモは「記録」から「思考」に変えると仕事が変わる

「考えが浅い」という指摘を受け続けていたあの頃の自分に、今なら伝えられることがある。思考の深さは才能ではなく、習慣の産物だ。ゼロ秒思考のA4メモ書きで思考を言語化する速度を上げ、メモの魔力の抽象化・転用で日常の出来事を知的資産に変える。この2つの習慣が、3ヶ月後の自分のアウトプットの質を変える。

メモ術に必要な道具は何もいらない。A4の紙と、ボールペンと、1日10分の時間があれば始められる。ツールを選ぶより、今日の朝に1枚書くことが先だ。「どんなメモを取るか」より「考えながら書く」という行為を習慣にすることが、思考力を上げる唯一の近道だ。

「メモの魔力」「ゼロ秒思考」の両方がAudibleで聴けるのは、エンジニアにとって好都合だ。通勤中に聴いて、翌日から即実践する。Audibleの無料体験期間中に2冊聴いて、自分に合うメソッドを試してみてほしい。30日後の自分のアウトプットが、今日のメモ1枚から変わり始める。

※ 30日間の無料体験。いつでも解約可能。