なかくきです。
USDM分科会の第２回オフライン会を行いました～。
開催日：4/6（金）19:00～21:30
参加者：7名
今回の内容は、
各自がいつも書いてる要求仕様書をUSDMで書いてみて、
それを発表してディスカッション
（とはいっても、前回は結局ほとんどの人がUSDM）
【USDM書く前に分析が必要】
鈴木三紀夫氏からいただいた資料より
「USDMが書けないと悩んでいる人の中には、
要求獲得や要求分析の知識や技術が不十分な場合がある。」
このことを大きく実感
ビジネス要求は何？システム要求は何？
システムを作ることを前提とせず、つくらなくても解決できないか？
どんなシステムができるとユーザゴールを満たすの？
を考えておかないといけないのですね。
今回のお題だと、
「FreemindのファイルをExcelで読み込む」と言う方向になりがちですが、
そもそもFreemindを共有ツールとしてインストールさせる、インストールできるようにする、
というアプローチもありでは？とか。
いきなりUSDMを書こうとしてはいけないのですね。
そのほかにもこんな話も
・ユーザーの要望をそのまま「要求」にしてはいけない。
ちゃんと整理と分析をしないと。
・理由に要求（～したいから）が混ざりがち。なぜその仕様が
ほしいのかなどを考えないといけない。
・要求の分析の仕方は様々だった。マインドマップを使う人が多かった。
そして分析のプロセスを踏んだ人は、差異はあるもののちゃんと
「要求」を意識して書けていたと思う。
【ユースケースからのUSDM】
ユースケースからUSDMを作成された方からは、
ユースケースを作ってからの方がUSDMが書きやすくなった。
という意見がありました。
ただし、ユースケースを作るのに時間がかかったとか。
見る方もユースケースがあることで全体を把握しやすいと思いました。
【アプローチの違い】
同じお題でも、問題を解決する方法は様々。
これはユーザゴールに対する解決方法であり、
解決方法はひとつではなく、いろいろなアプローチが出きますね。
出てきた解決アプローチは以下の３つ
・ExcelがFreeMindファイル(mm)を解釈して読み込む
・FreeMindがExcel形式のファイルを出力する
・FreeMind、Excelともに別の新たな形式を出力する
参加メンバーから、これらの解決方法をUSDMを落とす際に、
実現方法まで考えるとどこまでも詳細になってしまい、
気づいたらユーザゴールから外れていることになったりしたとか。
自分としては、実現方法をある程度考えておかないと、
いざ作るときに「作れません」となりかねないので、その視点は必要かなと。
次回
開催日：5/11（金）
内 容：各自の要求仕様について、テスト観点でレビューして、
テスト設計をして発表会
したっけ！！
【おまけ】
本日のお菓子
菓子名：モロホロッキー
内容：
とうもろこしの風味で、名前のとおりホロホロした感じ。
おいしかったけど、飲み物が必要かも。
評価：▼▼▼▽▽ ※独断と偏見の評価です！！
