インスペクターよ、誇りを持とう！！
皆さん、設計や開発のインスペクションやレビューって、どう思います？
ここ2、3年、仕事上において、第三者的視点で設計書やソースコードのインスペクションを行う機会が多くなってきています。これを読んでいる方々も、きっとインスペクションを行った経験のある方は大勢いらっしゃると思います。自分がメンバーではないプロジェクトや組織に関するインスペクションって、悩みがありませんか？
インスペクションのやり方や技法という面から見ると、ある程度数をこなしていると、「自分のやり方」「着目点」みたいなものが頭の中にできあがってきて、基本的にアドホック的に行っている事って多くないですか？
もちろん、チェックシートやレビュー記録票のようなツールは、当然利用する、あるいは用意して行います。しかしながら、やはり最終的に解釈、判断するのは人の目とセンス。網羅的かどうか？ 前提条件を掛け違えていないか？ レビュー自体の品質はどうか？ など、わたし自身は毎回悩みながら実施している状況です。
また、技術的な観点とは全く別の側面として、「第三者」というのがくせ者で、インスペクションを受ける側は、「文句つけんじゃねぇ」（言葉悪くてごめんなさい）とか、「第三者に何がわかる」的にとらえられていないかなぁ？ といった不安もあります。
インスペクションやレビューの必要性は、みんなアグリーだと思います（障害をできるだけ前工程で検出した方がいいのは常識ですし）。でも……
- 【実際やるのは大変】
現場の開発ピーク時に、実際問題として時間をとるのが難しい - 【価値を認めてもらえない】
費用対効果がはっきりしない（定量的な効果予測ができない） - 【あんまり喜ばれない】
必要なものとしてプロセスに取り込まれている所は多いと思いますが、開発の現場側からしてみると、かなり高い意識付けがないと、どうしてもやらされ感を感じてしまう
（もちろん、「動かない」ソースコードや致命的な実装バグ、だと違いますが、設計を対象としたものだと、即効的なものになりにくいですし）
などなど、あまり日の目を見ないことが多いですし、初めて見る大量のドキュメントやソースコードをインスペクションするのは、かなり苦しい作業です。
そんな悩みを持っていた最中、7月2日にソフトウェアインスペクション・ワークショップ 2009なるイベントが開催されました。「何かうまくやる方法がつかめるのではないか、また、メソドロジーや技法ってどんなものがあるんだろう」との思いで、さっそく参加してみました。
内容はこちらに掲載されていますが、ざっとこのような内容でした。
- インスペクションに関する動向
- インスペクションの基本概念や原理
- 3種類の手法に従って、サンプルの要件定義書とソースコード（約4000step）を対象に実際にインスペクションを実施
- インスペクション結果について、手法の違いやインスペクションのしやすさなどをディスカッション
- パネルディスカッション
非常にたくさんのキーワードや効果的になりそうな話が出たのですが、全部は書けないのでわたしが特に「ピンと来た！」「ちょっとやり方を見直せるかも！」という所をかいつまんで、わたしなりの解釈を踏まえて紹介したいと思います。
■読み取り、解釈した内容を別のレビュー者と交換■
1番難しいのは、「仕様間の関連性の齟齬、間違いを指摘すること」だと感じています。第三者的な立場だと、当然ですが業務知識やバックグラウンドがわからない事が多く、特に関連性に関する齟齬はなかなか見えてきません。「そういうものだ」と思ってしまいませんか？
そこで、記載された仕様をそのままとらえるのではなく、理解した内容を（声を出して）確認して、「捉え方に誤解がないか」「ほかの人間が違う捉え方をしていないか？」という観点で、ほかの人とすりあわせると、そういった齟齬が見えてくるとのことでした（なるほど納得、という感じです）。
■短期間に複数回す■
レビューって、他人の作成物を読み抜いて理解する、ということで、わたし自身は「いかに正確に読み取るか」に非常に力を入れていました。しかし、この方法だと非常に時間がかかるし、正直疲れます。当然人間なので、ずーっと同じ品質で作業できないし、その日のコンディションによっても見方が異なったりする。そこで、じーっくり読み深めるだけでなく、小さく（荒く？）見て、それを複数回見る。すると、見落としたものが見えるし、1度目よりは理解度が上がっていて、見落としたもものも見えてくる。
■事実で指摘する■
これは、レビュー結果の指摘、フィードバックの仕方についてです。「事実で指摘する」とは、「○○が記載されていない」「○○が実装されている」など、ありなしだけを言及する、という意味です。
ものすごく当たり前の事のように思えますが、インスペクションを受ける側のことを考えると、単に欠陥を指摘しただけだと、何となく冷たい印象を与えそうで、つい過去の経験や他の事例などを付け加えたくなってしまいがちです。しかし、これをやると非常に時間がかかるのと、親切心のつもりが的外れ、という事もありがちです。
そんなことになるよりは、欠陥は欠陥として端的に指摘する。一方、アドバイスとしては、指摘内容を全体的に見渡し、より根本的な原因として予想されることを示し、その是正策をサジェスチョンする方がいい、ということです。
例えば、同じような欠陥が多く見受けられるのであれば、標準化不足などの共通的な部分に原因があるのでは？ という予想ができそうです。一方、非常に局所的な欠陥であれば、その原因もおそらく局所的（担当者スキルなど）になるのでは？ といった予測を行う、ということです。
■誇りを持ってインスペクションする！■
1番グッっときた所です。実際の話の中では、いろんな話の中にちりばめられていましたので、そのものズバリの言葉があったわけではないです。ですが、ポイントだけ思い起こすと、講演していただいた方の自信に満ちた言動もから、きっと「もっと誇りを持ってやること、誇りを持てる領域である」ということだととらえました。
こんなことを講師の方は言われていました（記憶だよりな部分もあるので、一部不正確かもしれませんが）。
- インスペクションって、非常に地道で1番底辺の作業じゃないの？
- 開発や設計とは、違うベクトルを持っていて、地味で集中力を要する地味な領域（「グランドワーク」という言葉で表現されてました）。
- 効率化する方法はあるけども、最終的にはインスペクターの目と腕とセンスの勝負
- 10年後にも陳腐化しない、息の長い技術
- インスペクションするために、徹底的に仕様や実装を読み、理解する。そういう意味では、非常に多くのPJの設計や実装に触れる事ができる立場であり、その分いろんな技術や考え方を蓄積できる
- 「他の誰も見つけられなかった欠陥を、俺が見つけた！」という醍醐味
わたしの解釈ですが、底辺の領域で、ともすれば後ろ向きになりがちだけど、インスペクション技術はこの先もそう変わらない。その中で、1番頼りになるのはインスペクター自身の力であり、すなわち「プロ」としての技である。だからこそ、誇りの持てる技術であり、誇りをもって実施し、よりよりやり方を追求していく、そういうことだと感じました。
そのほか、技術的な面では、構造化ウォークスルー、Guided Checklists、ツールとの組み合わせての効率化、メトリクス計測による複雑度分析によるレビューの重点箇所のの絞り込み、など、いくつかありました。
自分自身のやり方を見返してみると、実際に実行している内容も多々あり、やり方や考え方自体はそんなに間違ってないとの確信を持つことができた反面、まだまだ、意識的にも技術的にも工夫の余地があることを実感した1日でした。
レビューやインスペクションを行っている皆さん、後ろ向きにならずに「俺、わたしだけが見つけた！」という誇りを感じられるように、がんばっていきましょう！！