はじめに
JaSST Review'20 (JaSSTソフトウェアテストシンポジウム-JaSST Review'20)
S7) パネルディスカッション
パネリスト
鈴木 兄宏（日科技連出版社）
川島 義隆（ウルフチーフ）
風間 裕也（ビズリーチ）
の聴講メモです。
Twitterのつぶやきがtogetterでまとめられています。併せてご参照ください。
ソフトウェアレビューシンポジウム2020 #JaSSTReview - Togetter
聴講メモ
Q.
レビューを実施する上で最も大切にしていることは？
A.
自分の役割を考えてレビューする。編集者はあくまでも手助け。コメントを受け付けてくれるかは二の次。そのコメントを受けて考えてくれることを重視している。（鈴木）
心理的安全性の確保。抽象度や目線の違いにより、感情のぶつかり合いに発展しがち。感情ではなく仕組みで動かす。（川島）
鈴木さんのやり方はレビュイーに寄った立場で動いており、心理的安全性を保っているように見えた。（風間）
著者がへそを曲げたらおしまい。（鈴木）
発言する前にはTwitterで様子見。記事にした時の反応を見ている。（川島）
仕組みはあまり考えたことがない。著者と編集者は1対1なので、馬が合わないときは仕方ない。部下との間であれば対応の仕方は考える。（鈴木）
Q.
レビューがうまくいく／うまくいかない主な要因は何でしょうか？その引き寄せ方・打開方法は？何をもってレビューの良し悪しを評価する？
A.
誉田先生の事例のように「自分の考えていたことがわかってよかった」というコメントはレビューがうまくいった証といえるのでは。（鈴木）
コンテキストのブレがバチッと決まったときに達成感を感じる。成果物が2,3割程度の段階での方向性のすり合わせに力を入れている。（川島）
作成者がコンテキストを説明してくれて、レビュアーがコンテキストを理解したうえでレビューを実施できた時はよかった。（風間）
欠陥を見つけるのがレビューの良し悪しの指標の1つではあるが、コストや性能のバランスを考えたうえで調整できたかどうかを判断できたかも重視している。（川島）
完成したものを持ってきても直したくない。なので、2,3割の段階で持ってきてもらって方向性を決めることを重視している。（川島）
コメントをなかなか受け付けてくれない著者でも、力量を一度認めてくれると、それ以降は態度が変わることもある。逆に言うと、そういうきっかけが無いとレビュアーとレビュイーの関係を変えるのは難しいかも。（鈴木）
Q.
レビュー対象の問題や改善点を見つけにいく際の着眼点・嗅ぎつけ方・情報の引き出し方など、実践している工夫を教えてください。
A.
過去の事例集めによって嗅覚が養われた。（鈴木）
Q.
よいレビューアになるために「これだけはやっておけ！」というものがあれば教えてください。
A.
私の話した内容を反芻していただければ…！視座はポジションにもよるので難しいが、スキルや経験を身に着けることは日々の鍛錬でできる。（川島）
ソフトウェア開発者は抽象化する能力が高いと感じるし、レビュアーとしても抽象化する能力は大切になる。抽象化と具体化のいったりきたりする能力が大事なのでは。（鈴木）
ソフトウェア技術者には抽象化する能力が大事。これがソフトウェア設計そのものであり、これができないとコードは書けない。「具体と抽象 ―世界が変わって見える知性のしくみ」という本を勧めている。（川島）
本を読んだときにその本の内容紹介を200文字でまとめてみるとよいかも。編集者は年中それをやっている。（鈴木）
Twitterは140文字で誤解されず正しく考えを伝えるための訓練といえるかもしれない。（川島）
Q.
人類はどうしてレビューを後回しにしてしまうのでしょうか？
A.
成果物が完成してからレビューするというプロセスになっていること。また、形になっていない状態で自分の考えを正しく話すというのはスキルが必要だし、気恥ずかしさもあるからでは。（川島）
Q.
自分を含めレビューアが複数いて、自分が上位者に当たる時、下位者のレビューアの発言が少なくなりがちです（上位者が発言するので当事者意識が薄くなりがち）。レビューの質を下げずに下位者のレビューアとしての成長を促すポイントはありますか？
A.
複数人で担当する時、普段は発言しないようにしている。上位者が発言すると下位者が発言しなくなるため。だが、ギリギリのタイミングでは指摘をする。（鈴木）
黙っていることも多いが、必ずしもそれが良かったとは思わない。議論の最後でちゃぶ台返しをしてしまうと、それ以降に委縮して話してくれなくなる。（川島）
会議に参加するとしゃべりたくなってしまうので、あえて出ないこともある。（鈴木）
自分の考えと周囲が完全に一致することは無い。その人にあったやり方を見つけてほしい。その間の失敗は上位者としてカバーする。（鈴木）
Q.
レビューは、成果物に対する欠陥を見つける作業になるため、レビューイからするとどうしてもネガティブに捉えられてしまうことがあるかと思います。ポジティブな雰囲気でレビューを実施するための工夫などがありましたら、共有いただきたいです。
A.
誉めるところを探す。何かしらはある。仕事柄あら捜しの面はあるが、それだと著者のやる気をそいでしまうため、気持ちが上がるような言葉の声がけを心がけている。（鈴木）
レビューで欠陥だけでなく良い点もコメントする。良いことから言って、そのあとに悪い点を指摘する。（川島）
欠陥をがんばって見つけるというよりは、ここが分からないのだけど、のように説明をお願いすると、説明の途中に作成者が気づくかもしれない。そうすると場も和らぐかもしれない。（風間）
Q.
どうしても誤字脱字に目が行ってしまい、肝心の内容が入ってきません。本質的な内容へ集中するためにどうしたらよいでしょうか。
A.
私も同じです！誤字脱字が多いと疲れる…。誤字脱字を一度指摘して直してもらってから見直している。誤字脱字に目がいってしまうのは仕方がないのでは。誤字脱字を見抜ける才能があると前向きにとらえてはどうか。（鈴木）
レビューで誤字脱字ばかり指摘している人もいる。集合レビューでは誤字脱字を指摘せず、後でまとめて指摘するようにしている。プログラマーは誤字脱字率が高い気がするので、気にならなくなってきた…。（川島）
誤字脱字の指摘は後で渡すとか、事前にレビューしておくというのはありかも。私も集合の場では言わないかも。（風間）
紙で見ると誤字脱字が見つかりやすい。データ（画面）で見ることで流れに集中しやすくなるかもしれない。（鈴木）
Q.
レビュー観点としてオープンになっており、かつ役立つものは何かありますか？
A.
ソースコードレビューなどはあるかもしれないが、設計レビューだと多岐にわたるので難しいかも。（川島）
チェックリストを使うような読み方はしない。文章が論理的に正しいかを意識しながらよんだりする。（鈴木）
チェックリストがあったとしても、それ自体が抽象的になっているので、それを当てはめるには…と考える必要がある。（風間）
