はじめに
プロダクトで、こんな要件の新機能を実装することになった。
- 超大規模な既存機能（A機能）と中身は同じ
- UI（表示テキスト）だけが異なる（B機能）
「既存機能のディレクトリをコピーして機械的にリネームすればいいのでは？」と考えて取り掛かったが、話はそう単純ではなかった。本記事では、単純なUI変更の要件が権限設計の見直しにまで発展した経緯と、そこから得た学びを共有する。
前提：機能名＝権限名という命名規則
このプロダクトには複数のユーザー権限があり、機能名と権限名が1対1で紐づく命名規則になっている。A機能を扱える権限は「A権限」、という具合だ。
当初の設計：B権限を追加する
この命名規則に倣い、「A権限の他に、B機能用のB権限を追加すればいい」と考えて設計・実装を進めた。しかし、中身が同じ機能に権限を2つ用意したことで、こんな問題が起きた。
- 内部的に同じことができる権限をいちいち切り替えるのが面倒
- 同じことができる権限が2つあり、UX的にわかりづらい
対応：権限を統合する
結局、権限は1つに統合して「A&B権限」に改名した。これで権限の切り替えは不要になり、A機能・B機能はUI（表示テキスト）上で別々に見せたまま保つことができた。
つまり「見た目を分けたい」という要望に対して「権限を分ける」という手段はそもそも噛み合っておらず、権限は分けず、名称を変えて機能単位で分離するだけでよかったのだ。
学び
プロダクトにおいて、既存構造を崩さずに新機能を実装していく設計は安全かつ、保守性の観点で重要な判断となる。
しかし、それよりもユーザーがUX的に使いやすいのか、わかりやすい構造になっているのかが最も重要であり、それを最優先事項として要件定義することが最も大切だと気づいた。