![見出し画像](https://assets.st-note.com/production/uploads/images/115310537/rectangle_large_type_2_4530265d75e988ee57a8ca4dc74bd2f4.png?width=1200)
フリーランスPMの備忘録:タスクが溢れないようにする工夫
この記事について
この記事は、フリーランスPMとして活動する筆者が
経験から学んだことを忘れないようにするための備忘録です。
私の身近でも、膨大なタスクに追われているPMをよく見かけますが、
そもそも何故PMのタスクは溢れやすいのかを分析して、
その対策として、私が日頃行っている工夫を記載します。
日々のタスク対応に追われるのではなく、
サービスの発展や、顧客への提供価値の最大化などの
PM本来の活動に注力できよう、少しでもお役に立てれば幸いです。
前提:この記事での「PM」について
フリーランスとして活動をしていると
会社ごとに「PM」が担う役割が大きく異なることを感じます。
この記事でのPMは
ITシステム開発プロジェクトのPMを指しており、
開発チームのマネジメントを主業務としつつ
関連するチーム(インフラ、テスト等) との連携や
顧客への対応・交渉などを行う役割を持つものとします。
「タスクが溢れる」とは何か
この記事内では
「抱えているタスクの数が多すぎて、管理しきれていない状態」
を指します。
※タスクが漏れて、いつの間にか納期を過ぎている等
なぜPMのタスクは溢れやすいのか
この記事を読んでいただいている人は
PM本人、またはPMが身の回りにいる人だと思うのですが、
多くのPMは、忙しそうにしてはいないでしょうか??
先ずは、なぜPMのタスクが溢れやすいのかから考えていきましょう。
PMのタスクについては、下記のような特徴があります。
1. タスク規模は小さいが、発生数が多い
PMはプロジェクトに関わる全てのチームのハブとなるポジションのため
コミュニケーションをする相手が非常に多いです。
※顧客、開発チーム、インフラチーム、テストチーム、営業部門等
上記の各チームが、他のチームに対して何らの働きかけをしたい場合に
PMを介して依頼するケースが多いので、
コミュニケーションをするチーム数が増えるほど
コミュニケーション系のタスクが多く発生します。
また、それ以外にも
働きが不十分のチームに対してサポートを行ったり
プロジェクトの将来性を考えて啓蒙活動をしたり
緊急時に先頭に立って指示を出したり
失敗した時に責任を取ったりと、
非常に幅広い働きを求められます。
※プロジェクトによって大きく異なりますが。。。
ただし、あくまでもハブ的なポジションですので
エンジニアが数人月の開発タスクを担当するような
大きなタスクを対応する機会は少ないです。
そのため、小さいタスクが大量に発生するケースが多いと感じています。
2. タスク優先度をコントロールしにくい
PMが担当しているチーム間コミュニケーション系のタスクは
納期指定はされませんが、依頼者の期待納期が非常に短い場合が多いです。
(要件定義に関する質問、スケジュールの確認、不具合の対応方針相談等)
というのも、依頼者側からするととても簡単なタスクなので、
依頼したら直ぐに回答を貰えると思っているケースが多いです。
ただ、PM本人からすると
その簡単なタスクを大量に依頼される上に
自分自身のタスク(プロジェクトの計画立案等) も持っているため、
勝手に即レスを期待されても苦しい部分があります。
※依頼者側は簡単だと思っていても、実際はそうではない場合も多いですし…
しかし、各チームのハブとなるポジション故に
PMが対応を行わないとチーム間コミュニケーションが進められず
タスク依頼したチームの業務がストップするケースもあります。
そうなると今度は顧客との金銭トラブルに発展するケースもあるので
PMも優先対応をせざるを得なくなります。
上記のように、PMのタスク優先度は
タスク依頼者の都合によって決められてしまうケースが多いです。
3. タスク実行のためにまとまった時間が取りにくい
会社にもよるとは思いますが
会議を主体としてチーム間コミュニケーションをする現場は
現在でも多いように感じます。
会議を開催すると30~60分は消費しますが、
その会議で決定する結論は、文章数行分であることが多く
あまりコストパフォーマンスの良いコミュニケーション手段ではありません
しかし、難しい話題に関して議論を行ったり
相手を説得したり、意見を引き出したりするためには
直接顔を合わせてコミュニケーションできる会議は有用ですし、
友好関係を築くことにも効果的です。
また、会議も適切な頻度で開催するのであれば
自分のタスク実施時間も確保しつつ、
質の高いコミュニケーションを実現できるでしょう。
しかし、PMの場合はハブ的なポジションである関係上
各チームが開催するあらゆる会議に招集される場合があり、
一週間のスケジュールが会議でミチミチになりやすいように感じます。
そうなってしまうと、
一日会議をして何となく仕事をした気分にはなるけれど、
自分のタスクが全く消化できておらず、残業でカバーとなりがちです。
上記3つの特徴により、
PMは実際に抱えているタスク以外にも
「タスク実行するための追加コスト」を支払わされます。
「タスク実行するための追加コスト」とは
1. タスク内容を思い出すコスト
過去に発生したタスクに着手する時に
そのタスクの内容を思い出すコストを指します。
他チームからの差し込み対応をする等により
対応できなかったタスクに再着手する度に発生します。
更に、今優先的に対応するべきタスクを探す時にも
タスクリストに記載された多くのタスクの内容を思い出す必要があり
日頃の仕事の中で無意識的にコストが発生します。
PMの場合はタスクの数が多いので
このコストの発生頻度が高くなりがちになります。
2. スイッチングコスト
現在進めているタスクを中断して
他のタスクに着手するコストを指します。
こちらも差し込みタスク等に対応する度に発生しており、
現在着手中のタスクをどこまで進めたか記録したり
新しく着手するタスクの内容について思い出したりと、
幾つかのコストが同時発生します。
また、集中が途切れてしまうこともデメリットです。
3. 脳内メモリコスト
対応中のタスクや、各タスクの状況等を
脳内のワーキングメモリの保持しておくコストを指します。
タスクをより早く処理しようとして
複数のタスクを並行して進めるマルチタスク状態になると、
複数のタスクに関する情報をワーキングメモリに保持することになります
更に、全てのタスクが完了しないまま
新しいタスクに着手してしまうと、常にマルチタスク状態になってしまい
脳内のワーキングメモリが開放されないままフル稼働となります。
これには時間的なコストはかかりませんが
人間は疲れるものなので、気づかないうちに作業ペースは低下します。
タスク実行するための追加コストによる影響
上記の「タスク実行するための追加コスト」は
発生頻度は高いものではありますが、
1回の時間的なコストとしては微々たるもので、
それが積み重なったとしてもそこまで大きな時間的コストにはなりません。
しかし、脳疲労の蓄積という観点では
とても大きなコストとなります。
あくまで私の経験をもとにした感覚的な意見ではありますが、
着手するタスクを決めるために、各タスクの内容や優先度を思い出すこと、
タスクを切り替えるために、そのタスクの詳細や進捗状況を思い出すこと、
マルチタスクを行うために、各タスクに関する情報を記憶し続けること。
上記のような「ワーキングメモリの保持・入れ替え」の行為が
脳疲労を加速させ、仕事のパフォーマンスに影響を与えていきます。
※もし脳疲労の蓄積によるパフォーマンスダウンを体感したければ
タスク管理ツールを使わず、全タスクを暗記で管理してみると
良いかもしれません。
脳疲労がPMのタスクを溢れさせる
「タスク実行するための追加コスト」によって引き起こされる
脳疲労によって、下記の様な流れでタスクが溢れていきます。
日々新しいタスクが発生する
しかしタスクを消化する時間が少ないので、タスクが溜まりがちになる
やがて「タスク実行するための追加コスト」により脳が疲れ、
更にタスク消化ペースが落ちるタスクの発生スピードを、タスクの消化スピードが下回る
どんどん抱えているタスクの数が増えていく
やがてタスク全体を管理をすることも間に合わなくなり、
タスクが溢れた状態となる
もちろん例外もあります。
会議が少なく十分にタスク実行する時間がある人や、
単純に仕事が早く、タスクを十分に捌けている人もいるでしょう。
または逆に、脳疲労など関係なく
純粋に仕事が多すぎて終わらないケースもあるでしょう。
本記事はタスクが溢れる原因の一例として考えてください。
ただ、ここまで記載させていただいた内容に心当たりがあれば
後述する対策についても、読んで試していただけると嬉しいです。
タスクが溢れることを防ぐ工夫
1. 先ずはタスクが管理された状態にする
チームのタスクとは別に、自分(PM)のタスクリストを作る
そもそもタスクが管理されていなければ
タスクが溢れていなくても、管理不能な状態になりますので
前提条件としてタスク管理は必ず行いましょう。
ただ、PM自身のタスクと、開発チームのタスクは
別々に管理するのがオススメです。
PMのタスクには
自分が担当している開発チームとは直接関わらないタスクが多々あり
一緒に管理とすると、タスクの種類が増えすぎて煩雑になります。
また、PMのタスクは発生・消化のサイクルが早く
ガントチャート等の、開発チームのタスク管理に適したツールが
合わない可能性もあります
そのため、PM自身のタスクのみをまとめた
タスクリストを用意してみましょう。
一日のはじめに、その日に終わらせたいタスクを決める
その日の業務を始める前に
その日に完了させたいタスクリストを作りましょう。
その日に必ず終わらせないといけないタスクや、
早めに処理しておきたいタスクをリスト全体からピックアップして、
小さなタスクリストを作ってみましょう。
それを作った時に、タスクの量に応じて
その日にどのくらいの差し込みタスクを対応出来るのか、
臨時ミーティングを入れられても大丈夫なのかが見えるので、
余裕がなさそうならそれらを無闇に引き受けないようにしましょう。
ただ、その日に終わらせると決めたタスクが
全て終わらない場合もあると思います。
その時は残業したり、焦ったりはせずに
自分のタスク消化スピードはそのくらいであるという
現実を受け入れる努力をしましょう。
※私もそうですが、自分が期待しているより結構遅いです。。。
消化スピードを把握できれば
どのくらいの量のタスクを引き受けられるのかも明確になり
引き受けたタスクは依頼者の期待通りに完了出来るようになるでしょう。
無闇に沢山のタスクを引き受けて納期に遅れてしまうより
適量のタスクを確実に完了させる人間の方が重宝されます。
先ずは自分の限界を認めて、そこから限界を広げる努力をしましょう。
どのようなタスクでも、リストアップしてから着手する
タスクの中には
発生してから数分で完了できてしまう軽微なものもあります。
※チャットの返信、電話報告等
これらのタスクであっても
先ずは一度タスクリストに記載をして、
優先度を考えてから対応するようにしてみましょう。
上記のような軽微なタスクは差し込みで発生することが多く、
タスク発生の度に即対応してしまうと
スイッチングコストによって脳疲労が加速します。
また、意外と即対応しなくても問題ない場合が多いので
先ずはタスクリストに追記して、いつ対応するかを決めましょう。
また逆に、しばらくは着手できないタスクについても
タスクを認識した時にリストアップするようにしましょう。
もしリストアップしないままにしておくと
タスクに着手はしないものの、忘れてしまうと漏れるので
頭の片隅でずっと暗記しておかないといけなくなります。
これはワーキングメモリの保持になるので、脳に負担がかかります。
タスクはとにかく1度リストアップして、
直ぐに着手しないものなら忘れて
ワーキングメモリを開放しましょう。
タスクをリストアップする時に、優先順位も決める
タスクが発生して、タスクリストに追記をする時に
そのタスクの優先順位も決めてしまいましょう。
タスクの優先順位の付け方は色々ありますが
個人的には、「タスクを一列に並べて、優先度が高いものを上にする」
方法が楽で良いと思います。
後述しますが、タスクは常に1つしか対応しないので
一列にすることに問題は無く、何よりも優先度整理が楽です。
また、常にタスクを優先度順に並べておけば、
新しいタスクよりも優先度の高いタスクだけ探して
その下にタスクを追記するだけで済みます。
こうすれば、それよりも優先度の低いタスクは
内容を思い出したりしなくても済むので、追加コストを抑えられます。
頻繁にタスク管理を行っても苦にならないツールを見つける
上記の工夫をする上で
タスク管理ツールの軽量さは非常に重要です。
ガントチャートのような高機能なツールですと
優先順位の入れ替えが発生する毎に線表も見直すので
その作業を日に何回も行うと、嫌になってきます。
また、自分だけが使うタスクリストですので
誰が見ても分かるように記載する必要も無く、
自分が見返した時にタスク内容を思い出せるようにするための
メモの箇条書きのようなものでも十分だったりします。
※ 私の場合はメモ帳アプリに箇条書きにしています
ただ、タスクリストにどこまでの情報を記載したいかは
人それぞれ異なると思いますので、
色々なツールを試して自分に合うものを見つけていただけたら嬉しいです。
余談ですが、
バックアップ機能があるタスクリストの方がオススメです。
後述しますが、本記事では着手中のタスク以外は
極力忘れることを推奨している関係上、
何らかの理由でタスクリストが消滅してしまうと
リカバリーが難しくなりますので。。。
タスクが完了したら、タスク管理ツールを開く
今着手しているタスクが完了したら
タスク管理ツールを開いて、そのタスクのステータスを完了としましょう。
※ステータスが存在しないツールもありますが
あなたの中で、「完了したタスク」と分かるようになっていればOKです
そして次に着手するタスクは
必ずタスクリストの中から1つだけ選び、着手しましょう。
これを習慣化すれば、下記のようなメリットがあります。
タスクリストに記載されたタスクしかやらないので
必然的に全てのタスクをリストアップするようになる。着手中のタスク以外については忘れられるので
対応中のタスクに集中できるその日に完了させたいタスクがどのくらい残っているか確認するので
自分の作業ペースが十分かも確認できる
(間に合わなそうなら、明日にまわしても大丈夫なタスクがあるか等のリカバリープランを早めに検討できる)
また余談ですが、
完了したタスクリストを作ってみるのも面白いです。
自分がその日にどのくらいのタスクを完了させたのかを可視化すると
小さな達成感が得られ、自分の仕事が前に進んでいる間隔を得られます。
これはやる気を養うために有用なことなので、
よかったら試していただけると嬉しいです。
2. 脳疲労を抑える
実行中のタスクは常に1つとする
沢山のタスクを抱えていると
早くタスク消化をしようとして
つい複数のタスクを並行して進めようとしてしまいます。
※気持ちはとても良く分かります。。。
しかし、人間の脳はシングルタスクしか出来ないので
実際にはマルチタスクは出来ておらず、
大量のスイッチングコストをかけて
シングルタスクで少しずつ進めている状態になります。
更に、平行対応中の全タスクの進捗状況を
ワーキングメモリに保持し続けることにもなるので、
脳疲労がどんどん加速していきます。
不要な追加コストの発生を避けるため
対応中のタスクは常に1つにしましょう。
…しかし、「対応中のタスクは常に1つにしましょう。」
という言葉を見て、あまり現実的ではないと感じた人が多いと思います。
PMの仕事では、そうもいかない現実があることはよく分かります。
ただ、幾つかのケースには対策がありますので
参考までにご紹介させてください。
ケース1:即レスを期待されるタスクへの対策
チャットの返信や、障害対応などが該当します。
他のタスクを進めている時に差し込みで発生するので
中断して対応するにしても、並行して進めるにしても、
追加コストは発生してしまいます。
これは先ず、
「一時対応だけすれば、後回しにできるタスク」なのか
「全てを後回しにして即対応するべきタスク」なのかを判断しましょう。
障害対応はもちろん即対応しないといけませんが
お客様からのご相談や、チームからの質問等々
重要ではあるけれども、1分1秒を争うほど急ぎではないタスクも
意外に多いと思います。
そのような場合は
先ず一時対応(確認する旨の返信等) を行って
タスクリストに追記をして、順番に処理していくことも可能です。
※完全に追加コスト発生は防げないですが、軽減はできます。
即レスをすれば短期的には相手を待たせずに済みますが
それによってタスク全体が滞ると、
長期的には相手を長く待たせることになります。
ケース2:相手の対応待ちになるタスクへの対策
他チームへの対応依頼系タスクが主ですが、
直ぐに結果がわからない施策等も、こちらに該当します。
ボールが相手に渡った後も
頭の片隅で覚えていないといけないので、
ワーキングメモリを消費してしまいます。
この場合は
・相手にボールを渡すまでのタスク
・相手が期待通りのボールを返してくれるか確認するタスク
の2つにタスクを分けましょう。
例えば他チームへの対応依頼を例にすると、
「相手にボールを渡すまでのタスク」は
そのチームに依頼を行うところまでのタスクとなります。
また、「相手が期待通りのボールを返してくれるか確認するタスク」は
相手が納期(又はその少し前) になっても対応完了報告をくれない時に
確認の連絡をするタスクとなります。
このタスクは実施日程をタスク作成時に決めてから、リストに追記します。
こうすることで、相手の対応完了を待っている間
そのことについて暗記しておかなくて済むので、
ワーキングメモリを開放することが出来ます。
ケース3:大きすぎるタスクへの対策
タスクのゴールが見えないような
不明確で時間がかかるタスクが該当します。
タスクが大きすぎるまま着手すると
そのタスクを進める中で新たなタスクが発生してしまい
いつの間にかマルチタスク状態になってしまう場合があります。
この場合はタスクを分割して、
各タスクの完了条件が明確になった状態にしてから
対応順序を決めて対応していけば良いのですが、
そう簡単に分割出来ない不透明なタスクもあります。
その場合は
・タスク内容を正確に把握する
・タスクの完了条件を明確化する
・タスクを分割する
等のタスクを作成して、
先ずはタスクの分割が完了するところまでを目指してみてください。
タスク分割が完了する時には
各タスクの完了条件も明確になっており、
順次対応を進められる状態になっているはずです。
ケース4:時間がかかるタスクへの対策
資料作成など、完了までの時間が長いタスクが該当します。
完了までの時間が長いと
その分、差し込みタスクとバッティングする可能性も高まります。
可能であるなら、まとまった時間を確保して
そのタスクが完了するまで集中できるのが望ましいですが、
そうではない場合は複数ステップに分割してみてください。
スライド資料作成であれば
・そのスライドで伝えたいメッセージを決める
・メッセージを伝えるためのストーリーを考える
・ストーリーを分割して、各スライドで伝えることを決める
・スライドのラフデザインを作る
・スライド全体のレイアウトを整える
・伝えたいメッセージが伝わるか確認する
などの複数ステップに分けられます。
このようにすれば、
各ステップの完了までに必要な時間が短くなるので、
完了まで集中して対応できる可能性が高まります。
ケース5:不安からマルチタスクになってしまうことへの対策
着手していないタスクのことが不安で
ついそのことについて考えてしまう等、心理的な問題が該当します。
また、タスク実行中に「本当にこの方法で良いのだろうか」と
迷うこともこちらに該当します。
実際にタスク着手していなくても、
考えてしまうだけで脳内ではマルチタスク状態になりますので、
脳疲労は加速してしまいます。
強い自制心を持って迷わないようにする。
といった精神論では上手くいかない場合が多かったので、
ある程度効果があった対策を記載します。
先ず1つ目は、
その問題について考えるタスクを作ることです。
考えたくなったら、考えるタスクをリストに記載して
現在着手中のタスクをどこまで進めたら、
考えるタスクを行うかを決めます。
こうすることで、考えるタスクに着手するまでは
1つのタスク実施に集中します。
2つ目は、
次のタスクが始まる時間にアラームをセットして、
それが鳴るまでは1つのタスクに集中することです。
私の場合は、次の会議までの時間に
実施中のタスクに集中するために使うことが多く、
会議のファシリテーションをどう進めるか等の雑念が浮かぶのを
防止するのに活用しています。
※会議準備等がある場合は、会議時間の5分前等にアラームセットします。
余談:睡眠を大事にする
最後は対策ではありませんが
脳疲労を抑えるためには、眠ることが非常に重要なので記載します。
先ずは日々の睡眠時間の確保です。
睡眠不足による脳への悪影響については
様々な書籍がありますので、詳細はそちらに任せるとして
ここでは個人的に工夫したことを記載します。
自分に合った睡眠時間を見つける
→レム睡眠・ノンレム睡眠のサイクルの都合上、
基本的には7.5時間が適切な睡眠時間と言われていますが
ここには個人差があるようです。
どのくらい寝るとスッキリするのかは感覚的にわかると思いますので
色々試してみてください。
※私の場合は8時間眠るととてもスッキリします。スムーズな入眠を促す
→これについては様々なことを行っていますので
簡単に箇条書きにいたします。
・部屋を出来るだけ真っ暗にする
・寝る前に決まったストレッチメニューを行う
・睡眠に適したアロマを使う
※無印良品のロールオンフレグランスは使いやすいです。
・朝に陽の光を浴びる
・朝に15分程の運動をする
※私はラジオ体操やスクワット等を行っています。昼寝をする
→私の場合はフルリモートで勤務していますので
お昼休みに15分程ベッドで眠っています。
完全に寝られなくても、目を閉じているだけでも効果があるそうです。
睡眠は仕事のパフォーマンスのみならず
メンタルや健康等、人生に大きな影響を与える要素です。
もしあなたが7時間の睡眠時間を確保出来ないほど忙しいのなら、
睡眠の重要性について書かれた書籍を購入することをオススメします。
おまけ. 脳疲労を防止する以外の工夫
前述した②までを行っていただければ
不要な脳疲労を抑えて、パフォーマンス低下を防ぐことで
ある程度タスクが捌けるようになると思います。
※もちろん個人差はございますが。。。。
ここまでで本記事で最もお伝えしたかったことは書き終えましたが、
ここからは、パフォーマンス低下とは異なる角度から行っている
タスク溢れを防ぐ工夫について記載させていただきます。
※おまけですので、今までの文脈とは若干繋がらない部分もございます。
もし宜しければ、最後までお読みいただけると嬉しいです。
不要なミーティングはなるべく避ける
先ず誤解を生まないように記載させていただきますが
ミーティングによる対面コミュニケーションは、
複雑な内容を伝えやすいだけでなく
信頼関係の構築等にも有効な、優れたコミュニケーション手段です。
ただ、1時間のミーティングを行った時に
その会議で決まった結論を文章にすると数行程度になる場合が多く、
もしもチャット等で済ませられた場合には、数分で済む場合があります。
そのため、不要なミーティングについては
出来るだけ参加を避け、チャット等の低コストな手段で代用できれば
あなたのタスク実施時間を大きく確保することが出来ます。
どのような会議が不要かについては意見が分かれると思いますが
ここでは私個人が不要と思うタイプの会議を記載します。
文章コミュニケーションで結論が出せる、簡単な問題を取り扱う会議
→図解やデータ等の補足資料を使用しないと理解が難しい問題や、
相手の理解状況を見ながら補足説明を入れる必要がある場合など、
ミーティングでないと取り扱えない複雑な問題以外は
チャット等のみで完了できる場合が多いです。
→例外として、初対面や新人教育など
相手の心理的安全性に配慮する必要がある場合は
簡単な問題でもミーティングで直接お話するのがオススメです。会議を行っても結論が出ない可能性が高い会議
→ブレスト会、悩み相談会、
とりあえず話そう的なミーティングがこちらに該当します。
これらは意外に開催依頼が来ることが多いのですが、
可能であるならばチャットのみで済ませる方がオススメです。
事前に信頼関係と心理的安全性が整っていれば
チャットのみでも十分に議論可能な話題ですので。。。1時間以上の会議
→その会議で決めたいことが事前に明確になっていれば
多くの場合は30分程で話しきれる場合が多いです。
→しかし、最初から会議時間を1時間に設定していると
1時間ギリギリまで会議時間を使おうとする人が時々いるので
時間的に損をする場合があります。
これらの会議を避けることで
私の場合はそれなりにタスク実施時間を確保できましたが、
その会社やチームの文化によって会議の価値観は大きく異なりますので
空気を読んだ選択をしていただければ幸いです。
仕事を安請け合いしない
日々の仕事をしていると
誰も担当が居ないタスクが存在していたり、
新しいチャレンジとしてタスクが新規発生することがあります。
もちろんこれらの仕事は誰かがやる必要はありますし、
そこに手を上げて、率先して対応していくことは
チーム全体にとって有意義なことです。
ただ、それらを引き受けた結果
引き受けたタスクも、元々持っていたタスクも納期に間に合わなければ
残念ながらあなたの評価は下がります。
なので、「安請け合い」はやめましょう。
先ずは自分が今担当しているタスクを確実に対応して
1日8時間よりも早く担当タスクを終えられるように工夫しましょう。
その後に、新しいタスクを、確実に出来る分だけ引き受けましょう。
それが出来るまでは、
タスクが落ちていることをチームに問題提起する程度に留めて
優秀な仲間に助けてもらいましょう。
タスク納期よりも早く終わらせて、提出は待つ
タスクの完了報告をすると、
多くの場合は、次のタスクを依頼されます。
また、予定納期よりも早くタスクを終わらせても
必ずしも依頼者に喜ばれるかは分からない上に、
次回以降の納期はより短くなる場合があります。
※次回以降はその納期が普通になるので
苦しくなった割に得することがありません。
一方で、タスクを納期に合わせて終わらせようとすると
想定よりも時間がかかり、納期に間に合わない場合もあります。
納期遅れは、本来不要なはずの調整コストを生み出すので
あなたのタスク総量が増えて、溢れるリスクが高まります。
納期のあるタスクは早めに着手して、
先ずは完了までに必要な時間の目処を立てましょう。
そして、もし終わらせられそうならは早めに終わらせて、
依頼者にとって都合が良いタイミングを見計らって報告しましょう。
これにより、より確実に納期までにタスク完了できるようになり、
かつタスク発生スピードを無理に上げてしまうこともなく、
更に依頼者からの信頼も得られます。
まとめ
本記事では主に
脳疲労を抑えることでパフォーマンスを維持して
出来るだけ多くのタスクを捌き切るための工夫について記載しました。
ただ、この記事に記載した工夫が役立つかは現場によりますし、
場合によっては不興を買う可能性もございます。
タスクが溢れないようにするのは
最終的にはお客様や上司からの評価向上のためでもあるので、
目的を履き違えないように注意しつつ
あなたが評価されるためにご活用いただければ幸いです。
この記事が参加している募集
この記事が気に入ったらサポートをしてみませんか?