はじめに
2018年12月14日(金)にJaSSTが開催するJaSST Review'18に参加してきました!
この記事はその感想の前編になります。
詳細はこちら。
JaSSTソフトウェアテストシンポジウム-JaSST Review'18
JaSSTの説明については「オープニングセッション」で説明されていたので、 そちらを参照のこと。
目次
感想
シンポジウム中にメモした内容と、
ここがよかったなぁと思ったことを書いていこうと思います。
結構な量をメモしたので長いです…。
目次から気になるところだけどうぞ。
他の方の感想はTwitterのハッシュタグにて。
聴講者の方からの質問に対して登壇者が回答をしてくれているので併せてどうぞ〜。
#jasstreview hashtag on Twitter
諸注意とオープニングセッション
JaSSTに参加したことある人は、半数以上はいた感じ。
資料にちょいちょい出てくる、ブロッコリーについて。
JaSSTの実行委員長である風間さんが、
Twitterではブロッコリーなので資料に出てきているw
JaSSTの説明
自分含めこれがキッカケで知った人もちらほらいる。
JaSSTはJapan Symposium on Software Testingの略。
日本語に訳すとソフトウェアテストシンポジウムとなり、
ソフトウェアのテストに関するシンポジウム(研究発表会、討論会)を開催する団体となる。
JaSSTはASTERが母体であり、
ASTERはNPO法人ソフトウェアテスト技術振興協会のこと。
このASTERがソフトウェア業界全体のテスト技術力の向上と普及を目指して開催しているシンポジウムがJaSST。
次回、関東で開催されるシンポジウムは3月の東京。
ソフトウェアとレビューの関係性
JSTQB（Japan Software Testing Qualifications Board)では、
テスト技法のひとつとしてレビューが紹介されているらしい(原典が見つからず…)
テスト技法のひとつとして紹介されているが、
いままでのJaSSTでレビューを題材にしたのは6/240ほど。少ない。
なのに今日は満席!
ということは、みなさん普段からレビューをやられているが、学びたいと思っているニーズも強い、ということ。
実際に事前アンケートの結果を見てみると、機能設計、コード、テストケースレビューについて、
それぞれにそこそこ参加している様子が見て取れる。
レビュードキュメントのリーディング技法
- CBR(Checklist-Based Reading)： チェックリストベースでドキュメントを読む技法。
- DBR(Defect based reading)： 固有の欠陥タイプごとにドキュメントを読む技法。
- UBR(Usage based reading)： ユースケースごとにドキュメントを読む技法。
- PBR(Perspective based Reading)：ステークホルダーごとにドキュメントを読む技法。
- その他
どれか1個だけ導入するというよりも、
レビューによって、ケースバイケースで組み合わせている。
実際、となりの人も複数あげていました。
またドキュメントだけでなく、開催形式も体系化されている。
事前アンケート結果について
担当業務について 組み込み、業務系、Web系で1/3ずつほど。
他ゲーム、パッケージなど。参加者の年齢。 20代前半、30代半ばが一番多いけど。
だいたい同じくらいの割合かなぁ。レビュアー、レビュイー、統括者 7:3くらいでレビュアーが多い印象。
統括はレビュイーより少ないくらいの経験数。
目的
レビューという共通言語に対して、どのように捉え方や普段の取り組み方がが違うのか。
普段、様々な環境で開発をされている方をお招きして、
これらの違いを感じていただくためのシンポジウム。
違いを感じた上で、実は本質的な部分は同じはず。
このあたりも確認していきたい。
まずは事例紹介を通して違いを知る。
そこから本質まで行けたらいいなぁという話。
今回セッションに関してテーマ選定の経緯
日立製作所 白水 俊治 氏「設計レビューで問題を叩き出せ！～QAの役割～」
上流工程のレビューについて。
重厚な開発でのレビュー。グロース・アーキテクチャ＆チームス 鈴木 雄介氏「アーキテクチャのレビューについて」
重厚とagileの間。
エンタープライズアジャイルの場合について。
設計レビューで問題を叩き出せ！～QA の役割～ 日立製作所 白水(しろうず)さん
資料は公開されてないようで見つからず…。
重厚な開発の話、ということで基本的にWFにて開発している日立製作所の事例。
白水さんのレビューの立場としては、
部下の言動をみて指摘する立場。
発言しなさいとか…よく言っている。
そしてうるさく思われているw
品質課題
開発するシステムは様々な用途に用いられるため、
それぞれに求められる品質の幅がある。
しかし、高い品質の維持は必須。
またそれ以外にも課題として、
重い開発ルール、厳しい短期開発、急な開発手法変更などがある。
WFメインの現場だけど、
目まぐるしく変わる市場で速度重視の開発もしなければならなくなっている。
部分的にアジャイルの考えを導入しており、
それらに対する品質の考え方や指標とWFの場合とですり合わせが難しいなどの課題もある。
レビューの基本
テストは書いてある通りに動くことを確認すること。
レビューは書いていない事を見つけるために行うこと。
仕様書に書いてないことのテスト項目は2割しかない。
しかし、書いてないことで発生するバグの方が多い。
これは気づいてないからテストしない、という背景がある。
レビューアも気づいてないから指摘できない。
つまり、気づかせるための工夫が必要。
ルールやチェックリスト類が多くなる。
問題は後半で表面化する。
そのため、設計書はしっかり作成、レビューを繰り返し確認する。
設計書はルールに乗っ取っていろいろ作る。
レビューは責任ある役職者が出席してチェックする。
こうしたレビューやルールが多くなるため、
キチンとできたかを確認するチェックリストも多くなる。
また、過去から引き継いだチェックリストもたくさんある。
(古いシステムはそういった古いチェックリストがたくさんある)
気づく、書いてもらうためにはどうすれば良いか?
現物確認至上主義！
設計書やテスト仕様書はQA自らの目で確認する。
実際に開発された製品も同様。顧客対応スペシャリスト！
現地や顧客先で問題があればQAが出向いて対応にあたる。
この現地作業での知見を開発現場に持ち帰ることで、
品質向上に役立てる!開発部門と独立組織！
開発と別の、独立した組織にすることで、
レビュー中の忖度や、品質が確認できない製品の出荷を食い止める。
ここで、開発とQAが別れている組織体系について一言。
開発とQAが別れていることによってメリットもあると思いますが、
必ずしも協調できない場合がありました(似たような組織で経験済み)
それは開発もQAもルールを守るのが最優先になってしまう(手段が目的になる)場合です。
そうすると品質ではなくルールを守るのが目的になり、
協調できない時が多かったと思います。
例：ルールだからあのドキュメントを出せ(それによって品質が上がるかは無関係)など
それと現場にいくQAの話についてもひとつ。
これはできるなら開発部門の人間も現場に行った方が良いと思っています。
白水さんは現地で障害対応をすると大変なので、
そうならないように開発現場に伝える、開発現場で品質をあげる努力をしているとおっしゃっていました。
私が昔いた現場もユーザーからの声が直接届かない開発現場だったので、
どこか危機感が薄かったと思います。
逆に直接ユーザーさんとやりとりしている現場はいい意味で緊張感がありました。
そのため、できれば直接、難しければ間接的にでもユーザーの声を定期的に届けた方が良いと思います。
白水さんのお話を聞いて、QAにユーザーの声が伝わっているのは心強いと思いました。
ここまでのまとめ。
- 自分で確認することによる「品質の責任感」
- 顧客対応することによる「品質への危機感」
自分で気づく、他人に気づかせることの重要性。
顧客からのフィードバックを開発現場に伝える、生かす、危機感として持つ。
具体的な開発フローについて(イメージ)
典型的なWF開発。
開発とQAが別部門なので、製品をやりとりしながら開発を進めていくイメージ。
QAの検査時は開発のテスト結果(エビデンス)をみて、ＯＫなら検査の受け入れをする。
この時点でNG(テスト項目不足とか不良件数の過不足など)なら検査の受け入れはしない。
検査を受け入れたらQAがテストする。
QAの検査でも開発となんどもやりとりを行う。
問題なければ出荷される。
最近はレビューを支援するツールを導入して効率化した。
いままでは顔を突き合わせてレビューしていたが、集まりが悪かったりで無駄が多かった。
そこで電子でレビューを行うようにしたことで非常に効率が高まり、
資料の閲覧時間をなどを確認することでレビューの品質向上にも役立てている。
感想
途中にも書きましたが同じような組織体系でWF開発をしている現場にいたことがあるので、
開発者の視点からもわかりみが深いなぁと思って聞いていました。
個人的に、QAから開発に気づかせること、
そしてQA内でも常に新たな気づきを考えることで品質を向上させようとしているのが印象的でした。
加えてどんなに大量のドキュメントやPCLを用意しても、
たくさんのレビュワーが参加しても、
不具合はなくならないという現実があります。
それでも現地で致命的なエラーが起こらないように開発や検査時に確認をしたり、
すぐ復旧できるように運用面でも手順などを考慮しているのが素晴らしい知見だと思いました。
いろいろ悩みながらも、よりよい開発やQAによるテストを目指して工夫されているのが素晴らしいですし、
比較的、自由にやれる規模の自分たちももっと工夫することができるなぁと思いました。
レビュー再定義 楽天 及部さん
資料はこちら。
冒頭のmentimeterを使用した動的なアンケート
mentimeterという来場者に動的にアンケートを取るところから開始。
これは聴取者が指定されたURLを開くと登壇者が設定した質問が表示されます。
この質問に答えると登壇者のページにその答えが表示されるようになっています。
3択では棒グラフなどのグラフ表示、自由記述では記述した内容が画面に表示されます。
この自由記述では複数の聴取者が同じ言葉を入力するとそれが大きく表示されるので、
回答数が多い内容は視覚的にわかるように表示されます。
初めてこのツールを見たのでとても驚きましたが、非常に面白い楽しいツールだと思います。
ぜひとも真似していきたい所存。
レビューの目的
当日のmentimeterで「あなたにとっての/あなたの考えるレビューの目的は何ですか?」という質問がされていました。
結果は上記資料の5ページにありますが、だいたいみんな同じような感じ。
もっとも多いか回答は品質向上でダントツ。
他の回答もバグを検出や不具合を防ぐだったので、品質関係が多い結果でした。
次点は教育のためということが多かったと思います。
及部さんは検査(Must)、強化(Will)、学習(Should)の3つに分類できるかなと。
このうち強化は長期的な意味のリファクタとか、今やらなくても良い系。
レビューの辛いところと、ではどうしていきたいか?
レビュー時にコミュニケーションに時間が取られる点。
特に、変数名などのコーディング規約のような点に時間が取られてしまい、
本来の目的である品質の話にいくまでに時間かかかってしまうのが辛い。
またエンジニアとしてスキルアップしていくとコード書く時間が減っていく。
レビュー観点でいえばレビュアーとしてレビューする時間が増えていく。
なんかツライ。
自分たちがやりたい、もっとわくわくするレビューをやりたい。
今日はもっとわくわくするレビューのアイディア。
モブプロでレビューは不要になった話
レビューをやらなくてよくなった話。
モブプログラミングだとタスク前後の同期作業が不要なので、レビューがいらなくなった。
分担作業では必要なタスク前後のレビュー(や意識合わせ)がモブでは不要ということ。
レビューにおける忖度。
「これは今は言わなくていいかなー」とか、
「些細なことだからいっかー」みたいなことがなくなる。
モブでは分担作業に比べて手戻りがない分フィードバックをしやすい、反映しやすい。
モブプロで学習する場合のメリットは以下の通り。
- 新人や新メンバーの受け入れに向いている。
- 経験値が低い人をドライバーにすると良い。
- ドライバーなら手を止められる。
- 聞く機会を自ら作れる。
モブでは暗黙知も伝えやすいという話。
よく暗黙知を形式知にという話があるが、形式知にしようと思ってもできない。
できたらそれは暗黙知ではない。
だから、共通体験として伝えれば良い。
そのため複数人で同じ体験が得られるのはモブプロのメリットのひとつ。
モブで不要になったレビューがやっぱり必要になった話
振り返りに近いレビューが必要になった。
最初にあげたレビュー目的の検査、強化、学習でいうと、強化の部分。
以下のようなことをレビューする。
- 今日の自分たちの仕事は最高だったか?
- ここからもっとよくできるのか? それはいまやるべきか? やりたいのか?
- 次にどういうことを学ぶべきなのか 学びたいのか?
Re・View
いままでのレビューは、レビューの場で初めて成果物を見ているレビューだった。
たとえば設計レビューやソースレビューでは、レビューの場で初めて成果物を見ていた。
つまりFirstViewだった。
初めて見るので、理解するコストが発生する。
モブによるリアルタイムレビューと時間を空けてのレビューはメリデメがお互いが補完関係なので、
モブのあとに別時間で振り返り的なレビューをする。
レビュー再定義
完璧にやらなきゃいけないという幻想から脱却する。
自分たちにできること(ROI)をやる。
失敗してもそこから学んでいけばいい。
情緒を大切にする
人間であることを楽しむ。
楽しいと楽しくないのインパクト。
いま楽しくないなら楽しくする工夫をするとか、やめるとか。
質疑応答
Q.モブプロを始めたキッカケと続けている理由
A.ゴールデンウィークの谷間にお試しで始めたみた。
良かったので続けている。
Q.実際に振り返りをしてみて良かったことはありますか?
A.お客さんとやってみて
向こうが勉強しなきゃなと言ってくれたこと。
あとは普段の仕事の話なので忘れた。
(暗黙知は暗黙知のまま共有されているんだろうなぁ)
Q.モブプロで新人のドライバーの頻度。
A.少し多めにするくらい。
顔色や声音でリアルタイムにフォローできる。
Q.ツライ仕事が多いので、仕事を楽しくなるコツを知りたい。
A.ツライことを減らす工夫とかよりも、
たんにやってみるだけ。
意外とやれることは多い。
本当にダメなやつはダメと言われるのでやめれば良い。
他にツールを用いて募集していた質問はTwitterで回答されていました。
気になる方は以下からどうぞ。
#jasstreview hashtag on Twitter
感想
普段なにげなくやっているレビューを考え直す非常に良いキッカケとなったセッションでした。
普段モブ(最近はペアですが)で開発をしている私にとっても、
振り返りのようなレビューを行うという知見は有意義でしたのでさっそく試してみています。
また個人的に、つい言葉の定義にとらわれて本質を見失いがちなので、
それは本当に必要なのか?自分たちやチームにとって価値があるのか?ということを、
問い直す、そして今後も問い続ける良いキッカケとなったと思います。
今回で言えば、"自分たち"は何故レビューをするのか?
レビューで"自分たち"が納得する目的を達成できているのか?
"自分たち"は楽しくできているか?
などを見直していきたいと思いました。
毎回、及部さんのセッションやお話で新しい気づきを得たり、
自分の固定観念を見直すキッカケとなるので、
毎回楽しみに、そしてワクワクして聞かせてもらっています。
この発見を持ち帰ってチームに伝え、
またそこで得た気づきをアウトプットして分かち合っていきたいと思います。
続きは後編で
長くなったので分割します。 この続きは後編で…。
