システム開発と「具体と抽象」を読んで今後のキャリアについて考えてみた

本の概要

「具体と抽象」に関する本を数多く執筆されている細谷功さんが、「システム開発」の文脈で具体と抽象について論じた一冊です。

https://gihyo.jp/book/2026/978-4-297-15790-6

IT業界の中でも特にSI業界の構造や課題に焦点が当てられています。

とはいえ登場する事例はSI特有のものではなく、自社開発企業などでも起こりうる構図なのかなと思います。

印象に残った内容

本の要旨は、「具体だけでなく抽象の視点も持とう」ということです。

私はSI業界のエンジニアではないですが、参考になる部分が数多くありました。

以下、私が特に印象に残った項目です。

具体を提示することで判断を促す

「昼何がいい？」と聞いたら「なんでもいい」と言われたので、具体的な案（e.g. 牛丼）を提示したら「それはあまり…」と言われたエピソードから主張が展開されています。

ここで主張されているのは、人間は抽象（e.g. 「昼何がいい？」）を判断するのが苦手だが、具体（e.g. 「昼は牛丼でいい？」）を判断するのは得意ということです。

この人間の特性が活かされているのが、「アジャイル開発」です。アジャイル開発では最初から完璧は求めません。まず小さな「具体」を作った上でフィードバックを求め、そのフィードバックをまた落とし込んで開発のループを回します。人間は「具体」の良し悪しを判断することは得意なので、スピーディに開発を進めることができるのです。

私は今まさにアジャイルで開発を進めていますが、「なぜアジャイルが有効なのか」についてここまで言語化はできていませんでした。この項目を読んだことで、アジャイルの有効性について改めて理解を深めることができました。

ユーザー視点はなぜ必要か

SIに限らずあらゆる業界でそうだとは思いますが、「ユーザー視点を考えなさい」と事あるごとに言われます。

私自身、「それはそうだよな。ユーザー視点を考えることは大事だよな」と思いながらも、「なぜユーザー視点を考えることは大事なのか」について深く考えてはきませんでした。

なぜユーザー視点を考えることは重要なのか？それは、「ユーザー視点（抽象）」を考えることで、より多くの「手段（具体）」が見えてくるからです。

例えば、ユーザーから「ここのボタンを青くしてほしい」と具体的な施策を頼まれたとします。

「具体の世界」を生きている人はこの言葉を真に受けてボタンを青くします。

もちろんそれでも間違いではないのです。ただ「抽象の世界」を生きている人はより高次の視点で考えます。「なぜこのユーザーはボタンを青くしてほしいのか」と。そうすると、「ボタンをより見やすく、押しやすくしたい」というユーザーの「本当の目的」が見えてきます。そこまで分かれば、また別のより良い施策（e.g. ボタンを大きくする、ボタンの位置を変える など）も提案できます。これがユーザー視点で考えることの効果なのです。

AI時代に生き残る人とは？

本の中で以下のように書かれています。

AIが最も得意とするのは定義された課題を具体化する（How）プロセス

AI時代に消えるのは職種ではありません。「考えているつもりで、実は与えられた具体を処理しているだけの部分」です。

つまり、AI時代に消えるのは特定の職種ではありません。消えるのは、どの職種にもある「具体を処理しているだけの部分」です。（もちろん、ある職種の仕事が全て具体の処理なのであれば、その職種自体が消えるでしょう）

では、どうすれば良いのでしょうか？本の中では以下のように書かれています。

これから問われるのは、具体をこなす力ではなく、抽象化し、問題を発見し、構造を設計する力です。

顧客からの要望を具体化する力。それは川下の強みです。しかし、その一歩手前で「そもそも何を目指すべきなのか」「本当に解くべき問題は何か」を考える力こそが、川上への入り口です。

つまり、課題を抽出し抽象化するという、AIが苦手な領域のスキルを磨くことが大事だということです。

今後のキャリアと身に付けるべきスキルについて考えてみた

この本を読んだ上で、自分なりに今後のキャリアや身に付けるべきスキルについて考えてみました。

なお、あくまでSREとして働いている私の個人的な話なので全ての人に当てはまるわけではありません。

参考程度にお読みいただければと思います。

まず頭に入れておく必要があるのが、「AIは具体を代替していく」ということです。これは間違いない流れでしょう。要は、問題解決（How）の具体の部分はAIが担っていくということです。

ただ具体は代替されるといっても、すぐに全てが代替されるわけではないです。真っ先に代替されるのは、「中途半端な具体」だと考えています。「高度（ハイレベル）な具体」はしばらくは残るでしょう。それは現場の感覚としてもあります。

また具体が代替されたからといって、具体のスキルが完全に不要になるわけではないです。いくら抽象を考える仕事が増えたところで、「具体的な作業を指示する仕事」は残るからです。何も技術が分からない状態でAIに的確な指示を出すことはできません。

従って具体のスキルは引き続き向上させていくことが必須です。とはいえこれまでの具体のスキルだけでは通用しなくなります。抽象のスキルを身に付け、比重を増やしていく必要があります。

磨いていくスキル

そんな中で私が力を入れていきたいと考えているのは以下のスキルです。

高度な具体のスキルとしては、特に低レイヤーの領域を磨いていきたいと考えています。単純に自分が興味のある分野なのと、低レイヤーの高度な具体を磨いておけばその上位レイヤーの具体は容易にキャッチアップできるようになると考えているからです。また、後で述べるオブザーバビリティを深める上でも低レイヤーの知見は効いてきます。

抽象のスキルとしては、システムアーキテクチャやプロダクトマネジメント周りを磨いていきたいと考えています。これは単純にAIが代替しづらい領域だからです。

さらにこれら（高レイヤー・低レイヤー）にプラスした専門性として、「オブザーバビリティ」に関するスキルも磨いていきたいと考えています。

多くの人が抽象を定義して具体をAIに任せる時代になった場合、抽象と具体を繋げるレイヤー（オブザーバビリティ）の需要は上がると考えているからです。例えばWhyの部分をエンジニアが考えてHowの実装の部分は完全にAIに任せたプロダクトがあるとしましょう。AIに任せているので、当たり前ですがエンジニアは実装（具体）の詳細は把握できていません。そんな中でシステム障害が起きたらどうなるでしょうか？原因が特定できずに途方に暮れる姿が目に浮かびます。

実装をAIに読ませればいい、という話でもありません。実際のトラフィックやレイテンシ、壊れ方といった実行時の事実は、そもそもコードの中に書かれていないからです。しかもAIで開発速度が上がるほどサービスの数も変更の頻度も増え、観測しないと分からないことは増える一方です。

そのギャップを埋めるのがオブザーバビリティです。オブザーバビリティを高めることで、具体の部分が多少把握できなくなっても、システムに対するエンジニアの解像度を補完することができます。

その意味でオブザーバビリティのスキルは磨いていきたいです。

具体的なキャリア

では具体的にどういうキャリアを目指すのかというところです。

個人的には、ITコンサルやSIerの上流工程のように、抽象だけを扱って具体は他者に渡す働き方には、あまり惹かれていません。

自分が関わった範囲では、間に人が増えるほど「作って、出して、直す」のループが遅くなると感じました。

そしてこのループの速さは、AI時代にはより効いてきます。作る部分をAIが担うぶん、ボトルネックは「これでよいか」を判断する側に移るからです。だとすれば、間に人が増えて判断が伝わるまでに時間がかかる構造は、そのままループの遅さになります。

直近は自社開発の企業で高レイヤーにも低レイヤーにも関われるポジションで、スピード感を持って独自のプロダクトを生み出せる環境に身を置きたいと考えています。

その上で（ピープルマネジメントにはあまりモチベーションが湧かないので）テックリード、スタッフエンジニアなどの技術上位職を目指したいと考えています。

とりあえず日常の業務に活かしていく

具体的なキャリアの話になってしまいましたが、まずは目の前の業務に対する意識を変えていくことから始めていきたいです。

何か依頼を受けたときに、「なぜ？」「何のためにやるのか？」「そもそも必要か？別の方法はないか？」を考えるなど、より抽象的なレイヤーで物事を考える癖を付けていきたいです。要は、Howに行く前にまずはWhyを問うてみるということです。

この本で学んだことを活かして抽象化スキルを磨き、AI時代も生き残っていけるエンジニアを目指したいと考えています。