RISING SUN ROCK FESTIVALをご存知でしょうか。
人生で一番音楽を聴いたであろう大学時代に初めて行った野外フェス、それが1999年の RISING SUN ROCK FESTIVALでした。
アーティストのラインナップをご覧ください。夜を徹してのこの超絶フェス、よく考えずに占有した陣地の目の前にある巨大スピーカーの爆音の渦の中でわたしは夜中も眠ることができず、「今ならこのギターウルフの演奏で鼓膜が破れてもいい！（治るなら）」と思いました。
そのフェスと同じ興奮と感動を与えてくれたのが、10月29日に東洋大学で開催された、「レビュー祭り」でした。いや、言い直しておきましょう。「第1回 レビュー祭り」と。・・・もう一度言い直そう。「第001回 レビュー祭り」、と。
アーティスト登壇者のラインナップをご覧ください。
ソフトウェア検証周りで働く人にとって、あまりに挑発的なメンツ。「レビュー祀り」といってもいいでしょう。この企画の管理者たるしんすくさんは、裏社会にどれだけのネットワークを持っているのかと・・・。
オープニングで、細谷泰夫さんが宣言されました。
「コーディングやテストと違って、レビューはソフトウェア開発者の誰もが行うもの。レビュー技法の体系化・進化のキッカケを作りたい」
そりゃ、このメンツならできるわ・・・。と、丸投げ心が働いた。
このオープニングに続いて、
- アジャイル・インスペクション
- チェックリスト
- レビューワークショップ
の3つのテーマが続き、最後にクロージング・パネルという流れ。
内容を少しでもお伝えできればいいのですが、当日すごい勢いで実況中継してくださった kimukou_26さんのtogetterまとめと、当日のエントリなのにクオリティの高い、しんやさんのレポートがありますので、わたしのエントリは蛇足に過ぎないね。
アジャイル・インスペクション
一体、どんなもの？
実はこれまで、アジャイル・インスペクションとはどういうものかをほとんど知りませんでした。 google先生に尋ねてみると・・・一番最初に、登壇者でもある森崎修司先生の記事がヒットします。で、3つ目にも森崎先生のブログがヒットします。しかも、2～3年前の記事。自分の知識遅れすぎ。
森崎先生のブログ記事から引用すると、
対象ドキュメント全てをレビュー／インスペクションするのではなく、一部を抜き取って実施し、品質（欠陥密度）が目標値になるまで、抜き取り→インスペクション→修正のサイクルを繰り返します。 (中略)通常のレビュー／インスペクションが網羅的な欠陥の指摘と指摘の修正であるのに対して、アジャイルインスペクションでは、一部を対象とする点が異なります。
同じ「インスペクション」という言葉がついていても、Fagan Inspectionとはずいぶん異なるようです。
プロジェクト・マネジメント学会での発表によると、日立公共システムエンジニアリング株式会社にも「一人一本目チェック技法」という考え方があります。あまり情報が公開されていませんが、コチラにこのように紹介されています。
これまでは設計書を「まとめて作成し、まとめてレビューする」プロセスであった。本技法は、担当者ごとの作業における短いサイクルの中で改善を重ねる。これが設計者自らの習熟効果により習熟曲線に沿って不良の作り込みを減らすことができるというものである。
本質的には同じ考え方かも知れません。
どんな流れで何をする？
アジャイル・インスペクションの概要の説明と演習は、永田敦さんが担当されました。
アジャイル・インスペクションの流れは以下の通りです。
- 1回につき、1ページのドキュメント（約500語）を対象とする
- レビューの場で、「ルール」に基づいてチェック
- 別に設けるロギングの場で、レビュイーが修正の有無を報告
ここでいうルールとは、たとえば「曖昧でないこと」。
例文として出された「絶対ドラゴンズに勝ってほしい」。この話者は、果たしてドラゴンズが勝つことを望んでるのか、負けることを望んでいるのか、曖昧ですね。「テストケースは全部できなかった」。曖昧ですね。でも、「すべてのチェックボックスがチェックされていない場合は」って、そう珍しい記述でもないですよね。。。
この「曖昧」の他に、「検証可能であること」「要求仕様に設計要素を書いていないこと」といったルールがあります。
そこから、何がわかる？
今回はこの「曖昧」のルールに基づいて、実際のドキュメントを使ったワークショップを行いました。各人が15分間で、4ページ程度（絵入りなので多め）のドキュメントサンプルの欠陥を探す。とりあえず、指摘の中身自体は問いませんでした。
ここで、もう1つのポイント。
レビューしたら、定量的に記録し、計測せよ。
永田さんが、アジャイル・インスペクションの提唱者・Tom Gilb氏からもらったという記録用のワークシートにデータを入力。欠陥件数・所要時間・推定検出率などから、サンプリングの母体となるドキュメント全体に残っているであろう欠陥の件数を推定します。この件数から、品質が閾値に達しているかを判断したり、推定される残欠陥が後構成にもたらすであろう損失額を算定したりします。
わたしは、ドキュメントのページ数と欠陥の数を、「欠陥密度」というメトリクスとして管理することがあります。
しかし、たとえば「機能」という単位でそれを分けたとしても、数個から、多くても20。10個くらいの数字をとって何か言えるとしても、せいぜい「ある機能が、他の機能に対して欠陥の密度が低い。おかしいかも？」ということくらい。それはそれで無意味ではないと思いますが、統計的に何かを言える気がしませんでした。
一方、無作為に1ページをサンプリングしてくるアジャイル・インスペクションでは、数を重ねるごとにサンプルの数が増える。また、1ページという細切れであれば、プロジェクトやソフトウェアの特性に、あまり依存しない数字が出そうで、もっとしっかりとしたデータが取れるように思いました。
そのスコープは？
アジャイル・インスペクションの狙いとして注意すべきは、アジャイル・インスペクションですべての種類の欠陥を取ろうとはしていないということです。1ページのサンプリングなのに、周りのページとの整合性、全体としての統一感といった欠陥が見つけられるわけがない。こういう欠陥は狙っていないのですね。
アジャイル・インスペクションで品質を高めるのは、ドキュメントの書きっぷり。共通的な部分。
ドキュメントのフォーマットや内容構成から始まり、曖昧・不明確といった、後の欠陥のリスクにつながるものを繰り返し除去していく。これを、短時間・高頻度で回すことで、書く側の腕も上がる。
全体を俯瞰しての欠陥や、ドメイン・業務要件に依存するような部分の欠陥は、設計工程後半のインスペクションで取り除いていく。その頃には、アジャイル・インスペクション時代に注目していたような「ルール」に抵触するような欠陥は少なくなっているはずなので、本来見るべき場所に注力できる、という仕掛けです。
アジャイル・インスペクションのスコープを、一般的な欠陥に絞る長所として、プロジェクト外の人間や、経験の浅い若手でも参加しやすいという点があります。若手がいきなりレビューの場に放り込まれても、何を指摘していいやらわからない。そこで、「ルール」という明確な観点を与えることで、自信をもって、また集中してレビューに参加することができるんですね。
この後、細谷さんによる事例紹介がありました。現状ではまだ非公開ということで詳しくは書けませんが、アジャイル・インスペクションが日常的な活動になっている様子は、すごい・・・。
自分の仕事に取り入れられるか？
で、これをどのように自分の現場に取り入れるか。
幸い、「ドキュメントを、できたそばから次々にレビューする」に対する抵抗感は、少ないと思います。ただ、「最初のレビューは、一般的な欠陥を見つけるよ。で、後からもう一回、業務や機能に特化した欠陥を見つけるよ」という、二段階の進め方は、場合によっては「ムダ」と判定されかねず、理解されるかどうか。慣れないと、一段階目はとてもまどろっこしい。「機能に関する欠陥を指摘してほしい/したいのに・・・」となりそうです。
「まずは、ドキュメントの品質のベースラインを上げるんだぜ！」ということを繰り返し吹聴して、うまく導入できるか試してみたいです。
ちょっと違う話ですが、「誤字・脱字はある程度、勝手に治っていくので、ほっとくこともある」というのも面白いと思いました。誤字や脱字の数を数えて、何か有益な情報が得られるとはあまり思えないので・・・。
その2はコチラ。
