この記事を書く経緯
サービスのエンジニアなので、DBからサーバサイド、フロントまでいろいろなことをやらせてもらっています。配属されてから、苦労した要件定義からリリースまでの話をしたいと思います！
この記事を読んでわかること
- 新規機能やバグ修正の依頼がきた時にどんな流れでやっていけばいいのか分かる
- 新卒で開発タスクを振られた後の業務の進め方がわからないという人
この記事を読むのに向いてる人
- 要件定義からテストまで全部やらなきゃいけないですって人
- ディレクター、エンジニアの人
前提
私が業務で担当しているサービスは、バグ修正や新規機能、追加修正などが入った際にタスクが振られます。
自分で気づくこともあれば、ディレクターさんやデザイナーさん、営業さんからの依頼ベースもあります。営業さんや運営さんからの依頼やバグ指摘→ディレクター（介さないこともある）→システムみたいな流れになっています。
最初の失敗
タスクが振られた後、配属されたばかりの新卒の私は、まず実装と思ってとりあえずブランチ切って実装をしていました。
実装が終わったので、プルリクを出すと上司から、
- ここの場合はどうする？
- このステータスの場合は大丈夫だっけ？
- その値ここでも使っているから、この機能に影響ない？
などテスト漏れや、仕様確認漏れなどがあって、事前にわかっておけばというようなことがありました。
文言修正ぐらいならいいのですが、新規機能や追加修正といった1週間以上実装にかかりそうなものともなると、いきなり実装から初めてダメと学びました。そこで、
まずチケットが切られたらざっとした流れを書き出す
| 順番 | 項目 | 種類 |
|---|---|---|
| 1. | 要求定義（営業・ディレクター確認） | 調査 |
| 2. | 要件定義 | 調査 |
| 3. | 影響範囲の調査 | 調査 |
| 4. | 見積もり作成 | 仕様書作成 |
| 5. | 設計書周りを作成（必要であれば） | 仕様書作成 |
| 6. | デザイン依頼（必要であれば） | 依頼 |
| 7. | WF作成（必要であれば） | 仕様書作成 |
| 8. | 単体・結合テスト仕様書作成 | 仕様書作成 |
| 9. | もう一度要件定義 | 調査 |
| 10. | DB定義書更新（必要であれば） | 仕様書作成 |
| 11. | 実装 | 実装 |
| 12. | 単体テスト・結合テスト | テスト |
| 13. | レビュー | レビュー |
| 14. | 仮環境での受入テスト | テスト |
| 15. | 本番反映 | リリース |
| 16. | 本番後検証 | テスト |
ざっとこれだけでも本番反映するまでにやらなきゃいけないことがあります。
注意
・実装が1週間以上かかるものを目安としていたり、これを全てをやらなくて良いタスクもあります。
・また、開発体制にもよるのですが、全てエンジニアがやるのではなく、ディレクターが仕様書まで作成するというチームもあります。
・順番が前後する場合もあります。
要求定義（営業・Di確認）
たまにこうしてください〜やここどうなってますか〜みたいな依頼がきます。
その場合、わからないことがあったりするときは必ず営業さんやDiさんに確認をします。
たまになぜその依頼をしたのかの理由や背景を詳しく聞いてみると、仕様上できないものや他に方法があるというような場合もあります。
小さいタスクであれば、チケット作成時にテンプレートを使用というのもいい案だなと思います。
■要望・追加修正のテンプレート
* 概要
* 課題
* 目的と効果
* タスク
■バグテンプレート
* 発生内容
* 期待される結果
* 発生画面URL
* 再現手順
* 原因
* 修正案
* その他
要件定義
要求が出揃ったところで、次に要件定義です。
- システムのどこを直さなければいけないのか、追加実装しなければならないのか
- DB修正などいるか
- APIの修正や追加などはあるのか
- 画面設計やバッチ設計などはどうするのか
といったシステム側の実装について決めていきます。
影響範囲の調査
一度既存システムにある機能修正をしたら、影響範囲もれで他の部分で正常に動くものを邪魔するということが起き、本番反映後に修正するということが起きました。
なので、要件定義の後に
- その要件とは関係のないところで処理や値が使われていないか
- ステータスや条件が間違っていないか
- その機能はどんな人が使えるのか
といった今回の修正や実装に基づく影響範囲の部分を調べることも大切です。
見積もり作成
そのタスクいつまでに終わる？だったり、
リリースいつ頃できそう？だったり、
先にリリース日が決まっているものもあります。（キャンペーンなど）
なので見積もり作成もきちんとします。
調査・設計〜実装〜テスト、本番反映までの見積もりを出します。
（こちらもテンプレートがあるので便利だと思います。）
設計書周りを作成・修正（必要であれば）
画面設計書やAPI仕様書、バッチ設計書など、設計書といっても一つではありません。
要件定義に基づき、設計書を作っていきます。
WF作成（必要であれば）
レイアウトが変わるような機能や修正の場合は、WF（ワイヤーフレーム）も作ります。
Bootstrapを使っているような画面であれば、工数削減にもなるのでデザイナーさんにはお願いせず、エンジニアやディレクター自身でワイヤーを作ってしまってもいいと思います。
どこにボタンがあったらわかりやすいか、必要な文言は何か、モーダルにするかなど、図に起こすことで把握しなければいけないことがわかります。
また実際使うのはエンジニア自身ではないので、営業さんなどに使いやすさなども聞いたりします。
デザイン依頼
もしデザイナーさんにデザインしてもらう必要がある場合は、デザイナーさんに依頼します。
単体・結合テスト仕様書作成
そして、単体・結合テスト仕様書を作成します。
テストに漏れがあって本番反映後にバグが出たりすると、リリース後にリリース前の状態に戻さなければいけなかったりしたり、修正が起きたりするので、ありとあらゆるパターンや、影響する部分もテストするように仕様書を作成します。
もう一度要件定義確認
なぜここでもう一度要件定義を確認するかというと、単体・結合テスト仕様書を作成することによって、ユーザーが実際に使う流れが見えたりします。
たまにですが、ここで要件定義漏れが起きていることがわかったりします。なので、確認することをオススメします。
DB定義書修正
DB定義書やドキュメントで変える必要のあるものは変えて起きましょう。
これを忘れると、末長いサービスだと、新しくチームに入った人やサービスについて何も知らないエンジニアが混乱したりします。
実装
ここでようやく実装です。設計書や仕様書に基づいて実装します。
単体・結合テスト
単体テスト・結合テスト仕様書に基づいてテストしていきましょう。
テスト通りに動かない場合は、実装の修正・見直しをします。
レビュー
実装が終わったら先輩エンジニアにプルリクを出します。レビューが返ってきたら、指摘点を確認して修正します。
仮環境での受入テスト
レビュー後、自分の修正や実装が反映されたら、すぐに本番に反映されるのではなく、どこのサービスも仮環境みたいなものがあると思います。なのでそこで受入テストをします。
気をつけたいのが、
本番と同じデータが入っているので、大量のデータを相手にしている処理などがうまくいくか、
他の機能や画面表示に不具合がないかなども見ます。
本番反映
そして本番反映です！ようやく！やったね！
まとめ
こう見ると新規機能追加とナルト、実装って一部分だったりもして、
ですが、要件定義や影響範囲の調査、設計書など、前段階のものをしっかりやっておかないと、
後から確認事項が増えて、実装に時間がかかるということになってしまいかねません。
実装だけじゃなく、こういうことも気にすることができるといいなと思います。