入社2年半でチームリーダーに！～実際の試行錯誤と学び～

本記事は  【Advent Calendar 2025】  2日目の記事です。
🌟🎄  1日目  â–¶â–¶ æœ¬è¨˜äº‹ â–¶â–¶  3日目  ðŸŽ…🎁

はじめに

もう入社して3年が経ちました、冬爪です。 この記事では、3年前にIT未経験で入社した若手が、IT未経験からリーダー業務をどのように進め、どのような学びを得たかをまとめます。
これからリーダーを目指す方や、同じように悩んでいる方の参考になれば幸いです！

きっかけ

私がリーダー業務をすることになったきっかけは、PLがプロジェクトを離れることになったためです。
元々私のチームでは、プロジェクトマネージャー（PM）が1名、プロジェクトリーダー（PL）が1名、サブリーダーの私、開発メンバーが5名の体制で進めていました。 PLの育休中に一度、リーダー業務を担った経験があったため精神的な受け入れはスムーズでしたが、今回は長期的な責任を伴う本格的なリーダー業務だったので、 正直、不安とやる気が入り混じった状態でした。

PLを引き継いだ当時の課題

当時はプロジェクトの開発チームに参画してまだ1年半で、システム仕様の理解が不十分なことが大きな不安でした。 さらに、ミドルウェアの知見がまだあまりなかったので技術面でのプレッシャーも感じていました。
加えてPLが抜けたことでタスク量が増え、PMのサポートはあるものの、実質2人分のタスクを抱える状況になりました。 リーダーしか判断できない事項について、身近に相談できる相手がいなくなることも不安を強める要因でした。
こうした状況で「どのように業務を進めるか」が一番の課題でした。

半年間で直面した課題

リーダーになってからの半年間で、障害対応の判断や修正方針の決定、リリーススケジュールの策定と顧客調整など、責任の重い業務が一気に増えました。
さらに、顧客・基盤チーム・検証チーム・連携先システムとの並行コミュニケーションも必要になり、調整力が試される場面が多くありました。

障害を乗り越えた経験と学び

開発環境でとある障害が発生した時、なかなか問題の特定ができずに解決策の決定が難航しました。
その状況下で、開発メンバーには詳細な調査を依頼し、自身はリリースの調整や修正方針の決定に注力しました。 役割を分担することで効率的に対応を進めることができ、最終的には停止していた機能を復活させることに成功しました。 振り返ると個人的に知見があまりないSpring Bootのバージョンアップが原因でしたが、この経験を通じて以下の学びを得ました。

• わからないことは溜め込まずに聞くこと

障害対応を一人で任された際、リリースの調整や検証の進め方をスピード感を持って決める必要がありました。 しかし勝手がわからず迷っていたため、すぐにPMに相談しました。
その結果、方針を早期に決定でき、対応を滞りなく進めることができました。相談することで時間のロスを防げると実感しました。

• 他チームにも協力してもらうこと

Spring Bootに関する障害対応では、他チームに資料を共有してもらったり、同様の事象が過去に発生していないか状況を確認しました。
異なる視点や知識を持つメンバーの協力によって、より確実な対応ができました。

• 十分な情報を収集すること

事前に関連ドキュメントや事例を調べていたおかげで、障害が起きた部分以外では特に困ることがなく、スムーズに対応できました。
準備をしておくことで、予期せぬトラブルにも落ち着いて対応できると実感しました。

今回はSpring Bootの事前調査を行った上で開発環境で発生した障害でしたが、今回の障害を乗り越えたことで、次回以降障害が発生しても冷静に対応しようという自信に繋がりました。

業務を進めるために工夫したこと

1. 開発メンバーの底上げ

リーダーの負担を軽減するにあたってPMにアドバイスをいただき、週に1回定期的に相談に乗ってもらえる開発リーダーというポジションを新設し、既存の開発メンバーから適任者を抜擢しました。 これにより、仕様や設計に迷った際は相談できるため精神的な支えを得ることができました。 また、リーダー以外でも対応可能な問い合わせは、開発リーダーをメンションに含めてもらい、タスクの振り分けをお願いしたことでさらに分担できるようになりました。
これらを続けてきたことで開発メンバーが自発的にタスクを拾ってくれるようになり、よりチームが活性化しました。

2. 自己開示とコミュニケーション強化で信頼関係を築く

自分の不安や課題を率直に共有し、相互にサポートしやすい雰囲気を作ることを心がけました。 また、メールやチャットだけでは認識のズレが起きやすいため、Zoomや対面での打ち合わせを増やし、重要な仕様やスケジュール調整は必ず口頭で確認しました。
これにより、トラブルを未然に防ぎ、チーム全体の主体性を引き出すことにつながりました。

3. 優先度を明確化

タスクが山積みになる中で、まず「自分が必ず確認しなければならないタスク」を最優先にしました。これにより、責任範囲の重要な部分を確実に押さえ、抜け漏れを防ぎました。 一方で、個人に依存しない対応可能な作業は積極的に開発メンバーに依頼しました。 これにより負担を分散し、チーム全体で効率的に進める体制を構築しました。
さらに、クリティカルなタスクは絶対に後回しにしないことを徹底しました。重要度と緊急度を軸にタスクを整理し、優先度を明確化することで、進捗を見える化して焦りを減らすことができました。

半年で得た学び

半年を振り返って感じたのは、気づいてもらうのを待たず、自分から相談することの重要性です。 また、タスクを振ることで負担を減らしたり、3年間で培ってきた人脈を活用して、チーム内はもちろん、他部署他チームとも相談できる関係を築いたりすることが業務を円滑に進めるカギだと思います。
結局、リーダー業務は「人間関係の構築」と「タスクとスケジュールの管理」が最も大切だと痛感しました。 未経験からリーダーになるのは不安も大きいですが、次の3ステップを意識すると業務がスムーズになると感じています。

1. 困ったときに頼れる人を明確にし相談できる環境を整える
2. タスクを「緊急度×重要度」で整理して優先度を決める習慣をつける
3. 認識相違を防ぐため、対面やオンラインでこまめに確認してコミュニケーションを強化する

まとめ

リーダー業務は人に働きかけることが業務の大半を占めるので、やはりコミュニケーションを磨いていくことが重要だなと感じています。
半年が経った今も、まだまだ手探り状態ですが、今後も少しずつ自分自身で判断できることを増やしていきたいと思います。 この記事は成長記録のようなものですが、誰かの参考になれば幸いです✨
最後まで読んでいただき、ありがとうございました！

余談

今回の記事はCopilotにインタビューしてもらいながら作成しました！
意外とCopilotに送った内容と真逆の解釈をされて文章が書かれていたり、自分自身では使わない言葉を使われていたり、しっかり確認が必要だなと思う反面、知らない言葉を知ることができたので総じて学びになりました☺
また、新人時代にまとめた自分の記事がPMや他チームに質問するときにも非常に役に立ったので置いておきます。

tech.nri-net.com

執筆者：冬爪
若手アプリエンジニア ポケモンだいすき✨