お疲れ様です！IT業界で働くアライグマです！
中途入社してわずか2週間、まだ社内のルールやプロダクトの全体像を把握しきれていないタイミングで、受託開発プロジェクトの責任者（プロジェクトマネージャー）を急遽引き継ぐことになった経験があります。
チームメンバーは私以外全員がジュニアエンジニアという構成でした。顧客からの要望チケットは粒度が粗く、引き継ぎ期間もほとんど取れないという厳しい状況下で、いかにしてリリース遅延を出さずに品質を保ち続けたのか。そのとき実践した「タスクの咀嚼と割り振り術」について振り返ります。
入社2週間で受託開発チームを引き継いだ背景
当時私が担当することになったのは、あるリンクまとめサービスの受託開発プロジェクトでした。
中途入社してわずか2週間のタイミングで、前任者からプロジェクトを引き継ぐことになりました。受託開発では通常、システムのドメイン知識や顧客とのコミュニケーションの癖、過去の経緯をある程度把握してから案件に入るのが理想です。しかし、今回は引き継ぎ期間が極めて短く、プロダクト全体のアーキテクチャやコードベースを把握するのと並行して、その日から現場のマネジメントを開始しなければならない状況でした。
引き継ぎ当初のチーム体制は、私を含めて3名（配下メンバー2名）。その後案件の進行に合わせて2名が増加し、最大で私＋メンバー4名の5名体制となりました。メンバーはいずれも実務経験の浅いジュニアエンジニアでした。意欲は非常に高いものの、複雑な仕様の意図を汲み取ったり、影響範囲を自力で見極めて設計に落とし込んだりする経験はまだ不足していました。
この体制で求められていた私の責務は明確でした。「顧客が定義した仕様をもとに、ジュニア中心のチームで品質と納期を担保しながら、継続的に機能追加とリリースを行い続ける体制を維持すること」です。開発を一切止めることは許されないプレッシャーの中で、プロジェクトのリスタートが切られました。
IT女子 アラ美
ITアライグマ直面した3つの壁：粗い要件、スキルのばらつき、短すぎる引き継ぎ期間
現場に入ってすぐに、チームの進行を妨げる3つの大きな壁に直面しました。
1つ目の壁は、顧客からBacklogに登録されるタスクの粒度が粗かったことです。顧客の担当者は非エンジニアであり、要件が「〇〇のボタンを押したら集計結果が出るようにしたい」「一覧画面の表示をいい感じに整えたい」といった大まかな要望のままチケットが起票されていました。画面遷移やエラーハンドリング、DBの既存データへの影響などは明記されておらず、仕様としてメンバーにそのまま渡せるレベルではありませんでした。
2つ目の壁は、ジュニアメンバーのスキルレベルにばらつきがあったことです。フロントエンドのマークアップは得意だがバックエンドのAPI実装には不慣れなメンバーや、ロジックは書けるがCSSやレスポンシブ対応に時間がかかるメンバーなど、得意・不得意がそれぞれ異なっていました。タスクの難易度と担当者のマッチングを誤ると、一人の詰まりが全体のスケジュールを大きく狂わせる危険がありました。
3つ目の壁は、引き継ぎ期間が極めて短く、プロダクト全体の学習とマネジメントを同時に行わなければならなかったことです。本来ならじっくりコードを読んでドメインモデルを理解したいところですが、受託開発の現場ではすでに進行中の機能開発や直近のリリース納期が迫っていました。立ち止まって全体を完全に把握してから動き出すという選択肢は取れませんでした。
IT女子 アラ美ITアライグマ顧客の運用を否定せず「自チームで咀嚼する」防波堤アプローチ
こうした状況でまず検討されるのが、「顧客に対して要件定義やチケットの書き方のルールを厳格化してもらう」というアプローチです。しかし、私はその方針を選びませんでした。
顧客側にはこれまでの業務フローがあり、受託開発において発注者に詳細な要件定義書の作成やチケットの厳密な記述を強いると、コミュニケーションコストが増大し、関係性の摩擦を生む原因になりやすいからです。そこで私は、「顧客側の自由な運用を尊重し、こちら側（PM）で仕様を咀嚼する防波堤になる」という方針を取りました。
具体的には、顧客がBacklogに追加したチケットをメンバーに直接アサインせず、まず私がすべて受け取り、以下の手順で分解・再定義を行いました。
1. 影響範囲の特定: 修正対象の画面、API、DBテーブル、影響を受ける既存機能を洗い出す
2. 難易度と作業分割: 1チケットあたり「半日〜1日」で完了する実装単位に分解する
3. メンバー適合判定: メンバーの現在のスキルセット（得意・苦手）に合わせてチケットをアサインするたとえば、「一覧画面に集計指標を追加したい」という大まかなチケットが届いた場合、そのまま渡すのではなく、「①集計用APIの改修（BE担当）」「②一覧テーブルの表示コンポーネント改修（FE担当）」「③ローディングおよびデータ0件時の例外表示対応（ジュニアメンバーのチャレンジ枠）」のように分解します。
さらに、各子チケットには「変更対象のファイル候補」「満たすべき完了条件（受け入れ基準）」を明記しました。これにより、メンバーは「何をどうすれば完了なのか」が明確になり、迷うことなく実装に集中できるようになりました。着任直後の立ち上げ期における役割分担や信頼関係の重要性については、エンジニアリングマネージャー転身ガイド：最初の30日間で実践すべきアクションでも触れられていますが、受託開発における防波堤としてのタスク咀嚼は、まさにチームの土台を固める実践そのものでした。
IT女子 アラ美ITアライグマプレイングでの伴走と週次定例による認識齟齬の早期解消
タスクを咀嚼してチケットを切り分けるだけでは、引き継ぎ初期の不安定な時期を乗り切るには不十分でした。そこで、日々の開発サイクルにおいて2つの工夫を徹底しました。
1つ目は、マネージャー自身がコードレビューを行い、プレイヤーとしても実装・デプロイに伴走することです。
メンバーが作成したPull Requestは、単に動作確認をするだけでなく、「なぜこの書き方にしたのか」「例外系の考慮漏れはないか」を丁寧にレビューしました。また、難易度の高い基盤改修や急ぎのデプロイ作業は私自身がプレイヤーとして手を動かして引き受けることで、ジュニアメンバーが無理な背伸びで潰れてしまわないようセーフティネットを張りました。自らコードを触り続けることで、私自身もプロダクトのコードベースへの理解を短期間で急速に深めることができました。
2つ目は、毎週の定例ミーティングで、リリース済みの機能と直近の進捗を直接デモ・説明することです。
顧客との定例会では、「今週どのタスクを完了し、本番環境に何をリリースしたか」を画面で見せながら説明しました。文章だけの報告では見落とされがちな「認識のズレ」を画面を動かしながら早期に発見し、その場で「仕様はこれで合っていますか？」と確認を挟む運用を徹底しました。
もし咀嚼した解釈に誤りがあったとしても、1週間単位の短いサイクルでフィードバックをもらえれば、手戻りのコストは最小限で済みます。この「プレイングでのフォロー」と「定例での早期認識合わせ」を組み合わせたことで、顧客との信頼関係も急速に構築されていきました。
IT女子 アラ美ITアライグマまとめ
入社2週間という短期間の引き継ぎにもかかわらず、プロジェクトは一度も納期遅延を出すことなく、継続的な機能追加とリリースサイクルを維持することができました。
今回の経験を通して学んだのは、以下の3点です。
- 顧客の運用を変えようとせず、チーム側が仕様を咀嚼する防波堤になること
- チケットを「半日〜1日」の粒度に分解し、メンバーのスキルに合わせてアサインすること
- プレイングでのレビュー・フォローと週次定例でのデモにより、認識のズレを早期に潰すこと
特にジュニアエンジニアが中心のチームでは、「何をすればいいか分からない」という状態が一番のボトルネックになります。PMがタスクを丁寧に咀嚼して渡すことで、メンバーは安心して実装に集中でき、成功体験を積みながら確実に成長していくことができます。
急な案件の引き継ぎや、ジュニア中心の受託チームマネジメントで悩んでいる方の参考になれば幸いです。
IT女子 アラ美ITアライグマ
