スモールチームで素早く価値を届ける──エンジニアのUX設計

こんにちは。モンスターラボでエンジニアリングマネージャーを務める国平です。

「予算が限られているから、まずは少人数で素早く価値検証したい」
「でも、UXデザイナーを最初からアサインする余裕がない…」

新規機能の開発や既存サービスの改善に取り組むとき、こんな悩みを抱えていませんか？

今回は、私がエンジニアでありながらユーザージャーニーマップを活用し、要件定義の段階で認識のズレを発見して、不要な実装を回避できた事例をご紹介します。「エンジニアがUX設計？」と思われるかもしれませんが、スモールチームだからこそ、役割の境界を越えて動くことで大きな成果を生み出せるのです。

企業の情報と案件概要

業界：エンターテインメント
案件内容：既存サービスへの外部SNS連携機能の追加
目的：SNS連携ユーザーへの追加サービス提供を可能にする
体制：MLテックリード2名 ＋ クライアントのプロダクトオーナー（PO）の3名体制
期間：要件定義〜設計：約0.6人月

本プロジェクトは、ファンコミュニティサービスの既存ユーザー向けに、外部SNSとの連携機能を追加するものでした。限られた予算とスケジュールの中で、少人数で素早く価値検証し、開発に進めることが求められていました。

課題：スモールチームでのUX設計をどう進めるか

“専門家不在”で進めざるを得ない現実

プロジェクト開始時、私たちが直面したのは典型的なスモールスタートの課題でした。

・リソースの制約：予算やスケジュールの関係で、UXデザイナーやビジネスデザイナーを初期段階からアサインできない
・認識齟齬のリスク：「SNS連携機能」という言葉だけでは、具体的にどんな体験をユーザーに提供するのか、関係者間で認識がズレる可能性がある
・手戻りへの不安：曖昧なまま開発を進めると、後から「思っていたのと違う」となるリスクが高い

とはいえ、「専門家がいないから仕方ない」と諦めたり、準備不足のまま進めては、プロジェクトの成功はおぼつきません。

目指したのは「エンジニアによるUX設計」

そこで私たちが目指したのは、エンジニアが役割の境界を越えてUX設計に踏み込むというアプローチでした。

モンスターラボには「Be Borderless」という価値観があります。これは、職種や役割の境界（Border）を越えて働くことを推奨する考え方です。
エンジニアだからといって技術領域だけに閉じこもるのではなく、ユーザー価値を考え、顧客とのコミュニケーションも積極的に担う──そんな働き方を実践することにしました。

解決策：エンジニアがユーザージャーニーマップを描く

ユーザージャーニーマップとは？

ユーザージャーニーマップとは、ユーザーがサービスを利用する際の体験を時系列で可視化したものです。各タッチポイントでのユーザーの行動、感情、思考を整理することで、サービスが提供する価値を明確にできます。

通常はUXデザイナーや企画職が作成することが多いですが、専門的なデザインスキルがなくても取り組めるのがポイントです。
大切なのは「ユーザーの行動を具体的に描く」こと。これさえできれば、エンジニアでも十分に活用できます。
特に今回は、モンスターラボとしても長く関わってきたサービスに対する機能追加であり、サービスやユーザーに対する理解が深かったため、エンジニア主導での作成が可能でした。

クライアントPOと2人で描いた「ユーザーの行動シナリオ」

私はクライアントPOと2人で、以下のような問いを立てながらユーザージャーニーマップを作成していきました。

・ユーザーはどのタイミングでSNS連携を行うのか？
・連携後、どのような行動を取るのか？
・その行動によって、どのような価値を感じるのか？

オンラインのホワイトボードツールを使いながら、ユーザーの行動を1つずつ時系列で書き出していきます。すると、仕様に対する重大な気づきがありました。

発見：「SNS連携」の認識が全然違っていた

モンスターラボの認識：「SNSでログインできるようにしたい」

当初の仕様として、「ユーザーがSNSアカウントと連携できる」と説明を受けていました。

これを受けて、私は「SNS連携 = SNSアカウントでサービスにログイン/新規登録できるようにする機能」と解釈していました。つまり、「SNS連携 ＝ ログイン手段の追加」と捉えていたのです。

実際に必要だったのは「アカウントの紐づけ」

しかし、クライアントPOとともにユーザーの行動を具体的に描いていくと、違う姿が見えてきました。

1. ユーザーは本サービスの既存アカウントでログインする
2. マイページでSNSアカウントを連携（紐づけ）する
3. 連携したSNS上でSNS連携したユーザーだけが利用できる追加機能を利用する

つまり、ユーザーはSNSアカウントで我々が開発しているサービスにログイン/新規登録する必要はなく、既存アカウントとSNSアカウントを紐づけるだけでよかったのです。

認識のズレが招くはずだった「不要な実装」

もしこの認識のズレに気づかないまま開発を進めていたら、どうなっていたでしょうか。

SNSログイン機能の実装に必要な作業：

・OAuth認証フローの設計・実装
　・SNSプロバイダーごとの対応
　・ログイン時の遷移
　・新規登録時の遷移

・既存アカウントとの統合処理（同一メールアドレスの場合の処理など）
　・アカウント重複の制御・発生時の解消

これらは本来不要な機能でした。ユーザージャーニーマップを描いたことで、開発着手前にこの認識のズレを発見し、シンプルな「アカウント連携機能」に焦点を絞ることができました。

成果：シンプルな設計で開発工数を削減 

定量的な成果

認識統一を早期に行ったことで、要件定義にかかる期間を約半分に短縮。さらに、不要な機能の実装を回避したことで、開発工数も大幅に削減できました。

定性的な成果

・顧客との信頼関係構築：「ちゃんと理解してくれている」という安心感を顧客に提供できた

・チームの自信：エンジニアでもUX設計に貢献できるという成功体験を得られた

・再現可能なプロセス：今後のスモールスタート案件でも活用できる手法を確立

まとめ：スモールスタートを成功させる3つのポイント

今回の経験から、スモールチームで素早く価値提供するためのポイントを3つにまとめました。

1. 役割の境界を越える（Be Borderless）

「これはデザイナーの仕事」「これはPMの仕事」と線引きせず、価値提供に必要なことは自ら実践する姿勢が重要です。エンジニアがUX設計に踏み込むことで、専門家のアサインを待たずにプロジェクトを前に進められます。

2. 可視化でコミュニケーションする

ユーザージャーニーマップは、言葉だけでは伝わりにくい認識のズレを明らかにします。具体的なユーザー行動を描くことで、関係者全員が同じ絵を見ながら議論できます。「SNS連携」という曖昧な言葉ではなく、「ユーザーがマイページでSNSを紐づける」という具体的な行動で認識を統一しましょう。

3. 開発前に認識を統一する

後から認識のズレが発覚すると、手戻りコストは膨大になります。開発に着手する前に、ステークホルダー間の認識を統一することが、結果的にプロジェクト全体のスピードを上げます。「急がば回れ」の精神で、要件定義に時間を投資しましょう。

おわりに

もちろん、これは「UXデザイナーやビジネスデザイナーが不要」という話ではありません。予算や時間の制約があるから要求された機能だけを実装する、というスタンスでもありません。
スモールスタートの段階ではエンジニアが越境してUX設計を担い、ビジネスがグロースしてきたタイミングでUXデザイナーのアサインを提案したり、サービス全体のロードマップ策定を支援したり──フェーズに合わせて伴走できることが、私たちの強みだと考えています。

「スモールスタートだからUX設計は省略」ではなく、「スモールスタートだからこそ、エンジニアがUX設計に踏み込む」ことで、本当に必要なものを見極め取り組むことができました。