KaQiita

新米 Web エンジニアが適当なことを書いてます。温かく見守ってやってください。

ソフトウェアの機能にも YAGNI 原則を適用する〜『プリンシプルオブプログラミング 2.3. YAGNI』を読んで〜

はじめに

「プリンシプルオブプログラミング」の「2.3 YAGNI」を読みました。


YAGNI とは「You Aren't Going to Need It.」の略で、「多分必要になるだろう」で現状は不要なコードを書いてはいけないという原則です。

コーディング原則として語られることが多いですが、ソフトウェアの機能についても同じことが言え、つい先日実務でこの YAGNI 原則に則って上手く対応できたなと思えたことがあったので忘れないために書いておこうと思います。

社内管理システムの機能追加依頼

社内で使っている管理システムに対して、業務効率化のために機能追加の要望を受けました。

要望の内容となぜやるのかについてなんとなく想像はできたのですが、念のため要望を挙げてくれた方に以下のことについてヒアリングを行うことにしました。

  • そもそも今実務を行っていてどんな問題・課題があるのか
  • この機能を追加することでそれはどんな・どれくらいの事業価値に繋がるのか

そして私の中で要望について理解でき、二種類の解決策を思いついたので A パターンの要件と B パターンの要件をメリデメと共に提示してどちらかを選んでもらうという形で機能について擦り合わせを行いました。

その擦り合わせが終わりかけた頃、「この要件とほとんど同じようなものを別のこちらの管理ページにも付けてもらうことはできるか」という提案を追加でもらいました。

ここが YAGNI 原則を適用して考えた点です。最初の要望を聞いた段階で「別のページにも同じように変更した方が良いかな」とちらっと思ったのですが、先程の A パターンにも B パターンにもそのページも同じ変更をするという要件は盛り込みませんでした。なので追加でもらった提案は一旦はお断りしています。

「多分必要になる機能」なのですが、「この機能を追加することで造られる事業価値」がまだ仮説の域を出ないため本当に機能追加が価値に繋がるのかが分かりません。なのでまずは今回元々解決しようと思っていた問題を解決して、この機能が本当に有用だと分かってから別ページにも同じような変更を行うか考えましょうと着地させました。

本当に必要になるか分からない機能を作るためにエンジニアリソースを食い潰すということを避けられて、個人的に悪くない意思決定だったと思いました。ちゃんと継続して行えるようにしていきたいと思います。

終わりに

YAGNI 原則について振り返ったことを書きました。

自身の頭の整理のために書いているものですが、誰かの参考になれば幸いです。