はじめに

ある案件で、こんなコードに出会いました。

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]

この形を見たときに、

これは本当に配列で持つべきか？

と一度考えるだけで、
設計の方向は大きく変わります。