はじめに

ソフトウェア開発のプロジェクトで、「要件定義」「基本設計」といった工程の言葉は日常的に使われます。ところが、同じ言葉を使っていてもメンバーごとに意味するものが違う、ということが頻繁に起こります。

たとえば「要件定義」を「必要な機能をリストにする工程」と考える人もいれば、「画面イメージまで固める工程」と考える人もいます。この認識のずれが、期待値の食い違い、成果物の抜け漏れ、スケジュールの遅延につながっていきます。

この記事では、開発工程の用語で認識齟齬がなぜ起きるのかを整理したうえで、現場で使える対策をまとめます。信頼できる情報源として IPA の共通フレーム2013 の考え方も参照します。

よくある認識齟齬のパターン

まず、実際に起きやすいずれを具体的に挙げます。

「要求定義」と「要件定義」の混同

この2つは名前が似ているため、最も混同されやすい組み合わせです。一般的な整理では次のように区別されます。

用語	主体	内容	表現の例
要求定義	発注者・利用者側	システムに求めることを整理する(What / Why)	「〜したい」「〜になること」
要件定義	開発者側	要求を実現するための仕様に落とし込む(What → How の入口)	「〜であるべき」「〜が必要」

要求定義はビジネス視点のニーズ、要件定義はそれを実装可能な形に整えた内容、という違いです。この切り分けが曖昧だと、利用部門と開発側が同じ言葉で違うものを指したまま議論が進みます。

「基本設計」「詳細設計」の範囲のずれ

基本設計(外部設計)と詳細設計(内部設計)も、境界が現場によってバラバラになりやすい工程です。一般的な区別は「視点」と「抽象度」の2軸で説明されます。

観点	基本設計(外部設計)	詳細設計(内部設計)
視点	ユーザーから見た振る舞い	開発者から見た内部構造
対象	画面・帳票・操作フローなど	モジュール分割・データ処理・エラー処理など
主な読み手	クライアント(合意が必要)	プログラマー

ただし現場では、内部設計と詳細設計を同じ工程として扱うところもあれば、方式設計を基本設計に含めるかどうかで解釈が分かれるところもあります。「どこまでが基本設計か」の線引きは組織ごとに異なるのが実情です。

呼称そのものの揺れ

同じ工程でも、基本設計 / 外部設計 / 概要設計、詳細設計 / 内部設計、と呼び名が複数あります。呼び名が違うだけで中身は同じこともあれば、呼び名は同じでも含む作業が違うこともあり、これが混乱を増幅させます。

なぜ認識齟齬が起きるのか

原因を3つに整理します。

1. 業界標準はあるが、名称は統一されていない

IPA が発行する共通フレーム2013 は、ソフトウェアのライフサイクル全体で「関係者が同じ言葉で話せるようにする」ことを目的としたガイドラインです。発注側と受注側で用語や作業範囲の解釈にずれが生じないよう、各工程の作業項目を標準化しています。

ここで重要なのは、共通フレームが取っている立場です。共通フレームは工程の名称そのものは規制しません。工程名は各社が長年標準化してきたもので、それを無理に統一するとかえって混乱を生むためです。代わりに、工程の構成要素である作業項目の名称を標準化する、というアプローチをとっています。

つまり、「基本設計」という名前を全社で揃えることには意味がなく、「その工程で何をやるか」を揃えることに意味がある、という考え方です。認識齟齬の根っこは、名前ではなく作業項目の解釈にあります。

2. 開発手法によって工程の捉え方が変わる

ウォーターフォールとアジャイルでは、工程の位置づけが異なります。ウォーターフォールは要求定義 → 要件定義 → 基本設計 → 詳細設計 → 実装 → テストと順に進み、各工程の成果物を固めてから次へ渡します。一方アジャイルでは工程の境界が曖昧で、作りながら要求を仕様に反映していきます。

同じプロジェクト内でウォーターフォールの感覚を持つメンバーとアジャイルの感覚を持つメンバーが混在すると、「要件定義はもう終わったはず」「いや、まだ動くものを見ながら決める段階」といったずれが生まれます。

3. 経歴・所属による前提の違い

SIer 出身者、自社開発出身者、発注側の業務担当者では、これまで見てきた工程定義が違います。多重下請け構造のように受発注が複雑な現場では、階層ごとに用語の解釈が異なり、同じ言葉でトラブルが起きやすくなります。

対策の軸:Why / What / How を「揃う抽象度」で書く

対策に入る前に、揃えるべきものを整理します。工程定義でよく語られるのは「誰が・何を・どこまで」やるかですが、これに「何のために(Why)」を加えた Why / What / How の三軸で捉えると整理しやすくなります。

ただし、この三つは書けば揃うというものではありません。書き方の抽象度がずれていると、書いてあっても認識が揃わないという問題があります。ここが対策を考えるうえで一番のポイントだと考えています。

抽象度がずれると何が起きるか

Why・What・How のそれぞれについて、抽象度が高すぎる場合と低すぎる場合の失敗があります。

Why(何のために)の抽象度

抽象度が高すぎる例:「ビジネス価値を届けるため」
- 全員が同意はするが、判断の物差しにならない。グレーな作業に出会っても答えが出ない
抽象度が低すぎる例:「画面Aのエラーメッセージ文言をクライアントと合意するため」
- その一件は判断できるが、他の判断には使えない。目的というより個別のタスクになっている
揃う抽象度の例:「ユーザーから見た振る舞いをクライアントと合意するため」
- 個別のグレーな判断(文言・操作感・エラー時の表示など)を、この目的に照らして各自が同じ結論に近づける粒度

What(何を決めるか)の抽象度

抽象度が高すぎる例:「システムの仕様を決める」
- 何をやっても該当してしまい、範囲の合意にならない
抽象度が低すぎる例:「login.html の入力欄の枠線を2pxにする」
- 個別具体すぎて、工程の定義ではなく作業指示になっている
揃う抽象度の例:「画面レイアウト、画面遷移、外部インターフェース、データ項目の論理定義を決める」
- 決めるべき対象のカテゴリが列挙されていて、抜け漏れをチェックできる粒度

How(どこまで・どうやって)の抽象度

抽象度が高すぎる例:「品質を担保する」
- 誰も反対しないが、どの状態になったら終わりなのかが分からない
抽象度が低すぎる例:「レビュー会を毎週水曜10時に開催する」
- 運用ルールであって、工程の完了条件になっていない
揃う抽象度の例:「クライアントの承認をもって完了とする。承認対象は基本設計書・画面遷移図・ER図(論理)」
- 誰が何をもって OK と判断するかが明確で、進捗の判断が揃う粒度

「揃う抽象度」の見つけ方

「揃う抽象度」というのは、次の条件を満たす粒度と言い換えられます。

具体的すぎない:定義に書かれていない状況に出会っても、その定義から自分で判断できる
抽象的すぎない:複数人が読んだときに、同じ結論に近づく
範囲が閉じている:「これは含む/これは含まない」の判断が付く

言葉を選ぶうえでの実用的な目安は、次の2つです。

そのプロジェクトの登場人物(発注側・開発側・運用側など)全員が同じ意味で読める言葉を選ぶ
工程内で発生する典型的な判断3〜5個をその定義で判断してみて、全員が同じ結論になるかを確かめる

判断が割れるなら、その定義はまだ抽象度がずれています。割れた判断が揃うレベルまで具体化するか、逆に共通する上位概念を見つけて抽象化するかで調整します。

具体例:要件定義の Why を「揃う抽象度」で書く

要件定義の目的を書いてみます。

高すぎる:「利用者の課題を解決するため」
低すぎる:「機能一覧を Excel にまとめるため」
揃う抽象度:「後のシステムテストで合否を判断できる基準を作るため」

揃う抽象度で書けていると、次のような場面で判断が揃います。

「レスポンスは速いほうがいい」という曖昧な要求が来た
- → テストで合否判定できる基準になっていないので、「何秒以内なら合格ですか」と問い返す
非機能要件を書くか迷った
- → テストで検証するなら書く、しないなら書かない、で判断できる

Why が「揃う抽象度」で書かれていれば、定義に書いていない判断も、複数人が同じ結論に近づけます。

対策

上の軸を踏まえた具体的な対策を挙げます。

対策1. プロジェクト内の共通定義を「揃う抽象度」で作る

プロジェクトの立ち上げ時に、そのプロジェクトで使う工程用語の定義を1枚にまとめます。ポイントは、Why / What / How の三つを、そのプロジェクトのメンバー構成で認識が揃う抽象度で書くことです。

## 基本設計(このプロジェクトでの定義)
- Why (目的): ユーザーから見た振る舞いをクライアントと合意する
- What (決めること): 画面レイアウト、画面遷移、外部IF、データ項目の論理定義
- How (完了条件): クライアント承認をもって完了。承認対象は基本設計書、画面遷移図、ER図(論理)
- 含めないもの: DBの物理設計(→ 詳細設計)

抽象度が合っているかを確認する簡単な方法は、次の2つです。

定義文だけを見せて、「この工程で〇〇はやりますか」という質問をメンバー数名にしてみる
答えが割れたら抽象度がずれているサインなので、揃うまで書き直す

「含めないもの」を書くと隣接工程との境界が明確になり、抽象度のずれを検出しやすくなります。

対策2. 共通フレーム2013 を「共通の物差し」として参照する

自前で工程定義をゼロから書くのが大変な場合、共通フレーム2013 の作業項目を下敷きにする方法があります。契約や見積もりの場面では、「共通フレーム2013 のソフトウェア詳細設計の範囲」といった形で作業範囲を示すと、発注側・受注側の双方が同じ基準で範囲を確認できます。

共通フレームの作業項目は、業界の平均的な現場で「揃う抽象度」になるよう調整されているため、プロジェクト定義の下敷きとして使いやすい素材です。

共通フレーム2013 は 2013年の策定以降、ベースの国際規格(ISO/IEC 12207)や JIS X 0160 が改訂されても、IPA は共通フレーム2013 の改訂は行わない方針を示しています。2026年現在も国内のシステム開発における参照先としては共通フレーム2013 が主流です。ウォーターフォール型に重点を置いているため、アジャイル前提のプロジェクトではそのまま使いにくい面もあります。

対策3. V字モデルで工程とテストの対応を可視化する

工程の位置づけを共有する道具として、V字モデルが有効です。各設計工程が、どのテスト工程で検証されるのかが対応関係で示されるため、「この工程で決めたことは、後でどこで確認されるのか」がチーム全員で見えるようになります。

V字モデルは、各工程の Why を「対応するテスト工程で検証できる状態にすること」という抽象度で束ねてくれます。要件定義の内容がシステムテストの合否基準になる、という対応が見えると、要件定義を曖昧にするリスクが実感しやすくなります。

対策4. 「同じ抽象度で話せているか」を疑う習慣を持つ

打ち合わせで工程名が出たとき、次の順で確認するとずれを早期に発見できます。

「その工程は何のためにやる想定ですか」(Why の抽象度チェック)
「そこでは何を決めますか」(What の抽象度チェック)
「どこまでできたら完了と判断しますか」(How の抽象度チェック)

回答が抽象的すぎたり具体的すぎたりしたら、そこにずれの芽があります。認識が揃っている前提で進めるのではなく、揃っていないかもしれないという前提で確認する姿勢が、手戻りを減らします。

AI駆動開発での認識齟齬

ここまでは人間どうしの認識齟齬の話でしたが、Claude Code や Cursor などの AI エージェントを開発に組み込むと、この問題は新しい形で現れます。

AI は「揃う抽象度」を自分では調整できない

「基本設計をして」とだけ指示すると、AI は自身が学習した一般的な「基本設計」の解釈で作業を進めます。人間なら「うちの現場だと基本設計はここまでだよね」と暗黙の前提で補正できますが、AI はプロジェクト固有の抽象度を持っていないので、指示の言葉どおりに動きます。

ここでも問題は抽象度です。

AI への指示が抽象的すぎる(「基本設計をして」)と、AI は自分の学習内容から適当な粒度を選ぶ
AI への指示が具体的すぎる(「login.html のボタンを青にして」)と、その1タスクは正確に終わるが、工程としての抜け漏れは AI 側で気付けない

AI に対しても、人間どうしと同じ「揃う抽象度」で工程定義を渡す必要があります。

工程定義を AI に渡すコンテキストにする

対策1で作った定義は、そのまま AI エージェントのコンテキストとして使えます。CLAUDE.md やルールファイルに書いておくと、AI が「このプロジェクトの基本設計」の粒度で作業しやすくなります。

# 工程定義(このリポジトリでの共通ルール)

## 詳細設計
- Why (目的): プログラマーが実装できる粒度まで内部構造を固める
- What (決めること): クラス構成、DBの物理設計、エラー処理方針
- How (完了条件): 詳細設計書・シーケンス図・テーブル定義がレビュー通過している
- 含めないもの: 画面レイアウトの変更(→ 基本設計に戻す)

Why を書いておく効果は人間の場合と同じで、定義に書かれていないグレーな判断に AI が出会ったときの手がかりになります。Why が抽象的すぎると AI は自由に解釈しますし、具体的すぎると想定外のケースを飛ばします。人間で「揃う抽象度」に調整した定義は、AI との協働でも同じように効きます。

曖昧な用語ほど「揃う抽象度」で明示する

「要件定義」「基本設計」のように解釈の幅が大きい用語ほど、AI へ渡す前に定義を明示しておく価値があると思います。プロジェクトの共通定義を整備することは、人間どうしの齟齬対策であると同時に、AI に正確な抽象度の文脈を渡すための準備にもなります。

まとめ

開発工程の用語で認識齟齬が起きるのは、業界に工程名称の統一基準がなく、開発手法や経歴によって前提が異なるためです。対策の軸は、名前を揃えることではなく、各工程の Why / What / How を「メンバー全員の認識が揃う抽象度」で書くことにあります。抽象度が高すぎれば判断の物差しにならず、低すぎれば個別作業になって工程定義として機能しません。

プロジェクト単位で工程の共通定義(Why / What / How)を、揃う抽象度で作る
抽象度が合っているかは、メンバーに質問して答えが揃うかで確認する
共通フレーム2013 を作業範囲の物差しとして参照する
V字モデルで工程とテストの対応を可視化する
打ち合わせで Why / What / How の抽象度を都度確認する習慣を持つ
工程定義を AI エージェントに渡すコンテキストとしても使う

同じ言葉で違うものを指していないか、そしてその定義が判断を揃えられる抽象度になっているか、というところから始めると、期待値のずれやスケジュール遅延を減らしていけると思います。

参考