インスペクタはこんなところをみている

ペットボトルの数

　少し成果物／技術的な領域から離れて面白い事例を紹介しましょう。

　筆者は日常的にさまざまなトラブルプロジェクトの開発室にお邪魔し、オンサイトでインスペクション活動を実施しています。この時、通常のプロジェクトとトラブルプロジェクトには、プロジェクトルームの中で決定的な差異があります。

　それこそ開発室・プロジェクトルームに入室した瞬間に判定できるわかりやすい指標なのですが、それは「開発担当者の席上においてあるペットボトルや飲料缶の数」です。

　そんなバカな！と思うかもしれませんが、逼迫（ひっぱく）したプロジェクト環境下では、画面上のエディターと格闘しているプログラマーはゴミを捨てに立ち上がる暇さえもったいないと思うことも少なくありません。

　また、仕様のすり合わせ、インターフェースの確認等ミーティングが頻発する中で少しでも息を抜く瞬間が欲しいと思うため、まだ飲みかけのペットボトルがあったとしても「買いに行く」行為で休憩を無理やり取っている場合も同じ現象が発生します。

　もちろん、これが科学的に証明された事例か？と問われると正直根拠は提示できないのですが、なぜか昔からトラブルプロジェクトは空き缶とペットボトルの山になっている場合が多いのです。

　Tom DeMarcoさんが名著「ゆとりの法則」という書籍の中で、開発環境の向上・整備がもたらす開発者の生産性向上について言及しています。ここからもわかるように、開発者を狭く苦しい開発室に閉じ込めてトラブルを「力」で乗り切ろうとする姿は、インスペクターからはペットボトルの数を数えることで「成果物のページを開く以前」にケアレスミスやコミュニケーション不足による成果物間不整合等といった欠陥が内在しているだろうな、と見抜かれているかもしれません。

　実際に筆者はこの観察は必ず行うようにしていて、各種欠陥の仮説を立ててインスペクションに挑んでいます。

仕様文書のコピーペースト率

　仕様書、特に要求仕様書に多く見られる事例として仕様文章そのものをコピーアンドアンドペーストして作成するということがあります。

　「上流仕様書の文字列であればカットアンドペースとしてもいいだろう」という考え方の記述者も多いのですが、コードであればクローン率・コピー率といったメトリクスで計測される行為と同様に、日本語の持つあいまいさや複雑さから致命的欠陥の原因になることがあります。

　日本語の自然文のコピー率が計測できるとよいのですが、直接的に計測する方法が存在しません。そこでメトリクス指標ではありませんがその方法をご紹介します。

　例えば対象がMicrosoft Wordで記述されたユースケースシナリオだとしましょう。ここにはユーザーとシステムのインタラクション（対話）が記載されています。このユースケースシナリオがコピーアンドペーストで作成されたかどうかは、文字列をソートしてみればわかるのです（図2）。

・手順１）ユースケースシナリオの文章をExcelに貼（は）り付ける
・手順２）ユースケースシナリオの隣の列に、文字列の長さ（=Length(対象文字列））を計測して貼（は）り付ける
・手順３）ユースケースシナリオの文章を、文字列の長さ列をキーにして昇順にソートする

　この手順によって、シナリオ文章が連続して現れるため、コピーペーストした個所が一目瞭然（りょうぜん）で理解できます。もちろん仕様書のコピーペーストが即時欠陥かと言うと、コード同様そんなことはありません。

　しかし安易に作成した仕様にはその貼（は）り付け個所の前後に欠陥が内在しやすく、比較的簡単に不整合や矛盾を定量化・評価することができます。