2026-06-06

タスク選びについて

自分はどうやってるときがうまくいってそうかとか、そういう観察のメモです。いやあ、もっとうまくやれるのかもしれんけど。とりあえずめっちゃ間違ってはいない。そう信じている。

0. タスクはたくさんある、でもどれをやろう？

プロダクトバックログの上の方には、とても価値が高いタスクが積まれている……はずだ。理想的にはこのリストの一番上から取っていけば、プロダクトはどんどんよくなっていく……はずだ。

だけど、いつも理想通りのプロダクトバックログの順位が保持されているとは限らない。時間とともに変化するのは当たり前だ。実際の開発現場では、価値あるタスクが上から取られていった結果、ちょっと微妙なタスクが上位にきていることもざらである。

バックログの品質は、チームとして向き合うべき問題だ。もっとリファインメントに時間を取ろう。PdMに相談しよう。これは至極まっとうで、正攻法な、全体最適のやり方だ。

ただ、今ここで書こうとしているのは、もうちょっと個人最適寄りの話だ。バックログの話はチーム全体で大事だねーと責務を共有するとして、一方で個人としてどういうタスクを選ぶか。ただ単に上から取っていくのか、あるいはもうちょっと効率を考えるのか。

あくまでICとして、という話になる気がしつつ。いい感じにパフォーマンスを出したいとなると、結局こういう感じになるかなあ。というのを考えてみた。

1. 得意な分野のタスクを選びたい

当たり前の話だけど、もし自分がほかのメンバーと比べて上手に出来ると思っている領域があるなら、そのような領域のタスクを取るとよいはずだ。

例えばあなたがフロントエンドエンジニアで、使いやすいUIの構築に強みがあるなら、UI改善のタスクを取っていけばよい。

逆に、そんなあなたが、あまり得意ではないバックエンドのタスクを取ってしまうと、遅いし疲れるし、基本的にいいことがあまりない。

もちろん、その分野の知見を深めたかったり、あるいは他の得意そうなメンバーが明らかに手一杯で、なおかつ今すぐやる価値があるチケットだったりしたら、取っていったってかまわない。でも、自分がそのチケットを選ぶ理由は、周りが不安に思わないように説明した方がいいかもしれない。

AIの登場で、苦手分野でもどんどん触れる時代になってきてはいる。しかし、なんとなくやれてしまうからこそ、苦手を得意にするのも大変になってきている。そういう意味でも、自分の軸足を大事にするのは個人的に推奨したい。そのほうが疲れないし、疲れないでいることは大事だ。

2. ちょろいのにめっちゃ効果があるタスクを選びたい

タスクを達成したときの「うれしさ」（インパクト）を指標化することは本当に難しい。だからこそ、バックログリファインメントみたいな儀式がある。本来的には、POやPdMに一つ一つ確認すべきであり、タスクに取りかかる時点では事前に確認された状態であるべきだ。

それでも、エンジニアとして鋭い嗅覚を発揮することで、「こんなにおいしいタスクがあっていいのかよ」みたいなものが見つかることがある。たとえば、一行修正するだけでユーザーがぐっと快適になるとか。ちょっとしたCI定義ファイルを書くだけで、開発者全員が安全にコードを書けるようになるとか。

もちろん、そういうコスパのいいタスクは、常に転がっているわけではない。それに、こういう感じのタスクを10個やっても、（コスパがよいという表現とは厳密には相反してしまうのかもしれないが、）ヘビーでコアなタスクを1個やるほうがインパクトが大きいこともある。まあ、そのヘビーでコアなタスクの方が、本当の意味でコスパがよかっただけなのかもしれないけど。むずかしい。

とにかく、「安くてうまい」みたいなタスクはたまに転がっている。そして、それをデリバーするだけですごく感謝されたりする。うれしいからやる気が出てくる。そういう好循環を生むために、見つけたら普段の仕事にちょっとプラスするといいかもしれない。

3. ずっしりしたコアタスクを選びたい

これこそ本当の意味でバックログの問題という感じはする。プロダクトの成長目標と結びつくタスクは、バックログの一番上にあるべきだ。でも、何度も言うように時々刻々と移り変わる小さなタスクの群れがあって、それを本当に価値ある状態にメンテナンスできているチームが世の中にどれだけあるだろうか。いや、あるなら素晴らしいし、目指すべきだ。それはそれで。でもこれは個人最適な動き方の議論だからちょっとその話は今は置いておこう。

このプロダクトが解決しようとしている課題はなんだろう？　成長目標として、つぎにこれが出来ると本当にうれしい、というタスクはなんだろう？　こういう視点をもってタスクを選ぶのが本当に大事だ。……それができれば苦労しない？　それは本当にそう！　それができていれば、その人はそのままPdMになっていいレベルかも。

でもやっぱり、プロダクトとして本当にコアな部分と、そうではない部分が確実にある。コアのタスクを倒すぞと言う意識でいても、周辺領域のタスクもどうせ倒すことになるから、この辺の判断軸を持っておくこと自体は大事そう。

で、こういうタスクをやるときは分割を自分なりに行えるかがすごく大事なんですけど、その話はまた別途。まあ現代ではAIに「分割して」って言えば分割してくれそうだけど。

注意点として、やり始める前に覚悟は完了しておきたい。これは、やりきる覚悟と、やりきれそうにないときに手放す覚悟の両方だ。ここの自信が持てないタスクは、他の誰かを頼ったほうがいい兆候かもしれない。

ex. タスクを取り過ぎない・手放す

これはタスクの選び方というか、そもそもタスクを取りすぎるなという話。

人によるんだろうけど、マルチタスクって基本的には効率が悪い。AIに後ろで走らせておけば良いという話もあるんだけど、人間の確認作業がボトルネックになる。

AIの成果物を確認する余裕がそもそもなかったり、ハンドリングできないレベルに作業が肥大化していたり、マルチタスクになっていたりするときは、タスクを手放そう。なんかやりかけでも、バックログに戻してよい。たぶん。

やりかけのタスクをぐずぐずと腐らせているより、知見をためた上で再走するほうが、速いかもしれない。AIのおかげで「ここまではわかっているという場所」に一瞬で戻れるようになっている昨今、どんなに大事でも、腐ってしまったタスクは一度手放す方が賢い。……たぶん。

集中力は有限だ。一回触って、うまく解けなかった問題は、寝かせてみよう。またいつか、簡単に解けるかも。実は解かなくていいかも。大事なタスクを「抱え落ち」すると、他の人がすぐその問題を解けるかもしれない可能性を潰してしまう。