Universal Specification Describing Manner（要求仕様の記述方法、略称：USDM）は、ソフトウェアおよびシステム開発における要求仕様の記述手法である。清水吉男によって考案・提唱された。

概要

USDMは、ソフトウェアおよびシステム開発における要求仕様記述手法であり、曖昧なステークホルダーの要求を、検証可能で正確な仕様へと体系的に変換するための規律ある方法論として定義される。その中核は「要求」「理由」「説明」「仕様」という4つの要素から成る構造にあり、この構造が曖昧さを体系的に排除し、開発後期における高コストな手戻りを防止することを目的とする。USDMは単なる文書テンプレートではなく、複雑なシステム開発における知識管理、品質保証、リスク管理のためのツールとして位置づけられる。

USDMの概念

USDMは、故・清水吉男によって考案・提唱された。彼は、システムの要求と仕様を効果的に定義・管理することに苦慮していた開発現場のための実践的なソリューションとして、この技法を開発した。USDMは、産業界で広く受け入れられ、現在ではSQuBOK（ソフトウェア品質知識体系ガイド）のような知識体系ガイドにも取り上げられるなど、複数の業界団体によって標準または推奨手法として採用されており、その信頼性と実績が証明されている。

USDMは、ソフトウェア開発プロジェクト失敗の主要因の一つである、要求定義フェーズに内在するコミュニケーション不足と曖昧さに直接対処する。多くのプロジェクトでは、顧客の真の意図が不完全にしか伝えられないために、完成した製品が期待と異なり、高コストな手戻りやスケジュールの遅延が発生する。

表現力豊かである一方で、自然言語は本質的に曖昧である。一つの文章が、顧客、開発者、テスターといった異なるステークホルダーによって複数の意味に解釈される可能性があり、期待と実装の間にギャップを生じさせる。これは特に、暗黙の知識や前提が重大な仕様漏れにつながりかねない複雑なシステムにおいて、深刻な問題となる。

この課題に対し、USDMは自然言語を置き換えるのではなく、厳格な構造の中に制約することで曖昧さを排除するアプローチをとる。これは一種の「制約された自然言語」フレームワークと見なすことができる。「目的語＋動詞」という文法を課し、階層構造や要求と理由の論理的結合といったフレームワークを適用することで、曖昧な散文を、正確で機械的に検証可能な仕様へと変換する。

例えば、「警官は銃で暴徒を撃った」という単純な文章でさえ、銃を持っているのが警官なのか暴徒なのかという解釈の揺れを生む。USDMの「目的語＋動詞で要求を記述する」という中核ルールは、記述者に対し、何が（目的語）何をされるのか（動詞）を明確にすることを強制し、このような解釈の曖昧さを即座に低減させる。

USDM文書の構造

USDM文書は、基本的に4つの主要な要素で構成され、通常は表やスプレッドシートで整理される。

構成要素 要求：システムが何をすべきか、達成すべきゴールを記述する。ステークホルダーが望む成果物を表現する。 理由：その要求がなぜ必要なのかを説明する。背景、動機、あるいはビジネス上の文脈を提供する。 説明：要求や理由の理解を助けるために、補足情報を提供したり、専門用語を明確にしたり、具体例を挙げたりする。 仕様：要求をどのように実現するかを詳述する。開発者が実装すべき具体的な振る舞い、制約、ロジックを記述する。

階層化の原則

USDMは、複雑な要求を管理可能な単位に分解するために階層構造を用いる。広範で高レベルな要求は、 上位要求と呼ばれる。これは機能の大きな範囲を定義する。次に、この上位要求は、より焦点の絞られた下位要求の集合に分解される。各下位要求は、上位要求の振る舞いの特定の部分を詳述する。そして最後に、各下位要求に対して仕様が定義され、実装の詳細の最終層が提供される。これにより、高レベルの目標からその実装に関する特定のルールまで、明確で追跡可能な経路が構築される。

「要求」と「仕様」の境界

USDMは、「要求」と「仕様」の間に厳格な概念上の分離を強制する。

「要求」は抽象的であり、ゴールや振る舞い（「何を達成するか」）を記述する。これは出発点であり、しばしば明確化が必要なある程度の曖昧さを含んでいる。その主な役割は、スコープを定義し、仕様を導出するためのプロンプトとして機能することである。 （例）：計測データを受信し、１０件ごとに平均値を計算して、画面に表示する。 （例）：天気予報をネットから入手して、最初の２日分は時間単位で表示し、その後の５日分はそれぞれ１日単位で予報を表示する。 「仕様」は具体的であり、実装（「どのように作るか」）を記述する。これは明確化プロセスの終着点であり、開発者が実装し、テスターが検証するのに十分なほど詳細化されている。最終的にソースコードに変換されるのはこの仕様である。 （例）：画面の氏名の横に、性別のラジオボタンを設ける。 （例）：性別が選択されたら、次にように性別コードを決める。

この「要求」と「仕様」を分離することで、分析者に対して「どのように」作るかを考える前に、まず「何を」「なぜ」作るのかを熟考することを強制するのが特徴である。要求の役割は仕様を「引き出す」ことにあり、「仕様」が決定されるまで設計を開始すべきではないという考えが根底にある。この考えにより、問題が完全に理解される前に解決策を設計してしまうという、工学における一般的なアンチパターン「ソリューショニアリング」を防ぐ。

記述のルール

目的語＋動詞

機能要求を明確な「目的語＋動詞」（「〇〇を△△する」）の形式で記述する。これは、仕様が要求の中の動詞と目的語に内在するという原則に基づいている。動詞はシステムの行動や振る舞いを記述し、その詳細は仕様セクションで明確化されなければならない。

また、この「計算する」「表示する」といった「動詞」が、計算アルゴリズム、グラフの種類、データ範囲、エラーハンドリングなどを詳述する仕様へとつながっていく。

例えば、「商品管理機能」のような要求では不完全であり、「商品情報を登録する」「商品情報を更新する」「商品情報を削除する」といった、実行可能なステートメントに分解されなければならない。

理由欄の記述

USDMでは、すべての要求に「理由」を付記する。また、「理由」には、新たな要求や曖昧さを含めてはならない。これにより、文脈と正当性が提供され、文書を読む誰もが要求の背後にある 意図を理解できるようになる。これは、たとえ要求の表現がわずかに不完全であっても、誤解釈を防ぐ効果がある。

「理由」は、長期的な保守と進化の観点から、USDM文書の中で最も戦略的に重要な部分である。それは、設計の根拠を保存するためのメカニズムとして機能する。例えば、開発担当者個人の「暗黙知」は、その開発者が組織を去ると知識が失われるという問題がある。「理由」欄は、まさにこの「なぜ」という背景を記録することで、この「暗黙知」問題に対する直接的な解決策となる。

階層と粒度

要求が過度に大きく扱いにくくなるのを防ぎ、明確さを維持するために、USDMは特定の制約を提案している。

一つの要求に含まれる明確な動詞の数は、理想的には5〜7個以内とすべきである。これを超える場合、その要求は複数の下位要求に分解する候補となる。 階層は浅く保つべきであり、推奨は最大2階層、厳格な上限は3階層とされる。これより深いネスト構造は、上位要求が広範すぎることを示唆しており、再検討が必要である。

一つの要求が大きすぎる場合（例えば、動詞が8個以上含まれる場合）、それを分割する必要がある。これらには、時系列分割（プロセスを時間的なステップで分割）、構成分割（機能的なコンポーネントで分割）、状態分割（システムの異なる状態ごとの振る舞いを定義）、共通分割（共有される機能を抽出）などが含まれる。

利点

最大の便益は、誤解や仕様の誤りに起因する手戻りの大幅な削減である。USDMは初期段階での明確化を強制することで、プロジェクトを脱線させるコミュニケーションの齟齬を防ぐ。また、すべてのステークホルダー（顧客、アナリスト、開発者、テスター）に対して、単一で曖昧さのない真実の源を提供することにより、明確で効率的なコミュニケーションを促進する。その構造化されたフォーマットは、仕様の漏れ、矛盾、重複を容易に発見させる。

明確に定義された仕様は、直接テストケースに変換可能である。「目的語＋動詞」の構造は期待される結果の定義を容易にし、テストカバレッジを向上させ、テストの曖昧さを減少させる。また、要求、理由、仕様の間の明確な連携は、変更時の影響分析を大幅に容易にする。要求が変更された場合、影響を受ける仕様は即座に特定可能である。派生開発をするためのXDDP（eXtreme Derivative Development Process）とも相性が良い。USDMは、SysML（Systems Modeling Language）を用いて、視覚的にモデリングできるのも利点である。

脚注

関連項目

要求仕様 システム開発