タスク管理とか予定の立て方って、表面的なノウハウはそこら中にあるけど、現場で本当に使える方法って意外と少ない。今回のnoteは、僕がずっと業務や創作で試行錯誤してきた結果、「結局こうすればロスが減って余裕が戻る」というところまで整理した内容をまとめたものだ。
スケジューリングは“ただ予定を置く作業”じゃない
辞書にあるような軽い言葉じゃまったく足りない。実際の現場では順番のズレひとつで全体が止まることもあるし、計画を組み直す羽目になることもある。僕もゲーム制作で「前工程終わってないのに後工程だけ先に突っ込まれて、全員が手待ちになる」という状況を体験した。
こういうロスは、誰かが悪いんじゃなくて“仕組みのミス”なんだよね。誰が・いつ・何をやるのかが曖昧だと、それだけで現場は壊れる。だからスケジューリングは、予定を決めるというより「無駄な時間を減らす仕組みづくり」なんだと強く感じている。
僕が予定を立てる目的は“余裕をつくるため”
このnoteでは、とくに「目的は期限を守ることじゃない」という話をしている。僕自身、長いこと“ちゃんと終わらせるための計画”を立てていたけど、最終的に大事なのは別だと分かった。
心に余裕がないと、計画はすぐ破綻する。仕事も創作も、焦ってると全部雑になる。予定を立てるのは、未来の自分を楽にするため。その前提を持たないと、タスク管理はどれだけ工夫しても継続しない。
有名な優先度マトリクスが途中から使えなくなった理由
僕も最初は「緊急度×重要度マトリクス」をかなり信頼していた。7つの習慣で知ってから、しばらくはこれに頼っていた。
でも複数プロジェクトが動くようになると、突然噛み合わなくなっていった。動画制作、ブログ、開発、グッズ制作……それぞれ工程もスピードもリスクも違う。それなのに同じ軸で優先順位をつけようとしても、うまく回らない。
理論は間違ってない。でも、僕の働き方と合わなくなった。そこで手法ごと組み替えていった。noteでは、その“破綻した瞬間”と、そこからどう改良したかも率直に書いている。
PMとしての視点が、このnoteの土台
本業でPMをやっているから、どうしても現場寄りの思考になる。PMって、みんなが動けるように道を整える人なんだけど、どれだけ準備しても想定外は必ず起きる。
「仕様的に無理です」「デザインが詰まりました」
こういうのは避けられない。だからこそ、自分のスケジュールに余白を作っておかないと対処ができない。余裕ゼロで詰めると、PM本人が倒れる。実際、僕も何度かギリギリのところまでいった。
この経験から、「スケジュールに余白を入れるのは怠慢じゃなくて戦略」という考えに行きついた。このnoteは、その思想がかなり強めに反映されている。
INTJ気質と不安性ゆえに、理論を何度も更新し続けた
僕はINTJ気質で、不安性もあって、自分で作った理論すらそのまま信用できないタイプ。「これ本当に正しい？」「別の状況でも使える？」と何度も検証したくなる。
その結果、スケジューリングの方法が常にアップデートされるようになった。今回のnoteは、その中でも“今の自分の生活と仕事に一番フィットしている形”をまとめたものだ。
昔の理論も全部土台として残っているし、これからまた変わるかもしれない。ただ、現時点で「これなら再現性がある」と胸を張れる内容になっている。
▼ここから先は有料版（第4章〜）
以下は第4章の一部抜粋です（原文そのまま）。
―――抜粋ここから―――
4.優先度のつけ方・重み付け
プロジェクト単位・タスク単位で期限を設定します。
まず概念の整理から。
タスクは「やること・やるべきこと」。
プロジェクトは「ある目的を達成するための計画」。
つまり、目的達成のために計画を立て、その計画を実現するための“やるべきこと”を順にこなしていく、という構造。緊急度×重要度マトリクス的に言えば、タスクは緊急度、プロジェクトは重要度の領域に関わってきます。
優先順位は、まず「期限ありき」です。
タスクには必ず期限を設けてください。何がなんでも、です。
「いつでもいい」が最も危険で、これを許すと際限なく後ろに流れます。未来の自分がなんとかしてくれると人は思い込みますが、未来の自分はだいたい現状の自分より疲れてます。
コラム：タスクとToDoの違い
タスクは「やるべきこと」。
ToDoは「やった方がいいこと」。
ニュアンスは近いようで、優先度ではまったく別物です。
ToDoに期限は不要。「やらなくてもいい」からです。ただし境界線は人によって違うため難しい部分もある。わかります、めっちゃわかります。
プロジェクトにも同様に期限が必要です。
期限がないプロジェクトは、もはや“願望”に近い。達成義務も計画性もない。そんな案件は時間の浪費になりがちで、もっと重要なプロジェクトを押しつぶします。
進めたいなら目的の再定義や具体化が必要。
昔、SNS運用チームで「フォロワー1万人」という目標がありましたが、期限だけが後ろ倒しになる状態でした。当初半年→いつの間にか1年。管理者は「まあ目標だし、達成できなくてもいいよ」。いやいや…。そのプロジェクト、達成する理由が誰にも共有されていない。
さらに、マイルストーンは希望的観測の羅列。
参考にしていた別チームアカウントはジャンルもゲーム性も違う。ガーデニングの手法をファッションに持ち込むようなもので、そりゃ噛み合わない。
目的と目標をしっかり定義しないと、永遠に終わらないプロジェクトだけ増えます。
コストだけ失ってモチベも死にます。
では本題。
「同じ優先度（期限）になったらどうすればいい？」という問題。
私は優先度に“偏差値”のような概念を入れていて、重み付けで順位を自動的に計算します。
期限系の計算はこう（例）：
タスクの期限までの日数 x 2
プロジェクトの期限までの日数 x 4
基準値50に足していくイメージです。
プロジェクトはタスクより重みが大きい理由は簡単で、タスクを達成してもプロジェクトが終わらないなら意味がないからです。
期限の計算式は
50 + 2×タスクの残日数 + 4×プロジェクトの残日数
それでも同点なら、上から順に処理。
もしくは、次に説明する「作業量」と「依存関係」を加味します。
緊急度は作業量×依存関係で判断します。
タスクには依存関係があり、Aを終えないとBに着手できないものがあります。
データベース作業の例でいえば「レコード作成」→「パラメータ設定」の順番が必ず必要になるようなもの。
さらに、経験があるタスクなら大体の作業時間も見えています。
例えば僕の場合、ナレーションテキスト作成は50分、構成は40分など。
時間が大きいものから片付けないと、1日が破綻するので、私は作業時間が大きいものを優先しています。ただし「今日は気分乗らない」ときは逆に小さいものからやるなど、ここは自分に合わせて調整します。
緊急度の計算は少し複雑です。
依存関係＝3×依存元の完了割合 + 3/(依存深度+1)
作業時間＝1.5×推定作業分数
最終的な優先順位スコアは
50 + 4×プロジェクト期限日数 + 3×依存完了割合 + 3/(依存深度+1) + 2×タスク期限日数 + 1.5×作業時間
係数はチームや性格に合わせて調整することを推奨します。
―――抜粋ここまで―――
さらに詳しい実践テクニックや僕の経験談はnoteでまとめています。
興味がある人はぜひチェックしてみてください
[note記事はこちら]https://note.com/alt_stella/n/n3ca88efaf509
コメント