JaSST Review2022 ワークショップへの質問に対する回答
質問 1
非同期でのレビュー（これを期日までにレビューしてください的な）が多いのですが、その時に特に注意した方が良いなどはありますか？
回答 1
非同期のレビューは、集合形式の実施が難しい状態の時に有効なアプローチの一つになりえますが、レビューアが一人である場合、レビューアの力量や持ち時間等により、見逃しが増える、偏った見方になってしまう可能性があります。
また、レビューアが複数人の場合についてはいくつかポイントがありますので個別に記述します。
・レビューアが複数人の場合は暗黙のうちに重複（n 重）確認が行われている可能性が高く、多重度をどこまでにするのかなどを事前に考慮して実施する必要があると思います。
・期日ギリギリに駆け込みでレビューコメントを提出してくる方が多く、一度に殺到する恐れがあります。レビューを受ける作業者はその辺も加味して期日を決めるのが良いです。
また、期日を過ぎたコメントをどうするか、は、あらかじめレビューアに通達しておくとよいです・同一箇所に対してレビューア毎に異なる見解が提示された際の対処に困るケースもあります。この場合、レビューを受ける作業者の力量によって結果集約後の対処をフォローするメンバーをつけるなどの対策が必要になります。

質問 2
ミーティングのタイムボックスが守られない場合にどういった対処をするとよいか。
回答 2
タイムボックスの時間設定が不適切な場合や、レビュー実施方法が不適切な場合など、その要因はいろいろですので一律の対処はないと思います。
例えば前者は、レビュー対象の量が多すぎて、設定した時間枠では不足であることを指しています。よって分割して実施するなど、分量と時間が釣り合う形に運営を変えることが必要になると思います。
人間の集中できる時間はせいぜい 30～60 分程度ですのでその枠を超える場合は一度休憩をとるとか、別の日時に続きを行うような配慮が必要です。
また、レビュー対象がすべて作成されてからまとめてレビューを実施するような形式は、大量の不備を作り込んでから一斉に指摘するため、大きな手戻り作業になりレビューアも作成者もみな不幸になってしまいます。
「部分的な成果物作成→レビュー」×ｎ回にするような段階的なレビューに組み替えるな
ど、時間だけでコントロールするのではなく、レビュー対象物の量的なコントロールも併用するなど工夫すると良いと思います。
一方後者の場合、途中で話が横道に逸れたまま戻らないとか、対処方法の議論に時間を使いすぎるなど問題があるケースも散見されます。司会（ファシリ―テーター）が集合会議冒頭にレビュー目的や運営方法、グランドルール等を共有する際に「横道に逸れないように集中して議論しましょう！ただそうなってしまった場合は私が介入して本線に引き戻す場合もありますよ」「指摘事項の確定を優先し、対処は時間があれば実施する」など注意喚起を行ってからスタートするのも一案だと思います。

質問 3
レビュー指摘が多過ぎるときは効果が高いものに絞ってレビュイーに伝えるべきですか？
（5:1 の意識や、そもそもレビュアーが時間をかけ過ぎているとか）
回答 3
修正が必要になるものは漏れなく伝える必要があると思います。
指摘事項が多すぎる、という状態になるのは、作業者の力量も一つの要因ですが、その状態に対するリスク対策を取っていないことが大きな要因だと思います。
作業者の力量が不足している場合や、大量の指摘が想定される場合は、「部分的な成果物作成→レビュー」×ｎ回にするような段階的なレビューに組み替えるなど、工夫すると良いと思います。
そのうえで、説明不要な誤字・脱字・衍字や類似の指摘事項がたくさん続く場合などは別途メモ書きでも伝えるようにするといいかもしれません。

質問 4
書かれていないことを見つけるコツはありますか？
回答 4
レビュー対象だけでなく、その上位や横の文書もインプットとするのもいいと思います
さらに、今回のワークで示したレビュー観点導出アプローチ「(A2)利害関係者の関心事アプローチ」と「(A3)対象成果物に求められることアプローチ」が参考になると思います。
(A2)はレビューの視座を変えることで、(A3)は「書かれていてほしいこと／書かれた結果どういう状態になっていてほしいリスト」でチェックしますので、「抜けや漏れ」が見つかりやすくなります。
また、レビュー対象が文章で書かれている場合は、その内容を表やマトリクス形式で表現する、テストケース構成要素をテンプレート化してそれぞれの枠に書き写してみるなど、「別の表現形式」に変えると”不足（書かれていないこと）”に気づきやすいです。

質問 5
レビューを開催しても他人事のように参加している人が多いです。そのような場合にはどうすれば良いですか？
回答 5
他人事になっている背景や理由により対応が異なると思います。
まずは、レビューの目的や意図、進め方、それぞれのレビューアに期待していることや役割等を全員で共有してから始めるのが基本です。
特定の個人だけが他人事になっている場合なら「私にはあなたの行動がこういう風に見えるんだけど合ってます？」と（責める意図ではなく、あくまでも自然に）本人に聴き、その理由により対処を考えます。
（私なら、ですが）一方ご質問の「他人事のように参加している人が多い」という表現から、チームや組織が持つ背景として当事者になると損をする、危害が加わる可能性があるような状態になっている可能性があります。
失敗すると断罪されるとか、やる気を見せると自分が持つリソースに見合わない余計なタスクがどんどん積み上がって身動きが取れなくなるなどがその例です。
まずはそれらを解消することが他人事になってしまっている現状を変える一歩になると思います。
これはレビューに閉じた話ではなく普段の作業状況がそうなっていることが多いのが通例です。その場合は、改善すべきはレビューではなく普段の作業環境です。
如何にして普段から必要な議論を建設的に行いながら作業を進められるようにするか、マネジメントのあり方が重要です。

質問 6・レビューの重要性に気づいていないメンバーへレビューの大切さを伝えるためにどんな活動をすればよいか。
・レビューを行なうことの価値の持たせ方を知りたいです。
(実施することが目的、というところからの脱却させたい)（以上 2 件は同様の内容とみなして回答します）
回答 6
理屈が分かると動く可能性があるならレビューある・なしで作業全体がどのように変わるのかを理詰めで説明する方法があると思います。
例えばレビューを実施する／しないで何が違うのかを身近な事例で整理して理解できるようにするところから始めるのが一案だと思います。
そうではない場合は、対象者の実務で問題や障害、手戻り（自分事となる事象）が発生した際に、発生要因と対策を事実情報に基づいて検討し、どの段階でどのような対処（例：レビュー）を行うとこんなことにならないかを自ら導出してもらい、関係者間でそれを議論して結論を導くのがよいと思います。
ここで大事になるのは「本人が自らその答えを出す」ことで、答えを押し付けることではありません。
関係者のみなさんは結論を押し付けることなく、自ら適切な解が得られること、そしてそれを本人が実践して効果を確認することをサポートしてあげてください。

質問 7
求める観点で見られるレビューアがいない時のカバー策はありますか？
回答 7
同じチームに求める観点で見られるレビューアがいない場合は、それができる別チーム、別組織の方にその部分だけピンポイントでお願いする／助言を求めるのがよいと思います。

質問 8
QA ならではのレビューの視点、コツがあれば教えてほしいです。
回答 8
QA は組織によって求められる役割や実践している事項が異なります。
例えば単にテストを実施する独立した役割を QA と呼ぶ組織もありますし、利用者や顧客が求めることを実装し、確認する方法を設計し、実践することを QA と呼ぶ組織もあります。
よって、「(A2)利害関係者が持つ関心事アプローチ」で利害関係者の一人に「QA」におき、対象成果物やプロダクト／サービスに関わる活動とその関心事から展開すると答えが出ると思います。
組織横断的な QA の場合は、複数のプロジェクトでの事例を知っていることが多いのでその利点を生かして「こんなことがあったよ、、とか、他のプロジェクトではこうしているけど大丈夫？」のようなアプローチを、プロジェクトの外にいるのであれば一歩引いた客観的な目線でのレビューが効果的になると思います。

質問 9
ペア・モブでの作業(コーディング、設計に関わらず)を実施した場合のレビューの実施可否の判断方法はありますか？
回答 9
すべての作業をペア・モブで行っている場合、レビュー不要とする組織もあるようです。
https://jasst.jp/symposium/jasstreview18/pdf/S2.pdf
ただ、ペア・モブ作業をどのレベルで実施しているか、誰とやったのかにもよると思います。
例えば代表的、典型的な箇所だけペア・モブ作業で行い、あとは同様に作業しておくようなアプローチもありそうですし、有識者が入らず特定のメンバーとペア・モブ作業を実施したにすぎない場合もあり得ます。
また、ペア・モブ作業を実施した後に要件や仕様に変更依頼が発生しているかもしれません。
よって、実践したペア・モブ作業やその後の変化が持つリスクを評価して決めることになると思います。

質問 10
レビュー実施時にバイアスを持たずにレビューする思考プロセスについて知りたいです。
回答 10
バイアスがかかる＝偏った見方になる、先入観や思い込み、決めつけで指摘する、などを指していると解釈しました。バイアスを完全に除去するのはおそらく無理ですが、可能な限り小さくすることはできると思います。
今回ワークでご紹介したようにレビュー目的から段階的に詳細化した観点に基づきレビューを実施する方法は、偏った見方にならないようにする＝バイアスを低くすることに効果を発揮すると思います。
あと、「あなたはきっとこう考えたに違いない」「どうせこうだろう」等作業者に対する決めつけが悪さをすることもあります。こういう捉え方をすると指摘事項が「あなたの〇〇が××だ」という「ユーメッセージ」になりがちで、作業者がとても嫌な思いをしがちです。
このようなネガティブな議論や結果を出さないように、レビュー会議の冒頭で「作業者に対する敬意を持ち、みなでよいものを作り上げるために事実に基づき建設的な議論をお願いする」、そしてレビューアは基本的に「アイメッセージ」で結果を伝える、推論や想定と事実を明確に分けて「事実に基づいて結論を出す」、司会は、建設的議論を逸脱しそうなときや逸脱した際にすぐに処置を行うなどがもう一つの対策になると思います。
※アイメッセージ、ユーメッセージの詳細については Web 検索などでお調べください。

質問 11
・(主に設計レビュー等での)議論しやすいレビューの空気の作り方。
回答 11
今回のワークのテーマとは外れる内容ですが回答します。
建設的な議論を阻害する要因はいろいろありますが、特に我の強い有識者が参加している場合が挙げられます。
話し始めるとみんなが黙るしかなく独演会になる、他人の意見には耳を貸そうとはしない、そのうちに作成者自身や異を唱える人を攻め始める、というような人です。
そのような方がレビューメンバーになった場合は、その方には単独でレビューを実施いた
だいて結果を入手し、他のメンバーは集合してレビューを実施するようなセパレート方式にするなどの工夫が必要です。
また、建設的に議論して最終的に適切解を導くためには、ファシリテーション実践が必要になると思います。
集合レビューの冒頭で建設的議論をお願いし、一人 1 件発言したら次に回す、全員が発言するように直接質問してコメントを引出す、有識者の意見を立てつつも余計な感情的軋轢にならないように場をコントロールする、もしルールを逸脱したら都度補正する、などのファシリテーション実践が効果的だと思います。とはいえ、以上はファシリテーターだけが実践することではなく、最終的には参加者全員が実践していくことが求められることに注意が必要です。
他にも以下の発表資料の内容をネタに、メンバーで話し合ってみるのも効果的かと思います。
https://jasst.jp/symposium/jasstreview21/pdf/S3-2.pdf

質問 12
作成者が「レビュアーに言われた通りに直せばいいんだ」と思考停止してしまわないように、フィードバックを伝える方法。
回答 12
思考停止させないアプローチの例ですが、対処方法を簡単に教えず、一緒に考えるけどヒントやポイントになることは伝えるけど自分で答えを出すまで考えてもらうように対話をするなど、形式的なアプローチをしないことです。
また、このように形式的にモノゴトを進める方は、目先の効率ばかり重視している傾向があります。そのように考えて行動してしまう要因が本人の特性なのか、それとも「良いものを作るよりも売上重視」のような組織やチームの価値観から来るのかは見極める必要があると思います。

質問 13
モブテストのように進めるレビューのやり方を知りたいです。
回答 13
モブテストとはどのようなものでしょうか？
テスト設計や実装、実行を関係者と一緒にやる、という類のものですか？
そうだと仮定すると、レビュー設計や実装・実行については、今回ワークショップで実施した内容を関係者で一緒に議論しながらやっていくのが一つのイメージになると思います。
その際に、Miro のようなオンライン情報共有環境を活用し、関係者が同期・非同期でレビュー設計や実装結果を共有し、同時編集が可能な状態で進められると、在宅・分散したメンバーでもモブレビューが進められると思います。