PMをやっていると、こんな場面が必ずやってきます。
- 「あのタスク、どうなってる？」と確認すると、まだ着手していなかった
- 完成したものを受け取ると、思っていたものと全然違う
- 「こうやってください」と説明しているのに、質問が止まらない
タスクは振った。なのに、なぜか進まない。なぜか質が低い。なぜか質問が多い。
こんなとき、「メンバーのスキルが足りない」「理解力が低い」と思うこともぶっちゃけあるのではないでしょうか？でも、多くの場合、原因は依頼する側のタスク設計にあります。
この記事では、タスクが思うように進まない根本的な理由と、それを解消するための「タスクの構造」と「タスク設計」の方法論を解説します。
この記事でわかること
- タスクが進まない本当の理由
- タスクを構成する4つの要素
- 抜け漏れなく依頼できるタスク設計の手順
なぜタスクは進まないのか？
タスクを振っても進まない。その原因を、依頼される側の立場に立って考えてみましょう。
もしかしたら、タスクを受け取ったとき、依頼された側の頭には、実は3つの「？」が浮かんでいるかもしれません。
❓ なぜ、このタスクをやるのか？
タスクをやる意義や必要性が、わからない状態です。
この状態では、「言われたことはやる」けれど、それ以上のことはできません。一方、目的がわかれば、自分で考えて動けるようになります。逆に、目的がわからなければ、指示の範囲でしか動けません。
心理的にも「なぜこれをやるのか？」という意義や目的、やる理由が腹落ち(納得)できている方が、やる気がでるものです。例えば、会議の議事録をまとめておいて！とただ言われるのと、上に対する報告資料に使いたいから議事録をまとめておいて！と言われるのでは、作業のやりやすさは全く違うと思います。
目的がはっきりするだけで、作成される成果物も変わってきます。上への報告のためならば、丁寧にわかりやすく作ろうと思います。一方で、目的がわからなければただ情報をまとめただけの資料ができあがるはめになります。
その結果、タスクを依頼した側からすると、期待外れの議事録が出てきたな・・・となってしまうわけです。
❓ 何をすれば、完了なのか？
成果物として何を作ればいいのか。最終的にどんな状態になっていればいいのか。それがわからない状態です。
ゴール地点が見えないと、「終わった」という判断ができません。だから、タスクが完了しないまま時間だけが過ぎていきます。
さらに、作るものが具体的にわからないと、いつまでも試行錯誤することになります。例えば、テスト方針をつくって！と依頼されても、具体的にどのような資料を作ればいいかはわかりません。具体的に、こういう構成で、こういう内容のことをまとめたテスト方針書というドキュメントを作ってほしいと伝えなければいけません。
それをしないと、ちょっと思ってたのと違うな・・・という成果物しか上がってきません。
❓ どうやって、進めればいいのか？
目的も成果物もわかった。でも、どんな手順で進めればいいかわからない状態です。
着手してから「さあ、どこから始めよう？」と考え始めることになります。その分、タスクの前進が遅れます。
タスクを実行する人がベテランであれば問題ないかもしれません。でも、成果物をつくるまでの手順を示して挙げないと、たくさんの寄り道(=無駄な作業)を行い、工数を食いつぶす可能性もあります。
なので、最短でタスクをすすめてもらうためにも、おおまかでも手順を提示することで効率よく進めることができます。
このように、3つの「？」が浮かんでいると、タスクは順調には進みません。結果として、遅延したり、期待外れの成果物が上がってきたりします。
- なぜやるのかわからないから、最低限しかやらない
- 何を作ればいいかわからないから、タスクが終わらない
- どうやればいいかわからないから、着手後に迷う
これはメンバーの問題ではありません。タスクの設計が不完全なことが原因です。
タスクの構造：4つの要素
では、3つの「？」を解消するには何が必要なのでしょうか。
タスクは、大きく 4つの要素 で構成されています。
- 目的：なぜこのタスクをやるのか
- INPUT：タスクを始めるのに必要な情報・材料
- OUTPUT：タスクが完了したときにできあがるもの
- プロセス：INPUTからOUTPUT作る作業手順
先ほどの「3つの？」と、この4要素は対応しています。
| 依頼される側の疑問 | タスク設計の要素 |
|---|---|
| なぜやるのか？ | 目的 |
| 何をすればいいのか？ | OUTPUT（＋INPUT） |
| どうやればいいのか？ | プロセス |
つまり、この4要素をすべて定義することが、タスク設計の本質です。
どれか1つでも欠けると、依頼された側はどこかで詰まります。4つがそろって、はじめてタスクをスムーズにこなすことができます。
タスクの設計手順
では、実際にどうやってタスクを設計するか。4つのステップで説明します。
ここでは「要件定義書の作成」というタスクを例に取りながら解説していきます。
STEP①：目的を言語化する
最初に、「なぜこのタスクをやるのか」を言葉にします。
目的を定義するときの問い
- このタスクをやることで、何が解決されるか？
- このタスクをやらないと、何が困るか？
- このタスクは、次のどんな作業に繋がっているか？
目的は、タスクの方向性を決める羅針盤です。目的が明確であれば、メンバーは自分で判断しながら動けるようになります。ここが曖昧だと、依頼された側は「言われた通り」にしか動けません。(指示待ち状態のできあがり)
例：要件定義書の作成
目的：開発ベンダーに見積を取るため、および設計のINPUT情報を可視化するため
「資料を作ること」が目的ではなく、「見積を取ること・設計のINPUTを作ること」が目的です。この一言があるかないかで、メンバーが作る成果物の質はまったく変わります。
STEP②：INPUTを定義する
タスクを始めるために必要な情報・材料を整理します。
INPUTとして定義すべきもの
- タスクに必要なデータや資料
- 前提として完了していなければならない別のタスク
- 判断に必要な条件や制約
ほとんどのタスクはまっさらな状態(なにもINPUTがない状態)でスタートすることはほとんどありません。なので、INPUTが揃っていないと、着手後に「あの情報ってどこにありますか？」という質問が飛んできます。INPUTを事前に定義・提供することで、そのロスをなくせます。
例：要件定義書の作成
INPUT：
- 課題・対応方針一覧（完成済みであること）
- As-Is業務フロー（完成済みであること）
この2つが揃っていない状態で要件定義書の作成を依頼しても、作業は止まります。前提タスクを明示しておくことが大切です。
STEP③：OUTPUTを定義する
タスクが完了したときに「できあがっているべきもの」を定義します。
OUTPUTを定義するときのポイント
- 成果物の形式（資料・一覧・報告など）を具体的に指定する
- 可能であれば、OUTPUTのフォーマットや枠組みを渡す
OUTPUTが曖昧だと、ゴールが見えないままタスクが進みます。結果、完成したものを受け取ってから「これじゃない」が起きます。フォーマットを事前に渡せると、OUTPUTのズレが大幅に減ります。
例：要件定義書の作成
OUTPUT：
- 要求一覧
- 業務要件一覧
- 機能要件一覧
「要件定義書を作って」と一言で依頼するのと、上記のようにOUTPUTを具体化して渡すのとでは、成果物の質がまるで違います。「このフォーマットのここを埋めてください」まで指定できれば、メンバーは迷わず動けます。
OUTPUTの枠組みを考えることは、ジュニアのメンバーだととても難しいものです。なので、フォーマットや枠組みをあらかじめ渡すことでスムーズにタスクを進められます。
STEP④：プロセスを定義する
INPUTを使って、OUTPUTを作るためのプロセスを整理します。
プロセス定義のポイント
- 大きなタスクは、小さなサブタスクに分解する
- 各サブタスクに「何を使って・何を作るか」を明示する
プロセスが定義されていれば、メンバーは着手後に迷いません。プロセスがなければ、着手してから「さあ、どこから始めよう」と考え始めます。その時間がそのままタスクの遅れになります。
例：要件定義書の作成
プロセス：
- 課題・対応方針一覧をもとに、要求一覧を作成する
- 要求一覧とAs-Is業務フローをもとに、To-Be業務フロー・業務要件一覧を作成する
- 業務要件一覧をもとに、機能要件一覧を作成する
3段階で段階的に具体化していく。このプロセスがあれば、メンバーは「まずSTEP1から始めよう」と迷わず動き出せます。
タスク設計の「総仕上げ」：可視化する
4つの要素が定義できたら、最後にそれを可視化します。
頭の中で設計できていても、見えない状態では他者に依頼できません。可視化することで、依頼する側と受ける側の認識を合わせることができます。
可視化のポイント
- 目的・INPUT・OUTPUT・プロセスを依頼チケットにまとめる
- 依頼された側がすぐに動ける状態まで具体化する
「口頭で説明したからOK」と思っていても、受け取った側の理解は人それぞれです。可視化して渡すことで、認識のズレをなくし、余計な確認コストをゼロにできます。
例えば、こんな感じで可視化します。
タスクはつながっている
プロジェクトでは、多くのタスクが同時進行します。しかし、それらは決して独立したものではありません。タスクはすべて、つながり合っています。
あるタスクのOUTPUTは、別のタスクのINPUTになります。要件定義書の例で言えば：
- 課題・対応方針一覧（前タスクのOUTPUT）→ 要求一覧作成のINPUTに
- 要求一覧（STEP①のOUTPUT）→ 業務要件一覧作成のINPUTに
- 業務要件一覧（STEP②のOUTPUT）→ 機能要件一覧作成のINPUTに
このように、タスクは連鎖しています。
タスクを設計するときの問い：「このタスクのOUTPUTは、次のどのタスクのINPUTになるか？」
この問いに答えられれば、目的は自動的に言語化できます。
タスクを「独立した作業」として捉えると、「言われたことをやった」で終わりになります。でも、「つながりの一部」として捉えると、「このタスクが次のどの作業を支えるか」が見えてきます。
これは、PMだけでなく、作業者にとっても大切な視点です。自分のOUTPUTが誰かのINPUTになると知っていれば、成果物の品質への意識がまったく変わります。
まとめ
タスクが進まない原因は、多くの場合、タスク設計の不備にあります。
依頼される側の頭には、常に3つの「？」があります。「なぜ・何を・どうやって」。この3つが解消されていないと、タスクはどこかで詰まります。それを解消するのが、タスクの4要素です。
タスク設計の4要素
- 目的：なぜやるのか
- INPUT：何を使うのか
- OUTPUT：何を作るのか
- プロセス：どうやるのか
この4つを定義し、可視化して渡す。それだけで、依頼の質は大きく変わります。
そして、忘れてはいけないもう一つの視点があります。タスクは孤立した作業ではなく、プロジェクト全体の「つながり」の一部だということです。あるタスクのOUTPUTは、必ず次のタスクのINPUTになります。
このつながりを意識するだけで、「なぜこのタスクをやるのか」という目的が自然に言語化できます。そして、それをメンバーに伝えることで、依頼された側は「自分の仕事がどこにつながっているか」を理解して動けるようになります。
タスクを振ることがPMの仕事ではなく、タスクを設計し、つながりの中で自走させることがPMの仕事です。依頼する側も受ける側も、タスクのつながりを意識したとき、プロジェクトは格段にスムーズに動き出します。
おまけ：NGパターン
タスク設計でよくある失敗を3つ紹介します。「見たことある」と思ったら、早めに見直すサインです。
NG① 目的が曖昧なまま依頼する
「とりあえずこれをやっておいて」「調査しておいて」などと雑にタスクを振ってしまう。目的が曖昧なタスクの典型です。
- 何のためにやるのかわからない
- だから、最低限のことしかやらない
- もしくは、的外れな方向に進む
依頼された側は「言われたからやった」以上のことはできません。目的が共有されていれば、メンバーは自ら考えて動けます。逆に目的がなければ、指示の範囲を超えることができません。
対策： 依頼するときに「このタスクをやる理由」を1文で添える
NG② OUTPUTが未定義のまま依頼する
「資料を作って」「まとめておいて」——何ができあがればいいのかが、ふわっとしたまま依頼するケースです。
- ゴールが見えないので、どこで終われるかわからない
- 完成物を受け取ってから「これじゃない」が起きる
- 手戻りが発生し、双方の時間が消える
成果物の形式・項目・フォーマットをできる限り具体的に定義しましょう。フォーマットを事前に渡せると、さらに効果的です。
対策： 「このフォーマットのここを埋めてください」まで具体化する
NG③ プロセスが未定義のまま依頼する
「やり方は任せます」——裁量を渡したつもりが、実は迷子にさせているパターンです。
- 着手してから手順を考えるので、スタートが遅い
- どこから始めればいいかわからず、質問が飛んでくる
- タスクの完了に余計な時間がかかる
特に経験が浅いメンバーに渡すときは、最初の手順だけでも定義してあげると効果的です。全部定義する必要はありません。「まずここから始めてください」という起点を渡すだけでも、動き出しがまったく変わります。
対策： 最初のサブタスクと、そこで使うINPUTをセットで渡す
関連記事