オルタナティブ・ブログ > 森崎修司の「どうやってはかるの?」 >

計測できそうでできない多くのこと。エンピリカル(実証的)アプローチで。

ブログのアクセス解析とソフトウェアメトリクスの共通点

»

もう1ヶ月前くらいなのですが、オルタナティブブログ「グラフカタリスト」の伊藤氏のお話を伺いました(お話の詳細はこちら。伊藤氏はアイティメディアでリサーチやアクセス解析をなさっています。お話は伊藤氏のブログの閲覧数増加を目的としたPDCAでアクセス解析の結果を使われています。閲覧数や参照元、滞在時間等の限られた情報から、その背景にある複雑なモデル(訪問者の嗜好や他のWebサイトとの関係や位置づけ)を推測していきます。モデルをもとに、より好ましいエントリのテーマや誘導方法(ソーシャルネットワークサービスで紹介する等)を選択していきます。

ソフトウェア開発で収集するデータも同じような特徴があります。たとえばソフトウェアテストでの検出密度というのがあり、テストで検出された欠陥を単位規模あたりの欠陥数、単位工数あたりの欠陥数、単位テスト件数あたりの欠陥数などを指します。検出密度が通常とは異なる値となっていれば問題の可能性があると判断し、詳細を調べたり対策を考えたりすることがあります。欠陥件数自体が主観的であり、規模、テスト件数、工数等も計測の方法によって異なるため、これらの数値だけで状況を把握することは難しい場合があります。

これらは表層的なデータであり、背景にある複雑な原因や事情を即座に把握することはできず、推測しながら考えていくことになります。では、表層的なデータだからといって取るに足らないもので全く意味がないかというと、必ずしもそうではありません。そうした難しさを理解しないと表層的であったり、言い訳、実績作り、ごまかしのためのデータ収集や分析をしてしまいます。他分野でのデータ収集や分析全般にあてはまる部分も多いと思います。

また、アクセス解析でもモデルを複数想定してデータでその想定を確認したり実際のWebページやエントリのテーマにあたったりして、何が好ましいかを確認していくそうです。ソフトウェア開発のメトリクスの分析でも起こるのですが過剰な期待が原因となって「それくらいのことしかわからないのか」と言われることもあるそうです。それでも何もない状態で進めるよりは状況把握できる可能性が高くなるという点にも共通点を感じました。

メトリクス収集や分析をしていると上のように多くの方が理解していることを忘れてしまうことも少なくありません。お手元のデータはどのような複雑な事情や原因を表せているでしょうか。また、可視化や分析の結果を説明される際に、表層的なデータから得られる知見には限界があることを十分に伝えることができているでしょうか。

ソフトウェア工学の学術論文は背景や事情の推察が書かれていることはあまり多くなく、推察であることを示した上でその背景を議論する論文が増えていってほしいと思っています。また私の研究グループでの論文にはなるべくそういう部分を増やしていきたいと思っています。

Comment(0)