IT開発組織でマネージャーをやっていると、プロジェクト実装がスケジュールに間に合いそうにない、と担当エンジニアから遅延のアラートが上がって来ることがあります。
先日もそのような相談があったので、アラートが来たときにどういう対処方法があるかを改めて考えてみました。
なお、アラートが上がって来ること自体は健全なチームの証です。もしプロジェクト遅延が発生しているのに、上司に怒られるから、のような理由で相談したくても出来なく、リリース期日間際になって遅延が発覚するなら、それは上司である自分自身に問題がないかを考えるべきです。
プロジェクトのエンジニア数を増やす
これはタスク量が多い時に有効な解決方法です。特に、複数エンジニアでコーディングしてもコンフリクトする箇所が少なく並列で進められそうな場合が当てはまります。
例えば、ブログプラットフォームの記事閲覧側と管理側でアサインを分けるとか、APIのサーバー側とクライアント側を一人で実装していたのを、もう一人追加してサーバー側とクライアント側で担当を分ける、などです。
この方法が有効かどうかは、タスクを複数の少タスクに分けられるかで判断出来ることもあります。複数のタスクに分けられるからといって必ずしもコードがコンフリクトしないというわけではありませんが、少なくとも１つの目安にはなります。
もちろん、プロジェクトが遅延しているからと言って、組織のエンジニア数をいきなり増やして即戦力にするのは難しいので、大抵は他の優先度の低いタスクを一旦停止し、そのタスクを担当していたエンジニアに手伝ってもらうことになります。そのエンジニアは既に自社コードベースに精通していることが多いので、プロジェクトの実装スピードをかなり改善出来ることが多いです。
経験豊富なエンジニアと交代してもらう
もしエンジニアのスキルに対してプロジェクトの技術的難易度が高過ぎるせいで遅延している場合は、もっとスキルが高くて経験のあるエンジニアに交代してもらうことで解決することがあります。
また、エンジニア自身に技術力はあるものの、チームに参加して日が浅いためコードベースを完全に把握していなかったり、ドメインナレッジが不足している場合も、この方法は有効です。
ただ、完全交代してプロジェクトから外してしまうとエンジニアの自信喪失につながったり、ドメインナレッジの共有が出来なくなってしまう可能性があります。難しい箇所の実装だけ手伝って残りは引き続き担当してもらうとか、ペア・プログラミングしてみるなど、プロジェクトの残り期間やチームのリソース状況にあわせて、残りの実装を全て巻き取るのか一部だけにするのかなど柔軟に対応したいものです。
なお、良い成長の機会かと思ってジュニアエンジニアをある程度レベルが高いタスクにアサインし、周囲もアドバイスなどしてみたものの、力及ばなかった、ということはどうしても起こってしまうものです。明らかにそのエンジニアのレベル以下のタスクしかアサインしないと、プロジェクト遅延は避けられるかもしれませんが、その人の成長機会を奪ってしまうことに繋がりかねませんので、注意が必要です。
自分をアサインする
これは最初の２つの方法の派生系ですが、人員的問題、もしくは技術的問題が発生したときに自分がプレイヤーとして出ていくパターンです。
元々技術力があったエンジニアだったためマネージャーになったケースに多いですが、「自分が実装すればすぐに終わる」と思ってしまう傾向が強いです。もしくは、マネージャーになったけどやはりたまにはコーディングもしたくなり、そういった場面が巡ってくるとスケジュールを間に合わせるために手を上げる、といった感じです。
私も決して例外ではなく、自分がマネージャー兼エンジニアとして行動することは決して少なくありません。特にエンジニア数が少ない組織だと、どうしてもプレーヤーとして動かなくてはならない時があります。
ただ、プロジェクト単体でなく組織全体を俯瞰して見た時に、それがベストな行動なのかはよく考える必要があります。自分が実装を担当したために本来のマネージャー業に支障が出たり、他のプロジェクトのレビューやテストが滞って代わりにそちらが遅延するなどの副作用が生じないよう、余裕のあるときだけにしましょう。
メインでないタスクを巻き取る
スタートアップや中小企業ではありがちですが、そのエンジニアが複数のタスクを抱えており、一番重要なタスクに100%の力を注げていないためにプロジェクトが遅延しているという場合、メインでないその他のタスクを巻き取ることが効果的です。
例えば、メインのタスクは遅れているのに、突発的に起こった本番環境でのクリティカルバグの修正も行わなければならない、といった状況です。
また、過去にそのエンジニアが実装した機能についての窓口がその人となっており、問い合わせ対応で追われてしまっているような場合も該当します。
バグ対応や問い合わせ対応など、メインでないタスクは全て別のエンジニアやPMにアサインし、そのエンジニアがプロジェクトに100%集中出来るような環境を作ってあげることで、実装スピードを上げてスケジュール遅延を取り戻すことが出来る可能性が高くなります。
外部にアウトソースする
これも最初の２つのケースの派生系で、内部でエンジニアを追加・変更するか、外部でそれを行なうかの違いです。
内部リソースにはどうしても限りがあるので、困った時に頼めるように外部の開発会社と常日頃から関係性を持って一緒に仕事をしておくのは悪くない考えです。プロジェクトに遅延が発生してから新しいアウトソース先を探し始めても、そんなにすぐに良いエンジニアが見つかる可能性は低いですし、たとえ見つかっても自社のコードベースに精通して戦力になるには数ヶ月かかってしまいます。
もちろん、外部のエンジニアをタスクがない状態で常に空いた状態でキープしておくのは無理な話ですから、定期的にタスクを依頼する必要があることは認識すべきです。
納期の延期を交渉する
要件定義が当事者同士でなかなか決まらなく実装期間が短くなったり、プロジェクト遅延がクライアントからの要求増大によるスコープ・クリープが原因の場合には、その原因に応じた期間変更を依頼することはなんらおかしなことではありません。
また、上記のような原因ではなく内部のリソース不足や技術力不足が原因の場合でも、当初予定していた納期が相手にとってそれほど重要ではなく、交渉してみたらすんなりと延期に応じてくれた、というのは私も何度も経験しています。
納期は当事者間の合意で決まるものですので、最初から無理だとあきらめるのではなく、だめもとで聞いてみるのが重要です。
仕様を削る
この方法は、新しい試みでビジネス的にうまくいくかわからないのに、最初から機能が盛り沢山になっているようなプロジェクトに有効です。
そのようなタスクの場合、実装途中であろうが改めて仕様を関係者で見直し、その機能のMVPは何なのか、あったら良いがクリティカルではない機能が紛れてないか、運用でカバー出来る部分はないのか等を議論することで、クリティカルでない機能を洗い出しスコープから外すことが可能な場合があります。
その上で、リリース直後は運用でカバーし、本当に運用が大変でその機能が必要になったタイミングで改めて追加改修の検討を行なう、などと提案することで、相手も未来永劫その機能が実装されないわけではない、と納得してくれることがあります。仕様交渉も納期交渉と同様、だめもとで尋ねてみることが大切です。
労働時間を増やす
残業や休日労働を許可もしくは要請して、短期間スパートをするやり方です。
リリース間近になると開発現場で起こりがちですが、これは自分的には最後の手段で、出来るだけやりたくはありません。自分が担当のタスクだったら遅延は自分の力不足なので止むを得ない部分もありますが、他人に強制するのはなるべく避けたいものです。
短期間的にはそれで乗り切れるかもしれませんが、日常茶飯事になってしまうとエンジニアも疲弊しますし、モチベーション低下に繋がりかねません。会社の労務的にも問題になったりしますし、残業代の増加で当初の予算をオーバーしてしまったりもします。
もしこの手段を使うなら、そのタスクがリリースされた後は原因を振り返り、次回からは通常の労働時間内で実装出来るような対策を行なうことが重要です。
まとめ
プロジェクト遅延の解決策をリストアップしてみましたが、問題が解決したらそのままにせず、そもそもなぜそのような状況に陥ってしまったのかをチーム全員で振り返ってみましょう。
プロジェクトボリュームに対して人員が不足していたのか、要求される技術水準とエンジニアのスキルにギャップがあったのか、それとも仕様に不必要な機能が盛り込まれていなかったのかなど、原因を究明して次のプロジェクトでは同じことを繰り返さないように改善につなげていくことが重要です。