脱炭素SaaSのプロダクトデザイナーに欠かせない“2つ”の役割とは
こんにちは、e-dash編集部です。
「e-dash」のクラウドサービス開発を手がけるプロダクト開発部では、12月1日からクリスマスの25日に向けて毎日1本ずつブログ記事を投稿するe-dash Advent Calendar 2024を実施しています。
本日ご紹介するのは、Advent Calender 22日目の、プロダクト開発部 Kazuさんによる記事です。
＊＊＊＊＊＊
はじめまして、e-dashでプロダクトデザインを担当しているKazuです。
当社では「脱炭素を加速する」をミッションとして、CO2排出量を可視化するのためのSaaSプロダクトや排出量の報告や開示、削減に向けたコンサルティングサービスを提供しています。
事業活動で使用したエネルギー関連の請求書を企業にアップロードしてもらい、簡単かつ正確にCO2排出量を可視化する。そして、可視化したデータをもとに適切なソリューションを提案し、実行に繋げる。結果としてお客様の脱炭素を加速させ、ビジネスチャンス獲得やリスク低減に繋げるのが私たちの使命です。
私が所属するプロダクト開発部ではそのミッションを達成するために日夜開発に励んでいます。
その中でのプロダクトデザイナーの役割は何か？
リサーチからコンポーネントの運用など、プロジェクトによって立ち位置は変わりますが、その中から代表的なものとして「プロジェクトの解像度を上げる」と「人間が扱いやすいものにする」の2つを挙げながら、普段どんなことをしているのかのご紹介ができたらと思います。
🔍プロジェクトの解像度を上げる
はじめにプロジェクトの要件に対して形を与えることで解像度を高めていき、議論を進めていくための役割を説明します。
たとえば、現在社内で使用するための管理画面のリプレイスを行うプロジェクトが進行しています。このプロジェクトでは元々使っていたアプリケーションのパフォーマンスを向上させ、業務の効率化、安定性を高めることが主な目的です。はじめに管理画面を使用するスタッフにヒアリングをし、既存のフローの洗い出しやどんな課題があるのかを伺っていきました。
そこで挙がった課題として、業務を行う中で確認するべき画面が点在していることがありました。
そのため、「画面の往来を減らしフローをシンプルにする」ことを念頭に置き、デザインの改善を進めています。
管理画面で扱う主要なコンテンツとして「請求書データ」があります。ユーザーによってアップロードされた請求書はOCRを用いてデータ化されますが、請求書の種類は電力小売業者だけでも全国で700社程度あり、請求書の内容は同じであっても、フォーマットは各社ばらばらです。そのため人力で管理する部分が出てくるのですが、多様なフォーマットに対しても同じ画面で表示できるような工夫をしました。
また、請求書データと登録後に作成されるデータは別のものですが、それらを進行状況という切り口から同じ画面でタブで分け、社内での進行状況に合わせて対象のデータが移行していくような形で整理していきました。
叩き台としてのワイヤーフレームからプロトタイプに至るまで、チームで議論をしながら開発が可能なレベルまでブラッシュアップをして進めていきました。
このように、e-dashでは、予め決められた仕様をもとにFigmaを操作するのではなく、課題に対してどう解決するかをPdM（プロダクトマネージャー）と二人三脚で考えていくことができます。この点は、デザイナーとして魅力的な環境だと感じています。
一方で、デザインはデザイナーが全てを担うものではなく、デザイナー、チーム、ステークホルダーがそれぞれの視点を掛け合わせることで立ち上がってくるものだということも強調しておきたいです。（※特にMVP開発では開発コストを抑えて仮説検証を行っていく面が強いので、フィージビリティ観点から仕様やデザインが決定されていくケースが多い）
また別のケースとして、弊社に所属するドメイン知識のエキスパートであるソリューション＆アドバイザリー部（以下S&A）のメンバーとのアドバイスを受けながらデザインの解像度を上げていくこともあります。
直近の例だと、カーボンオフセット（削減したCO2排出量を「排出権」という形で取引し、埋め合わせを可能にするもの）に関する証書のアップロード画面をリニューアルするプロジェクトがあり、PdM主導の元、S&Aにヒアリングし叩き台を作成していきました。
社内にはドメイン知識を得るためにGX検定の費用を会社が負担してくれる制度もあり、開発メンバーも個々人の努力でキャッチアップしています。しかし、実用に耐えうるプロダクトを作っていく上では言うまでもなくエキスパートの力が必要不可欠です。
レビューを重ねる中で、CDPに準拠した適切な用語を提案してもらうことをはじめとして、実際のユースケースで必要な要件（たとえばオフセット量を年をまたいで適用させたり、適用量の一部を償却する）も洗い出していくことができました。それに合わせUIにおいても画面をステップに分けて分岐させるなど、ユーザーの多様な状況に対応するための工夫をしていきました。
余談になりますが、社内のSlackにドメイン知識豊富なエキスパートに質問を投稿することができる専門チャンネルがあります。また、S&Aチームのナレッジを学習させたSlackbotがあり、ここから回答を得ることも…！
🎨人が扱いやすいものにする
もう1つの役割として「人が扱いやすいものにする」を挙げたいと思います。
これはプロジェクトが進んでいく中で立ち上がってきた意匠を人が触れた時に違和感の少ない状態に調整することです。こうやってあえて回りくどく表現しているのは、デザイン自体はソフトの使い方さえ習得しなくても、テンプレートや生成AIを活用して誰でも作れる現状があるからです。しかし現時点ではそれらのアウトプットにはある種の「固さ」があり、人にフィットする形にはまだまだ隔たりがあると感じています。
特に脱炭素という専門性の高いドメイン知識を扱うことから、ユーザーが操作する上で学習が必要である面が少なくないといえます。「メールを送る」「ECサイトで商品を購入する」など日常から触れるアプリケーションには既に学習済みのメンタルモデル（デザインにおいては狭義的にシステムや製品について心の中に構築する抽象的なイメージのことを指します）があるので、初めて使用するサービスだったとしても操作に困ることは少ないでしょう。
しかし、こうしたBtoBアプリケーションについては、ユーザーにとっては未知の連続です。そのため、いかに学習コストを下げ、扱いやすいものにできるかが満足度に直結するのです。なのでデザイナーはあの手この手でこの問題を解決しようとします。
コントラストの最も高い箇所に人間の目線が誘導されるので重要な情報を配置する。同じ情報は近い位置にグルーピングする。色で優先度をコントロールする。専門用語は補足する。無機質さを回避するためにアイコンやイラストを活用する。情報量を減らしてノイズを減らす。逆に情報量を増やして一覧性を高める、などなど。
OOUIをはじめとしたデザインの手法論やトレンドは数あれど、結局は銀の弾丸は無く、泥臭い創意工夫の積み重ねが人にフィットするものを作る唯一の道だと信じています。
また、特に留意していることとして、「あの手この手」が本当に伝わっているか？を疑うことです。たとえば、とある新機能が「タブ」として既存の画面に追加されたことがありました。問題となったのはそのタブの順序です。開発側の意向としては、まずその新機能に触れてほしいという理由から最も左（＝開いた時に初めに表示される画面）に配置したと聞いています。
しかしカスタマーサクセスのメンバーから「その新機能は補助的な位置付けであり、タブの位置は適切でない」といった意見がありました。とても的を得た意見だと感じたと同時に、開発側がいくらロジカルに考えてもユーザーにとってはそんな事情は全く関係ないことを改めて痛感しました。
ダニエル・カーネマンの名著『ファスト＆スロー』では人間が犯しやすい先入観による意思決定の歪みについて記されていますが、私もデザインする上でバイアスは避けれないことを頭の片隅に置くようにしています。（例：利用可能性ヒューリスティック。記憶に残っている情報を優先的に頼って判断し、重要性を高く見積もる傾向）
こうした配慮の1つ1つは地味ではありますが、積み重ねによってユーザビリティが向上していくのは間違いありません。こうした取り組みによって、「e-dash」を「使いやすさ」を決め手に選んでもらえるようなプロダクトに育てていくのがプロダクトデザイナーとしての目標です。
長々と書いてしまいましたが、普段デザイナーって何やっているんだろうという理解の助けになれば嬉しいです。最後までお読みいただきありがとうございました。
引き続き、e-dash advent calendar 2024をお楽しみ頂けましたら幸いです。
【採用情報】
e-dash開発チームは現在一緒にはたらく仲間を募集中です！ 同じ夢について語り合える仲間と一緒に、環境問題を解決するプロダクトを作りませんか？