「相談」もレビューである #JaSSTReview

「レビュー」に対するイメージ

皆さんは「レビュー(特に設計レビューなどのコード以外のレビュー)」と聞いてどんなイメージを持ちますか?

  • 大きな会議室に有識者と呼ばれる人が多数集まる
  • 色々と指摘を言われ、それに対して納得する返答が求められる
  • 完璧なドキュメントを用意して、指摘が無いクオリティにしてからレビューに臨む

こんなケースもレビューです

一方、普段の業務でこんなことはありませんか?

  • 「ちょっとここの部分、どうすれば良いのか分からないんで、教えてもらって良いですか?」
  • 「方針を考えてみたんですけど、ちょっと見てもらって良いですか?」

一見すると、「ただの相談じゃないか」と思うかもしれませんが、これも立派なレビューです。*1

「レビュー」というと堅苦しいイメージがあるかもしれませんが、こういう普段の業務でも実はレビューを行っているのです。

f:id:nihonbuson:20191021091535p:plain
「「超」やさしいレビュー ~開発とQAに壁はない!~」より(JaSST'18 Kansaiにて発表)*2

MTGのやり方以外のレビューの話がしたい!

一般的に「レビューの方法」について調べてみると、「どのようにMTGを開くのか」「MTGにはどんな人が参加していると良いのか」という話題ばかり出てきます。

しかし、これらの情報はこの記事の最初に書いた「レビューとは有識者と呼ばれる人が多数集まる」というレビューに限定している可能性が高いです。*3

しかし、「MTGの開催方法」ではない部分にも色々と考えることはあります。

レビューを行っている人は「相談を受けるときに、どのような部分を気にして会話をしているのか」「レビュー時にどのように対象物を読んでいるのか」「レビュー中はどんなところを気にしているのか」など、会議のやり方以外で考えたり工夫したりしている部分があるはずです。

そんな内容について議論をしていきたいと考えています。

JaSST Reviewでレビューの中身について考えてみませんか?

11/1に「JaSST Review'19」という、レビューについて考えるシンポジウムが行われます。

www.jasst.jp

レビューMTGの開催方法ではなく、「レビューでどのようなことを考えればよいのか」について、このシンポジウムで一緒に見つめ直してみませんか?

レビューの内容を考えたい方々のご参加を待ってます!

*1:「ピアデスクチェック」や「ペアレビュー」と呼ばれるレビュータイプです

*2:元資料は JaSSTソフトウェアテストシンポジウム-JaSST'18 Kansai-レポート に載っています

*3:「インスペクション」や「チームレビュー」と呼ばれるレビュータイプです

JaSST Review'19の見どころ紹介3「『違和感のつかまえかた』 ~組み込みシステムの開発者(テスター)としてやっていること~」 #JaSSTReview

はじめに

11/1にJaSST Review'19 が開催されます。

www.jasst.jp

そこで、何回かにわたり、JaSST Review'19での見どころを紹介します。

深谷さん(miwaさん)のセッション紹介

今回紹介するセッションは、miwaさんによる講演「『違和感のつかまえかた』 ~組み込みシステムの開発者(テスター)としてやっていること~」です。

セッション内容として、下記のように書かれています。 *1

みなさんは「なんとなくだるい」「寒気がする」「熱っぽい」というような違和感を感じた時、どうしますか?症状がひどくならないよう行動を変える方が多いのではないでしょうか。

開発の現場で感じる違和感も同じです。違和感は『注目すべきシグナル』です。より良い製品を作るため、みなさんは行動を起こさなくてはなりません。

本セッションでは、私がいつ、どこで、何を見て違和感を感じているのかを紹介します。また違和感をつかまえるために大事なこと、違和感をつかまえやすくするコツや工夫についてもお伝えする予定です。

今よりももっと違和感に敏感になりたい、違和感をもっと製品開発に活かしたい、そんな方の参考になればうれしいです。

見どころ

miwaさんがブログなどでも発信している*2「違和感」に着目して発表する点が見どころです(勝手に思っています)。

普段から違和感を言語化することを大切にしている、miwaさんならでは発表になると思います。

レビューツールだけに囚われない、「現場で感じる違和感」をどのように発表で伝えてくれるのか楽しみです!

おわりに

JaSST Review'19はまだまだ申し込み受付中です!(直球な宣伝)

www.jasst.jp

今まで無意識的に行なってきた内容を改めて考え直すきっかけになると思うので、違和感をつかまえて製品へ活かす方法が気になっている方は、ぜひ11/1に赤坂でmiwaさんの講演を聞きに来てください!

JaSST Review'19の見どころ紹介2「レビューツールの利用とプロセスのあり方」 #JaSSTReview

はじめに

11/1にJaSST Review'19 が開催されます。

www.jasst.jp

そこで、何回かにわたり、JaSST Review'19での見どころを紹介します。

岡野さん(あさこさん)のセッション紹介

今回紹介するセッションは、あさこさんによる講演「レビューツールの利用とプロセスのあり方」です。

セッション内容として、下記のように書かれています。 *1

ソフトウェア開発の中で、レビューは多くのプロジェクトで実施されます。ツールを利用される方もいらっしゃるのではないでしょうか。「なんでこのツールなんだっけ?」のような疑問を持ちながら利用していることはありませんか?

その疑問・違和感は、なぜおきているのでしょう?

利用したいシーン・動機(問題・課題)に合致した目的・用途ごとにレビューツールの強み・弱点をしり、選択・利用する必要があります。

私が所属するSEPGでは、ツール利用の推進も行っております。

その際にどのような点を考慮しているか、現場ではどのような課題が多いのか、についてお話させていただきます。

レビューだけではなく、他のプロセスでも共通する考えでもありますが、レビュープロセスに照らし合わせて、一緒に考えていきましょう!

見どころ

レビュー利用の推進をするにあたり、ただ「このツールを使え」ではなく、どのような点を考慮しているかを言語化して発表する点が見どころです(勝手に思っています)。

去年登壇して頂いた白水さん*2もそうですが、レビュー利用に関して企業で組織的に行っていること言語化して伝えていただく機会は非常に少ないので、貴重な発表だと思います。

私自身もそのような発表を聞くのが今までなかなか無かったので、非常に楽しみです!

おわりに

JaSST Review'19はまだまだ申し込み受付中です!(直球な宣伝)

www.jasst.jp

他のJaSSTでも積極的に発表されている方で分かりやすいと思いますので、レビューツールをどのように考えて導入すれば良いか気になっている方は、ぜひ11/1に赤坂であさこさんの講演を聞きにきてください!

JaSST Review'19の見どころ紹介1「文書校正におけるReviewと活用するための分類およびルール化」 #JaSSTReview

はじめに

11/1にJaSST Review'19 が開催されます。

www.jasst.jp

そこで、何回かにわたり、JaSST Review'19での見どころを紹介します。

津田先生のセッション紹介

最初は、筑波大学の津田先生による講演「文書校正におけるReviewと活用するための分類およびルール化」です。

セッション内容として、下記のように書かれています。 *1

ソフトウェアは多種多様であるため,各工程の成果物は組織やプロジェクトによって様々に表現されている.また,レビューするソフトウェア関係者の背景知識やスキルもばらばらなため、指摘事項も一定ではない.そのため,ソフトウェアレビューに関するノウハウには規則性が乏しく,ルール化が困難であり,多くは個人の経験と勘という暗黙知として蓄積されている.

そこで本講演では,規則性に乏しくルール化が困難な人間の文章作成における"間違い"をルール化することで,文書校正支援システムを実現したプロセスを紹介する.このプロセスで実現した仕組みは,Microsoft Wordなどの中でスペルチェックシステムのベースとなっている.この開発における最大の課題は,"間違い"という偶発的であり意図としない事象を形式化することであった.このノウハウを紹介することが,ソフトウェアレビューの知識化の一助となれば幸いである.

見どころ

文書校正支援システムを実現したプロセスが見どころです(勝手に思っています)。

Microsoft Wordなどで文章を書くと、下記画像のように赤波線が入ると思います。

f:id:nihonbuson:20191007200918p:plain
Wordでよく見る赤波線

津田先生はこの赤波線のシステムのベースを開発した人です。

システムを作った背景や、どのようにしてこのシステムを作ったのか、過去の経験からどのようなものをシステム化できると考えられているのか、などなどを聞ければと考えています。

おわりに

JaSST Review'19はまだまだ申し込み受付中です!(直球な宣伝)

www.jasst.jp

津田先生のお話を一度聞かせていただいたのですが、ご自身の経験の話もそこからの思考の話もすごい良かったので、興味がある方はぜひ11/1に赤坂で講演を聞きにきてください!

技術書典7で頒布しました&2F→3Fへの移動経路の話 #技術書典

目次

はじめに

先日、9/22に池袋サンシャインシティで行われた「技術書典7」で本を頒布しました。

techbookfest.org

本記事では、今回の頒布物の話と、2F→3Fの移動経路の話をします。

頒布物

今回私は、合同誌と個人誌を執筆しました。

合同誌

技術書典5,6に続き、Crabinkとして『300 Multiple Choices』という、複数人のテストエンジニアが書いた合同誌第3弾を頒布しました。

f:id:nihonbuson:20190927020319p:plain
300 Multiple Choices

書かれている内容のラインナップとしては以下の通り。

  • アジャイル
  • 開発者に伝えるテストの研修
  • ファシリテーション
  • プロジェクト運営
  • テスト会社への発注
  • リスク分析
  • テスト自動化
  • テスト計画
  • QA活動
  • 海外で働くことについて

非常に多岐に渡っています。

おそらく、今までのCrabinkで一番テスト要素が多いんじゃないかとの噂です。

まだ、物理本が余っていますので、また別のイベントで頒布するかもしれません。

個人誌

そして今回は、個人誌も頒布することにしました!

タイトルは『事例で学ぶ ソフトウェアテストと品質』です。

f:id:nihonbuson:20190927020953p:plain
事例で学ぶ ソフトウェアテストと品質

こちらは100部用意したのですが、2時間足らずですべて頒布しました!

頒布終了後も「もう無くなっちゃったんですか?」「電子版は無いんですか?」「再販しないんですか?」と多くの方からお声をかけていただきました。申し訳ないと思いつつ、そのように言ってくださり嬉しい限りです。

何よりも印象的だったのは、

「こんな表紙の言葉なんてただの煽りで、中身は大したこと無いんだよ」

と話していた2人組が、本の中身を読んだ上で購入に至ったことです。*1 眉唾物で読み始めた人にも買う価値があると感じてもらえたのはすごい嬉しいです!

少し加筆修正を加えた上で、より多くの方に届けられるように検討したいと思います。

2F→3Fへの移動経路について

我々のサークルの位置

SNS上でも話題になっている2F→3Fへの移動経路ですが、我々のサークルは一番その状況を把握していたかもしれません。

なぜならば、我々のサークルは一番、2Fから3Fへの移動待機列のところに一番近かったサークルだからです。(下の地図の赤矢印の部分は我々のサークルです)

f:id:nihonbuson:20190927022957p:plain
サークルの位置

待機列の状況

2F→3Fへの移動待機列は、図のオレンジ領域の部分に形成していました。

元々、「入場待機スペース(Cホール)」と書かれた部分全体が、移動の待機列として用意していたスペースだと思われます。

しかし実際には2列×25名程度の塊が2つ分ぐらい(計100名程度)しか、混雑している時でも並んでいませんでした。

動線の影響

そして、この導線の煽りを我々のサークルも少しだけ受けました。

本来、出口もしくは移動待機列へ通る動線を地図上で見ると、必ず我々のサークル前を通ります。

しかし実際には、青矢印の部分が開けていたため、我々のサークル前を通らずに出口へ向かえるようになっていました。

なので、我々のサークルを見ないで帰ってしまう人が多かったことが分かります。

それと同時に、やはりあの動線では、2F→3Fへの移動待機列には気付くことすらできなかったのではないかと考えられます。

おわりに

今回は運営も混乱し、一般参加者も目の前を通らないという条件の中、個人誌は無事に頒布終了になりました。

次回はまた改善された技術書典になることを期待しておりますし、そこでまた頒布できるように頑張りたいと思います!

*1:ただ、この2人組が購入した瞬間、私は残念ながら離席していたので、売り子をしていた人に後から聞いた話ですが…。

7payの会見から学ぶソフトウェアテストの7原則

目次

はじめに

話題になっている7payの話を、ソフトウェアテストの知見(ソフトウェアテストの7原則)を使って、反面教師として次に活かせる形にして書いてみます。

ただし、「これを知れば事前に防げる!」と主張したいのではなく、(エンジニアも経営層も)意識して臨まないといけないという意味も込めて書きます。

この記事の元ネタ

教訓の元にした7pay会見の記事はこちら

www.itmedia.co.jp

ソフトウェアテストの7原則の説明はこちら(昨年に改定された版を引用しています)

【リンク】ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018.J02

教訓1:「脆弱性はなかった」という発言


セブン&アイ清水健執行役員は「あらゆるサービスについて、事前にセキュリティ審査をやっている。7payもきちんと確認したが、脆弱性(ぜいじゃくせい)はなかった」と繰り返し強調した。

この部分から活かせる教訓は2つ。

ソフトウェアテストの7原則の1.テストは欠陥があることは示せるが、欠陥がないことは示せない

テストによって導き出せるのは、欠陥があることのみです。悪魔の証明ってやつですね。

上記の発言が「(セキュリティ審査の中では)脆弱性がなかった」という報告であれば良いです(結果としては良くないけど)。

ただし、「セキュリティ審査はやった。だから脆弱性はない」という主張であれば、明確に「テストは『欠陥があること』しか示せない」という原則を理解していないことが分かります。

ソフトウェアテストの7原則の7.「バグゼロ」の落とし穴

「バグがない=素晴らしいとは限らない」ということです。

特に今回のように、「セキュリティ審査では1件も問題が出なかった」という報告は(特に経営陣は)安心材料になったのかもしれないです。

ただし、そこには落とし穴があり得るという理解が必要です。

教訓2:仕様・設計の段階での指摘


そもそも「明らかに問題がありそうな仕様・設計」について、現場担当者レベルで誰も気付かなかったのかという疑問は残る。

この部分から活かせる教訓はこれ。

ソフトウェアテストの7原則の3.早期テストで時間とコストを節約

テストに関しては初期部分から入ることが重要です。

今回の場合は仕様策定や設計段階で気づくべき内容を、リリース後まで放置していたためにこれだけ大ごとになってしまっています。

仕様レビューの段階で「これってどうなの?」という話し合いがあれば、きっと小1時間で修正できたでしょう。*1

(「現場は修正したかったが、政治的なことがあって…」とかは邪推できますが、一旦その話は置いときます)

教訓3:決済系のサービスに対するテスト


今回の大規模な不正アクセス被害で多くの利用者の信頼を失ったのも事実だろう。「スマートフォン決済全体の信頼を損なう出来事ではないか」と指摘されると、小林社長は「(今回の件は)残念な事象。スマートフォン決済は安心、安全、便利と思ってもらえるよう、早急に立て直したい」と答えた。

この部分から活かせる教訓はこれ。

ソフトウェアテストの7原則の6.テストは状況次第

全ての製品・サービスにおいて同じテストを当てはめれば良いのではなく、状況によって変わっていきます。

生命を扱う製品・機能と、使いやすさを追求するだけの製品・機能では、テストの工数や方法なども変わっていきます。

今回の場合は決済というお金を扱う部分が含まれているにも関わらず、テストがきちんと行われていなかったように思われます。

セブンイレブンの場合、2007年に「お取り寄せ便」というサービスを開始しています。(現在のサービス名は「セブンミール」)

7-11net.omni7.jp

しかし当時のクレジットカード決済はそこまで使われていたとは思いにくく*2、お金を取り扱っているという意識は少なかった(商品をお届けするためのサービスという位置づけだった)のではないでしょうか?

そういう状況であれば、乗っ取りが発生しても各ユーザーに甚大な被害は起きなかった可能性が高いです。(いや、個人情報とかがあれば、それはそれで問題だけど)

決済というお金を扱う部分も含めていることで、もっとその部分に関して重点的に考えるべきではなかったかと思います。*3

おわりに

今回は7payの会見を元に、ソフトウェアテストの7原則に当てはめて書いてみました。

とはいえ今回の記事は、こうやって事象が起きた後ならば、いくらでも書ける内容であることは確かです。

「はじめに」でも書きましたが、あくまでも今回の事象を教訓に自分の製品でもあてはめて考えてみたいです。

そして、実際に開発・テストをするのは現場とはいえ、経営層も含めてソフトウェアテストの7原則を意識すべきだと思います。

【リンク】ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018.J02

*1:えっ?なんでレビューの話をしてるの?と思われる方もいるかもしれませんが、ISTQBのシラバスでは静的テスト活動の1つとしてレビューが書いてあります。

*2:経済産業省の資料によると、2008年当時クレジットカードの支払額は全支出の12%程度でした。また、支払額での比率のため、セブンイレブンの利用者層はもっとクレジットカード利用率が低かったのではないかと思います。

*3:そもそもオムニ7の時点で…という意見はまさにその通りだと思いますが、先述の「セブンミール」から開発が続いていた場合、お金を扱う意識がそこまで無いまま作っていった可能性があります。あくまで推測ですが。

JJUG CCC 2019 Springで色々な工夫を凝らしつつ、テストについて発表してきました! #jjug_ccc #ccc_e4

5月18日に開催された「JJUG CCC 2019 Spring」で「テストエンジニアが教える JUnitを書き始める前に考えるべきテスト」というタイトルで発表してきました!

www.java-users.jp

発表をするにあたり考えていたことや工夫したことを記事にしておきます。

目次

発表資料

speakerdeck.com

テストエンジニアなのにJJUGに発表しようと思ったきっかけ

主に以下の2点。

  • PHPカンファレンス福岡でQAの知り合いであるリナさんがほぼ毎年登壇しており、「QAでも言語系カンファレンスに登壇してもいいんだー」と思ったから underscore42rina.hatenablog.com

  • XP祭りの運営もされている山口さんが、「アジャイル系のイベントにテストエンジニアが参加してくれて嬉しい」と言っていたので、テスト系以外のイベントでも受け入れられるんだーと思ったから

発表前

CfPが採択されたものの、まさかの一番大きな会場に割り当てられました…!

事前アンケートで「聞きたい!」と言ってくれた方が多くいらっしゃった結果なので、嬉しさ半分、しっかりとしたものを発表しなきゃという想いが半分でした。

めっちゃ緊張してました…w

なにせテスト系のイベントではなく開発系のイベントなので、聴講者はどんな雰囲気・目的で聞きに来ているのか分からなかったからです。

また、「本当にこんなコンテンツを聞きに来てくれるのだろうか…?」と思ってましたが、結局、私の発表は280名の満席に近いセッションとなりました。圧倒的感謝…!

発表時の仕掛け

おそらく聴講者の皆さんが普段聞き慣れていないであろう「テストの話」を、ただ発表するだけではつまらないだろうと思い、2つの仕掛けをしました。

仕掛け1. menti.comでたくさんの回答を貰うための仕掛け

今回の発表では menti.comを利用し、聴講者の皆さんとインタラクティブな発表を目指しました。

www.menti.com

より効果的かつ盛り上がるコンテンツにするためには、何よりもできるだけ多くの聴講者にこのサービスを利用してもらう必要があります。

そのために色々な工夫をしました。

工夫その1. 講演前、講演中にサイトへの誘導を行う

上記のようなツイートを行い、また講演開始前に会場でもアナウンスを行いました。

そして講演が始まってからも、私の自己紹介のスライドの一番上に常にサイトへのアクセス方法を書いておくようにしました。

工夫その2. 最初は簡単な操作を要求することで入りやすい状況を作る

今回、menti.comでは3つのコンテンツを用意しました。

  • コンテンツ1. ハートをクリックする
  • コンテンツ2. 二者択一のアンケートに答える
  • コンテンツ3. 自由記述のアンケートに答える

いきなり自由記述のアンケートに答えるのは難易度が高いです。

そこでまずは「ハートをクリックする」という単純な操作を体験してもらうことで、「自分が手元で操作した行動が、こうやって投影している部分に反映されるのか」と体験してもらいました。

次に「二者択一のアンケートに答える」ことで、「アンケートに答えると投影している部分に反映される=アンケートに答えると何かしらのリアクションが返ってくるんだ」と体験してもらいました。

こうすると「自由記述のアンケートに答える」ときには、参加者の多くが答えやすい状況になっています。

工夫その3. その場で変化の実況を行う

工夫2で書いた「何かしらのリアクションが返ってくるんだ」を増幅させるために、あえて大げさにリアクションをしました。

例えば、以下のように言ってました。

  • 「ああっ!どんどんハートが増えてくる!100名を超える皆さんに参加してもらえてますね!ありがとうございます!」(コンテンツ1の時)
  • 「おっ!圧倒的に開発者の方が多く、テストエンジニアが今回の参加者の5%ぐらいしかいない!つまり私はアウェーの中で発表しているということですね」(コンテンツ2の時)
  • 「おおー!色々書いていますね!『品質保証』なるほどー!『バグを見つけるため』そうですよねー!」(コンテンツ3の時)
結果

実に多くの方にmenti.comを利用していただきました!

それぞれのコンテンツ結果は以下のようになりました。

自由記述の時(コンテンツ3)でも、216名の方に回答いただけており、離脱率が少ない状態を保たれていることが分かります。

f:id:nihonbuson:20190520004655j:plain
二者択一の結果

f:id:nihonbuson:20190520004732j:plain
自由記述の結果

また、menti.comを使うことで、聴講者の皆さんがどんな心持ちで聞きに来たのか把握することができました。

こんなことも一発で聴講者にも分かってもらえますw

仕掛け2. ペアワークで活発な意見を出してもらうための仕掛け

今回はmenti.comの利用だけでなく、講演中にペアワークを入れてみました。

今までもペアワークを取り入れた講演をしたことはあったのですが、以下の2つの条件により、今までのペアワークの講演の中で最難関でした。

  • 参加者数が300名弱と、過去最多
  • 講演時間が45分間しかない

そのため、これに対してもいくつか工夫をしました。

工夫その1. 講演前に隣の人と自己紹介をしてもらう

隣の人がどんな人か全く知らない状態でペアワークを始めても、きっと会話が弾まないでしょう。

そこで、講演開始前に会場でアナウンスを行い、隣の人と自己紹介をしてもらいました。

特に、Javaは様々な現場で使われていることが多い言語ですので、普段の業務は何をやっているのかについても話してもらうことにしました。

工夫その2. 自己紹介しやすい空気を作る

いきなり「普段の業務について話せ」と言われてもなかなか話しづらい人もいるかもしれません。

そこで自己紹介しやすい空気を作るために、「自分の名前と一緒に普段の業務についても話してみてください。あっ、ただ例えば『実はCIAのスパイなんだ』みたいな言えない事情は言わなくて大丈夫ですよー」と言ってみました。

そうすることで、「あんな変なことを言ってもいいんだ」と、自己紹介に変なプレッシャーを感じなくする効果があると思ってます。

結果

結果として、ペアワークに価値を感じてくれた方が何名かいらっしゃったようです。

発表後

menti.comの利用、そしてペアワークの実施など、様々な仕掛けを45分間でしてみました。

結果として、このセッションやテストに対してポジティブな感情を抱いてくれたようです。

もしもテストに興味を持った方がいましたら、ぜひWACATEにも参加してくださいね!

wacate.jp

また、明日はWACATEの体験版となる勉強会も開催予定ですので、気になる方はぜひ!

wacate.connpass.com

おわりに

最初は「言語系カンファレンスにテストの話を発表するのはいいのかな…?」と不安でしたが、色々な仕掛けをすることで、概ね良い結果になったと思います。

ただしこのような結果になったのは、wi-fiを設置してmenti.comに繋ぎやすい環境だったり、講演開始前にもかかわらず色々なアナウンスを快く受け入れてくださったJJUGのスタッフの皆さんのおかげだと思っています。本当にありがとうございました!

今回言語系カンファレンスでの発表は初めてでしたが、他の言語系カンファレンスでも発表していきたいと思います!

また、今回は45分という短い時間だったので一部しか話せませんでしたが、「もっと聞きたい!」という方は、お気軽にご相談ください。twitterのDMでOKです!

個別・会社内・勉強会問わず相談に乗りたいなと思ってます。お待ちしております!