依頼を受けた仕事の「仕様」を確定させる

 私はメーカー勤め

私はメーカーの法務担当をしています。日々、売買についての契約書等に目を通したり、困った社員さんの相談に乗ったりしています。メーカーですので、売買の話は日常茶飯事です。

売買取引の常識
何かの品物を作ってお客に売るとします。その製造に関して、お客との間で、どのような物を、どれくらい、いつまでに作って引き渡すかを決めてから製造に取り掛かります。そういった取り決めの書面、仕様書や発注書などですが、それを取り交わさずに引き渡すことは、メーカーとそのお客との間での取引であれば、まずしません。

仕様書無しで引き渡すことは、製造するメーカーも、買い入れるお客も、それぞれ大きなリスクを負います。「え、こんな風に製造されるとは思わなかった…」「そんな物を求めていたんですか…」と、お互いに思惑が異なると、製造するメーカーはさらなる改造をすることで手間と時間が余計にかかります。お客側も、締め切りまでに物を手に入れられず、その物を使って転売しようと考えていた場合にはその売り先にも迷惑をかけることになります。

つまり、製品を作り始める前に詳細まで取り決めておくのは、製品の売買をする上では常識中の常識なんですね。

非常識なことが日常に・・・
仕事の依頼を受けて、その仕事を依頼通りに遂行するという関係も、さすがに売買取引ではないものの、共通するものが多いと思います。なのに、常識からはまったく外れた手順で仕事が流れていることが一般的にはよくある話かと思います。

まず、どのような仕事をして欲しいかという、仕様書にあたるような説明がきちんとなされないことが多く、仕様書に書いていないことは察して欲しいという話がまかり通ってしまっている。そして、どれだけ欲しいというのも、言われないこともありますね。そして、それは、依頼を受けた側が確認すべきこととして思われていることが多い。会議資料が何部必要かは、その会議の参加人数を調べれば分かることだろう、といった具合。さらに、いつまでというのも明確でないことがよくありますよね。私がよく言われるのは「なる早」。引渡希望日に「なる早」と書いてある注文書はあまり見ないです。

発注書、発注請書の仕組み
あやふやな条件で話を進めてしまいお互い損害を被ってしまうことを避けるための仕組みとして、買う側は発注書をきちんと作り、売る側も発注請書を作るわけです。これはもう取引の基本中の基本。さらには、もし質や量が不足していたらどうするか、他の人に迷惑をかけたらどうするか等の周辺情報も別途基本契約という取決めをして、お互いのリスクを最小限に抑える仕組みを整えるわけです。

翻って、社内の仕事の受発注は？
まさか、日々の仕事の依頼にそこまでの契約書類を取り交わすことまでは必要ありませんが、少なくとも「どういう物を」「いつまでに」「どのくらい」欲しいのかは教えてくれないと、上の売買取引の考え方でいくと危なっかしくて引き受けていられませんよね。でも、それらが抜け落ちた状態で依頼が来ることがしょっちゅうではないでしょうか。

GTDの「処理」はそのリスクを回避する
GTDの「処理」というプロセスは、依頼された仕事をどういった形で返すか、製品で言うと「仕様」を確認するプロセスです。GTDでは、依頼を受けた本人がその確認をするという想定ですが、私は依頼主と直接話したりメールで聞いたりして、とにかく仕様を確定させます。「では、このような表にまとめて、来週の火曜日までにお送りします」といった具合です。これが、製品の売買取引での発注書発注請書のやりとりと同じ効果があり、あとで「こんなはずじゃなかった…」と言われない、「そういう意図で依頼されたんですか…」と言うことがないようにしています。

ここまでやるか？という意見もありそうですが、「察する」「空気を読む」「行間を読む」という力に頼った方法をとる危険性を考えれば、むしろここまでやるのが自然ではないかと私は考えています。