エンジニアの成長を加速する「具体⇔抽象」思考モデル

はじめに

最近、「『具体⇄抽象』トレーニング 思考力が飛躍的にアップする29問 (PHPビジネス新書)」という書籍を読みました。

Amazonリンクはこちら

この書籍は、個々の具体的な問題や情報を昇華して抽象化し「知の発展」を目指す方法、さらに抽象的な概念を具体的な実践へと再び構築するプロセスについて解説しています。
この本を読んで、私の普段の業務では、目の前の具体的な課題やコードに集中することが多い一方で、根本的な設計や構造、再利用可能なパターンにまで深く考える機会は意外と少ないかもしれないと考えさせられました。

また、近年はAIやツールの進化によって、単なる作業や機械的なコーディングは自動化されやすくなっています。
こうした状況では、単なる情報量だけでなく、本質的な問題解決能力や抽象力を高めることが、エンジニアとしての価値向上に繋がるはずです。

今回は、この書籍のコンセプトを基に、「具体⇔抽象」の往復思考をエンジニアリング業務にどのように活かしていくかを整理し、普段の業務や学習の質を高めるヒントを共有したいと思います。

「エンジニアに必要な2つの思考：「具体」（横方向）と「抽象」（縦方向）」

エンジニアが問題解決能力を高めるには、「具体」と「抽象」の両方の思考をバランスよく使い分けることが重要です。どちらか片方によると、「具体病」、「抽象病」の罠に陥ってしまいます。

• 「具体病」 とは、目の前の具体的な作業に集中しすぎて思考停止状態に陥ることです。この状態では新たな発想や応用が生まれにくく、AIや自動化技術に置き換えられやすくなってしまいます。

• 「抽象病」 とは、口頭で理論や概念を語るだけで具体的な行動に移せない状態です。実践に落とし込めないため、実際の成果や改善につながりません。

エンジニアに必要なのは、「具体」と「抽象」を自在に行き来しながら、問題の本質を捉えて解決できる力であると考えます。

そもそも「具体」と「抽象」とは？

思考の種類	特徴	例
具体	断片的で個別的な情報やノウハウ、現実的で即時適用可能な知識	コード、技術記事等の具体的な実装方法、AIにより生成された情報
抽象	本質的で構造化された概念や原則- 他の問題にも応用可能な知識	設計パターン、ビジネス要件、システム思考

エンジニアに求められる「抽象化」「具体化」スキル

抽象化（縦方向の思考）とは

• 「なぜ（Why）そうなっているのか？」を深掘りする
• 必要な情報を目的に合わせて整理・取捨選択し、言語化・図解して理解する
• 良質な情報を選び、抽象概念として整理する

具体化（横方向の思考）とは

• 「どのように（How）やるか？」を考える
• 抽象概念を具体的な方法や実践手順に落とし込む

参照 「具体⇄抽象」トレーニング 思考力が飛躍的にアップする29問 (PHPビジネス新書)

業務への具体的な活かし方

個別のコードや実装パターンを「具体知」として集める

日々の業務を行う中で、自分が書いたコードや同僚からコードレビューを受けた際の気づきを単にその場限りにするのではなく、意識的に「具体知」としてストックしていきます。

具体的には、プロジェクトごとのコードや実装の特徴、他のエンジニアの書いた優れたコード例、あるいは自分が躓いた問題とその解決方法などを明確に記録し、「パターン集」やノート、ドキュメントなどに蓄積していきます。ブログや技術記事にまとめるのも良い方法です。

例

• 非同期処理のエラーハンドリング
• アーキテクチャやディレクトリ構造
• テーブル設計
• 技術記事（具体）を抽象概念へと昇華させる
  • 具体 → 要約 → 抽象を意識する
  • 内容を「技術的なトピック」「解決した問題」「得られた知見」に分解する。

→「パターン集」として蓄積することで、具体知の量を増やしていきます。
なのでなるべく優秀なエンジニアの多い職場で働けるとこの具体知の拡大がさらに進みます。

複数の具体から「抽象概念」を導き出す

そうして集めた「具体知」の中から、「共通パターン」や「原則」を言語化・概念化することで、「抽象知」として整理します。
そうして得た抽象知は具体に依存しないさまざまな問題解決にも役に立ちます。
つまりどこの職場でも活用できる武器となります。

→「共通原則」「設計原則」として抽象化することで、適用範囲が広がる。なぜこの実装なのかを考える。

新しい業務に抽象を適用して、再度具体化する

別のプロジェクトで似た課題に直面したとき、過去に抽象化した知識を使って、新しい場面に応用します。

例

• ReactからNext.jsに移行する際に「検索条件の状態管理はURL主導がよい」と判断
• 新規API設計時に「エラー処理はアプリ共通のレスポンス構造に統一」とルール化

→「個別案件の属人的対応」ではなく、「普遍的な設計知識」として再利用可能になります。

抽象⇔具体を意識した学習・アウトプット習慣化の例

学習対象	具体	抽象
新しいライブラリ	サンプルコードを見る	ライブラリの思想・設計方針を理解
コードレビュー	個別の実装を見る	共通設計ルールを抽出して共有
技術記事	コード例を読む	何を解決するための設計パターンかを理解

日常的に意識するポイント

タイミング	意識ポイント
実装中	- なぜこの設計にしたか、理由や背景をメモ - 他のプロジェクトや言語でも応用できるか考える - 過去の事例（自分やチーム）から使えるパターンを探す
コードレビュー	- 単なる指摘で終わらせず、似た事例を思い出す - 設計や実装方針の共通点・相違点を意識 - 参考になるコードは「パターン集」にストック
技術記事やドキュメント	- サンプルコードを見るだけでなく、「なぜこの設計か？」を考える - 自分の案件にどう応用できるかを必ず検討
振り返り	- プロジェクトごとに「新たに得た設計知」をまとめて資産化 - 過去のパターンや原則を定期的に見直して更新
新しい課題	- いきなり個別対応せず、まず「過去知識」から類似パターンを探す - 抽象化した原則に沿って設計→個別調整する流れを意識
チームとの会話	- 設計や技術選定の背景を言語化・共有 - 暗黙知を「設計パターン」として見える化 - 「この設計は他の案件でも使える？」を常に問いかける

効果

• 場当たり的なコーディング(how)が減り、「設計原則ベース」(why)の思考が身につく
• プロジェクトごとのノウハウを「資産化」できる
• 応用力が上がり、新しい技術や案件にもスムーズに適応できる

実践ポイントまとめ

ステップ	アクション
具体知の蓄積	日々の実装やコードレビューでパターンをストック（ノートやドキュメントに）
抽象化	似た事例をまとめ、共通の設計原則や考え方に落とし込む
再具体化	新しい案件や技術選定で、抽象知を元に具体設計へ適用
思考トレーニング	「この設計は他に応用できるか？」「他にも使えるパターンは？」を日常的に考える癖をつける

プラスα：生成AIを使った「具体⇔抽象」壁打ち

ChatGPTやGitHubCoplilotを壁打ち相手にして、以下の対話を繰り返すのも非常に有効です。

• 「この実装パターン、他にどんな場面で使える？」
• 「似たような設計パターンある？」
• 「これを抽象化すると、どんな設計原則にまとめられる？」
• 「なぜこの実装にした？」

まとめ

「具体⇔抽象」の往復を意識すると、以下の力が身につきます。

• 要件（抽象）から具体（コーディングや基本設計など）に落とし込む力
• 個別事例（具体）から設計パターン（抽象）を学ぶ力
• 設計パターンを新しい案件に適用する力
• 普遍的な「設計思考」「設計知識」を蓄積する力

日々の業務や学習を、この「具体⇔抽象」モデルに沿って意識的に取り組むことで、プログラミングスキルを「汎用的な知的能力」として鍛えることができます。

ここまでまとめたものもエンジニとしてスキルアップに絞った、一例でしかありません。
具体化・抽象化の技術があるかではなく、その視点を意識することが最も大切です。

あと、今回紹介した本ですが、どなたにも絶対に参考なる部分がある良書だと思いますので是非読んでみてください。