こちらは ソフトウェアテスト Advent Calendar 2019 20日目（2019年12月）の記事ですよ。
11月のある日よしたけさんから「ソフトウェアテストアドベントカレンダー2019に参加しませんか？」と誘われた。
私がブログなどに投稿したのをあまり見ないので記事を読んでみたいという理由らしい。
あーあ、ついに化けの皮がはがれる時が来た。（別に隠していたわけではないけどね）
私、国語が大の苦手で学生の時分に大いに苦労した輩だから文章を書くのが超苦痛。
子供の頃も外で遊んでばかりで絵本や昔話すらほぼほぼ読んでいない。
ある程度大人になってから、メディアで流れてくる部分的な情報が耳に入って何となくわかっている程度。
一寸法師と金太郎とおむすびころりんと花咲かじいさんが混じってシナリオと結論がいまいちよくわかっていない。（苦笑）
国語のテストで「この場面で〇〇の気持ちを回答しなさい」という問題に「その人に聞かないとわかるわけない」と真面目に解答した戦歴を持つ。（汗）
とはいえ、よしたけさんにはお世話になっているので覚悟を決めて書くことにした。
きっとつまらない内容だから読み飛ばして構わない。
テストの猛者のみなさんが書いた面白い記事、尖った記事が続いていると思うので、ちょっとした箸休めくらいになれば・・・いや、そんな気の利いた文章も書けないのであしからず。
文章の組み立てを考えて、、、なんてことはやりたくてもできないで思い付きの話題をバラバラと書いてみることにしよう。
みんなテストのことを書くと思うので、私は「レビュー」のことを。
思い浮かんだことに表題（■・・・）をつけて書いては次の話題へと。
表題ごとに連携させるようなことは考えていないので注意してね。
でははじまりはじまり～。
あ、この時点で「テストアドベントカレンダーなのに、どうしてレビューなんだよ！」って思った人はJSTQBのシラバス第3章を読んでね。
→http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018.J03.pdf
レビューはテストの一形態らしいよ。
■レビューとのかかわり～空回りでもいいのさ
そういえば最近お仕事やコミュニティで「レビュー」に関わることがこれまで以上に多くなってきた。
コミュニティ関連でちょっと思いついたものだけ書いてみると
・日科技連SQiP研究会レビュー分科会のアドバイザー対応が3期目（昨日4期目も継続が確定）
・JaSST Review2018初開催運営
・JaSST2019北陸招待講演「そのレビュー、大丈夫ですか？ ～現状レビューの問題発見・解決」
・JaSST2019新潟基調講演「レビューのキキメ ～あなたのレビューは何のため？」
以前に実務で毎日毎日レビューをやらなければならない境遇が長かったくらいで、優れたレビューアでも何でもないのに・・・。
たくさんのイヤな想いや失敗を繰り返し、未だにうまくできる気もしない。
とはいえお声がけいただけること、これまでにない活動にかかわれるのはとてもうれしいことだ。
声がかかるうちが花だから、普段の実務で使える、あるいはヒントになる情報やヒントくらいは残しておきたいとは思って対応している。
ところでいつ頃から「レビュー」のことを外向けに発信するようになったのかと思い返してみると、、、あ、そうそう。
2006年にJaSST札幌（現在のJaSST北海道）を立ち上げた際に書いた論文がきっかけだった。
首都圏に行かないと技術情報が得られない田舎の境遇を打開するために地元で開催させてもらうことにしたJaSST札幌。
開催準備の過程で発表コンテンツが不足したため、初開催準備でてんやわんやの舞台裏で無理やり論文を書いたのがきっかけだった。
空いたコンテンツ枠を実行委員長自らの発表で埋める。
誰かがやってくれるわけではないから自分でやるしかない。
今考えるとハチャメチャな対応だけど当時はJaSSTを初開催するのにとにかく必死だった。
それまで論文なんて一度も書いたこともない＋JaSST開催準備だけで手も足も出ない状況でホントにアホだよね。
忙しかった仕事に加えて初JaSSTの準備で空回りしまくっていたんだよなぁ。
当時はそのくらいの勢いというか若さ（当時42歳、、、ぜんぜん若くないしｗ）があったのかも。（苦笑）
JaSST2006札幌終了後に宴会会場に向かうタクシーの中で、Nさんに「おまえがあのような内容を論文にするのは十年早い（意訳）」と言われたよなぁ。
はははは、まあいいさ。
とにかく、JaSST2006札幌は無事にやり遂げたのだから、と頭の中で思っていたのはナイショ。
その後この論文がきっかけで少なくとも5年間ほど、見知らぬ方から突然連絡が。。。みたいなさまざまな引き合いをいただいた。
内容の良し悪しはともかく、苦しくても逃げずに夢中で取り組んで結果を出力するとちゃんとそれを見て拾ってくれる人が現れる。
バタフライ効果とまでは言わないけど、世の中のしくみってホントにすごいなぁと思う。
たとえ誰も見ていないと思えるところでも自らを信じて一生懸命取り組み、アウトプットするのって大事だよね。
一つ目の話題、これで終わり～。
■レビューって言葉がつかないとレビューじゃないの？
JaSSTでも話したことなんだけど、「レビュー」って言葉がついた活動じゃないとレビューではないと思っている人がたくさんいるみたい。
チームメンバーで設計成果物に対して「設計レビュー」を行うとか、「レビューをお願いします」と頼まれたから実施したとかそういうこと。
でもね、「ねーねー、これ、こうしようと思うんだけどどう思う？意見聞かせて！」とか「〇〇の承認をお願いします」とか「□□機能についてちょっと相談に乗って！」とか。
こういうのも一種のレビューなんじゃないのかな。
一つ目と三つ目は、解法の適切性確認、または代替案の有無の確認と検討。
二つ目は、申請内容の審査。
無理やりそれっぽいことを書いてみたけど、レビューって名前がつかなくてもレビューってやってるんだよね。
フォーマルなレビューや〇〇レビューって名前がついていることだけがレビューではない。
よいソフトウェア／システムを作るために関係者がもっとカジュアルにレビュー（というか対話による検討＆相互理解）に取り組めばよいと思う。
レビューと称してわざわざ集まって実施する意味を、もう一度確認してみるのがいいんじゃないかな。
「いつもそうしているから」は理由にならないから注意してね。
二つ目終わり。（はやっ！）
■レビューって”何か”との比較？
レビューでは、レビュー対象を確認して指摘事項（質問なども含む）を提示する。
その時に主にやっているのは「”何か”との比較」なんじゃないかと。（仮説）
いや、たった今思い付きでそう考えただけだからたいした話ではない。
テストに例えると”期待結果”と実際のテスト結果との突合、と似たような位置づけになるのかな。
その”何か”とレビュー対象の内容を突合することによって、合っている、間違っている、あれっ？何か変だな、ん～意味がわからないから質問しよう！、などの結果を出力する。
一般的にはこの”何か”が頭の中にあることが多く、その量や質がレビューアの力量を左右しているように思える。
（おっ、この思い付き、もしかするといけるかもしれない。（ワクワク→勝手な思い込み））
”何か”の例を思いつくまま列挙してみようっと。
一般常識や自分の経験則、成果物作成への入力情報、各種のルールや規約、関連ドキュメントの記述内容など。
その場で自分が理解したこと、認識したことなども含まれる。
例えば、レビュー対象となる作業成果物を作る際に使った入力情報と、作業成果物の内容を突合する場合。
入力情報と作業成果物を直接ぶつけているように思えるかもしれないけど、実際にはちょっと違うような気がする。
入力情報を読み取り、自分の頭の中でそれを理解した結果が”何か”じゃないかな。
理解する過程、つまり”何か”を導き出す過程で、知識として持っている一般常識や過去の経験などが活用されているに違いない。
もう一つ違う例でも”何か”との比較が成り立つのかどうかを検討してみよう。
レビュー対象成果物の内容を読みながらそれを理解しようと・・・ん？これはどういうこと？？？・・・わからない！ってなった箇所に質問や疑問をぶつける。
あらら。この例だと”何か”って登場しない。
やっぱり思い付きの仮説はダメかも。。。いやいや待て待て。もうちょっと粘ろう。
(1)作成者が意図したこと、を(2)成果物の記述として表現する、そして(3)レビューアが読んでみて理解する（または、理解できなかった）。
最終的に(3)の自ら理解したことベースに、作成者に(1)を質問して解決（レビューアでも理解できるように直す）に向かうなら、”何か”は(3)になるなぁ。
お、やっぱりイケるかも。（ホッ）
ということでまとめると、レビューでは「自分の理解」と対象を比較して判定しているんだな。（そうだ、そうなんだ）
なんてどうでもよいことを、出張帰りのJRの中でツラツラと考えていた。
だから何？って言われると、、、それまでだけど（爆）。
あ、三つ目終わり。
■レビューの利点って？
JSTQBのFLシラバスには「静的テストの利点」として以下のようなことが書かれていた。
→http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018.J03.pdf ※第３章を見てね。
・ソフトウェア開発ライフサイクルの初期に適用すると動的テストを実行する前に欠陥を早期に検出し、安価に除去できる。
・欠陥の検出と修正をより効率的に、しかも動的テストを実行する前に行うことができる。
・動的テストでは容易に検出できない欠陥を識別できる。
・要件の不整合、曖昧性、矛盾、欠落、不正確性、冗長性を明らかにして、設計時またはコーディング時に欠陥が混入するのを防止できる。
・開発の生産性を向上できる（設計の改善、保守性の高いコードなど） 。
・開発にかかるコストと時間を削減できる。
・テストにかかるコストと時間を削減できる。
・ライフサイクルの終盤または本番リリース後に検出される欠陥数が減少し、ソフトウェアの存続期間にわたる全体的な品質コストを削減できる。
・レビューへの参加過程でチームメンバー間のコミュニケーションを改善できる。
いっぱいありすぎてよくわからないけど、安い、早い、コスト・時間が削減できる、など主に管理者にとって魅力的なものが多い印象。
そして動的テストが苦手なこと（例：保守性や規約への適合、書かれていないこと＋必要性がないことの検出など）をレビューは実施できるらしい。
こんなにたくさんある利点のうち、実際どれくらい獲得できているかを評価してみると・・・悲しい現実が・・・。
まあそれはよいとして、そもそもレビューの度に明確な目的を設定して実施している組織やチームはどのくらいあるんだろう？
「今回はこんな結果が欲しいな」でもよいので。
つまり、欲しい結果をあらかじめ狙って実施しているかってこと。
さらに、レビュー終了後に得られた効果やうまくいかなかったこと等を評価して、次の実施につなげている組織やチームはどのくらいあるんだろう？
以上、（狙いもせず）いつもの通り、いつものやり方でなんとなくレビューを・・・みたいに、ぼんやりとなんとなくレビューをやっても、シラバスに書いてある利点を得ることは（ほとんど）ないので注意が必要だよね。
四つ目終わり。
■レビューが教えてくれたこと
好きでそうなったのではないけど、これまでたくさんレビューをやってきた。
もちろん今でもやってるよ。数は減ったけど。
レビューを通じていろいろな気づきをもらったんだけど、その中でもピカ一（ピカチュウの鳴き声「ピカ～」ではなく、ピカイチｗ）だなと思うのは「相手の立場（立ち位置）に立つことって大事」。
レビュー対象は、作成者の考えが反映されたものだから、その方の趣味嗜好や考え方の癖、性格、作成時の境遇などが成果物の内容に影響を与える可能性がある。
単にレビュー対象記述だけから答えを出そうとするのではなく、作成者がどのような性格で、作成する際にどのような境遇で、何を考えて作りこんだのか？、その結果、どこにどんな欠陥を仕込みそうなのか？などを想定しながら観ることが必要だ。
100%相手を理解する、100%相手の立場になりきる、のはムリなんだけど、ムリだからやらなくてよいということにはならない。
自分が相手になった”つもり”で対象を眺めると見えてくるものや疑問が沸いてくることがある。
少しでも相手に近づく、相手を理解することがレビューの結果を変える可能性がある、ということになるのかな。
居間にあるガラス天板の机上に珍しい形の陶器の花瓶があるとする。
いつものソファーに座ったままで眺める。
立って近づき真上から見てみる。
机の下に潜り込み、真下から見てみる。
机の周りを歩きながら斜め上、斜め下、真横などから見てみる。
そして手に取って重さや手触りを味わう。
水を入れて、そして水を捨ててみる。
花を挿してみる。。。
対象を様々な立ち位置で、様々な角度から見る、触る、持ってみる、使ってみる、、、これがレビューでやるべきことの例え。
その中の一つとして「相手の立ち位置に立つ」がある。
たった一つかもしれないけど、相手を理解する、共感することが大事なことなんだなぁと実感させてくれたのはレビューだ。
相手を理解し、対象を理解する。
そういう背景で、そのように作れば、なるほどこうなるよね！って理解すること、共感することを通じて答え（レビュー結果）を出す。
その結果を相手に適切に伝える。
伝えられた相手も自分のことを理解してくれてうれしいと感じて、より良い成果物に仕上げ直す。
それが一つのレビューの形なのかもしれないね。
＜おまけ～後日談＞
上記の内容を書いた数日後、10数年ぶりに野中郁次郎さんの講演を聞いた。超楽しかった。
ナレッジマネジメントSECIモデル、そしてスクラムの生みの親。名著「失敗の本質」の著者。
講演ではSECIモデルを回して知的創造を促進する組織を作り上げるには「エンパシー（共感）」が大事だと。
その意味は〝他者の視点になりきる”だそうだ。
お互いまっとうに向き合い、徹底的に議論する。議論による相互理解を通じて新しい第三の案や知恵を導き出す。
そういうことらしい。
話しのレベル、ありがたみのレベルはぜんぜん違うけど、レビューが教えてくれたことと同じ匂いがした。
■レビューの大事な効果の一つ
ソフトの開発で大事なことの一つは、開発や運用の関係者（顧客も含む）がこれから開発するソフトウェアに対する認識を合わせている（合わせ続けている）ことだと思っている。
”ソフトウェアに対する”の中には、ソフトウェアを利用する人のコンテキストや、利用目的や利用局面における利用方法、ソフトウェア要件、仕様、振る舞い、作り方や考え方などが含まれる。
これらが関係者の頭の中で一致していないと、求められるソフトウェアがまともに完成しない、あるいは開発過程で混乱する可能性が高まるんだよね。
そしてこの場のテーマである「レビュー」って、関係者が集まってレビュー対象（ソフトウェアやそのことを記述したドキュメントなど）を突っつきまわし、実はこういう内容が正解だよねっていう結論を出していく。
その過程を通じて、参加した関係者のソフトウェア（関連成果物）に対する認識が（結果として）合っていくことになる。
つまり、レビューは”ソフトウェアに対する関係者の認識を合わせる”ために役立つ、効果がある、ということだ。
ただレビューをやっていれば必ずそうなる、ってほど簡単ではない。
そのことを意識して、意図的にレビューを実践すれば効果を獲得できるかも。
レビューが終了しても関係者の認識が合わない状態のままだったら、そのレビューは失敗かもね。
最近流行のモブワーク。
これは関係者がワイワイ成果物をその場で作成していく。
いや、作成していく、というのは正しくない表現かも。
ドライバー役が案を書き込む過程で、ナビゲーター役が必要なコメントや代替案、それらの理由等フィードバックを入れて、成果物を完成させていく。
もしドライバー役がわからないことがあれば「ここがよくわからないので教えて！」と言えばよい。
ナビゲーターがその場で教え、ドライバーが早速やってみる。
間違いや意味が異なる等があれば具体的に知らせ、直しながらゴールを目指す。
ドライバー役は教えてもらったことをその場で実践して、うまくいかないことも、その打開方法も含めて経験できる。
つまり、成果物を作り始めてから完成させる過程で、その作り方や考え方をも共有（教育）していく側面を持つ。
成果物作成とレビューと教育をすべてパッケージしてほぼリアルタイムに実践する。
そして関係者の認識を合わせをも同時に成し遂げる、それがモブワークだ。
関係者が集うので、その間他のタスクは止まることになるが、一度成果物が完成すると（変更や仕損じがない限り）そのまま前に進められる。
もちろん、チームのメンバーがすべてのことを知っているわけではない場合もあるから、時には仕損じが発生してて戻ることもある。
とはいえそれはモブワークであろうと、なかとうろ一緒だよね。
担当する機能やモジュールなど役割を分担し、それぞれの担当が思い思いの考えで成果物を作る。
出来上がったそれぞれの素案に対して関係者がレビューを実施し、その結果から手直しを行うのが従来の方法。
どちらがよいのかは選択肢だから課せられた制約の中で最も生産性のよい方法を、あるいは自分たちのやりやすい方法、ポリシーに合う方法を選ぶしかないんだよね。
いろいろと書いたけど、あらてめて関係者の認識を合わせるために必要なこと、大事なことはいったい何だったのかを今一度考えてみよう。
それは「レビューをすること」ではなく「互いに真摯に対話すること」。
真摯な対話のない、一方的なレビューや形式的な対応は効果が薄いのもそのせいだ。
そして真摯な対話はレビューをやらないとできないなんてことはないよね。
レビューに限らず、普段からソフトウェアに対する認識を合わせるための真摯な対話を継続しよう！そうしよう！
以上で思い付きの散文はおしまい。
昼休みや出張移動の時間を使って・・・計６つも書いたんだ！（←えらいっ）
こんなに文章書いたのは久しぶり。小学生の感想文みたいなレベルだけどね。
よしたけさん、素敵な機会をありがとうございました。
こんなのでよかったのかなぁ。。。でももうお腹いっぱいです。（笑）
みなさん、楽しいクリスマスとお正月を迎えてくださいね～。ではでは。