タスクの優先順位付け

能力が上がれば、同じ時間でも大きい成果を出せる

そもそも優先順位にもいくつかの軸がある

優先順位自体の構造化をしていけたらいい

目線

顧客にとっての

頻度、代替、

自社にとっての

売り上げにつながるか

開発者にとっての

将来的に開発が辛くならないか

容易さ、時間、難度、頻度

重要度ってなんやねんという気はする

MVP

バグや、理想的な挙動じゃなかったとしても、回避策があるならまだましのこともある

特にユーザが少ない時、to Bとか

この動作を行うと落ちるがリロードすれば直る、とか

全然良くないんだけど、相対的に最優先にはならないかも知れない

高そうなやつのヒント

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

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

経営に直接関係する

代替手段がない

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

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

直観で決めない

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

データがある

論理的に判定できる

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

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

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

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

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

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

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

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

数が多すぎる

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

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

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

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

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

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

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

ミニマリスト的志向

いかに捨てられるか

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

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

時間で区切る

機能で区切る

洗い出し、という字面から感じられる感覚が、実は微妙なのかも知れない

を収集しておきたい

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

これを完了しないと他のタスクを進められない