先日、AFFORDD主催の「USDM勉強会」に参加してきましたので、どんな感じだったのか簡単にレポートします！
12/8（金）。外は気温マイナス５度。前日から爆弾低気圧が暴れ、風と雪がひどくてとても寒い１日でした。講師は「要求を仕様化する技術・表現する技術（以下USDM本）」著者の清水吉男氏。
14時～20時まで講義と演習、間の休憩２回と結構ハードなタイムテーブルでしたが、USDM以外にも清水さんご自身の実体験や勉強の方法など、色々なジャンルのお話が入り交じり、とっても面白くて最後までニヤニヤ楽しく勉強できました。
＃1/3はUSDM以外の話だったんじゃなかろうか(^^; ・・・
私は4・5年ほど前に、どうやって仕様をまとめていけばいいのかわからず困っているところで、USDM本に出会いました。また、今年はTEF道のUSDM分科会にも参加して、少しはUSDMをかじっていたつもりだったんです。
でも、全然だめ。要求と仕様をちゃんと理解していなかったり、USDMがカバーする範囲を勘違いをしていたことを思い知らされました。最後の演習でも、うまく要求が表現できず。悔しい～（＞＜！
清水さん曰く、「要求は最初はうまく書けないものなので、ちゃんと表現できるようになるまでには訓練が必要。まずは書いてみて、１週間後に見るとよい。そこで何か気がつけば、成長している。」
もう一度FreecelのUSDMを書き直してみようかな。実はJaSST'12 北海道のWSで使ったUSDMは私が書いたのですが、今書けばもうちょっとうまく書ける・・・はず。
さて今回、いくつかの疑問を抱えて勉強会に望んだのですが、終わってみるとほとんどが解消されていました。スッキリ～。せっかくなので、以下で少し紹介しますね。
＃私の理解による解釈が入っているので間違っていれば指摘ください。
１.USDMで定義・表現する領域はどこか。
- 書籍ではUSDMがカバーする領域はシステム要求から下層と書いてある。
- これは、システム要求のなかのソフトウェア要求（ソフトウェアへの要求）を指す。
２.要件定義書とUSDMの関係は？
- 本来は、要件定義＝USDM（要求仕様書）。
- ただ、実際には要件定義で仕様まで落とせていない（仕様が書いてない）ことが多いので、USDMに要件定義が包含されるような状態がほとんど。
３：理由には何を書く？目的とは違うのか？
- 理由欄には、その振る舞いがソフトウェアに求められる理由を書く。Reason・背景。
- 目的は含めない方がいい。目的にはソフトウェアへの要求以外の、ユーザーの要望やビジネスの背景といったものが入ってくるので、範囲がぼやけてしまう。
- 理由＋要求で文章になることが多い。○○なので（理由）、△△したい（要求）。目的＋要求ではうまく文章が結べない（と思う）。
４.画面仕様。例えば入力桁の記述が画面で分散し、一覧性がなくて困るが？
- 必要であれば別表で補足すればいい。どんどん自分で工夫しろ。
５.ロジックなど、仕様欄に文章で表しづらいものがある。
- 図で書いてセルに張ればいい。自分で工夫しろ。
- 仕様は操作の流れを見せることが大事なので、細かいロジックは別参照にした方がいい。
６.ユーザーの要望を分析した要求と、USDMの要求は同じ？
- ちょっと違うようだ。
- 設計者やPGは、細かくしてから（一段下げてから）、要求を出そうとするからうまくいかない。何がしたいんだい？と（一段上げてから）、出てきたものがUSDMの要求になる。
- ただし、上がりすぎてユーザーの要望レベルになってもだめ。あくまでソフトウェア要求の範囲内で考えること。
少し、分かってきた気がします。試しにUSDMのセルフチェックリストを作ってみました～。
まだ粗々なので今後推敲していきたいと思います。
■USDMセルフチェックリスト
＜要求＞
□ソフトウェアへの要求になっているか。
□「振る舞い」を表しているか。
□「イベント」が特定されているか（どのタイミングで、何がどうなる）。
□「目的語」、「動詞」が入っているか。
□どこまでを作ればいいか、範囲を示しているか。
□例外処理、エラー処理が入っていないか。例外は無理に入れずに省略してもよい。
□動詞は多くて５個ぐらい。多ければそれらをまとめるような表現にして、その分、仕様グループを作って分ける。
□仕様になっていないか。具体的な数値が入っていればそれを別の言い方にする。2秒ー＞長押し
□動詞が一つなら細かすぎる。ある一連の操作の一つの処理しか表していなかったり、イベントが入ってないなら、細かすぎる。○○のときに○○して、○○する。ぐらいが最小。
□本当にその階層化は必要か。最初は階層なしで書いてみた方がいい。最初は細かくせず、まとめてみた方がいい。大きくなりすぎたら、細かくするぐらい。最初から階層を意識しようとすると難しい。
□保守性の要求は書いたか。
□実現可能性が見えるか。
□検証可能性が見えるか。
＜仕様＞
□グルーピングされているか。
□シナリオ・操作の流れになっているか。
□要求のなかに収まっているか。迷子なら、別の要求に入れるか、新しい要求を作る。
□誰が見ても同じ振る舞いをするソフトウェアが作れるところまで、書いてあるか。
最後に、わざわざ北海道までお越しいただいたAFFORDDの清水さん、梶本さん、そして勉強会をセッティングいただいた安達さん、本当にありがとうございました。とっても楽しかったです。多謝！
（小楠）