kdnakt blog

hello there.

#JaSSTReview で振り返るソフトウェアのレビューの話とか

2018年12月14日(金)に開催されたソフトウェアレビューシンポジウム「JaSST Review'18」に参加したので、参加レポート的なものを。

少し間が空いてしまった……。

 

JaSSTソフトウェアテストシンポジウム-JaSST Review'18

[2018/12/22追記]

JaSSTソフトウェアテストシンポジウム-JaSST Review'18-レポート

[追記ここまで]

 

 

[何で参加しようと思ったか]

ブロッコリー委員長

という感じ。

 

あとは登壇者に及部さんのお名前があったのも大きい。 

 

ブロッコリー氏と及部さんチームにお邪魔した時のレポートはこちら。

kdnakt.hatenablog.com

 

……というのは半分本気、半分冗談で。

 

■レビュアはどう振る舞うべきか

3~4年くらい前に、設計レビューの本(下記リンク参照)を買って読むくらいにはレビューに興味があった。改訂版の発売日を見ると3年前なので、改訂版になる前の原著の方だったかもしれない。 

なぜ重大な問題を見逃すのか? 間違いだら けの設計レビュー 改訂版

なぜ重大な問題を見逃すのか? 間違いだら けの設計レビュー 改訂版

 

 

当時は、ちょうどレビュアの立場でレビューに参加するようになってしばらくたっていた。

 

自分がレビュイーとしてレビューに参加した経験は当然あったものの、自分の考えを説明したりレビュアからの指摘を吸収しようとしたりするので精一杯で、レビュアとしてどう振る舞うべきかは悩ましい問題だな、と感じていた。

 

そして、今も、似たようなことに悩んでいる。その辺りが参加のモチベーション。

 

[参加して何が分かったか]

■S0. オープニングセッション

ブロッコリー氏登場。オープニングセッションだが25分かけて、初開催となる「レビュー」をテーマとした本イベント開催の経緯について説明があった。

 

テストの認定資格であるJSTQBでも、静的技法の一つとしてレビューが挙げられているが、過去3年間のJaSSTのセッションの中で、レビューをテーマとしているのは240セッション中わずか6セッションのみ。なかなか事例が出てこないので、今回の開催に踏み切ったと。

レビューと一言で言っても、機能設計レビュー、コードレビュー、テストケースレビューと多様で、今回の参加者の属性も組込系からWEB系、開発者からテストエンジニア、レビュアもいればレビュイーもいる。そのレビューに関する経験や思考が、本質的には同じ部分があるのでは?という問いが背景にある、と。

 

■S1. 設計レビューで問題を叩き出せ!~QAの役割~

こちらのセッションは資料公開はなさそう……残念。ただ、関連する書籍として、下記が紹介されていた。

[2018/12/22 追記]

JaSSTのHPにて資料が公開された模様。

http://www.jasst.jp/symposium/jasstreview18/pdf/S1.pdf

[追記ここまで]

 

QA、品質保証部門の立場からのレビューについての発表。硬めのウォーターフォール型開発で、Wモデルを活用していて、QAが製品出荷にノーと言う強い権限を持っている現場のお話。

 

QAという言葉から受けとる自分のイメージとは異なり、普段の業務ではトラブル発生時に客先での顧客対応も行なっているらしく、そうしたトラブル対応の現場での知見などを社内に持ち帰り、レビューに生かしているとのこと。

 

レビューとはちょっと話がずれるが、「探針(Quality Probe)」の話が印象的だった。開発テストの終盤で、QAテスト項目を先行評価し、見直し観点や品質向上案の提示に加えて、開発プロセスの改善案や残存不具合数の推定値を提示することもあるらしい。

 

設計レビューのポイントとしてまとめられていたのは次のような内容だった。

  • 俯瞰し、想像する思考力
  • 勝手な自己解釈で忖度しない
  • チェックリストを過信せず、定期的に見直しを

 

 

■S2. レビュー再定義

 

及部さんのセッション。Mentimeterを使ったインタラクティブな始まり!

www.mentimeter.com

 

モブプログラミングを導入して、成果を同期するためのレビューは不要になったのでやらなくなっていった、という話が前段。

改めて感じたのは、モブプロによって、リアルタイムでフィードバックが得られるようになり、かつ、チーム全員が合意したアウトプットが出来上がるので、レビューの場だと生じうる忖度や遠慮が極小化されるというのは本当に良いと思う。

 

と、この辺までは、Speaker Deckに上がっている及部さんの過去の資料でもうかがい知ることのできる内容。しかし、本セッションのオリジナルな内容として、「やはりレビューは必要だった」という内容が続いた。

モブプロとは、という説明のスライドに合わせて、トラブル対応の時のチーム総力戦を普段の仕事に持ち込むようなものだ、と及部さんが説明されたのが思い起こされる。つまり、一時的な場の盛り上がりで問題を解決して終わり、とするのではなく、もっと良い方法はなかったか、諦めた問題があったとして次に何を学ぶべきか、といった振り返り(=レビュー)こそが必要だったのだ、と。

 

「人間らしいレビューが大事」という最後のメッセージが印象的だった。

 

■S3. アーキテクチャのレビューについて

www.slideshare.net

 

最近アーキテクチャ関連の仕事をすることが増えたので、実は気になっていたセッション。

 

アーキテクチャのレビューは常に事前的であるがゆえに難しい、というのが印象的だった。ソフトウェアの開発テストが完了してからアーキテクチャのレビューをしても、遅すぎるから、事前にやる必要があるのは当然だが、何もソフトウェアが無い段階でやらなければいけないので、当然難しい、と。

 

レビューのポイントとしては、非機能要件の抽出と、構成案の評価の2点が挙げられていた。 

 

非機能要件として、性能効率、可用性、セキュリティ、保守性、移植性などはなんとなく聞く前にぼんやりとはイメージできていたものの、使用性も観点に入ってくるのはちょっと意外だった。

 

構成案の評価については、技術的なリスクだけでなく、システムの成長リスクの観点を指摘されていた。成長を予測して先行したアーキテクチャにすれば、予測がずれて温泉旅館のような増改築を繰り返すことになるし、小さく作ってリリースすれば作り直しをすることになる。かといって、拡張可能なパーフェクトなアーキテクチャを目指すのは、JavaIDEとして一時代を築いたEclipseの開発者エリック・ガンマのような天才的なエンジニアでないと難しい。

この点についてあまり深く考えたことがなかったけれど、オーバスペックなものを作っても無駄なので、凡人の自分としては小さく作って必要に応じて捨てていくしか無いのかな、と感じた。

 

締めの「技術力ではなく、傾聴して整理し、正しい方向へ働きかける力が重要」という言葉が刺さった。

 

■S4. パネルディスカッション

[2018/12/22追記]

パネルディスカッション時の投影資料も公開されていた。

http://www.jasst.jp/symposium/jasstreview18/pdf/S4.pdf

[追記ここまで]

 

登壇した3名とオープニングセッションを務めたブロッコリー氏を交えて、パネルディスカッション。それぞれのセッションで発表した内容について、別の登壇者がコメントをする、という形で進んでいき、会場からの質問に回答する時間もあって良かった。

 

登壇者3名の共通点として指摘されていたのが、「レビューで言いたいこと/言うべきことは日和らず言う、忖度せずに言う」と言うポイントだった。

確かにこれは自分も覚えがあるし、せっかくレビュイーを育てソフトウェアを良くするチャンスなのだから、

 

レビューで指摘するポイントをどのように探すか、と言う点も共通していたように思う。「レビュイーを見て質問する」という部分。例えば、ドキュメントで曖昧な表現になっているところであったり、レビュイーが自信がないと思っている箇所を傾聴したり、反対に自信満々であまり考えていない部分に突っ込んだり。

 

会場から、レビューの目的達成をどのように判断するか、という難しい質問があった。

時間は常に不足しているので、目的が未達だと感じるなら課題として残すもよし、レビュー時間を伸ばすもよし、というのが一つ。また、レビューで課題が残ったとして、お客さんとトラブルになっていないか、というのが重要な評価指標になるという回答も。運用してみて感覚を掴め、ということと理解。また、レビューの最終目的は安心なので、ツールを使って、この人がこれだけ時間かけたならOKの筈、というのも一つの策としてありではとの回答もあった。

 

ブロッコリー氏からの、「レビューの専門家はいない、それぞれの得意分野活かしてレビューが盛り上がり、事例のアウトプット増えてほしい」というのは良い締めだった。

 

[今後どう活かすか]

チェックリストを定期的に見直しやることを減らす、はできていない気がするので取り入れたいところ。人力でやるのではなく、自動化とかで解決して、より重要な、より価値のあることに注力できるようにしたい。

 

振り返りをあまりできていないので、本当に最高だったか、次に学ぶべきポイントは何か、ということを振り返り、より強くなりたい。

 

特に今年後半、もっと技術力向上に注力したい、と考えてやってきたけど、アーキテクチャを考えレビューしそれを実現していく上ではソフトスキルというか、Fearless Change的な力も重要になってくるのは明らかなので、来年の目標の一つに加えたい。

 

JaSSTについては弊社からの参加者登壇者もちらほらいるので、前々から存在は知っていたものの、参加は今回が初めてだった。今回良い学びを得られたので、来年も機会があればどこかで参加したい。

 

[まとめ]

初のJaSST Reviewとても楽しかった。

実行委員のみなさま、ありがとうございました! 

 

今日のブログ執筆BGMはこちら。

www.youtube.com