こんにちは、開発チームでエンジニアをしている和田です。
普段の業務では、Node.js で作られているアプリケーションの仕様を考えたり、機能開発をしたりしています。
入社してから新しく開発した機能のほとんどの仕様作成に携わってきました。
今日はそんな筆者が、
「初めて機能開発に携わることになったけど、仕様ってどうやって考えればいいの...？」
と悩めるエンジニアの方のために、この1年ほどで学んできた仕様を考えるうえで大事な観点について記事にしてみようと思います。
※ あくまで個人の意見であり、筆者が所属するチームで大切にしている考え方であることにご留意ください。
仕様は DB から考えよ
「和田さん... DB が全てなんですよ。」
筆者が現在の開発チームにアサインしたばかりの頃に、シニアエンジニア T さんから最初に言われたセリフです。
Tさん曰く、DBが決まれば仕様はほぼ決まるとのこと。
当時の私からしたらなんのことだかさっぱりでした...😅
どういう意味なのでしょうか？
DB は後から変更しにくい
DB とはすなわち、アプリケーションを使用するユーザーごとに保存された個々の情報でありユーザーの財産とも言えるものです。
ユーザーの大切な情報であるため、機能がリリースされてから DB に情報が保存されると後から簡単に変更することができないという特性があります。
つまり最初のテーブル設計を間違ったまま機能をリリースすれば、変更に時間のかかる負債となる機能を生み出しかねないわけですね。
だからこそ、最初に仕様を考えるうえで DB 設計を大切にしなければならないのです。
バックエンドやフロントエンドのコードは後から変えられる
一方でバックエンドやフロントエンドのコードはどうでしょうか？
これらは利用者が変更できるものではなく、開発者がコントロールする領域です。
万が一、バックエンドやフロントエンドに誤ったコードが含まれていたとしても DB 設計さえ問題なければ、後から修正ができます。
DB 設計ってどうやればいいの？
では DB 設計はどのように行えばいいのでしょうか？
結論としては、一概にこのやり方が正解だという答えは存在しない です😇
残念ながら DB 設計ばかりは、アプリケーションの仕様に依存するためやり方を一つに定めることはできません。
筆者も社内のエンジニアにこの疑問を聞いて回りましたが、
「DB 設計は奥が深い。一度作ってもしばらく経つと、仕様の変更によって扱いづらいDBになっていることもよくある。」
とのことでした。やはり、決定的な答えは存在しないようですね。
とにもかくにも、仕様を考える上で熟考しないといけないのが DB であることは間違いないようです。
しかし、DB 設計よりも遥かに大事な観点があります...
現行の仕様で実現できないかを考えよ
仕様を考える上で、DB 設計を行うこと以上に大切なことはズバリ 現行の仕様で課題解決ができないかを考える ということです。
本当に必要な機能開発か見極めよう
現行の仕様で課題解決を行うことが推奨される理由は、時間をかけなくて良いからです。
先程、DB 設計をうまく行えていればコードは後から修正可能だと述べました。しかしながら、これらの修正にも時間がかかります。
修正に時間をかけている間、競合のアプリケーションが魅力的な新機能をリリースしたり、開発しているアプリケーションに優先度の高い別の需要が発生することも有りうるのです。
修正が必要なコードを生み出すよりも、ユーザーに真に求められている機能の調査やその開発をしたほうが良いということですね。
本当に必要な機能を見極め慎重に開発するのも我々エンジニアの仕事というわけです。
最後に
最後まで読んでくださりありがとうございました🙇♂️
今回は筆者が仕様を考えるにあたり、大切にしていることを記事にさせていただきました。
初めて機能開発に携わるエンジニアの方の参考になればと思います🙏
