yoshitake_1201’s diary

テストのこととか、ペンギンのこととか書きます。

2018/02/02 第3回長崎QDGに参加してきました!

NaITEさん主催の、第3回長崎QDGに参加してきました。
(大分遅くなったけど…)以下内容と感想です。

■開催概要

日時: 2018/02/02(金) 12:00 ~ 17:20 場所: メルカつきまち nagasaki-it-engineers.connpass.com

togetter.com

■各講演の感想

池田暁さん:「単なる仕様チェックから卒業するために 〜最初に抑えたいキホンのキ〜」

www.slideshare.net

講演内容は、昨年の盛岡勉強会での内容をギュッとまとめて、という感じでした。
(具体的にはスライド32~94の内容でした。)
個人的に、↑の資料を見て、講演内容を聞いてみたい!と思っていたのですごいありがたかった。。。

スライドにもあるんですが、以下のように設計の思考とテストの思考は違うんだよ。

  • 設計のための思考 > 問題領域を狭めていく
  • テストのための思考 >問題領域を広げていく

っていうのが、納得感が高かったです。
(さらにこの2日後に実体験することになって、理解は深まりました。)

テストをする前に如何に気づくことができるか?
っていうところを重要視されていて、同じ感覚だなぁと思いました。
(ただ、気づくまでのアプローチも、気づいてからのアプローチも、自分は全然足りないなぁとグサリ…。)
あと、ブラックボックステストホワイトボックステストは、
技法というよりはどちらかというとスタイル、っていうのはなるほど〜となりました。

原 佑貴子さん:「速効性重視のレビュー技術:高速2パーソンインスペクションのススメ」

なんとリモートでの講演でした。
原さんの登壇が決まったのは、開催日の週ということだったんですが、 講演が決まってからツイッターが盛り上がっていたのでワクワクしながら聞きました。
(原さんが、細川さんの話によく出てこられる赤ペンの方だったというのは、講演が終わってから知りましたw)

セッションの内容は 参加者が実際にインスペクション レビューを体験するというもので、 2人組になり、唐突に渡されたFlight Planning and Management Systemのドキュメントについて 役割分担してレビューするというかんじでした。

以下は原さんの講演資料と口頭で教えてくださったにレビュー実施のコツです。

  • お菓子を用意する!
  • 自分が1ページが何分で読めるか?っていう力を持っておくべき
  • 指摘に対して「いいね!」と口にする

  • 指摘や言い換えに自信がなくてもとりあえず言ってみる
  • 事実を指摘する
(書いていないことを指摘しない)
  • 欠陥の検出に注力する(原因や解決策を議論しない)

  • 1ページ目からレビューしない(1ページ目は、書いた人が1番自身があるから)

ガツッと”レビュー”という名目なレビューを体験したことがなかったので、 ただただ戸惑うばかりでした。
ただ、2人組になった相手がなそさんだったので、指摘の仕方とかも知れて助かりました。
感謝。。

一般にはインスペクションは重たい空気になりやすいとのお話だったんですが、 今回体験したのは楽しかったなぁ〜と。

そして後半、細川さんと原さんによる生インスペクションを披露してくださいました。
ドキュメントの曖昧さに対して「これはバグですか?」という指摘が衝撃でした。
ドキュメントをレビューする段階で、「バグ」っていう言葉を使うんだなぁと。

レビューはもちろんながら、静的テストという概念を、もうちょっとチームに広めていきたいなぁと思いました。

日下部先生:「いろいろ使える(システム理論に基づく)セーフウェアのためのモデルSTAMPとその分析法」

STAMPとは「ものごとがうまくいかないことを説明するモデル」!
とのことだったのですが…
そもそもSTAMPというものを知らなかったので…個人的には難しい内容でした。。^^;

以下を読んでそもそもどういうものか勉強しようと思います。
「はじめてのSTAMP/STPA ~システム思考に基づく新しい安全性解析手法~」の公開:IPA 独立行政法人 情報処理推進機構

STAMPを活用できそうな状況として、
例えば大学教授と学生の関係において。
* 大学教授の思惑>この内容の講義をやれば学生は積極的に参加するはずだ! * 実際の学生>とりあえず参加する、そもそもやる気がない…など。

というような状況をSTAMPで説明できそうとのことでした。
このあたりを聞いて、問題分析ということで TOCクラウドやブランチにも近いのかなぁ…って思ったりもしました。

くまちきさん: 「PSP活用SIG活動報告」

というのは覚えました!w
たぶんここが一番重要(違う

PSPは、CMM(Capability Maturity Model, 能力成熟度)を開発した ハンフリー博士が提案した個人レベルでの継続的プロセス改善のしくみ!
とのことなんですが、 PSPもまた知らなかった内容なので…こちらも個人的には少しむずかしい内容でした。。。
(そもそもCMMもよくわかっていないので…勉強不足すぎる。。。

以下を読んでみようと思います!
第1章 PSPを導入する理由(わけ) ~自立したエンジニアのためのライフハック:ゼロからはじめるPSP ─Personal Software Process | エンジニアマインド … 技術評論社

金子 昌永さん:「チームで、長期間で、たくさんのソフトウェアを快適に開発し、価値を生み続けるためのエンジニアリング」

www.slideshare.net

金子さん、とりあえず冗談が冗談に聞こえず、普通に信じてしまいました。
「天は人の上に人を作らず…」これは忘れられないw
たぶん、僕は金子さんをお見かけするたびに、思い出すんだろうなぁと思いました。

内容について、 ソフトウェアビジネスのイメージが、わかりやすくて納得でした。
またチームの方向性や、求められる知識など、考えさせられることが多く、 現状の分析をツールも含めてやってみると、足りていないものやできていることなど分析できそうだなぁと思いました。

LT セッション

tositeさん:「いっぽんのサービスのむこうに」

www.slideshare.net

LTらしいテンポ感なLTだったなぁーとw
システムを1から全部1人で導入してていてすごいなぁ…と。
自分も研究室時代にClientからServerまで全部やって大変だった記憶があるけど、 会社で製品としてそれをするのはただただすごいなぁと思いました。
寿司とビールが同じ問題とかあるんですねぇ。
第18回 MySQLの寿司ビール問題,Pgpool-II3.6.1リリース:OSSデータベース取り取り時報|gihyo.jp … 技術評論社

caori_tさん: 「一人じゃ探せない答えを探してみたら…」

caori_tさんの発表は、ひとまず癒やされますよねw
チームメンバーとの問題解決をするのにファシリテートって大事だなぁ…とひしひしと感じでおります。
さじ加減が難しいのと、これでいいのか?がよくわからないのが最近の悩みですが…。
ゆるファシをされたい。

さとうひろゆきさん: 「テストを料理で例えてみよう」

テストの伝道師、さとうさんの、テストプロセス(開発工程も含む?)を料理で例えてみた。
というお話。
常々、さとうさんは例えるのがうまいなぁ…と思います。
テストプロセスとか自分なりに説明しようとしてもなかなかわかってもらえないんですよね。
( そもそも自分がそんなに理解できてないというのが問題ないんですが…
経験してない相手に如何にわかりやすく伝えるか?というのは重要ですよね。
自分も精進しようと思います。

細川 宣啓さん:「ソフトウェア品質レビューの全て:生い立ちから先進技術まで」

昨年、私が一番拝聴した講演者は、間違いなく細川さんなのです!が…
まさか2018年、1回目のテストイベントで細川さんの講演を聴くことができるとは…という なかなか衝撃でしたw

「いいレビュー・すごいレビューってどんなレビュー?」という、問いかけから始まったのですが 、 これは自分が「いいテスターってどんなテスター?」って悩んでいた疑問に似ているなぁと思いました。
人や状況によってだいぶ違うだろうし、難しい問いだなぁ…と。
細川さんが提示された、うまくレビューする(いいレビューをする)という1つの解としては、以下とのことで、あぁ、たしかに直してもらわないと意味ないし、どうせ直してもらうなら気持ちよくのほうがいいよなぁ…と思いました。

  • 開発者に気持ちよく直してもらうこと。
  • うまくフィードバックして、すっと直してもらえる。そして、開発者の行動が良い感じに変わること。

また、バグ分析のために、毎日バグのカルテを書いていた、というのは刺激的でした。
バグのカルテを書いて、そのカルテを自分の血や肉として、今に活かせている、と。
自分の環境的には、バグの原因まで知ることが今の状況だと難しいですが カルテをつけていってみようと思いました。

■全体の感想

参加者と講演者が近くて、良い感じの会だなぁと。
懇親会も翌日のツアーも面白かったですし!
福岡から陸路で行ける数少ない勉強会なので、来年もまた参加したいなぁと思いました。

そして、長崎、とても美味しかったです(´▽`
f:id:yoshitake_1201:20180304000722j:plainf:id:yoshitake_1201:20180304000733j:plainf:id:yoshitake_1201:20180304000742j:plainf:id:yoshitake_1201:20180304000749j:plain