システム開発と具体と抽象とは？要件定義で失敗しない思考法を解説

システム開発を外部に依頼したとき、「思っていたものと違う」「何度も修正が発生してコストが膨らんだ」という経験をした経営者や担当者は少なくありません。

その根本的な原因の多くは、発注者と開発者の間に生まれる「具体と抽象のギャップ」にあります。

細谷功氏が2026年に著した「システム開発と具体と抽象」(技術評論社)でも指摘されているように、SI業界の課題の本質は「具体と抽象を往復できないこと」にあります。

本記事では、この概念を発注者の立場から解説し、要件定義で失敗しないための実践的な思考法を紹介します。

システム開発における「具体と抽象」とは何かを理解する

システム開発の現場で「具体と抽象」という言葉が注目を集めているのは、それがプロジェクトの成否に直結する思考の構造を説明しているからです。

具体的思考と抽象的思考の違い

具体的思考とは、特定の場面・個別の事実・数値・操作手順など、目に見えて確認できる情報を扱う思考です。

一方、抽象的思考とは、複数の具体事象に共通する本質や目的、「なぜそれが必要か」という問いを扱う思考です。

たとえば「月次の売上集計レポートを経営会議で使いたい」というニーズを考えると、「経営判断を迅速にしたい」が抽象(目的)、「毎月末に各部門の売上・粗利を一覧表示するレポートを自動生成し、PDFで出力する」が具体(手段・仕様)にあたります。

この2つは別々に存在するのではなく、常に行き来しながら整合性を保つことがシステム開発の要件定義には欠かせません。

「往復」がなぜ重要なのか

抽象だけでは開発者がシステムを作れません。

逆に、具体だけを積み上げていくと、いつのまにか「なぜそれを作るのか」という目的を見失い、本来解決したかった業務課題がそのまま残ります。

IPA(独立行政法人情報処理推進機構)が継続的に実施しているソフトウェア開発実態調査でも、上流工程(要件定義)の品質がプロジェクト成否に最も大きく影響するという結果が繰り返し示されています。

具体と抽象を意識的に往復することで、発注者の本当のニーズを開発可能な仕様に落とし込む確度が上がります。

具体と抽象のギャップがシステム開発の失敗につながる仕組み

「具体と抽象」のギャップがどのように失敗を生むのか、構造を理解しておくことが重要です。

発注者と開発者の間に生まれる認識ズレ

発注者が「使いやすいシステムにしてほしい」と伝えた場合、この言葉は抽象的なままです。

「使いやすい」が何を意味するかは人によって異なります。操作手順の少なさ、画面レイアウトの直感性、処理速度のどれを指すのかが定義されていなければ、開発者は自分なりの解釈で設計を進めます。

完成品を見た発注者が「思っていたのと違う」と感じるのは、この認識ズレが積み重なった結果です。

日経クロステックが1,700件超のシステム開発プロジェクトを分析した調査によると、プロジェクト失敗の最大原因は要件定義の不備であり、スコープ定義の失敗を加えると、全失敗原因の約3分の2が要件定義関連に起因するという結果が出ています。

IT開発専門メディアの2024年調査でも、システム開発プロジェクトの失敗率は47%に達するとされており、このうちの相当割合が上流工程の課題に起因しています。

要件定義の不備がもたらすコスト増加

認識ズレが発覚するタイミングが遅いほど、修正コストは指数関数的に増加します。

ソフトウェア工学の研究者Barry Boehm氏の研究(「Software Engineering Economics」1981年)を起点に業界で広く引用される試算では、要件定義フェーズでのバグ・仕様ミスを修正するコストを1とした場合、設計フェーズでは約5倍、実装フェーズでは約10倍、テストフェーズでは約20倍、そして運用開始後には最大200倍にまで膨らむとされています。

「実装が終わってからやり直す」では済まない理由がここにあります。

業務フローの整理が不十分なまま開発に着手した案件では、テスト段階で機能の作り直しが発生し、当初予算の1.5倍以上にコストが膨張するケースも実務上少なくありません。

最初の要件定義に投資する時間と労力は、後工程のコストを大幅に削減するための先行投資です。

立場別に見る「具体と抽象」のズレが生む課題

発注者とエンジニアのどちらにも、思考が特定の方向に偏りやすい傾向があります。

その構造を理解することが、コミュニケーション改善の第一歩です。

発注担当者が陥りやすい「抽象のままで止まる」状態

経営者や業務担当者は、日常の業務課題を「売上を上げたい」「業務を効率化したい」といった抽象レベルで把握しています。

これは経営や業務の視点として自然ですが、システム開発の文脈では「何をどう作ればよいか」という具体のレベルまで噛み砕かないと、開発者に伝えることができません。

具体例として、「業務効率化のために受注管理システムを作りたい」という要望だけでは、開発者側には何も判断材料が与えられていません。

誰が・どの業務を・どのような操作で・どれくらいの頻度でシステムを使うのか、現在の業務フローのどこに課題があるのか、といった情報が揃って初めて開発の方向性が定まります。

エンジニアが陥りやすい「具体に埋もれる」状態

一方、エンジニアは技術的な実装の詳細に集中するあまり、「なぜそれを作るのか」という目的を見失いやすい傾向があります。

「〇〇テーブルのINSERT処理の仕様を確認してください」という説明は、技術担当者同士には通じますが、発注者には意味が伝わりません。

この結果として「エンジニアの言っていることがよくわからない」「何を決めればいいのかわからない」という状態が生まれ、発注者がプロジェクトに関与しにくくなります。

関与が薄れると、開発者はさらに自己判断で進めるしかなくなり、ズレが拡大するという悪循環に陥ります。

細谷功氏の「システム開発と具体と抽象」(技術評論社、2026年)では、このような立場の違いが生む認識ギャップの構造を「具体と抽象のレイヤー差」として分析しており、解決策は思考のレイヤーを意識的に合わせることだと示しています。

発注者が実践できる「具体と抽象を往復する」要件定義の進め方

発注者側で実践できる、具体と抽象を橋渡しする要件定義の手順を3つのステップで整理します。

ステップ1: 目的(抽象)と機能(具体)を切り分けて整理する

まず、「このシステムで何を実現したいか」という目的を1〜2文で言語化します。

次に、その目的を達成するために「誰が・何を・どうする」という利用シーンを具体的に書き出します。

最後に、利用シーンごとに必要な入力・出力・制約条件(処理速度、対応デバイス、ユーザー数など)を数値や条件で明示します。

たとえば、「営業担当者がスマートフォンから日報を入力し、上長が当日中に確認できるようにしたい」という目的に対して、「1日あたり最大50件の日報入力に対応」「入力から5秒以内に保存完了」「上長への通知はプッシュ通知で送る」といった具体要件に落とし込むことができます。

ステップ2: 業務フローを「誰が・何を・どうする」で可視化する

現在の業務フローを図や箇条書きで整理し、どの工程をシステム化するかを明確にします。

「今は紙で行っている」「Excelで管理しているが入力が手間」「担当者によってバラバラ」といった課題を、システムでどう解決するかを一つひとつ対応させていきます。

この作業を通じて、自分でも気づいていなかった業務の非効率や例外処理が見えてきます。それを開発者と共有することで、「実はここも対処が必要だった」という後からの仕様変更を減らせます。

たとえば受注管理をシステム化する場合、「営業が受注票を手書き → 事務が転記してExcel管理 → 月末に集計して経理へ渡す」という業務フローを書き出すと、どの工程で二重入力が発生しているか、どこでミスが起きやすいかが明確になります。

すると「営業のスマートフォン入力と事務のPCが同じデータを参照できること」「月次レポートは自動集計で出力すること」という要件が自然に導き出されます。

業務フローを起点にすることで、抽象的な「効率化したい」という要望が、具体的な機能要件に変換されるのです。

ステップ3: プロトタイプで認識ズレを早期に発見する

要件定義が完了したら、開発者に動くプロトタイプ(画面のサンプルやモックアップ)の作成を依頼し、実際の業務担当者に触らせてみることを強くお勧めします。

実際に画面を操作することで、文字上の仕様では気づけなかった使い勝手の問題や、「この項目は必要ない」「この操作が抜けている」といった認識ズレを、コストが低い段階で発見できます。

ここで重要なのは、プロトタイプへのフィードバックを「具体と抽象」の両視点で行うことです。

「使いにくい」(抽象)だけでなく「この入力項目が多すぎる」「保存ボタンを押した後の画面が分からない」(具体)まで落とし込んでフィードバックすることで、修正の方向性が明確になります。

中小企業がシステム開発で押さえておきたい思考のポイント

中小企業がシステム開発を外注する場面では、発注側の関与の質が成否を大きく左右します。

「丸投げ」を避け、目的を持って開発会社と向き合う

「あとはお任せします」というスタンスでシステム開発を進めると、要件定義の主体が開発会社に移り、発注者の本来の業務課題が反映されにくくなります。

発注者自身が「なぜそのシステムが必要か」「導入後に何が変わっていれば成功か」を明確に持ち、開発会社に問いを投げかけ続けることが重要です。

細谷功氏が「システム開発と具体と抽象」(技術評論社、2026年)で提唱する「思考のメタ化」とは、具体的な実装の話をしているときも目的(抽象)を意識し、逆に目的を語るときも実現可能な手段(具体)との整合性を確認する思考習慣のことです。

この往復を意識するだけで、プロジェクトの方向性が大きく変わります。

具体と抽象を橋渡しできる開発パートナーを選ぶ

開発会社を選ぶ際には、技術力だけでなく「発注者の目的を引き出すヒアリング力」があるかどうかを確認することが大切です。

最初のヒアリングで技術的な仕様の話ばかりをする会社よりも、「その業務でどんな課題を感じていますか」「導入後にどんな状態を目指しますか」という問いを立てられる会社のほうが、要件定義で発注者と一緒に考えてくれます。

また、開発の進め方として、小さな範囲で要件定義と試作を繰り返すアジャイル的なアプローチを採用している会社は、具体と抽象の往復が組み込まれているため、認識ズレを早期に修正しやすい傾向があります。

システム開発を依頼する前に確認すべきチェックリスト

要件定義の精度を高めるために、開発会社に相談する前に発注者側で確認しておきたいポイントをまとめます。

1. このシステムを導入する目的・解決したい業務課題を1文で説明できるか
2. 現在の業務フローを図または箇条書きで書き出せているか
3. システムを使う主な利用者(誰が・いつ・どこで)を特定できているか
4. 「あれば望ましい」機能と「なければ困る」機能を区別できているか
5. 予算・納期の制約を事前に社内で合意できているか
6. 導入後の成功基準(どうなれば良かったと判断するか)を言語化できているか

これらを事前に整理しておくことで、開発会社との最初のミーティングから具体的な議論に入れます。

逆に整理できていない項目があれば、そこが要件定義でもっとも時間をかけるべき箇所です。

このチェックリストを使って気づくことが多いのは、6番目の「成功基準の言語化」です。

「便利になればいい」「社員が使ってくれれば」という状態では、完成後に「これで良かったのか」を判断する基準がなく、追加開発の要求が際限なく生まれやすくなります。

「月次集計の作業時間を現在の8時間から1時間以下に短縮する」「受注入力ミスをゼロにする」というように、数値と状態で定義することで、開発会社も設計の優先順位が立てやすくなります。

具体的な成功基準は、プロジェクト全体の「抽象(目的)」を最も端的に表すものでもあります。

まとめ

システム開発と具体と抽象の関係を理解することは、発注者にとって「良いシステムを作ってもらうための語学力」を身につけることに近いといえます。

目的(抽象)と仕様(具体)を行き来し、「なぜ作るか」と「何を作るか」を常に対応させる意識が、要件定義の失敗を防ぐ最大の手段です。

IT開発専門メディアの2024年調査でシステム開発の失敗率が47%に達すること、また要件定義後の修正コストが運用時には最大200倍になることを踏まえれば、上流工程への投資の重要性は明らかです。

プロジェクト開始前に1〜2週間かけて要件定義を丁寧に行う手間は、後工程での手戻りやコスト増加を防ぐ確実な先行投資になります。

システム開発の依頼先をお探しの方や、要件定義をどう進めればよいか分からないという方は、Dimebizにお気軽にご相談ください。

発注者側の目的整理から、開発会社とのコミュニケーション設計まで、中小企業の実情に合わせてサポートしています。