タイトルのイベント本編のお話です。
悲劇 - Heavy rain -
朝起きると何やら外が騒がしい。
なんかザーーーーみたいな音がするんですよね。
で、外を見たらすべてを知りました。
50年に一度の豪雨とのことでした。
当日、車や電車で来る方は大幅な遅れとなりましたが、幸いみなさん頑張ってきてくださいました。さすが長崎まで来るだけあります。
本編
何はともあれ、池田さんのアツイオープニングトークがあり、勉強会本編が無事スタートしました。詳細はこちら:
8月12日 長崎SWQuality&DevelopmentGathering2015(長崎県)
清水さんの自己紹介のあと、USDMに関する解説をしていただきました。
自分を「かぎる」
自己紹介のところでは書籍で書かれている一度挫折した話が出てきました。やはり読むのと実際に聞くのとでは大きな違いがあります。改めて、自分を「かぎる」ことはやめようと思いました。
清水さんは3年間の時間をすべて、技術の修得に投入したそうです。
とはいっても、具体的にどうすれば「時間をすべて、技術の修得に投入した」といえるのかわからなかった自分は、懇親会で詳しく聞いてみました。
以下の手順になります。皆さん、メモの準備はいいですか!
1.なにはともあれ、部屋にある娯楽装置(テレビ)を物理的に破壊すること
2.仕事終わりは、遅くとも20時には家に帰ること
3.そして、夜の2時まで勉強すること
4.見かけた技術書や論文は全部読むこと
5.夜ご飯の自炊はやめて、近場の食堂をローテーションすること。自炊は時間コストがかかるため。
6.どうしても怠け心が出てきたら、ひたすら峠道をのぼること。一歩の積み重ねで前に進むことができるのだと体に覚えさせる。できるだけバスの本数の少ない峠道を登るのがおすすめ。
どうですか皆さん!方法を知っていても、それができるかどうかはまた別問題なんだなって私は思ってしまいました!
USDM
このセッションは基本的に書籍の内容をベースとした解説となっていました。書籍の簡単なまとめのリンクは以下になります。
『[改訂第2版] [入門+実践]要求を仕様化する技術・表現する技術 -仕様が書けていますか?』(清水吉男)の感想(24レビュー) - ブクログ
さて、本題のUSDMですが
残念ながら私はまだ、この話がピンとくるレベルには至っていませんでした。というのも仕様書を書いた経験がないからです。
とはいえ、要求の理由をつかまなければ的はずれな対応になってしまうというのは日常でも全然ある話です。
大学時代のホテルのアルバイトで、
カーテン持ってきて→ちがうよ、緑色のカーテンだよ→大きさが違うよ→もういいよ
みたいなやりとりがあって、重いカーテンを持って仕事場を3往復くらいした挙句怒られたことがありましたが
そういった時も「この机にかけないといけないから(理由)、こんな色のこんな大きさのカーテンを持ってきてくれ(説明)」的な要求を引き出せていればよかったわけです。
なので考え方はおさえておきたいなと思った次第です。
ちなみに、USDMのセミナーが今度名古屋であるっぽいのでそれに行ってきます。
※これは、最近編み出した藤沢メソッドという手法で、「わかんなかったらもう一回同じ説明聞きに行けばいんじゃね?」という方法論です。私はこの方法でテスト設計コンテストチュートリアルを2回聞きに行きました。(東京と名古屋)これはあまりに変態すぎてあまり実践する人がいませんが、非常に理解が深まるのでお勧めです。
また、USDMのサンプル演習も最後にやったので、これも後で時間を見つけてやり直したいです。
Communityショートセッション「SQuBOK読破会活動紹介とSQuBOKにおける派生開発」
これは自分の担当セッションでした。
数々のレビュー指摘をいただき改善したかいあって、自分でもだいぶまともな出来だなと思います。
あと、発表は練習したのですが2分ほどオーバーしました。練習ではうまくいっても、本番だと色々練習で言ってなかったことも話したくなりますね。もっと短くなるように練習すべきでした。
セッションでも言いましたが、SQuBOKは本当に良い書籍です。ソフトウェア品質にかかわる人であれば必読でしょう。また、内容も充実しているのでぜひ第二版を買うことをお勧めします。会社に無かったらこっそり買ってしまいましょう。
また、資料で言及しているXDDPの書籍はこちらです。
■Qualityセッション&ディスカッション「V字モデルのテスト工程のインプットがUSDMだったときに慌てないために」
イベントとりまとめの池田さんのセッションです。気合入っていました。
「長崎SWQuality&DevelopmentGathering2015」V字モデルのテスト工程のインプットがUSDM形式だったときに慌…
趣旨としては、
V字モデルのソフトウェア開発プロジェクトの開発工程にXDDPが適用されていて、そんな中「じゃ、テストやってね」とテスト工程で要求仕様書を渡されてしまった!
というパターンにおいてどう対処するかという話でした。
まずそもそもUSDMについての基礎知識はおさえておこうという話や、
社内プロセスを変更するのは長い期間がかかるため、その場でできる応急処置的な対応をしようというわりと生々しい話がありました。(このあたりは事情がおそらく近いので納得感が強かったです)
これに対する清水さんの回答は、イベントの後半にありました。そちらは後述します。
■Qualityセッション「テスト自動化の現場から」
テスト自動化で陥りやすい罠の話でした。
自分もテスト自動化を少しかじったことがあるので、「あるある」には共感しました。
しかし、その「あるある」に対して現実的な対応策も同時に示していて勉強になりました。
次の「あるある」はなんだろう?と非常に興味を持ちながら聞くことが出来ました。
■コミュニティアピールセッション
バグ票ワーストプラクティスや、九州ソフトウェアテスト勉強会の紹介がありました。
長崎SWQuality&DevelopmentGathering2015 レストタイムセッション スライド集
そして、後日バグ票ワーストプラクティス検討プロジェクトの鈴木しょうごさんとコミケ参加することになるとは、この時夢にも思わなかったのでした…この件は別途書きます。
■クロージングトーク「派生開発とUSDMの今後を語ろう」
清水さんからの、池田さんの発表に対する回答がありました。
個人的に印象に残ったのは「テストケースも、派生開発の対象となる」ということ。これはまったく考えていませんでした。
確かにテストケースの要件とのトレーサビリティはよく重要視されるものですから、当然といえば当然なのかもしれません。
ただ、開発者から変更要求仕様書を受け取ってテストケースを派生開発すればいいのか、と言われると
そもそもXDDPやUSDMが認知されていない状況ではそうもいかないのかな、と色々考えました。
「テストケースは、要件とのトレーサビリティを取る必要がある」という認識がもっと広まればよいのかなと思います。そもそもちゃんとしたVモデルを知っているのなら、要件定義書がシステムテストやユーザ受入テストのインプットとして必要であることはわかりそうなものなのですが…おっと愚痴になってしまいました、すみません。
全体を通して
自分も盛岡ソフトウェアテスト勉強会なるものを企画しているのですが、
やはりこういったイベントの主催はエネルギーが必要なのだと思い知らされました。
池田さんの発表やスライド、準備の入念さからそれはありあまるほど感じられましたし、実際そういったエネルギーがあるからこそ感じるものもあるのだろうし協力してくださる方もいらっしゃるのだと思います。
とてつもなくどでかい背中を見せつけられた感じがします。
ですがここで「かぎって」しまっては後がないので、どうにか踏ん張っていこうと思います。
懇親会
やはり長崎は魚がうまいですね。プリップリですよ。さすが港町は違いますね。
ここで前述の清水さんの「すべてを投入した3年間」の話を伺いました。圧倒されましたね。
ですが私は頑張ります。
「あの人だからできた。自分には無理だ」といって
逃げるのはもう終わりにしたいです。
歯を食いしばる。
と、決意を新たにした一日でありました。
大変意義のある勉強会を、無料で運営してくださった池田さんには感謝してもしきれません。
僕は入社してから2年がたちました。周りの方々はもっとたくさんの年数がたっています。
しかし、そこにあるのは年数の差なのではなくて、積み重ねた経験の差です。それを思い知りました。
3年後、10年後、20年後、40年後。
あんなふうに自分はなれているだろうかと。
背中が遠い人ばかりですが、一歩を踏み出さなければ近づけません。いいえ、一歩だけでは遠ざかるだけかもしれません。
少しでも近づきたいです。近づいて、いつか同じ場所で話をしてみたいです。
すみません、若干ポエミーな感じになってしまいましたが
とても意義ある一日でした。関係者の皆様本当にありがとうございました。