要求仕様書記述手法「USDM」について思う

こんちは。志望校がふっくら太郎になる。

ふっくら太郎です。

今回は、USDMについて、ちょろっと勉強する機会があったので、感想を書きます。

USDMは、普段の業務の中で触れてはいるのですが、仕様書のフォーマット程度の認識

しかなく、こんなかっこいい名前があることすら知りませんでした。

先日、ある方に教えてもらう機会があり、興味を持ち勉強した次第です。

USDMって何や？

• USDMは、「Universal Specification Describing Manner」の略語で、要求と仕様の記載方法を定義したもの
• 株式会社システムクリエイツの清水 吉男さんが提唱している。数冊本が出てます。

[改訂第2版] [入門+実践]要求を仕様化する技術・表現する技術 -仕様が書けていますか?

要求を仕様化する技術・表現する技術 - 入門＋実践 仕様が書けていますか?

USDMを理解するにあたって参考になるもの

分かりやすい資料が、ネット上で色々公開されてますので、紹介させてもらいます。

ありがたやですね。

AFFORDD派生開発推進協議会

http://swquality.jp/temp/nagasakiqdg15_usdm.pdf

株式会社SRA発表資料 

https://www.sra.co.jp/public/sra/event_seminar/seminar2014/140905-h/SRA_Seminar_140905-2.pdf

SQip Library

www.juse.jp

USDMについて調べた感想

• 要件定義の抽出は大事だ！

USDMの仕様書を見ていると、「漏れなく仕様を書き出せているか？(テストする側とし

ては、書かれているか？)」を意識しがちなんですが、そもそもの、「要求定義がしっか

りされているか？」が重要なんだなぁと、改めて感じました。 

現場で作業していると、「XX画面を印刷できるようにする」みたいな感じで、ざっくり

とした要求がUSDM仕様書に書かれていることが多いです。

で、要求を書いた人だったり、別の人が、ざっくりと仕様を書いて、よく分からないま

ま、ぼやけた感じで実装が行われ、残念な感じで世の中に出ていきます。 

「XX画面でXXボタンを押下すると、共通印刷レイアウト画面が表示され、レイアウト

画面上の印刷実行ボタンを押下すると印刷が開始される」みたいな感じで、最低限の振

舞いが仕様書に書かれているだけでも、「こういうことをしたいのね」って部分が、プ

ロジェクト内で共有されるので、その後の製作、設計の作業効率、要求の実現具合は、

大きく変わりそうです。 

要求定義がおざなりになる理由は、USDMを最初に導入した有識者が組織からいなくな

って、よく分からないまま、残った人が体裁だけ使って、形骸化するパターンが多いと

思います。

そういう意味では、要件定義をしっかりやることの意識付けと、USDMについての学習

コストを設けるだけでも、大きな改善に繋がりそうです。 

基本的に、ふっくら坊やはテストの人で、仕様を書くことは無いのですが、「こういう

要求の書き方してると嬉しいな」とは言えるので、身近な所から、今後、改善のお手伝

いをしていければなぁと思いました。

• 大規模開発の場合はどうなんだろう？

対象製品が数十万行、数百万行あるような、規模のデケェ！ソフトウェアの場合も、

USDMって効果的なんでしょうかね？

仕様書を複数人で書くことによる要求定義の粒度や仕様の切り出しサイズのずれや、モ

ジュールごとの記述粒度の統一具合など、いい塩梅に調整できるのでしょうか？

USDMを理解した上で書けば、誰が書いても、どんな製品でも、いい具合に要求仕様の

構造化ができるんだろうけど、そこは人なので、ちゃんと回そうとすると、組織文化ご

とのガイドライン的なものが必要になりそうな気がしました。

この辺り、うまいこと回している現場があれば、一度見てみたいです。

あと、仕様に関係するモジュールやソース、外部仕様書とのトレーサビリティについて

も、Excel仕様書では限界があるように思えました。

これも、市販品、OSSなどで、要件管理サーバー的なもので存在したりするのだろうか？

まぁ、まとめると、大規模開発におけるベストプラテクスを知りたいというわけです。