呪いにかかると鈍くなる。仕事には数多くの呪いがある。

前置き

本稿での「確認」は「やるかどうかや進めるかどうかのお伺いを立てること」を指します。完了の定義や制約条件等、内容の確認は違う軸の話。確認を依頼する側（実行者、メンバー）と確認する側（仕事を依頼する者、リーダーやマネージャー等）が登場人物で、確認を依頼する側の視点ではなく、確認する側の自戒として書いています。

やる前に確認せよと言う呪い

確認は美徳のように扱われることも多く、何か問題が起こったら「なぜ確認しなかったんだ！」と言ったり、チェックシートを作ってみたり、頻繁にするように指示したり。そんなマイクロマネジメント万歳な事をのたまいつつ、「自分で考えて行動しない」とか愚痴ったりする。何かがおかしい。何がおかしいのかを考えてみる。

「やる前の確認」は待機を伴う同期処理になる。確認がされるまでその作業を進めることはできない。その間に他のことをすれば無駄にならないと言うかもしれないが、待たなくていいのとは比べるべくもなく、スイッチングにかかるコストは非常に軽視されている。スイッチングのコストを過小に見積もって、うまく行くはずがない。マルチタスクが効率的だと言うのが幻想なことくらい、そろそろ当たり前の話になってほしい。

また、確認を依頼する際に期限を指定することはあまりない。往往にして確認を依頼する側の方が立場が弱く、依頼された側は多忙なもの。依頼する側が期限を切るのは難しいだろう。仕事は立場の上下関係ではなく協力関係であるべきなので、これが難しい時点で何かがおかしいのだけれど、現実は現実として受け入れなければ話が進まない。このため、確認を依頼した側はいつ返ってくるかわからない確認結果に心をさきながら待つことになる。確認しなかった場合に冒頭で挙げたような「なぜ確認しなかったんだ！」と言うような関係では当然そうなる。

「やった後に確認」だと何が問題なのか。手戻りが大きい、無駄なコストをかけることになる、、、などが挙げられるだろうが、手戻り（これも嫌いなのだけど）の大小やコストの有効無効を判断することは、確認を依頼する側にはできない。その判断ができるほどの情報を持っているのであれば、おそらく確認は不要になる。ここにジレンマがあり、判断できない方に確認のトリガーを任せているところに無理がある。

このように情報弱者に確認トリガーを押し付けると、あらゆることを「やる前に確認する」しかなくなる。確認が必要かどうかの判断がつかないのに、確認をしなかったら「なぜ確認しなかったんだ！」と責められるわけだから。当然確認するためのコミュニケーションにコストがかかるし、いちいち立ち止まるから遅くなる。確認待ちの間は他のタスクを行っていても返答の待ち受けるスレッドは常駐せざるを得ないので余計だ。そのうち確認していいかの確認をすることになっても不思議ではないし、実際そうなっているのを見ることもある。

「やる前に確認する」はおかしい。おかしいにも関わらず、誰にも指示されていないのに「やる前に確認しなければならない」と思い込んでいたりする。これまでの経験から思い込まされていたりするんだろう。このようなおかしいことをやってしまうのは、正しく呪いなんだろう。

やる前に確認が必要なものは、確認の必要性を判断できる側がするべき指示。これに対して「やる前に確認せずに進めたこと」を責めるのはお門違い。確認を指示されていたのにそれを無視したとしたら問題ではあるが、責められることは確認しなかったことではなく、指示に従わなかったことになる。と言うことで、確認タイミングも指示するのが正しい。ようこそマイクロマネジメントへ……あれ、おかしいな。

マイクロマネジメントの何が悪いって話もあるが、それはさておき。これを避けるため、つまり「やる前の確認」を実行者が自発的に行うためには、情報を持つ必要がある。判断しきる情報があればそもそも不要だが、そこまでいくと最初の「やれ」と言う指示から不要になるので堪えておこう。少なくとも「確認が必要かどうか」を判断するための情報はあって、最低限この情報を与えなければならない。もしくはその情報を当然知り得る環境を整えなければならない。ここで誤ってはいけないのは、後者の場合に「なぜその情報を知らなかったんだ」と責めること。情報を当然知り得る環境とは、例えばWikiやチャットなどに書く、ミーティングで言及する、などになる。環境を準備してそれで情報を得られていないとしたら、それは情報を知らなかったことを責めても意味はない。対象個人と環境とのミスマッチに過ぎない。個人よりは仕組みに帰属させたい。

仕事には数多くの呪いがある。呪いにかかると鈍くなる。呪いが解けたらどうなるか。鈍の対になるものは何か。鈍いには鋭い。鈍感には敏感。後者で居たい気はする。