電力運用ダッシュボード — 運転計画・CSV操作・実装支援
スマートシティの電力運用に使う社内ダッシュボードで、運転計画と運転モード切替の2機能を設計した案件。曖昧な要件を画面と操作フローへ落とし込み、コード試作、フロントエンドバリデーション、エラー表示、API連携仕様、ベンダー向け資料を整備した。実装レビューと必要箇所の修正にも関わり、両機能は本番公開・利用開始まで進んだ。
期間：2025年12月〜2026年7月
この実績が活きるご相談
CSVやデータベースを使った影響の大きい業務について、現行運用の把握から画面設計、バリデーション、仕様化、実装支援まで進めた事例です。
- CSVや手作業に依存する業務を画面操作へ移したい
- 誤操作やデータ消失を防ぐ操作フローを設計したい
- 曖昧な要件を実装可能な画面仕様へ整理したい
- フロントエンドとバックエンドのバリデーションを調整したい
- 他社・他チームが実装できる仕様書と参考コードを準備したい
- 実装レビューと必要箇所の修正まで支援したい
概要
スマートシティの電力運用に使われる社内ダッシュボードで、運転計画（Operation Planning）と運転モード切替（Operation Mode Switching）の2機能を設計・仕様化しました。正式な役割はフロントエンドエンジニアで、案件内では業務フローの整理、UX/UI設計、要件と仕様の言語化、コードモックアップ、フロントエンドバリデーション設計、ベンダー向け資料、コードレビュー、必要箇所の実装まで担当しました。機能全体の本番実装は外部ベンダーが担い、作成した参考コードの一部が流用されました。レビュー時には仕様との不一致や複雑な実装箇所を確認し、具体的なコードの提示や直接修正も行いました。2つの機能は本番公開され、利用が開始されました。
背景
対象のダッシュボードは、スマートシティのエネルギー運用環境で、電力デバイスの管理・監視に使われています。担当した機能は、短期的・試験的な運転計画を編集し、適用するためのものです。従来はExcel、CSV、コマンドライン、直接的なデータベース更新を組み合わせて対応していました。電力制御に関係する操作であり、誤った計画の適用はコストや供給安定性に影響する可能性があります。CSVアップロードは日付単位のスナップショット置き換えとして処理され、CSVに含まれないデータが削除される仕様でした。
課題
影響の大きい運用操作を、日常的に扱える画面へ整理し、誤操作を防ぐ仕組みと実装可能性を両立する必要がありました。
- 要件が初期段階では曖昧で、画面案を確認しながら具体化する必要があった
- CSVの内容が日付単位で既存データを置き換えるため、入力ミスが削除・上書きにつながり得た
- UIで選択した日付とCSV内の日付を一致させる必要があった
- デバイスID、稼働状態、値の範囲、48スロットの欠落など、複数の検証条件があった
- 初期リリースでは約6台、将来は50〜100台 × 48スロットを扱う想定だった
- 既存画面では日付・時刻の境界やエラー原因を把握しにくい箇所があった
- 外部ベンダーが実装できる粒度まで、状態、例外、API、文言を定義する必要があった
- 既存コードベースと既存画面への影響を考慮する必要があった
主な利用者
- 日々のスケジュールを調整するオペレーション担当者
- 同じ画面を直接操作するマネージャークラス
- 必要に応じて計画の確認・適用を行う社内ステークホルダー
設計対象
Operation Planning：月別ビュー
- 当月と翌月を表示する2か月分のグリッド
- 行にデバイス、列に日付を配置
- 各セルで計画の有無を確認
- 実験対象となる日付・デバイスだけに計画が入る前提
- CSVテンプレートのダウンロード
- 複数日を選択した一括削除
- 選択状態と確認モーダル
Operation Planning：日別ビュー
- 選択した1日分の詳細グリッド
- 行にデバイス、列に48個の30分スロットを配置
- デバイスごとの最小値・最大値を考慮
- CSVのダウンロードとアップロード
- 選択した日の計画削除
- バリデーション結果と修正箇所の表示
Operation Mode Switching
- 現在のモードとステータスの表示
- アップロード済みの計画を有効化するモードの切替
- 変更内容と運用上の影響を確認するモーダル
- 明示的な確認後に変更を適用するフロー
CSVワークフロー
- 計画が存在しない状態でも使えるテンプレートのダウンロード
- 有効なデバイスと48スロットを含むテンプレート
- 選択中の日付画面からのアップロード
- UI上の日付とCSV内日付の一致確認
- 単日削除と複数日一括削除
- スナップショット置き換えを考慮した警告と確認
実施内容 / 進め方
現行運用と要件の整理
運用関係者へのヒアリングを通じて、既存のExcel、CSV、コマンドライン、DB更新を使った流れを確認しました。運転計画の作成・適用方法、データ更新時の影響、利用者が判断する内容を整理しました。当初の要件には曖昧な部分があり、具体的な画面案を見せながら認識を合わせました。明確なPMがいない環境だったため、仕様の言語化と関係者間の合意形成も担当しました。
画面構造の反復
Figmaで、デバイスごとのカード型画面、2か月分の月別グリッド、デバイス × 48スロットの日別テーブル、選択・保存・適用・一括削除を含む編集操作を段階的に検討しました。インライン編集とCSV中心の運用を比較し、実装コスト、運用方法、誤操作のリスクを確認しながら最終スコープを決めました。
コードによる操作検証
初期のレイアウトと情報構造はFigmaで検討し、CSVパース、バリデーション、エラー表示、選択状態、一括削除などの振る舞いが複雑になった段階でコードモックアップを作成しました。画面上の操作、データ量、実装制約、既存コードベースとの接続を確認し、外部ベンダーへ参考実装として共有しました。一部は本番コードに流用されました。
フロントエンドバリデーションとエラーUXの設計
- 拡張子、ファイルサイズ、日付不一致、許可されていない日付範囲をファイル単位で検証
- 48スロットの不足、不正なデバイスID、無効なデバイス、許容範囲外の値を内容単位で検証
- 処理を継続できないエラーはアップロードを停止
- 修正可能な複数のデータエラーは行・列情報とともに集約表示
- バックエンドエンジニアと、検証責任、エラーコード、レスポンス形式を調整
データ更新と破壊的操作への対応
- アップロードを日別画面からの操作に限定
- 選択中の日付とCSV内日付を照合
- 日付不一致の場合はアップロードをブロック
- 単日削除と複数日一括削除を分離
- 削除・モード切替前に確認モーダルを表示
- 変更対象と影響を確認してから適用するフローを設計
実装仕様とハンドオフ資料の作成
- 各画面の挙動と注釈付きスクリーンショット
- UI要素ごとの状態、モーダル、空状態、エッジケース
- 単日削除と複数日一括削除のフロー
- APIエンドポイント、ペイロード、レスポンス
- フロントエンド・バックエンドのバリデーション分担
- エラーコードと日英UIメッセージの対応
- モーダル内の長文コピーと翻訳表
- 設計理由と実装時に守る必要がある挙動
実装レビューと必要箇所の修正
外部ベンダーが機能全体を実装し、仕様との整合性、バリデーション、エラー処理、既存画面への影響をコードレビューで確認しました。設計内容が反映されていない箇所や実装判断が複雑な箇所では、レビューコメントに具体的なコードを提示し、必要に応じて自身で修正しました。GitHub Copilotはバグ、バリデーション漏れ、セキュリティ上の懸念を洗い出す補助として使い、各指摘を実際のコードと変更範囲に照らして確認したうえで、妥当な問題を修正しました。
設計・実装上のポイント
初期規模と将来規模を分けて設計
初期リリースでは約6台 × 48スロットを扱い、将来的には50〜100台 × 48スロットまで拡張する想定でした。現在の操作性と将来の情報量を考慮し、月別と日別の表示を分けました。
日付の一致をアップロード条件にする
アップロード操作を選択中の日付画面に限定し、UI上の日付とCSV内の日付を照合しました。対象日が一致しない場合は処理を止め、別の日の計画を更新する操作を防ぐ仕様にしました。
修正可能なエラーをまとめて表示する
行・列単位のエラーを集約し、位置と原因をまとめて表示しました。利用者が複数の修正箇所を一度に確認できる設計です。
削除とモード切替に確認を組み込む
単日削除、複数日一括削除、運転モード切替について、対象と影響を確認するモーダルを設計しました。
設計と実装の解釈差を減らす
画面、状態、例外、API、バリデーション、エラーコード、日英文言を一つの仕様として整理しました。レビュー時には仕様とコードを照合し、必要な修正を実装へ反映しました。
アウトプット
- 現行業務フローと操作リスクの整理
- 月別・日別画面の情報構造とUI仕様
- Operation Mode Switchingの操作・確認フロー
- CSVテンプレート、アップロード、削除フロー
- Figmaワイヤーフレームと最終画面
- コードモックアップと参考実装
- フロントエンドバリデーション仕様
- バックエンドとのバリデーション分担
- エラーコードと日英メッセージの対応表
- API、状態、例外、モーダルを含む実装仕様書
- 外部ベンダー向けハンドオフ資料
- コードレビュー、実装指示、必要箇所のコード修正
結果
- Operation PlanningとOperation Mode Switchingを本番公開
- 両機能の利用を開始
- 曖昧だった要件を、画面、状態、例外、API、文言を含む実装仕様へ整理
- フロントエンドのバリデーションとエラー表示を仕様化
- データ置き換え、削除、日付不一致、モード切替に対する確認・制御を実装へ反映
- コードモックアップの一部を本番実装に活用
- ベンダー実装をレビューし、具体的な実装指示と必要箇所の修正を反映
画面・設計資料
最終仕様：月別ビュー
当月と翌月の計画有無をデバイスごとに確認し、CSVテンプレートの取得と複数日削除を行う画面。
最終仕様：日別ビュー
選択した日について、デバイス × 48スロットの値を確認し、CSVの入出力と単日削除を行う画面。
CSVバリデーションエラー表示
複数の修正可能なエラーを、行・列と原因が分かる形でまとめて表示。
運転モード切替
現在のモードを確認し、アップロードした計画を有効化する状態へ切り替える画面。
運転モード切替の確認モーダル
変更対象と運用上の影響を確認してからモードを切り替える。
Draft 1：カード型の日別画面
1デバイスを1カードとして、日別の計画を確認・編集する初期コンセプト。
Draft 2.5：月別グリッド
計画がある日付を把握し、日別画面へ移動する構造を検討した段階。
Draft 3：日別テーブル
デバイス × 48スロットを扱うため、カード型からテーブル型へ変更したイテレーション。
Draft 4：編集・一括操作
編集状態、保存・適用操作、一括削除と誤操作防止の関係を検討した段階。
この実績で示せること
業務上の影響が大きい社内ツールについて、利用者の操作、データ更新の制約、フロントエンドとバックエンドの境界、実装コストを同時に確認しながら設計した経験です。曖昧な要件をFigmaとコード試作で具体化し、画面仕様、バリデーション、API、エラー文言、例外処理へ展開しました。外部ベンダーへのハンドオフ後も、コードレビュー、具体的な実装指示、必要箇所の修正を通じて、本番公開まで関わりました。