具体と抽象をテーマにした著書が多い細谷氏の、システム開発に特化した具体と抽象本です。 もともと他の著書も好きだったのと、自分自身がシステム開発を生業としているので「これは読まねば！」と意気込んで読みました。
↓「具体と抽象 ―世界が変わって見える知性のしくみ」「13歳から鍛える具体と抽象」の感想文↓ mizzsugar.hatenablog.com
AI時代にリーダーを育成する立場として、悩んでいた部分の原因の一部について書かれていたので共感しました。ただ、本著には「どうすれば解決するのか」をあえて明示していないので、明日から行動できるような答えを求めている方には物足りないかもしれません。しかし、AI時代に求められる能力についてぼんやり不安を抱えている人には、どんな背景によってどんな思考が求められているのかヒントを得られるかもしれません。「答えを言われないと動けない」から脱したい人にも刺さるかもしれません。
「言われたことは得意だが、提案が不得意」
本著はSI業界の課題として「言われたことは得意だが提案が不得意」なことを述べています。その要因として、上意下達の業界構造とそれによる「言われたことを言われた通りにやる」ための問題解決型の思考回路を上げています。 今までの業界構造ではそれで問題なかったけれども、企業の系列構造が崩れてきたこととAIの台頭によって変わってきました。提案して仕事を取ってくることが求められるようになり、問題発見型の思考が必要になってきました。
抽象思考で問題発見、具体思考で問題解決
何が問題か、なぜやるのか、など形がないものを扱う問題発見には抽象思考が求められます。一方、どう作るかなどゴールが決まっているものをあつかう問題解決には具体思考が求められます。 抽象ではWhyを問い、具体ではHowを問うともいえます。 抽象思考と具体思考は完全に分かれているのではなく、グラデーションです。ITのPJに例えると抽象的なものから、企画→要件定義→基本設計→詳細設計→実装のように徐々に具体的な内容になっていきます。
グラデーションになっているからこそ、1段階上の抽象度で「なぜこのタスクをやるのか」「この機能の目的は」など考えることが大切です。設計書に書かれていることを着実に実装する前に、「なぜこの機能があるのか」「どんな要望があるのか」など抽象度をあげて目的を考えると、どんなことに考慮して実装やテストをすべきか見えてきて出戻りや考慮漏れが減らせるのではと思いました。
問題発見と問題解決は思考のOSが違う
問題解決型の人材が問題発見型になるのが上手く行かないのは、そもそも思考のOSが違うからだと述べています。いわば、あるPCのOSをMacOSからWindowsOSにリプレースして動くようにしろと言っているようなものです。 それでも問題発見と問題解決を場面によって使い分けないといけません。そのためのイメージモデルとして「メタ化」が提唱されています。1段階上の段階の思考モデルとして下位モデルである具体と抽象を切り替えます。
野球で言うと、問題発見型はピッチャーで課題解決型はキャッチャー。両方同時にやれというのは防具をガチガチに装備しながらボールを上手く投げれないのと同じです。切り替える必要があります。同時にやれと言っているような指示を出さないように気をつけないとなと思いました。
AIが「SIの具体」を代替していく
「ITの進化は抽象度を上げて複雑さを隠す歴史だ」と述べられています。例えばOSはハードの違いという具体を吸収しました。今の時代だと、生成AIは今までに人間が担ってきた設計や実装の一部という具体を肩代わりしつつあります。定義された問題の解決する今までSIがやってきた役割がAIによってコモディティ化してきているからこそ、抽象化し、問題発見し、構造を設計する力が問われます。
リーダー育成を顧みて思ったこと
メンバーとして与えられたタスクを実装・テストする業務が中心だったところからリーダーとして問題を見つけて定義する立場で苦戦するのは、思考のOSが違うから当然なのだと腑に落ちました。
そして、これは生まれ持っての才能に依存する能力ではなく具体と抽象を行き来するトレーニングでカバーできそうな感触があります。例えば、ある業務で受け取ったフィードバックを一般的な教訓に言語化して抽象化し別の業務ではどう行動するか具体で考えることは、どの役職・立場でもすぐにできそうなトレーニングかなと思います。
