「確認する」という言葉の落とし穴

業務に関する要件定義や仕様書に「確認する」という言葉がよく使われます。この言葉は、一見明確なようで見過ごしてしまいがちですが、曖昧さが残っている場合が多く、後々要件や仕様の齟齬を生みます。

本来「～であることを確認する」という言葉は、”What”しか定義されておらず、それに対して「何を使用して」、「どのような方法で」という”How”の定義が対になるはずです。システムであれば、前後関係からその方法が明確な場合が多いため、齟齬に至る前に設計上で修復されますが、業務の場合には個人の解釈に従って業務設計・構築までなされてしまうため、後々になって齟齬となる確率が高くなります。

また、「確認する」と言う行為には、結果としてOKの場合とNGの場合が存在し、NGの場合にも考えられるパターンによって事後処理が変わってきます。それにも関わらず、OKとなる場合のみを想定して、確認結果に分岐や事後処理を規定しないパターンもよく見受けられます。システムであれば形だけの確認であったり、比較の結果のNGのルーチンを作製しておく必要があるため、このような抜け漏れは起こりにくいのですが、業務となったとたんにこの分岐の規定を行わない場合が増えてしまいます。

組織の中で暗黙のうちに行われる業務上のエラー修正を前提にすれば、ここまできちんとした業務設計をする必要もないのかも知れませんが、本来であれば「確認する」という作業を明確に規定することは業務設計の基本です。J-SOX法の適用による内部での業務統制を測るためにも、今一度「確認する」という業務作業に関して、見直しを行うべきだと思います。