【感想・ネタバレ】システム開発と「具体と抽象」～問題発見と問題解決を往復する「思考のメタ化」を身につける～のレビュー

細谷功

◆AI時代、「具体と抽象」を往復できる人が、プロジェクトを動かす◆
システム開発の現場で、こんな思いをしたことはないでしょうか。「で、具体的に何を作ればいいんですか」 経営者の語る構想も、コンサルタントの描く青写真も、いざ手を動かす段になると要件が定まらない。全員が真剣なのに、話が噛み合わない。要件定義で合意したはずが、成果物を見せた瞬間に「そうじゃない」と言われる。立場が違う人の間で、なぜこれほど合意形成は難しいのか。その断絶の正体は、「具体と抽象」という思考の階層の違いにあります。
本書は、ベストセラー『具体と抽象』をはじめ数々の思考力に関する著作で知られる細谷功氏が、システム開発の現場に焦点を当て、この「具体と抽象」のフレームワークを軸に、現場が構造的に抱える課題の本質とその乗り越え方を体系的に解説した一冊です。主な特徴は、以下の3点にあります。
1つ目は「立場の違いが生むコミュニケーションギャップの構造を解き明かす」点です。経営者とエンジニア、コンサルタントと開発者、営業と技術。現場で日常的に起きる「話が通じない」問題を、「具体と抽象」の視点から構造的に分析します。なぜ抽象的な指示にエンジニアは苛立ち、なぜ具体的な報告に経営者は物足りなさを感じるのか。その双方向のメカニズムを理解することが、立場を超えた合意形成の第一歩となります。
2つ目は「思考のOSのメタ化という新しい変革モデルを提示する」点です。これまで「具体」で価値を出してきた強みを捨てるのでも、単にバージョンアップするのでもない。場面に応じて川上と川下の思考回路を使い分ける「メタ化」という第三の道を提唱し、個人にも組織にも適用できる実践的な視座を示します。実装やコーディングで培った力をそのままに、「何を作るべきか」を決める側にも立てるようになる。AIに具体を委ねる時代に、エンジニアが自らの価値を問い直すための核となる考え方です。
3つ目は「個人・プロジェクト・組織の3層構造で課題を立体的に捉える」点です。個人の思考回路の転換から、プロジェクト現場で頻発する落とし穴の構造分析、さらには組織の成長・保守化のメカニズムまでを一貫して読み解きます。「魚」「釣り方」「川の構造」という独自のアナロジーを通じて、目先のノウハウではなく、問題を生み出す構造そのものの理解へと読者を導きます。
即効性のあるノウハウ本ではなく、半世紀にわたり解決されてこなかった「なぜ」に切り込む本書は、AI時代に自らの価値の源泉を問い直すすべての作り手にとって、思考の転換点となる一冊です。


■こんな方におすすめ
・「言われたものを作る」から「何を作るかを提案する」側へ進みたいエンジニア、PM、テックリードの方
・顧客への提案力・構想力を高めたいITコンサルタント、プリセールスの方
・DX・AI活用を掲げながらPoC止まりに悩む情報システム部門・経営企画の方
・組織の「思考のOS」を変えたいと考えるIT企業の経営者・マネジメント層の方
・「仕事を頼む・頼まれる」関係で提案に携わる、製造・広告など他業種の方


■目次
第１章 SI業界が抱える課題
・1.1 「言われたことは得意だが、提案が不得意である」
・1.2 なぜ「提案型人材」が少ないのか
・1.3 受動的問題解決から能動的問題発見へ
・1.4 OSのメタ化が必要
第２章 「具体と抽象」とは
・2.1 具体と抽象の基本
・2.2 ITと「具体と抽象」
・2.3 「手段と目的」への応用
第３章 SIプロジェクトと「具体と抽象」
・3.1 川上と川下、問題発見と問題解決、具体と抽象
・3.2 ２つの思考回路の矛盾による問題点
第４章 SIプロジェクトにおける落とし穴
・4.1 新規テーマの提案はなぜ受け入れられないのか
・4.2 「投資対効果」の罠
・4.3 「事例調査」の罠
(略)
・4.15 なぜこれらの落とし穴は何度でも繰り返されるのか
第５章 組織の成長と「具体と抽象」
・5.1 「会社の進化」と「具体と抽象」
・5.2 外注化の流れを普遍的に捉える
・5.3 組織の変化に伴う必要なスキルの変化
(略)



■著者プロフィール
細谷功：著述家・抽象アーキテクト。株式会社東芝を経て、外資系/日系のグローバル・コンサルティングファームにて業務改革等のコンサルティングに従事した後独立。著書に『地頭力を鍛える 問題解決に活かす「フェルミ推定」』（東洋経済新報社）、『具体と抽象』（dZERO）などがある。

[ブクログ · ★★★★★]

川上と川下の考えが今の構想にぴったりとハマった。

以下は、細谷功『システム開発と「具体と抽象」〜問題発見と問題解決を往復する「思考のメタ化」を身につける〜』と、添付いただいたページ（20〜23%付近）を踏まえて再構成したまとめです。本書は、従来の『具体と抽象』をシステム開発・DX・AI時代へ応用した内容であり、「なぜシステム開発は噛み合わないのか」という構造的な問題を、「具体⇔抽象」の往復という思考法から解き明かしています。

⸻

システム開発と「具体と抽象」

問題発見と問題解決を往復する「思考のメタ化」

全体要旨

本書が一貫して伝えているメッセージは非常にシンプルです。

システム開発の失敗原因は技術ではなく、「抽象と具体を往復できないこと」である。

AIでもDXでもクラウドでも、本質は同じです。

技術が進歩するほど

* 人間は具体作業から解放され
* より抽象的な設計
* 問題発見
* 構造設計

へ仕事が移っていきます。

つまり

ITの歴史とは「抽象度を上げ続ける歴史」なのです。

⸻

① 人間は抽象が苦手

添付で最初に説明されている重要ポイントです。

人間は

「AIを活用したい」

と言われても考えられません。

しかし

「この画面をこうしたい」

と言われると急に理解できます。

つまり

抽象だけでは

思考停止

が起きます。

逆に

具体だけでは

本質が見えません。

この往復こそが思考です。

⸻

② 批評スイッチは具体で入る

人は

「何となく違う」

とは言えます。

しかし

「何が欲しいのか」

は分かっていません。

だから

最初から要件を聞いても

要件は出ません。

⸻

Appleの有名な言葉

People don’t know what they want until you show it to them.

まさにこれです。

プロトタイプを見ると

初めて

* 違う
* ここを変えて
* もっとこう

が出てきます。

つまり

具体物が批評スイッチを入れるのです。

⸻

③ 要件定義は最初から完成しない

本書では

相手の

「何でもいい」

を

完成形として扱ってはいけない

と言っています。

まず

未完成でも

プロトタイプ

試作品

モック

画面

を見せます。

すると

脳が動き始めます。

これは

アジャイル開発の本質でもあります。

完成度を高めるためではなく

相手の思考を動かすため

に作るのです。

⸻

④ ITの歴史は抽象化の歴史

ここは本書の中でも特に重要です。

ITは

具体作業を

どんどん隠してきました。

添付では以下の流れが紹介されています。

⸻

ハードウェア

昔

直接機械語

↓

アセンブラ

↓

高級言語

⸻

高級言語

Java

Python

Rust

Go

など

「どう書くか」

ではなく

「何を実現したいか」

を書くようになりました。

⸻

仮想化

物理サーバ

↓

VM

↓

コンテナ

↓

Kubernetes

↓

OSを意識しない世界

⸻

クラウド

オンプレ

↓

AWS

↓

Azure

↓

GCP

↓

インフラを意識しない

⸻

Serverless

サーバ管理不要

⸻

NoCode

コード不要

⸻

AI

最後は

自然言語だけで

システムを作る方向へ向かっています。

つまり

人間は

具体を書く仕事

から

抽象を書く仕事

へ移っているのです。

⸻

⑤ AI時代は「どう作るか」が価値ではない

本書では

ノーコード

生成AI

を

同じ流れとして説明しています。

昔

どう書くか

が価値でした。

今は

何を作るか

です。

AIは

設計

実装

テスト

コード生成

を担当できます。

しかし

AIには

何を解決するか

は決められません。

⸻

⑥ 具体と抽象を往復する人だけが価値を持つ

抽象だけ

↓

評論家

具体だけ

↓

職人

両方ある人

↓

アーキテクト

本書では

この

往復運動

を

思考のOS

と呼んでいます。

⸻

⑦ 問題発見と問題解決は別能力

非常に重要です。

問題解決

↓

具体化

実装

改善

問題発見

↓

抽象化

構造理解

目的再定義

多くのSI企業は

問題解決

は得意です。

しかし

問題発見

が苦手です。

だから

言われたものは作れるが

提案できません。

⸻

⑧ AI時代は「抽象」が仕事になる

本書の結論はここです。

生成AIは

具体化

実装

コード

ドキュメント

画面

を作れます。

つまり

具体部分は

AIへ移ります。

人間は

* 顧客理解
* 本質理解
* 構造設計
* 問題発見
* 意思決定

つまり

抽象レイヤー

へ移ります。

⸻

本書から得られる示唆

① AIはプログラマーを代替するのではなく、「具体」を代替する

AIが置き換えるのは「コードを書く行為」そのものです。一方で、「何を作るべきか」「何を解決すべきか」を定義する抽象的な設計は、人間の重要な役割として残ります。

② PoC疲れの本質は「抽象→具体→抽象」の循環不足

PoCが成果につながらない原因は、技術検証だけで終わり、目的や事業仮説へ戻るサイクルが回らないことです。PoCは単なる検証ではなく、抽象仮説を具体で試し、得られた学びを再び抽象へ引き上げるプロセスとして設計する必要があります。

③ 新規事業は「要件を集める」のではなく「批評を引き出す」

顧客は最初から正解を言語化できません。そのため、初期段階では完成度よりも「反応を引き出す具体物」を早く提示することが重要です。これはリーンスタートアップやデザイン思考とも整合します。

④ DXの本質はIT導入ではなく、抽象度を上げること

クラウドやAIの導入自体がDXではありません。現場がインフラや実装の細部から解放され、「顧客価値」「業務構造」「意思決定」といった、より高い抽象レベルへ思考を移せることがDXの本質です。

⑤ 経営者に最も必要なのは「具体⇔抽象」の往復能力

経営者はビジョンだけでも、現場の詳細だけでも不十分です。戦略・ビジョン（抽象）と、顧客接点・プロトタイプ・KPI（具体）を高速で往復し続けることが、AI時代の競争優位になります。

⸻

総括

本書は、システム開発の技術書というよりも、「AI時代の知的生産・事業開発・経営に必要な思考法」を体系化した一冊と言えます。

添付箇所から特に印象的なのは、「ITの進化とは、人間を具体作業から解放し、より抽象的な価値創造へ移してきた歴史である」という視点です。この考え方は、生成AIによるコード生成やノーコードツールの普及とも自然につながります。今後、人間に求められる競争力は「どう実装するか」ではなく、「何を解決し、どのような構造で価値を生み出すか」を定義し続ける能力へと一層シフトしていく、というのが本書の中核的なメッセージです。