エンジニアのためのデザイン思考実践：開発を成功に導く初期段階の関わり方
はじめに：なぜ開発エンジニアがデザイン思考の初期段階に関わるべきか
サービス開発において、デザイン思考はユーザー中心のアプローチを推進するための強力なフレームワークです。多くの開発エンジニアの皆様は、プロトタイピングやアイデアの実装フェーズからデザイン思考に関わることが多いかもしれません。しかし、デザイン思考の初期段階である「共感（Empathize）」や「定義（Define）」フェーズに開発エンジニアが積極的に関わることは、サービス開発の成功確率を高める上で非常に重要となります。
この初期段階でユーザーの本当の課題やニーズを深く理解することは、開発の方向性を定め、手戻りを減らし、最終的にユーザー価値の高いサービスを創出することに直結します。技術的な知見を持つ開発エンジニアがこのプロセスに加わることで、実現可能性の観点から早期にフィードバックを提供したり、技術的な制約の中での最適なソリューション発想を支援したりすることが可能になります。
本稿では、開発エンジニアがデザイン思考の初期段階にどのように関わり、その活動を開発にどのように活かせるのか、具体的な手法やヒントをご紹介します。
「共感」フェーズにおける開発エンジニアの貢献
「共感」フェーズの目的は、サービスやプロダクトを利用する人々（ユーザー）を深く理解することです。彼らの行動、思考、感情、そして抱える課題やニーズを多角的に捉えます。開発エンジニアは、このフェーズで以下のような貢献が可能です。
1. ユーザーインタビューへの参加
単なるオブザーバーとしてではなく、積極的にインタビューに参加することをお勧めします。
- 聞き手として: ユーザーの言葉から直接情報を得ることで、仕様書や要件定義だけでは見えにくい背景や感情を理解できます。技術的な視点から、ユーザーが抱える課題の根本原因について、より深い質問を投げかけることも可能です。
- 観察者として: ユーザーの非言語的な情報（表情、声のトーン、操作方法など）を観察し、メモを取ります。後でインタビュー記録を見返す際に、具体的なシーンを思い出す助けとなります。
インタビューを通じて得た生の声や一次情報は、その後の課題定義やアイデア発想において、チーム共通のリアルなユーザー像を形成する基盤となります。
2. ユーザー観察やフィールドワークへの参加
ユーザーが実際にサービスを利用している現場や、関連する活動を行っている環境に立ち会うことで、彼らの行動文脈や隠れたニーズを発見できることがあります。例えば、特定のツールをどのように使っているか、どのような状況で困っているかなどを直接観察します。開発エンジニアは、システム的な視点から、ユーザーの非効率な作業や技術的なボトルネックとなっている可能性のある部分に気づきやすい利点があります。
3. 既存データからのインサイト抽出
ユーザーインタビューや観察が難しい場合でも、既存のデータは活用できます。
- サービスログ分析: ユーザーの利用行動パターン、離脱ポイント、頻繁に行われる操作などを分析し、仮説を立てます。
- 問い合わせデータ分析: サポート窓口への問い合わせ内容やFAQの閲覧状況から、ユーザーがどの機能でつまずいているか、どのような課題を抱えているかを把握します。
- アンケート結果分析: ユーザーの満足度、不満点、要望などを定量・定性的に分析します。
開発エンジニアはこれらのデータソースへのアクセスや分析スキルを持つことが多いため、データからユーザーの「声なき声」を聞き取り、共感の材料とすることができます。
4. 共感マップ（Empathy Map）の作成・活用
チームで収集したユーザー情報を整理し、共有するために共感マップを作成します。「言う」「考える」「感じる」「行う」といった要素ごとにユーザーの情報を書き出し、ペルソナ像を具体化します。開発エンジニアもこのプロセスに積極的に参加し、技術的な視点やデータから得た知見を反映させることで、より多角的でリアルなユーザー像を構築できます。
「定義」フェーズにおける開発エンジニアの貢献
「定義」フェーズでは、「共感」フェーズで得られたインサイトを基に、ユーザーが抱える本質的な課題を明確に定義します。解決すべき問題を具体的に定めることが、その後の適切なソリューション発想につながります。
1. ペルソナ作成への参加と技術的制約からの視点提供
ユーザー像を具体化したペルソナ作成において、開発エンジニアは技術的な実現可能性やシステムの振る舞いという観点から貴重な意見を提供できます。例えば、特定のペルソナが想定する利用シーンにおいて、現在のシステム性能やアーキテクチャではボトルネックが生じないか、といった視点からのフィードバックは、ペルソナの解像度を高め、後工程での手戻りを防ぎます。
2. 課題ステートメントの深掘り
ユーザーの課題を「〇〇（ユーザー）は△△（ニーズ）を必要としている、なぜなら□□（インサイト）だからだ」のような形式で定義する際に、その「なぜなら」の部分を深く掘り下げる手助けをします。技術的な背景やシステム構成の知識を活かし、ユーザーの課題がなぜ発生しているのか、その構造的な原因を特定することで、より本質的な課題解決につながる定義が可能になります。
3. Why-How-What思考
「Why（なぜその問題を解決するのか、目的は何か）」「How（どのように解決するのか、アプローチは）」「What（何を開発するのか、具体的な機能は）」という思考フレームワークは、課題とソリューションの関係性を整理するのに役立ちます。開発エンジニアは、特にWhy（目的）とWhat（機能）の間で、How（技術的なアプローチ）の観点から議論を深めることができます。目的達成のためにどのような技術要素が必要か、または現在の技術でどのようなアプローチが可能か、といった視点は、現実的かつ効果的な課題定義につながります。
4. 問題定義ワークショップへの参加・リード
チームで課題定義を行うワークショップにおいて、開発エンジニアは積極的に議論に参加し、技術的な観点からの意見を提示します。場合によっては、ファシリテーターとしてワークショップをリードし、技術的な実現可能性を踏まえた上で、チームが最も重要な課題に焦点を当てられるよう導く役割を担うことも可能です。
実践における課題と克服のヒント
デザイン思考の初期段階に開発エンジニアが関わる上で、いくつかの課題に直面することがあります。
1. 時間がない問題への対応
日々の開発タスクに追われ、デザイン思考の活動に時間を割くのが難しい場合があります。
- ヒント:
- 短時間ワークショップの導入: 長時間拘束されるワークショップではなく、1〜2時間で区切った短時間のワークショップを定期的に実施します。
- 既存データの活用: ユーザーインタビューなどが難しい場合は、既存のログや問い合わせデータを分析することから始めます。これは比較的短時間で取り組めます。
- スプリント内での活動時間確保: アジャイル開発のスプリント計画時に、デザイン思考関連の活動（インタビュー、データ分析、定義ワーク）に時間を確保するタスクを明示的に盛り込みます。
2. 非デザイナーとの共通理解の醸成
デザイン思考特有の用語や概念について、チームメンバー（特に非デザイナー）との間で理解の差が生じることがあります。
- ヒント:
- 用語のすり合わせ: デザイン思考のワークショップなどを始める前に、使用する用語（ペルソナ、CJM、インサイトなど）について簡単な説明会や資料共有を行います。
- 共通ツールの活用: MiroやFigJamなどのオンラインホワイトボードツールを活用し、情報を視覚的に共有・整理します。これにより、テキストベースのコミュニケーションでは伝わりにくいニュアンスや関係性が明確になります。
- 具体的な事例共有: 自社のサービスや過去の開発事例を例に挙げながら説明することで、抽象的な概念への理解を深めます。
3. 初期段階で得たインサイトを開発にどうつなげるか
「共感」「定義」フェーズで得たユーザー理解や課題定義が、その後のアイデア発想や開発プロセスにうまく反映されないことがあります。
- ヒント:
- ドキュメンテーションと共有: 得られたインサイト、ペルソナ、課題定義などを分かりやすくドキュメント化し、チーム全体がいつでも参照できる場所に保管します。Confluenceや共有ドライブなどが有効です。
- 定期的な共有会: 開発チーム内で定期的に、デザイン思考の活動で得られた気づきやユーザーの声を共有する時間を設けます。
- ユーザーストーリーへの落とし込み: 定義された課題やニーズを基に、具体的なユーザーストーリーを作成します。「〇〇（ユーザー）は△△（目的）を達成したい、なぜなら□□（理由）だから」という形式で記述することで、開発タスクとユーザー価値を結びつけやすくなります。
まとめ
サービス開発の初期段階である「共感」と「定義」フェーズに開発エンジニアが積極的に関わることは、表面的な仕様に囚われず、ユーザーの真の課題解決を目指す上で不可欠です。ユーザーインタビュー、観察、データ分析を通じてユーザーを深く理解し、そのインサイトを基に本質的な課題を定義するプロセスに技術的知見を持ち込むことで、より実現可能で効果的なソリューションの発想につながります。
時間的な制約やチーム内の共通理解といった課題は存在しますが、短時間での実践、共通ツールの活用、得られたインサイトの丁寧な共有といった工夫により克服は可能です。デザイン思考の初期段階への積極的な参画を通じて、開発エンジニアの皆様がユーザー中心の開発文化を牽引し、サービスの成功にさらに貢献されることを願っております。