第1回JaSST Reviewってどんな感じだったのか紹介（開催の経緯編） #JaSSTReview

目次

はじめに

2018年12月8日に、ソフトウェアレビューのシンポジウムである「JaSST Review」が東京で初開催されました。本記事はJaSST Reviewをどのような想いで開催したのか、どのような発表や議論がされたのかを紹介します。

JaSSTとは

日本では2003年からソフトウェアテストシンポジウム（JaSST）が全国各地で開催されています。これまでの15年間で約90回開催されてきました。 様々な方がテストに関する知見を社外に発表していることから、業務でのテストの経験が言語化されてきました。結果として、テスト技術として整理もされてきたと感じています。

なぜJaSSTでレビューを取り扱うのか

前述の通り、JaSSTはソフトウェアテストを扱っているシンポジウムです。そんなJaSSTでなぜレビューを取り扱うのでしょうか。

実は、JSTQB（ソフトウェアテスト技術者資格認定）には、「静的技法でテストできる方法の一つ」として、レビューが紹介されています。 つまり、テスト計画、テスト設計、テスト自動化などがJaSSTで扱っているのと同様に、レビューもまたJaSSTで扱うべき分野の一つだと考えています。

なぜJaSST Reviewを開催したのか

JaSSTは全国で開催されており、東京では毎年二日間にわたってJaSST Tokyoが開催されています。 そんななか、JaSST Tokyoとは別枠でJaSST Reviewを開催しました。これには理由があります。

過去3年間（2016年-2018年）における全国のJaSSTでは、合計で約240セッションが実施されました。 その中でレビューを題材としたセッションは6セッション（全体の約2.5%）のみでした。*1 これはとても少ない数字ですよね？

つまり他のテスト技術に比べ、レビューに関してはあまり広がりを見せていないという現状が分かります。 そうした状況を打破するためにも、レビューについて真剣に考える機会を作るためにJaSST Reviewというシンポジウムを新たに立ち上げました。

レビューの分類

一言に「レビュー」といっても、様々な分類を行うことができます。

JaSST Reviewの発表内容をお伝えする前に、レビューの種類にはどのようなものがあるか紹介します。 そして、読者の皆さんはどこに位置づけられるのか、他の組織ではレビューがどのように使われているのか知っていだければ幸いです。

レビューの対象物

レビューの対象物も組織によって様々です。対象物によって、レビューは大きく以下の3つに分けられます。

レビュー対象物

レビューを行うタイミング

レビューをどのようなタイミングで行うかについても組織によって違います。大きく以下の3つに分けられます。

レビューを行うタイミング

レビューで用いるリーディング技法

ドキュメントなどをレビューで読むときに用いる技法も様々あります。例えば、以下のようなリーディング技法があります。

リーディング技法

レビューの開催形式

開催形式については、公式的なものと非公式なものに大きく分かれ、その中でもいくつか方法があります。

レビューの開催形式

「レビュー」に対する考えは十人十色

ここまで書いたように、一言で「レビュー」と言っても、その言葉からの捉え方は十人十色であることが分かります。

そこで、色々な分野の方のお話を聞くことで、「レビュー」に対する考え方を広げてもらいたいと考えています。

おわりに

本記事では、JaSST Review開催の経緯について書きました。

この経緯は、11/1開催のJaSST Review'19でも同様の考えを持っています。

もしも、この考えに共感を持ってもらえる方がいましたら、ぜひJaSST Review'19にも参加してみてはいかがでしょうか？

www.jasst.jp

*1:そのうち5セッションは、JaSST Review実行委員の2人による発表でした。

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

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

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

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

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

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

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

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

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

「「超」やさしいレビュー ～開発と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さんの講演を聞きに来てください！

*1:JaSSTソフトウェアテストシンポジウム-JaSST Review'19-タイムテーブル より

*2:miwa719.hatenablog.com

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に赤坂であさこさんの講演を聞きにきてください！

*1:JaSSTソフトウェアテストシンポジウム-JaSST Review'19-タイムテーブル より

*2:JaSSTソフトウェアテストシンポジウム-JaSST Review'18-レポート より

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

はじめに

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

www.jasst.jp

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

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

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

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

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

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

見どころ

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

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

Wordでよく見る赤波線

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

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

おわりに

JaSST Review'19はまだまだ申し込み受付中です！（直球な宣伝）

www.jasst.jp

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

*1:JaSSTソフトウェアテストシンポジウム-JaSST Review'19-タイムテーブル より

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

目次

はじめに

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

techbookfest.org

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

頒布物

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

合同誌

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

300 Multiple Choices

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

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

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

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

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

個人誌

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

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

事例で学ぶ ソフトウェアテストと品質

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

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

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

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

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

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

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

我々のサークルの位置

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

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

サークルの位置

待機列の状況

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