はじめに
入社して 2 ヶ月目の 5 月末頃に，プロダクトの追加機能についての案件オーナーとして開発タスクをやらせてもらいました．このプロダクトには，集計したデータを PDF 形式のレポートとして出力する機能があり，このレポートの内容を英語で出力する要望に応えるための案件でした．要件定義がそもそも何かをわかっていない状態から，リリースまでやり遂げた際に学んだこと・振り返りなどを記録します．
要求・要件定義編
ユーザーストーリーについて考える
当たり前ではありますが，プロダクトは誰かに使ってもらうために作っています．そのため，どのような人に向けて作るのか，どのような課題を解決するために作るのかを要求定義の形でまとめます．
PdM（プロダクトマネージャー）が本来この部分を担当するのですが，せっかくの機会というのもあり，書かせてもらいました．ここでの学びは，ユーザーの立場から考えることが大切であることでした．でなければ，必要とされない開発に貴重な時間を費やしてしまうからです．
要求定義をする際にはいくつかのフレームワークがあり，ジョブストーリー，バリュープロポジションキャンバス，ギャップ分析から定義しました．
機能開発をする上で各所と合意を取る必要がある
要求定義が決まると，次にそれをシステムでどうやって実現するのかを要件定義の形でまとめます．この段階では，主に決めることが二つあり，仕様の決定と工数の見積もりがあります．
仕様を決定するためには，開発部署以外の人を含めたステークホルダーを集めて会議を設けたり，テキストでやり取りをする必要がありました．最終的な目的としては，各所から合意を取ることで，見当違いな機能ができあがらないようにするためです．ここでは，話した内容や合意した内容についてエビデンスとして残しておくことが大事でした．こうすることで，後の認識齟齬を防ぐことができます．
会議の際は，テンプレートで用意されている議事録に，基本的な日時や参加者などの情報と，議題を事前に準備しておきました．会議内で議事録を更新していき，会議後に手直しをして参加者に共有するフローで進めました．
工数の見積もりをするためには，決まった仕様からタスクの大きさに分解し，それぞれにかかる人日を想像しました．当時，どのような開発やテストが発生し，どのぐらいの時間がかかるのかは正直わからなかったので，メンターと確認しながら進めました．この部分ではスケジュールなどに左右されず，純粋にかかる時間を図ることが重要でした．工数が多くかかる場合は，人的資源を投じることや，開発スコープを狭めるなどの対策を正確に講じることにつながります．
上記の仕様と工数を再度 PdM に最終的なアウトプットや要する時間を確認してもらいました．今回の案件では，自分一人で開発してもスケジュール的に問題ないと判断されましたが，リリース日が事前に決まっているため絶対に遅れないように，と言われていました．結果的に遅延はありませんでしたが，この時細かく状況を報告するように心がけるようにしました．
開発編
実装のしやすさは要件定義で決められているほどにやりやすい
いざ実装してみて一番感じたのは，仕様がしっかり決まっているところの開発はスムーズに進んだ点です．実装方針も自ずと決まるため，迷わず正しいものを作っているのがわかりました．逆に，実装するとなって発覚する仕様漏れなどは，都度仕様を改めて決める必要があったため，開発着手までにその分の時間が追加でかかりました．
今回の案件では，レポートの内容を英訳するにあたり表示する文字数が増え，デザインを変更する必要がありました．一枚のページに収めるために削っても良い箇所や内容の省略表示について，実装を進めたタイミングで改めて仕様を見直しました．
開発では feature flag を利用して進めました．各 PR を細かく main ブランチにマージできたのが利点でした．他の進め方として，統合ブランチを作成する方法もあったかと思います．
QA の観点は鋭い
6 月末ごろに開発が一通り終わり，開発したものの QA を依頼しました．開発者テストもしっかり行っていたつもりでしたが，様々な観点から事前に不具合が見つかりました．一つ具体的には，文章の省略表示を文字数で判断していた実装でしたが，レポート上に表れる英字は種類によって文字幅が異なるため，別の方法の実装に置き換える必要がありました．実装ロジックが間違ってはいなかったものの，QA 観点から様々なデータでテストしてもらえるのは，とても心強いと感じました．
リリース編
プロダクトの変更は十分に周知するべき
プロダクトに変更を加える際には，ヘルプページの作成・変更依頼と，顧客と直接やり取りをする CS（カスタマーサポート）チームに周知します．今回の案件で一番の反省点となったのは，ここの周知が十分にできていなかったため，CS から顧客への周知より先に本番リリースしてしまい，多くのお問い合わせを発生させてしまいました．エンジニアとしては，リリース日と変更内容を十分に各所に周知することが大事だと身をもって知りました．
想定外のニーズに対する追加実装をした話
新機能を 7 月上旬にリリースしてから数日して，デザイン変更で削られた内容が想定以上に見られていたことが判明しました．仕様作成段階では，問題ないと判断していたことが，実際のニーズと異なってしまい，要求を定める難しさが垣間見えました．このため，緊急的にこの要求に応えるような追加実装も自分が担当し，再度リリースをすることになりました．
リリース後しばらくしてから，feature flag を利用していたため，技術的負債を残さないために，このフラグを削除する対応も行いました．
まとめ
約 2 ヶ月に渡り，開発過程を試行錯誤しながら，一気通貫して携わることができた貴重な体験でした．今後はこの経験を活かし，自分のスタイルで開発の仕事を進められたら良いと考えています．あくまでも一例ではありますが，始めて開発のフローに携わる方がイメージを持つ助けになれば幸いです．