私は(というか私のチームは)現在システムの設計をしている。漸く外部の仕様が固まってきたので、週次の打ち合わせ自体は終了した。とは言え実際に詳細設計を進めていくと、「あれ?これどうするんだっけ?」という新しい課題はどんどん登場する。
基本的に外部設計さえ決まれば、あとはどうやって内部で処理するかを決めれば良いはずなのだが、結局内部の設計に引きずられるようにして、外部設計にも影響が出ることがほとんどなので、お客さんに合意を取る必要がある。
また、私の場合はまだまだ若手社員という身分であるので、お客さんに確認する必要がないことでも、自分の上司に確認を取らなければならないことも多い。というかほとんどがそうである。今の私には決定権はないのだ。設計工程のほとんどの仕事は決めることなのだが。
そんなことは協働者だって百も承知のはずだが、なぜか私の上司ではなく、私に質問を投げかけてくる。
例えば、その質問の決定権がもっとも遠いお客さんにあった場合、協働者に対して回答をするまでの模範手順はおそらく下記のようになる。
1.協働者からの質問を上司にエスカレーションする。
2.お客さんと調整をする。
3.お客さんから回答を受領する。
4.回答を協働者に展開する。
そして、実際に内部処理の設計やコーディングを進めるのは協働者のため、作業の進捗に影響が出てしまうのである。概ねお客さんへの質問の回答は2週間ぐらいかかる。だからちょっと想定外の問題が起こったら後工程に遅れが生じるのである。
ただ、私の場合は上記手順とは順序が異なり、下記のようになる。
1.回答を協働者に展開する。
2.協働者からの質問とそれに対する回答を上司にエスカレーションする。
3.お客さんと調整をする。
4.お客さんから回答を受領する。
5.協働者に決定連絡をする。
こうすることで後工程への遅れはかなり軽減できる。
いやいや、もしお客さんからの最終回答と自分の回答が違っていたらどうするんだ?と思う人もいるだろう。無論、手戻りが発生する。下手をすれば余計な作業が発生した分だけ正式な手順を踏んだ場合よりも作業は遅延してしまうかもしれない。
だからこそ、自分に権限がないことが明らかな問題に回答することをためらう人は多いと思う。新入社員の時に、事前に上司に確認することの重要性を説かれた人もいるだろう。
ただ、そんなものは理想論でしかない。仕事というものはいつだって限られた時間の中で成果を出さなければならないのだ。そして、組織の中で業務スピードを上げるには確認作業を少しでも少なくするしかない。
確認を減らす、というのはリスクである。ただしそのリスクの大きさは確認する内容によってまちまちである。私だって全ての質問に対してとりあえず即答してしまうわけではない。それではただの怖いもの知らずのバカである。
ただし、自分の中で許容できる範囲のリスクだと判断でき、かつ上司の回答やお客さんの回答が今までの傾向から推測できたのであれば、それを暫定的に回答とする。ちゃんと論理的な推測の上で出された回答が自分の中にあると、上司やお客さんも説得しやすい。
逆に小さいリスクを避けすぎていると、仕事の効率は必ず落ちていく。新入社員なら1にも2にも確認が正しいのかもしれない。(私は初めからほとんど確認しなかったが。)しかし、少しずつ自分の頭で判断してうまくリスクと対峙していけるようにならなければ、永遠に仕事が出来る人にはなれないだろう。