この記事を書いた人
製造業系のソフトウェア開発企業で、7年くらいQA部門であれこれを経験
その後、いろんな製造業の品質保証部門であれこれを経験
数年前、ソフトウェア業界にQAとして舞い戻りアジャイル開発などあれこれを経験

この記事は一体何か？

USDMという考え方・方法をご存知でしょうか？？
「要求を仕様化する技術・表現する技術」(清水吉男,2010)という本にまとめられているのですが、
この本、実はウォーターフォール派生開発の要件開発〜仕様化の方法として書かれているんです。
しかも2010年に出版されたものとあってアジャイル界隈では全くといっていいほど注目されていません。
製造業系で派生開発中心のQAに育てられた者として、この方法論が
アジャイルの現場でも役に立つかもしれないと思い、簡単にご紹介できればと思います。
USDMに注目すべき理由を述べた後に、USDMについて簡単に説明しています。

USDMってどういうものか？？が知りたい方は、記事の真ん中以降、USDMの紹介をご覧ください

派生開発とアジャイル開発

そもそも派生開発って何？という方も多いかと思いますので、サクッと。

派生開発

基本的にウォーターフォールで、仕様は文書化され、決して伝言ゲームになりません
既にリリースされている特定の製品の後継版を作る
- 例えば、スマートフォン。私はXPERIA5ⅱ を使っていますが、これは派生開発で作られたものです。既に市場投入済みXPERIAをベースに変更を加えたものになります
  - ゲーミングスマホにしたい（リフレッシュレートの変更 / 放熱性能の変更...etc,）
  - SONYのデジタル一眼レフα1と同じカメラ性能を持たせたい（シャッターは物理ボタンのみ / ISOやシャッター速度をカスタマイズして撮影できる / ポートレートは瞳をフォーカス...etc,）
  - 前任機種からその他諸々が、とんでもなく凄く変更されていそう

アジャイル開発

各イベントで話し合いによるステークホルダ間での合意がなされるため、人により理解が異なるリスクがある（伝言ゲームになるリスク）
短期間にデプロイを繰り返し、デプロイ毎にユーザーストーリーに沿って機能を変更していく
- ユーザーストーリー自体の変更も辞さない
- （ここではデプロイ＝市場投入と捉えてください）

つまり、少なくとも以下の点では同じであると言えそうです

要件(ユーザーストーリー)と、機能の結びつきを重視する
｢仕様は変更される｣ことを前提としている

すべての機能はストーリー実現のためにある

すべての機能はストーリーに紐づいている はずです
ストーリーとは、V字モデルでいうところの要件に該当しそうです。
だとすれば、機能（UI）単位でテストケースを作ってたら ¹ 変更が大変になるの当たり前ですよね？
そもそもの要件としてのストーリー自体がカンタンに変わってしまうのですから。。。
アジャイルとはいえ、V字マインドからの脱却は難しく、どうしても小さいV字をクルクル回しているような状況が多いのでは？と思います。
とすると、短期間に以下の手戻りを何度もやり直すことになります。
（めっちゃ大変ですね！！）
- バグが発見されると修正のための戻りが大きくなります（時間・工数とも）。場合によっては要求事項まで戻ります。これは短いイテレーションにおいて致命的です。

それでも、仕様が原因のバグって多いですよね。特に要件の再確認まで戻るようなバグが多い。
- バグだけでなく、プロジェクトとして要件定義で既にコケている場合が多い ²
- ITプロジェクト実態調査 2018を見ると、以下の問題が大きいようです
  - 満足度：要件定義が不十分だった
  - コスト：追加の開発作業が発生した
  - スケジュール：要件定義が長引いた
    …ということらしいです。
    - ならもういっそのことストーリーに紐づいたテストを作れば良いですね！！
    - テストをパスするように開発できれば、ストーリーを達成できるという事です
    - 「こらもう、人力TDDやで！！」

前置きが長くなりました……
つまり、要求を丁寧に仕様化する方法があれば良さそうです。
……ようやく、要求を仕様化するためのUSDMをご紹介します。

USDMの紹介

要求とそれを実現するために必要な機能を記載します。
- 「入力→処理→出力」の振る舞いは動詞で表現できます。
  - 例）「共有プリンタの管理者が、迅速に対応しやすくするために、印刷前に用紙やトナーの不足を検知したら管理者や担当者に通知を送信する」
    - 直接記載されている動詞：検知する。送信する。
    - ＜ポイント＞読み取るべき動詞：管理担当者のアドレスを読み出す。
    - それぞれの動詞に対してどうすれば実現できるのかを考えます（仕様化）
      
      ＜ポイント＞仕様の範囲：印刷ジョブを受け付けてから印刷開始までに用紙とトナー不足を検知する
      
      残量ステータスの入手方法
      
      用紙やトナー不足の判断基準
      
      メッセージの構成
      
      送信先の場所（ユーザー情報/ユーザーIDなど）
      
      送信対象者の入力（担当者は週ごとに手動で変更される）
      
      通知方法（プッシュ通知/メール送信）

＜ポイント＞ 要求のwhoとWhatを「上位要求→下位要求→仕様」へと階層的に具体化していきます
＜ポイント＞ 要求に合わせて、その要求が必要な理由を記載します（why）

先ほど共有プリンタを例に記載したような方法では、ダラダラと長くなって分かりにくい場合もあるかと思います。

以下のような方法で仕様を階層化する

「時系列分割」「構成分割」「状態分割」「共通分割」の４つの分割基準
（例としてメールソフトで考えてみます）

時系列分割：要求内の動詞（動詞で表せるもの）を時系列に並べる

 1. メールボックスからひとつ選択できる
 2. 受信時間の新しい順に表示できる
 3. 表示されたメールを押下すると、本文を表示できる

構成分割：機能の構成で分ける

 1.検索ができる
    - 差出人で検索したい
         - メールアドレスで検索できる
         - 表示名で検索できる
    - タイトルのみを検索できる（本文を含まない）
         - 文字列の含む/含まないを選択できる
    - 期間を指定して検索できる
         - 未来の日付は選択できない
         - 日付は「To＝端末の時刻設定日」「From＝端末の時刻設定日－1日」とする
  2.ツールバーで表示方法を変更したい
    - 「重要なメール」のみを表示できる
    - 各メールの本文の先頭30文字のみを表示できる

状態分割：状態遷移をイメージする

     - 画面表示中のイベント
         - 新着メールを表示できる
             - 未読メールのタイトルを太字にする
             - 未読メールのあるメールボックスの文字を太字にする
        - 本文表示中
             - 未読メールのタイトルを太字にする
             - 未読メールのあるメールボックスの文字を太字にする

共通分割：異なる上位要求に含まれる、共通の要求

      （ちょうど、状態分割に良い例がありました！）
         - 未読メールのタイトルを太字にする
         - 未読メールのあるメールボックスの文字を太字にする

コツは、まず時系列分割を使って要求を具体化していくことです。

時系列分割だとうまく当てはまらないものが出てきたら、「構成/状態/共通」で分割します。
- 時系列分割では正常系のルートを抜け漏れなく拾いやすい
- 「構成分割」「状態分割」「共通分割」では異常系を拾いやすい
  ４つの分割視点を持つことで、仕様の抜け漏れや食い違いが見つけやすくなります。

基本フォーマット

つらつらと文章で書いてきましたが、百聞は一見に如かず、ですね。
こういうイメージです。

このくらいなら「階層化された要求＝仕様」として充分にレビューできそうです。
このくらいの階層に分割できたら、開発とQAでレビューします。
※QAをレビューに入れることで要求からテストまで串刺しにして「テスト容易性」を高めることが期待できます。
QAは、この仕様に対して実装結果を確認していきます。以下のメリットが期待できます。
- 正常系は問題なさそう
- 分割により異常系も拾えそう（図：MAL01-03-03-001）
- 仕様変更があっても、仕様に対応するテストケースを修正するだけで済む
  - これが一番大きなメリットかと思います
一応、このやり方のデメリットも記載しておきます。
- とにかくめんどくさい！！

まとめ

いかがでしたか？
第一線を退いた感のある仕様化の方法ですが、まだまだ現役として頑張ってほしいところですね！
ですが、アジャイル開発プロジェクト全体で、この方法に取り組むのは正直おススメしません。。。
というわけで以下のような時に、ターゲットとなる機能を絞って実践してみてはいかがでしょうか。

機能の要求（ユーザーストーリー）にじっくり向き合ってみたいとき
要求から仕様、さらにテストケースまでしっかりトレースを取りたいとき

ソフトウェアテストをカイゼンする50のアイデア（P.84 「どうやって」ではなく、「何を」テストするのか説明しよう） ↩
システム開発プロジェクトの5割が失敗（日経コンピュータ「ITプロジェクト実態調査 2018」 ,2018） ↩