新規プロダクトの 2 人目エンジニアが参画当初にやってよかったこと

はじめに

私は現在、保育施設と保護者をつなぐプラットフォーム「えんさがそっ♪」の開発エンジニアとして働いています。

このプロジェクトに自分が参画してからそろそろ 2 年が経とうとしています。今回はその振り返りも兼ねて、新規プロダクトの 2 人目エンジニアとして参画した当初、私がどのようなことを意識し、どのような取り組みを行ったのかをお話ししたいと思います。

データメンテナンスなどの運用作業を積極的に引き受ける

オンボーディングが終わって最初に行ったことは、運用タスクを積極的に引き受けることでした。リリース初期段階の「えんさがそっ♪」には、よくある管理者用の画面がありませんでした。そのため、データメンテナンスが必要になるたびに SQL を直接叩いて対応していました。ビジネスサイドからのデータ追加や更新の依頼が頻繁にあり、その都度開発作業を中断する必要がありました。

参画直後の私と 1 人目のエンジニアでは、どうしても機能開発のスピードに差が出ます。そこで、まずは運用タスクを引き受けることで、キャッチアップを図りつつ、チーム全体の効率を高めることにしました。

メモ書きレベルでも Wiki にする

参画時、開発環境の構築やリリース手順などの情報はすでに Wiki に記載されていました。しかし、記載が不十分な部分や新しい情報もあり、理解するために 1 人目エンジニアに説明をお願いすることが多々ありました。最初は手元のメモに残していましたが、なるべくその場で Wiki に追記するように変更しました。

これは、自分の理解が正しいかどうかをレビューしてもらえるという利点がありました。また、次に参画するエンジニアに対して、100%ではないものの、ある程度の情報を共有できるというメリットもありました。Wiki に書くハードルが下がることで、情報共有がスムーズに行えた点が良かったと思います。

チーム内で発言しやすい空気を作る

朝会や夕会、振り返りの時間が余ったときに雑談する場を設けるように心がけました。前職の話やエンジニアのキャリアについての話から、音楽やアニメの話まで、幅広く何でも話しました。

雑談の際には自己開示を心がけました。自己開示をすることで相手も話しやすくなるという効果があるというのを実践してみました。

また、話し合いの場では、自分の中で 50 点くらいの意見だなと思っても、とりあえず言うようにしていました。これは、何も意見が出ないよりも 50 点くらいの意見でも出して反応をもらった方が話が進みやすく、発言自体のハードルを下げる効果があったと思います。

会議でのファシリテーションを積極的におこなう

チームの朝会、夕会、振り返りの進行を積極的に行うようにしました。最初は「誰もやりたがらないなら自分がやるか」という軽い気持ちでしたが、時間の配分や議論の進行をコントロールできる点が良かったと感じています。雑談や質問、意見交換の流れを作りやすくなりました。

おわりに

振り返ってみると、チームとして見たときに自分は何をすべきか、自分には何ができるのかということを常に考えながら行動していたように思います。何をすべきかはチームによって異なりますが、大切なのはその時々にチームが直面している課題に真剣に向き合うことです。

また、私が様々なトライを実行できたのは、前向きで協力的なチームメンバーのおかげです。このチームメンバーだったからこそ、私も自分の役割を果たし、チームに貢献できたと感じています。

---

こちらもどうぞ!

https://zenn.dev/babyjob/articles/role-in-development-team