とあるコンサルタント上がりと仕事をするのにあたり、
非常に、細かく形式ばった分類をしないと仕事が前に進まない状態が起きました。
私としては、正直、全部クリアしてやらなきゃならなことなので
そんな分類しなくても仕事を前に進めたいんですけどね、、、
「それは課題なのかタスクなのか？」
と、コンサルタントが問いてくるわけです。
それが課題なのかタスクなのか、分類するとしたらどうしたら良いでしょうか？
正直、プロジェクトにおいて限られたリソースで課題もタスクも、どちらもクリアしていきたいモノなのでどっちでも良いのですが・・・
課題とタスクの違いは？
どうやら一般的に
- 課題は、一人では解決できない問題
- タスクは、一人でやるだけの作業
のようです。
問題＝ToBe（トゥービー）-AsIs（アズイズ）
問題（ToBe – AsIs）が、乗り越えるべき課題に変化し、
課題が、複数のタスクになるイメージが多いようです。
両方ともプロジェクトとしてはやらなきゃならない事柄には変わりないのですが、
タスクはやればやることが出来ますが、課題は解決できるとは限らない事象のようです。
でも、そう考えると請け負ったプロジェクトというのは、ほとんどは課題ではなくタスクの集まりのように思えますね。（だから請け負ったわけです。）
問題と課題の違いは？
問題の課題の違いについては、2パターンの解釈がります。
解釈パターン1（問題≒課題）
俺は、こちらの方が腑に落ちます。
問題というのはたくさん出てきますが、その問題の中で絶対立ち向かわなければならない問題の事を「課題」（＝課せられた問題）いうイメージです。
解釈パターン２（問題→課題）
インターネット上で、「問題と課題の違い」について調べると、いろんな事をそれっぽく語っている人がいます。「そんなことも知らないのか？」的に。
ただ、日本語的には明確な違いは無いので、結局その人の感性だと思いますが、
（ビジネスでは）課題は、問題に対して原因を分析し解決するためにやるアクション
という人がいます。
問題を、とある人の感性フィルターで分析した結果の文章ということですね。
わかり易い例えで話しますと、
- 問題：プロジェクトが遅延している
↓ - 課題：（「問題」に対して原因の所在を分析した結果）プロジェクト遅延の原因がリソース不足。
↓ - タスク：（「課題」に対して、解決策が導き出された後）解決策に対し具体的に誰がいつまでに何をやるのかを決めたもの。
俺はこちらは腑に落ちません。なぜならば、
- 分析が間違えていたら本当の問題を読み違えて伝えてしまう可能性がある
- 課題がアクションなら、もう課題では無くやるだけのタスクである
結局、この解釈だと課題とタスクの違いがあいまいになり、ただ課題のアクションが大きいか（複数のタスクで組み合わさって）・小さいか（一つのタスクか）だけの違いになってしまいます。
結論：課題とはまだ解決できていない一人で解決が難しい問題
と、と俺は理解しています。
問題の議題の上に、考えられる原因を並べていくのはアリです。一つの問題を分析した結果、複数の課題に分かれるということもあり得ると思いますので。
「問題 → 課題 → 最終的に複数のタスク」
と言え、タスク化されればそれは進捗管理対象でしかないブツになるというイメージですので、
管理対象は
- 問題≒課題（検討しなければならない事柄、時間がかかるもの）
- タスク（やればよいだけのもの）
か、で管理できれば理想です。
ただ、どっちもやらなきゃならない事柄なので「それは課題なのか？タスクなのか？」といった言葉は、厳密な定義はなく、正直どちらでも良いかなと思います。
ではヒアリング事項（選択肢）は課題なのか？
では、お客さんに聞きたい項目（＝ヒアリング事項）は課題なのでしょうか？
「ヒアリング」という意味も、
- 現状をただ聞きたい
- お客さんに決定してもらいたい
と二種類ありますね。ここで話しているのは後者です。
お客さんが決定してくれればよいだけの項目ですが、いわゆる選択肢だから聞いているんだと思います。
- 決めるだけと言われれば、やればよいだけの「タスク」とも言えますが
- 決めなきゃならないということは検討しなければならない
なので、課題ともタスクともどちらもとらえられそうです。
それを課題と感じるか、タスクと感じるかは受け取った側の感覚のように感じます。
例えば、「名前」を決めるだけのヒアリング項目は「課題」とは言いませんよね。
ただ、将来を決めるような分かれ道の選択肢は、「タスク」とは言い難い気がします。
まあ、このようにそれはタスクなのか課題なのかはグレーな個所がありますので、そんなに厳密に言葉の定義を考えれすみ分け、言葉にこだわる必要はないかと俺は思います。
そのタスクもしくは課題（呼び名はどちらでもよい）に対し、任せた人に時間がかかっている（＝何かネックがある）かどうなのかを見てあげれば良いかと思います。
要するに本質は、困っているタスクか困っていないタスクかは見極めたいってことだと思います。
ちなみに、backlogというプロジェクト管理製品では「問題」も「タスク」も「課題」です。
毎日の業務で発生するタスクや問題を課題で管理します。
Backlogでは、担当者を決めて処理すべき事柄、つまりタスクのことを「課題」と呼びます。課題には「件名」「詳細」「担当者」「開始日」「期限日」などの属性を設定できます。
課題と状態 – Backlog ヘルプセンター
課題とリスクの違いは？
では、課題とリスクの違いは何でしょうか？
- 課題は、今起きている問題であり、
- リスクは、将来起きるかもしれない問題
のようです。
つまり、リスクは心配性だけで終わってしまうかもしれません。
リスクって何でしょうかね？
見積もり時にはリスクはあるかもしれませんが、そのリスクを許容した見積もりで請け負った後は
リスクはいくら発生しようがこなすだけのような気がします。
いくら何でも、出来ないことを出来ると言って受注し請け負うのは詐欺ですからね。
そう考えると、リスクは受注前の状態であり
受注後は（解決が出来ないようなコストや技術的な）課題は普通はあまりないのが当然かと思います。もちろん、プロジェクトとしての人的課題は出たりもしますけど。
- 課題やリスクという言葉は、プロジェクト管理（ヒト・モノ・カネ・情報・時間）周りのみに使い、
- プロジェクトの中の技術的な話は、課題もタスクも同じようにとらえる
というのが、わかり易いのかもしれませんね。
以上、プロジェクトで細かい人は課題とリスクとタスクに分けたいという話でした。
コメント