劇的な意識改革！フロントエンドエンジニアがプロダクトマインドを獲得した学習過程

2025年5月26日

技術的には完璧だったはずのプロジェクトがリリース後にユーザーから厳しい評価を受け、大きな衝撃を受けました。それまでの私は最新の React フレームワークを使い、パフォーマンスを最適化し、コードの品質にこだわっていたのに、なぜ失敗したのか理解できませんでした。この失敗体験から始まった私のプロダクトマインド獲得への道のりと、それによって次のプロジェクトで達成できた成功について共有します。技術だけを追求していた私が、ユーザー価値を中心に考えるエンジニアへと変わった過程は、多くの気づきをもたらしました。

背景と課題

私が担当したのは、社内で注目されていた Web アプリケーションのリニューアルプロジェクトでした。当時の私は、技術的な観点からのみプロジェクトを捉えていました。

技術スタックを優先した意思決定

最新の React 18 と Next.js を採用し、Tailwind CSS でスタイリングを行い、状態管理には Redux を導入しました。これらの選択は、以下の理由から行われました：

私自身が学びたかった最新技術を試せる機会だった
パフォーマンス指標が良好だった
チーム内での技術的な評判が高かった

しかし、これらの選択がユーザーにとって本当に価値があるのかという視点は欠けていました。

jsx// 技術的には美しいが、ユーザーにとっては複雑すぎたコンポーネント構造
const ProductPage = () => {
  const dispatch = useDispatch();
  const { product, loading, error } = useSelector(
    (state) => state.product
  );
  const { user } = useSelector((state) => state.user);

  // 複雑な状態管理とデータフェッチング
  useEffect(() => {
    dispatch(fetchProductDetails(productId));
    dispatch(fetchRelatedProducts(categoryId));
    dispatch(fetchUserPreferences());
  }, [dispatch, productId, categoryId]);

  // 多数の条件分岐
  if (loading) return <ComplexSkeletonLoader />;
  if (error) return <ErrorBoundary error={error} />;

  return (
    <ProductLayout>{/* 多機能で複雑なUI */}</ProductLayout>
  );
};

ユーザーテストの軽視

プロジェクトでは、開発の効率を優先し、ユーザーテストを十分に行いませんでした。

デザインレビューは行ったが、実際のユーザーの反応は確認せず
社内関係者からのフィードバックのみで判断
「技術的に正しい」ことを過信

当時の私は「優れたコードを書けば、自然と優れたプロダクトになる」と思い込んでいました。しかし現実はそう単純ではありませんでした。

機能過多による複雑化

私たちは「できること」に焦点を当て、以下のような問題を引き起こしました：

一画面に多くの機能を詰め込みすぎた
ユーザーの本当のニーズを理解せずに機能を追加
技術的な「かっこよさ」を優先し、複雑なアニメーションや遷移を実装

プロダクト目標の認識不足

最も根本的な問題は、私がプロダクトの目標を明確に理解していなかったことでした：

KPI や成功指標を意識せずに開発
ビジネス要件を技術要件に変換する過程でのミスコミュニケーション
「なぜこの機能が必要か」という本質的な問いかけの欠如

試したこと・実践内容

失敗から学ぶために、私は様々な取り組みを行いました。

失敗分析ワークショップの実施

まず、チーム全体で失敗の原因を客観的に分析するワークショップを開催しました：

ユーザーフィードバックを全て書き出し、カテゴリ分け
各問題の根本原因を「5 つのなぜ」で掘り下げる
開発プロセスの各段階で何が欠けていたかを特定

このワークショップで明らかになったのは、私たちがユーザーの課題解決ではなく、技術的な課題解決に集中していたことでした。

UX デザイン基礎の学習

私は UX デザインの基本を学ぶことにしました：

「Don't Make Me Think」「UX リサーチの道具箱」などの書籍を読破
オンラインコースでユーザーインタビューの手法を学習
デザイナーとペアで作業する時間を意識的に増やす

jsx// Before: 技術的に洗練されているが使いにくいフォーム
<form onSubmit={handleSubmit}>
  <div className="grid grid-cols-2 gap-4">
    <Input name="firstName" label="First Name" validations={[...]} />
    <Input name="lastName" label="Last Name" validations={[...]} />
    {/* 複雑なバリデーションと状態管理 */}
  </div>
  <Button type="submit" disabled={!isValid}>Submit</Button>
</form>

// After: ユーザー体験を考慮したシンプルなフォーム
<form onSubmit={handleSubmit}>
  <FormField
    name="name"
    label="お名前"
    placeholder="例：山田太郎"
    helpText="姓名をスペースなしで入力してください"
  />
  {/* ユーザーの入力負担を減らすシンプルな設計 */}
  <Button type="submit">送信</Button>
</form>

A/B テスト導入への貢献

次のプロジェクトでは、A/B テストを積極的に導入することを提案しました：

フロントエンド実装に A/B テストのフレームワークを組み込む
計測可能な仮説を立てる習慣を身につける
データ分析チームと協力し、結果の解釈方法を学ぶ

例えば、商品ページの「購入ボタン」のデザインとワーディングについて：

jsx// A/Bテストの実装例
function BuyButton({ productId, variant }) {
  const trackPurchase = () => {
    // クリックイベントを計測
    analytics.track('purchase_click', {
      productId,
      variant,
    });
  };

  return variant === 'A' ? (
    <button
      className='bg-blue-600 text-white px-4 py-2 rounded'
      onClick={trackPurchase}
    >
      今すぐ購入
    </button>
  ) : (
    <button
      className='bg-green-500 text-white px-6 py-3 rounded-lg font-bold'
      onClick={trackPurchase}
    >
      カートに追加する
    </button>
  );
}

これにより、ユーザーの実際の行動データに基づいた意思決定ができるようになりました。

ユーザーストーリーを起点とした開発

開発の起点をコードからユーザーストーリーに変更しました：

機能実装前に「この機能は誰のどんな問題を解決するのか」を明確化
ストーリーマッピングセッションに積極的に参加
開発タスクをユーザーストーリーに紐づける方法を改善

気づきと変化

これらの取り組みを通じて、私の考え方や行動には大きな変化がありました。

実装前の問いかけの変化

コードを書く前に、以下の問いを自分に投げかけるようになりました：

この機能は本当に必要か？
もっとシンプルな解決方法はないか？
ユーザーはこの機能をどのように使うか？
この実装はビジネス目標にどう貢献するか？

以前は「どう実装するか」だけを考えていましたが、「なぜ実装するか」を考えるようになりました。

コードレビュー基準の拡張

技術的な側面だけでなく、ユーザー体験の観点からもレビューするようになりました：

Before	After
「このコードは効率的か」	「この UI はユーザーにとって直感的か」
「バグはないか」	「ユーザーが混乱する可能性はないか」
「コーディング規約に従っているか」	「ビジネス要件を満たしているか」

計測指標への関心向上

以前は技術的な指標（ビルド時間、バンドルサイズなど）にしか興味がありませんでしたが、以下のような指標に注目するようになりました：

コンバージョン率
ユーザーの滞在時間
離脱率
機能の使用率

これにより、自分の仕事の成果を技術的な完成度だけでなく、ビジネスインパクトで測れるようになりました。

機能のプライオリタイゼーション能力

限られたリソースの中で何を優先すべきかを判断する能力が向上しました：

コストと効果のバランスを考慮した意思決定
MVP の考え方を取り入れた段階的な実装
「素晴らしいあれこれ」より「必要十分なこれ」を優先

他のチームで試すなら

私の経験から、他のチームでも実践できそうなアプローチをいくつか紹介します。

失敗から学ぶ文化の醸成法

プロジェクトの失敗を建設的に分析する文化を作るには：

「誰が」ではなく「何が」問題だったかに焦点を当てる
失敗を隠さず、オープンに議論できる心理的安全性を確保する
「学びのログ」を残し、同じ失敗を繰り返さない仕組みを作る

重要: 失敗を責めるのではなく、共有の学びに変えることで、チーム全体の成長につながります。

プロダクト視点を育てるワークショップ案

エンジニアのプロダクトマインドを育てるワークショップのアイデアです：

ユーザーペルソナ作成: 実際のユーザーデータを基にペルソナを作成し、その視点でプロダクトを評価する
ジャーニーマップ体験: 自社のプロダクトをユーザーとして使い、感じた不便や疑問を記録する
競合分析: 競合製品を使い、良い点・悪い点を分析して自社製品に活かす方法を議論する

小さく始める検証アプローチ

大きな変更を一気に行うのではなく、小さく始めて検証するアプローチ：

最小限の機能で検証可能なプロトタイプを作成する
限定されたユーザーグループで検証する
フィードバックを集めて分析し、次のイテレーションに活かす

jsx// シンプルなプロトタイプの例
function FeaturePrototype() {
  const [feedback, setFeedback] = useState('');
  const [submitted, setSubmitted] = useState(false);

  const handleSubmit = (e) => {
    e.preventDefault();
    // フィードバックを送信
    logUserFeedback(feedback);
    setSubmitted(true);
  };

  return (
    <div className='p-4 border rounded'>
      <h2>新機能プロトタイプ</h2>
      {!submitted ? (
        <form onSubmit={handleSubmit}>
          <p>この機能はいかがでしたか？</p>
          <textarea
            value={feedback}
            onChange={(e) => setFeedback(e.target.value)}
            className='w-full p-2 border'
          />
          <button
            type='submit'
            className='mt-2 px-4 py-2 bg-blue-500 text-white'
          >
            フィードバックを送信
          </button>
        </form>
      ) : (
        <p>ありがとうございました！</p>
      )}
    </div>
  );
}