
Summary
この文書の要点
- Excelのセル構造をそのまま画面構造にしない。
- 計算ロジックはUIから分離し、テストできる関数にする。
- Excelの見た目を再現する前に、指標の定義、粒度、締めタイミングを分離する。
- Webダッシュボードでは、集計済みテーブルとドリルダウン用データを分ける。
どこが設計の難所か
Excel集計をWebアプリに移す時、既存シートのレイアウトをそのまま再現しようとすると、画面が複雑になり保守しづらくなります。一方で、計算式や確認手順を軽視すると、現場が結果を信頼できません。
既存のExcelには、明示されていない業務ルールが入っていることがあります。空白の扱い、丸め、除外条件、手入力で補正している値などを洗い出さないと、Web化後に数字が合わない問題が起きます。
Excelの集計表には、計算式だけでなく、担当者の判断、補正値、締め後の修正、例外処理が埋もれがちです。そのままWeb画面に写すと、見た目は近くても、どの数字がいつ確定したのか説明できないダッシュボードになります。
境界をどう切るか
まず、入力、計算、表示、出力を分けます。Reactは画面表示と操作に集中させ、集計ロジックはTypeScriptの純粋関数として切り出します。Excelから取り込む場合も、取り込み直後の生データと検証済みデータを分けます。
まず、入力データ、集計ルール、表示ビューを分けます。Reactで見た目を作る前に、指標ごとの定義、集計単位、フィルタ、権限、更新頻度をデータモデルとして置くと、後からグラフや一覧を増やしやすくなります。
実装で効く細部
計算関数には、入力型、出力型、丸め規則、除外条件を明示します。画面では集計結果だけでなく、元データ件数、除外件数、警告件数を表示します。既存業務でExcel提出が必要なら、WebアプリからExcelを再出力する導線を残します。
実装では、rawデータ、正規化済みデータ、集計スナップショットを分けます。画面は集計APIから軽いDTOを受け取り、詳細確認時だけ元データへドリルダウンします。これにより、初期表示の速度と数字の追跡性を両立できます。
- 指標ごとに計算式、対象期間、除外条件をメタデータとして管理する。
- 集計スナップショットには生成時刻と元データ範囲を保存する。
- 手動補正が必要な場合は、上書きではなく補正テーブルとして履歴を残す。
壊れ方を観測する
検証では、既存Excelで計算済みの代表データをテストケースにします。Web版の結果とExcel版の結果を比較し、差が出た場合は丸め、日付、空白、除外条件のどこに原因があるかを分類します。
検証では、既存Excelの代表月とWeb集計結果を突合します。差分が出た場合に、丸め、日付境界、除外条件、補正値のどこで違うのかを追えるようにしておくと、単なる数字合わせで終わらず仕様の整理になります。
捨てた選択肢とトレードオフ
Excelの自由度をすべてWebに持ち込むと、結局複雑な表計算アプリになります。Web化の目的が入力統制なのか、集計速度なのか、共有なのかを決め、自由入力を残す範囲を絞ることが必要です。
Excelの自由度をすべてWebで再現しようとすると、複雑で壊れやすい画面になります。逆に固定しすぎると現場の例外処理を吸収できません。自由入力が必要な部分と、確定指標として固定する部分を分ける判断が必要です。
現場に残す判断軸
Excel集計のWeb化では、画面の再現より計算根拠の再現が重要です。ロジックをテストできる形に分離し、結果を現場が確認できる情報を添えることで、移行後の信頼を作れます。
ExcelからWebダッシュボードへの移行は、UI移植ではなく指標定義の再設計です。数字の出どころを説明できる構造にすると、グラフの見た目以上に実務で使える画面になります。


