タスクの優先順位付け

高そうなやつのヒント

他のタスクを遂行するために必要

多くのタスクに依存されている

経営に直接関係する

代替手段がない

困っているユーザの数が多い

データを見て判断する必要がある

直観で決めない

本当の要件を見極めて、そこから順に見ていく?

ボトルネックを突き止める

とにかくいくつか発案してみる？

嫡出する前に個々の問題について考えてみる

課題の要点とその解決策を複数発案するとか

小さい課題は小さく改善し、大きい課題は大きく改善するとか？

優先順位を付けるのはなぜ難しいのか？

比較するものの抽象度が混在している

会社やプロジェクトにおけるタスク等を比較するわけだが、

その際に、比較するものの抽象度が揃っていないと比較のしようがない(?)

抽象的な要件と、具体的な施策や機能を、同列で比較すべきではないだろう

抽象度を揃えたとて、価値判断が難しい

こちらの方が、こういう理由で優先順位が高い、という説明をしたい

課題の対処を考えた時、その課題の影響の派生はありがち

説明するための材料の有無

データがある

論理的に判定できる

自分がペルソナであり直感で判断できる(?)

これらも単純に比較可能でないことが多い

型が異なれば、常に何らかの基準で大小を判定できるものではない

ある人がタスクに追われている

その人のタスクの中から時間がかかっているものを仕組み化する、他の人に任せる

その人の時間が空いたら、その人に他のタスクを任せるわけだが、そのタスクとはなに？

作業を効率化するのは良いが、効率化した先にやりたいことは何だっけ？

実は今ある作業を効率化するよりも、その先のタスクを先にやったほうが良かったりはしない？

数が多すぎる

いくつかのグループがある

例えば、経営目線まで行くと範囲が広くなりすぎる

開発、営業、人事、受注生産など全てのタスクが入ってくる

優先順位の低いものを後回しにすれば良い、というわけでもない

優先度の高いタスクと関連性が高いのであれば一緒に解決したほうが効率が良い

また、抽象の発見のヒントに繋がるので、より良い

こういう、タスクの関連付けに関してはCosenseが強い

ミニマリスト的志向

いかに捨てられるか

プログラムにおける抽象(インターフェース)の設計の難しさにも似てる

小さな口で大きな効能を生み出す

時間で区切る

機能で区切る