仕事のやり方を言語化できるか

ルーティンワークの経理担当者とシステム機能の要件定義をしていて、日々の自分の仕事を言語化できずにもやもやしているシーンをよく見る。今回もそうだった。

たとえば、
先方「このデータを見て “問題” があれば保留にして次に進める」
当方「 “問題” の定義を教えてもらえますか？」
先方「前回のデータと “大幅” に違う場合です。」
当方「 “大幅” の定義を教えてもらえますか？」
先方「前回と比較して “突出” している場合です。」
当方「突出しているかどうかをあなた以外の誰かが判断できますか？」
先方「みんなでやっている。」
当方「みんなは誰ですか？Ｂさんですか？Ｃさんですか？」
先方「Ｂさんは長いからできる。Ｃさんは私が見ながら対応する。」
のような。

良いシステムを作りたければ、利用者が自分の仕事を言語化できないと絶対に無理。
そこを引き出すのがこちらの仕事とも言われるが、あけてもあけても空の引き出しを手探りで見つけたところで、その偶然見つけたお宝は数ある例外の１つかもしれないし。そこから類型を作って構造化・体系化してMECEな仕様を作ってもやり直しのオンパレードになるに決まってる。

だから、ITを導入したい現場が「自分たちの仕事は非効率的で、機械がこうしてくれたら楽なのに」を明文化してビジョンを持った状態でないといけない。
ところが多くのIT導入プロジェクトでは、現場はさほど問題を抱えていないがトップに提案して通った話からスタートする。すると現場は、「何ですか？何すればいいですか？」的な、目的地がわからない人同士が集合してさ。
我々は地図や道具は用意するけども、行き先については決められないんだから、それが失敗の始まりなんだと思うよな。