『システム開発と「具体と抽象」』を読んで、要件定義の見方が変わった話
目次
いま入っている案件で、基幹システムの要件定義と基本設計をやっている。顧客からの要望が毎週のように積み上がっていくタイミングで、細谷功さんの システム開発と「具体と抽象」 を読んだ。
システム開発と「具体と抽象」これが今の自分に刺さりまくった。一番残ったのは、問題発見と問題解決では、そもそも搭載しているOSが違うということ。そして自分は、顧客の要望という「具体」を捌くことに追われて、その奥にあるWhyを問えていなかったということ。刺さったところを、自分の現場に引きつけて書いていく。
提案ができないのは構造の問題だと思っていた
この本、いきなりSI業界への耳の痛い話から始まる。決められた仕様の通りには作れるが、それ以上のことはできない（やらない）。
正直、最初は「いやいや」と思った。受託開発って決められたこと以外はむしろやっちゃいけない世界だし、言われた通りに作っていれば売上も利益も上がる契約構造なんだから、提案するインセンティブが弱いのは当たり前で。個人の能力っていうより、構造の問題じゃないの？と。
ただ読み進めると、その構造ごと問われてるのが分かってくる。AI中心の最近のDXは、業務のやり方を新しい技術に合わせて最適化するっていう逆の発想が要る。で、ITとAIの知識を持ってる人材は開発側に多いんだから、開発側から業務のやり方ごと提案していくしかない。構造のせいにして終われる話じゃなかった。
長年受け身でやってきた人にいきなり提案しろって言うのは「高校までメイク禁止だったのに、社会人になったらメイクは必須と言われるようなもの」っていう例えがあって、これが妙に刺さった。姿勢の問題じゃなくて、思考回路そのものを切り替える必要があるということ。
問題発見と問題解決では搭載しているOSが違う
この本の中心はここだと思う。川上の仕事は問題発見で、アウトプットは「問い」になる。川下の仕事は問題解決で、アウトプットは「答え」になる。問題発見は具体から抽象へ、問題解決は抽象から具体へ。問題が定義された瞬間に、ベクトルが反転する。
問題にも2種類ある。顕在的問題は顧客も認知してて、依頼として降ってくるもので、正解がある。潜在的問題は顧客自身が言語化できてなくて、仮説を立てて能動的に提案するしかない。「AIで何かやりたい」みたいなふんわりした要望は、潜在的問題を引き出す絶好のチャンスらしい。今までは「ふんわりしてて困る」としか思ってなかった。
自分に当てはめると、問題解決のOSはそれなりに動いてる気がするけど、問題発見のOSは全然スペックが足りてない。十分な情報が揃ってから動くっていう発想が染み付いてると、不十分な情報のまま仮説を膨らませることに抵抗を感じてしまう。この抵抗感がOSの違いなんだと思う。
デジタル千円札を自分も作っていた
この本で一番効いたのがこの例。お金を具体レベルでデジタル化すると、千円札がデジタル千円札に変わるだけっていう滑稽な産物が生まれる。「人々の共通の価値を交換するもの」って抽象化してからデジタル化するから、PayPayみたいなサービスが生まれる。具体から具体への置き換えは、トランスフォーメーションでも何でもないということ。
で、自分の過去を振り返ってみると、Excelをそのまま画面に置き換えるっていう同じことをやってしまった気がする。顧客が口にする要望をそのまま作るのは一見顧客志向っぽいけど、なぜやりたいのか、何を達成したいのかに踏み込まない限り、出来上がるのは個別最適の局所解にとどまる。耳が痛い。
Whyには過去向きと未来向きがあるっていう話も良かった。なぜ障害が起こったのかっていう過去向きのWhyは、エンジニアには馴染みがある。でも、それで何を達成したいのかっていう未来向きのWhyは、意識しないと問えない。要件定義で問うべきなのは後者なんですよね。
Xでレスバが起こる理由も具体と抽象で説明できる
この本では、具体をレーザーポインター、抽象を懐中電灯に例えている。具体派は狭いけど濃い世界を見ていて、抽象派は薄いけど広い世界を見ている。だから具体派からは抽象派が「薄っぺらくて何も分かってない」ように見えるし、抽象派からは具体派が「視野が狭い」ように見える。現場の人とマネージャーや経営層のすれ違いも、だいたいこの構図で説明がつく。
これを読んで思ったのが、Xでレスバが起こる構造ってまさにこれなんじゃないかということ。広く浅く60点を取りに来ている発言に対して、自分が絶対に勝てるほんの一部の狭い土俵で勝負を挑んで、勝った気になって冷笑する。でも抽象で見てる側からすれば、ほんの一部の話だから痛くも痒くもないし、仕掛けた側はそのことに気づいていない。
大事なのは、自分を具体派か抽象派かのどっちかに二極化することじゃなくて、いま自分はどっちのモードで見てるのかをメタ認知すること。これができてないと、不毛な争いに巻き込まれるだけになってしまう。
AI時代に消えるのは職種ではない
この職種は安泰だ、この職種は危ない、って議論には半分しか意味がないらしいが、確かにそう思った、そもそもXの文字数制限の中での発言なら、抽象的だったり一部を全部と捉える人もいるからなおさらだと思う。どんな仕事にも、AIに置き換わりやすいタスクと、AIで価値が高まるタスクが同居してる。消えるのは職種じゃなくて、考えてるつもりで実は与えられた具体を処理してるだけの部分らしい。この本で一番怖い一文だった。
問題解決をAIが担えるようになってきたからこそ、人間の仕事の重心は問題を見つけて定義する側に移っていく。前に AI時代だからこそ基礎力が大事だと思った話 を書いたけど、基礎力が問題を「解く」力だとすると、具体と抽象は「問いを立てる」力で、両方揃ってはじめてAIに正確に委譲できるんだと思う。
目の前の要望の山を一段抽象化してみる
というわけで、まずやることは決めた。積み上がってる顧客要望のリストを一件ずつ潰す前に、一段抽象化して「結局この顧客は何を達成したいのか」を仮説として言語化してから、次の定例に持っていく。答えを聞くんじゃなくて、仮説をぶつけて、その反応から潜在的問題を探る。
言われた通りに作る力は、これからも捨てるつもりはない。それは受託の強みそのものだから。その上で、場面に応じて問題発見のOSに切り替えられるようになりたい。具体と抽象の往復を、まずは目の前の要望の山からやってみる！