(前回のつづき）

3．道具の変更

手順ではなく道具を変更する。
ここでいう道具とは、アプリケーションやシステム、ウェブサービスなどのソフトウェアと、
パソコンや加工機械などのハードウェア双方を意味する。
たとえば、入力ミスが発生しないサポート機能のついた会計ソフトに切り替える、
操作に熟練の技術が必要な加工設備を、誰でも簡単に扱える設備に入れ替えるなどがこの手法だ。

手順の変更と違ってお金がかかるのが難点ではあるが、
人間に頼らないだけに、安定かつ高い改善効果が期待できる。

4．確認作業の追加

問題が発生しないよう、途中に「確認」という新たな作業を挟むという解決方法もある。
他の手段はなく、手順や設備の変更では解決できない場合、
こういった形で当事者以外の誰かに確認作業をしてもらうことで問題を発生させない、
仮に発生したとしても確認段階で気付き修正ができる。

もちろん、確認作業の分だけ手間が増えるのが問題だ。
また、ダブルチェックは「もう一人がきちんと見てくれる」と気の緩みを生み、あまり効果がないという調査結果もある。

5．復旧体制の追加

どんな対策を行っても問題が発生する可能性をゼロにはできない。
だったら、発生した際の影響を最小限に留めればよい、というのがこの解決策だ。

発生しそうな問題を想定し、もし発生した場合は迅速に対処できる方法を予め用意しておく。
たとえば銀行のシステムなどは、停止するが許されないため、機械の故障などの起こりうるトラブルを事前に想定し、トラブル時でも動作が止まらないよう二重三重の解決策を用意している。
（それでも、想定外の事由で停止することはあるのだが）

6．目的そのものの変更

問題が発生した際に、そもそもの目的に立ち戻って考える。
解決策が見当たらない場合はこういう「そもそも論」が有効な場合がある。

実は過去の慣例でやっていた作業であり、現在ではより簡単な方法で目的を達成できる・・・なんてのは、特にITが絡むことではよくある。
会議が多く、またその効果が感じられないとする。
その際、会議の進め方のような本を読むのではなく、「この会議ってそもそも必要なのか？」と自問してみると、実はメールでの連絡だけで何の問題なかった、といったケースだ。

やり方はいくつもある

筆者がシステムエンジニアだった頃、プログラムの本に書いていた格言で、今もずっと心に残っているものがある。

There’s More Than One Way To Do It.

意訳すると、「やり方は一つじゃない（いくつもある）」。

どんな問題も、その解決方法は一つではない。
ただ、それに気づいていないだけだ。

「この方法しかない」と思い込んでしまうとトラブルの元になる。
今回解説した6つの方法などを念頭に、「解決策は本当にこれだけなのか」と常に自問自答するクセをつけるといいだろう。