はじめに
個人開発しているコレクション管理アプリ「SLX（StockLedgerX）」では、当初はシンプルな2階層構造で設計していました。
コレクション
└ アイテム
できるだけシンプルな構造の方が使いやすいだろうと考えていたためです。
しかし実際に機能追加や画面設計を進めていくと、少しずつ違和感が出てきました。
結果として現在は、
コレクション
└ ジャンル
└ タイトル
└ アイテム
という4階層構造へ変更しています。
今回は、その設計変更で感じたことをまとめてみます。
当初の構造
最初は、
コレクション
└ アイテム
だけでした。
例えばゲームであれば、
ゲーム
├ FF7 Rebirth
├ モンスターハンターワイルズ
├ ゼルダの伝説
という形です。
構造としては非常にシンプルで、実装コストも低く済みます。
実際、最初の段階ではこれで十分だと思っていました。
起きた違和感
開発を続ける中で、管理対象が増えてくると少しずつ違和感が出てきました。
例えばゲームの場合、
ゲーム
├ PS5
├ PS4
├ Switch
├ Steam
というプラットフォームの違いがあります。
さらに本や漫画の場合は、
本
└ 漫画
└ ワンピース
├ 1巻
├ 2巻
├ 3巻
という管理をしたくなります。
しかし2階層構造では、
本
├ ワンピース1巻
├ ワンピース2巻
├ ワンピース3巻
├ 呪術廻戦1巻
├ 呪術廻戦2巻
のようになりがちです。
管理できないわけではありません。
ただ、人間が頭の中で整理している構造と少しズレているように感じました。
3階層でも足りなかった
次に考えたのは3階層構造です。
コレクション
└ ジャンル
└ アイテム
これであれば、
ゲーム
└ PS5
├ FF7 Rebirth
├ モンスターハンターワイルズ
のような整理ができます。
一見すると十分そうに見えます。
しかし漫画や小説、映画シリーズなどを考えると、
漫画
└ ワンピース
└ 1巻
という中間概念が必要でした。
シリーズと個別アイテムを同じ階層で扱うと、どうしても整理しづらくなります。
最終的に4階層構造になった
そこで最終的に採用したのが、
Collection
└ Genre
└ Title
└ Item
という構造です。
例えば漫画であれば、
本
└ 漫画
└ ワンピース
├ 1巻
├ 2巻
├ 3巻
ゲームであれば、
ゲーム
└ PS5
└ RPG
└ FF7 Rebirth
のように整理できます。
利用者が頭の中で認識している構造に近づいたことで、データの見通しも良くなりました。
設計変更して感じたこと
4階層にしたことで、単純に画面数は増えました。
データベース構造も複雑になりました。
実装コストだけを見ると、明らかに重くなっています。
ただ、その代わりに得られたものも大きかったです。
-
パンくずリストが自然に実装できる
-
アイテム移動機能が作りやすい
-
バックアップ構造が整理しやすい
-
将来の機能追加に対応しやすい
-
コレクション数が増えても管理しやすい
実装中は遠回りに見えましたが、結果的には後続機能の実装を楽にする土台になりました。
当時の思考の変化
振り返ると、最初の自分は
「画面数は少ない方が良い」
という考えを強く持っていました。
そのため、できるだけ階層を増やさずに解決しようとしていました。
しかし実際には、
「画面数を減らすこと」
よりも、
「利用者が自然に整理できること」
の方が重要でした。
構造を無理に単純化すると、後から機能追加を行うたびに違和感が発生します。
結果として、設計の見直しが必要になりました。
おわりに
今なら、まず実装コストを見るのではなく、
「利用者は頭の中でどう整理しているのか」
を先に考えると思います。
シンプルな構造は魅力的ですが、将来の拡張や利用者の認知構造とズレてしまうこともあります。
今回の4階層化を通して、
「画面数を減らすこと」よりも、
「自然に整理できる構造を作ること」の方が大切だと学びました。
同じようにコレクション管理アプリや在庫管理アプリを開発している方の参考になれば幸いです。