ENECHANGE Developer Blog

ENECHANGE開発者ブログ

「PoCが進まない」を脱却!UXデザイナーがAIと共創する時代へ

私たちは、問い、実験し、愛を持って体験をデザインします🧪&♥️


はじめに

こんにちは、ENECHANGE EXPERIENCE部、部長の草間です。

この7月に、UXデザインとデータを管轄するエクスペリエンス部を新設し、その責任者として活動しています。 デザイナーの私がエンジニアブログに登場するのは、AIコーディングの導入で大きくワークフローが変わるからです。 従来のデザイナーとエンジニアの役割分担が大きく変化し、新しい開発手法が必要になってきたことを強く実感しています。

エクスペリエンス部は単に見た目がきれいな画面の作成や、データの収集をするチームではありません。

「社会に根ざした価値ある体験の実装」を目指して、ユーザー体験 × 事業戦略 × 社会実装 の接点をデザインすることにコミットしていきます。

私たちは問いを立て、手を動かし、試し、学び、それをサービスに還元することに力を注ぎます。 その根底にあるのが、 PoC(Proof of Concept)駆動型 の開発です。 このアプローチにより、UXとデータが融合したサービス体験を素早く形にでき、組織全体に成長をもたらすことを目指しています。

なぜ今、PoC駆動が必要なのか?

これまでのサービス開発は、見積もり済み要件に従ってデザインやUIを詰める伝統的なプロセスで駆動していました。その中で見えてきた課題は以下の通りです。

  • 要件定義に縛られ、リリース後に見つかる課題に手が出しにくい
  • デザインと実装が分断され、UXに対する議論が後手に回る
  • 実装が難しいデザインをしてしまい、実装者に苦労させる
  • 実際に動かさないと気づけない課題が多く、結局手戻りが発生する
  • 営業やCS、データチームが現場感に合ったフィードバックを出しにくい
  • 新しいテクノロジーやスキルに挑戦する機会が限られる

また、新サービスや改善のアイデアの種は多数あっても、実装するエンジニアの手が足りないために進められない、ということが往々にしてありました。

そこで私たちは「画面を作るだけでなく、そこに紐づく業務やデータ、運用も含めて動かしながら試す文化」に舵を切ることにしました。

「PoC駆動」とは?

ここでいうPoC駆動とは、動く試作品をどんどん作って試す開発体制です。

具体的には:

  • デザインしたUIに最低限動くデータやボタン動作を追加
  • データチーム、営業やCSと一緒に触って感触をその場でフィードバック
  • それを受けてすぐ改良版を作成
  • このサイクルを短期間でぐるぐる繰り返す

これにより、仕様書や企画書だけでは気づけない課題やチャンスが早期に見つかり、営業・開発工数の効率的な投入を実現できるようになります。

なぜ「画面デザインだけでは足りない」のか?

UX(User Experience)は、きれいなUIだけでは成立しません。その裏には必ず業務やデータ、法規制への対応といった複雑な要素が絡んできます。

たとえば:

  • そのボタンを押したら、裏側でどんな業務が発生するか
  • データがどんなルールで更新されるか
  • 運用時にはどんな手順でメンテナンスするか
  • 法規や導入先ごとのルールにどんな影響があるか

これらを後回しにすると、リリース後に「見た目はいいけど使えない」という状況に陥ってしまいます。 だからこそ、従来は慎重な設計と要件の定義が重要でした。 もちろんPoC駆動においても「UIと業務、データ、運用」をセットで試すアプローチが大切になります。

いままでできなかったPoC駆動が実現するのはなぜ?

AIエージェントの高性能化で画面の表現を自動的に実装したり、デザインツールであるFigmaとの連携が可能になるなど、従来であればエンジニアに依頼(=工数を確保)しないと作れなかったレベルのものが、直接デザイナーたちの手で作れるようになりました。

また、従来のデータ管理チームをエクスペリエンス部に配置することで、保有するデータの価値や運用をダイレクトに取り扱うことができるようになりました。

この変化を大胆に取り入れ、かつ、着想・デザインプロセスの中心に取り入れることにより、PoC駆動が実現可能になりました。

具体的な体験:設計ドキュメントとPoCの融合

深澤さんの記事で紹介された「設計ドキュメントをコードと同様に扱う」アプローチは、私たちのPoC駆動と非常に相性が良く、実際に以下のような効果を実感しています。

従来の課題: - 設計書は作るが、実際の動作確認まで時間がかかる - デザインと実装の間で認識のズレが発生 - フィードバックを得るまでに数週間かかる

AIエージェント活用後の変化: - 設計ドキュメント(reStructuredText)から直接PoCを生成 - CursorやClaude Maxを使って、設計書の内容を即座に動く形に変換 - 営業やCSチームと一緒に触りながら、リアルタイムで改善

例えば、先日取り組んだ電力料金比較機能のPoCでは、以下のような流れで進めました:

  1. 設計ドキュメント作成(深澤さんのアプローチを活用)

    • ユーザーストーリーをGitHub Issueで管理
    • reStructuredTextで画面設計を記述
    • Mermaidで画面遷移図を自動生成
  2. PoC生成(AIエージェント活用)

    • 設計書をAIエージェントに読み込ませて実装コードを生成
    • Figmaのデザインと連携してHTML/CSSを自動生成
    • ダミーデータを自動で用意
  3. 即座の検証

    • 営業チームと一緒に触って感触を確認
    • データチームから実際のデータ構造を教えてもらい調整
    • その場で改善案を出して、すぐに改良版を作成

この結果、従来なら1ヶ月かかっていた機能の方向性確認が、1週間で完了しました。

PoCと完成品はどう違う?

PoCは方向性を見極める手段です。その違いを以下にまとめます。

項目 PoC(試作) 完成品(リリース版)
ゴール 方向性が妥当か早期に見極める ユーザーが長期間安心して使える状態にする
デザイン 動きや流れがわかる最低限 ブランドやUIガイドラインに沿った仕上げ
データ ダミーデータやテスト用データ 実運用データに対応、セキュリティや法規対応済み
運用面 簡単な手動操作で検証 社内外に向けた運用ルールや監視体制が整っている
リリース後 リリース前に課題を見つけ修正するための手段 リリース後は安定性、拡張性、メンテナンス性が最重視

PoCは方向性を見極める手段です。このステップをきちんと踏むことで、リリース後に出てくるリスクを減らし、リソースを無駄にせずに済みます。

OODAループが成長を加速させる

PoC駆動は、単に試作をし続けることを目的としているのではありません。「Observe→Orient→Decide→Act」のOODAループに沿って、サービス成長そのものを促進し、事業に貢献することが重要です。

🔍 Observe(課題を集める)

  • 営業やCS、導入先からフィードバックを収集
  • 仮想ユーザー(AI等)によるテストで潜在課題を先取り

🧠 Orient(問いを再定義する)

  • UXデザイナーが体験価値を再設計
  • データチームがデータ視点から可能性や課題を整理

🛠️ Decide → Act(試作からリリースへ)

  • AIエージェントと協働し、動く試作品を短期間で用意
  • データ整備や業務フローも織り込み、現場に近いUXに近づける
  • エンジニアに引き渡せるものが実装に近いことで工数を削減する

AIエージェントとの具体的な協働体験

酒井さんの記事で「全方位型の相棒」と表現されたAIエージェントは、私たちのPoC駆動でもまさにその通りだと実感しています。

従来のデザイナーとエンジニアの関係: - デザイナー:「こんな画面を作りたい」 - エンジニア:「実装が難しいから、デザインを変更して」 - 結果:妥協案で終わることが多い

AIエージェント活用後の変化: - デザイナー:「こんな画面を作りたい」 - AIエージェント:「実装可能です。HTML/CSSを生成しました。さらに、テストコードも作成しました」 - 結果:理想に近い形で実装できる

このように、AIエージェントは単なる「コード生成ツール」ではなく、デザイナーの創造性を最大限に活かすための「全方位型の相棒」として機能しています。

このアプローチが組織にもたらす成果

成長スピードが向上

方向性が見えやすくなり、見込みが薄いアイデアには早期に見切りがつけられる

提案力が強化

動く試作品はそのまま導入先への「提案ツール」として活用でき、説得力が増す

リソース分配が効率化

要件定義書に頼らず方向を絞れるため、リソースが最適に使える

チームとメンバーが成長する

デザインやデータに広く触れる文化が根付き、新しいスキルが身につきやすい

エンジニアとの関係性が変わる

従来の「デザイナー vs エンジニア」から「デザイナー + AIエージェント + エンジニア」の協働へ

組織全体のイノベーション力が向上

各チームがAIエージェントを活用することで、組織全体の創造性と実行力が向上

おわりに

私たちがPoC駆動を採用するのは、単なる手法ではなく「問い→試作→検証→成長」の文化を根付かせるためです。このアプローチが広がることで、EXPERIENCE部は単なる出力チームから、成長に直結するエンジンへと進化していきます。

EXPの3文字に、エクスペリエンスとエクスペリメントを重ねて。

私たちは、動かして試し、フィードバックから学び、それをサービスに還元するループを回し続けます。その成果が導入先や市場にとって新たな価値となり、ひいては組織そのものが成長する原動力となると信じています。