「全部、急ぎです」と言われたら? 若手開発リーダーの優先順位の決め方

システム開発のリーダーと若手メンバーが、依頼内容と仕事の順番を検討するイメージ
影響と仕事のつながりを確かめ、優先順位の根拠を共有する。画像はAI生成の説明用イメージです。

リーダー育成

「全部、急ぎです」と言われたら? 若手開発リーダーの優先順位の決め方

「急ぎ」という言葉だけでは、開発チームの仕事の順番は決められません。私は、若手リーダーにまず身につけてほしいのは、遅れたときの影響と、ほかの仕事とのつながりを確かめ、その根拠をもとに順番を決める力だと考えています。

システム開発では、画面の修正、API仕様の確認、テストで見つかった不具合など、性質の違う仕事が同時に届きます。頼まれた順に着手したり、すべてをメンバーへ追加したりすれば、何を先に終えるべきかが曖昧になります。リーダーには、必要な情報を集め、今進める仕事と、条件を調整する仕事を整理して説明する役割があります。

この記事の要点

  • 「急ぎ」の理由を聞き、遅れたときに誰の何が止まるかを確かめる。
  • 後続作業へのつながりを捉え、順番の根拠を説明する。
  • 対応できる量も確認し、必要な納期・範囲・体制の調整まで扱う。

まず「急ぎ」の理由を確かめる

「今日中にお願いします」と依頼されたとき、期日だけを受け取って仕事の順番を変えていないでしょうか。今日中という希望に、どんな事情があるのかを確認します。明日の利用開始に間に合わせるためなのか、依頼者が明日不在だからなのかでは、考えるべき対応が違います。

担当者の説明を聞く前に、「追加機能の作業を優先すべきだ」と結論を決めないことです。いま利用中の機能への影響、後続工程の予定、代わりの対応があるかなど、判断に必要な条件を確かめます。そのとき、依頼者が確認した事実と、リーダー自身の見立ても分けておきます。

私なら、まず二つの問いを使って仕事の状況を整理します。相手を説得する材料を探すためではなく、チームとして守るべきことを明らかにするためです。

問い1.後回しにすると、誰の何が止まるか

一つ目は、対応が遅れたときの影響です。「困ります」という説明を受けたら、誰が、どんな作業を進められなくなるのかを具体的に聞きます。

たとえば画面の表示不具合でも、見た目の一部が崩れる状態と、必要な操作を完了できない状態では影響が異なります。利用できる条件や、当面の代替手段があるかも確かめます。不具合という名前や、依頼者の急ぎ方だけで順位をつけないためです。

事前に分かる情報から「この処理が止まると、翌日の受入テストを始められないのではないか」と仮説を置けば、「どの試験が、何を確認できない状態ですか」と質問を設計できます。説明を聞いて影響が違うと分かれば、見立てを修正します。重要そうだという印象を、そのまま判断の根拠にしないことです。

問い2.何が終わらないと、次の仕事へ進めないか

二つ目は、仕事の前後のつながりです。目の前の作業が終わることで、誰が次の仕事に進めるのかを確認します。

API仕様の確認自体は小さな仕事に見えても、その回答を待って画面の実装とテスト準備が止まっているかもしれません。この場合は、仕様を確定するための確認を先に進める案が考えられます。一方で、その仕様判断に必要な情報がまだなければ、まず情報をそろえる人と期限を決めます。

「この仕事を先にする」と指示するだけでなく、「この確認が済めば、画面側とテスト側が進められるため」と理由まで共有します。メンバーが前後の仕事を理解すれば、判断に迷ったときにも、何を相談すべきかを考えやすくなります。

順番を決めても、全部は終わらないことがある

二つの問いで順番を整理しても、必要な作業量がチームの対応できる範囲を超えていれば、すべてを期日までに終えることはできません。優先順位を決めることと、仕事を引き受けられることは、別に確認します。

その場合は、納期、対応する範囲、進め方、体制のどこを調整できるかを、上司や依頼元と相談します。たとえば追加画面の要望について、次の打ち合わせには画面案を示し、実装は後にできるかを確認する。こうした選択肢を、影響とともに提案します。権限のない約束を若手リーダーだけで決めず、誰の判断が必要かも明らかにします。

順番を変えるときには、後になる仕事の担当者と依頼元にも、理由と次の確認時期を伝えます。私は、先に進める仕事を選べたかだけでなく、待ってもらう相手への説明と調整まで行えたかを、リーダー育成の対象にしたいと考えています。

研修では、順位よりも判断の根拠を比べる

若手開発リーダーの研修でこの力を扱うなら、優先順位の一覧を覚えるだけでは足りません。情報が十分にそろっていない依頼を題材に、何を確かめ、どう判断するかを練習します。

今回の課題に合わせた演習例として、画面修正、仕様確認、不具合対応の架空の依頼メモを用意します。受講者は不足情報を挙げ、依頼元に聞く質問を作り、確認した条件をもとに順番と調整案を説明します。その後で追加情報を示し、最初の判断を変える必要があるかを検討します。

受講者同士では、「自分と同じ順番か」だけでなく、遅れの影響と後続作業を確かめたか、判断の根拠を相手に説明できたかを見ます。ここで示したものは演習の設計例です。実際には対象者の役割や、会社の判断・相談のルールに合わせて内容を組み立てます。

職場で決めた順番を、次の学びに持ち込む

研修後は、複数の依頼が重なった場面を一つ選び、実際に試します。何を確認し、どの根拠で順番を決め、誰と何を調整したかを記録します。結果として何が進み、どこで見込みと違いが出たかも残します。

次の研修では、その記録をもとに判断を振り返ります。期限の理由を十分に聞けていたか。別の担当者の回答待ちを見落としていなかったか。仕事の順番を変えた理由がメンバーに伝わっていたか。上司からも、判断の根拠と調整の進め方について意見をもらいます。共有する記録では、顧客名や社外秘の情報を除きます。

情報が変われば、優先順位も見直します。私が育成の中で確かめたいのは、最初からすべてを見通せたかではなく、必要な情報を集め、根拠を説明し、状況の変化に応じて判断を更新できたかです。その振り返りから、次に確かめることや、相談のタイミングを変えていきます。

開発リーダーの判断力を、日々の仕事から育てる

人間力教育センターのリーダー育成アカデミーでは、意思決定や実行計画、関係者との対話などを、各社の課題に合わせて学びと職場実践につなげます。依頼者の事情を理解する姿勢と、チームとして仕事を進める判断のスキルを、実践と振り返りの中で育てていきます。

若手リーダーが依頼を抱え込む、仕事の順番を説明できない、納期や範囲の相談が遅れる。そうした課題があれば、開発現場で任せたい判断と、上司が支援する範囲から、育成の内容を一緒に考えませんか。

教育コラム一覧へ戻る

↑