システム開発と「具体と抽象」の書評｜言われたことの先を考えるようになった

『システム開発と「具体と抽象」』は、何かに悩んでいて手に取った本ではありません。タイトルを見て、単純に興味がわいたので読みました。

結論から言うと、言われたことだけの仕事をこなしている、と感じている人に合う1冊です。開発の手法やツールの本ではなく、システム開発の仕事を「具体と抽象」の目で見直す本です。

いちばん刺さったのは「川上と川下」の話でした。そこから何を変えたのかを書きます。

システム開発と「具体と抽象」はどんな本か

書誌情報は技術評論社の書籍ページによるものです。著者は、ビジネス書『具体と抽象』の細谷功さんです。章は次の5つでできています。

第1章は「言われたことは得意だが、提案が不得意である」というSI業界の課題から始まります。第2章で具体と抽象の基本を押さえ、第3章以降で、その考え方をシステム開発の現場や組織に当てはめていく作りです。

読んだきっかけ｜悩みではなく、単純な興味

刺さったところ｜川上と川下の話

いちばん刺さったのは、第3章「SIプロジェクトと「具体と抽象」」の「3.1 川上と川下、問題発見と問題解決、具体と抽象」です。この節には「川上と川下の特性の違い」「川上の問題発見と川下の問題解決」といった見出しが並んでいます。

ざっくり言うと、仕事には、何が問題なのかを見つける川上と、決まった問題を解く川下がある、という話です。

見出しには「問題発見から問題解決は「マトリョーシカ構造」」ともあります。技術評論社の紹介記事によると、どの仕事にも、問題を見つける川上と問題を解く川下が入れ子で入っている、という意味です。上流工程・下流工程のように、工程や役割で分かれているだけではありません。

エンジニアの仕事に当てはめると、たとえばこうなります（私の例）。

「自分は実装担当だから川下」と決めつけず、目の前の小さな作業の中にも川上がある、と気づけるのがこの見方のよいところです。

川下が得意な人ほど、川上でつまずく

第3章には「3.2 ２つの思考回路の矛盾による問題点」という節があり、「「守り」と「攻め」の違い」「完璧主義と顧客からの信頼が「最大の負債」」といった見出しが並びます。

紹介記事では、SI業界では長く「川下から川上へ」と言われてきたのに実現していない理由として、指示されたことを高品質・高効率にこなす考え方が、正解のない川上ではかえって邪魔になる、と説明されています。本の冒頭には、優れた問題解決者ほど当てはまる9項目のチェックリストがあるそうです。

読んでから変えたこと｜相手が何を求めているのかを深く考える

読んでから変えたのは、言われたことだけで終わらせず、相手が何を求めているのかを深く考えることです。言われたことをそのまま作るのは川下の仕事です。その手前で、「この依頼で、相手は本当は何をしたいのか」と一段抽象に上がってから、作るものを決めるようにしました。

本の中では、第2章「2.3 「手段と目的」への応用」で、手段と目的の関係も具体と抽象の関係だ、という話や、「「2つのWhy」とは」「目的とは「使い手視点」で考えること」といった節が出てきます。

考える順番

依頼を受けたときの考え方を、流れにするとこうなります。

たとえば、こんな依頼

説明用の例です。「この画面の一覧を、CSVでダウンロードできるようにしてほしい」と頼まれたとします。

• 言われたことだけ：CSVのダウンロードボタンを付けて終わり
• 目的まで考える：「CSVで何をするのか」を聞く。毎月Excelで集計して、会議で推移を見ているなら、集計済みの表やグラフを画面に出すほうが、相手の手間は減るかもしれない

どちらが正解かは、目的しだいです。CSVが本当に必要なこともあります。大事なのは、作る前に一度「何のために」に上がって確かめることです。

ほかに読みどころになる3つの話

「なんでもいい」は「見るまで決められない」

第2章には「「なんでもいい」が「これじゃない」に変わる具体と抽象の不条理」という見出しがあります。「なんでもいい」と言われて案を出したら、「これじゃない」と返される。開発でもよくあるすれ違いです。

紹介記事によると、人は抽象的な問いには答えにくく、具体を見せられると「これは違う」とすぐ判断できる、という話です。だから「なんでもいい」は「具体を見るまで決められない」と受け取り、作り込む前に未完成の試作を早めに見せて反応をもらう。アジャイル開発はこの性質を生かした進め方だ、とも書かれています。

相手が何を求めているかを考えるとき、聞くだけで分からなければ、小さく作って見せるのも1つの手だということです。

具体派と抽象派は、お互いがこう見えている

第4章「4.14 「具体と抽象」によるコミュニケーションギャップ」には、「経営者と担当者」「コンサルタントとエンジニア」「エンジニアと経営者」という見出しがあります。

どちらが正しいという話ではなく、お互いがこの構図に気づいていないことが問題だ、というのが紹介記事の説明です。仕様の話がかみ合わないとき、相手と自分のどちらが具体の話をしていて、どちらが抽象の話をしているのかを見ると、整理しやすくなります。

AIが代わりにやるのは「具体」

「おわりに」には「AIが代替していくのは「SIの具体」である」という見出しがあります。紹介記事でも、生成AIが得意なのは決まった課題を具体にすることで、コーディングのような実装からAIに置き換わっているのは偶然ではない、と説明されています。人に残るのは、あいまいな状況から問題の形を言葉にする川上のほうだ、という見方です。

私は毎日Claude Codeを使って開発しています。AIに実装を頼むときも、何を作ってほしいかを言葉にするのは自分です。AIへの頼み方はClaude Code本おすすめ5選やClaude CodeによるAI駆動開発入門の書評でも書いています。

合わなかったところ｜特になし

合わなかったところは、特にありませんでした。注意点を挙げるなら、例の多くがSIプロジェクト（受託開発やSES）の現場の話であることです。プログラミングの技術を学ぶ本ではありません。

今のレベル別の読み方

272ページなので通して読める厚さですが、今の自分に合わせて先に読む章を決めると入りやすいです。

向いている人・向いていない人

• 向いている人：言われたことだけの仕事をこなしている、と感じている人。SIerやSESで、決まったものを作る側にいる人
• 向いていない人：開発の手法やツールの具体的な使い方を知りたい人。この本は仕事の考え方の本で、技術の手順を学ぶ本ではありません

あわせて読みたい

• アジャイルのスプリントとは：第4章「「アジャイル開発」の阻害要因」とあわせて
• Javaの抽象クラスとは：第2章「「具体と抽象」とオブジェクト指向」の、コードでの具体例
• SESを辞めたい理由：第1章の「受託開発とSES契約」の現場側の話

私の前職はSESで、そのあと自社開発に移りました。経歴はプロフィールに書いています。読んだ本はほかにも、トムの本棚に並べています。

よくある質問

Q. 細谷功さんの『具体と抽象』を読んでいなくても読めますか？

読めます。第2章「「具体と抽象」とは」で、具体と抽象の基本から説明されています。

Q. エンジニアでなくても読めますか？

読めます。プログラミングの知識がなくても読める内容です。ただ、例はシステム開発の現場（SIプロジェクト）の話が中心なので、開発に関わっている人のほうが、自分のこととして読みやすい本です。

Q. 電子版はありますか？

あります。技術評論社の書籍ページでは、Kindle・楽天kobo・Gihyo Digital Publishingなどで買えると案内されています。