NPO法人ソフトウェアテスト技術振興協会 イベント報告-JaSST'15 Tohoku

オープニング

実行委員長の根本氏の挨拶。今年はテーマを「レビューフェスタ」とし、ドキュメントレビューやコードレビューをメニューにした。JaSST Tohokuで名物となりつつある「ライブ」はライブコードレビューを行っていただくことにした。
レビューは銀の弾丸ではないが、ヒントがたくさん散らばっているので、是非参加者にヒントを持ちかえって欲しいという言葉でJaSST'15 Tohokuが始まった。

アイスブレークタイム

一人一枚ずつ紙が渡され、レビューについて感心があるポイントをマッピングし、気になることについて記入した。その後グループに分かれ参加者同士で自己紹介を行い、記入したことについて話しあった。お互いにどういった点が気になるのかを確認することができ、他の参加者の答えでさらに気になる点が増え、本会に対する期待や感心を各々で確認することができた。

S1)基調講演＋レビューワーク
「現在のレビューに必要な次の一手を把握するレビュー実践ウォークスルー」
安達 賢二 （HBA　Quasol）

「今日はレビューについてみんなで一緒に歩いてみようという意味を込めてウォークスルーという表現にした。」という言葉から基調講演が始まった。事前アンケートの結果を分析して、安達氏の経験からどの現場でも困っている3つのポイントに絞って説明をした。

・ポイント1．レビューの開始基準

レビュー対象の品質が悪いと検出率も悪く時間がかかる。構造化と分類化がなされていれば、検出率もあがり時間も短縮できる。そこでレビュー対象は最低限ものを作っておいてもらい、それもできない場合は、きちんと方針を決めて解決してもらう。
　またレビュー対象を見たときに、欠陥が頻発する場合はセルフチェックを促すために差し戻すか、レビューはせずにレビュー依頼者と相談の時間とする。

・ポイント2.　レビューの目的・観点

レビュー依頼者がレビューして欲しい目的や観点をその場で言えるか尋ねている。目的がはっきりと言える依頼者は大変少なく、できたとしても抽象的なことである。そのくらい目的を考えるのは難しいことである。
ここで、ワークを行い立ち位置を変えると観点も変わるということをまず参加者が実感することができた。その出した観点は粒度もバラバラになっていることが分かり、観点を体系化していくと、目的がはっきりしてくることがわかった。

・ポイント3.レビューの効果、効果を評価する方法

レビューの効果が実感できないとモチベーションが下がってしまう。レビューの効果を評価する方法はメトリクスを使うなど方法があるが、大事なのはレビュー結果を（例えば工数節約の視点で）評価し、短時間で振り返りを行うことである。記憶が新しいうちに振り返りを行うことで、高い効果が期待できる。レビューの評価が自分たちで実感できるようになると次のレビューのモチベーションになる。

限りある時間の中で、ドキュメントレビューの全体像がとてもイメージしやすく構成されており、その中でも3つのポイントについては深く説明するなど、レビュー初心者にとっても、普段レビューをしている人にとっての再考の場としても非常に有意義だった。より多くの人に聴いてもらいたい講演だったと思う。

S2)事例発表

事例発表では3名とも身近で起こる実践しやすい内容であった。松尾氏と村上氏の話は筆者の現場ですぐ適応できる内容であったし、根本氏の話はあらゆる場面で試してみたい内容であった。

「改善をより効果的に回すためのレビューへの取り組み」
松尾 和昭（クックパッド）

クックパッドではコード管理にGitHubを使い、プルリクエストを出すとチェック項目を自動的に表示させる仕組みを作成。これにより公開前に最低限の品質を開発者自身で確認することができるようになった。情報を分散させずに通知する仕組み作りを行い、人の負荷を下げることが大事である。

「効果的なレビューの運用について」
村上　正則（仙台ソフトウェアテスト勉強会）

レビューをするのに時間がかかるのが、レビューミーティングのための時間調整や議事録を作成する時間、大量のドキュメントを見る時間。手軽にレビューができるように、時間がかかる対面レビューをやめ、Redmine上でのレビューをするように変更した。また、ドキュメント修正にリポジトリ・リビジョンのコミットログが残るようにしている。

「達人の指摘から学ぶレビューのポイント」
根本　紀之（仙台ソフトウェアテスト勉強会）

達人（ドメイン知識があり、レビューで指摘をたくさん出せる人）の指摘から、レビューの観点とキーワードをマインドマップで作成した。

• 観点：自分が次回指摘できるような抽象的なワード
• キーワード：開発ごとの特有の機能、機能ごとの繋がりや関連、重要な設定などの具体的なワード

この分析により、自己レビューで活用する時の助けになった。ドメイン固有の問題は達人に聞くことで少しずつ自己学習する。

S4)招待講演＋レビューライブ
「ライブコードレビューで学ぶ！「納品のない受託開発」を支えるコードレビューの取り組み」
倉貫 義人（ソニックガーデン）
西見 公宏（ソニックガーデン）

倉貫氏はソニックガーデンで実践している「納品のない受託開発」について説明した。通常の受託開発では受注している側は納期がゴールとなってしまい、発注側のゴールであるビジネスとずれてしまう。常に変化するサービスに対応できるように定額制で納品の必要がない受託開発を実現した。
その中の取り組みの一つに「ドキュメントを作らない」というものがある。仕様はコードが全てとしている。コードを常にクリーンな状態にするため、コードレビューを行い仕様追加や変更に備え、コードの品質を保つようにしている。
コードレビューはGitHubのプルリクエストで行い、エンジニアはテスト駆動開発（TDD）を行っている。不具合を出さないことよりも、不具合を見つけた先のプロセスを大事にしている。

レビューライブ

数名の参加者に共通課題（テーマは券売機）のプログラムを提出してもらい、西見氏がコードレビューを行った。西見氏は的確にプログラマーのコードの癖を見抜き、より可読性があるのはどちらか、DRY（※1）になっているか、YAGNIの原則（※2）に沿っているかを指摘した。プログラムを提出した参加者と意図を探りながらどちらがよりよいコードなのかを確認し、共通認識を作っていることがよく分かるライブとなった。

※1）：DRY・・・Don't repeat yourselfの略。同じ意味や機能を持つコードを重複して置くことをなるべく避けるべきとする考え方。

※2）：YAGNIの原則・・・You ain't gonna need it.の略。機能は必要となるまで追加しないのがよいとするエクストリーム・プログラミングにおける原則。

振り返り

最後にアイスブレークで書いた内容の振り返りを行った。クロージングセッションはJaSST'15 Tohoku実行委員の村上氏。レビューは教育にも役立てることが理解できたのではないか、小さいところから是非活用していただきたいと本会を締めくくった。

まとめ

本会を通してオープニングのアイスブレークで参加者全員が本会のゴールを設定でき、クロージングで参加者自身のフォローアップまでできる一貫性のある会だった。
ドキュメントレビューとコードレビューがあることで、普段コードを見ることがない人にも、レビューの勘所がわからなかった人にもお互いヒントが得られたのではないだろうか。
本会が終わったあとの情報交換会でもドキュメントレビューとコードレビューのグループに分かれてトークセッションが行われ、最後までとても有意義であった。
筆者は普段レビューをすることもコードを書くこともないのだが、本会にてレビューについて幅広く知ることができ、ライブではピンポイントで具体的なレビューを見ることができ大変満足な会であった。