デザイン思考「共感」「定義」フェーズ：エンジニアリング視点で課題の本質に迫る実践手法
サービス開発においてデザイン思考を取り入れる際、エンジニアはしばしば「実装」や「技術的実現性」のフェーズでの関わりが中心と考えがちです。しかし、デザイン思考の初期段階である「共感（Empathize）」や「定義（Define）」のフェーズに、エンジニアリングの視点を積極的に活用することは、ユーザーの真の課題を見つけ出し、より価値の高いサービス開発に繋げる上で非常に重要です。
この記事では、エンジニアが自身の技術的知見を活かし、デザイン思考の共感・定義フェーズの質を高めるための実践的なアプローチについてご紹介します。
エンジニアリング視点が共感・定義フェーズにもたらす価値
エンジニアはシステム構造、技術の可能性、運用上の制約など、非技術者とは異なる視点を持っています。この技術的視点は、ユーザーへの共感を深め、課題を定義する際に以下のような価値をもたらします。
- 隠れた課題の発見: ユーザー自身も気づいていない、システム的なボトルネックや技術的な制約に起因する不満やニーズを発見しやすくなります。
- 課題の根本原因特定: ユーザーが訴える表面的な不満の、技術的な側面からの根本原因をより正確に分析できます。
- 実現可能性を考慮したインサイト: 技術的な制約やトレンドを理解しているため、得られたインサイトが現実のサービスとして実現可能か、あるいは新しい技術で解決可能かといった見通しを持ちながら分析を進められます。
- 新しい解決策の着想: 特定の技術に関する深い知識が、従来とは異なる角度からの課題解決のアイデアや、新しいユーザー体験の可能性に気づかせてくれます。
共感フェーズにおけるエンジニアの実践手法
ユーザーへの共感を深めるために、エンジニアリングの視点をどのように活かせるでしょうか。
1. ユーザーインタビューにおける技術的深掘り
単にユーザーの行動や感情を聞くだけでなく、技術的な側面に関する質問を織り交ぜてみましょう。
- 具体的な質問例:
- 「この作業で使っているツールやシステムの、特にここが使いにくいと感じる点はどこですか？ どのような技術的な問題が考えられますか？」
- 「このサービスを利用する際に、ネットワーク環境やデバイスの性能に起因する不満はありますか？」
- 「普段お使いの〇〇（競合サービスや関連技術）で、技術的に『すごい』と感じる点、または『なぜこうなっていないのだろう』と思う点はありますか？」
エンジニアがこうした視点から質問することで、非エンジニアのインタビュー担当者だけでは気づけない技術的な課題や、ユーザーの技術リテラシーのレベル、技術に対する期待などを引き出せる可能性があります。
2. 観察・フィールド調査でのシステム的着眼点
ユーザーがサービスを利用する様子や、業務を行う環境を観察する際に、システム的なボトルネックや非効率なプロセスに注目します。
- 着眼点:
- 複数のツールやシステム間でのデータの受け渡しに手間取っていないか
- ネットワーク遅延や処理待ちによってユーザーのフラストレーションが高まっていないか
- 特定のデバイスやOS環境でのみ問題が発生していないか
- ユーザーがシステムの「裏側」を推測して、非効率な回避策を取っていないか
実際にユーザーの環境に身を置くことで、設計段階では見落としがちな技術的な「現場のリアル」を肌で感じ取ることができます。
3. 既存サービス・技術の技術的分析
ユーザーが現在利用している、あるいは競合となるサービスや技術について、表面的なUI/UXだけでなく、その技術的な仕組みや構成を推測し分析することも有効です。
- 分析例:
- 「なぜこのサービスは高速なのだろうか？ （特定のキャッシュ戦略や非同期処理など）」
- 「この機能を実現するには、どのような技術的なハードルがあるだろうか？」
- 「この競合サービスは、おそらく〇〇という技術を使っている。その技術の特性上、ユーザーはこのような課題に直面しているのではないか？」
技術的な視点からの分析は、既存サービスの強み・弱み、そしてユーザーが抱える潜在的な不満を深く理解する手助けとなります。
定義フェーズにおけるエンジニアの実践手法
共感フェーズで得られたインサイトを、ユーザーの課題として明確に定義する段階でも、エンジニアリングの知見は役立ちます。
1. 技術的実現性を踏まえた課題のフレーミング
発見されたインサイトを課題として定義する際、技術的な観点からその実現可能性や難易度を考慮に入れます。
- 例: ユーザーが「もっとサクサク動いてほしい」と感じている場合、単に「パフォーマンスが遅い」という課題定義だけでなく、「特定の処理におけるデータベースの負荷増大により、ユーザーは待ち時間に不満を感じている」のように、技術的な要因を含めて定義することで、その後のアイデア発想や解決策検討が具体的なものになります。
- 同時に、現在の技術で解決が困難な課題なのか、それとも既存技術の組み合わせで解決できるのかといった見立てを持つことで、より現実的かつインパクトのある課題設定が可能になります。
2. システム構造からの課題の根本原因特定
ユーザーの課題が、システムの特定の構造や設計に起因している場合、エンジニアはその根本原因を特定しやすくなります。
- ユーザーの行動パターンやシステムログなどを分析し、技術的な観点から課題の発生メカニズムを解き明かします。「なぜユーザーはこのエラーに頻繁に遭遇するのか？」「この操作で必ずフリーズするのはなぜか？」といった問いに対し、システム構造の知識を持って臨むことで、より深いレベルでの課題定義ができます。
3. 技術的可能性から新しい課題領域を発見
最新の技術トレンドや、自社が持つ技術資産を理解しているエンジニアは、既存の課題解決だけでなく、「このような技術が可能になったことで、ユーザーはもしかしたらこんな新しいことができるようになるのではないか？ それを阻害しているものは何か？」といった視点から、新しい課題領域を発見する可能性があります。
- 例えば、音声認識技術の進化を知っていれば、「キーボード入力が困難なユーザーのコミュニケーションにおける課題」という新しい角度からの課題定義に繋がるかもしれません。
チームでの実践：エンジニアリング視点を共有する
エンジニアが得た技術的なインサイトや気づきを、デザイナーやプロダクトマネージャーといった非エンジニアのチームメンバーと共有することは非常に重要です。
- 具体的な方法:
- 図解・比喩: 複雑なシステム構成や技術的な課題を、非エンジニアでも理解できるよう、簡単な図や身近な比喩を用いて説明する。
- ワークショップ: 短時間の共有会やワークショップを実施し、インタビューで得られた技術的示唆や、システム分析から見えてきた課題について、チーム全体で議論する時間を設ける。
- 共通ドキュメント: ペルソナやカスタマージャーニーマップ、課題定義書などに、技術的な側面からの補足情報や気づきを明記する項目を追加する。
エンジニアが持つ視点はチーム全体のユーザー理解を深め、より多角的な課題定義を可能にします。
忙しい中でも実践するヒント
日々の開発業務に追われる中で、デザイン思考の初期フェーズに時間を割くのは難しいと感じるかもしれません。しかし、工夫次第で効果的な実践は可能です。
- 既存情報の活用: ユーザーからの問い合わせ内容、サービスログ、GitHub Issue、過去の技術負債リストなど、既存の情報をエンジニアリング視点で改めて分析するだけでも、多くのインサイトが得られます。
- 短時間集中: ユーザーインタビューの同行や観察を短時間（例: 1時間）に限定したり、週に一度30分だけチームでインサイト共有会を実施するなど、可能な範囲で時間を取り組みます。
- 「ついでに」の視点: 自身の担当機能や関連技術について調べる際に、「この技術はユーザーにとってどんなメリット/デメリットがあるのだろう？」「このシステム制約はユーザーのどんな行動に影響しているだろう？」といったデザイン思考的な問いを「ついでに」考えてみる習慣をつけるのも有効です。
まとめ
デザイン思考における「共感」と「定義」のフェーズは、単なるユーザーへのヒアリングや観察に留まりません。エンジニアリングの深い知見を持つエンジニアがこの初期段階から積極的に関わることで、ユーザー自身も気づいていない技術的な課題や、システム構造に起因する根本的な問題を発見しやすくなります。
技術的視点を活かしたインタビュー、観察、分析は、得られるインサイトの質を高め、より現実的かつ価値の高い課題定義に繋がります。これはサービス開発の方向性を定める上で非常に重要であり、その後のアイデア発想やプロトタイピング、そして最終的な開発の成功確率を大きく高めることに貢献します。
自身の専門性をデザイン思考の初期フェーズにどう活かせるかを考え、日々の業務の中で少しずつでも実践していくことが、「本当に価値のあるサービス」を創り出す第一歩となるはずです。