はじめに
初めてプロジェクトリーダーを任されてから8ヶ月が経過し、これまでに直面した失敗とその対策をまとめて記事にしていきます。まだ実践できていないところもありますが、今後の行動指針として少しずつ実践していければと思います。
独りで多くのタスクを抱え込む
開発現場では基本的にマネージャー、リーダー、エンジニアという3つの役割が立てられますが、場合によってはこれらの役割を2つ、3つと兼務することが多々あります。この8ヶ月間、プロジェクトリーダーとしての役割を果たしながら、開発者としても実装を進めていました。具体的には、API・DB設計、新規機能の開発、PR確認、要望対応、工数算出、リファクタリング、お問い合わせ対応、クライアントとのミーティング、バグ改修といったすべてのタスクが降りかかっている状況でした。多くのプロジェクトリーダーが初期に陥る罠として、「誰かに依頼するより自分でやったほうが早い」と思い込み、一人で抱え込んでしまうことがあります。自分自身も例外ではなく、結果的に仕事を抱え込みすぎてしまいました。この状態ではすべてのタスクを満足にこなすことはできず、「自分がやらないと駄目」、「自分がすべてを把握していないと駄目」と思い込んでしまい、結果として残業が増え、疲弊が続きました。その結果、業務の細部にまで気が回らず、開発メンバーの残業も増え、全体的な疲弊感が広がるという負のスパイラルに陥りました。
対策： 1. 自分でやった方が早いを克服する
作業の方針と期待値をメンバーに提示し、定期的に状況を確認しつつも、メンバーに任せることができる箇所はどんどん任せるようにしています。タスクのうち、自分自身が作ろうと思っていたものの時間不足で手が付けられずそのままになっているタスクがあれば、それを他のメンバーに依頼します。
対策： 2. 頭出しで相談する
タスクの優先順位など判断に迷ったら、「実装等の方針」を予め提示できる状態にした上で、ある程度メンバーにも頭出しを行います。例えば「タスクを1,2,3の順番で実施予定ですが、もし優先して行うタスクが存在すれば教えてもらえるとありがたいです。」とslack等でコミュニケーションをとると相手も回答しやすくなります。相談することで周囲を巻き込みつつ、手戻りをできる限り少なくします。
対策： 3. その場しのぎをやめる
進捗の遅れなどが発生し、スケジュール通りにいかなかった場合、早めに相談して調整作業に入ります。よくありがちなものとして、遅れているタスクを自身が巻き取って終わらせるという選択肢がありますが、プロジェクトリーダーには別の作業タスクが存在し、それが優先度の高いものであった場合（例えばタスクの実装方針検討等）、メンバーが後続タスクに取り掛かることができなくなってしまいます。また、プロジェクトリーダーにタスクが集中し、結果的にメンバー管理が疎かになり、プロジェクト全体の進捗を遅らせてしまう可能性もあります。先のタスクの状況を見て、安易に自身で終わらせようとするのではなく、全体的な状況を見て判断していくことが重要です。
対策： 4. プロジェクト全体の確認と技術を同時にバランスよく進めるコツを掴む
納期を間に合わせるために、時間を都度分割して「時間管理」するコツを試行錯誤で身に付けていきます。言われるがままにコードを書いたり、ミーティングに出席するのではなく、適宜「プロジェクト全体の計画と調整を見失わないこと」が重要となってきます。自分一人が担当するコーディング作業から一歩引いて、チーム全体での技術力の貢献や調整を行っていきます。
レビューの品質低下
多くのタスクを一度に多く抱えてしまった為、メンバーから依頼を受けたPRレビューの時間を確保することができず、レビューが3~4日後になることがザラにありました。コードレビューが遅滞した場合、チームメンバーが書いた新機能や不具合修正は、レビュー待ち、再レビュー待ちの状態が何日も続き、チーム全体の開発速度が減少することにつながります。
対策: PRレビューは最優先で着手する
タスクに集中的に取り組んでいる最中でなければ、コードレビューの依頼が来たら最優先で着手、遅くても営業日1日以内に実施するようにして、ソフトウェアの品質向上に努めています。もし緊急の対応により着手が遅れる場合は、より広い視点で挙動に問題がないか、全体として問題なく設計されているかどうかを、初期段階のコメントを残すようにしてます。
差し込みタスクの増加
これは案件の性質上仕方がないことではありますが、日常的に差し込みタスクが発生しており、優先順位が入れ替わることが度々発生していました。
開発スピードを鈍化させる要因の一つとして、差し込みタスクの増加が挙げられます。タスクの優先順位の変化やさまざまなことに対応することによって、実装者は集中してタスクに取り組むことができず、開発スピードに与えるコストは多大になります。
対策： 1. 差し込みタスクの削減
まずは初期の段階で、全てのタスクの洗い出しを行い（荒すぎず、細かすぎない粒度）、タスクの緊急度・優先度を決定します。同じ内容のチケットはできる限りまとめて実装するように割り振り、差し込みタスクはできる限り減らすようにすると良いでしょう。
対策： 2. 新規タスクの仕様把握を初期段階で行う
タスクの仕様把握を初期段階で、ある程度プロジェクトについて掘り下げ、ある程度満足のいく程度にまで予想し予定を組み組み込みます。初期の段階では、完璧に計画を立てることや事前に仕様について詳細に把握する必要はなく、
対策： 3. クリティカルパスの把握
クリティカルパスとは、プロジェクトを進めていく中で、そのタスクが完了しないことにより、プロジェクト全体の遅延に繋がるようなタスクを把握するプロジェクトの管理方法です。クリティカルパスがどこに存在するのかは適宜把握して、タスク遅延が発生しないようにしていきます。
エンジニア間の連携不足
業務が忙しくなるにつれ、エンジニア間でコミュニケーションを行う回数が減り、個々人で実装している内容を把握しきれていない事がありました。メンバーの実装の進捗を把握しきれていなかった為、結果的に進捗が遅れていることが後半で発覚して残業して納期に間に合わせることが多くありました。
対策： 1. エンジニア間のミーティングを毎週開催する
エンジニア間のコミュニケーション強化の為、定例後に週2回、エンジニア間で個々人で実装している内容の把握や、実装で気になっている箇所がないかどうかを話し合う場を設けています。この機会を通して実装の状況を理解するだけでなく、チームメンバーが今考えていることやプロジェクトの改善点を吸い上げる場としても機能させていきます。
対策： 2. 1on1面談の実施、プチ勉強会の実施
ミーティングだけでなく、1on1面談とプチ勉強会を定期的に実施してます。1on1面談やプチ勉強会を行う目的は以下の三つです。
-
自分自身とメンバーとの間に人間的なつながりをもつ
毎回言う必要はありませんが、業務外のプライベートな部分まで少しづつ自らオープンに話すことで信頼関係の構築を図ります。 -
早期アラートの発見
メンバーの気力や活力が落ちたことに気づいた場合、面談を通して何らかのアクションを取ったり、全体の場では話しづらいプロジェクト（やプロジェクトリーダー）に対する不満点を聞き改善に持っていきます。 -
要検討事項について話し合う
要検討事項については普段のミーティングでも話しますが、もし必要であれば面談を通じて確認をとります。
自分自身割と人見知りでコミュニケーションが苦手ところがあるのですが、1on1の場合気軽にメンバーと話すことができる為、肌に合っていると感じます。
勉強会は毎週実施しスクラップで議事録をとっています。
1on1で質問する内容は以下のフォーマットを参考にしてます。
対策： 3.心理的安定性を確保する
プロジェクトで何か失敗して報告が上がってきた場合、本人を責めるのではなく、まずは報告してくれたことに「ありがとう」と伝えるようにします。起きてしまった出来事に対して、怒ったとしてもプロジェクトが進ことはなく、起きた問題が二度と起きないように仕組み化して対策することに注力する方が良いです。また、別の作業を行っていたとしても、質問・相談にはできる限り答えるようにしてます。
対策： 4. メンバーの仕事の障害を取り除く
自身の仕事よりもまずは開発メンバーの仕事の障害を取り除くことを優先的に取り組みます。開発メンバーの進捗が滞ってしまうと、結果として全体の進捗が遅れてしまう為です。
業務の属人化
運用を長く続けているとトラブル発生箇所のドメインによってメンバーが固定化・業務の属人化が発生しており、特定の個人がもつスキルや知識・ノウハウに強く依存する状況にありました。特定業務に関する手順について個人の知識に強く依存してしまった為、担当者が不在の時はタスクが実施できず、担当者にかかる負荷が過大になる傾向がありました。
対策： 属人化の防止
ドメインについてメンバー全員が調査対応できるようにすること。知識や調査方法を共有することで知識の属人化を防ぐ試みを行いました。また、問い合わせ調査のOJTを行い、メンバーが調査対応できるようにすることで、知識や調査方法を共有することで知識の属人化を防ぐ試みを行います。
チケットごとの実装着手前に実装方針を共有することで、ドメイン知識向上を図っていきます。（ペアプロといったり2人1組でペアを組んでプログラミングを進めていく開発手法は非常に効果が高いですが、Previewerの時間が大きく取られてしまう為、実装方針の共有だけで済ますようにしてます。）
工数が足りない
メンバーが多かった頃と同じ感覚で当初は工数を算出しましたが、メンバーが削減されたことにより、一人に業務が集中し、当初想定していた工数よりもはるかに多くの開発時間がかかってしまいました。工数が足りなくなったことで残業が増加し、平日は遅くまで開発を行い、土日も返上でリカバリーを行うため、疲労からくる判断の遅れ・間違いや心身の不調、メンバーの離脱が発生してしまいました。
対策： 1. 想定の1.5倍算出する
バッファとして、実際に想定した工数の1.5倍を見積もるようにします。どんなに予想を立てて開発しても、不測の事態は必ず発生するものです。もしバッファのない工数を出してスケジュールが遅れてしまうと評価が下がりやすいですが、見積もりに対して予想よりも早く終わらせると評価が高まりやすく、後続タスクへの影響も最小限に抑えることができます。不確実性が高い案件やタスクほど、余裕を持った工数を算出するようにしています。
対策： 2. 工数算出の根拠を持つ
どのような工数の数字であれ、例えば、以前の類似案件がn人日だったから同じくらいn人日必要など、ある程度は自分なりの根拠を持つようにします。これは工数に対して譲らないためにも重要なことです。
対策： 3. やらなくても良いことを決める
限られたリソースの中で最大限効果を発揮するために、そもそもやらなくても良いことを決定します。必須の「実装しなければならない機能」と「開発に使える人員」を算出し、今やらなくても良い開発や優先順位の低い開発は後工程で対応するように調整します。「工数 = 時間 × 人」と定義される計算式において、時間が固定であるなら、人員を増やすことで工数を増加させることは可能ですが、ロジックが非常に複雑なプロジェクトにおいては人員の増加が効果的ではないこともあり、状況によって追加人員のための予算を確保できない場合もあります。
最後に
ここまで色々と自分が失敗したことと実施していること（今後実施したいこと）をまとめていきました。まだチームとして完全にパフォーマンスを出せるところまではいっていないと思いますが、今後も取り組んでいきたいと思います。
参考文献
Discussion