はじめに
ある案件で、こんなコードに出会いました。
data[user][date][product]
一見、シンプルに見えます。
しかしこの構造、
あとから確実に効いてきます。
■ はじまりはシンプルだった
最初はこうでした。
data[user][date]
ユーザーごとの日別データ。
よくある設計です。
しかし要件が追加されます。
- 商品ごとに管理したい
そしてこうなります。
data[user][date][product]
この時点では、まだ違和感はありません。
■ 図解：崩壊のプロセス
■ 実際のコード（Python / Java）
Python
for u in range(U):
for d in range(D):
for p in range(P):
process(data[u][d][p])
Java
for (int u = 0; u < U; u++) {
for (int d = 0; d < D; d++) {
for (int p = 0; p < P; p++) {
process(data[u][d][p]);
}
}
}
■ 現場で何がつらくなるのか
① 変数の意味が消える
data[x][y][z]
- xはユーザー？
- yは日付？
- zは商品？
👉 コードから意味が読み取れない
レビューのたびに説明が必要になります。
② 修正が怖くなる
- どこに影響するか分からない
- 横断的な変更がしづらい
👉 触ると壊れるコードになる
③ 要件変更に弱い
例えば、
「商品に属性を持たせたい」
👉 配列では表現しづらい
👉 無理に拡張すると破綻する
■ 本質的な問題
これは「配列が悪い」のではありません。
データに“意味”を持たせていない
これが問題です。
■ リファクタリング：意味で扱う
Python
class Record:
def __init__(self, user, date, product):
self.user = user
self.date = date
self.product = product
records = []
Java
class Record {
String user;
String date;
String product;
}
List<Record> records = new ArrayList<>();
■ 図解：設計の変化
■ 学び
3次元配列が問題なのではなく、
「次元で設計してしまうこと」が問題
でした。
■ 3次元配列が適しているケース
ここは否定しすぎないことが重要です。
- 画像データ（縦 × 横 × RGB）
- 数値計算
- シミュレーション
次元そのものに意味がある場合は自然な設計
■ まとめ
- 3次元配列は便利だが、業務では扱いが難しくなりやすい
- 次元が増えたら設計を見直すサイン
- インデックスではなく「意味」で設計する
最後に
data[x][y][z]
この形を見たときに、
これは本当に配列で持つべきか？
と一度考えるだけで、
設計の方向は大きく変わります。