2012年はレビューにも想いを寄せる

　今年もよろしくお願いいたします。
　拙ブログ、今年は1エントリ/10日+αで40本書く。そしていつしか量が質に転化して・・・という展開を目指しています。いつしかっていつだ。

レビューへの野望

　2011年は「ソフトウェアテスト技法ドリル勉強会」のおかげで、テスト技法に関する勉強を進めることができました。
　2012年はこれに加えて、「レビューどうやろうか」ってことをじっくり考えていきたいと思っています。昨年末のレビュー祭りでアジャイル・インスペクション、「ガイドを用いたサンプリングレビュー」のお話を聞いたことが大きいですね。

www.kzsuzuki.com

　レビューは静的テストに分類されるのですが、プログラムのテストと大きく違う点があります。
　テストケースがないことです。
　何をもってよしとするかもよくわからないし、「レビューってどうやるの？」という疑問にも答えがたい。自分自身、システマティックにチェックやレビュー作業をしているとはとても言えない。

　細谷泰夫さんによる、SPI Japan 2011の発表資料・『産学連携によるデザインレビュー改善事例』を絶賛精読中なわけですが、このスライドp.8のような、レビューのロードマップを、自分なりに持っておきたいですね。

レビュー形態のマッピング

　さて、スライドp.8の図を参考に、レビュー形態を次の2つの軸でマッピングしてみました。理解が誤っていたらスミマセン。

縦軸: 技術⇔ドキュメンテーション

　「技術」はそのまま、技術的に妥当な設計かということを検討するもの。「ドキュメンテーション」（もっと適切な表現がありそう）は、用語の統一、ヘッダー・フッターといったエディトリアルな正しさや、記述の十分性、明確さなどを検討するもの。

横軸: サンプリング⇔全数

　ドキュメントの一部を対象とするのか、全部を見るのか。

　(A)(D)(E)がスライドにあるもの。(B)はレビュー祭りで習ったもの。(C)は今、自分で考えているものです。1つずつ見てみます。

(1)ドキュメンテーション×サンプリング の象限

　まず、(A)アジャイル・インスペクションです。先の発表スライドにあるように、文書様式、言葉の定義、記述の粒度や深さという部分を見ます。技術的な妥当性は埒外。
　使える道具として、エディトリアルな観点についてはプロジェクトや組織規定のチェックリストがあったり、曖昧さにつながる表現の検出については一部、ツールで機械的にチェックできますよね。

　(B)「ガイドを用いたサンプリングレビュー」の守備範囲はアジャイル・インスペクションと重複するものの、真にエディトリアルなところは見ないので、若干上側に。ここで使用する道具は、ガイド。

(2)ドキュメンテーション×全数 の象限

　(C)チェックリストに基づくレビューってのを考えています。チェックリスト嫌いな人、かたじけない。
　ここでいうチェックリストは、コーディング規約を羅列したようなものとか、過去の失敗事例に基づいて作成したような技術的・各論的なものではありません。開発対象のプログラムの性質にあまり依存しない、汎用的な項目です。

(3)技術×全数 の象限

　(D)インスペクション。(C)との合わせ技で、技術的な妥当性と、それに伴う記述の十分性・正確性を担保する！というところでしょうか。言うだけなら簡単ですね。
　レビュー担当者の成長パスとして、最初は(C)のチェックリストをたよりにレビューに貢献しつつ、次第に(D)にシフトしていく作戦。

(4)技術×サンプリング の象限

　(E)ウォークスルーです。
　(D)と(E)については、先のスライドにそれぞれ「自信のない部分を局所的に」「全体を通して」とあることから、この位置にしています。

　で、今年よく考えていきたいと思っているのは、太い楕円のもの。(B)の「ガイド」と、(C)のチェック観点の手持ちを増やしたい。
　(B)のガイドについては、レビュー祭りで習った入出力のガイドと、前回書いたキーワードマトリックスで、とりあえず2つ(笑)。
　(C)のチェック観点として考えているものを、今後書けたらと思います。

　もしかすると、車輪の劣化再発明を一生懸命やっているのかも知れません。参考になる本や記事などあれば、教えてくださいませ。

「技術的なチェックリスト」について

　(C)のチェックリストは、技術的な事例の集まりじゃないよと書きましたが、「やりがちな失敗」「設計誤りの経験」みたいなものを、ノウハウとして蓄積していくのは正しいと思っています。
　でもそれをチェックリストの体裁にして、設計後にそれに基づくチェックをする/させるというのは、アンチパターンかなと。挿話証拠「そんなチェックリストあるなら先に言ってよ」。
　そういうノウハウは、ドキュメントを書く前に見て、理解しておくべきなんですよね。