「自分の仕事は終わったのに、なぜ進まない？」仕事を止めないために、最初に考えたいこと
前回の独りロールプレイ会議、タスク分解が意外と好評だったので続編です。
「この仕事なら、1週間あれば終わる」
何度もやったことのある仕事なら、「この仕事なら、1週間あれば終わる」、そう考えるのは自然です。
でも、実際に始めてみると予定どおりに進まない。
確認を待つ。
資料を待つ。
質問の回答を待つ。
途中で認識の違いが見つかる。
修正が増える。
気がつけば、最初に考えた1週間を過ぎている。
では、なぜでしょう。
今回も第1回と同じ4人に集まってもらいます。
- 先輩：経験から問題を見つける
- 自分：今の計画を考える
- 後輩：素朴な「なんで？」をぶつける
- 突っ込み役の同僚：計画に穴がないか見る
この4人で仕事を見直してみましょう。
「この仕事なら1週間で終わる」はずが、なぜ崩れる？
自分「この仕事、前回は6日で終わったから、今回は1週間あれば大丈夫」
先輩「自分の作業は？」
自分「もちろん1週間以内に終わります」
同僚「相手の作業は？」
自分「……相手の作業？」
後輩「確認してもらうとか、資料をもらうとかですか？」
自分「そうだけど、それくらいは1週間の中でできると思う」
先輩「前回、確認を待ってる時間があったよね」
自分「ありました。でも作業時間じゃないから、あまり気にしてませんでした」
同僚「でも、仕事が終わるまでの時間には入ってるよね」
自分「……確かに」
後輩「じゃあ、自分が作業する時間と、仕事が終わるまでの時間って違うんですね」
先輩「そうね。そこを分けて考えた方がいいよ」
自分「じゃあ、予定が崩れたら、作業時間の見積もりが間違っていただけじゃなくて、どこで止まったのかを見る必要があるのか」
同僚「その方が次回にも使えるよね」
タスクを作っただけで、仕事が完成するわけではない
自分「第1回で仕事を細かくしたから、今回はかなり分かりやすくなったと思う」
例えば、
記事構成を作る
↓
初稿を書く
↓
校正する
↓
公開する
というタスクにしたとします。
後輩「構成を作ったら、すぐ初稿を書くんですか？」
自分「そうだけど……」
後輩「誰かに見てもらわなくていいんですか？」
自分「ああ、確認が必要か」
先輩「前回も構成を作ったあと、確認が入ったでしょう」
自分「そうでした」
同僚「他にも無かった？」
自分「資料が必要な仕事なら、資料をもらわないと進められない」
後輩「資料が来なかったら？」
自分「待つ」
後輩「いつまで？」
自分「……決めてない」
同僚「ほら、そこ」
自分「そっか。タスクを作っただけじゃ仕事の進め方まで決まってないのか」
先輩「実際に進めてみると、最初には見えなかった問題が出てくるからね。そこを次のタスクに反映すればいいってことだね」
4人の自分で「どこで止まりそう？」を探してみる
自分「じゃあ、今回は最初から4人で仕事を見てみよう」
先輩：「前に、どこで止まった？」
先輩「前回、一番時間がかかったのはどこ？」
自分「確認、ですね」
先輩「誰の確認？」
自分「相手側の担当者です」
先輩「じゃあ、今回もそこは予定に入ってる？」
自分「入ってません」
先輩「前に止まったところなら、今回も止まる可能性があるよね」
自分「じゃあ、最初にそこを確認しましょう」
自分：「今回は、この順番で進める」
自分「月曜日に構成を作って、火曜日から制作。金曜日に完成予定」
同僚「火曜日から制作できる条件は？」
自分「構成が決まってること、かな」
同僚「誰が決めるの？」
自分「相手」
同僚「じゃあ、相手の判断が水曜日になったら？」
自分「……水曜の判断が出ないと制作に進めない」
後輩「じゃあ、火曜日から制作する予定なのに、構成を決める日が決まってないんですね」
自分「そういうことか」
後輩：「なんで？」
後輩「なんで確認する期限を決めてないんですか？」
自分「相手が見たら返事をくれるという前提で考えてた」
後輩「いつまでに返事が来ると思ってるんですか？」
自分「……そこは決めてない」
後輩「じゃあ、返事が来なかったらどうするんですか？」
自分「……」
先輩「こういう質問は大事だよね」
自分「確かに。『普通は返事が来る』で済ませてました」
同僚「本当に、それでいい？」
同僚「確認期限を決めるのはいいけど、相手にとって都合が悪かったら？」
自分「こっちの都合を押しつけることになるかな」
同僚「そうならないようにしないと」
先輩「確認する日が決まっていれば、相手も自分の予定を立てやすいよね」
後輩「じゃあ、『早く返事してください』じゃなくて、『この日までに見てもらえれば予定どおり進みます』って伝えるのはどうですか？」
自分「それなら相手にもメリットがあるね」
同僚「そうだね。期限を相手に守らせる話ではなく、仕事を予定どおり進めるための条件を共有する話に持っていけば」
「相手の判断が必要な場所」を探してみる
自分「じゃあ、仕事の途中で相手の判断が必要な場所を探せばいいんだ」
先輩「そう。今回ならどこ？」
自分「構成の確認」
後輩「他には？」
自分「初回案の確認」
同僚「最終確認は？」
自分「それも」
先輩「でも、最終確認で大きな変更が出たら？」
自分「遅い、それは困る」
同僚「じゃあ、大きな方向を決める確認はもっと前に置かないと」
自分「そうだな」
後輩「仕事によって、止まる場所は違いますよね？」
先輩「そうね。だから『ここを必ず確認する』と決めるんじゃなくて、今回の仕事でどこに判断が必要かを探さないとね」
自分「Web制作ならデザインかもしれないし、原稿なら企画かもしれない。会社の仕事なら上司や他部署の判断かもしれない」
同僚「だから、自分の仕事を4人で見て探すって事ね」
「期限を切る」のではなく、仕事が進む条件を最初に共有する
自分「じゃあ相手には、『○日までに返事をください。返事がなければ進めます』でいい？」
同僚「それはちょっと…」
自分「どうして？」
同僚「相手からすると、自分の都合で期限を押しつけられたように聞こえるんじゃないかな」
先輩「こう伝えたら？もし修正点がございましたら、○月○日○時までにご指示ください。特にご指示がなければ、当初の進行表に沿って、このまま次の工程へ進めさせていただきます」
後輩「これなら、いつまでに見ればいいか分かりますね」
自分「こっちも、いつまで待てばいいか分かるし」
同僚「そう。期限は相手を急かすためではなく、次に進める条件を共有するために使う」
先輩「そして、これはできるだけ仕事の初期に話して相互確認しておく事ね」
自分「仕事が始まってから突然言うより、最初の進行表や打ち合わせで決めておく方がいいね」
「意見がなければ次へ進む」は、お互いのルールにする
後輩「でも、それって自分が相手に確認してもらうときだけですか？」
自分「どういう意味？」
後輩「相手から原稿や資料をもらって、自分が確認するときは？」
先輩「そこも同じにしないとね」
自分「どういう事ですか？」
先輩「『○日までに資料をいただければ予定どおり作業します。内容について確認事項があれば連絡します』」
同僚「そして、自分が確認する期限も決める」
自分「なるほど。相手だけに期限を守ってもらうんじゃないってことか」
後輩「お互いに、いつまでに判断するか決めるんですね」
先輩「そう。一方的なルール運用にしないって事ね」
自分「相互条件にするわけですね」
「自由にする部分」と「決めておく部分」を分ける
後輩「相手から原稿が来たら、それを全部編集するんですよね？」
自分「そのつもりだけど……」
同僚「何文字でも？」
自分「決めてないけど」
同僚「画像は？」
自分「それも決めてない」
後輩「ものすごく大量に送られてきたら？」
自分「限界はあるよな…。大量だったらできないかも…予定が崩れるな」
先輩「なら、自由にしてもらう範囲を先に決めればいいよ」
例えば、
原稿は○文字まで
画像はJPEGまたはPNG
縦横○px以上
○MB以内
対象ページは○ページまで、とか。自分「自由にしてください、じゃなくて、この範囲で自由にしてください、か」
同僚「そうだね。自由と無制限は違うからね」
後輩「テンプレートから選ぶ部分と、自由に作る部分を分けてもいいですね」
先輩「その方が、仕事をする側も頼む側も分かりやすいね」
大きな変更と小さな修正を分けておく
自分「修正についても決めておいた方がいいかな？」
先輩「特に制作物はね」
後輩「全部完成してから、『やっぱり最初から変えたい』と言われたら？」
同僚「それをOKしたら、最初に決めた予定の意味が無くなっちゃうよね」
自分「じゃあ、大きな変更は早い段階で確認する」
先輩「そう」
自分「誤字を直すとか、文字を変更するとかは？」
先輩「それは軽微な修正」
同僚「大きな変更と小さな修正を、同じ『修正』として扱わない方がいいよね」
例えば、
大きな変更
- 構成変更
- デザイン方向の変更
- コンセプト変更
- 作業範囲の追加
小さな修正
- 誤字修正
- 文章の変更
- 数字の変更
- リンク変更
- 画像差し替え
自分「これなら、どの段階で何を決めるのか分かりやすいな」
「間にいる人」が増えたら、誰が判断するか確認する
後輩「確認する人が3人いたら、3人全員の返事を待つんですか？」
自分「そうなる場合もあるな」
同僚「その3人の意見が全部違ったら？」
自分「決まらないし、進まなくなるかも」
先輩「じゃあ、意見を出す人と、最終的に判断する人を分けられない？」
自分「なるほど」
後輩「作業しない人は、いない方がいいんですか？」
先輩「必要な人ならいた方がいいけど。でも、情報を伝えるだけの人が何人も入ると、話が変わってしまうことがある」
同僚「『誰が作業するか』だけじゃなく、『誰が判断するか』を決めておかないと」
自分「そこが曖昧だと、また仕事が止まるな」
仕事が止まったら、「誰が悪い？」より「何が足りなかった？」
それでも仕事は止まる事があります。
自分「今回は相手の返事が遅くて、予定がずれた」
先輩「じゃあ、次回はどうする？」
自分「確認期限を最初に決める」
後輩「なんで最初から決めなかったんですか？」
自分「今まで必要だと思わなかったから」
同僚「じゃあ、今回必要だと分かったなら、次回は決めておけるね」
自分「仕事が止まったこと自体は変えられないけど、次回は少し改善できる」
先輩「それでいいね」
後輩「仕事が止まって失敗、じゃなくて、次の仕事の材料にもできるんですね」
同僚「ただし、同じところで何度も止まるなら、そこはちゃんと改善しないとね」
自分「なるほど」
実行して分かったことを、次のタスクに持っていく
自分「最初に全部完璧に決めなくてもいいんだ」
先輩「実際にやらないと分からないこともあるからね」
自分「じゃあ、最初のタスクを作る」
↓
実行する
↓
問題が起きる
↓
タスクを直す
後輩「次回は最初から直したタスクを使うって事ですね」
同僚、「そして、それを繰り返す」
例えば、
「ここで確認が必要だった」と分かったら、次回は確認タスクを追加する。
「確認に3日かかった」と分かったら、確認期限を設定する。
「原稿が想定より長かった」と分かったら、文字とかの条件を決める。
「修正が何度も往復した」と分かったら、もっと早い段階で確認する。
自分「タスクそのものを、仕事をする度に改善していくわけだ」
先輩「そうだね」
「予定どおり進める」より、予定を改善できる仕事の進め方を作る
後輩「じゃあ、最初から完璧な予定を作らなくても良いって事ですか？」
先輩「それで良いよ。実際にやってみないと分からないこともあるからね」
自分「でも、同じところで何度も止まるなら？」
同僚「そこは次の仕事で変えればいいんじゃないかな」
自分「仕事が止まっても、そこで終わりじゃないんだ」
先輩「そう。次の仕事を少しやりやすくする材料にすればいい」
大切なのは、最初から完璧な計画を作ることではありません。
目標を決める。
仕事をタスクに分解する。
実際にやってみる。
問題が見つかったら、タスクや進め方を変える。
そして、また実行する。
この繰り返しで、少しずつ自分の仕事の進め方ができていきます。
今回の記事を読んだら、今進めている仕事を1つ選んで、
「この仕事は、どこで止まりそう？」
と4人の自分に聞いてみてください。
先輩なら何を思い出す？
後輩なら何を質問する？
同僚ならどう突っ込んで何を疑う？
そして、自分はどう進める？
まずはそこからです。
次回は、「仕事が予定どおり進んでいる」とは、何を見れば分かるのか？を考えてみます。
