JaSST Review'20聴講した
JaSST Reviewはソフトウェアテストに関するシンポジウムの中でも
レビューに特化したシンポジウム。今年はオンラインで開催でした。
…個人のメモなので抜け・間違いがあります。
各セッションの概要と感想
セッション 0：はじめに
- 概要
JaSST Reviewの開催経緯。
何故テストを扱うシンポジウムでレビューなのか？
JSTQBではレビューは静的技法（テストできる技法の一つ）として位置づけられている。
今回は前回の成果を引き継ぎつつ、より「レビュー対象にどのようにアプローチしていくか」がテーマ
アプローチ：準備で考えたり、実施中にも考える。終了後も考える
レビューでのアプローチとは？
・準備で考える
レビュータイプの決定
リーディング技法の選定
etc..
・実施中にも考えを変える
（ここの事例があまり出てこないのでこの部分について聞きたい）
・終了後も考える
レビューメトリクスの測定
etc...
事例投稿も募集。募集した目的は「様々な方の普段のアプローチを聞きたい」
- 感想
導入で、大まかなテーマの説明があるのが良いです。
映画を楽しむパンフレットがあるかのような感じ。
（予稿集もですが）
セッション 1：講演1「専門書が出版されるまでの編集者の思考と行動～編集者はどのように校正・校閲しているか～」
- 概要
日科技連の鈴木様による講演。
本を作る際、著者の意図を読者が読み間違えず、理解しやすい本を作るため
編集者がどのようなことに気を付けて著者に意図を伝えているか。
また、校正や校閲で何に注意を払っているか。
- 感想
参考になり過ぎたの嵐（語彙消失）
このセッションは2種類の見方があります。
1.編集者（≒レビューア）が著者（≒レビューイ）に意図を伝える際に、どのようなことに気を付けて
伝えたいことを伝えるか
2.文章の校正のコツ
1はとにかく「相手に伝わること」が最優先。
そのために相手を立てる言い回しをする。
相手に意図を伝えるための土台を作る（例えば、苦言を和らげるために評価できるところを褒めたりとか）
目的は「著者の意図が伝わる理解しやすい本を作ること」で
そのためには「意図のやりとり」が必要で、そのための土台を作っていく。そんな話でした。
私のようなテスターが開発の方に意図を伝えるときも全く同じだと思います。
そしてそのためには相手の意図をよく読みこむ、
お話の内容のすべてから著者を大切にされている感じが伝わってきました。
2はガチのブラッシュアップ内容でした。
この校正も何もない文を書いているのがお恥ずかしい限り。
>>『しかし』の後には著者の主張が述べられることが多い
間違いないです。
鈴木様は文を理解しやすくする読者的視線で校正を紹介していましたが
自分も文を書くときには今回の予稿集を引っ張り出してペルソナ読者になって校正します。
そして本を買おうー！
セッション 3：事例紹介1「刺激語カードを用いたソフトウェアレビューの実践について～アイデアを刺激し意識外から観点を得る」
- 概要
エムスリーの中塚様による事例紹介。
開発にスピード感が求められる状況において
従来の観点（マインドマップやチェックリスト）で拾えない想定外の箇所に
「手間をかけず」「すぐ実施できて」「色々なプロダクトのQAに使える」
レビューの方法として「刺激語法」を使用したお話。
- 感想
一見ソフトウェアと関係なさそうな言葉から連想に連想を重ねて観点を導き出す
というのは斬新だと思いました。
反面、この方法を使用するには「レビューアがテストないし機能について知見をもっている」ことが重要に見えました。
「刺激語」＋「連想力」＋「今までの知識」をもってして観点を広げる方法。
仕様とにらめっこしていると思考が狭まりがちなので、思考のタガをはずしたほうが良いときに使ってみたいです。
連想中は連想に集中するためにレコーダーを用意するというのも面白いです。
人は複数のことを考えると脳が混乱することをうまく理解しているように思えます。
セッション4：事例紹介2「レビューイの力を引き出すフィードバックのチューニング～チーム外からの支援で見えてきた、成熟度に応じた「問いかけ」の調整方法と各種レビューへの適用可能性」
- 概要
グロース・アーキテクチャ＆チームスの常盤様による事例紹介。
レビューする側（レビューア）が「指摘事項が思ったように反映されていない」
レビューを受ける側（レビューイ）が「言われた通りに直したのに違うと指摘される」
どちらも目的はレビュー対象が良くなることなのに報われない、こんな状況を抜け出すための話を
スクラムチームのふるまいに例えて紹介するお話。
どちらかというとレビューア視点だったと思います。
- 感想
一方的に「伝える」だけだと納得感も低く伝えたまましかやらなくなってしまう。
レビューされる側（外から支援されるスクラムチームのメンバー）にの成熟度に合わせて
段階的に自分で考えていってもらえるようにしていく。このアプローチは人を育てる上でめっちゃ良いと思います。
レビューする側であるとき、レビューされる側を自分の意のままにすることが目的ではないですよね。
レビューされる側が自分の意図で考えるはしごをかけているようなイメージ。
成熟度を見ながらという所も良いです。
あまりにも何もわからない状態で「どうすればいいか」と問いかけられても
多分突き放したり責めているような印象を与えそうなので、一辺倒ではなく
相手の成熟度に寄り添ってアプローチを変えていくのが重要だな、それを再認識するセッションでした。
セッション6：講演2「ソフトウェア設計における意思決定とそのレビューの秘訣」
- 概要
ウルフチーフの川島様による講演。
アーキテクチャは設計に関する重要な意思決定。後戻りをするのが難しい。
決定の背景を知らずに既存の仕組みを変えてしまったり、過去の意思決定した状況と
大きく変わってしまっているのに見直しがされない、このような事態を防ぐために
アーキテクチャの意思決定を明確にしておくフォーマット、ADRがある。
アーキテクチャのレビュー（制約上において考えられているか、公平か、代替案が検討されてるか）が
どのように行われているかを事例を交えて紹介。
- 感想
最初かなり難しい内容だな…と思ったのですが、事例を交えたうえでの解説が多く後半になるにつれ
分かりやすくなるという奇跡のセッションでした。
言ってみれば前半が抽象で後半が具体だったかもです。
全体として言われていたのは「抽象と具体の行き来」。
文に書くのが難しいのですが、、詳しすぎるところでがんじがらめになっているときはいったん抽象度をあげて
代替案を考えてみたりとか、代替案の案ごとの差が分からないときはその代替案の評価軸を変えたて検討したりとか
とにかく「詳しさ」と「視点」をコントロールして考えよう、と言っているように思えました（違ったらすみません）
印象に残ったのは
「抽象度の低いほうから高いほうは見えない」
「レビューイの立場からすると、そもそも～の話をされるのはつらい」
見ている視点を他人にぎゅーっと強制的に上げられるのはつらいということと思いました。
まずなんで抽象化するかの合意が必要と。
最初の鈴木様のセッションの「著者を大切にする」を、また別のアプローチで実施しているように見えました。
セッション7：「パネルディスカッション」
- 概要
slidoの疑問にパネリストの皆様で回答。
印象に残っている質問
・良いレビュアーになるには
・人類はなぜレビューを後回しにするのか
・誤字にばかり目が行く場合はどうすれば
- 感想
人類はなぜレビューを後回しにするのか、めっちゃ笑いました。
後回しにするがあるあるなんだなーと。
質問内容を見ていると自分以外の人々もまた泥臭くレビューをやっているなあというのが
感じ取れて、がんばろーという気持ちになれます。
最後にブロッコリーさんが拾ってくれた質問（レビュアー忙しい問題）は自分なのですが
読み上げられたときに初めて「あっ今回のJaSST Reviewってレビューア側の話中心で
レビューイ側の話ではなかったな」と思いました。（パネリストの人々がどの視点の話か悩む中
すごい迅速に「見てほしいポイントを伝える」と回答くださったブロッコリーさんに感謝）
終わりに
良いレビューは相手との関係性、そして幅広い視点を持つこと、それを伝える力を持つこと
→レビューはコミュニケーションの総合格闘技みたいだなあ
という感想。
しかし今回ほんとに内容が濃かった。聞いてよかったです。
この校正していない文を公開するのはお恥ずかしいですが、とりあえず今日の聞いてよかった感を貯金するために
公開しておきます。
良いお話をありがとうございました！
