Excel管理表が崩壊する本当の理由とは？「現在状況の上書き」をやめて「出来事の記録」に変える設計思想
「合理的な一手ずつが積み重なって崩壊する」という構造を、ストーリー形式で見事に可視化した良記事。エンジニアだけでなく、Excelで業務管理しているすべての人に読ませたい一本です。
「前任者が作ったやつで、自分もよくわからなくて……」—— この引継ぎ会話、あなたも一度は経験したことがあるのではないだろうか。 Zennに投稿されたTOKIUMプロダクトチームの記事が、なぜExcelの管理表は必ず崩壊するのか<strong>をストーリー形式で鮮やかに解説しており、思わず「あるある」と唸った。Excelの使い方の問題ではなく、</strong>データ設計思想の問題だという指摘は、エンジニアでなくともすべての管理業務担当者に刺さる話だ。 崩壊のストーリー：合理的な一手ずつが積み重なって地獄になる 記事では、シンプルな従業員名簿がどう崩壊していくかをストーリーで追っている。最初は4列の美しい表だった。 | 社員番号 | 氏名 | メールアドレス | 現在の状況 | |----------|------|----------------|------------| | 001 | 山田 太郎 | yamada@example.com | 在籍中 | ここから「入社日が知りたい」「退職理由も記録したい」「育休2回目の日程も」「更新者・更新日時も」と、ひとつひとつは完全に正当なリクエストが積み重なっていく。そのたびに列が追加され、ほとんどの行でほとんどの列が空白という状態が生まれる。非表示にしても問題は消えない。見えなくなるだけだ。 本質的な問題：「現在状況」を上書きすると過去が消える 記事が指摘する核心はここだ。 高橋さんが育休に入ったとき、「現在の状況」セルを <strong>「在籍中」→「育休中」に書き換えた</strong>。では、書き換える前の「在籍中」という情報はどこへ行ったか？ 消えた。 > 現在の状況を管理しようとすると、過去が消えます。 > 何が起きたかを記録すると、現在の状況は自然と導き出せます。 これはデータベース設計でいうところの ミュータブルな状態管理 vs イベントソーシング の違いと本質的に同じ話だ。現在値を直接持つのか、イベント履歴から現在値を導出するのか。Excelという道具の話をしているように見えて、実はソフトウェア設計の根幹に触れている。 解決策：「1つの届出 = 1枚のシート」 記事が提案する解決策はシンプルで明快だ。 - 入社届シート → 入社が決まった事実を記録 - 入社辞退届シート → 辞退が決まった事実を記録 - 育休届シート → 育休の申請を記録 - 退職届シート → 退職の申請を記録 育休届シートには育休を取った人の行しか存在しない。2回育休を取れば2行ある。それだけで「育休は何回か」が自動的にわかる。退職していない人の行に退職日列を用意する必要がない。 この設計の美しさは、<strong>行があること自体が「申請した」という事実を意味する</strong>という点だ。NULLだらけの表は、設計が間違っているサインだと言い換えてもいい。 エンジニア視点での補足：これはRDBの正規化と同じ プログラマーなら気づくはずだが、この設計はまさにリレーショナルデータベースの正規化そのものだ。1つのテーブルに何でも詰め込むのではなく、エンティティごとにテーブルを分け、外部キーで関連付ける。育休届テーブルに employee_id 列を持たせれば、JOIN で社員情報と紐付けられる。 Excelでも同じ思想を適用できる。VLOOKUPやPOWER QUERYを使えば、届出シートを結合して「現在の状況」ビューを作れる。記録する表と、見るための表を分ける——記事タイトルの意味がここで腑に落ちる。 まとめ：「崩壊する表」は悪意や怠慢の産物ではない 記事の冒頭にある一文が印象的だった。 > これは、あなたがズボラだからでも、前任者が悪かったからでもありません。管理表のつくり方に、構造的な問題があります。 個々の変更は合理的で、やめようと言えるタイミングが存在しない。だからこそ、最初の設計思想が重要になる。「今の状態を記録するのか、起きた出来事を記録するのか」——この一点で、管理表の将来が決まる。 Excel運用に悩むすべての担当者、そして設計レビューをするエンジニアに、ぜひ元記事を読んでほしい。データベース設計の教科書より、よほど身近な言葉で本質を伝えている。