知的生産の荒野をゆく：タスクの依頼・実行の基本
書きつくされた「仕事の進め方」をあえて書く
「知的生産」とは、「見渡す限り暗闇の荒野」に旗を立てて水脈を探す仕事に近いと思う。それは答えのない暗闇で、ただ自分が正しいと信じる方向に進むための道標を探す旅だと思う。
「コンサルタント」という仕事に復帰して、早2ヶ月が経過した。
およそ2年ぶりにマーケティングの現場に戻り、仕事の感覚を取り戻すうちに、言語化されていない「仕事の進め方のコツ」があることを思い出した。
知的生産の現場では、しばしばイレギュラーが発生する。
「それ、先に教えてくれていたらもっと楽に仕事進められたのに！」
「その前提、先に確認しておけばこんなに時間かけなくてすんだわ…」
「思ったよりも工数かかってしまって、しんどいスケジュールに…」
雑な依頼、雑な受諾、雑な進行によって膨れ上がった工数は人を疲弊させる。
自分が学生の頃から数えて約6年、知的生産のタスクを請けたり依頼したりしてきたが、何度も何度も失敗をした。過去にも同じ目にあったのに…というような手痛い失敗を繰り返してしまうこともあった。
そこで、自身の備忘録も兼ねて、知的生産の現場で働く後輩達に役立つTipsを作ることにした。
すべての知的生産に関わる人に敬意を表して、なにかの役に立つことを願う。
■依頼の基本：仕事は「線」で依頼する
依頼者に求められるのは、「リテイクの必要のない完璧なアウトプットを出させる依頼」をすることだと思う。
「依頼」の章で伝えたいことはただ一つで、「依頼時に手を抜いた分の工数は、締切の時に自分に返ってくる」ということだ。
特に、タスクを依頼される立場の人間は「仕事の全体観」やそもそも「働くことのマインドセット」が未熟な人も多い。自分もそうだった。
そんな未熟な人でも「一定水準をクリアしたアウトプット」を出せるようにするには、適切な依頼と中間フィードバックが重要だ。
では、適切な依頼とは何か？
私は「仕事を【線】で伝えること」に収束すると思う。
タスクは一見、プロジェクトの成果物を構成するひとつの「点」に見える。しかし、どんなタスクも、孤立して存在しているわけではない。必ず前後の繋がりを持っている。
依頼するタスクの全貌を示し、前提を伝えること。まずはこれを意識することから始めよう。
プロジェクトの背景・目標を説明する
あなたがそのタスクを依頼するのはなぜか？（本当に必要なタスクか？）
そのタスクはプロジェクトにおいてどのような意味を持つのか？
どういうアウトプットが得られれば、タスクは完了したと言えるのか？
この3つの問いの答えをそのままタスクを請ける側に伝えてほしい。
タスクの概要のみを聞かされても、請けた側にはその目的や合格ラインがわからない。
ゆえに、依頼者と実行者の間でアウトプットのイメージ・水準がズレる。
まずは、依頼の前に、そのタスクがプロジェクト全体の中でどういう位置づけにあり、どの程度の水準を求めているのかをしっかりと言語化することから始めるべきだ。
タスクの背景を説明することは、ただの情報共有だけでなく「目標の共有」につながり、タスク実行者のモチベーションの増加にもつながる。
「ただレンガを積むだけの単調な仕事」と思って働くか、「今後100年に渡ってこの国を豊かにする橋を作る仕事」と思って働くか、でモチベーションには大きな違いが発生するだろう。
タスク実行者のモチベーションを喚起することはより品質の良いアウトプットにつながる。これだけの手間で質が変わるなら、依頼者はよほど時間がない状況を除けば、毎度プロジェクトの全体像を伝えることを癖付けるべきではないだろうか？
タスクの概要を説明する
しっかりとタスクの背景が伝わったら、次にタスクの概要を伝える。
やるべきことは主に以下の3点だ。
・アウトプットイメージを示す
・作業手順を伝える
・アウトプットの水準（粒度）を伝える
既に近いイメージのアウトプットがあればそれをまず見せることが重要だ。あれこれ説明する前に「これを作ってくれ」とイメージを共有してしまった方がタスク実行者に無用な想像をさせずに済む。
続いて、そのアウトプットをどう作るか？の手順を伝える。
これは依頼される側のリテラシーやスキルによってどこまで伝えるかは調整ができる。
スキルがある人への依頼ならば「プロセスは任せる」として問題ないだろうし、伸びしろのある新人への依頼ならば、箇条書きベースで手順を示してやるのがいいだろう。
これを逆転させてしまうと、悲しみが発生するので注意（スキルのある人の時間を無駄にし、初心者を暗闇に放り出すことになる）。
そして、今回必要としている粒度を伝える。
手本として示したものが詳細な調査データだったとして、そこまでの工数をかけなくてよい場合はその旨を伝える。逆に、簡易な調査項目ではあるが深堀りしてほしい場合はその旨を伝える。
この3点を押さえることで、いざ上がってきたアウトプットの水準が、求めていたものから大きく逸脱してしまうリスクを防ぐことができる。
納期を設定する
最後に、納期は必ず具体的な日付で設定するべきだ。
できれば、時間帯まで指定した方がいい。
たとえば「来週中」と依頼した場合、人によって週末の概念は異なる。
「タスクの美学」がわかっている人であれば、水曜には一次提出をして木曜に修正指示をもらい金曜にFIXする、といったようなスケジューリングができるだろう。
しかし、初心者は金曜の夜中に一次提出をする。最悪の場合は日曜の夜になるかもしれない。月曜の会議で使うためのアウトプットだったのに、月曜になって蓋を開けて見たら全く見当違いのものだった、という事になっては笑い事では済まない。
このような事態を避けるために、依頼者側の方で納期を具体的に示すことが重要だ。
「真のデッドタイム」ではなく、「軌道修正が可能な範囲」を締め切りとし、タスクを依頼しよう。
仕事の線：背景→概要・具体イメージ→納期
ここまで、タスクを依頼する側が留意することについて書いた。
「なんだ、当たり前のことか」「知ってるよ」と思った方は「知ってるかどうか」という目線ではなく、「自分が実行できているかどうか」という目線で振り返っていただきたい。
仕事の背景からきちんと説明して依頼している人はあまりいないのではないだろうか？「ただの作業」としてタスクの手順だけを依頼していないだろうか？その結果、あなたの部下はつまらなそうに仕事をしていないか？
また、アウトプットの粒度の説明を忘れて、必要以上のボリュームで提出されたり、過小な内容しか上がってこなかった経験はないだろうか？それによって納期が圧迫され、疲弊した経験は？
ひとつでも思い当たるものがあるとすれば、それは全て依頼時に言語化していれば防げた事象だと思う。
依頼の精度を高めることを怠らないこと。これを心がけるだけで、きっとより良い依頼になると信じている。
■作業の基本：「時間通り」に「まっすぐ歩く」
さて、ここからはタスクを請けた側が、いかにして良い仕事をするか？について書いていく。
依頼される側が目指すのは、「リテイク0回での一発合格」だ。
そのためのコツを解説していく。
キーワードは「工数の見積もり」と「途中で相談」だ。
作業手順を分解し、工数を見積る
まずは依頼者から聞いた作業手順を、動作ベースに分解して、作業におおよそどれくらいの時間がかかるかを試算するところから始めよう。
どのレベルまで分解するかというと、
・○○（調査ツール）にログインする
・調査するための各種設定項目を入力する
・調査を開始、ツールの動作完了まで待機
・調査結果のCSVデータを出力する
・CSVのn行目～m行目を、調査資料のA~Eシートにそれぞれコピペする×5回
といった具合だ。
これを行うことで、「○○調査」というひとつのタスクが、どれくらいの作業時間がかかるかを把握することができる。
初めて行うタスクの場合は、どんな動作があるのか、どれくらいの時間がかかるのかがわからない場合もある。
そういう時は、実際に作業しながらひとつひとつの動作とそれにかかった時間を書き出し、タスクの完了までのおおよその時間を試算してみよう。
なぜ初めに試算をするかというと、「とりあえず作業開始をして数時間後、納期に間に合わないかもしれないことがわかった」という事態を防ぐためである。
試算した段階で納期を超えてしまう見込みであれば、すぐにタスク依頼者に相談をするべきだ。
タスクに取り掛かる前に「試算」をする癖をつけよう。
試算もまだうまくできないうちは、タスク依頼者に15分ほど時間をもらって一緒に試算をしてもらうといい。
自分の中で締め切りを細かく設定する
「試算」をしたら、次に意識すべきは「締め切り」だ。
試算をして作業の全体像が見えていれば、「○時までにここまで終わってれば余裕で間に合う」「○時にここまでしか進んでいないと結構ヤバい」といった進捗の良し悪しを判断する目安が持てる。
目安に則って、タスク依頼者の締め切りに間に合わせるための「中間チェックポイント」を自分で設定しよう。カレンダーツールに自分だけの予定を入れてしまうのがいい。
チェックポイントが「最終ゴール＝提出締め切り」だけだと、途中で進捗の良し悪しを振り返ることができない。
なんとなく悪そうだ、と思っても、「この1時間で超集中すれば終わる」「頑張ればなんとかなる」と根拠のない自信に飲まれ、結局間に合わないリスクが増加する。
夏休みの宿題を最後の1日で追い込んでやっていた人ほど、その可能性は高くなると思う。「追い込まれた自分」のパフォーマンスを過信してしまうからだ。私がそうだった。
チェックポイントを設定することは後述する「相談」のきっかけにもなるので、慣れない仕事をする時ほど設定することを心がけてほしい。
作業途中で相談する
作業を分解し、工数を試算し、締切を細かく設定したら作業に取り掛かろう。作業に実際に取り掛かると、試算のときには見えなかった色々なことが見えてくる。
例えば、下記のようなことだ。
・聞いていた前提を覆す要素が出てきた
・思った以上にツールの動作が遅く、ある手順で作業全体がストップする
・反復作業だと思っていた手順が実は毎回考える必要のあるものだった
これらは全て、見積もりよりも時間がかかるか、見積もりそのものを見直す必要を生む。見積もりが変わるということは「納期に間に合わない可能性が出てくる」ということなので、早急にタスク依頼者に相談しよう。
また、ありがちなのが「作業に熱中して求められていたアウトプットと違う方向に進んでしまうこと」だ。
初心者ほどやってしまいがちだ。熱の入れどころを間違えないように、作業が順調な時こそ、区切りのいいところで本来の目的に立ち返ろう。自分で締め切りにしたタイミングを振り返りに当ててもいい。「ズレてるかもしれない」と思ったらタスク依頼者に相談だ。
10分ほどもらえれば、自分が正しい道にいるかどうかがわかるだろう。
仕事の前後の繋がりを意識する
順調にタスクを進められたら、仕上げの段階だ。
最後に自分のアウトプットを見る人のことを考えて、表現を調整しよう。
自分のアウトプットを参照して、次の仕事を行うのは誰か。
Webマーケターの場合、次の工程にいるのは事業全体のPMや、施策を実装する制作・開発メンバーであることが多い。
彼らのリテラシーに合わせた表現に調整しよう。
例えば、エンジニアに向けて技術的な仕様の解説をすることは不要だし、事業全体のPMに対してプロジェクトの概要説明をするパートは不要だ。
実際にはタスク依頼者が調整することが多いが、先んじて調整しておくことでタスク依頼者の手を空けることができる。
自分のアウトプット・資料は誰が読むのか？を意識してみよう（わからない場合はタスク依頼者に聞いてしまおう。1分で済む）
タスク完了後、フィードバックをもらう
仕上げが終わったら、タスク依頼者にアウトプットを提出しよう。
ここまでで、きちんと締め切りを守り、都度相談をしてきたならば、大きな修正はないはずだ（よくあるのは、スライドの場合のページ番号の振り忘れや、EXCELの場合の枠線表示・罫線の入れ忘れだ）。
ここで一安心、仕事を終えてYouTubeでも見よう…としてはならない。
タスクを依頼される側に求められるのは「リテイク0回で完璧なアウトプットをすること」だ。タスクを振り返ることで、次回以降のリテイク数を減らすヒントが手に入る。
そのヒントを得るチャンスは、タスク完了後が一番アツい。なぜなら、タスク完了直後はタスクに関する記憶が新鮮で、つまづいたポイントやうまくいったポイントを「脳」が覚えているからだ。
タスク依頼者に、今回のアウトプットの良かった点と改善点を聞く習慣をつけよう。
また、自分でも振り返る癖をつけると良い。
タスク依頼者は作業中の様子まではわからない。自分が自分の良きコーチとなり、作業の質を上げるためのフィードバックを送るのだ。これを繰り返せば、たいていの知的生産の仕事で役立つ力が手に入るだろう。
■あとがき：より良いタスクの依頼・実行を
タスクの依頼・実行の基本はまとめられたと思う。
社会人3年目に突入した今頃になってようやく言語化できた。
自分がこれを早いうちから実践することができていれば、もっと早い段階から成果を出すことができていたように思う。
当時の自分に読んでほしい気持ちで書いたので、この文章がどこかの誰かにとって、知的生産の荒野を進むための道標になれば幸いだ。
■番外編：より良い仕事をするためのポイント
本筋からは逸れるものの、重要だと思う内容をまとめてみた。時間があれば読んでほしい。
■番外編1：タスク依頼フォーマットを作ろう
タスク依頼者がいちいち「えーっとタスクを依頼するときは何を伝えればいいんだっけ…」と考えることは非効率的だ。
事業・プロジェクトにとって最も簡潔かつ不足のないフォーマットを作り、都度、それに則った依頼をしよう。例えば以下のような形式があれば、常に依頼のクオリティを保てる。
・プロジェクトの目的・現状
・依頼したいタスク（1行で）
・タスクの意義・目標
・作業手順
・納期
■番外編2：タスクを依頼される人になるには？
タスクを依頼する側としては、「作業クオリティが高い人」に依頼したいと思うのは当然だ。
しかし、最初は誰もが初心者だ。それに知的生産の現場では玄人よりも初心者の方が割合は多くなる。
では、選択肢が「初心者」しかなかった時に選びたくなるのは誰か？
どんな簡単な仕事でも納期通りにタスクを完了できる人だ。
納期通りにタスクを完了してくれそうな人、とはどんな人だろうか？
細かく進捗を報告してくれる人だろう。
これなら、このnoteに書いた「作業途中で相談する」を実践すれば達成できる。
知的生産に携わる人にとって、自分のスキルの低さを認めて相談することはなかなかハードルが高いらしい（自分もそうだった）。だから、納期ギリギリになってタスクが終わらずに叱られる人が後を絶たない。
どんどん質問することをおすすめする。
■番外編3：納期を遅らせる勇気を持とう
「(社内)納期を遅らせることは悪いことではないよ」
かつての先輩に教えてもらって衝撃を受けた言葉だ。
初心者である自分が任されている仕事のレベルなんて、所詮大したものではない。だから、後ろ倒しになっても問題のない、余裕のある納期が設定されていることが多い。むしろ、相談せずに納期に無断で遅れる、当日・直前に間に合わないことを伝えることの方がよっぽど悪である。
きちんと見積もり、進捗の良し悪しを判断し、間に合わない可能性が出てきた時点で正直に相談しよう。大抵は、早めに相談したことを褒めてもらえる。
■番外編4：お客さん（アウトプットの享受者）と話す機会をもらおう
社内の先輩のみと仕事のやり取りをしているうちは、「先輩のメガネにかなう資料を作ること」が仕事だと思ってしまいがちだ。
しかし仕事の目的はいつだって「成果（売上・利益）を上げること」に帰結することを忘れてはならない。
クライアントワークの場合、アウトプットの享受者であるクライアントが資料を見て内容を理解できるかどうか、成果につながる行動を取ってくれるかどうか、が自社とのプロジェクト継続に大きく関わる（成果を出せないコンサルに継続投資する企業は稀だ）。
自身の仕事はどう活きるのか？喜ばれるのか？なんだか理解されていない感じなのか？その顛末を目撃する機会を得よう。MTGに出席するのだ。できれば自分の口で資料の内容を説明すると良い。
次回のタスクに緊張感が生まれ、また、クライアントの喜ぶ姿を見るために頑張るというモチベーションが生まれるからだ。