長崎ＩＴ技術者会　第９回勉強会　「長崎QDG2015 & 盛岡ソフトウェアテスト勉強会 合同報告会」の発表資料です。 http://nagasaki-it-engineers.connpass.com/event/21250/

1. 長崎ＩＴ技術者会 第９回勉強会
「長崎QDG2015 & 盛岡ソフトウェアテスト勉強会 合同報告会」
2015年12月5日 @ 大森文化の森
すずき しょうご
長崎QDG2015参加報告(仮)
公開版

2. • 2015年8月12日に開催された
「長崎SWQuality&DevelopmentGathering2015」に参加した。
• 当日の様子やセッションの概要などをお話しする。
http://kokucheese.com/event/index/307158/

3. 今日のお話しの内容
• はじめに
• 参加の動機
• 当日の様子
• 懇親会
• さいごに
• 付録
• 観光報告

4. はじめに
• 参加の動機
• USDMについて学べる機会
• 演習が複数人でできる機会は多くない
• 都道府県踏破カバレッジの向上
• 一度行ってみたかったｗ

5. 前日の天気・翌日の天気
2015年8月11日＠大浦天主堂 2015年8月13日＠出島

6. 当日朝の様子
http://news.yahoo.co.jp/pickup/6170303

7. 当日のコンテンツ
時間 タイトル スピーカー
12:00 ～ 12:10 オープニング「開会の挨拶」 池田 暁 氏
12:10 ～ 14:40 要求仕様記述手法「USDM」ってどんなの？
～明日から使えるUSDMのエッセンス～
清水 吉男 氏
14:40 ～ 15:05 SQuBOK読破会活動紹介とSQuBOKにおける
派生開発
藤沢 耕助 氏
15:05 ～ 15:25 Ｖ字モデルのテスト工程のインプットが
USDMだったときに慌てないために
池田 暁 氏
15:25 ～ 15:55 テスト自動化の現場から 浦山 さつき 氏
15:55 ～ 16:00 休憩 -
16:10 ～ 16:10 コミュニティアピールセッション 投稿者
16:10 ～ 16:35 クロージングトーク
派生開発とUSDMの今後を語ろう
清水 吉男 氏
池田 暁 氏
16:35 ～ 17:45 クロージング「閉会の挨拶」 池田暁 氏

8. 「オープニング」
• 長崎SWQuality&DevelopmentGathering2015(長崎QDG2015)の説明
• ソフトウェアの「品質」「開発」を取り上げるイベント
• 第一回のテーマ「派生開発」
• 参加者の住んでいるところ(都道府県)の分布
• 半分以上が、九州以外からの参加
• 長崎IT技術者会の紹介
• 池田さんの地域振興推進と地元愛(^^
• これまでの活動実績
• JSTQB AL テストアナリスト勉強会
• マインドマップ勉強会
• 第1回長崎QDG2015
• TPI NEXT 日本語版 勉強会
• ソフトウェアテストことはじめ
興味ある方は、Facebookグループ「長崎IT技術者会」に参加を！

9. 「要求仕様記述手法「USDM」ってどんなの？
～明日から使えるUSDMのエッセンス～」
• トラブルの多くは仕様の問題
• 仕様漏れ：仕様が明示されていない
• あいまい表現：読み手に伝わらない
• 設計ドキュメントには、「機能名」「仕様」は
明記されるが、「要求」は表現されていない。
• 機能の満たすべき「枠」を表現できない
• 「仕様」を拾いきれない、見落としてしまう。
USDMで解決可能
日本語をがんばれ
明文術 明文術 伝わる日本語の書きかた(NTT出版)
そこで、USDMです

10. • 「仕様」は、要求の中の「動詞」と「目的語」に存在する
• 階層構造で、仕様漏れしにくい構造になる
• 要求と仕様
• 上位要求と下位要求
• 1つの要求に対して、イベント(複数の動詞)が存在する。
動詞が「枠」を作る。
• 「理由」をつけて「要求」を相手に伝える
• 「理由」をつけることで「要求」を理解しやすくなる
• 「理由」から「仕様の引き出し」や「設計方法」を考えるこ
とができる

11. • 仕様として妥当かどうか？を考える方法
• ベースライン設定後の仕様変更率
• 品質を織り込む技術
• ISO 25010 からの評価の視点
(例：時間効率性、修正性)
• 品質要求も「要求」として表現しなければ実現されない
(例：保守性、移植性)
• 品質を織り込む設計技術が不可欠
• データ構造、アルゴリズム
• モジュール分割、クラス分割技術、尺度 など
変更仕様数
総変更数
× 𝟏𝟎𝟎 ≤ 𝟓%

12. • USDMを利用することで、派生開発を効果的にする
「変更要求仕様書」を作成できる
• 要求と仕様の階層表現ができる
• 要求と仕様を分けて表現する
• 要求に理由をつける
• 実現内容の認識を特定(Specify)することが大事
すべての変更を扱う要求仕様書を
「Before」「After」(差分)で表現することで、
変更の要求意図を把握し、
仕様漏れや影響範囲に気付きやすくする

13. 再演セッションをご覧ください
• SQuBOK読破会活動紹介とSQuBOKに
おける派生開発
(藤沢 耕助 氏)
• Ｖ字モデルのテスト工程のインプットが
USDMだったときに慌てないために
(池田 暁 氏)

14. 「テスト自動化の現場から」
• 自動化した事例の紹介
• 店舗ポータルサイト・顧客管理システム
• ほったらかしのテストケース
• テストしていないところから
バグ発見(デグレード発生)
• テストの草刈り
• 担当者の撤退
• 自動化が引き継がれない
自動化スクリプトに保守性を考えることは非常に重要。
• 自動化あるある事例
• 自動化の認知度が低い
• 急に動かなくなる自動テスト
• チケットの後回し
構造化されていないスクリプト
• 修正が追い付かない
• サーバのパンク
(テスト結果出力でストレージ枯渇)

15. クロージングトーク
派生開発とUSDMの今後を語ろう
• 変更情報から、どのようにテスト対象を絞り込むか
• なぜその箇所を変更するのか？
• その方法しかないのか？
• 影響箇所についてどこまで考えたのか？
• 影響が発生する個所について、根拠や理由は明確か？
• その他の箇所に影響が発生しないことなぜなのか明確か？

16. 懇親会
• 人数が多すぎず少なすぎなかったせいか
非常に内容の濃い交流ができた。
• 仕事や生き方（?）に関する
心構え的な何か。
• USDMとリスク管理 など
• 清水さんのお話しは非常に興味深かった。
ぜひ、機会があればまたお話ししたい。

17. 所感
• 人数は多すぎず、少なすぎずという感じで、密度の濃い
講義や議論ができた。
• USDMの講義や演習は非常に興味深かった。
• 要求と理由が明確になっている点
• 「仕様グループ」を要求や理由ごとに明示できる点
• 仕様の漏れに気づきやすくなる点
• USDMを使うためには、訓練が必要。
• テスト自動化は、けっこう泥臭い。
保守性をはじめから考慮に入れておかないと失敗する。

18. さいごに
2016年10月7日(金) 次回開催予定!!
10/10まで連休!!
http://nagasaki-it-engineers.connpass.com/event/21303/

19. 観光の足跡(^^;
• 三菱重工 長崎造船所

20. グラバー園
オランダ坂

21. 亀山社中の跡
若宮稲荷神社

22. 稲佐山

23. 平和記念公園
長崎原爆資料館
浦上天主堂

24. 出島
めがね橋

25. 関連サイト
• 【開催レポート】長崎QDG2015
http://swquality.jp/2015/08/qdg2015.html
• 長崎SWQuality&DevelopmentGathering2015のハイパーなレポート
http://mhlyc.hatenablog.com/entry/2015/08/24/000734
• 長崎旅行記
http://masskaneko.hatenablog.com/entry/2015/08/23/133246