前回のJaSST Reviewってどんな感じだったのか紹介(発表内容編) #JaSSTReview

はじめに

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

今回のJaSST Reviewの狙い

前回の記事に書いたとおり、一言に「レビュー」といっても、皆さんが思い描くレビューは十人十色です。そのため「レビュー」の取り組み方はバラバラな現状があります。

そこでJaSST Reviewでは、分野が異なる以下のお三方を、発表者としてお招きしています。

JaSST Review'18は下記の3名に発表をお願いしました。

さらに、このお三方をパネラーとして、パネルディスカッションも行いました。「レビュー」という共通の単語に対して、どのように捉え⽅・普段の取り組み⽅が違うのか、もしくは同じなのかを感じる内容を⽬指しました。

また、「レビューミーティング(以下、レビューMTG)の運営方法」「プロセスの中におけるレビューの設置方法」などといった管理面の話は極力対象外にしました。一方で、「どのような思考をもってレビューに取り組んでいるのか」「レビューの指摘内容はどのようなものか」といった技術面の話を中心に発表をお願いしました。

当日の内容

前回の記事で、どのような狙いをもって準備をしたか書きましたが、当日は狙い以上のお話を伺うことができました。

それぞれの発表でもともと依頼していたこと、期待していたこと、実際の発表で得られた予想外のお話を紹介していきます。

なお、本記事を読む際にはJaSST Review レポートページも参考にしてください。

www.jasst.jp

日立製作所 白水様

依頼内容

リリースまでの期間が長い、重厚な開発プロセスでのレビューについてお聞きしたいと思い、白水様に講演を依頼しました。品質を重要視されている日立製作所さんならではの取り組みや思考が聞けると期待しました。

予想していた発表内容

上流の品質を確保するようなレビューをより重視しているのではと予想しました。

リリースまでの期間が長い場合、テストなどの実装後工程で不具合が散見されてしまうと修正コストが非常に高くなります。 高くなるコストを防ぐ一つの方法として、レビューがあると考えました。

実際の発表内容

発表資料は下記です。

設計作業が全体の作業の約5割を占めているというデータから、レビューを重要視されていました。特に大切にしていたことは、各工程でのレビューを繰り返し実施し、工程間(例:機能設計書と詳細設計書)のズレが発生していないか確認することです。 さらに工程以外にも、レビューの位置づけとして「書いてない事を見つける」という考えを持っていました。これは、社外発生不具合の86%は仕様書に記載が無かったというデータから、書いてない内容を見つける目的を重要視していました。

設計レビュー時に気を付けていることについての紹介もありました。 まず、レビュアーが自ら気付くようになるために、「俯瞰する」「先見する」「想像する」の3つを大切にしていました。

  • 俯瞰する…対象機能だけでなく連携する機能についても考える
  • 先見する…その機能が動いた瞬間だけでなく使い続けた将来はどうなるのか考える
  • 想像する…レビューイが想定していなかった使い方をした場合にはどうなるのか考える

レビューイだと対象物のみについて考える狭い思考になりがちです。ここで挙げた3つは、どれもレビューイとは違う視点を持つためのポイントでした。

これらの話は、レビューを大切にしていると予想して講演依頼した私にとって、しっかりとデータや文章にして表現してくださったので非常に参考になりました。

楽天株式会社 及部様

依頼内容

Agile開発でのレビューについてお聞きしたいと思い、及部様に講演を依頼しました。最近盛り上がりを見せている、「モブワークでどのようにレビューが行われているか」を特に聞きたいと期待していました。

予想していた発表内容

「レビュープロセス」が存在しないモブワークで、実はレビューと同じような会話をしているのではと予想しました。

また、純粋に指摘についての話が聞けるのではないかと予想しました。レビューの発表といった時には、よくMTGの参加者構成など、どのようにしてレビューMTGを開催するのかという話になりがちです。ただし、モブワークの場合はレビューMTGが存在しないため、レビューMTGの形式について議論する余地がないと考えました。

実際の発表内容

発表資料は下記です。

speakerdeck.com

レビューMTGだと「設計上は良くないけど、忙しいだろうし、動くから今はとりあえずこのままでいいか」「今回は指摘が多いから、これ以上の指摘はやめよう」といった忖度が発生するというお話がありました。 逆にこのような忖度が発生しないようなレビューになれば、価値のあるものになると感じました。

また、「モブワークはチーム全体の活動である」という話も印象的でした。チーム全員で立ち向かってダメなら仕方ないという考え方です。また、暗黙知を無理に形式知化させるのではなく、暗黙知暗黙知のまま共通体験で伝えるようにしていました。これもモブワークがチーム全体の活動だからこそできることかなと感じました。

一方で、モブワークの中でもレビューが必要になってきた、という話は予想外でした。 必要となったレビューは設計レビューのようなものではなく、自分たちの仕事の成果を自分たちで見直すためのレビューでした。 その中で、レビューという言葉を改めて考えるという話がありました。レビューは「Review」というスペルです。つまり「Re(再び)view(見る)」からレビューなのです。一方で、普段行っているレビューは「Re view」ではなく「First view(初めて見る)」になっているのではないか、という発表でした。この発表は、レビュアーはレビュー時点で初めて対象物を見ることが当然だった自分にとって、シンポジウムの中で一番の衝撃でした。

グロース・アーキテクチャ&チームス株式会社 鈴木様

依頼内容

アーキテクト観点でのレビューについてお聞きしたいと思い、鈴木様に講演を依頼しました。特にAgile開発では、コード中心のレビューになることが多いと想像しており、もっと基盤寄りのアーキテクチャの話を聞く機会が重要だと考えました。

予想していた発表内容

アーキテクチャは開発をする上での最上流工程だと考えていました。なので、そのようなまだ開発方針も定まりきっていない状態での物事の決め方が聞けるのではないかと予想しました。

実際の発表内容

発表資料は下記です。*1

www.slideshare.net

アーキテクチャの良さは非機能で判断する必要がある、というお話がありました。非機能要件は「こうあるべき」という絶対的なものがありません。それを見るためには、工程完了の確認のためではなく、相談に乗る形でレビューに参加することが多いようです。 また、バランスが取れた判断も考えていました。アーキテクチャ設計が100点満点になることはありえません。そこで、松竹梅の複数プランを示して、落とし所を決めることを重要視していました。

アーキテクチャ設計レビューの難しさも話していただきました。 アーキテクチャ設計は常に事前的であるため、将来性が考慮されているかも重要です。その将来性を考えた上で、どのようなリスクがあるか、そのときにどのようにしてリスクを回避するかを考えていました。 その中で、「◯◯については今は考えない」といった情報も記録に残すように心がけていました。記録に残さないと、「意図的にその時点では考えなかった」「そもそも考慮していなかった」のどちらなのか、将来的に分からなくなるからです。

今回はアーキテクチャのレビューについて話してもらいました。ただし、最上流工程だからこそ難しさが顕著になっているだけで、話していただいた内容はすべてのレビューに当てはまる考え方のように感じました。

おわりに

本記事ではJaSST Review'18での発表内容について紹介しました。

JaSST Review'18の様子を読んで、「面白そう」と感じた方は、11/1開催のJaSST Review'19にもぜひ参加してみてください!

違った方向で新たなレビューに対する考え方を得ることができるはずです。

jasst.jp

*1:発表から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つに分けられます。

f:id:nihonbuson:20191024013937p:plain
レビュー対象物

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

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

f:id:nihonbuson:20191024014420p:plain
レビューを行うタイミング

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

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

f:id:nihonbuson:20191024014449p:plain
リーディング技法

レビューの開催形式

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

f:id:nihonbuson:20191024014212p:plain
レビューの開催形式

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

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

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

おわりに

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

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

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

www.jasst.jp

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

「相談」もレビューである #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人組が購入した瞬間、私は残念ながら離席していたので、売り子をしていた人に後から聞いた話ですが…。