NPO法人ソフトウェアテスト技術振興協会 イベント報告-JaSST Review'18
HOME > 活動報告 > イベント報告 > JaSST Review'18
2018年12月14日(金) 於 ワークスアプリケーションズ セミナールーム
JaSST Review'18 は今回が初開催である。筆者が会場に入ると、「本日は満席です」との案内が聞こえた。多くの技術者がレビューに対して高い関心を持っていることを実感した。
風間実行委員長から、JaSST Review は今回が初開催なので他の JaSST と異なりオープニングセッションに長めの30分を割り当てた、との挨拶があった。オープニングセッションの内容は以下のとおり。
レビューは、JSTQB では「静的技法でテストできる方法の一つ」として紹介されているが、ソフトウェアテストシンポジウムの中で少なからず発表があったものの、レビューを主眼においたシンポジウムは聞いたことがなかった。そこで、ソフトウェアテスト同様にレビュー分野もより発展させるべく、JaSST Review を開催することにした。
事前アンケートによると、製品分野については、組み込み系、業務システム系、WEB系が多く、ついでパッケージ製品と続く。役割は、品質保証、テスト技術者が多く、開発者、プロジェクトマネージャと続く。立場はレビューアが多かった。
様々な分野の方を講演者としてお招きすることで、「レビュー」という共通の単語に対して、捉え方や普段の取り組み方がどのように違うのか、感じていただきたい。
日立製作所の白水氏へは「重厚な開発プロセス」でのレビュー、楽天の及部氏へは「アジャイルやモブワークの観点」でのレビュー、グロース・アーキテクチャ&チームスの鈴木氏へは「アーキテクト観点」でのレビューについての講演を依頼した。
今回は sli.do を活用して、パネルディスカッションで使う質問を募集するので投稿をお願いしたい。テーマは「レビューに関する悩み」である。
実行委員長から、新しいシンポジウムを設立した熱い思いが会場に向けて語られ、以降のセッションに対する期待値が高まった。
白水氏は金融系企業に提供する基盤ソフトウェアの品質保証部門（QA）で品質保証を担当してきたとのこと。重厚な品質保証プロセスがあり、お客様からも高品質を求められているとのこと。近年は部下を育てることに従事しているそうだ。講演概要は以下の通り。
レビューは「書いていない事を見つける」ことと考える。仕様書に書かれていないところに問題は潜む。ある製品の分析では、社外発生不具合の86%が記載なし、検査摘出不具合の58%が記載なしという結果だった。よって仕様書のレビューでは、設計者自らが書いていないことに気付き、仕様書に書かせるための取り組みが重要である。人から暗黙知を引き出せるかどうかが、レビューの良し悪しを決める。
開発内容（設計書やエビデンスなど）について、QAは自分の目で確認し、製品は実際に動かして品質を確認する。処理方式まで踏み込んで確認する。妥協せず、安易に出荷させない。
サポート部門が対応できない難しい問題は自ら解決し、現地でのトラブル復旧支援、解決対応も行う、広い知識で顧客のシステム設計支援も行う。
品質活動に特化した全社組織であり、製品出荷の「最終障壁」と呼ばれている。担当者レベルでもNOと言える。
製品の品質を確保するためには「設計」「テスト」「品質」の三つの枠組みのレビューで対応する。設計レビューでは、開発者が気付いていない事、設計書に書いていない事を挙げる。テストレビューでは、テストでは確認できていない条件を探して検査観点に取り込む。品質レビューでは、品質計画通りの作業が行われている事を証拠物も含めて確認する。中身の分析を重視する。
設計レビューのポイントは「人事と人智を尽くす」ことである。レビューで重要な三大思考力として「俯瞰する」「先見する」「想像する」を挙げる。思考を変えるだけで知識不足を補うことが可能となる。
レビューアは日和らないことが大切である。たとえ指摘できなくても質問することが大切である。また、チェックリストを過信しないこと。チェックリストは英知の結晶だが、使い方を間違うと思考停止を招くことを忘れないようにする。
開発スタイルに合わせたレビューとテストの連携が重要と思っており、ウォーターフォール型開発にアジャイル的思考を加えた開発モデルを実践している。設計書を完璧に作成しない事によるリスクを、テスト強化・早期の検査評価で軽減する。重要機能は先に開発して機能単位にテストすることで、問題を早い段階で発見できる。
ソフトウェア開発は「人」が行う。品質への「責任感」「危機感」を持ち、他人と異なる視点や思考を大切にする「人」を育成することが重要である。
昔から日本を支えてきた製造業の品質保証部門として、品質の良い製品を市場に出す重い責任があり、そのための仕組みが長年かけて築かれてきたことが十分に伝わってきた。
及部氏は講演の冒頭で「本日は自分たちが実践しているモブプログラミングを紹介するが、みなさんに『ぜひやりましょう』と薦めることはしません」と前置きした。次に、menti.com というサービスを用いてリアルタイムに会場アンケートを行った。各自がスマホやPCからサイトに接続すると、画面に「あなたにとってのレビューの目的はなんですか？」「レビューは楽しいですか？」などの質問が表示されるので、意見を書き込んだり、回答を候補から選択した。その結果がプロジェクターに随時反映された。講演概要は以下の通り。
レビューの目的として、「検査（Check）」「学習（Learning）」「強化（Enhance）」が挙げられる。一般的にレビューの話をすると「検査」の話になりがちである。しかし、エンジニアとしてキャリアアップすると、メンバーの教育やレビューが増えるなど、自身がコードを書く時間が減っていくのはツライ。もっとわくわくするレビュー（＝検査だけでなく学習や強化の領域も含まれる）を考えたいと思っていた。そんなとき、モブプログラミングの経験を通して「もっとわくわくするレビュー」についてのアイデアが出てきた。
モブプログラミングとは、「チーム全員が同じ時間に同じ場所で１台のコンピューターでプログラミングすること」である。自分たちのチームでは、プログラミングだけでなく多くの作業を全員で実施している（モブワーク）。モブワークを始めてからやらなくなったものが色々あるが、そのひとつがレビューである。
分担作業とモブワークを比較してみると、分担作業は前後に同期のための作業が必要になるため、想像しているほど効率的ではない。この二つは二者択一ではなく、仕事や状況に合わせて使い分けている。
また、普通のレビューでは既に作成したものに対して指摘を行うため、相手のスキルや進捗状況に応じて指摘事項を変えざるをえないことがあり、ストレス源となる。モブワークの場合は、目の前の作業に対してリアルタイムで意見を言い合うため、忖度せずにチームの最善を目指すことができる。
「学習」の観点では、チームが学ぶ量の最大化を目指す。開発経験が少ない人には、ドライバーをやってもらうと良い。ドライバーには、わからない時に手を止めて教わる権利があるから。
モブワークでは、形式知も暗黙知もまとめて伝えることができる。特に暗黙知は、なぜこのように作ったのか、どこに苦労したのか、などについて共通体験を通して伝えることができる。
モブワークを実践してレビューをやめたが、モブワークの弱点を補完する意味で、新しいレビューの必要性を感じてきた。「検査」と「学習」についてはモブワークで実践できているが、「強化」が不足していると感じ始めた。自分たちの仕事の成果を自分たちで見直すことが必要と感じ始めた。最高の仕事ができたのか、もっとよくする余地があるのか、次に自分たちが学ぶべきことは何か、などを考える「ふりかえりに近いレビュー」の必要性である。そこで、毎日夕方15分間をその時間に充てるようにした。
レビューは Re-view と書くが、実際には First-view であることが多く、理解するためのコストが発生する。他人の思考・仕事を後から理解することは難しい。モブワークは一緒に作業するため、そのコストは不要である。
モブワークとレビューは補完関係にあると考える。例えば、モブワークでは、その場の熱によって誤って判断したり、局所最適になる可能性があるが、レビューでは異なる場所とタイミングで成果物を観るため、冷静に全体最適を考えることができる、などである。
自分たちに合ったレビューを再定義してみてはどうか。レビューの強みを活かしているか、レビューではないプロセスの方が解決しやすいことはないか、などを考えてみよう。
やらなくてはいけないことは多いが、リソースは有限である。完璧にやるのではなく、最善を尽くすこと、失敗から学ぶこと、変化に対応することを重視しよう。
情緒を大切にしよう。完璧ではないけれど成長することができることを楽しもう。人間らしいレビューを目指そう。「あなたのレビューは楽しいですか？」
冒頭で実施したアンケート項目のひとつ「レビューは楽しいですか？」が、とても重要なメッセージだったことに感激した。
鈴木氏からは、近年クラウド利用などでシステム構成が複雑になるに従い、アーキテクチャ設計の重要性が高まっており、本日は非機能に注目したアーキテクチャレビューについて紹介された。講演概要は以下の通り。
アーキテクチャは、システムの要素と統合の方針である。特に、将来的な変更に対してどのように対応するか、を示すことは大切である。
現代的なシステム開発では、機能を実現する手段がたくさんあるため、なるべく作らず、既存のものを組み合わせる。進化が進むとマイクロサービスアーキテクチャになる。
アーキテクチャの良し悪しは、非機能で判断する。他システムやクラウドは、性能やセキュリティを司るものが向こう側にあるため、こちらで想定していたものとズレが生じやすい。非機能が保証されないと、大規模な障害発生の原因となる。例えばピタゴラスイッチのような、部分的に問題が発生すると全てが止まってしまうようなアーキテクチャでは困る。
アーキテクチャの設計工程でレビューを適切に行うことが大切である。ビジネス要件が求める非機能要件を定義した時点と、アーキテクチャの構成を評価する時点でレビューを行う。
非機能を定義する際には、経産省などから提供されているセットがいくつかあるので、自分で使いやすいものを決めておくと便利である。
「機能適合性」については、ビジネスチームからの要件に対して、なぜその要件が必要なのかを確認することが大切である。「すぐに」「早く」「確実に」などのあいまいな表現には注意が必要である。
「性能効率性/可用性」については、クラウド/仮想化によって柔軟になり、この10年で変化した。キャパシティプランニングは時間軸を意識して考えると良い。
レビュー観点として重要なことは、ステークホルダーの意見が整理されていることを確認することである。この時点では、矛盾や不可能性は許容し、残しておくことが大切である。構成案は可能なら松竹梅の3案を作るとよい。100点満点のアーキテクチャにはならないので、バランスが取れた判断になっていることを重視する。
アーキテクチャ設計レビューの難しさは、何もない状態でレビューするため、常にリスクがあることである。代表的なリスクとして、技術的リスクとシステムの成長リスクがある。特に成長リスクは、未来は誰も予想できないので、稟議書に書かれた数字を鵜呑みにしないことが大切である。
問題が発生した時に、人のせいにするのは簡単である。アーキテクトには信念が必要であり、傾聴し、整理し、働きかける力が求められる。多くの人を判断に巻き込み、「誰かの意見」にのみ従っていないかを確認する。
複雑かつ日々進化するクラウド環境に対応するアーキテクトへの重圧が伝わってきた。
本日の講演者３名がパネリストになり、風間氏がモデレータとして進行を担当した。最初に各講演者から簡単な自己紹介と、問い「レビューの目的について」のトークがあった。各講演者が問いについて挙げたキーワードを下記に紹介する。
白水氏：製品を良くする
及部氏：わくわく、すっきり
鈴木氏：メンバーの成長
風間氏：コミュニケーション
最初のテーマは「お互いの発表を聞いて参考になった点」だった。主な意見としては、レビュー参加者が定義されていること（及部氏→白水氏）、リアルタイムにレビューし日和らないこと（鈴木氏→及部氏）、モブプログラミングは面白そうだ（白水氏→及部氏）、属人化はあきらめて良い点を伸ばすこと（及部氏→鈴木氏）などの意見が出た。
次のテーマは「レビュー時の発言について」だった。
まずは、「指摘するまでの思考過程」について語った。暗黙知を元にひらめきで指摘するので思考過程を答えるのは難しい（白水氏）、初期リリース時や、５年後などかなり先のことではなく、運用開始から２年後などしばらく経った時のことを聞く（鈴木氏）、その成果物を作った経緯を聞く（及部氏）、などが挙がった。特に経緯については、注意すべきセリフとして「余裕っス」「なんとなく」があると盛り上がった。
次に、「優先順位」について語った。優先順位は決めずに思っていることを言い、チームで優先順位を決める（及部氏）、指摘のステップを作り、細かい指摘の前に視点を一段上げた指摘を行う（鈴木氏）、否定的な指摘から言う（白水氏）などが挙がった。
次に「何をベースに指摘するか」について語った。ドキュメントをベースに質問する（白水氏）、ソースコードだが、アジャイルでも必要なドキュメントは作る（及部氏）、アーキテクチャレビューでは図が大切（鈴木氏）、などが挙がった。
次に、sli.do で集めた会場からの質問について、投票数の多い順に取り上げた。
最後にまとめとして各講演者がコメントした。レビューアを教育する観点でレビューできたらと思う。レビューのやり方を工夫したい（白水氏）、パネルディスカッションは難しかった（及部氏）、レビューについて話す機会は貴重と感じた（及部氏）、外側から見るのがレビューで、コミュニケーションを増やしたい（鈴木氏）。
三者三様の背景だったが、共通点やお互い参考になった点を各自見いだすことができたことで、自分と異なる背景の取り組みも大いに参考になると、気づいた。
実行委員長の風間氏から、普段レビューについて考える機会がないため、本日は自分自身が深く考えることができた、とても勉強になった、と感想があった。
レビューをテーマとしたシンポジウムの初回で、それぞれ分野が異なる各講演者の講演内容とパネルディスカッションから、共通点やお互いに参考となる点が多かったことに驚いた。これは、実行委員の準備や講演者の伝えたいことが、レビューを深く考えるという一点に集中したことで生み出された結果だと感じた。
記：和田 憲明（ASTER）