はじめに
Webアプリエンジニアの加瀬です。 OpenWorkにはメッセージ機能があり、企業や人材紹介会社の担当者とメッセージでやり取りをすることができます。 昨年所属していたプロジェクトにてこのメッセージ機能の改修を行いました。開発リーダー的ポジションを担った経験があまりない中、改修にあたりサブDL（DL = Development Leader）という形で開発を担当しました。 プロジェクト内外のメンバーと連携する場面が多々あり、開発を進める中で学ぶことが色々ありました。
サブDLという形で開発を進める中で学んだことについて、いくつか書いてみたいと思います。 開発リーダーのポジションに興味のある方にとって、少しでも参考になれば幸いです。
メッセージボックスの改修内容について
OpenWorkのメッセージボックスでは、企業から届くメッセージと人材紹介会社から届くメッセージの両方を受信できるのですが、改修前はどちらも企業単位のスレッドで表示されていました。 しかし、同じ人材紹介会社に在籍する複数の担当者からメッセージを受け取った場合、一つのスレッド上で複数のやり取りが表示されるため、どの担当者からのメッセージか分かりにくい状態でした。
やり取りを確認しやすくするため、人材紹介会社からのメッセージについては担当者単位のスレッドで表示できるようにしました。これによりどの担当者から受け取ったメッセージかを確認しやすくなりました。
サブDLとは
プロジェクトにもよりますが、エンジニアが所属する多くのプロジェクトにはDLという開発リーダーがいてプロジェクト全体の開発管理を行っています。 DLはプロジェクトで成果を出す上で効率的な開発を進めることに責任を持っており、状況や施策内容に応じて各メンバーをアサインして進捗状況の管理等を行います。
昨年私がいたプロジェクトにもDLがいたのですが、マネージャーとしての仕事もあり仕事量が多い状態でした。 開発工数が大きい施策を扱うことが多いプロジェクトだったので、正式な役職ではないですが、DLの負担を減らすことを目的としてサブDLという役割を設けることになりました。
サブDLの主な役割は以下のとおりでした：
- 担当する施策における設計・実装方針の決定を行う
- 担当する施策のタスク管理及びメンバーのアサイン・進捗状況確認を行う
- 担当する施策のリリーススケジュール管理・他プロジェクトとの連携などを行う
メッセージボックスの改修も開発工数が大きい施策だったため、サブDLとしてこの施策の開発を担当することになりました。
サブDLとして開発を進める中で学んだこと
開発を進める中で反省点やこうすべきだったなと感じることがありました。いくつか挙げてみたいと思います。
反省点
開発工数の見積りが甘かった
開発に着手する際に開発工数を見積ってリリーススケジュールを決めたのですが、想定よりも開発工数が多く途中でリリース予定日を変更しました。 必要な対応の洗い出しが足りなかった、および各作業にかかる工数の見積りが甘かったなと思います。 仕様をよく確認した上で、できるだけ細かい粒度で必要な作業を洗い出すことが求められると思いました。 普段から「この作業はどのくらい時間がかかるかな」と見積もる習慣をつけて経験を積み、見積もり精度を高めていきたいです。
実装内容を定期的に確認してもらうべきだった
ある程度実装が進んでから営業チームに確認してもらっていたのですが、営業チームが想定していた仕様と実装内容がズレている場面がありました。 作業途中でも良いので、「今このような形で実装を進めている」という共有をもっと密に行っても良かったかなと思います。 仕様が固まりきっていない箇所がある状態だったので、仕様変更に柔軟に対応できるスクラム開発を採用しても良かったかもしれません。
リリースできる箇所を先にリリースしても良かったかもしれない
バックエンドとフロントエンドの修正を一つのブランチにまとめてリリースしたのですが、最終的な修正ファイル数が400以上となっていました。 修正ファイルが多い分、リリース当日の動作確認項目が多くなるほか、実装ミスの発覚などによるリリース中止のリスクが高かったなと思います。 リリースの負担やリスクを減らすためにも、バックエンド側の処理などリリースできる箇所を先にリリースしても良かったかなと思います。
やっておいて良かったこともいくつか挙げてみたいと思います。
良かった点
開発と並行してテスト項目を整理し、他のメンバーに内容を確認してもらった
実装をすべて終わらせてからテストプランを作成し、テストを実施することが以前は多かったのですが、テストプラン作成時に確認すべきテスト項目をパッと思い出せないことがありました。 開発規模が大きい施策の場合そのリスクが高いので、実装と並行してテスト項目をメモするようにしていました。 これによりテストプランの作成をスムーズに行うことができました。 また、メモしていたテスト項目を他のメンバーに確認してもらいました。メンバーからの指摘のおかげで、確認すべき項目の漏れに気づくことができました。 テストしようと思っている内容をお互いに確認しあうというのは不具合発生のリスクを減らす上でも有効だと感じました。 同様の場面があればまた実施したいです。
開発を担当する領域を決めてそれぞれ専念する形にした
修正範囲が広かったため、機能および修正対象のページで作業範囲を分離して各メンバーに専念してもらう形にしました。 他のメンバーの作業が終わるまで着手できない、という状態がなるべく起きないよう意識して分担しました。 各機能に専念できるので作業しやすかったのと、お互いの作業待ちが発生する場面も少なくできたように個人的には思います。
進捗管理シートを作成してメンバーと共有した
必要な作業および担当者、期日などをまとめたシートを作成してメンバーと共有し、適宜更新してもらうようにしました。 どこまで作業が終わったのか・残作業は何かを一目で確認できるようにしたことで進捗確認をしやすかったです。
サブDLとして開発を担当し、意思決定とコミュニケーションの重要性を改めて実感しました。
どのような方針・スケジュールで実装を進めるか、設計をどうするかなど意思決定を求められる場面が多く、決定が遅いと作業が進まなかったり混乱が生じることもあります。 素早く正確な意思決定をするためには、施策の背景理解や仕様確認、ソースコードなどの調査を徹底することや、開発スキルや知識を高める必要があると思いました。
（個人的な意見ですが、どうすべきか迷った場合、後から軌道修正が可能であれば一旦決め切ってしまうことも時には必要だと思いました。）
また仕様や実装内容の認識を揃えたり相談事項を早期に解決するためにも、関係者とのコミュニケーションを細かく取ることは大切であると感じました。 悩んでいることを相談したり、メンバーの作業状況や相談事項を積極的にキャッチアップできるようにしたいと思いました。
おわりに
自分の作業だけでなくメンバーの作業状況を把握したり、関係者と連携する必要があったりとリーダーポジションは考えることが多いなと改めて感じました。 大変でしたが、その分施策を無事にリリースできたときの達成感は大きかったです。
サブDLという役割についてですが、開発リーダーとしての経験を積む上で良かったなと思いました。 部分的にリーダーの役割を担う経験を積めたのはとてもありがたかったです。 開発管理を指揮できるような人材になれるよう、少しずつ経験を重ねていきたいです。
オープンワークでは、エンジニアとして幅広く成長できる機会があります。ご興味があればぜひ求人を覗いてみてください！
