見出し画像

システム開発と「具体と抽象」〜問題発見と問題解決を往復する「思考のメタ化」を身につける〜

「言われたことの実行は得意だが、能動的な提案は不得意」。SI業界でよく言われるこの課題に、心当たりがある人は多いはずです。指示された仕様通りに動くものは作れる。でも、そもそも何を作るべきかを問われると、途端に手が止まる。

自分もその1人でした。細谷功さんの『システム開発と「具体と抽象」〜問題発見と問題解決を往復する「思考のメタ化」を身につける〜』は、この課題を「具体と抽象」という1本の軸で解き明かしてくれる本でした。

この本を手に取った理由

以前、同じ細谷功さんの『「具体⇄抽象」トレーニング 思考力が飛躍的にアップする29問』を読んでいました。具体と抽象を往復する練習問題を通じて、思考の型そのものを鍛える本です。

そのベースを持っていたこともあり、SI業界というより具体的な現場にこの軸を当てはめて書かれた今回の本は、出版前から気になっていました。

もう1つ、「言われたものを作る」から「何を作るかを提案する」側へ進みたい、という気持ちがずっとありました。ただ、その転換へ何が必要なのかを、うまく言語化できないままでした。

同じ時期に読んでいた別の本『システム思考の世界へ』の影響もあります。この本は、思考のシステム、自己認識、フィードバックループ、パターン思考といった構成で、思考そのものを扱う抽象度の高い本でした。読みながら「テニスの本を読んでもテニスができるようにはならない、実際にやる必要がある」という一節が残り、抽象的な思考力もまた、練習して身につける実践なのだと感じていました。そんなタイミングで本書に出会い、SI業界という具体的な現場に「具体と抽象」という軸を当てはめて考え直してみたくなりました。

どんな本か

一言で言うと、SI業界が抱える「提案型人材の不足」という課題を、「具体と抽象」というフレームワークで構造的に解き明かす本です。

本の構成は、次の流れで進みます。

  • SI業界が抱える課題

  • 具体と抽象の基本

  • SIプロジェクトへの応用

  • SIプロジェクトの落とし穴

  • 組織の成長

第2章では具体と抽象の基本的な考え方をIT分野に当てはめ、「手段と目的」という別の軸への応用にまで話が広がります。第5章では個人のスキルの話から一段引き上げ、組織自体が成長する過程にも「具体と抽象」の軸が効いてくることが語られます。おわりには、AIが代替していくのは「SIの具体」であり、抽象化を突き詰めた先にあるのはSI自身のメタ化だという話でしめくくられます。

冒頭に置かれた「魚」か「釣り方」かという問いが象徴的でした。魚(成果物)を渡すだけの仕事と、釣り方(考え方)を伝える仕事は、似ているようでまったく違います。この本は終始、後者の視点に立って書かれています。

第4章「SIプロジェクトにおける落とし穴」の見出しの付け方も印象的でした。

  • 「投資対効果」の罠

  • 「事例調査」の罠

  • 「2つのピザ」の話

  • PoC(概念実証)疲れの正体

  • コストセンター型PoCのジレンマ

抽象的な理屈で終わらせず、現場で誰もが一度はぶつかる具体的な場面に、あえて名前を付けて並べています。理論の本というより、現場のよくある場面を構造化した本、という読み味に近い章でした。

刺さったポイント

川上と川下は、そのまま抽象と具体に置き換えられる

SIプロジェクトの上流と下流は、これまで「要件定義と実装の違い」という工程の区分として捉えていました。上流であるほど抽象、下流であるほど具体。この本を読んで、そう軸を置き換えられることに気づかされました。

問題発見(何が課題なのかを見つける、抽象度の高い仕事)と問題解決(見つけた課題を実装に落とす、具体度の高い仕事)を往復する力。これこそが「言われたものを作る」から「提案する」への転換に要るものなのだと理解できました。工程の呼び方を変えただけのようで、実際には見える景色がまったく変わる置き換えでした。

これまでの自分は、要件定義という工程さえ丁寧にこなせば、上流の仕事は果たせていると思い込んでいました。ただ実際には、要件定義も「与えられた前提の中で具体化する」作業になっていれば、それは川下の仕事のままです。本当の川上の仕事は、その前提自体を疑い、そもそも何が課題なのかを抽象度の高いところから問い直すことにあるのだと、この本を読んで区別できるようになりました。

FDEとの違いは「抽象化レイヤー」の有無

コラムで紹介されていた「FDEは『顧客駐在型』とどう違うのか」という視点も印象的でした。現場に入り込んで働くという意味では、FDE(Forward Deployed Engineer)も従来の顧客駐在型のSEも似て見えます。

違いは抽象化レイヤーの有無にあります。現場の個別事情にただ合わせるだけでなく、個別の事象から再利用可能な抽象構造を取り出せるかどうか。具体に沈み込むだけでなく、そこから抽象へ引き上げる往復運動ができるかどうかが分かれ目になるのだと理解しました。

これは、自分が現場で個別対応を重ねているときに一番陥りやすい罠でもあります。目の前の顧客から求められることに応え続けているうちに、いつの間にか「その現場でしか通用しない特注品」を量産する係になってしまう。抽象化レイヤーを意識的に挟むかどうかが、その特注品を「他でも使える資産」に変えられるかどうかの分かれ目になるのだと、あらためて気づかされました。

抽象的な思考力は、読むだけでは身につかない

『システム思考の世界へ』を読んでいたときに引っかかった「テニスの本を読んでもテニスができるようにはならない」という感覚は、この本を読んでさらに輪郭がはっきりしました。

具体と抽象を往復する力も、知識として理解するだけでは使えるようになりません。目の前の課題を、あえて一段抽象化して眺め直す。抽象化した見立てを、また別の具体的な現場に当てはめてみる。この往復を実際の仕事の中で繰り返すことでしか、思考のOSはメタ化されていかないのだと感じています。

以前読んだ『「具体⇄抽象」トレーニング』が29問の練習問題という形式だったのも、今になって腑に落ちます。読んで理解する本ではなく、手を動かして鍛える本として作られていたのでしょう。今回の本はSI業界という具体的な現場に軸足を置いていますが、根底にある「読むだけでは身につかない」という前提は同じでした。

読んだあとにやってみたいこと

  • 目の前のタスクへ着手する前に、「これは川上(抽象・問題発見)の仕事か、川下(具体・問題解決)の仕事か」を一度自問する。工程表上の呼び名ではなく、実質どちらの仕事をしているかで判断する

  • 現場対応した個別の事象を、そのまま終わらせず「他の現場にも使える形」に抽象化できないかを考える一手間を入れる。特注品を作って終わりにせず、資産として残せる形を意識する

  • 第4章の「落とし穴」リストを、自分のプロジェクトの現状と1つずつ照らし合わせてみる。当てはまるものがあれば、それは個人の失敗ではなく構造的に起きやすいパターンだと捉え直す

  • コラムで紹介されていた参考図書を含め、具体と抽象を扱う他の本にも手を広げてみる

この本を誰に勧めたいか

  • 「言われたものを作る」から「何を作るかを提案する」側へ進みたいエンジニア、PM、テックリード。川上の仕事の中身を具体的に知る手がかりになる

  • 顧客への提案力・構想力を高めたいITコンサルタント、プリセールス。「投資対効果」の罠のような、提案の場面で実際に起きる落とし穴を先取りできる

  • DX・AI活用を掲げながらPoC止まりに悩んでいる情報システム部門、経営企画。PoC疲れの正体が構造的に説明されている

  • 組織の「思考のOS」を変えたいと考えているIT企業の経営者、マネジメント層。個人のスキルの話に閉じず、組織の成長という章立てで語られている

SI業界を主な題材にしていますが、上流・下流を持つプロジェクトに関わる人であれば、業界を問わず当てはめて読める内容です。

読み終えて残ったのは、「提案型人材になる」という目標そのものより、その手前にある「川上と川下を意識的に往復する」という具体的な動作でした。抽象的な心構えとして終わらせず、日々のタスクの中で実際に往復してみることでしか、この本で言う「思考のメタ化」には近づけないはずです。まずは自分の持ち場から、その往復を意識するところから始めていきます。

いいなと思ったら応援しよう!