ボドゲを愛するテスト屋さん

ソフトウェアテストとか、ボドゲとかを自由気ままに。

改善手段を選ぶ順番

どうも、アドベントカレンダーがもうすぐ始まりますね、オムそばです。
今年もソフトウェアテスト(12/6)についてと、ソフトウェアテストの小ネタ(12/13)について書きます。

qiita.com

qiita.com

 

さて、今回は改善する手段の選ぶ順番について、書きたいと思います。

f:id:teamomusoba:20181201063654p:plain

 

■改善の落とし穴

「チェックリストを作って改善します」。
今までたくさん聞いてきたセリフですし、私も何回も言ってきたセリフです。
もちろんチェックリストは立派な改善手段の一つですが、ちゃんと用法用量を守らないと、"改善したけど別の問題を引き起こしている"、いわゆるモグラ叩き現象に陥りかねません。

「せっかく1ヶ月かけてチェックリストを作ったのに、チェック項目が数百個あって、一回のチェックに一日かかる、それも毎週。。。」

極端な例ですが、このような、作成にかかるイニシャルコストや、運用するためのランニングコストを考慮した上で、改善手段は選ぶ必要があります。

 

■改善手段を選ぶ順番

改善する手段を選択する際、当たり前かもしれませんが「費用対効果の高いものを選ぶ」ことを意識したほうがよいでしょう。
ここでいう"費用"には、イニシャルコスト、ランニングコストが含まれています。

つまり、最も安くて(早くて)、時間のかからないことをしましょう、ということです。

以下に改善手段を選ぶ際に考慮すべき順番を書きました。1を考えて、だめなら2を考える、みたいな形で使っていただければ。

  1. なにかをやめる
    やめることは、コストが最もかからない手段です(やめるための調整などはかかるでしょうが)。余計な作業をやめることで、時間を作ることができます。それにより、問題が改善される場合があります。
  2. やり方を変える
    ちょっとした工夫で、問題が改善される場合があります。
    場合によってはランニングコストが増すかもしれませんが、イニシャルコストはほぼないといえます。
  3. 既存のものや仕組みを取り込む
    すでに存在しているツールやメソッドを取り込むことで、問題が改善される場合があります。
  4. 新しいものや仕組みを作る
    既存のツールやメソッドを使わず、自分(達)でいずれかを作ることで、問題が改善される場合があります。最初に書いた"チェックリスト"はここか、もしくは3番にあたると考えています。
  5. 人を入れる
    新たな要員を追加することで、問題が改善される場合があります。
    イニシャルコスト、ランニングコストの高さはいわずもがな。

チェックリストを作って改善だ!という前に、無駄な作業をしていないか、やり方を変えれば改善されないか、などを一度振り返って考えてみるとよいかもしれません。