2ヶ月ほどまえに参加したセミナーについて、ブログってみました。
有料だったのでどうかなと思ったのですが、にしさんから許可（？）もらったので、掲載しちゃいます。
所感
非常に費用対効果が高いセミナーでした。こんなセミナー、もうないんじゃないかなぁと思うほどの満足度の高さです。ありがとうございました。
森崎さんの講演で、「チェックリストは「やり方が」書かれていない。どうやってそれを確認するのか？が書かれていない。」というお話がありました。
社内でも、「ツール」を使った、そのツールが＊＊です、という報告はあるが「どう使われたのか、使った目的は何か」というところに触れられていないことがあるのとリンクするなぁと思いました。手段・方法は、プロセス・目的と一緒にセットで情報を持っていないと意味がない。そう思いました。
細谷さんの講演では、グランドルールありき、チームビルディングありきの改善かもしれない、とおしゃっられていたことが印象的でした。
個人ではなくチームでルールを作り、自分たちで決めたことは守る、ということを厳しく貫いているところがおおきな成功要因なんだなぁ、と思います。
パネルディスカッションを見ることが一番の目的でした。ここだけで、もう本1冊分の価値があったのではないかなぁと思うような内容でした。「レビュー」と「テスト」って、似て非なるもの。そこを痛感するパネルでした。
開催概要
- タイトル：ワークプロダクトレビューの技術とプロセス ~レビュー技術・事例と標準化最新動向の紹介~
- 日時: 2017年 10月18日(水) 13:15～18:00
- 会場: 機械振興会館 地下3階 研修1号室
- 概要：
ソフトウェアの品質向上のため、要件定義書や設計書などワークプロダクトのレビューは重要です。2017年2月にISO/IEC 20246:2017 (ワークプロダクトレビュー)がレビュー技術やプロセスを定義する国際標準として発行されました。
本セミナーでは、このISO/IEC 20246:2017発行を機会に、レビュー技術や事例、また標準化最新動向を紹介・解説します。まず、レビューの技術やプロセスについて一般的なものから最新情報など、また、産業界での適用事例を紹介します。さらに、ISO/IEC 20246:2017の解説を行います。最後に、パネルディスカッションを行い、レビュー技術の事例や国際標準の意見交換を行います。
●ソフトウェアプロダクトレビューの基礎と研究動向（森崎さん（名古屋大学））
ソフトウェアプロダクトレビューは実行可能なプログラムが存在しない時点でも実施できる欠陥検出技法です。本講演では、ソフトウェアプロダクトレビューの基礎と研究動向を紹介します。ソフトウェアプロダクトレビューの基礎として、目的、参加者の役割、欠陥の検出例を示し、ソフトウェアプロダクトレビューの原理を理解いただきます。次に、検出した欠陥を早期に修正することによって得られる欠陥の修正コストや欠陥の見逃しリスクの低減といった効果を解説します。最後に、これまで研究分野で議論されてきたソフトウェアプロダクトレビューの技法や技術を紹介した上で、近年注目を浴びているModern Code ReviewやArchitecture Tradeoff Analysis Methodを紹介します。
- レビューは、ソースコードがない状態でも欠陥を検出できる。
- だれがやっても同じようにできる必要がある。レビューは準備が大事。
- レビューは、「どのような条件がそろうと、達成されるとやった意味がある、と思われるか」を考えよう。
- テストの場合は、あまり属人性があると聞いたことがないけど、レビューは人のスキルに依存することが非常に多い。
- レビューで、特殊なタイミングや競合、バッファオーバフローやセキュリティなどはレビュー時点で検出したほうが良い。⇒ 病気と一緒
- チェックリストは「やり方が」書かれていない。どうやってそれを確認するのか？が書かれていない。
- モダンコードレビューというものがグーグルで行われている。
- 目的は協調であり、欠陥検出ではない。ペアプログラミングの代替手段となっている。
●狙いの明確化によるレビュー改善事例（細谷さん（三菱電機（株）））
ソフトウェア開発において、ドキュメントやコードのレビューは、品質向上のために重要な活動ですが、開発現場では、レビューに投入したコストに見合った効果が得られている実感がないという課題がありました。そこで、レビューで検出したい欠陥を明確化し狙いに合わせたレビューの実施時期、実施方法を定めることにより、開発現場が効果を実感できるレビューに改善しました。本セッションでは、レビュー観点の分類、レビュー技法の使い分け、実施シナリオなど改善活動の中で定めた実施方法について紹介します。
- 産学連携して行ったカイゼンで、Melcoグループ内のガイドラインとして作成した内容を紹介。
- レビュー技法は使い分ける。
- 序盤は、例えば運用シナリオ、ユースケースなど、多く記述しそうなものであれば、最初でやり方・書き方の合意をレビュー内で行う。
- 残りのものに水平展開する。後半は工数を削減することができる。
- 中盤は、重要と思われる機能の部分など、ピンポイントで見るべきものに絞ってレビューを行っていく。
- レビュー観点とレビューの仕方を関連付ける。
- 4象限で観点を明確化することは効果がある。
- プロジェクト内で合意を得ながら実施する。
- ナレッジメンバーを任命。ナレッジメンバー＝レビューの有識者。
- 有識者だからといって、レビューができるとは限らないので教育をする。教育の中には、演習も入っている。
- いくつかシナリオを用意して、人格攻撃をしない、とかディスカッションを交えた教育を行っている。
- グランドルールありきの改善かもしれない。チームビルディングありき。
●パネルディスカッション「レビュー技術の研究と活用」
パネラー：森崎さん（森）/増田さん（増）/細谷さん（細）/西さん（西）
１．V&V V字の左側でもやるべきだということが言われているが、妥当性確認について どう考えているのか？レビューで妥当性確認ができるか？どうやればいいのか？
- 森：最後に言われても困るので、途中でいうことに意味がある。スクリプトテスト・探索的テストに代わるものがレビューにもあると思っている。終盤にいわれても直せない、ということになってしまう。どのタイミングでどういう指摘を行っていくか、をレビュー計画で合意することは大事。 ⇒細谷さんの事例に重なる
- 細：事前にレビューしてほしい観点を渡してレビューしてもらったりした。
- 増：ただしくつくったか？つくったものはただしかったか？を確認するのがV&V。正しく作っているか？というところにたいして、定義しているのが20246である。つくったものはただしいか？という観点でのチェックまでは言及していない。
- 西：V&Vは時代遅れ。妥当性確認としてどういう観点で確認したらいいかを分解しておいて、テストでは何を確認すればいいのか、を合意していくべきである。
２．オフショア・ニアショア 品質確保（検証）の良いやり方を教えてほしい。
- 森：共同研究内容。発注工程の前工程でのQ&A（＝ドメイン知識）の内容に着目する。前提知識が同じになっているかどうかでわかってくる。受注側からの質問の質で受注側のスキルを測るとよい。実績も大事。技術力がない受注側をレビューで何とかするのはむり。発注先を変える勇気も必要。ドメイン知識と技術両方ないとうまくいかない。オープンクエスチョンで聞いてくる人は、ちょっと危ない。YES/NOで聞いてくるところは安心できるかも。
- 細：契約の序盤でレビューしたりする仕組みを入れないと難しいと思う。そういうことを盛り込めるような契約にしていくべきだと思う。ワークショップ的なものを一緒にやる。ユースケース的なものを一緒に作ったりして、やり方を教えたりしている。内部品質に着目するのであれば、機能設計を一緒にやるとかを考えないといけない。
- 増：レビューのトレーニングとしてレビューを捉えることも大事。有効な手段。ツールで効率化するなども、選択肢の一つである。国際標準規格は、受注側の技術力が低い場合にも、「こうやるとうまくいくよね」というものを想定して作られている。重量級の国際標準は発注側の視点で考え方や技術などが細々と書かれているので有用である。
３．再現性・・・属人性排除、次回も同じようにできる、などについて
- 増：できる。そのために規格を作成している。再現性があるのか、品質があがるのか、という条件に関しては、組織それぞれでの前提条件などがあるとおもうので、それを文書化していくとよい。
- 細：属人性の排除。レビューの仕方はやり方があるので、できる。役割の設定、レビュー技法も取り入れられるはず。その人たちの能力の範囲でできると思う。能力の質の属人性は別の話。組織としてのいいところは狙えるけど、ひとのスキルに依存するばらつきは排除できないと思う。「組織のスキルの限度において」よい仕事ができる。
- 森：着眼点が一緒、属人性の排除。前提条件の抜けが認識できていなければ無理。 結果を予測できるようなものになるというのも、属人性の排除には重要。技術力が低いのであれば、「ないものねだりをしない」のが大事。
文化、マインド・・・の話：
- 森：素質、再現性、プロセスを定義する、マインドの話・スキルの話。マインドがあるけどスキルがないからうまくいかない、スキルがあるけどマインドが低いからうまくいかない・・四象限的。
- 細：細かく繰り返すというのに重要視している。どこを目的としていて、どう改善していくか、が大事と思っている。
- 増：F2Fでやったほうが効率が高いと聞いて、実行している。すべてがトップダウンで行っているわけではなく、プロジェクトのアウトプットが高まる行為であればOK。ツールであろうが、マインドにかかわる話であろうが、上記の効果が期待できるものであれば実施する。
４．レビュー文化：個人主義の国（欧米とか）・組織・エンジニアは、レビューのような皆のための仕事はしないので、枠や型が必要なのではないか？
- 森：レビューを手伝った人は人事評価をよくするなどの仕組み的対処が必要。レビューで後ろから打たれるような状況を作ってはいけない。
- 増：自分が書いた試験に自分で回答して自分で丸付けして100点というのは本当かどうかわからないから、確認が必要。欧米ではテスト専門の職業などがあるけど、日本ではなかなか受け入れられない。
- 西：組織の方針と仕組みは国とか個人の考えをオーバーライドするので、そういうマネジメントをしてしまっているだけなので、マネジメントの怠慢だと思います。
⇒森：レビューは社風が出る。けん制しあって向上するという文化とか。文化が異なる同士のレビューはそれぞれ違和感を感じるだろう。
５．改善内容の適用スコープは、全プロジェクトに共通というわけではないとは思う。レビューの目的やプロダクトの特性などによって改善内容を変えるべきか？レビュー設計はしているのか？
- 細：変えているが、全プロジェクトに適用しているものもある。（インスペクションに有識者を入れるというのは100％）。レビュー設計としては、目的・観点を決めるなどのレビュー計画は行っている。
- 森：細かいレビュー設計は、細かくすればするほど形骸化しやすい。コストが下がらなくなる。
- 増：チェックリストはどうやってつくるの？⇒過去の障害を一般化する一般化抽象化して、全プロジェクトに適用、とか。
６．国際規格などを隠れ蓑にして形式的に仕事に文句をいうひとにはどう対応すべきか
- 細：内部品質に対する意識を組織的に共通にしていくとかに使う。レビューのタイプで使い分けましょう。
- 森：バディチェックで回避できる。
- 増：標準は厳密に従うものではない。良いところどりをすればよい。特に20246は意識を高めてやっていこうというもの。
７．この30年間でレビューは何が変わったのか？一言で。
- 増：ほとんど変わっていない。ソフトウエアの複雑度・テクノロジーが高度になっているので、相対的には変わっていない。
- 細：若い人に「変わっていない」ということが伝わっていない。若い人は、「はじめてききました」という。それを伝えていく手段として、標準化された規格は使えると思う。
- 森：本質は変わっていないが、対象範囲が広くなり、考え方もいろいろ出てきている。反復型の開発が一般敵になってくると、レビューの役割も変わるだろう。未熟な自分を理解していこう。
- 西：テストも同じ状況だった。この先、おカネや技術が流入してきたら、変わると思う。
以上！
