ID:65340さん

Epic Ownerとして、バックエンドエンジニア1名、フロントエンドエンジニア1名（状況に応じてアルバイトメンバーを含む）で構成される開発プロジェクトをマネジメントしました。PdMとの要件整理、タスクの優先順位付け・アサイン、コスト見積もり、進捗管理などを行いました。また、Epic Ownerである自分がコードレビューをすることで品質の保証にも取り組みました。

プロジェクト全体を計画どおりに進めるとともに、メンバーが手戻りや待ち時間を最小限に抑えながら開発できる状態を維持することが責務でした。そのため、PdMとEpic Owner間、およびプロジェクトメンバー間で仕様の認識齟齬が発生しないよう、機能要件・非機能要件を十分に整理することを重視しました。また、コードレビューでは短期的な実装効率だけでなく、可読性・保守性・テスト容易性を考慮した設計を促し、チーム全体で品質を維持しながら継続的に開発できる状態を目指しました。

品質と開発速度を両立させることを重視し、「仕様の認識齟齬を防ぐこと」と「メンバーの手待ち時間を発生させないこと」を意識してプロジェクトを進めていました。 まず、PdMとEpic Owner間、およびプロジェクトメンバー間で仕様の認識がずれると、後工程で大きな手戻りが発生すると考えていたため、実装前に機能要件・非機能要件を十分に整理し、認識合わせを行いました。一方で、仕様調整には一定の時間を要するため、その間に他メンバーの開発が止まってしまうことが課題でした。 そこで、仕様変更の影響が比較的小さいCRUD画面やAPIについては、要件をすべて固める前から担当者へタスクを割り振り、並行して開発を進められるようにしました。また、バックエンドのインターフェースはMockを用意し、フロントエンドはバックエンド実装の完了を待たずに開発へ着手できるようにするなど、依存関係を減らして開発を並列化しました。これにより、仕様策定を進めながらも開発全体の停滞を防ぎ、品質を維持しつつ開発速度の向上を図りました。 また、コードレビューでは、長期的な保守性を重視した技術的な意思決定を行いました。例えば、複雑な処理を1本のSQLで実装していたケースでは、可読性や保守性を考慮してSQLを複数に分割する提案を行いました。さらに、扱うデータ量から性能面で問題が発生しないことを確認したうえで、一部のロジックをGoのアプリケーションコードへ移し、単体テストを充実させる設計を提案しました。SQLを1本で完結させることよりも、将来的な変更容易性やチーム全体の保守性を優先する考え方を共有し、品質向上につなげました。

新卒の同期3人(元々4人だった)でチーム開発したSubReqのプロジェクトマネジメントをしました。具体的には、タスク出し・タスクの見積もり・開発メンバーへのタスクの分配などを担当していました。

必要な機能を納期までに開発し、実際に他の人が必要な手順を実施した後にサービスを利用できる状態にする責務がありました。本プロジェクトで開発したプロダクトはOPTiMのエンジニア報酬制度に提出するために開発したプロダクトです。エンジニア報酬制度とは、エンジニアの技術力を提出したリポジトリ・コードから評価するというOPTiMの社内制度です。報酬制度に提出するためには、サービスの概要やサービスを利用するための手順・使用技術などをドキュメントにまとめて、報酬制度の評価者がサービスを利用・評価できる状態にする必要がありました。私は開発に携わった開発メンバー全員がSubReqを報酬制度に提出した状態にする責務がありました。

以下の点を意識して取り組んでいました。 ・チームメンバーの得意な領域・やりたいことを整理し、適切にタスクを配分する。 ・チームメンバーにプロジェクトのスケジュールの全体感を伝える。(7月は機能A,8月は機能Bを完了のようなイメージ) ・余裕を持ったプロジェクトのスケジュールにして、予期せぬ出来事があっても納期に必ず間に合う様にする。具体的には、10月末が納期であったが、10月7日をチーム内で納期として設定したことで、確実に10月末の納期に間に合う様にした。 ・実装中にエラーに詰まった場合、必ずチーム全体に共有するようにしていた。チーム全体でエラー解決に取り組むことで、特定のエラーに大幅な時間を消費して、プロジェクトの納期に間に合わない危険性を避けた。 問題が生じたのは以下の2点です。 ・チーム開発当初(7月2日)にはチーム内で定めていた期限が12月末であったが、エンジニア報酬制度によって10月末まで期限が短くなった。(エンジニア報酬制度の期限が10月末までと知った日が8月12日) ・8月29日にメンバーの1人が個人的な事情で本プロジェクトを辞退した。 1つ目の納期の急な変更に関しては、mtgを開いて10月末までに開発する機能の見直しをしました。具体的には、サービスの価値を落とさない必要不可欠な機能のみ選定しました。また、サービスに関しても元々AWSを利用して外部公開する想定でしたが、ローカル環境でdockerコンテナを起動してサービスを利用していただく方針に変更しました。2つ目のメンバーの1人が辞退した件に関しては、残りのメンバーでタスクを上手く分担して調整しました。