※この記事は、2024 Speee Advent Calendar 25日目の記事です。
前日の記事はこちらになります。 tech.speee.jp
はじめに
こんにちは！
2024年1月に中途でSpeeeに入社し、現在は新規プロダクト開発のプロジェクトリーダーを担当している、手塚です。 入社から半年が経過したところで、担当プロダクトのプロジェクトリーダーという役割を初めて任されることになりました。
私自身、エンジニアとしてプロジェクトをリードしていく立場になって色々と学びがありましたので、この記事ではプロジェクトリーダーとして直面した課題と、それらを解決するために取った具体的なアプローチを共有しようと思います。 プロジェクトリードをしていくことになったエンジニアの方々に、プロジェクト推進する上での動き方が参考となる記事になれば幸いです。
目次はこちら
プロジェクトリーダーを初めて任された
Speeeに入社する前は、別の会社で業務委託エンジニアとして既に要件が決まった機能のバックエンド・フロントエンド実装を担当していました。 入社後は新規プロダクトの開発チームにjoinし、最初の半年間は既に要件が決まっている、1-2週間程度かかる中規模機能のデータベース設計やバックエンド・フロントエンド実装を中心に取り組んでいました。
入社して半年が経過した時点で、レビューを行いながら順調にスプリントゴールを達成していたこともあり、新規プロジェクトのプロジェクトリーダーを任されました。リードエンジニアからは、「まずは事業目標を達成するための機能をPdMと一緒に決めて、プロジェクトの開発計画を作成してほしい」と伝えられました。
任されたプロジェクトで直面した課題
まず、当時のプロジェクトの状況を簡単に説明します。
私がプロジェクトに参画する以前、提供予定の機能が事業目標の達成に十分かどうかを判断するために、事業責任者がプロトタイプを使った機能の仮説検証を実施していました。 事業目標の達成日から逆算した場合の開発開始時期を迎えたとき、仮説検証を通して製品版の開発に着手しても問題なさそうだという見解も出始めていました。
しかし、事業責任者は事業により大きなインパクトを早く与えるために、仮説から得られた結果を元にさらに仮説検証をするべきだという結論を下しました。 そこで、仮説検証期間を延長しつつも製品版のリリースは遅らせないように、仮説検証と製品版の開発準備を並行して進めることになりました。 私は仮説検証で得られた結果を製品版への要件に反映しつつ、開発準備をする必要がありました。
このような状況で以下のような課題がありました。
- プロトタイプの仮説検証も進行中で、製品版で何をつくればいいかわからない
- リードエンジニアは開発期間が約1ヶ月以上必要だと見込んではいたが、いつ開発が終わるかわからない
プロジェクトの課題にどう向き合ったか
これまでに、1ヶ月以上かかるプロジェクトをリードした経験はなかったので、先輩エンジニアにもアドバイスを求めながら、プロジェクトの課題を突破するために以下の行動を取りました。
他職種との同期と要件のブラッシュアップを繰り返した
まず、プロジェクトに参画した時点ではPdMがある程度の要件を決めており、私はその要件のキャッチアップから始めました。要件はスプレッドシートにまとめられており、今回実現したい機能の大枠は把握できましたが、開発する機能が解決したい課題に対して十分かどうかは不明でした。
そこで、自分の中で開発できるイメージが持てるように業務プロセスを図式化したりデータフロー図を作成して、要件の抜け漏れがないかを点検しました。 また、プロトタイプでの仮説検証が並行して行われていたので、要件が日々変化していました。事業状況の変化に伴う要件変更を確実にキャッチアップできるよう、事業責任者・PdMとのコミュニケーション頻度を高めました。
そして、新しくアップデートされた要件があれば、元々作成していた図に反映させて、チームメンバー間での情報の認識にずれが生じないように工夫しました。
タスク管理の徹底と状況に応じたゴール設定の更新をした
プロジェクト立ち上げ時では細かいタスクから大きいタスクまでやるべきことが無数にあるので、何から行動すればいいかわからない状況に陥ります。
なので、まず「誰が」「いつまでに」「何を」「どのように」やるかを決めました。 例えば、PdMには優先的に決めて欲しい要件を、チームのエンジニアには技術的な難所の調査を期限を設けてリクエストしました。 技術的な調査は調査開始時時点でどこまでを調査するかを決めたことで、調査時間にかけすぎないようにしました。
最初はSlack上でタスク依頼をしていましたが、Slackでのメッセージだと抜け漏れが発生してしまいました。これに対して、Slackのリスト機能を使って細かいタスクでもタスク管理を徹底したことで、タスクの抜け漏れを防ぐことができました。
私たちのチームではこれまで基本的に1週間のスプリントゴールを決めて開発を進めていましたが、今回の場合は要件が日々変化したり、調査結果から新たな課題が出てきて、やるべきことが週の途中で変化することがあったので、週初めにスプリントゴールを設けつつも必要なタイミングでゴールをアップデートしました。
技術的な難所に対して調査・設計をした
要件がすべて決まっていない段階でも、業務プロセスを整理する中でプロジェクトのメイン機能は必ず開発する必要があることがわかっていました。
しかし、その機能の実現するためにどのような設計・実装をすればいいかわからなかったので、メイン機能の開発方針と開発工数を明らかにするために技術調査を実施しました。 また、複数の設計パターンがあり議論が必要そうな部分については、Architectural Decision Records（ADR）を書いて、開発計画作成前に設計方針を固める動きをしました。
なお、私たちのチームで大切にしている意思決定プロセスは、こちらの記事をご覧ください。
学び
今回のプロジェクトリーダーの経験を通して、私はプロジェクトを推進していくために重要なことを主に2つ学びました。
早い段階で要件定義に関与すること
私たちのプロジェクトでは、仮説検証の結果を随時要件に反映させる必要があったため、要件の更新漏れや曖昧さが生じやすい状況でした。
このような状況下で、PdMによる要件アップデートを待つだけでなく、エンジニア自ら事業責任者・PdMを巻き込んで情報の同期をしたり、要件定義に積極的に参加していくことで、要件の抜け漏れを防ぐことができました。 早い段階でエンジニアも要件定義に主体的に関わることは、チームメンバー間の情報のずれを最小限に抑えながら開発する機能の具体化へ進めることができるので、開発着手まで早く辿り着けると思います。
早い段階で技術的な難所を潰すこと
要件定義の段階で技術的な難所を早く特定し、その難所を潰しにいく動きが大切です。開発する機能が今までの知識・経験から開発できるイメージがなければ、要件定義と並行して技術的調査をすることで、実現方法といつまでにその機能ができるかを早いタイミングで知ることができます。
そのような行動をすることで、プロジェクトの見通しが立ち、実装段階で行き当たりばったりで進めることなく、安心して開発を進めることができると思いました。
まとめ
プロジェクト立ち上げ時では「何をつくればいいかわからない」「いつ開発が終わるかわからない」といった不確実性が高い状況が発生しますが、プロジェクトリーダーは常にプロジェクトを推進することが求められます。
このような不確実性の高い状況下でもエンジニアとしての技術力を活かしつつ、他職種を自ら巻き込んでいけば、大きな課題も突破できることがわかりました。 今後もこうしたカオスな環境を楽しみつつ、事業・プロジェクトを推進できるように頑張りたいと思います。
本記事が同じような悩みを持っている人に届いてれば嬉しいです！
最後までお読みいただきありがとうございました！
Speeeでは一緒にサービス開発を推進してくれる仲間を大募集しています！
新卒の方はこちらより本選考に申し込みが可能です！
キャリア採用の方はこちらのFormよりカジュアル面談も気軽にお申し込みいただけます！
Speeeでは様々なポジションで募集中なので「どんなポジションがあるの？」と気になってくれてた方は、こちらチェックしてみてください！もちろんオープンポジション的に上記に限らず積極採用中です！！！
