細谷功のレビュー一覧
-
Posted by ブクログ
東芝からEYに転じたコンサルタントの著者が俯瞰視点の持ち方のノウハウをまとめた本。機能と仕様との関係は、機能を具体化したものが仕様であり、複数の仕様があり得ることはシステムエンジニアリングでも仕様の性能規定化でも学んだ。しかし、具体と抽象という切り口で、コミュニケーションの問題、上司と部下の関係、他人にレッテルを張ることで自分と差別化を図ろうとする行動、DoubleRing（仕事と遊び）の９パターンの関係がいかに主観に左右されるかといった、仕事や人生でであうニ項対立問題のほとんどが説明される。具体に生きる人は具体であり、抽象に生きる人は抽象であることも多い中で、以下に具体と抽象をエレベーションし、他人をそのエレベーションに巻き込んでいけるかがポイントなのではないだろうか。
-
-
-
-
-
-
-
Posted by ブクログ
「具体と抽象」を読んでいる人や、自然と”抽象”（本書で言う川下）のマインドセットが付いている人にはやや食傷気味かもしれない。
ただし、本書の想定読書者であるシステム開発・運用に携わる人の大多数が「具体と抽象」を読んでなかったり、あるいは読んだけど腹落ちできず”川下”の仕事に徹してるんじゃないだろうか。
なので、このくどさはあえて演出しているものではないかと思う。
SIerやコンサル、情シス系の仕事をしている人は必修にしてもいいんじゃないだろうか。本書で狙う通り汎用性が非常に高い（魚ではなく釣り方...ですらなく川の構造）
ーーーーーーーーーーーーーーーーーーーーーーーーーー
目標：言われたことの遂行→能動的提案力
課題：抽象概念の取り扱い
打手：具体と抽象の行き来
川下（言われたことの遂行）のプロとしてのスキルが
川上（能動的提案）の足枷になる
受動的問題解決→能動的問題発見
知識＝分解能を上げること＝具体の引き出し
人間の欲求は曖昧（抽象）
プロダクトや具体的成果を見て初めてそれがマッチするかどうか評価するスイッチが入る
→「なんか違うんだよね」と言われる構造
→ガラケーユーザの要望からは絶対にスマホは生まれない
打手：未完成の具体を、なる早でもっていく。 Quick and Durty
ITの進化の歴史＝抽象化の歴史
複雑性の排除、
「何ができるようになったか」＆「何を考えなくて良くなったか」
WHYの2つの意味
過去に対するWHY：原因
経験や事実、なぜなぜ分析
未来に対するWHY：目的
抽象化：未来方向へのWHY
具体か：HOW
p95
技術課題→業務課題→経営課題
川上：
不確実性高、混沌、境界不明瞭、非分業、抽象度高、蓄積なし、少人数、質重視、統一指標なし、属人的
川下：
不確実性低、秩序、境界明瞭、分業、抽象度低、蓄積あり、多人数、量重視、統一指標あり、非属人的
潜在的問題・顕在的問題
潜在的問題：
・見つけようとしないとでてこない
・改革機会
・顧客が言語化できてない
・内発的
・未来志向
・多数の仮説を立てる
品質と川上・川下
川上：ヒットすれば儲け物（例：野球の打席）、攻め
川下：高得点が当たり前、守り
→川下の発想（品質要求）は川上の仕事はできないし、そもそもそれは求められていない。
”統一感のあるシステムは「一人で全体を設計する」ことから生まれる”
専門家＝素人と違うものの見方ができる、そのための引き出しが豊富 -
-
-
Posted by ブクログ
ネタバレ思いの外、期待以上に良かった。哲学的な話だけど、ヨシタケシンスケさんの絵も手伝ってから読みやすく。
音楽のCDアルバムがなくなって1曲ずつの切り売りになった。間違いや無駄はないが、偶然の出会いがなくなった。これと同じ理由で、旅行のパッケージツアーをどちらかというと初心者向けと思っている人にもたまには参加してみて偶然乗る出会いをしてみてほしいという話がやたら響いた。
具体的と抽象的の話もまた同じく。具体的な例をできる人が頭いいという印象が強いけど、人間だからこそ抽象化することができるとのこと。確かにお昼食べに行こうと言われるのをあの店のアレを食べに行こうとは誘わない。
形から入るのを馬鹿にしがち、という話もまた。確かに形を作っている時点で、ただ考えてる人よりはよっぽど進んでる。
特に自分の思考に当てはまるところが多く、面白かった。 -
Posted by ブクログ
ネタバレ川上と川下の考えが今の構想にぴったりとハマった。
以下は、細谷功『システム開発と「具体と抽象」〜問題発見と問題解決を往復する「思考のメタ化」を身につける〜』と、添付いただいたページ（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によるコード生成やノーコードツールの普及とも自然につながります。今後、人間に求められる競争力は「どう実装するか」ではなく、「何を解決し、どのような構造で価値を生み出すか」を定義し続ける能力へと一層シフトしていく、というのが本書の中核的なメッセージです。 -
-
-
-
-
-
Posted by ブクログ
具体と抽象、なんとなく意識していたことを言語化してくれてありがたい一冊だった。ものごとや、小説・漫才・映画などを構造的に読み解いてみるのが好きなんだけど、めっちゃ役立ちそう。ほか、なぜ人は分かり合えないのかといったコミュニケーション、どうして仕事がうまく行ってないのかといった課題解決、優先順位の付け方などにも活かせると思った。
とはいえ、書かれていることはだいぶ抽象的。仕事や生活に活かすのは自分次第だと思う。
単なるハウツーの本ではなく、具体と抽象で階層的に教えてくれる。
より具体的な方が良いこと、より視座を上げて抽象的に考えないと最適解が見えてこないこと、など色々な局面で行き詰まった時に思い出せるようになりたい。
言い争いや喧嘩はもしかしたら、考え方が違うのではなく、前提条件を共有できてないとか、そもそも抽象レベルの不一致が原因かもしれないというのは、なるほどなと思った。面白い。
抽象するとは、それ以外の要素の具体を捨てること。 -
Posted by ブクログ
具体と抽象。
知識と思考。
5W1HのうちWHYとHOWだけが、階層を移動する思考の言葉だ。他は知識の言葉である。
具体→WHY→抽象→HOW→具体。
思考はこの往復運動でできている。
AIに乗っ取られてはいけないのは、まさにこのプロセスだ。だからこそ読書が効く。著者が何年もかけた往復運動を、読者は数時間で追体験できる。
学校の勉強においても、抽象化を取り入れた勉強は立体的になり、すべての学問がつながって見える。
人の知力は、横軸が知識量、縦軸が抽象化力のピラミッド。
知識の壁はガラス張りだが、抽象の壁はマジックミラーだ。下から上は見えない。
だからすれ違う。
帰納・演繹は、論理構造としての具体と抽象。 -
Posted by ブクログ
子供に読ませたい
具体と抽象について、130pでまとめている本なんだけど、良かった。
エンジニアだから普段抽象的なことばかり考えてる人間なのかと自認していたけど、抽象について認識を改めさせられる本だった
特に印象に残っているのは、
・抽象から具体にはおりづらい（方程式や言葉を使うな） ボドゲでいうカタカナーションとか、そういうのを試すゲームもあるよね
・抽象はメッセージ性が弱いし、実行可能性は低く聞こえる。具体は短期的だし、すぐに行動可能だし、解釈の自由度が狭い。
解釈の余地があるから感情に訴えづらい。でも具体の方が強い。抽象は解釈の余地があるから結果をぼかせる。政治家が演説で、レトリックを駆使して具体と抽象を行き来して観客をアジテートするのはそういうことか。
・意思決定の人数は抽象レベルが高い方は少ない方がいい。これは、デザイナーとか建築家に顕著で、尖らせたものを作りたいから意思決定は少ない方がいい。逆に現場は多くて目があるほうがレベルの高い品質の良いものができたりする。焦点がボケて角の丸くなった凡庸なものに近づいていく。多数決に効果がある。
・コンセプトがはっきりしている
哲学や理念コンセプトといった抽象概念がもたらす効果は、バラバラになりがちな具体レベルの事象に統一感や方向性を与える。
・アナロジーはパクりと異なる。表面的な真似は特許侵害とかになるけど、抽象的なアイデアを真似するレベルは問題ない。
・抽象は嫌われやすい。その世界に入ると抽象概念が自然で不可欠なものになる。動物から見ると我々も抽象的だ。
高尚な理は卑近のところにあり。
国語と算数ができない人は抽象化の学習に失敗している。難解な長文を要約したり、自分の考えをまとめたりする練習をするのは、抽象と具体の往復運動という頭の体操のためである。