要求を言語化し、仕様化する技術を学んだ話

2024年8月20日 22:47

はじめに

こんにちは。
最近は PO として要求を理解して仕様を適切な日本語で言語化したいと思い、「［入門＋実践］要求を仕様化する技術・表現する技術」という本を読んでいます。
今回は、この本で学んだことをアウトプットとして記事に起こしたいと思います。

要求を書く際に最も重要な発見は、適切に表現された要求には「範囲」があるということでした。この「範囲」の概念は、以下の点で非常に重要です：

要求の表現方法によって、その後の仕様化のプロセスが大きく変わることを学びました。以下は本書でも紹介されていた例です。

Before：「1 週間の天気予報を表示する」

After：「天気予報をネットから入手して、最初の 2 日分は時間単位で表示し、その後の 5 日分はそれぞれ1日単位で予報を表示する」

この例から分かるように、適切に表現された要求は：

要求の範囲が示され、その範囲の中の動きが動詞の形で表現されることで、その要求を満たすべき「仕様」が抽出されやすくなります。上記の例では：

といった動詞が使われています。
仕様とは、そこにある「動き」= 動詞に対して、具体的な制約や処理内容や選択肢などを記述したものなので、要求という振る舞いの中に含まれている「動き」をすべて表現してしまえば、必要な仕様をモレなく記述することができます。

要求には必ず理由があります。この理由を理解し、要求と組み合わせることで、

例えば、「天気予報を表示する」という要求の理由が「外出の計画を立てやすくするため」だとすれば、単に予報を表示するだけでなく、外出に適した時間帯をハイライトするなどの機能を追加することで、より適切な要求表現に修正できるかもしれません。

要求と理由がフィットしない場合、以下のような問題が潜んでいる可能性が高いことを学びました。

この定義から、仕様は単なる技術的な記述ではなく、関係者間のコミュニケーションツールとしても機能することがわかりました。

仕様をいつ書くべきかについて、重要な洞察を得ました。

早期に仕様化することで、以下のようなメリットがあることを学びました。

これらのメリットにより、早期仕様化に使った工数は、後の工程で十分に回収できることがわかりました。

仕様を書く際の重要なポイントとして、以下を学びました。

例えば、以下のような仕様があったとします（本書で紹介されていた例です）。

不適切な例：
「データを処理しきれないときは、それ以上データを受信しない」

この仕様は曖昧で、具体的な動作が不明確です。これを以下のように改善できます。

改善例：
「データを処理しきれないときは、それ以上データの送信を一時中断するように要請する」

この改善により

この記事が気に入ったらサポートをしてみませんか？