はじめに
2018年12月8日に、ソフトウェアレビューのシンポジウムである「JaSST Review」が東京で初開催されました。本記事はJaSST Review'18でどのような方々をお呼びして、どのような発表になったのかを紹介します。
今回のJaSST Reviewの狙い
前回の記事に書いたとおり、一言に「レビュー」といっても、皆さんが思い描くレビューは十人十色です。そのため「レビュー」の取り組み方はバラバラな現状があります。
そこでJaSST Reviewでは、分野が異なる以下のお三方を、発表者としてお招きしています。
JaSST Review'18は下記の3名に発表をお願いしました。
さらに、このお三方をパネラーとして、パネルディスカッションも行いました。「レビュー」という共通の単語に対して、どのように捉え⽅・普段の取り組み⽅が違うのか、もしくは同じなのかを感じる内容を⽬指しました。
また、「レビューミーティング（以下、レビューMTG）の運営方法」「プロセスの中におけるレビューの設置方法」などといった管理面の話は極力対象外にしました。一方で、「どのような思考をもってレビューに取り組んでいるのか」「レビューの指摘内容はどのようなものか」といった技術面の話を中心に発表をお願いしました。
当日の内容
前回の記事で、どのような狙いをもって準備をしたか書きましたが、当日は狙い以上のお話を伺うことができました。
それぞれの発表でもともと依頼していたこと、期待していたこと、実際の発表で得られた予想外のお話を紹介していきます。
なお、本記事を読む際にはJaSST Review レポートページも参考にしてください。
www.jasst.jp
依頼内容
リリースまでの期間が長い、重厚な開発プロセスでのレビューについてお聞きしたいと思い、白水様に講演を依頼しました。品質を重要視されている日立製作所さんならではの取り組みや思考が聞けると期待しました。
予想していた発表内容
上流の品質を確保するようなレビューをより重視しているのではと予想しました。
リリースまでの期間が長い場合、テストなどの実装後工程で不具合が散見されてしまうと修正コストが非常に高くなります。
高くなるコストを防ぐ一つの方法として、レビューがあると考えました。
実際の発表内容
発表資料は下記です。
設計作業が全体の作業の約5割を占めているというデータから、レビューを重要視されていました。特に大切にしていたことは、各工程でのレビューを繰り返し実施し、工程間（例：機能設計書と詳細設計書）のズレが発生していないか確認することです。
さらに工程以外にも、レビューの位置づけとして「書いてない事を見つける」という考えを持っていました。これは、社外発生不具合の86％は仕様書に記載が無かったというデータから、書いてない内容を見つける目的を重要視していました。
設計レビュー時に気を付けていることについての紹介もありました。
まず、レビュアーが自ら気付くようになるために、「俯瞰する」「先見する」「想像する」の3つを大切にしていました。
- 俯瞰する…対象機能だけでなく連携する機能についても考える
- 先見する…その機能が動いた瞬間だけでなく使い続けた将来はどうなるのか考える
- 想像する…レビューイが想定していなかった使い方をした場合にはどうなるのか考える
レビューイだと対象物のみについて考える狭い思考になりがちです。ここで挙げた3つは、どれもレビューイとは違う視点を持つためのポイントでした。
これらの話は、レビューを大切にしていると予想して講演依頼した私にとって、しっかりとデータや文章にして表現してくださったので非常に参考になりました。
楽天株式会社 及部様
依頼内容
Agile開発でのレビューについてお聞きしたいと思い、及部様に講演を依頼しました。最近盛り上がりを見せている、「モブワークでどのようにレビューが行われているか」を特に聞きたいと期待していました。
予想していた発表内容
「レビュープロセス」が存在しないモブワークで、実はレビューと同じような会話をしているのではと予想しました。
また、純粋に指摘についての話が聞けるのではないかと予想しました。レビューの発表といった時には、よくMTGの参加者構成など、どのようにしてレビューMTGを開催するのかという話になりがちです。ただし、モブワークの場合はレビューMTGが存在しないため、レビューMTGの形式について議論する余地がないと考えました。
実際の発表内容
発表資料は下記です。
speakerdeck.com
レビューMTGだと「設計上は良くないけど、忙しいだろうし、動くから今はとりあえずこのままでいいか」「今回は指摘が多いから、これ以上の指摘はやめよう」といった忖度が発生するというお話がありました。
逆にこのような忖度が発生しないようなレビューになれば、価値のあるものになると感じました。
また、「モブワークはチーム全体の活動である」という話も印象的でした。チーム全員で立ち向かってダメなら仕方ないという考え方です。また、暗黙知を無理に形式知化させるのではなく、暗黙知は暗黙知のまま共通体験で伝えるようにしていました。これもモブワークがチーム全体の活動だからこそできることかなと感じました。
一方で、モブワークの中でもレビューが必要になってきた、という話は予想外でした。
必要となったレビューは設計レビューのようなものではなく、自分たちの仕事の成果を自分たちで見直すためのレビューでした。
その中で、レビューという言葉を改めて考えるという話がありました。レビューは「Review」というスペルです。つまり「Re（再び）view（見る）」からレビューなのです。一方で、普段行っているレビューは「Re view」ではなく「First view（初めて見る）」になっているのではないか、という発表でした。この発表は、レビュアーはレビュー時点で初めて対象物を見ることが当然だった自分にとって、シンポジウムの中で一番の衝撃でした。
グロース・アーキテクチャ＆チームス株式会社 鈴木様
依頼内容
アーキテクト観点でのレビューについてお聞きしたいと思い、鈴木様に講演を依頼しました。特にAgile開発では、コード中心のレビューになることが多いと想像しており、もっと基盤寄りのアーキテクチャの話を聞く機会が重要だと考えました。
予想していた発表内容
アーキテクチャは開発をする上での最上流工程だと考えていました。なので、そのようなまだ開発方針も定まりきっていない状態での物事の決め方が聞けるのではないかと予想しました。
実際の発表内容
発表資料は下記です。*1
www.slideshare.net
アーキテクチャの良さは非機能で判断する必要がある、というお話がありました。非機能要件は「こうあるべき」という絶対的なものがありません。それを見るためには、工程完了の確認のためではなく、相談に乗る形でレビューに参加することが多いようです。
また、バランスが取れた判断も考えていました。アーキテクチャ設計が100点満点になることはありえません。そこで、松竹梅の複数プランを示して、落とし所を決めることを重要視していました。
アーキテクチャ設計レビューの難しさも話していただきました。
アーキテクチャ設計は常に事前的であるため、将来性が考慮されているかも重要です。その将来性を考えた上で、どのようなリスクがあるか、そのときにどのようにしてリスクを回避するかを考えていました。
その中で、「◯◯については今は考えない」といった情報も記録に残すように心がけていました。記録に残さないと、「意図的にその時点では考えなかった」「そもそも考慮していなかった」のどちらなのか、将来的に分からなくなるからです。
今回はアーキテクチャのレビューについて話してもらいました。ただし、最上流工程だからこそ難しさが顕著になっているだけで、話していただいた内容はすべてのレビューに当てはまる考え方のように感じました。
おわりに
本記事ではJaSST Review'18での発表内容について紹介しました。
JaSST Review'18の様子を読んで、「面白そう」と感じた方は、11/1開催のJaSST Review'19にもぜひ参加してみてください！
違った方向で新たなレビューに対する考え方を得ることができるはずです。
jasst.jp
