2021年1月27日にオンラインイベント Build.Lunch Session『 “ディスカバリー”プロダクト開発を前進させる探索プロセス』を伊藤忠テクノソリューションズ株式会社と共同開催しました。

お客様のITライフサイクルを支えるソリューションプロバイダ 伊藤忠テクノソリューションズと、デザイン会社として初の上場を果たしたデザインカンパニー Goodpatchの二社が、プロダクト開発における初期の探索プロセスであるディスカバリーフェーズについて議論を交わしました。

本記事では、パネルディスカッションの様子をお届けします。

前回のBuild.Lunch Session イベントレポートはこちら
事業の価値と方向性をデザインで可視化し、DXを推進。Build.Lunch Session Vol.1 『不確実なDXを解き明かす鍵「デザインの力」』

Part1:「不確実なDXを解き明かせ!ディスカバリーのすすめ」

Buildサービス推進チーム Experience Designer 有馬 正人さん / モデレーター
Buildサービス推進チーム Solution Owner 小岩井 裕さん
Buildサービス推進チーム Experience Designer 東海 連さん
Buildサービス推進チーム Solution Achitect 羽多野 晋一さん
株式会社グッドパッチ UX Designer 西村 洋

ユーザー・ビジネス・システム観点からアプローチするディスカバリーフェーズ

小岩井さん:
まず、ディスカバリーフェーズについて説明します。このフェーズには大きく2つの目的があります。1つ目は、プロダクト開発を進めていく上で「なぜ作るのか」「何を作るのか」を明確にすること。2つ目は、開発に必要な情報整理などの準備をすることです。

ディスカバリーフェーズは、3つのプロセスに分けることができます。①学習フェーズ、②定義フェーズ、③計画フェーズです。

①学習フェーズでは、プロダクト開発の背景や解決すべき課題、ビジネスインパクトなどを整理。プロダクトの構想やプロトタイプの設計までを行います。

続いて②定義フェーズです。学習フェーズにおけるインプットを元に、ユーザーストーリーマップ、プロトタイプ、アーキテクチャーのダイヤグラムといった成果物を定義フェーズで生み出します。

プロダクト開発では、エンジニアリングとデザインの接合部分に課題が生じることが多く見受けられます。この定義フェーズこそが、エンジニアリングとデザインを繋げるタイミングなので非常に重要なフェーズです。

最後に③計画フェーズです。定義フェーズで検討したプロトタイプをベースに、MVPの定義付けやバックログの作成(=To Doの優先順位付け)、チーム間のコミュニケーションツールとしてのプロダクトロードマップの作成を行います。また、開発に必要なデリバリーチームの形成までを成果物として納品します。

有馬さん:
ディスカバリーフェーズでは、①ユーザー観点、②システム観点、③ビジネス観点といった、それぞれの立場からのアプローチをいかにバランス良く検討できるか、そしてプロダクトビジョンを獲得できるかが肝になります。

エクスペリエンスデザイナーである私の実感として、ユーザーとビジネス観点からの理想的なプロダクトビジョンに寄りすぎており、実現性といったシステム観点からのアプローチの検討が疎かになっていることが多いです。

そういった課題感が存在するディスカバリーフェーズにおいて必要な機能とは、どのような機能が挙げられるのでしょうか。

西村:
我々が担当するプロジェクトでは、「ユーザーの価値観や行動様式が移りゆく中で、サービスをどのように変化させていくべきなのか」といった声をよくお聞きします。そのような場合は、ユーザーリサーチだけでなく、その先の企画までをやり抜く力が重要であると思います。

特にDXにおけるディスカバリーフェーズでは、開発したプロダクトをユーザーへ届け切るといった意味でも、現在の業務とは異なる理想的な業務フローや変革のためのモデリングを意識すべきです。

有馬さん:
ユーザ観点からのアプローチでプロダクトを考えていく中で、実現性といったシステム観点からのアプローチの必要性を感じると思います。その際にどのような機能があれば良いと考えていますか。

西村:
実現可能性と実現方法について、システム観点からアプローチできると良いと考えています。初期のディスカバリーフェーズにおけるアイデア創出の際に、実現可能性といったシステム視点を取り入れる。また、プロトタイプ作成時に、アーキテクチャーの構成やエンジニアリングの工数、プロダクトの拡張性などといった実現方法をシステム観点から考慮すべきだと思います。そうすることで、ディスカバリーフェーズの進捗がスムーズに進むことが多いですね。

実効性と実現性を獲得するMVP開発

羽田野さん:
プロダクト開発において一つ目のマイルストーンをMVPの開発と置くと、実効性と実現性の獲得が探索的プロセスにおけるMVP開発の大きな成果物です。

MVP開発に至るまでの道筋が無数にある中、限られた期間で探索的プロセスを進行することは非常に難しいと感じています。

テクノロジーの観点からはアーキテクトによって、MVP開発における実効性と実現性を定義できると思うのですが、デザインの観点からはどのように定義されるのでしょうか。

東海さん:
デザイン観点からの実現性でいうと、ユーザー価値としての実現性を定義していく過程で作成するプロトタイプがあって、その目的は、ユーザーニーズの有無を明らかにすることだと考えています。また、様々な仮説に対する評価を複眼的に測定するといったチーム間のコミュニケーションツールとしての機能もプロトタイプが果たします。

このような目的意識を持たず、プロトタイプを作成すること自体が目的になっているケースがよく見受けられます。デザインだけでなくテクノロジーの観点からも言える話ですが、プロダクト開発の成果に紐付くようにプロトタイプの作成目的を定めた上で、計画を進めていくことが大切です。

西村:
ユーザーニーズの有無を探る探索的プロセスにおいては、時にニーズが仮説と異なっていた、そもそもニーズがなかった、というケースが出てきます。

そうなると、新しく探索できたニーズに合わせてソリューションのカタチを大きく転換するか、止めるか、の判断を行う必要がでてきて、これがなかなか自分たちで判断がつけられないケースがあります。そんなときはチーム外の方にアドバイザリー的に入ってもらうと効果的です。

有馬さん:
MVP開発において、デザイン・エンジニアリング・ビジネスといった各視点によって大切にしているポイントや優先順位などは様々ですよね。

それぞれの視点や意識が合致した状態を意図的に作り上げていく必要があると思うのですが、どのように考えていますか。

小岩井さん:
様々なステークホルダーが存在する中で、プロダクトオーナーやプロダクトマネージャーといった優先順位を決定する役割がハブとして機能することで、チームの視点や意識を合致させるべきです。

どの視点にも寄りすぎない合意形成をチームの中で生み出し、責任範囲と役割分担を決めて物事を進めていくことで、失敗する確率は比較的に減ると思います。

Part2:「国内DX状況から見たディスカバリーの取り組み」

Buildサービス推進チーム長 神原 宏行さん / モデレーター
株式会社グッドパッチ Business Designer 伊澤 和宏

トランスフォーメーションに重きを置くDX

神原さん:
Part1のセッションでは、既にDXに着手している方向けの内容でしたが、当セッションはこれから着手する方向けの内容です。

まず、「DXは最終的にユーザ体験の向上につながっているような印象を受けます。そもそもDXが必要とされる企業は業種業態などに条件があると考えられますか?」と質問をいただいており、テーマ検討していた内容と近いのでこちらに回答しながら、セッションを進めていきたいと思います。

「ユーザ=消費者」といったイメージが強いと思いますが、その観点も含めてDXをどのように捉えていますか。

伊澤:
消費者をユーザーとして定義するのではなく、社員をユーザーと置き換えて社内システムを効率化した。という事例もありますよね。DXと聞くと、「消費者であるエンドユーザーに向けて何かをトランスフォーメーションしなければならない」というイメージが強いのですが、会社の課題などをデジタルでトランスフォーメーションさせることも立派なDXなので、決まった条件はないと思います。

神原さん:
DXは「デジタルで利益創出をしなければならない」といったように、デジタルにフォーカスされがちです。しかし、世の中やエンドユーザー、社内の何かを変革させることにフォーカスするべきですよね。

伊澤:
極論なのですが、デジタルはさておき、「会社や社会をどのように変えていきたいのか」「どのようなビジョンの元、変革させるのか」を現場レベルと経営者層レベルで明確にしておくことが重要です。

「デジタルを使った新しいビジネス」や、「デジタルを使ったトランスフォーメーション」など、デジタルという概念に囚われてDXを開始してしまっており、目的や理由を見失っているケースが多々あると思います。

ユーザー起点で未来に向けたシナリオを紡ぐ

伊澤:
一方、DX推進を突き止めた結果、「新たな変革を促すための手段がデジタルである必要性がないのではないか」という結論に至るケースがあると思います。このような事例に関してはどのように考えていますか。

神原さん:
DXにおいてデジタルはあくまで手段です。しかし、5年後10年後を見据えた際に、会社が競争力や変化に対する適応能力を向上させ、世の中をより良くするためには、どこかで必ずデジタル的な要素が組み込まれます。DX推進はトランスフォームにフォーカスして、デジタルという手段を選択することで大きなうねりが生じ、世の中全体がより良くなると考えています。

伊澤:
私は先ほど「デジタルを使ったトランスフォーメーション」という表現をしました。しかしDXは、「デジタル時代におけるトランスフォーメーション」という捉え方もできますね。

神原さん:
DXによってプロダクトやビジネス、世の中をより良くしたいと考えた時に、ある程度の未来予測が重要であると思います。そこで、ユーザー起点で行うデザイン思考を活用したプロダクト作りは、現在軸の課題にフォーカスしすぎてしまうのではないかという懸念を感じたことがあります。

デザイン思考によってどのようにプロダクト作りを実行していくべきなのでしょうか。

伊澤:
まずは、ユーザーの定義付けから行います。先ほど、デジタル時代といった話がありましたが、必然的に1つのプロダクトに関わるステークホルダーの数が多くなりますよね。多種多様なユーザーが存在する中で、「どのユーザーに対してどんな価値提供を実現すべきなのか」といった定義付けを行う必要があります。

100%の未来予測は不可能であるということが前提なのですが、未来予測という意味では、現在と未来という点と点の間に紡がれるいくつかのシナリオを考え得ることはできると思います。

その際に、現時点でのユーザーの価値観や声を徹底的に拾い上げて、未来へのシナリオの仮説を構築します。時代の流れに対して、ユーザー起点で紡いだ未来に向けたシナリオが沿っているのか、逸れているのかを常々繰り返しリサーチすることが重要です。

神原さん:
SIerとしてシステムインテグレーションを行う際も、まずは、現存する真の課題を特定した上で、解決に向けた実装を行います。プロダクト開発には、ユーザーも含めてチーム内でのフィードバックループを形成することが大切なのですね。

伊澤:
そうですね、今までは企画と開発の間に分断があったと思います。自信を持って、より良い未来を切り開いていくためには、ユーザーの声を元にチーム一丸となってプロダクト開発を進めていくべきです。

QAセッション

ここからは視聴者の方の質問に答えていくQAセッションを行いました。

全メンバーの共通認識を確保してプロトタイピングを進める

有馬さん:
プロトタイプによるユーザニーズ検証後にソリューションアーキテクトを考えると、クライアントに提示したプロトタイプと異なってしまうケースがあります。プロトタイピングのアプローチをどのように進めているかお伺いしたいです」といった質問です。

東海さん:
プロトタイピングにおけるUXデザインは、ビジネスサイドとデザイナーサイドを中心とした体制で進めることが多いと思います。ディスカバリーフェーズは、個人の当事者意識を高め、チームの理解を深めることが目的でもあるので、プロトタイピングの前段階から開発メンバーも積極的に参加すべきです。そうでなければ、認識の齟齬が発生してアウトプットに”ずれ”が生じます。

有馬さん:
プロトタイピングのモックアップを見せることは両刃の剣だなと感じる瞬間があります。ユーザー観点に寄りすぎた結果、非現実的なプロトタイプをユーザーに提示してしまい、期待値が上がりすぎてしまうみたいな。仮説・ニーズ検証の手段と目的を全メンバー間で共有することが重要だと思います。

ユーザー体験を磨き込んで価値の流れを可視化する

神原さん:
ユーザの体験価値の磨き込みが最優先だと思いますが、ビジネスモデルの検討はどのタイミングでスタートしていますか? また、初期段階のビジネスモデルのデザインはどのような形式で定義されてますか」といった質問です。

伊澤:
ビジネスモデルの検討に特定のタイミングはないと思いますが、ユーザーに対して何かを当ててみて、確からしい価値を見出すことができた瞬間からビジネスモデルはある程度構築できると思います。いわゆるPSF(プロブレム・ソリューション・フィット)のことです。

神原さん:
ビジネスモデルは、ユーザーに対して何かを当ててフィードバックを元に改善したり、ピボットしながら進めるということですね。

また、ディスカバリーフェーズにおける、初期段階のビジネスモデルのデザイン形式はどのように考えていますか。

西村:
一般的に、最初にビジネスモデルを考えてユーザー体験を磨き込むという形式を採択しており、ユニークなビジネスモデルにならなかったり、ビジネスモデルをピボットしなくてはならないということが多々あります。なので、ユーザー体験の磨き込みを最優先に行うべきです。

現在、消費行動や社内業務の形態が変化している最中です。そういった変化を踏まえてユーザーの体験価値をモデル化した上で、ビジネスモデルやキャンバスを作成するといった順番が良いと思います。そうすることで、ビジネスモデルによって図解化されたお金の流れに加えて、価値の流れが可視化されます。

有馬さん:
状況に応じて、どのキャンバスを使用するのかを柔軟に考える必要がありますよね。キャンバスはビジネスモデルを可視化するツールとしての機能を果たすだけでなく、チームの合意形成を促進する役割も担います。

伊澤:
有馬さんがおっしゃった通り、キャンバスはチームの共通認識を揃えるコミュニケーションツールとして捉えることが重要です。キャンバスを共通言語としてプロダクトをアップデートしていく。そういった目的を意識して活用することが、プロダクト開発を前進させるきっかけになります。

最後に

以上、Build.Lunch Session Vol.2 『 “ディスカバリー”プロダクト開発を前進させる探索プロセス』のイベントレポートをお届けしました。プロダクトの方向性やチームの共通認識をすり合わせるといった、プロダクト開発の基盤となるディスカバリーフェーズ。手段の形骸化や想いの風化を防ぐためにも、チーム間で様々な観点が織り混ざった目的意識を醸成することの重要性が述べられていました。

GoodpatchはUI/UXを強みに、デザインパートナーとして企業のDXを伴走者として支援して参ります。DXに関するご依頼やご相談については、お気軽にこちらからお問い合わせください。