エンタメ業界に20年いた私が異業界でのSaaS開発をUI/UXデザイナー目線で語るお話

デザイナー 前多 美佳
テクノロジーコンサルティング事業部
2023年7月入社

＜プロフィール＞
キャリアスタートから20年以上に渡ってゲーム開発や運営に携わる。UX業務のバリエーションを増やしたいと思い、近年は積極的に業務系ソフトウェアの開発にも関わっている。エンタメ業界出身の強みを生かした「ユーザーフレンドリー」さが強み。
現在は開発デザインセクションの統括的な役割を担い、社内外エンジニアやマネージャー陣とコミュニケーションをとりつつ、円滑な実装のための仕組みづくりに奔走中。

こんにちは！
株式会社リブ・コンサルティングのテクノロジーコンサルティング事業部、プロダクトチームでUI/UXデザイナーをしているマエダと申します。
(……もうすでに自己紹介が長い。こんな長い所属を噛まずに言い切る自信がありません。文章でよかったです。)

コンサルタント会社×SaaS開発

「普通のSaaS開発とは違うの？」「特徴的なことはなに？」この辺りがよく聞かれることであり、そして私たちが業務について説明するときに意識してお話しすることが多いトピックかなと思います。

そんなに特殊じゃない部分について

基本的な要求スキルは一般的なソフトウェア開発と差はないと思っています。
自分はデザイナーなので課題発見〜仮説検証〜工数見積〜ワイヤからFigma実装デザイン作成まで、みたいな感じです。それぞれの工程で各マネージャーやエンジニア達と協力し、FBをもらいながら進めています。
これらの作業自体はどの会社でも行われているのではないでしょうかね。

ユニークな部分について

ここからが本題です。以下に挙げる項目が、私が感じた特徴です。
① マインドセットが強い：
顧客の【成果】が自分たちの成果
② チームを超えた連携がデフォルト：
成果を出すためのチームであり、それはどこまでも拡張する
③ 貪欲に知識を展開していく：
成果を出すためには足りない知見を貪欲に求める＆与える
④ 優先順位を常に考える ：
「誰」に「何」を提供するのか、ということを考えると生まれるルールや仕組み

①〜④は全て「顧客の成果創出のため」に存在しているので、開発職ではありますが、常にマーケットや顧客の状況にアンテナを立てている感じです。

自分がこれらの部分について面白いと感じてコミットできているのは職責と自分の興味の部分で利害が一致しているからです。
どのような部分が利点なのかということを詳しくみていきたいと思います。

課題解決を目指すデザイナーにとって面白い場所

デザイナーと一口に言っても、さまざまなタイプがいると思います。
なので、ここでは自分が面白さを感じている課題解決型のデザイナーの話になります。
『答えは顧客が持っている』というスタンスです。

①「成果」で計る、は忖度なしに現実や仮説の制度を図ることができ、改善サイクルのための重要なヒントとなります。「頑張ったからよかった」みたいなフワッとした総括は存在せず「どのような成果が出たのか」という計測可能な部分で話ができることは、思い込みによる貴重なリソースを浪費することを防いでくれます。

②現在私は「プロダクトチーム」というテック（テクノロジーコンサルティング）事業部の中の１チームに所属しているのですが、事業部には他にも「カスタマーサクセス」「マーケ・セールス」というチームがあります。ここのチームと日常的に双方向的なやり取りが生まれて、上下の別無く同じ土俵で話ができるということが非常に面白く思います。
共有会議などを挟まずに、生の数字に直接アクセスして見られるというのは非常にエキサイティングです。

③ GiveもTakeも常に循環する空間です。 この姿勢は、なかなかな強度のプロフェッショナルさなのではないでしょうか。よく見るのがGiverは常に固定された少人数から、それ以外の人はひたすら享受する側か、なんなら興味ないと無視する（現在抱えている作業の邪魔とすら思う）みたいなシチュエーション、ありませんか？
現職では成果にコミットしているが故に、使える知識を集めることに貪欲な人たちが質問者であり回答者となっており、自分はその関係が非常に好きです。

④ ②で挙げたように様々なチームが「クライアントの成果」という同じゴールに向かって走っています。その際に選ぶルートは、様々な要因により、あるチームにとっては親和性が高く他のチームにとっては馴染みのない方法を選ぶかもしれません。例えば、内勤の開発職だけれど、短パンなどのカジュアルすぎる服装は不可、など。でもそれは 「成果を出すためには最初に顧客から信頼されなければならない」ということから逆算して考える と、理解しやすいのかなと自分は感じています。

これらの内容は、「課題発見」「課題設定」「仮説検証」「仕様策定」「実装」「テスト」という作業サイクルを回すデザイナーにとっては、非常に有効性を感じられるロジックが随所に散りばめられていると思うのです。
計測した数字に仮説を当てはめる時に思い込みにハマらないために、統計的に数字を扱い、ファクトを求めていける環境というものは、自分にもプロダクトにも顧客にもwin-win-winなのかなと噛み締めています。イエーイ。

まとめ

長々と語ってしまいましたが、顧客の情報が直接的なヒアリングから統計的な数字に至るまで手の届くところに揃っている開発環境というのはすごくエキサイティングだよ！ということを私からはお伝えしたいです。
手に入れた環境をどのように生かすか、そんなことを考えるとワクワクしちゃう方にはオススメです！

ここでは書ききれないほど様々なエピソードがあるので、気になった方はカジュアル面談で気軽に聞いていただければ嬉しいです！