はじめに

2019年11月1日(金)にソフトウェアのレビューに関するシンポジウムJaSST Review'19に参加しました。今回は、そのレポートを自分なりの解釈でまとめました。

(まずはじめに) JaSST Reviewとは？ソフトウェアレビューシンポジウム

ソフトウェアレビューシンポジウム
ASTERとJaSST Review'19 実行委員会が主催
ソフトウェアレビューに特化したカンファレンスは国内でも少なく、貴重！

(まずはじめに) JaSST Revieｗ’19のポイント？　「レビューで指摘するときの思考」について

ポイント「レビューで指摘するときの思考」
- どのようなバグを狙って見つけにいっているのか
- 制作物のどんなところ、レビューイのどんなことを気にして指摘しているのか
- ＋効果的にツール導入をするためのプロセスについて
講演セッション
- 津田和彦氏（筑波大学大学院）
  - 「文書校正におけるReviewと活用するための分類およびルール化」
- 岡野麻子氏（三菱スペース・ソフトウエア）
  - 「レビューツールの利用とプロセスのあり方」
- 深谷美和氏（toRuby (とちぎRubyの勉強会)）
  - 「『違和感のつかまえかた』～組み込みシステムの開発者（テスター）としてやっていること～」
今回の開催情報
- 開催　　2回目（前回は2018年に開催）
- 会場　　TKP赤坂駅カンファレンスセンター
- 参加費　6,000円（税込）

ASTER（特定非営利活動法人ソフトウェアテスト技術振興協会）
JaSST (Japan Symposium on Software Testing) -ジャスト-
JaSST Review (Japan Symposium on Software Testing and Reviews)　
[JaSST Review’18] http://www.jasst.jp/symposium/jasstreview18/report.html

セッション

「文書校正におけるReviewと活用するための分類およびルール化」・・・津田和彦（筑波大学大学院）

レビューでは、制作物の多様な表現方法や、読み手の経験の違いなどにより、"間違い"のとらえ方が人により異なるという問題がある。
このセッションの内容は、制作物中の漠然とした"間違い"を、ルール化するための方法とルール化により得られる効果についてでした。
自然言語記述の制作物をレビューしている方は、"読みにくさ"や"理解のしづらさ"に悩まされることがあると思います。ルール化することで一定の"読みやすさ"・"理解しやすさ"を確保できるかもしれません。

ソフトウェアレビューの悩み事　＝　自然言語で記述された制作物は、読みづらい＆理解しづらい

自然言語で作成される設計制作物は、表現が自由であり、テクニカルな内容を理解し議論する以前に、「読みづらい」,「理解しづらい」という悩みを持つことは少なくない。

ソフトウェアレビューの一課題　＝　制作物の多様性×関係者の多様性により発生する”暗黙知”

制作物の表現が多様化している一方で、関係者(製作者やレビューアなど)の知識・経験のレベルなども多様であり、「読みづらい」や「理解しづらい」を、各々が”なんとなくの感覚” (=”暗黙知”)で感じている。

”なんとなくの感覚”でレビューしてしまうと、制作物の判定基準(OK/NG)は関係者(製作者やレビューアなど)によって異なるので、制作物の品質(レビュー結果)が属人的になってしまうという問題がある。

そのため、”なんとなくの感覚”(=”暗黙知”)を捉える必要がある。

※暗黙知　主観的で言語化することができない知識

“暗黙知”を捉えるための方法　＝　“形式知化”

”なんとなくの感覚”(=”暗黙知”)を、言語化（”形式知化”）することで、部分的に制作物の判定基準(OK/NG)を捉えることができる

暗黙知を形式知化する例↓
- 誤字・文法誤りを添削
- 単語表現の添削 (ex. (誤)「ヴァイク」 / (正)「バイク」)
- 慣用句表現の添削 (ex. (誤)「頭をかしげる」 / (正)「首をかしげる」)
- 副詞の呼応の添削 (ex. (誤)「たぶん～する」 / (正)「たぶん～するだろう」)
文章表現に対する形式知化の例↓
- 文長、文節の長さを制限 (ex. 一文40文字以内)
- 使用禁止用語と置換 (ex. (禁止)「土方」/ (置換)「建設作業員」)
- 同音異義語への置換 (ex. (置換前)「しかし，けれども，が，etc.」 / (置換後)「しかし」)

捉えた形式知をルール化し、ルールを関係者が守ることで、制作物の品質(レビュー結果)の属人性を部分的に軽減することが可能
暗黙知全てを形式知化することは難しいので、100点の制作物ではないが、
把握できる範囲での暗黙知を形式知化することで、80点の制作物をコンスタントに開発可能になる。

※形式知　客観的で言語化することができる知識

まとめ:　暗黙知（「読みづらい」や「理解しづらい」）の形式知化により制作物の品質向上

制作物の「読みづらい」や「理解しづらい」を、”なんとなくの感覚” (=”暗黙知”)で感じている
”なんとなくの感覚”(=”暗黙知”)を、言語化（”形式知化”）することで、部分的に制作物の判定基準(OK/NG)を捉えることができる
捉えた形式知をルール化し、ルールを関係者が守ることで、制作物の品質(レビュー結果)の属人性を部分的に軽減することができる

「レビューツールの利用とプロセスのあり方」・・・岡野麻子（三菱スペース・ソフトウエア）

業務の質や効率の向上を目的に多くの現場でツールが導入されています。しかし、ツールを導入したにもかかわらず、期待する効果を得られなかったということもよくあるかと思います。このセッションでは、ツール導入により効果を得るために、ツールを導入するまでの流れとその時に考慮すべき点についてお話がありました。
ツール導入を検討する際には、漠然と導入を進めるのではなく、本セッションで紹介されているプロセスで進めていくと、効果的な導入につながるかと思いました。

効果的なツール導入のためには？　事前検討が重要！

一言にツール導入といっても、漠然とツールを導入しても期待する効果が得られるとは限りません。事前に分析と検討をすることで、効果的にツール導入をすることができる。
↓のプロセスでツール導入を進めると、効果的にツール導入を実現することが可能。

課題抽出
手段選択
効果想定
ふりかえり

1. 課題抽出: 人の抱えている課題(“愚痴”や”違和感”)をチームで共有する

チームの課題は、メンバの愚痴(ex.「この作業、時間かかり過ぎじゃない？」)や、メンバの違和感 (ex.「ちゃんとセルフレビューしているのかな？」)の中に隠れている!

そのため、メンバの抱えている課題(“愚痴”や”違和感”)をチームで共有して、表層化する必要がある。
↑これやらないと次進めないので、ちゃんと困りごと共有はとても重要！
朝会、チームミーティング、立ち話、etc. でチームメンバの抱えている愚痴・違和感を共有してみては？

2. 手段選択: ツールに求める機能を検討し、ツールを調査

チームの抱えている課題を解決することが最大の目的であることを考え、
課題に対して、どんな機能がツールに求められるか事前に検討を行う。
ex.
(愚痴)「ちゃんとセルフレビューしているのかな？」
→ (ツール要求) 「簡単なチェックはツールに任せて、それ以外の作業に時間を費やしたい」

3. 効果想定: 課題は解決されるか？シミュレーションする

ツールを導入により、チームの課題が解決されるのか、シミュレーションしてみる。
その際に、ツールに期待する効果と期待しない効果を明確にしておくことが大切。

せっかく、導入したのに、↓だったら嫌ですよね。

目的を果たせない
一部の人の利益にしかならない・一部の人しか関心がない
ツールを導入して運営していくための知識・体制がない
ツールの情報を共有する仕組みがない
ツールを導入したのに全員が使いこなせない
ツール導入後の効果を測れない

4. ふりかえり: 実施後の変化と成熟度

カイゼンは、ツール導入して終わりではなく、課題は解決できたのか？「効果の測定」をする必要がある。
効果測定は、数値で定量的に評価することが重要で、良くなった・悪くなったという抽象的な表現では説得力がない。定量的に測定・評価（ツール利用により工数○○時間削減）とすることで、説得力が向上する。
(また、別の困りごとが発生したならそれをカイゼンする活動を開始する必要があります。)

まとめ: ツール導入で効果を得るために

ツールを導入することを目的にしない
- なんとなくで、ツールを導入しても大きな効果は得られない
- チームの抱えている課題に特化した“ツール導入”をして初めて効果が得られる
ファーストステップは、チーム内の課題を表層化すること←肝心
- メンバの抱えている違和感や愚痴の中に課題は隠されている
- 一度、チーム全員で共有してみましょう！
ふりかえりの重要性　ツールを導入して終わりではない。
- 発生した新たな課題に対しても引き続き”カイゼン”を続けていきましょう
- ツールを導入してどれだけ効果がえられたのかを定量的に測定する

「『違和感のつかまえかた』～組み込みシステムの開発者（テスター）としてやっていること～」・・・深谷美和（toRuby（とちぎRubyの勉強会））

このセッションの内容は、miwaさんがテスト(レビュー)をするときに、気を付けていること・実践していることについてです。
レビューに携わるエンジニアが、実際にレビューで「気にしている観点」や「アンテナの張り方（違和感のつかまえかた）」についての紹介で、実践的な内容でした。新人レビューアを始め、普段レビューを実践している人にとって、とても刺激・勉強になる内容だと思いました

何を見て違和感をつかまえているのか？

テストやレビューをするときに、その製品自体は多くの人が注目していると思います。しかし、それ以外にも人の発言や会議の内容、チケット状態や、コミットの履歴など様々なことに違和感のヒントは落ちている。今回はその一部を紹介していただきました。(↓以外にも、「私は○○を気にしているよ」というのがあれば、ぜひコメントお願いします。)

@ 朝会で考えていること
- 自分ならどう解くかを想像しながら、実際との差分を探している
- まだ見つかっていない問題を見つけようとしている
- テストのネタ探し
- 本当にそれがやりたいことなのか？（要件定義に戻るときもある）
- どのようなことを試したいかを考えている
- どうやったら壊せるかを考えている（エアテスト(脳内テスト)）
- 話題になっていないことは何かを考えている
- 同僚の様子や言動を観察している(↓要注意ワード)
  - 「そういう仕様です」
  - 「ずっと前からそうなっています」
  - 「大したことない変更」
  - 「今回はマージするだけなので」
  - 「全部やりました」
@ テストしているとき
- 自分の期待する動き、予想と比べてどうなのか
@ チケットを見るとき気にすること
- 知りたいことが書いてない、情報が足りない
- ひとりで複数のチケットに手をつけている
- Bugチケットは頭に叩き込む勢いで読み込んでいる
@ コミットログを見るときに気にすること
- 変更する内容に対して変更したファイルが多すぎる
- 気になるものは変更前と変更後のコードの差分
- 連休の前日にコミットしたもの
@ 自分自身から感じること
- 感情の変化や身体の状態

違和感に対する感性を高めるには？

製品を知っているからこそ感じることが圧倒的に多い
- よい製品、わるい製品のイメージを持っていた
- 設計の難しいところ、間違いやすいところを知っていた
- 過去の不具合を知っていた（再現手順や現象、原因も）
他者の違和感を取り入れている(なりきり)
- なぜそれをやってみようと思ったのかを聞く
- なぜその問題（バグ）に気づけたのかを聞く
自分の感情に目を向け、なぜそう感じるのかを考えている
- なぜそう感じるのか、何がそうさせているのかを考える

違和感をつかまえるためのコツ・工夫

自分の意識の持っていきかたを矯正している
- 誰も（自分も）考えそうもないことは何かを考える - 見えないもの、書いてないことに注目する - 話題になっていないことは何だろう？ - 安心していることは何だろう？
  - 間違っているかもしれないぞ、と思う
    - 決まった仕様、過去にそれでよしとしたもの
    - 自分のことも疑う
    - それが間違っていないとなぜ言えるのか
    - それで良いとなぜ言えるのか
  - 想定外の問題を見つけるのではなく想定をひろげる
    - 気にする範囲をひろげる
    - これだけやっていればいい、は危うい
疲れないようにする
- 疲れているときは違和感をつかまえられない
- 仕事中は１時間に１回は休憩を取る

違和感をつかまえた後のこと

つかまえた瞬間に声を出す出し惜しみしない
観察する　違和感の正体を明らかにする
同僚に話す　同僚の考えを聞いてみる

※違和感をつかまえたのに、そのままにしてしまったことありませんか？

そういうものなのかもしれない
気にはなるけど問題（バグ）とは言いきれない
ずっと前からそうなっている
気のせいかも

↑の考え方は危険

つかまえた違和感は、すぐに声に出しましょう!
一人で抱え込まず、チームの問題として捉えましょう！
発言しやすいチームの雰囲気づくりを日ごろからしましょう!

+α eXtremeなチーム

”最良の開発プラクティスを最大限適用する”という考えのもと、レビューが良いものならば、常にレビューするを実践しているそうです。
開発スピードの向上、品質の早期向上のために、形式的レビューに固執せず、非形式レビューを日常的に行うことも大切だと思いました。

まとめ:　レビューアとして品質向上に貢献するために

違和感をつかまえる
- 製品について知る
  - 弱いとこ
  - 過去のバグ
- 全シーンで"本当にそれでいいのか？","なぜそれでいいのか？"を客観的に考える
- 対象は、制作物だけでない
- 人の発言や会議の内容、チケット状態や、コミット履歴など様々なことに対して違和感のアンテナを張る
- 誰も（自分も）考えそうもないことは何かを考える
- 間違っているかもしれないぞ、と思う
- 想定外の問題を見つけるのではなく想定をひろげる
つかまえた違和感は、すぐに声に出す
- 一人で抱え込まず、チームの問題として捉える
- 発言しやすいチームの雰囲気を日ごろからつくる

イベント全体のまとめ

JaSST Review'19を通じて、ツール導入時に検討すべきこと、レビューの質を上げるためにレビューアとして実施するとよいこと、レビューの対象(制作物以外の)と考え方を学ぶことができた。ぜひ↓を実践していきたい

ツール導入で実践したいこと
- 事前検討を十分に行ってツール導入を進める
  - ツール導入を効果的に導入するために、漠然と導入を進めるのではなく、事前検討を十分に行い、効果的にツール導入を行う必要がある
- チームのメンバが抱えている課題を共有して、課題を表層化する
  - ツール導入のファーストステップは、チーム内の課題を表層化すること
  - メンバの抱えている違和感や愚痴の中に課題は隠されている
  - 課題をチーム全員で共有する
レビューアとして実践したいこと
- "間違い"や"読みづらさ","理解しづらさ"の原因を、形式知化する
  - 形式知化し、制作物作成時のルール、レビュー時の観点に反映させ蓄積する
  - レビューアによる観点の違いを解消する
  - 他の人の観点をシェアする　
- 全シーンで"本当にそれでいいのか？","なぜそれでいいのか？"を客観的に考える
  - 対象は、制作物だけでない
  - 人の発言や会議の内容、チケット状態や、コミット履歴など様々なことに対して違和感のアンテナを張る
  - 感じた違和感は、形式知化し、レビューの観点として蓄積する
  - 蓄積した観点は、他者とのシェアにも活用する
- テストやレビューを、発想的に取り組む
  - 疑いの目を常に持ち、違和感("本当にそれでいいのか？","なぜそれでいいのか？")に敏感になる
  - "なりきり"(あの人ならどんなことを考えるかな？と考える)を実施する
- とらえた違和感は、声に出す
  - ひとりの問題ではなく、みんなの問題として共有

参考URL

[JaSST Review'19] http://www.jasst.jp/symposium/jasstreview19.html
[togetter まとめ] https://togetter.com/li/1424587

【イベントレポート】JaSST Review'19