SEA Forum in July 2012に参加してきました。
テーマは「レビューについてあらためて考えてみよう」。IBMの細川宣啓さんと、ソニーの永田敦さんのお二人のかけあいプレゼンテーションでした。特にピンときたポイントをご紹介したいと思います。(細川さん許諾ありw)
テーマは「レビューについてあらためて考えてみよう」。IBMの細川宣啓さんと、ソニーの永田敦さんのお二人のかけあいプレゼンテーションでした。特にピンときたポイントをご紹介したいと思います。(細川さん許諾ありw)
欠陥密度の分母と分子
欠陥密度とは、テストでいえば規模あたりの欠陥数、設計ドキュメントでいえば、ページ数あたりの欠陥数。「密度」というのは、何かしら客観的にモノを言っている感じのする魅惑のメトリクスです。
ただ個人的には、様々なソフトウェア開発において、設計工程における欠陥密度が一定の値の範囲にサワヤカに収まるとは思えません。ものすごーくブレるのが当然だと考えています。
なので、その場で設計工程のメトリクスには興味を失ってしまっていました。計測して意味あるのかよ・・・と。
なので、その場で設計工程のメトリクスには興味を失ってしまっていました。計測して意味あるのかよ・・・と。
ですがお二人から、以下のようなポイントを伺いました。
|
(1)の方は、ドキュメントの欠陥密度を考える人であれば一度は悩むポイントです。日本語のドキュメントのページ数を、どう正規化するのか。句読点数?文章メインでないドキュメントはどうする?
(2)はそもそも、考えたことがありませんでした。
確かに言われてみると、設計における欠陥には、仕様全体にインパクトのあるものから、軽微なものまであります。その粒度の幅は、テスト工程において見つかる欠陥より広いでしょう。では、粒度はどう合わせればいいでしょう。
確かに言われてみると、設計における欠陥には、仕様全体にインパクトのあるものから、軽微なものまであります。その粒度の幅は、テスト工程において見つかる欠陥より広いでしょう。では、粒度はどう合わせればいいでしょう。
(1)も(2)も、まだまだ理解できていないです。ちゃんと質問すればよかった・・・。同様の機会があれば、ぜひ伺いたいまくりたいところです。
トレンドを見る
永田さんの資料で、レビューによって設計の品質が改善していく様子が説明されました。時系列で追っていくと、欠陥密度が徐々に下がっていくというものです。
ここで重要なことは、この「時系列」が、いくつもの別のソフトウェア開発を比較しているわけではないということです。そうではなく、1つの開発における、小分けにしたレビューの結果のトレンドを追っています。
ここで重要なことは、この「時系列」が、いくつもの別のソフトウェア開発を比較しているわけではないということです。そうではなく、1つの開発における、小分けにしたレビューの結果のトレンドを追っています。
ただでさえブレの大きい設計工程なのに、それぞれ特性の違うソフトウェアにおけるデータを比較することには、多分あまり意味がない。アジャイル・インスペクションについてはレビュー祭りでも教えていただきましたが、1つの開発で、同じチームと行うレビューだからこそトレンドを見る価値があり、改善を確認することができるのですね。
www.kzsuzuki.com その考え方は、細川さんの「2時間のレビューを1回やるより、15分のレビューを8回やる!」にも現れています。
レビューとはそもそも
細川さんは、「レビューとは、悪さの知識の移転場所」という考えです。それを推し進めると、その知識は移転可能な形になっていないといけない。1つ1つの欠陥の「インスタンス」ではなく、それを幾分抽象化した形にして、保存しなくてはならないのです。
この他にも、レビュー速度・サンプリングレートの考え方や、レビュー計画書の必要性(まずは書いてみよう!)など、示唆に富むお話がたくさんありました。
たとえば「レビューはまとめて1回じゃなくて、10回やることにしよう」などといきなりプロジェクトの方針を転換できるかと言えば難しいのですが、教えていただいた考えを少しずつ推し進めて行こうと思います。