ある問題を担当しているとして、役員や部門長から「そういえばあの件はどうなっている？」と経過報告を求められることはよくあります。間違っても「今現状を把握するためにデータを集めています。」とか回答してはいけません。
「データが揃うまで対策は検討できない。」と言っていると永遠に対策が出せないことがあります。やみくもにデータを集めていたのでは時間だけが過ぎていきますので、データを集めるにも戦略が必要です。この戦略は仮説に基づいて立てます。
例えば、すでに出荷している製品がある時期を境に急に不具合が多発しているという問題を担当していて上司に進捗を聞かれたとします。その場合「パーツのばらつきというよりも、そもそもの設計に問題があったと考えています。現時点では、気温10度以下の環境で不具合の再現性が上がることが分かってます。材料を変えてデータを取っていますので後ほど報告します。」のように回答を行うべきです。
仮説は一つだけではない
仮説は、断片的な事実から問題が起きる仕組みの推理を行うことです。仮説は必ずしも正しくはありませんので、複数個候補があってもよいです。
仮説を考える際には、消去法的に候補から外せるところはどこかを考えることも有効です。すでにあるデータから候補から外せるところを調べます。
仮説は間違ってもよいので、自分の経験に基づいて立てても構いません。ただ必ず仮説は検証を行わなくてはいけません。
仮説を検証する
仮説をもとにデータを取ってその仮説が正しいか、または正しくないのかを検証します。データが仮説と反していても、このデータが新たな仮説をつくるきっかけになります。データが多少ずれている場合は、元の仮説を多少修正するということもあります。
仮説検証のデータはラフで良い
ビジネスでの判断材料としての仮説検証はかなりラフで良いというのはわかりやすいですが、技術系においても仮説検証での調査や測定はある程度ラフで構いません。仮説が正しいか、間違っているのかを素早く判断することを優先する必要があります。仮説が正しそうであれば、追加で検証を実施して精度を出せばよいでしょう。
コメント