初めまして、テストエンジニアのノッカーです。
日々の業務の中で、いままでとは違う新しい経験ができましたので、その体験談を共有させていただきます。
早速ではございますが、以下のような場面に遭遇したことはありませんか？
要件定義(要求分析含む)の問題により、実装の抜けや漏れ、実装内容の誤りが発生。
そして後の工程に影響が・・・
私はこの問題をUSDMを用いて解消することができました。今回はUSDMがどのようなものなのか、USDMの特徴、実際にUSDMを導入した経験を書かせていただきますので、参考にしていただければ幸いです。
USDMの概要（要求仕様書）
USDM（Universal Specification Describing Manner）とは、日本語で言うと
要求と仕様の記載方法を定義したもの
となり、要求仕様を明確に定義するための手法です。詳細については後で説明しますが、まずはUSDMを利用することになった背景からお話したいと思います。
導入のきっかけ
私がこれまでテストベースとして扱ってきた資料の殆どは、開発担当者が作成した機能仕様書です。その中には情報が十分に揃っている機能仕様書もあれば、情報が不足している機能仕様書もありました。おそらく、開発担当者の方もQAの方も、情報不足や共有漏れによる仕様の誤認やすれ違いの経験があるかと思います。
私が経験してきたプロジェクトでも、情報不足や共有漏れにより以下のようなプロジェクト状況となっていました。
- テスト分析フェーズでの仕様質問が多く、回答待ちの時間が頻繁に発生していた
- テスト分析段階での仕様質問により、仕様の漏れが判明し、追加の改修が発生した
- 本来改修しなければならない画面とは別の類似画面に改修が入ってしまった
- 仕様の意図が不明瞭であるため、テストの目的を定めるのが難しい場合があった
これらを解消するために、「開発前にテスト分析できる環境を整備する？」「開発担当者とQAが協力して要件定義をレビューする？」「仕様に関連する背景や意図をヒアリングするプロセスを確立する？」などQAチームで検討しました。その中で「USDMはどうだろう？」という意見が浮上し、QAチームでUSDMの勉強をして以下のことがわかりました。
USDMとは、ひとまとまりの大きな要求を細かく分割し、分割したそれぞれの要求に対して具体的な処理や振る舞いを想定して仕様化(要件定義)する手法。
期待できる効果としては、
- 要求、要求の背景、仕様(要件)が並列されて見やすい
- 細かく要求が分割され、要求の範囲を理解しやすい
- 理由(要求の背景)が書かれるので誤った仕様化(要件定義)が減りそう
- 要求の範囲が理解しやすいため、具体的な処理、振る舞いを検討しやすい
- 具体的な処理、振る舞いを書くため、テスト仕様にもしやすい
- 要求、仕様がID管理されトレーサビリティが取りやすい
- 仕様(要件)毎にステータス管理(仕様Fix、実装済み、テスト完了など)が可能
なんだか、プロジェクトの状況を好転できる可能性を感じました。これなら試してみる価値があるのではないかという結論に満場一致で至り、USDMを導入することとなりました。
期待できる効果を見てみると、実装の抜けや漏れ、実装内容の誤りの他にも、以下のような状況の改善にも効果がありそうですね。
- 要求と要件のトレーサビリティが取りづらくなってしまっている
- 要件毎のステータス(進捗)が把握しづらくなってしまっている
- 要求に変更が入った場合に検討しなおしとなる要件、物量が把握しづらくなってしまっている
ということで、USDMについて、もうちょっと詳しく説明していきたいと思います。
特徴
USDMの構成としては以下のとおりとなります。
USDMのフォーマット（テンプレート）
（１）要求 要求を記述します
（２）要求を分割 大きな(複合的な)要求事項を分割して細かい(単純な)要求にします
（３）要求を階層化 分割した単純な要求を元の要求の下層に配置します
（４）理由を記述 要求を通したい理由を記述します
（５）説明を記述 補足事項や背景など要求の記述では足りない情報を記述します
（６）キーワードラベル 馴染みのある用語や別名を記述します
（７）グループ 要求や仕様が多い場合に小さい集合に分類して範囲を限定します
（８）仕様を導出 要求と理由から特定できる仕様を導き出して記述します(要件定義を行う)
（９）仕様ラベル 仕様であることを示し、要求と明確に分離します
全てをご紹介するには膨大となってしまいますので、今回は要点を抑えた以下の4点にフォーカスしてご紹介します。
- 要求を分割する
- 要求を階層化する
- 理由を記述する
- 仕様を導出する(要件を定義する) ※以下、仕様と要件は同義としてお読みください
要求は曖昧性を多分に含んでおり、中には要求を書いた本人にしかわからないということもあります。以下の図の要求を例にして、曖昧な要求を具体的にしていく方法を説明していきます。
EM1 は要求に対する通しIDのようなもので特に指定はありませんが、一意となるように記述します。画像の中にある □□□ は仕様ラベルと呼ばれるもので仕様を書く欄であることを意味し、□にチェックマークなどを入れることで、ステータス管理にも活用できます。
まずは複合的な要求を単純な要求に分割します。分割した要求は階層化して、元の要求を上位要求、その配下に分割した要求をそれぞれ下位要求として記述します。
次にそれぞれの要求に対して理由付けを行います。
USDMは見る人の認識のブレを抑える目的で本質的な理由を記述することが必須事項となっています。
「本来改修しなければならない画面とは別の類似画面に改修を入れた」は、改修の目的(理由)が曖昧だったため発生した事案となります。本質的な理由が書かれることで改修しなければいけない画面や機能の取り違え、改修内容の誤認を防ぐことを期待できます。
次に下位要求から仕様を導き出し、特定できるレベルまで仕様化(要件定義)を行います。下位要求EM1-1で例えるなら、保存するデータと保存先のHDDの情報を得るために何が必要かという要求に含まれる具体的な処理や振る舞いを表現します。
※上記仕様は一部となります
単純な要求である下位要求から仕様を導き出すことにより、仕様化に必要な情報の粒度が細かくなり、仕様漏れのリスクが軽減されます。以前の問題点として前述した、仕様漏れが発覚して追加の改修が発生するような事例については、下位要求による具体性とその要求が必要な理由、そして特定できるレベルの仕様が記述されたことによって解消されました。
USDMを導入してみて
要求の理解が容易になり、手戻り開発の発生なし！
要求仕様書作成段階で開発とQAがブレインストーミングしながら、要求の分割～仕様化を一緒に行うことで以下の表の結果となりました。
導入してまだ日が浅く、要求数も試行回数も少ないところではありますが、滑り出しとしては好転していると言ってもいいでしょう。
USDMで記述された仕様書は、要求が明確に理由を添えて具体化されており、仕様の意図が明瞭です。この明確な意図により、誤解を防ぐだけでなく、価値を高める要素として、理由を考慮した代替案やより良いアイデアが出てくる場面も増えました。
さいごに
まだまだアップデートが必要な部分、改善が必要な部分は垣間見えますが、私が狙っていることは、下流工程での工数削減やプロジェクトメンバーの負担解消です。開発工程の後半で仕様変更が発生すると納期への影響が懸念されます。もちろん、要求仕様書作成にも期日はあるかと思いますが、少なくとも私が関わったエンジニアの方々は口をそろえてこう言います。
「後になって問題が発生するより、前に問題を見つけた方が何倍もマシだ」
どの業界にも同じことが言えるとは思いますが、私自身も早い段階で問題や改善点を見つけて、改善していくことを心がけています。
最後までお読みいただき、ありがとうございました。
