プロジェクトマネジメント体験記 - Adwaysエンジニアブログ

みなさんこんにちは。アドプラットフォーム事業でアプリケーションエンジニアをしています、中村です。

この記事では、自分が1Q(2023年1月~3月)に主導して行った、広告プラットフォーム連携のアプリケーションの開発に関して書いていきたいと思います。主にプロジェクトマネジメントの観点から自身とチームの動きの関係を中心に、どのように進めていったか、及びその中で感じたことを振り返りながら書いていきたいと思います。ちなみに、他社ではテックリードのような役職の方が行う、技術選定及びそのリードも兼ねて行いました。しかし、それについても書いているととても長くなってしまうため、要所要所で触れる程度にしたいと思います。

プロジェクトマネジメントに関わったことがある人、及びこれから関わる人に向けて、なんらかの参考になれば幸いです。

背景と目的
やったこと(概要)
やったこと(詳細)
まとめ

背景と目的

背景と目的については、過去に自分が書いた記事を参照していただけると幸いです。

一言で言うと、自社サービスのデータを利用して広告の最適化を図る施作の一環であるアプリケーションを開発しました。
自分が以前から携わっていたプロジェクトだったのでチーム内で一番詳しいということもあり、自分から手を挙げてプロジェクトのリードを担当しました💪

やったこと(概要)

今回の仕事では、アプリケーションの設計の前段階である開発可能判断の調査から行いました。並行して設計も行なっていました。
その後、タスク分割・分配を行い、実際にタスクをチームのエンジニアに割り当てました。
最初は自身のタスクをこなしつつ周りのサポートを行っていましたが、想像以上にきつかったので途中からはサポートに徹しました。
その後、チームのシニアエンジニア(ここでは、二つ以上のプロジェクトの進行および技術的に責任を持つエンジニアという意味です)に入ってもらい、設計を見直しつつなんとか動くものを作りました。現在は運用・改善フェーズに入ることができています。

以下でそれぞれのフェーズについて、詳細にやったこと(起こったこと)及び所感を書いていきます。

やったこと(詳細)

開発可能判断の調査

最初に割り当てられたタスクは、設計の前段階としてそもそも開発可能か調査する&可能であればどれくらいの期間で開発できそうか見積もる、というものでした。
調査と言いつつ、これまでの経験から
期間を見積もるにはざっくり設計をしてみないと分からない
ことに気づいたので、システムのデータの流れや構成を図に起こしながら考えました。調査としては、他社の公開している似たシステムの使い方の記事や広告プラットフォーム側の提供しているAPIのドキュメントを読みました。
また、この件に関して社内のチャットツールでつぶやいたところ、Agency事業部の大窄さんが知見があるとのことで声をかけてくれました。その結果、広告プラットフォーム側のAPIについては、かなりスムーズに調査を進めることができたので感謝しています。
設計図については、チーム内外の3人のエンジニアにレビューを頼みました。その結果、もう少しリッチに作り込む方面と、検証だからざっくりGAS(Google App Script)とかで動くものを作ってもいいんじゃないかという2方面からのフィードバックをいただきました。フィードバックをいただいてから加えて3つ設計図を描き、その中で一番リトライや検知の仕組みが作りやすい設計に決定しました。

所感

この時点では、比較的いい動きができていたと思います。普段読みなれているような技術的なドキュメントではないものの、知ってる人に聞いたり、スプリントレビューを待たずしてPdM(プロダクトマネージャー)側に調査結果を先出するなどして、認識のずれを最小化する動きが取れていました。
しかし、この時点で検証なのか、作り込んでいいのかの期待値合わせまでしっかり行なっておくべきだったなと今では思います。

結論として、1ヶ月(4スプリント)で見積もりを出し、その期間で作るということで合意を得ました。

タスク分割・分配

次に、前のフェーズで作成した設計図に基づいてタスクを書き出して、人に渡せる粒度まで分解しました。
この作業を始めた時はスプリントの途中だったため、リファインメント(チームで行っているバックログにあるタスク詳細化及び優先度決めのための会議)を待たず動いていました。手が空いた人から個別にタスクを渡すイメージです。
全体的に、スプリントの開始や終了を待たずに、動けるところから先読みして動き始めることを意識していました。
ちなみに、その頃チームの編成が固まり切る前だったため自分を含めて5人のエンジニアがこのプロジェクトに割り当てられているという状況でした。多いですね！！

所感

この動きはあまり上手くできてなかったなと思います。
まず、タスクの粒度ですが、割り当ててみると思ったより大きめの粒度で渡していたようです。チームの人は前Q(2022年10月~12月)に別の広告プラットフォーム連携のアプリケーション開発で使っていた技術であるScala3/ZIO2、およびそれに付随する種々のライブラリやフレームワーク、ひいてはそれが動いているインフラ環境であるECSなどに明るいメンバーではありませんでした。そのことを知ってはいたのですがあまり加味できず、自分がわかるより少し丁寧めくらいの詳細を書き、残りは各人に合わせてサポートでカバーしようとしました。

結果、全員に想定以上のサポートが必要になりました。

次に、各人に個別に渡したせいで全体感や個別のタスクの関係をちゃんと把握しているのが自分一人になってしまいました。その結果、技術及び仕様面の質問が自分に一極集中し、本当に大変なことになりました。
幸い、チームの振り返りでこの辺りの不安を共有したところ、「このプロジェクトは技術的な投資案件として扱っていい」ということをエンジニア間で合意は取っていました。要は、多少プロジェクトが伸びても技術的な知見を共有できるメリットを優先するということです。しかし、この点に関して、PdMやその上ときちんと合意が取れていたかというと微妙なラインでした。

期間が伸びるとして、どれくらい伸びるのか？

リソースが必要だとして、何人をどれくらい当てるのか？

そういった、時間やリソース管理の観点をもちつつ、全体感を持ってプロジェクトに責任を持つ人がいないというよくない状況になっていました。

自身のタスクをやりつつ、周りにタスクをやってもらう&それをサポートする動き

上記のような粒度の大きいタスク分割のままチームのエンジニアにタスクが分配され、自身のタスクもこなしつつサポートをする期間が始まりました。

2スプリントくらいで限界が来ました。

加えて、チームで抱えていたもう一つのプロジェクトの優先度が上がり、そちらにチームのシニアエンジニアが二人とも割当てられてしまいました。元々技術的にちゃんとリードできるのが自分だけだった上に、リソースまで持ってかれた形になります。
広告プラットフォーム連携のプロジェクトは、ある程度出来上がるまでデモで見せられる機能がないという性質がありました。その結果プロジェクト進行に対する注目度は下がり、スプリントレビューの議論の中心ももう一つのプロジェクトに置き換わりました。

所感

この辺りで、自分はなんとなくやばいと感じていた(かつ週次の振り返りで軽く伝えてはいた)ことが確信に変わったものの、それをどう伝えてどうして欲しいかまで考えてアクションできるような余裕を失っていました。
日中は技術的サポートの応対をしていたらあっという間に定時が来るので、朝少し早起きするか夜ご飯を食べて戻ってくるかしてなんとか割り当てられていた分のタスクは完了させました。

流石にやばい状態になっていることをチームに伝え、以下のように変わりました。

自身のタスクは割り当てずサポートに徹させてもらうこと
コードレビューは自分以外に分担すること
各人のタスクで扱うデータの入力/出力を確認し、前後の作業者間で合意を取ること

なるべく自分に一極集中していた負荷を分散するような状態に持っていきました。

周りのサポートに徹する動き

周りのサポートに集中させてもらえるようになり、全体を見る余裕が生まれました。
この辺りで、だいぶタスクの渡し方やサポートに慣れてきて、プロジェクトがちゃんと回り始めました。
タスクの完遂が難しい人はその中の部品を作ることにまず集中してもらい、それらを繋ぎ合わせる作業は自分が後で巻き取ることにしました。
また、この辺りでチームの編成が落ち着き、エンジニアが2人別チームに行きました。この時に当初合意を取っていた4スプリントの期間が終わります。

所感

この判断及び動き自体は、悪くなかったと思います。が、もう少し早くこの状態に持っていきたかったなと思っています。自分の動きとしてはだいぶ安定して余裕ができましたが、その結果プロジェクトとしては当初の予定に間に合っていないことに気づきました。

シニアエンジニアが入ってきて設計にちゃぶ台返しを食らう話 & 動くものの完成

予定より遅れていることがチームの優先的な課題となり、もう一つのプロジェクトに入っていたシニアのエンジニアが一人、こちらのプロジェクトに入りました。そして、工数を削減するため設計のちゃぶ台返しをくらいました。結果的に、自分が一番最初に提案した、リッチにする前の簡易な設計に戻りました。そこから2スプリントくらいで、なんとか動くものを完成させました！

結果として、当初1ヶ月の予定だったものが動くまで2ヶ月、以下に続く改善も含めると足掛け3ヶ月ほど開発していたことになります。

所感

1.5ヶ月越しとはいえ、自分が最初に書いた設計図に同意が得られたのは嬉しかったです。と同時に、あの時は主張しなければいけない時だったと反省しました。 4月を目前に控えていて、自分が新卒研修にリソースを当てなければいけなくなる前に動くものができたのでなんとか一安心でした。

動くものを作ってからの改善

動くものができてからは、営業側の連携を待ちつつリファクタリングや改善を行っていました。テスト用の機密情報を平文でやりとりしていた部分を暗号化して送るよう改修したり、突貫工事で進めていた部分を整えたりしていました。

所感

ここは比較的余裕を持って行えました。ただ、フェーズが変わった時に改善タスクの優先度を見直す動きは必須だなと感じました。具体例としては、突貫で作ったため自動デプロイではなく手動デプロイでECSにあげていますが、運用・改善が続く(=デプロイの機会が度々ある)ならここを自動にするタスクは優先的に行われるべきです。とにかく機能開発するフェーズから運用を考えるフェーズに変わったことをきちんとチームで認識し、非機能要件も含めたタスクの優先度を並び替える必要があると強く感じました。

まとめ

今回のプロジェクト全体で得た、プロジェクトマネジメント的な観点からの学びを以下にまとめます。

常に全体感を把握・意識して、予定通りかどうかを判断できる余裕を持った人が必要
- 加えて、都度PdM及び営業側に期間的な期待値のズレがないかを補正する動きが大事
- 時間やスケジュール管理、およびリソース管理
そのプロジェクトが現在どのフェーズなのかを常に意識し、都度タスクの優先度を見直す
- 検証、作り込む、運用・改善
リソース効率が良いならば進みが良いとは限らない(=フロー効率を意識する)
- 自分含めて5人のエンジニアは1人でマネジメントするには多すぎました
- サポートできる人数は多くて2人