この本を読んだことが、視野が狭くなっているかもしれない、と気づくきっかけになると思う

具体の良し悪しを判断する拠り所は少数（できればひとり）が構築したコンセプトあるいは哲学。 具体で問題が起きているときに具体で解決するのではなく抽象化して構造を整える。

川上で抽象化する作業は分業ではなく少人数。コンセプトや方針を決めるのに具体はノイズになるってことかしら

アジャイルやプロトタイプの狙いは、単に早く具体物を作ることではなく、「具体⇄抽象」の往復運動をプロセスに組み込むことにある。実際、要件調整でも「つまりこういうこと？」と具体を返して初めて、「そう、それで思い出したけど」と新しい要件が出てくる。具体化は確認というより、相手と一緒にまだ見えていないものを発見するためにある。 一方ですべての具体を知ってから正しいコンセプトを描くことはできない。限られた具体から仮説として抽象化し、具体に落として反応を見て、また抽象に戻る。上司からの資料作成リクエストなんかも、言われたものをそのまま作るのではなく、自分で意図を仮説立てしてラフを作り、当てて、また考える。その往復の速度を上げたい。 ただし、抽象化する能力があればいいという話でもない。そもそも抽象化や俯瞰を評価する組織なのか。権力を持つ人がすぐ具体の話に引き戻す環境では、抽象レベルで構造を考えること自体が難しい。そこが変わらないなら、本にあったように「土俵を変える」のもひとつなんだろう。 抽象→具体は仕事をしていればある程度慣れる。一方で具体→抽象は、意識的にやらないとなかなか鍛えられない。相手がいまどの抽象度で話しているのかを捉え、自分で階層を上げ下げする。その往復の回数と速度を上げることを意識したい。

アジャイルやプロトタイプは「具体⇄抽象」の往復運動をプロセスに組み込むことが狙い。 それぞれの思考にはそれぞれの能力が必要。

具体を知らなくても俯瞰したものを描けるというけれど、それが通用するかは組織や文化や評価制度次第ですよねという気もする。声のでかい人は具体が好きだし

具体的なものを見るまで、クリティカルなコメントや指摘は返ってこない。がゆえにアジャイル的に

はじめにだけ読んだ 具体がAIに置き換えられてくは言われがち 抽象化がSIの仕事になっていくか… むしろそのために詳細を知る必要があるって感じなのかな

具体抽象の行き来に関する思考の仕方がわかりやすく説明されている。SI業界を元に説明されているため、読む人によってわかりやすさは変わるかもしれない。 個人的に本のカバーの質感が好き

経営層と担当者、コンサルとエンジニア、なぜ会話が噛み合わないのかという積年の疑問が見事に言語化されている。ゴリゴリJTC社畜のわたしは、経営からの「AI使え」の圧力に、具体→具体の回答を繰り返していることに気づく。