『システム開発と「具体と抽象」』を読んだ#

問題解決と問題発見を考える

PHASE 1 / 問題意識#

なぜこの本を読もうと思ったのか#

問題解決はイメージできても、解くべき問題を定義することができていないと感じていた

  • AIによる開発の割合が増えるなか、エンジニアとしての価値の出し方を変えられているか
  • 相談を受けると、すぐ解決策を考えてしまう
  • チームの目標設定では、納期、品質、粗利で測りやすい仕事を優先しがちになる

そんな自分にとって、『システム開発と「具体と抽象」』はまさに読みたいタイトルだった。 個人的に実践したい項目をピックアップしていく

PHASE 2 / 具体と抽象とは#

1. 具体と抽象とは#

具体は目の前の事象を扱い、抽象は複数の事象に共通する目的や構造を捉える。

具体抽象
個別の事象、機能、手順目的、関係、構造
どう作るかなぜ作るか、何を作るか
狭く深い浅く広い
レーザーポインタ懐中電灯

具体が悪・抽象が善ではない。ただの区別 本書では、時と場合によってこの思考を使い分けるようにするのが良いとのこと。

PHASE 2 / 具体と抽象とは#

2. 2種類のwhy#

Whyには原因と目的の2種類がある

原因のwhy目的のwhy
過去に向かっている未来に向かっている
なぜなぜ分析なぜやるのか
川下では重要川上で重要

視野の広さはWhyが見えているかで変わる

PHASE 2 / 具体と抽象とは#

3. 個人: 反応する人と思考する人の違い#

反応する人は、言われた通りにしかつくることができない

反応する人思考する人
表面事象から直接解決策を考える表面事象から本質的な課題(why)を整理し、その課題に対して解決策を考える
仮説を更新する品質と再現性を高める

抽象のWhyフィルターを通すことで、依頼に縛られない「能動的な提案」が可能になる

PHASE 2 / 具体と抽象とは#

3. 組織: システム開発における川上・川下の違い#

川上では問題を発見し、川下では定義された問題を正確に解く。

川上：問題発見川下：問題解決
曖昧な状況から問題を見つける定義された問題を解く
Whyから前提を見直すHowを磨く
仮説を更新する品質と再現性を高める

川上と川下では、求められる思考も仕事の進め方も異なる。

PHASE 3 / どうすべきか#

1. 個人の具体と抽象#

思考する人は、目の前の事象から一度抽象へ上がり、具体的な打ち手へ戻る。

  1. 起きている事象を観察する
  2. 背後にある目的、関係、構造を考える
  3. 仮説を具体的な打ち手へ落とす

具体から具体へ直行すると、与えられた問題の外にある選択肢を見落としやすい。

PHASE 3 / どうすべきか#

2. 組織の具体と抽象#

組織には、具体を磨く力と、抽象から方向を決める力の両方が必要になる。

具体を磨く組織抽象から考える組織
品質、安定性、再現性を高める目的、方針、選択肢を考える
失敗を減らす小さく試して学ぶ
限りなく10割を目指す3割から前へ進める

同じ評価軸で測ると、探索する仕事だけが不利になる。

PHASE 3 / どうすべきか#

3. プロジェクトの具体と抽象#

プロジェクトは、曖昧な期待を、目的を失わず実装可能な形へ変える仕事である。

  • 抽象だけでは作れない
  • 具体だけでは、何のために作るのかを見失う
  • 具体を見せて反応を得たら、目的と問題設定へ戻る
  • 新規案件に投資対効果を求めるのは構造的に無理がある
    • 新規は前例がないので、既存の事例はあてにならないため
    • 「成功事例をみせろ」は前例踏襲型思考である

また、プロジェクトは一人で大枠を考え、全体像や方向性を明確にした上で各専門領域は移譲する

PHASE 4 / 自分の経験と照らし合わせる#

1. 個人の具体と抽象#

相談を受けた瞬間に解決策を返すことを、無意識で行っていた

  • 「検索が遅い」と聞けば、すぐ技術的な改善策を考える
  • 「なぜ起きたか」は聞いても、「なぜ取り組むか」まで聞けていない
  • 完成度を上げてから見せようとして、学習の機会を遅らせる

まずは解決策を話す前に、目的を一つ聞くところから具体と抽象の意識をつける 曖昧な場合は、まずは素早くモックを出し、「これじゃない」を出し目的に合わせていく

PHASE 4 / 自分の経験と照らし合わせる#

2. 組織の具体と抽象#

粗利、品質、納期だけで測ると、新しい価値を探す仕事を始めにくくなる。

  • 粗利を伸ばすチームには、仮説を早く試す余白が必要
  • 基盤や運用保守を担うチームには、高い品質が必要
  • 守る仕事と探る仕事では、評価すべき視点が異なる

目標設定の際には、どちらを軸にしているのかをすり合わせする必要がある

PHASE 4 / 自分の経験と照らし合わせる#

3. プロジェクトの具体と抽象#

川下で信頼を生んだ習慣を、そのまま川上へ持ち込むと探索が止まる。

  • 問題を正確に解く力 → 与えられた問題を疑わなくなる
  • 完璧に仕上げる姿勢 → 仮説を見せるまでが遅くなる
  • 顧客との信頼 → 顧客が示した課題を正しい前提として扱う

強みを捨てるのではなく、プロジェクトの局面に応じて使い分けたい。 PoCを作る際は完成させるのではなく課題抽出。改善を前提に進める

PHASE 5 / 最後に#

具体と抽象を、意識して往復する#

メインは目的・原因のWhyを検討してからHowを考えること

  • 案件設定の際は、問題解決の前に、何を解くべきかを考える
  • 粗い具体を早く見せ、目的と問題設定へ戻る
  • 事業貢献の定義を整理し、守る仕事と探る仕事を、同じ物差しで測らない

PHASE 5 / 最後に#

個人的に残しておきたいメモ#

単位メモ
個人完璧主義と顧客からの信頼がこそが川上への最大の負債になりうる
個人仕事とは抽象から具体への変換作業である
Project新規案件に投資対効果を求めるのは構造的に無理がある。新規は前例がないので、既存の事例はあてにならないため
Project「成功事例をみせろ」は前例踏襲型思考である
組織川上OSと川下OSを同じ評価体型の中で混ぜているのは危険。短期的な結果が明白な川下は直接的な数字に繋がりやすく、長期的な戦略は直接の成果が出にくい川上。川上をやるとなりながら、評価は粗利だけで行う。「挑戦しろ」となりながら、失敗は原点評価になる。ということがありうる

広告/PR#

システム開発と「具体と抽象」とても面白かったので、興味ある方はぜひ読んでみてください https://link.amazon/B03dBoZcS

← 『システム開発と「具体と抽象」』を読んだ 00:00 1 / 1