はじめに
最近、要件定義を書くことが増えてきて、「要件定義って意外と楽しいかもしれない」と思うようになりました。
入社当初は要件定義をほとんど意識せずに開発していましたが、とある開発をきっかけに考え方が変わりました。
今回はその話を書いてみます。
入社当初は「言われたものを作るだけ」だった
入社したばかりの頃は、要件定義を全くしていませんでした。
要望が来たら、その内容をそのまま実装する。
「なぜその要望が来たのか」「どんな課題を解決したいのか」といった背景は、正直ほとんど意識していなかったと思います。
今振り返ると、「要望が来たから作っただけ」の機能が多かったな、と感じます。
もちろん当時の自分なりに必死でしたが、背景まで理解していれば、もっと良い形で実装できた機能もあったのではないかと思い、少しもったいなさを感じています。
半年後、要件定義書を書くことになったが乗り気ではなかった
入社して半年ほど経った頃、課長から「要件定義書を書いてみよう」と言われたのが、要件定義に関わる最初のきっかけでした。
それまで要件定義書を書いたことがなかったため、「そもそも要件定義書って何を書くの？」という状態からのスタートでした。
当時は開発にも少しずつ慣れてきていて、「実装内容は頭の中でイメージできているつもり」でもありました。
そのため正直なところ、「要件定義書を書くのは面倒くさい」「そのまま実装した方が早いのでは？」と思っていました。
書き始めた頃は、「書いた方がいいんだろうけど、別に書いたところで…」という気持ちがかなり強かったです。
API連携開発が転機になった
そんな中、外部業者の機能とAPI連携を行う開発を任されることになりました。
API連携の経験はなく、実装もかなり複雑になりそうな内容でした。
このとき先輩から、「今回はちゃんと要件定義書を作った方がいいよ」と言われ、要件定義書の作成に本腰を入れることになりました。
API連携自体がよく分かっていなかったこともあり、「どうやったらうまく実装できるか」を一つひとつ考えながら書く必要がありました。
結果として、要件定義書の作成には1週間ほどかかりました。
何度も先輩にチェックしてもらい、フィードバックをもらっては修正する、ということを繰り返しました。
正直、「本当にOKがもらえるのだろうか」と不安になることもありました。
実装を進めて気づいた要件定義書の価値
最終的に要件定義書にOKをもらい、開発を進めることができました。
その開発中、私は何度も要件定義書を見返していました。
たとえば、
・機能のフローがどうなっているのか
・どのテーブルのどのカラムが紐づくのか
といった点を確認しながら実装を進めていました。
このとき初めて、「要件定義書を作っておいて本当によかった」と感じました。
実際に感じたメリット
要件定義書を作って感じたメリットはいくつかあります。
1つ目は、頭のリソースを使いすぎなくて済むことです。
すべてを頭の中で覚えておく必要がなく、迷ったときに要件定義書を見返せるため、実装そのものに集中できました。
2つ目は、先輩と実装イメージを事前に共有できることです。
実装前にフィードバックをもらえることで、開発後に手戻りが少なくなりました。
そして何より、自分の開発でどんな機能ができるのかを想像するのが楽しかったという点が印象に残っています。
要件定義書を書いていく中で、機能が少しずつ形になっていく感覚があり、その過程自体を楽しめている自分に気づきました。
それ以降も要件定義書を書くようになった
API連携の開発が終わったあとも、要件定義書を書くようになりました。
やはり便利ですし、特に「先輩と認識を合わせた状態で開発を進められる」という点は大きなメリットだと感じています。
まだ数は多くありませんが、最近は要件定義書に対するフィードバックの回数も少しずつ減ってきた気がします。
最近感じていること
一方で、要件定義書を書く中で新たに気づいたこともあります。
それは、要件定義書を書く段階でどれだけ具体的に実装イメージを持てているかが重要だということです。
以前、要件定義書の段階で想定しきれていなかった点が開発途中で発生し、その結果スケジュールにズレが生じたことがありました。
スケジュール通りに開発を進めるためにも、要件定義書を書く段階でしっかりとイメージを固めることが大切だと感じました。
ただし、そのためには既存の機能理解も欠かせないと感じています。
要件定義書は大事で楽しい反面、ある程度の前提知識がないと書くのが難しい部分もあります。
それでも、考えれば考えるほど深くなっていくところが、要件定義の楽しさだなと感じています。
私が要件定義書を書くときの流れ
参考までに、私が普段要件定義書を書くときの流れを簡単にまとめます。
まず、要望をしっかり理解し、どんな機能を作るのかを明確にします。
次に、その機能があることで何が便利になるのかをイメージします。
そのうえで、「どこに」「どのように」実装するのかを具体化していきます。
ボタン一つを追加する場合でも、そのボタンで何ができるのかを説明できるレベルまで落とし込むようにしています。
テーブル設計が必要な場合は、既存のテーブルを理解したうえで、最低限必要なカラムだけを追加するように考えます。
一通り書き終えたあとは、AIで観点漏れがないかを確認し、先輩からフィードバックをもらい、修正して完成させています。
おわりに
私はまだまだ要件定義書を書くのは練習中です。
それでも、要件定義書を書くことで開発の質が少しずつ上がっている実感があります。
これからも要件定義書を書きながら、より質の高い開発ができるエンジニアになっていきたいと思います。