この記事はenechain Advent Calendar 2025の22日目の記事です。
はじめに
こんにちは、enechainでプロダクトデザインを担当している伊藤です。 普段は、エネルギーの取引に関わるSaaSプロダクトのUI/UXをデザインしています。 読者の皆様にとって、「エネルギー取引」は専門的で馴染みのない遠い世界のように感じるかもしれません。
私自身もその一人でしたが、直近の2年間で、同じエネルギー領域でも全くドメインが異なる、特に複雑なプロジェクトを2つ経験しました。本記事では、その中で「専門的なドメインをどう理解し、形にしていくかのプロセス」を新規プロジェクトの経験をもとに振り返ります。
業務理解
専門用語のキャッチアップ
どちらのプロジェクトにおいても各領域の専門家たちがドメインエキスパートとして関わっていました。私が参画したタイミングでは、そのドメインエキスパートたちが専門用語を使いながら高度な議論を進めていました。
単語の意味を調べるだけでは不十分で、 「この言葉が、実務のどの動きに紐づいているのか」 まで理解しないと良いUIは作れません。
そこで、分からない用語はすべてNotionにメモし、後でオペレーションマニュアルや資料を読み直して、「どの場面で使われる言葉なのか」を紐づけていくことで、少しずつ全体像が見えるようになっていきました。
業務そのものの理解
最初に取り組んだのは、社内オペレーター向けにまとめられていた業務資料を読み込むことでした。 そこには日々の運用手順、注意点、想定されるエラー、締切との向き合い方など、実際に現場で起きている情報が詰まっていました。
プロダクトに直接関わらない業務も含めて、業務全体の流れを把握することは、より良いUIデザインを考えるうえで重要でした。 例えば、プロダクト内に承認機能を実装するかどうかも、すでに請求書の承認が別のプロダクトで行われていると分かっていれば、そもそも初期スコープに含めるべきかどうかを検討する論点として挙げることができます。
他にも、実際の業務で使用しているExcelそのものを見ながら、普段どのようにインプットしていて、どのようにアウトプットされているのかをそのユーザーになりきって作業をイメージすることも重要でした。 実際の画面（UI）に落とし込む過程で、Excel業務とのギャップが明確になりました。「Excelで行っている操作が仕様に含まれていない」という抜け漏れに気づけたり、「Excelの不便な点をUIでどう解決するか」というポジティブな改善案が出やすくなりました。
フローチャートを使って理解
ただ、文章で読んだだけではどうしても全体のつながりが見えてきませんでした。 そこで次に、Notionに整理されていた業務フローを、フローチャートとしてMiroに起こし直しました。
- どこで判断が発生しているか
- どの例外が業務に影響するか
- どのステップが別資料と接続しているか
といった業務全体の構造がはじめて立体的に見えるようになりました。
AIをつかって理解
専門領域を短期間で理解するために、AIも積極的に活用しました。特に効果を感じたのがNotebookLMです。
プロジェクトに関する資料は、規約、仕様書、業務説明、手順書など膨大で複雑でしたが、NotebookLMに資料一式を読み込ませることで、専門用語の意味や規約上の定義、資料同士のつながりや前提の違いを一気に整理できました。
NotebookLMを使うことで、
- 知識の拾い漏れをなくす
- 資料の構造化を高速で進める
- 議論前に前提を固められる
がスムーズに進み、キャッチアップ速度が劇的に向上しました。
認識のずれを減らすためにしたこと
複雑なドメインゆえに認識のずれも度々発生しました。 例えば、お金のやり取りをする画面の対応範囲について、関係者の間で認識のずれがありました。 初期段階で具体的なユースケースを洗い出しきれず、開発の初期スコープが曖昧だったことが原因です。
ユーザーの実務における複雑な例外処理まで網羅したいという 「要件」 に対し、初期リリースとしてどこまで機能実装すべきかという 「開発スコープ」 の線引きにおいて、チーム内で認識のすり合わせが必要な状態でした。
改善策
認識のずれを解消するために、私が特に意識して取り組んだのは「言葉ではなく、目に見える形で揃える」ことでした。
このプロジェクトでは複数の視点が入り混じるため、口頭での説明やドキュメントだけでは、どうしても解釈にずれが生まれやすい状況でした。 そこで有効だったのが、BRD（ビジネス要件定義書）を起点に、まず理想的な業務や状態を図として整理するプロセスです。
BRDをもとに、目指すべき理想状態を図で可視化し、すでに確定している仕様でどこまで対応できるのかを整理しました。 その図をもとにFigmaで実際のUIとして画面に落とし込み、チーム内で共有・議論を進めていきました。
Figma上で理想状態をデザインしながら、「既存の仕様でカバーできる部分」と「新たに検討すべき部分」を整理することで、言葉だけではずれやすい認識も、画面を見ながら徐々に揃えていくことができました。
開発をスムーズに進めるためにしたこと
このプロジェクトでは、仕様がまだ確定していない早い段階でデザインを作成し、仕様が揃ってきたタイミングでなるべくプロトタイプ化してフィードバックをもらうような形で進めていきました。
仕様を文章で詰めるより、
画面を見ながら議論したほうが圧倒的に早い。
- 操作の流れは自然か
- 迷うポイントはないか
- 必要な情報は十分か
- どのタイミングでアラートが必要か？
こうした議論は、デザインやプロトタイプがあると一瞬で具体的になります。
特に、「こうすればもっと使いやすくなるのではないか」といったアイディア段階では、文章で説明するよりもデザインとあわせて共有するほうが、メンバー全員に伝わりやすいと感じました。また、その場での反応を見ることで、UIデザイン案の確度を高めることができました。
お客様からの反応
enechainでは "Customer Obsession(お客様を中心に考えることにこだわり続ける)" という考え方を大事にしており、お客様と対話する機会を増やしています。 このプロジェクトではお客様向けには取引時に必要となるシミュレーション機能を提供しました。
この画面をお客様に使っていただいたところ、「こういう機能を待っていた」「取引の判断がしやすくなった」といった好印象な反応をいただきました。 さらに、実際の画面を一緒に見ながら操作していただく中で、具体的なフィードバックもいただき、次に取り組むべき開発の種も見つかりました。 プロダクトはリリースして終わりではなく、ユーザーと共に作り上げていくものなので、現場のリアルな声に触れられたことは、プロジェクト全体にとっても大きな収穫でした。
このプロジェクトが教えてくれたこと
このプロジェクトを通して得た学びは、数えきれないほどありますが、特に大きかったのは以下の3つです。
- 分からないことは、まず図にする
- 専門領域ほど、認識を揃えることが価値になる
- プロトタイプは、最強の要件定義ツールである
どれも私にとっては「プロダクトデザインとは何か」を改めて問い直すきっかけになりました。難易度の高いドメインだったからこそ、この学びが強く響きました。
おわりに
enechainでは、今回紹介したプロジェクト以外にも、エネルギー取引の世界を支えるさまざまなプロダクトを開発しています。 もし、エネルギー領域のプロダクトづくりに興味があったり、社会インフラを支えるサービスに関わってみたいと思われた方がいれば、ぜひお話しできたら嬉しいです。私たちと一緒にプロダクトをつくり、未来のエネルギー取引を支えてくれるメンバーを募集しています。
ご興味がありましたら、ぜひこちらからお気軽にご応募ください。
