社内エネルギー運用ダッシュボード — 運転計画とモード切り替えのUXエンジニアリング
既存のスマートシティ向け社内ダッシュボードで携わった複数の機能追加のうち、本ケーススタディでは「運転計画」と「運転モード切り替え」のUXエンジニアリングを取り上げています。中心となる成果物は、インタラクション、UI状態、フロントエンドバリデーション、エラーハンドリング、データフローを含む画面実装仕様書です。Figma資料と動作するプロトタイプを補足資料として使用しました。また、バックエンドエンジニアとフロントエンドのデータ要件を調整し、外部ベンダーによる実装から本番リリースまで関与しました。コードレビューでは具体的な変更コードを示し、必要に応じて自分でも変更を行いました。
この実績が活きるご相談
CSVとデータベースに依存していた影響度の高い業務フローを、既存の社内ダッシュボード内の新しい機能領域へ移行した事例です。業務フローの分析、UXエンジニアリング、バリデーション設計、技術調整、実装仕様の作成、本番対応を組み合わせて進めました。
- CSVや手作業で行われていた業務フローの社内インターフェースへの移行
- インタラクション、UI状態、データフローの定義
- 意図しないデータ消失のリスクを抑える操作設計
- 変化する要件の検証可能なインターフェース案への具体化
- バックエンドエンジニアとのフロントエンドデータ要件およびバリデーション境界の調整
- 別の実装チームに向けた画面実装仕様書の作成と、Figma資料および動作するプロトタイプによる補足
- コードレビュー、具体的な変更コードの提示、必要に応じた直接変更を通じた実装支援
概要
スマートシティのエネルギー運用環境で使用される既存の社内ダッシュボードにおいて、複数の新機能開発に携わりました。本ケーススタディでは、そのうち「運転計画」と「運転モード切り替え」の2つの機能領域を取り上げています。正式な職種はフロントエンドエンジニアであり、これらの機能における主な役割はUXエンジニアリングでした。既存の運用フローを調査し、Figmaとプロジェクトのフロントエンド技術構成を用いた動作するプロトタイプを併用することで、ステークホルダーが具体的な選択肢を評価し、要件を明確にできるよう支援しました。そのうえで、合意した業務フローを実現するためのインタラクション、UI状態、バリデーションルール、エラー処理、データフロー、実装詳細を、画面実装仕様書にまとめました。Figma資料と動作するプロトタイプは、その仕様を補足する資料として使用しました。バックエンドエンジニアとは、フロントエンドで必要となるデータを共有し、データ構造の候補を提示したうえで、フロントエンドとバックエンドの責任範囲を協議しました。APIの最終設計はバックエンドエンジニアが担当し、私は合意したAPIの挙動、ペイロード、レスポンス、バリデーション境界、エラー処理をフロントエンド実装仕様に反映しました。本番機能全体の実装は外部ベンダーが担当しました。プロトタイプコードの一部は実装に再利用され、私は合意した挙動や仕様との整合性を確認するコードレビューを行いました。レビューコメントでは具体的なコードを提示し、複雑、不完全、または仕様と一致していなかった一部の領域については直接実装・修正しました。両機能は本番リリースされ、実運用が開始されています。
背景
既存のダッシュボードは、スマートシティのエネルギー運用環境において、電力設備の管理と監視に使用されています。本ケーススタディで扱う機能領域は、短期的または実験的な運転計画の編集と適用を支援するものです。従来の業務フローでは、Excel、CSVファイル、コマンドライン操作、データベースの直接更新を組み合わせていました。これらの操作は電力制御に関係するため、誤った計画を適用すると、運用コストや電力供給の安定性に影響する可能性がありました。また、CSVアップロードには日付単位のスナップショット置換方式が使用されていました。そのため、アップロードしたファイルに含まれていないデータが削除されたものとして扱われる可能性があり、ユーザー操作、バリデーション、データ更新の関係を特に慎重に設計する必要がありました。
課題
既存プロダクト、変化する要件、現実的な実装制約の中で、運用への影響が大きい業務フローを、より安全で理解しやすいインターフェースとして実現する必要がありました。
- 初期要件には、具体的なインターフェースの挙動がなければ判断しにくい未確定事項が含まれていた
- CSVの内容が選択した日付の既存計画データを置き換えるため、上書きや削除のリスクがあった
- 画面上で選択した日付とCSV内の日付を一致させる必要があった
- 設備ID、稼働状態、設備ごとの値の範囲、48コマすべてのバリデーションが必要だった
- 初期リリースでは約6台を対象とし、将来的には50〜100台 × 48コマへの拡張が想定されていた
- 既存画面では日付の境界やエラーの原因が分かりにくかった
- 外部実装者に、インタラクション、UI状態、エッジケース、データの挙動、API、文言を明確に伝える必要があった
- 他画面に影響を与えず、既存のコードベースに適合させる必要があった
主なユーザー
- 運転スケジュールを調整する運用担当者
- インターフェースを直接使用する管理職のステークホルダー
- 必要に応じて運転計画の確認や適用を行うその他の社内関係者
機能範囲
運転計画：月表示
- 当月と翌月を表示する2か月分のグリッド
- 設備を行、日付を列として表示
- 各セル内に計画の有無を表示
- 選択した実験日と設備に対してのみ計画を作成
- CSVテンプレートのダウンロード
- 選択した複数の日付に対する一括削除
- 選択状態と確認モーダル
運転計画：日表示
- 選択した1日分の詳細グリッド
- 設備を行、30分単位の48コマを列として表示
- 設備ごとの最小・最大出力制約
- CSVのダウンロードとアップロード
- 選択した日の運転計画の削除
- 修正箇所を特定できるバリデーション結果
運転モード切り替え
- 現在の運転モードとステータスの表示
- アップロードした計画を有効にするタイミングの制御
- 変更内容と運用上の影響を説明する確認フロー
- モード変更適用前の明示的な確認
CSVワークフロー
- 計画が存在しない場合のテンプレートダウンロード
- 有効な設備と48コマすべてをテンプレートに含める
- 選択した日表示からのみアップロード可能
- 画面上の日付とCSV内の日付の一致確認
- 1日単位の削除と複数日付の一括削除
- スナップショット置換に関する警告と確認
アプローチ
既存業務フローの理解と要件の具体化
運用担当のステークホルダーにヒアリングを行い、Excel、CSVファイル、コマンドライン操作、データベース更新をどのように組み合わせて運転計画を作成・適用していたかを確認しました。これにより、業務の手順、データ更新による影響、関連するリスク、ユーザーが判断すべき事項を整理しました。一部の要件は、抽象的な議論だけでは定義することが困難でした。そのため、具体的なインターフェース案と動作するプロトタイプを提示し、ステークホルダーが想定する挙動を評価しながら、業務フローに必要な要件を明確にできるようにしました。また、専任PMが不在だったため、決定事項を文書化し、関係者間の認識合わせも支援しました。
Figmaと動作するプロトタイプを行き来した反復
Figmaを使用して、情報構造、画面構成、UI状態、複数の選択肢を検討しました。設備ごとのカード型レイアウト、2か月分の計画グリッド、設備 × 48コマで構成した日表示、選択・保存・適用・一括削除に関する異なる挙動などを比較しました。また、React、Next.js、TypeScript、Material UI、MSWとプロジェクト既存のフロントエンドパターンを使用して、動作するプロトタイプを作成しました。検討する内容に応じて適した表現手段を選び、プロセス全体を通じてFigmaとコードの間を行き来しました。具体的な選択肢を提示することで、ステークホルダーは各案を比較し、実際の運用ニーズに合う点と合わない点を判断できました。最終的な範囲を決定する前に、インライン編集とCSVベースの操作を、実装コスト、既存の作業方法、データ制約、操作ミスのリスクという観点から評価しました。
インタラクション、UI状態、データフローの定義
この作業は画面レイアウトやワイヤーフレームの作成だけではありませんでした。各ユーザー操作の後に何が起きるか、状態に応じてインターフェースがどう変化するか、各時点でどのデータが必要か、成功・バリデーションエラー・処理失敗に対してフロントエンドがどう応答するかを定義しました。コードプロトタイプは、既存コードベース上でのCSV解析、バリデーション、選択状態、エラー処理、破壊的操作、データ量の検証に特に有効でした。また、技術的な制約を早期に明らかにし、合意する挙動に反映できました。プロトタイプは実装仕様を補足する資料として外部ベンダーに共有され、そのコードの一部は本番環境で再利用されました。
バックエンドとのフロントエンドデータ要件の調整
インターフェースの挙動が明確になるにつれて、各画面で必要となるデータと、そのデータが必要になるタイミングを特定しました。データ構造の候補を提示し、特定のデータ変換をフロントエンドとバックエンドのどちらで行うべきかを、実装効率、一貫性、再利用性、安全性の観点からバックエンドエンジニアと協議しました。APIの最終設計はバックエンドエンジニアが担当しました。私はフロントエンドの要件と提案を共有し、合意したAPIの挙動、ペイロード、レスポンス、バリデーション境界、エラーコードを実装仕様に反映しました。
フロントエンドバリデーションとエラーUXの設計
- ファイル拡張子、ファイルサイズ、日付の不一致、許可範囲外の日付を検証
- 必須となる1〜48のコマに欠損がないかを確認
- 無効な設備ID、停止中の設備、設備ごとの制限範囲外の値を確認
- 処理を継続できない場合はアップロードを停止
- ユーザーが修正可能なデータエラーを、行・列情報とともに集約
- バリデーション結果と処理失敗がUI状態に与える影響を定義
- バックエンドエンジニアとバリデーションの責任範囲、エラーコード、レスポンス形式を調整
スナップショット更新と破壊的操作への対応
- アップロードを選択した日表示に限定
- 画面で選択した日付とCSVに含まれる日付を比較
- 日付が一致しない場合はアップロードをブロック
- 1日単位の削除と複数日付の一括削除を分離
- 削除と運転モード切り替えの前に明示的な確認を追加
- 変更の適用前に、対象と想定される運用上の影響を明示
- 成功、ブロック、失敗それぞれのUI状態とデータ更新の挙動を定義
実装仕様と引き継ぎ資料の作成
- 各画面および機能領域の注釈付き仕様
- インタラクション、UI状態、モーダル、空状態、エッジケース
- 1日単位および複数日付の削除挙動
- バックエンドエンジニアと合意したAPIエンドポイント、ペイロード、レスポンスパターン
- フロントエンドとバックエンドのバリデーション責任範囲
- エラーコードと英語・日本語のローカライズメッセージの対応表
- 長いモーダル説明文のコピーおよび翻訳表
- 実装仕様を補足する動作するプロトタイプ
- 実装時に一貫性を維持すべき設計意図と挙動
実装レビューとコード変更への関与
本番機能全体の実装は外部ベンダーが担当しました。私は、合意したインタラクション、バリデーションルール、エラー処理、データフロー、および既存画面への影響との整合性を確認するため、コードレビューを行いました。合意した挙動が実装に反映されていない場合や、より具体的な実装上の指針が必要な場合には、レビューコメントで具体的な変更コードを提示しました。必要に応じて、自分でも変更を行い、本番コードに反映しました。GitHub Copilotもレビューと検証の補助として使用し、潜在的なバグ、バリデーションの不足、セキュリティ上の懸念を洗い出しました。各指摘を実際のコード、プロジェクトの範囲、実装状況と照合し、有効と判断した問題を修正しました。
UXエンジニアリングと実装のポイント
要件を具体的な形で検討可能にする
要件を事前に完全に言語化することが難しい場合でも、Figmaの選択肢と動作するコードプロトタイプによって、ステークホルダーが具体的に評価できる対象を提示しました。その反応をもとに、インターフェースの挙動、運用フロー、最終的な機能範囲を調整しました。
初期規模と将来規模を分けて考える
初期リリースでは約6台 × 48コマを扱い、将来的には50〜100台 × 48コマまで増えることが想定されていました。月表示と日表示を分けることで、初期の業務フローに対応しながら、将来的な情報量の増加も考慮しました。
日付の一致をアップロード条件にする
アップロードは選択した日表示からのみ行えるようにし、画面上の日付とCSV内の日付を照合しました。一致しない場合は、別の日の計画が更新される前に処理をブロックしました。
修正可能なエラーをまとめて表示する
行・列単位のエラーを、その位置と原因とともにまとめて表示することで、ユーザーが複数の修正事項を一度に確認できるようにしました。
破壊的操作と運用上重要な操作を確認する
1日単位の削除、複数日付の一括削除、運転モードの切り替えでは、操作を適用する前に対象と想定される影響を示す確認フローを設けました。
インターフェースの挙動とデータの挙動をつなぐ
ユーザー操作、UI状態、フロントエンドバリデーション、APIレスポンス、データ更新による影響を、個別の設計・開発事項ではなく、ひとつの業務フローとして定義しました。
実装時の解釈のずれを減らす
インタラクション、UI状態、エッジケース、API、バリデーション責任範囲、エラーコード、ローカライズ文言を、相互につながるひとつの仕様として文書化しました。その後、コードレビューを通じて、実装がこれらの決定事項と一致しているかを確認しました。
成果物
- 既存の業務フローと運用上のリスクに基づく要件
- 月表示と日表示のインタラクションおよび画面構造仕様
- 運転モード切り替えの挙動と確認フロー
- CSVテンプレート、アップロード、バリデーション、削除の各ワークフロー
- Figmaによる検討案と最終的な注釈付き仕様
- 実装仕様を補足する動作するコードプロトタイプ
- UI状態とインタラクションの仕様
- フロントエンドバリデーションとエラーフィードバックの仕様
- フロントエンドのデータ要件とデータ構造案
- フロントエンド・バックエンド間のバリデーション責任範囲表
- バックエンドエンジニアと合意したAPIの挙動に関する文書
- エラーコードと英語・日本語のローカライズメッセージの対応表
- 状態、データの挙動、エッジケース、モーダルを含む実装資料
- 外部ベンダーへの引き継ぎ資料
- コードレビュー、実装ガイダンス、本番コードへの部分的な変更
結果
- 運転計画と運転モード切り替えを本番リリース
- 両機能の実運用を開始
- 変化する要件を、具体的で検証可能なインターフェースの挙動へ変換
- インタラクション、UI状態、データフロー、バリデーションルール、エッジケース、文言を定義
- フロントエンドのデータ要件とバックエンドとの責任範囲を調整
- スナップショット置換、削除、日付不一致、運転モード切り替えに対する安全策を実装へ反映
- 動作するプロトタイプの一部を本番環境で再利用
- ベンダーの実装をレビューし、レビューコメントで具体的な変更コードを提示するとともに、一部の変更を直接実施
画面とデザイン資料
最終仕様：月表示
設備ごとの計画の有無を2か月分確認し、CSVテンプレートのダウンロードや、選択した複数の日付に対する計画の削除を行う画面です。
最終仕様：日表示
選択した日付について、設備 × 48コマの表でCSVのアップロード、ダウンロード、バリデーション、削除を行う画面です。
CSVバリデーションエラー表示
修正可能なエラーを行、列、原因の情報とともに集約し、複数の問題を一度に確認できるようにしています。
運転モード切り替え
現在の運転モードを表示し、アップロードした計画をいつ有効にするかを制御するインターフェースです。
モード切り替え確認
新しいモードを適用する前に、変更内容と運用上の影響を確認できるようにしています。
ドラフト1：カード型の日表示
設備ごとに1枚のカードを使用し、日別計画の確認と編集方法を検討した初期案です。
ドラフト2.5：月間グリッド
計画が存在する日を確認し、月表示から選択した日の日表示へ移動する方法を検討した案です。
ドラフト3：日別テーブル
より多くの情報を扱うため、カード型構造から設備 × 48コマのテーブルへ移行した案です。
ドラフト4：編集と一括操作
編集状態、一括操作、データ更新の挙動、操作ミスの防止を検討するために使用した案です。
この取り組みから示せること
本ケーススタディは、既存の運用プロダクトにおけるUXエンジニアリングの実践例です。ユーザー操作、インタラクション、UI状態、フロントエンドとバックエンドの責任範囲、データ更新の制約、実装コスト、運用上の影響を一体として検討する必要がありました。Figmaと動作するコードプロトタイプの間を反復的に行き来し、変化する要件を具体的で検証可能な形にしました。その後、合意した挙動を、バリデーションルール、データ要件、ローカライズされたエラーメッセージ、エッジケースへの対応、画面実装仕様へと展開しました。引き継ぎ後も、ベンダーのコードレビュー、具体的な実装ガイダンス、本番コードへの部分的な変更、リリース、実運用の開始まで継続して支援しました。