システム開発と「具体と抽象」 ～問題発見と問題解決を往復する「思考のメタ化」を身につける～（技術評論社） [電子書籍]

システム開発と「具体と抽象」 ～問題発見と問題解決を往復する「思考のメタ化」を身につける～（技術評論社） の 商品概要

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

• 目次

  はじめに
  「魚」か「釣り方」か
  
  第1章 SI業界が抱える課題
  1.1 「言われたことは得意だが，提案が不得意である」
  1.2 なぜ「提案型人材」が少ないのか
  受託開発とSES契約
  1.3 受動的問題解決から能動的問題発見へ
  1.4 OSのメタ化が必要
  
  第2章 「具体と抽象」とは
  2.1 具体と抽象の基本
  具体が善で抽象が悪なのか
  具体と抽象とは
  「レーザーポインタ」と「懐中電灯」
  「なんでもいい」が「これじゃない」に変わる具体と抽象の不条理
  2.2 ITと「具体と抽象」
  ITそのものが具体と抽象の産物
  ITにおける抽象化のもう一つの意味
  ITの進化は「抽象度を上げて複雑性を隠す」歴史である
  「具体と抽象」とオブジェクト指向
  2.3 「手段と目的」への応用
  「手段と目的」の関係も「具体と抽象」の関係
  「5W1H」の構造：Whyは次元が違う問いである
  「2つのWhy」とは
  思考のOS：具体と抽象の往復運動
  「反応」する人と「思考」する人の違い
  目的とは「使い手視点」で考えること
  目的とは経営視点で考えること
  「単なるデジタル化」とDXとの相違
  
  第3章 SIプロジェクトと「具体と抽象」
  3.1 川上と川下，問題発見と問題解決，具体と抽象
  本書における「川上（上流）」と「川下（下流）」の定義
  仕事（問題解決）とは抽象から具体への変換作業
  川上と川下の特性の違い
  本書における問題発見と問題解決の定義
  顕在的問題と潜在的問題
  川上の問題発見と川下の問題解決
  問題発見から問題解決は「マトリョーシカ構造」
  問題発見（川上）と問題解決（川下）の仕事の特性の違い
  3.2 2つの思考回路の矛盾による問題点
  「守り」と「攻め」の違い
  キャッチャーミットとプロテクターをつけて打席に立つ
  「底上げ」という言葉が示すもの
  完璧主義と顧客からの信頼が「最大の負債」
  コップに水が「半分しか入っていない」か「半分も入っている」か
  
  第4章 SIプロジェクトにおける落とし穴 ～具体と抽象の観点から～
  4.1 新規テーマの提案はなぜ受け入れられないのか
  4.2 「投資対効果」の罠
  4.3 「事例調査」の罠
  「実例」と「具体例」の違い
  4.4 それは本当に目的なのか
  「見える化」「可視化」が最終目的であることはない
  「○○のレビュー」
  「○○データの収集，分析」
  4.5 「2つのピザ」の話
  4.6 「統一感」の正体
  4.7 「一人で考えるためにはすべて知らなければならない」という幻想
  4.8 ICTの世界が建築の世界から学べること
  4.9 アーキテクトは一人だけではない
  4.10 なぜ「この業界（業務）は特殊だ」と思うのか
  4.11 PoC疲れの正体
  4.12 コストセンター型PoCのジレンマ
  4.13 「アジャイル開発」の阻害要因
  決定論と確率論の違い
  直列的プロセスと並列的プロセス
  情報を集めてから動くか，動きながら情報を集めるか
  思考回路のギャップによる問題点
  ここでも手段の目的化
  4.14 「具体と抽象」によるコミュニケーションギャップ
  経営者と担当者
  コンサルタントとエンジニア
  エンジニアと経営者
  4.15 なぜこれらの落とし穴は何度でも繰り返されるのか
  
  第5章 組織の成長と「具体と抽象」
  5.1 「会社の進化」と「具体と抽象」
  縦横両方向の細分化
  ルールや規則も増える一方
  性善説から性悪説へ
  外向き志向から内向き志向へ
  5.2 外注化の流れを普遍的に捉える
  5.3 組織の変化に伴う必要なスキルの変化
  個性的から没個性的へ
  加点主義から減点主義へ
  創造から管理へ
  5.4 専門家のジレンマ
  5.5 不可逆的変化と川の流れの関係
  5.6 思考のOSをメタ化するとは
  5.7 「混ぜるな危険」
  
  おわりに
  AIが代替していくのは「SIの具体」である
  究極の抽象化とはSI自身のメタ化
  自分たちの仕事をなくす仕組みを考える
  

システム開発と「具体と抽象」 ～問題発見と問題解決を往復する「思考のメタ化」を身につける～（技術評論社） の商品スペック