どうも、アドベントカレンダーがもうすぐ始まりますね、オムそばです。
今年もソフトウェアテスト(12/6)についてと、ソフトウェアテストの小ネタ(12/13)について書きます。
さて、今回は改善する手段の選ぶ順番について、書きたいと思います。
■改善の落とし穴
「チェックリストを作って改善します」。
今までたくさん聞いてきたセリフですし、私も何回も言ってきたセリフです。
もちろんチェックリストは立派な改善手段の一つですが、ちゃんと用法用量を守らないと、"改善したけど別の問題を引き起こしている"、いわゆるモグラ叩き現象に陥りかねません。
「せっかく1ヶ月かけてチェックリストを作ったのに、チェック項目が数百個あって、一回のチェックに一日かかる、それも毎週。。。」
極端な例ですが、このような、作成にかかるイニシャルコストや、運用するためのランニングコストを考慮した上で、改善手段は選ぶ必要があります。
■改善手段を選ぶ順番
改善する手段を選択する際、当たり前かもしれませんが「費用対効果の高いものを選ぶ」ことを意識したほうがよいでしょう。
ここでいう"費用"には、イニシャルコスト、ランニングコストが含まれています。
つまり、最も安くて(早くて)、時間のかからないことをしましょう、ということです。
以下に改善手段を選ぶ際に考慮すべき順番を書きました。1を考えて、だめなら2を考える、みたいな形で使っていただければ。
- なにかをやめる
やめることは、コストが最もかからない手段です(やめるための調整などはかかるでしょうが)。余計な作業をやめることで、時間を作ることができます。それにより、問題が改善される場合があります。 - やり方を変える
ちょっとした工夫で、問題が改善される場合があります。
場合によってはランニングコストが増すかもしれませんが、イニシャルコストはほぼないといえます。 - 既存のものや仕組みを取り込む
すでに存在しているツールやメソッドを取り込むことで、問題が改善される場合があります。 - 新しいものや仕組みを作る
既存のツールやメソッドを使わず、自分(達)でいずれかを作ることで、問題が改善される場合があります。最初に書いた"チェックリスト"はここか、もしくは3番にあたると考えています。 - 人を入れる
新たな要員を追加することで、問題が改善される場合があります。
イニシャルコスト、ランニングコストの高さはいわずもがな。
チェックリストを作って改善だ!という前に、無駄な作業をしていないか、やり方を変えれば改善されないか、などを一度振り返って考えてみるとよいかもしれません。