スタートアップの2年目エンジニアが考える優先順位付けとスケジューリング

はじめに

私はスタートアップのエンジニアになって2年目になりますが、タスクの優先順位の付け方に課題を抱えています。

チームで仕事をする場合は、優先順位の付け方を間違うと周りに迷惑をかけてしまいます。

• 私が経験した例
  • 優先順位を高く設定していたタスクが、実はそこまで高くなかったと発覚し、本当に優先順位が高いタスクに取り組めなかった。
  • 不確実性（把握できていないこと）を考慮せずに優先順位を付けてスケジューリングし、期限に間に合わずチームに迷惑をかけた。

優先順位の付け方に悩んでいる時、上長から以下の4つの軸で判断することを勧められました。

• 優先順位の判断軸
  • 重要度
  • 緊急度
  • 仕様的不確実性
  • 技術的不確実性

重要度と緊急度

まずは重要度という軸と緊急度という軸です。

「重要度が高くて、緊急度も高いタスクの優先順位を高く設定して対応すること」といえば、当たり前のように感じます。

しかし、ここで勘違いして欲しくないのは、重要度も高く、緊急度も高いタスクだけをやればいいということではありません。 重要なのは 重要度が高くて、緊急性が低いタスクに時間を割くこと です。

『時間管理のマトリクス』

上記の考え方は7つの習慣に出てくる『時間管理のマトリクス』を参考にしています。

完訳 7つの習慣 人格主義の回復

著書には以下の内容が書かれています。

第Ⅰ領域へ時間を割くことは避けられないが、第Ⅱ領域へ時間を割くことによって減らすことはできる

例えば、新機能を実装したときに、既存のコア機能が使用できなくなったとします。

コア機能が使用できないのでユーザ影響がかなり大きいと判断できます。よって重要度も高く、緊急度も高いので第Ⅰ領域のタスクになります。優先順位を高く設定して取り組むべきです。

しかしよくよく考えてみると、新機能の実装時に既存のコア機能が使用できなくなってしまうことを防げなかったことを問題視すべきではないでしょうか。テストを書いたり、リリース前の動作確認時にコア機能の動作も確認したりするなど、未然に防ぐ手段を考えることが重要になるはずです。

この場合、未然に防ぐ方法を考えることの重要度は非常に高いですが、緊急度は低いです。よって第Ⅱ領域のタスクになります。

つまり、第Ⅱ領域へ時間を割くことで、第Ⅰ領域の問題の発生を減らすことができるわけです。だから、重要度が高くて、緊急度が低いタスクにも時間を割くべきなのでしょうね。

また私が働いているようなスタートアップでは、いかに限られた時間で重要な課題にフォーカスするかが重要になります。

しかし、優先順位の高いタスクの割り込みが多いとパフォーマンスに大きく影響したり、割り込みの度に意思決定に体力を消費するため大事な場面での意思決定を間違ってしまったりします。

参考: スタートアップは行動しない / フォーカス、ツール、オペレーションについて

こういった違う視点でも、重要度と緊急度が高いタスクを発生させないように第Ⅱ領域のタスクに時間を割くことが重要であるとわかります。

仕様的不確実性と技術的不確実性

もう2つの判断軸として、仕様的不確実性と技術的不確実性という基準を設けています。

仕様的不確実性: 要件や仕様において不明確な部分の多さ 技術的不確実性: 実装する上で不明確な部分の多さ

不確実性に向き合う思考

上記は「エンジニアリング組織論への招待 不確実性に向き合う思考と組織のリファクタリング」という著書を参考にしています。

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

この著書の一説に以下の内容が書かれています。

エンジニアリングの本質が「不確実性の削減」であることに気づかずにいると、確実でない要求仕様にフラストレーションを抱え、確実でない実現手段にストレスを感じ、確実なものを確実な手段で提供したいというような決してありえない理想を思い描いて、苦しい思いをすることになってしまいます。

私も仕様や実装方針が定かでないのに対応してしまい、予想外のことに直面するという経験をしたことがあります。 結果手戻りなどが発生して、スケジュール通りに進めることが難しくなり、チームに迷惑をかけてしまいます。

そうならないためにも、私は「仕様的不確実性」と「技術的不確実性」が低いものから、優先順位を高く設定して対応するようにしています。 不確実性が低いものから対応すれば、予想外のことに直面する可能性も低く、スケジュール通りに進めやすくなるからです。

一方で不確実性が高いタスクは焦らず、上長とも認識を合わせながら、不確実性を削除していくようにしています。

また「仕様的不確実性」と「技術的不確実性」は低くて、30分以内で対応できそうなタスクは、重要度と緊急度が低くても優先度を高く設定するようにしています。すぐに対応できそうなタスクをいつまでも残しておきたくないという思いからです。

終わりに

優先順位付けやスケジューリングが不安定だと、チームに迷惑をかけてしまい、士気を下げてしまうかもしれません。さらにスタートアップとなるとサービスの成功にも大きく関わってくるのではないかなと感じています。

私もまだまだ優先順位付けやスケジューリングで迷うことがありますが、この考え方でいくつか改善された部分もあります。この記事を読んで、私と同じ状況で悩んでいる方の助けになれば幸いです。