私がデータ分析に関して「教えていただいたこと」と「大切だと実感したこと」

はじめに

私がデータ分析に関して教えていただいたことと、大切だと実感したことをまとめておく。
また、おまけとして、データの収集や分析について、思いついたことも追記する。

教えていただいたこと

1. アクションに結びつく分析を行う

アクションに結びつかないデータ分析をしないように注意する。
課題解決・問題解消につながらないデータ分析をしないように注意する。

「データ指向のソフトウェア品質マネジメント―メトリクス分析による「事実にもとづく管理」の実践」

野中誠，小池利和，小室陸，「データ指向のソフトウェア品質マネジメント―メトリクス分析による「事実にもとづく管理」の実践」，日科技連出版社，2012
https://bookmeter.com/books/5474213

書籍に示されている「品質データ分析の作法」の中に、「作法7：アクションに結びつく分析を行う」がある。

「日本企業がデータドリブン企業になれない本当の理由とその解決方法」

河本薫，「日本企業がデータドリブン企業になれない本当の理由とその解決方法」，ソフトウェア品質シンポジウム2020，2020
https://www.juse.jp/sqip/symposium/2020/timetable/files/kichou-kouen_happyou.pdf

河本薫さんの講演資料の中に以下の言葉が出てくる。

データ分析のゴールは、課題を解決し、問題を解消することである。

2. まずは、横の比較ではなく、縦の比較をする

小池利和さんからは、「横の比較ではなく、縦の比較をしなさい」と教えられました。
横の比較とは、別の組織との比較・別のプロジェクトとの比較・別の人との比較などです。
縦の比較とは、過去と現在の比較です。
つまり、横の比較は他者との比較、縦の比較は自分との比較です。

前提が違うデータを比較し良い悪いなどを判断するのは難しいため、まずは過去と比較しどう変化したかを見なさいということだと理解しています。

3. データ分析をする対象に中に入る

@kaizen_nagoyaさんから、以下のように教えられた記憶がある。

機械学習を使う前に、自分の勘と経験で学習をしてみなさい。そうすれば、機械学習の結果の妥当性が判断できる。

@kaizen_nagoyaさんは、「ウィキペディアの分析をするならウィキペディアの記事を100回くらい書きなさい」「書籍の分析をするなら書評を100冊分くらいかきなさい」「Qiitaの分析をするならQiitaの記事を30個くらい執筆しなさい」と言われていた気がします。

確かに、自分が分析対象の中に入ってみると、仮説が思いつきます。

3.1. 経験と勘をつかう

「データ分析は、3K（経験、勘、コツ）が重要」と教えられたとおっしゃっている方がいた。
確かにと納得した。
まずたくさんの事実とデータを見た経験が大切。それによって勘(=仮説)が働き、最後にそれをコツ(=技術、技法)で検証するって感じかもしれない。
数字を見て仮説を考えるではなく、仮説をもったうえで数字を見て仮説を確かめるという感じかもしれない。

@kaizen_nagoyaさんの以下の記事でも、経験と勘が重要ではないかという仮説が述べられている。
https://qiita.com/kaizen_nagoya/items/f5ec32472774d17e46ec

3.2. 悪手は数値だけから異常を見つけようとすること

森崎修司氏が以下のツイートをしていた。
https://mobile.twitter.com/smorisaki/status/1483647369929723904

ソフトウェアメトリクスでの悪手は数値だけから異常を見つけようとすること。開発支援側だけの仕事になっていて開発側から「ジャマしないでそっちだけでやってほしい」という要望を飲んでしまったときに起こりがち。異常な状況を想定、理解できていない状態で適切なものが定義できることはほとんどない

データがあると悪手である「数値だけから異常を見つけようとする」に陥ることがありそう。
データを見る前に、データの裏にある状況を想定・理解しておく必要がある。

4. 測定行為が測定結果に影響を与える

小川清さんから、以下のコメントをいただいた。

測定が対象に影響を与えるかどうかの基本が抜けているかもしれない。観測そのものが対象を変える測定と、誤差の範囲内の影響しか与えない事項を分類していないかも。現代科学の基本中の基本だったのでは、、、。
https://bookmeter.com/books/3178248

ホーソン効果が、一つの有名な事例かも。
私も、工数の入力定着率を計測していたら、値が勝手に良くなった経験がある。
流出不具合も組織で計測をしていると、いろいろな要因で、毎年勝手に減っていくかも。

書籍「測りすぎ――なぜパフォーマンス評価は失敗するのか? 」も、非常に参考になる。
みんながハマっていることが示されている。特に、測定と報酬の関係に注意が必要であることが示されている。
https://bookmeter.com/books/13574094

5. その他

@kaizen_nagoyaさんが、データ分析に関して様々な知見を展開してくださっている記事

私が大切だと実感したこと

私がデータ分析をするうえで経験則からもっとも大切だと実感したのは「アクションに結びつく分析を行う」です。

アクションに結びつく分析を行う

経験則を「ゴールに繋がるアクションを生み出すデータ分析活動の事例」というタイトルで、SPI Japan 2019で発表しました。

おまけ

データ収集について

清水吉男さんのメッセージ

２０１の鉄則：原理１４３＜管理の原理＝押し付けがましいデータの集め方をするな＞

データ収集に協力した方が、結局は自分たちにとってプラスになるということが分かれば、設計者も協力してくれます
・・・
必要なことは、収集に無理がなく、乗りやすいということ
・・・
できるだけ設計者の負担にならないように、データ収集を自動化することも有効です。
・・・
収集したデータを個人の評価に使ってはならない

私の思いつき

先日、SQiP研究会の皆さんと交流（雑談）をする場があった。
会社で品質保証関連の役割を持っている方から「データ分析をしたいんですけど、現場からデータが集まらないんですよね」という悩みを聞いた。
品質保証関連の役割の組織・人は、「悪い（悪そうな）ところを見つけてあげよう」というモチベーションで、データを集めようとしていることが多い気がする。
人は自分の悪いところは見られたくない心理があるように思う。人は自分の良いところは見たい心理があるように思う。
「ダイエットをしているとき体重が減っていくのは見たい」「SNS等で”いいね”が増えていくのは見たい」
など
だとしたら、「良いところを見せてあげよう」というモチベーションで、データを集めようとしたほうがうまくいくのではないか？「良いところを見せてあげよう」として、たまたま「悪い（悪そうな）ところを見つける」というアプローチがいいのではないか。