【初心者向け】タスク設計のやり方・基本的な考え方

こんにちは！

今回は「タスク設計」についてご紹介します。

どんな仕事であろうと役に立つスキルだと思うので、是非参考にしていただければと思います！

では、早速行きましょう！

タスク設計とは

タスク設計とは、簡単にいうと、「ToDoの洗い出し＆スケジュール表の作成」のことです。

公務員だろうと民間企業だろうと作成することが多いと思いますし、なんなら仕事に限らず、

• 大規模な飲み会をやるとき
• 一定の人数で旅行に行くとき

に作成されたりします。

タスク設計がある程度できるようになって思うことは、「タスク設計は、知識だけあってもできるようにならない」ということです。

自分の手で何度かタスク設計して、それに沿って仕事をこなし、

と、何度か失敗しないと身につかないスキルだとは思います。

とはいえ、大事な考え方は実戦の中で見えてきたので、そのご紹介をできればと思っています。

では、作り方のコツをご紹介していきます！

タスク設計のコツ

「タスク設計 ＝ ToDoの洗い出し＆スケジュール表の作成」なので、

• ToDoの洗い出し
• スケジュール表の作成

に分けてコツをご紹介します。

ToDoの洗い出し

社会人になったばかりでタスク設計の考え方がよくわからなかった私は、

と色々な書籍を漁っていました。

しかし、WBS/ガントチャートの「スケジュール作成」の部分ばかりが詳細に説明されていることが多いです。

そして、「ToDoの洗い出し」の部分は、

と、さらっとした記述ばかりで、

と途方にくれた記憶があります。

そんな私が、実戦の中で失敗しながら身につけたToDoの洗い出しのコツは、

1. 最終的な状態・流れを描き、そこから逆算する
2. 大きなToDoをまず洗い出し、それを分解する
3. タスクの先後関係をしっかり整理する
4. アナロジーを使う
5. 関係者に確認してもらう

の5点です。

それぞれ見ていきましょう。

最終的な状態・流れを描き、そこから逆算する

「ToDoの洗い出し」で一番重要なコツは、「最終的な状態・流れを描き、そこから逆算する」です。

最終的な状態・流れをどれだけしっかり考えられるかによって、タスク設計の成否が決まります。

例えば、「100人くらい参加する大きな飲み会」をする場合は、

と考え、

• ホテルなどの会場で受付をし、
• 立食形式で開催され、
• 途中で余興の出し物があり、
• 最後は偉い人から挨拶してもらって終わる

という大まかな状態・流れをイメージします。

そして、

という感じで、最終的な状態・流れを起点にして、そこからToDoを洗い出していくことになります。

「最終形から逆算する」は、どんなタスク設計でも使える考え方なので、ぜひ参考にしていただければ。

大きなToDoをまず洗い出し、それを分解する

ToDoを洗い出すときは、いきなり細かい作業レベルのものを洗い出してはいけません。

「広告を打つ」、「安定した調達を確保する」といった抽象的で大きなものをまず洗い出し、

と確認してから、それらの抽象的で大きなToDoを、詳細な作業レベルに分解していきましょう。

例えば前述の「100人くらい参加する大きな飲み会」の企画の際も、

と考えた上で、

と詳細に分解していきます。

いきなり詳細な作業に分解してしまうと、分量が多すぎて抜け漏れのチェックが難しくなります。

また、詳細な作業だけ記載されていると、最終形との結びつきが想像しづらく、

という話にもなりかねません。

なので、必ず抽象的で大きなToDoを挟んでから、詳細なToDoの検討に入りましょう。

タスクの先後関係をしっかり整理する

洗い出したToDoごとに、

というToDo間の先後関係を整理しましょう。

大きなToDoを詳細なToDoに分解するときに、併せて先後関係も検討したら良いと思います。

例えば、

そして、

そして、

といった感じで、「このToDoをやるためには、何が完了していなければいけないか」を考えていきます。

そして、この先後関係を使って、後ほどスケジュール表を作成することになります。

アナロジーを使う

「ToDoの洗い出し」では、他の事例が参考になります。

過去に全く同じ内容のタスク設計をしているときは当然参考になりますが、全く同じでなくても、共通点があるときは役に立ちます。

これらの類似事例を用いることで、ToDoに抜け漏れがないかチェックすることができるようになります。

例えば、「100人くらい参加する大きな飲み会」の場合、

• 大人数を一箇所に集めたイベント
• 偉い人に参加してもらったイベント

の経験があれば、その時にやったToDoは大抵は流用可能です。

具体的には、

• 友人の結婚式における二次会
• サークルの先輩の送別会
• 大学での論文の発表会

などの時のToDoを覚えていたら、そのまま活用できるでしょう。

といった感じで、抜け漏れが確認できます。

関係者に確認してもらう

自分一人での「ToDoの洗い出し」が終わったら、様々な部署の関係者と打合せの時間をとって、足りないタスクがないか確認してもらいましょう。

意外と、

というものがあるものです。

私の公務員時代の経験だと、法令改正に向けたToDoリストを秘書課（＝人事課）に一応確認してもらったところ、

と言われ、驚いたことがあります。

というのも、今回の法令改正の内容は、組合とかには全く関係のないものだったからです。

なので、秘書課に、

と聞いたところ、

と言われ、「なるほど。そういうものか」と思ったことがあります。

スケジュール表の作成

ToDoが洗い出すことができたら、次はそれをスケジュールに落とし込みます。

スケジュール表作成でのコツは、

• バッファを含めながら工数見積もりをする
• マイルストーンと対比させながらスケジュールを決める
• （こちらも）関係者に確認してもらう

の3つです。

なお、ここで注意ですが、そもそもスケジュールを立てる目的は、「効率的かつ実現可能なプロジェクトの進め方を検討し、より良いアウトプットを生み出すため」です。

つまり、スケジュール表は、より良いプロジェクトの進め方を検討するためのツールでしかないのです。

「スケジュールを守るために、アウトプットの質を毀損する」というのは本末転倒すぎます。

スケジュールを組んだ結果、

となった場合は、

• 進め方を工夫し、必要工数を減らすか
  （「M＆Aで会社ごと買ってしまう」など）
• 最終形のクオリティ目標を（問題ない範囲で）引き下げて、必要工数を減らすか
• 作業人員を増員したり、高度なツールを導入して、タスクを消費するペースを上げるか
• 他に良い進め方の選択肢がない場合は、〆切を後ろ倒すか

のいずれかを選択し、スケジュール表を柔軟に修正する必要があります。

にも関わらず、

と、「スケジュール厳守」を求める “旧日本軍” みたいな人が一定数います。

無理のあるスケジュールを組み、その非現実的な〆切を守るために、新サービスの質が落ちたり、本来実装しておくべき機能が落ちてしまったりするのは、正直、本末転倒です。

低クオリティのサービスを体験して離脱していったユーザーは帰ってきません。

皆さんが上司の立場になったら、こんなことはしないようにあらかじめ気をつけましょう。

では、話を戻し、スケジュール表作成のコツをそれぞれ見ていきましょう。

バッファを含めながら工数見積もりをする

スケジュールに落とし込むためには、各ToDoごとに、どれだけの工数が必要なのかを見積もる必要があります。

その際は、必要工数ギリギリで見積もらず、必ずバッファも含めた見積もりにするようにしましょう。

現実的なことを言うと、どれだけ緻密なスケジュールを作っても、絶対何かしらトラブルが起きてスケジュールは崩れます。

例えば、

• 担当者が体調を崩して休んでしまう
• 台風で交通機関が停止してしまう
• 配送トラブルで機材が時間どおりに届かない
• 世界的に新型の感染病が蔓延してパンデミック状態になる

などなどの可能性が考えられます。

大事なのは、「スケジュールは必ず崩れる」ということを盛り込んだスケジュールを作成することです。

バッファを組み込んでさえいたら、そこを削って巻き返すことができます。

マイルストーンと対比させながらスケジュールを決める

各ToDoの必要工数が決まったら、ToDoの先後関係を踏まえながらスケジュールに落とし込んでいきます。

その際は、

• 中間発表会が10月にある
• 経営の役員会が4月にある

といった大きなマイルストーンがあるはずなので、そこを起点にしてスケジュールを組んでいきます。

そして、一旦スケジュールを組んだら問題ないか確認し、必要なら、

• 各ToDoの工数の再見積もり
• 先後関係の再整理

などをやってブラッシュアップしていきましょう。

トライ＆エラーが重要です。

（こちらも）関係者に確認してもらう

こちらも、様々な部署の関係者と打合せの時間をとって、問題なさそうか確認してもらいましょう。

関係者にスケジュールを確認してもらったら、調整が絶対発生するので、この工程を嫌がる人が一定数います。

面倒に感じる気持ちはわかりますが、はじめのスケジュール作成段階で苦労しておかないと、プロジェクトの後半に、

と炎上してもっと苦労します。

プロジェクト初期の炎上であればいくらでも修正が効きますし、なんなら早めに炎上したことでグッと成功確率が上がります。

一方、プロジェクト最後の炎上は、そのまま失敗に直結します。

気をつけましょう。

おわりに

いかがでしたでしょうか？

お仕事の参考になれば幸いです！