共同検討の結果をソリューション化していただいた事例

分析手法をソフトウェアとして実装した。分析ソフトウェアのコア部分は日本ユニシスさんと共同で開発し、日本ユニシスさんMiningPro21開発チーム、奈良先端大の私たちのチームで、それぞれの分野用に検証、調整している。文面はこことここで公開されている。ユニシスさんはビジネスデータむけのソリューションMiningPro21を奈良先端大の私の研究グループではソフトウェア開発時に収集されるデータの分析ソフトウェアとしてパッケージ化(NEEDLE)している。詳しくはここの末尾の図で。日本ユニシスさんからの「常識破り」という文言と会員データの分析例(架空)がわかりやすくて気に入っている。

ソフトウェア開発中に収集するデータをみているうちに、意外な拾い物をすることは少なからず存在する。ただし、ぼーっと数値を眺めているだけではなかなか何かを発見することはできない。特にソフトウェア開発におけるデータ収集では、目的のないデータ収集や分析が期待する効果を発揮しないことが多数指摘され、それを解決するためにGQMパラダイムやQIPフレームワークが提案されている。

しかしながら、計測の目的を明確にしたり、仮説/検証のための仮説をたてるためにも、何らかのきっかけが必要になる。今回、共同開発したソフトウェアはそのようなきっかけをルールの形式(AならばB)で与えてくれる。ルールには「当たり前」「たまたま当たった」というものも含まれるが、多くのケースにあてはまる「当たり前」の常識ルールとそれとは結果が異なる少数の反例「常識やぶり」の例外ルールをみつけて整理した上で提示する。

たとえば、変更管理表に対して適用すると、一般に変更時間が短くて済むような変更を常識ルールとして抽出でき、特定の条件が加わった際に変更時間が長くなるような常識破りのルールが得られ、それらを対比しながら見ることができる。

以下は変更管理表からのルール例

常識ルール (サブシステムAの機能追加) かつ (変更依頼=小規模) → (変更工数 10.5人時)
例外ルール (サブシステムAの機能追加) かつ (変更規模=小規模) かつ (データ
ベースへのカラム追加=あり) → (変更時間 74.3時間)

これをもとにデータベースに対する変更が必要になるような変更依頼には慎重になることができ、変更リスクを低減できるだろう。

ソフトウェア開発にしろ、ビジネスデータにしろ、「そういうのは現場がよくわかっているベテランやエキスパートから聞けばよい」というのが通例だが、そういう人の時間を拘束するのは一般には難しく、それをもとにした改善がなかなか進まない理由の1つとなっていないだろうか。NEEDLEやMiningPro21はそういう状況を乗り越えようとする方の一助となるかもしれない。