サービス開発プロセスにデザイン思考の成果を組み込む：エンジニアが果たす役割
サービス開発において、デザイン思考はユーザー中心の強力なアプローチを提供します。共感、定義、アイデア、プロトタイプ、テストといった各フェーズを経て、ユーザーの隠れたニーズや本質的な課題、そしてそれを解決するための新しいアイデアや具体的なソリューションの形が見えてきます。
しかし、そこで得られた貴重な洞察やアイデアが、実際の開発プロセスにうまく組み込まれず、単発の活動として終わってしまう、あるいは開発チーム全体に十分に共有されないといった課題に直面することがあります。特に忙しい開発現場では、デザイン思考の成果物をどのように日々のタスクやスプリント計画に落とし込むか、チームメンバー（特に非デザイナー）と共通認識を持つかが重要になります。
本記事では、デザイン思考の成果物を開発プロセスに効果的に統合し、ユーザー価値の実現を加速させるための実践的な手法と、エンジニアが果たすべき役割についてご紹介します。
デザイン思考の成果物が開発に繋がりにくい背景
デザイン思考の活動を通じて、ペルソナ、カスタマージャーニーマップ（CJM）、インサイトリスト、アイデアスケッチ、プロトタイプなどが作成されます。これらはユーザー理解や問題定義、解決策の探索において非常に有用ですが、そのままの形式では開発チームのタスクや仕様に直結しにくい場合があります。
主な背景としては、以下の点が挙げられます。
- 成果物の形式の違い: デザイン思考の成果物は定性的な情報や概念的なものが多く、開発に必要な機能リストや技術仕様とは形式が異なります。
- 時間の制約: 開発チームは既存のバックログ消化や急な仕様変更への対応に追われ、デザイン思考の成果物を読み解き、開発項目に変換する時間を十分に確保できないことがあります。
- チーム内の理解度の差異: デザイン思考のプロセスに直接関与していないメンバーにとって、成果物の背景にある意図や重要性が理解しづらい場合があります。
- 継続性の欠如: デザイン思考の活動が一度きりのイベントとして実施され、その後の開発プロセスとの連携が体系化されていないことがあります。
これらの課題を克服し、デザイン思考の成果をサービス開発に継続的に活かすためには、意図的なプロセス連携の仕組み作りが必要です。
成果物を開発チームが理解しやすい形式に変換する
デザイン思考で生まれた成果物を開発プロセスに統合する第一歩は、開発チームが理解し、アクションを取りやすい形式に変換することです。
ペルソナやCJMをユーザーストーリーや受け入れ条件に落とし込む
デザイン思考の「共感」や「定義」フェーズで作成されるペルソナ（ターゲットユーザーの具体的な人物像）やカスタマージャーニーマップ（ユーザーがサービスを利用するプロセスを可視化したもの）は、ユーザーの状況、ニーズ、課題を深く理解するためのものです。
これらを開発に活かすためには、具体的なユーザーストーリーや受け入れ条件に変換することが有効です。
- ユーザーストーリー: 「（ユーザータイプ）として、（目的）のために、（何）をしたい」という簡潔な形式で記述し、ユーザーの視点からの機能要求を明確にします。例えば、ペルソナの「忙しいビジネスパーソン」が「移動中に素早く情報を確認したい」というニーズを持っている場合、「忙しいビジネスパーソンとして、通勤中にスマートフォンで最新のお知らせをストレスなく確認したい」といったユーザーストーリーが考えられます。
- 受け入れ条件: そのユーザーストーリーが「完了」と見なされるための具体的な条件を記述します。例えば、「お知らせ一覧が3秒以内に表示される」「未読・既読が明確に区別できる」など、テスト可能な形で定義します。
ペルソナやCJMを参照しながらユーザーストーリーと受け入れ条件を作成することで、開発チームは単なる機能要求だけでなく、その機能が誰のために、どのような目的で必要なのかを理解できます。
プロトタイプの学びを具体的な機能リストやタスクに分解する
「アイデア」フェーズで生まれたアイデアを具体化し、「プロトタイプ」フェーズで作成したプロトタイプは、ユーザーテストを通じて多くの学びをもたらします。これらの学びは、単にプロトタイプを修正するだけでなく、開発すべき機能の特定や、既存機能の改善点として整理する必要があります。
- テスト結果の分析と機能への分解: ユーザーテストで得られたフィードバックを分析し、「ユーザーが〇〇に困っていたので、△△という機能が必要だ」「ユーザーは✕✕の操作に迷っていたので、UIをこのように変更する必要がある」といった形で、具体的な機能要求や改善タスクに分解します。
- 機能リストへの反映: 分解したタスクを、開発バックログ（今後開発すべき機能やタスクのリスト）に、優先順位付けを行って追加します。この際、タスクに紐づくペルソナやユーザーストーリー、インサイト情報へのリンクを含めると、開発者が背景を理解しやすくなります。
このプロセスを通じて、プロトタイピングで得られた定性的な学びが、開発チームが直接作業できる具体的なタスクへと変換されます。
既存の開発プロセスへの統合
デザイン思考の成果物を開発チームが理解できる形式に変換したら、それを既存のアジャイル開発プロセスの中に自然に組み込むことが重要です。
スプリントプランニングでの活用
スプリントプランニングでは、次のスプリントで何をするかを計画します。この会議にデザイン思考の成果物やそこから抽出されたユーザーストーリーを持ち込み、開発チーム全体でレビューします。
- ユーザーストーリーの共有: スプリントの対象となるユーザーストーリーについて、関係者（プロダクトオーナー、デザイナー、エンジニアなど）が協力して背景にあるユーザーのニーズやインサイトを説明します。これにより、開発者はタスクの表面的な内容だけでなく、そのタスクがユーザーにどのような価値をもたらすのかを理解できます。
- タスク見積もりへの反映: 開発チームは、ユーザーストーリーと受け入れ条件、必要に応じてプロトタイプを参照しながら、タスクの技術的な実現性や工数を見積もります。デザイン思考の成果物があることで、仕様の不明瞭さが減り、より正確な見積もりにつながる可能性があります。
バックログリファインメントでの活用
バックログリファインメント（バックログの整理・詳細化）の機会に、デザイン思考で新しく得られたインサイトやアイデアを議論します。
- 新しいアイデアの検討: ユーザーテストで発見された課題や、ブレインストーミングで生まれた新しいアイデアをバックログに追加するかどうか、追加する場合どのように記述するかをチームで検討します。
- 既存バックログの優先順位見直し: 新しいインサイトに基づき、既存のバックログ項目の優先順位を見直すこともあります。ユーザーにとって本当に価値の高いものに、開発リソースを集中させることが目的です。
スプリントレビューでの連携
スプリントレビューでは、完了した機能のデモを行い、フィードバックを得ます。この際、開発した機能が当初のデザイン思考で発見されたどのインサイトやニーズに対応しているのかを説明することで、ステークホルダーやチームメンバーの理解を深めることができます。
- ユーザー視点でのデモ: 単に機能が動くことを見せるだけでなく、それがペルソナのどのような課題を解決するのか、カスタマージャーニーのどの部分を改善するのかといった、ユーザー視点でのストーリーを交えてデモを行います。
- フィードバックの収集: レビューで得られたフィードバックを、今後のデザイン思考活動や開発バックログの見直しに繋げます。
実践上のヒントと注意点
デザイン思考の成果を開発プロセスにスムーズに統合するためには、いくつかの工夫が必要です。
- 開発チームの主体的な関与を促す: デザイン思考はデザイナーだけが行うものではありません。エンジニアを含む開発チーム全体が、ユーザーインタビューへの同席、プロトタイピングへの技術的な視点からの参加、テスト結果の分析など、活動の初期段階から関与することで、成果物への理解が深まり、開発プロセスへの統合が容易になります。
- 共通言語と共通ツール: チーム全体で理解できる共通の用語（例: ペルソナ名、ジャーニーの各ステップ名）を使用し、バックログ管理ツールやドキュメンテーションツールなどで成果物を一元管理・共有することで、情報へのアクセス性を高めます。
- 小さく始めて改善する: 最初から完璧なプロセスを構築しようとせず、まずは一つのスプリントでデザイン思考の成果物（例えば特定のペルソナとそれに基づくユーザーストーリー）を意識的に活用してみるなど、小さく開始し、チームの状況に合わせてプロセスを継続的に改善していく姿勢が重要です。
- 成果の可視化: デザイン思考の活動やその成果が、どのように開発に貢献し、どのようなユーザー価値に繋がったのかをチーム内で共有し、可視化することで、活動の意義付けやモチベーション向上に繋がります。
まとめ
デザイン思考は強力なフレームワークですが、その成果が開発プロセスに効果的に組み込まれて初めて、サービスとしてユーザーに価値を届けることができます。本記事でご紹介したような、成果物の形式変換や既存の開発プロセスへの統合手法は、そのための具体的なステップとなります。
エンジニアは単に仕様に従ってコードを書くだけでなく、デザイン思考の成果を理解し、それを技術的な視点から実現可能な形に落とし込み、開発チーム全体で共有・活用していく上で中心的な役割を果たすことができます。デザイン思考を日々の開発業務に組み込み、ユーザー中心のサービス開発を推進していくための一助となれば幸いです。