ID:72177さん

私はSasS新規開発事業のプロジェクトを一部をマネジメントしていました。 プロダクトオーナー1名とエンジニア5名のチームで、エンジニア5名は全員がリーダーという形で仕事の依頼は双方向に行っておりました。

プロジェクトのリリース期限に合わせて機能を完成させる責務がありました。 モバイルアプリの開発は他の企業に依頼していたため、担当者と開発スケジュールを調整し、仕様の検討を行っていました。 また、一部機能は開発規模が大きかったので、タスクに落とし込んだ上で他のメンバーに協力を依頼しました。

## 考えたこと 新規開発事業で売上を立てることが目標だったので、MVPを意識して売上につながるタスクを最優先で行っていく必要がありました。 その一方でインフラ面におけるDBのパフォーマンスなど重要な部分に関してはプロダクトオーナーに相談して優先的に対応するように心がけました。 ## 問題や障害 ### 外部企業とのやり取りは待ちの時間が多い 外部企業とのやり取りはクリティカルパスになることが多いので、返信を最優先にするように心がけました。その結果、開発スケジュールに影響を及ぼすことを防ぐことができました。 ### タスク依頼した時に認識齟齬が生じ、間違った方向に進んでしまう タスクを依頼する側であれば、伝え方に問題があったのだと考えました。 そのため、タスクを依頼する時はなぜこのタスクをやるのか目的を伝えるように意識することで、方向性のブレが生じることを防いだり、より良い代案をもらうことがありました。 ### リリース直前にチームのコミット量を増やす必要があった リリースが迫っている中、バグが多く発見されました。（普段はあまりやりたくありませんが）土日にプルリクエストを複数送ったり、チケット作成によるslack通知を飛ばしてメンバーのモチベーション向上に務めました。結果としてチームの振り返りでは土日の作業したことが評価され刺激になったと言っていただけました。

大規模プロジェクトの小チームのチームメンバー数人をマネジメントしていました。 リーダーは別にいましたが、リーダーが多忙で打ち合わせで不在のことが多かったため、一部業務についてBPのメンバーに作業内容を共有して依頼していました。

BPの方に作業を依頼して、できた成果物をレビューする責務がありました。

## 考えたこと チームの状況としては仕事量のバランスが偏っており、リーダーにばかり負荷がかかっていました。 そのため、リーダーの仕事量を減らし、なるべくリーダーはリーダーにしかできないことをしていただくのが大切だと考えました。 入社1年目だったため、自分でできることとできないことに切り分けて、ベテランのBPの方の力を借りつつ進めることにしました。 ## 問題や障害 ### タスクを依頼するための準備ができていない 事前に作業を依頼するための資料作りやサンプルを作成し、それをBPの方に共有し、作業の依頼をしました。 ### 業務知識や技術力が足りていない 朝の通勤時間や土日を利用して本を読んで勉強しました。 また、BPの方には知識が豊富な方が多くいたので都度教えていただきながら進めました。