資料公開｜DX時代のシステム開発とは？ UXデザイン先行型の要件定義手法を解説。

2021年9月28日にオンラインセミナー「DX時代のシステム開発とは？ UXデザイン先行型の要件定義手法を解説。」を開催いたしました。
この記事では当日用いた資料を公開し、そのポイントを解説しています。

動画で見る

はじめに

本セミナーは「システム開発を外注する」という文脈に沿って説明していますが、UXデザイン先行型の要件定義は内製する場合でも使用可能です。内製を想定してご覧になる場合、「発注者」を「ユーザー部門」に、「ベンダー」を「システム部門」に、それぞれ読み替えてください。

システム開発の要件定義でよくある問題

システム開発において、要件定義はプロジェクトの成否を左右するほど重要で難しいプロセスです。なぜなら、要件定義に問題があると発注者の求めるものがベンダーに伝わらず、発注者のイメージと全然違うものが出来上がってしまう可能性があるからです。

この問題は、下記の2点に起因し、どんなプロジェクトでも起こりえます。

• 発注者が自分の要求を正しく表現することが難しい
• ベンダーが発注者の真の要求をうまく引き出すことが難しい

要約したものですが、次のような例えでよく説明されているのではないでしょうか。

要件定義の失敗イメージ
発注者がベンダーに「ブランコを作ってください」とだけ話し、細かい要件をまで正しく伝えられないと、それぞれの考えるブランコが異なってしまい、本当に必要なものとは似て非なるものが作られてしまう。

比較的完成形がイメージしやすい、類似システムがすでに世の中にある開発案件でもこうした問題がよく起きますが、DXにおける要件定義はさらに難しくなります。

DX時代の要件定義で生じる問題

「DX時代の要件定義」を説明する前に、DXとは何かを定義をしておきます。
ここでは簡単に「既存のビジネスモデルにとらわれず、新しいデジタル技術を活用することによって、新たな価値を生み出していくこと」がDXであるとしておきます。

なぜDX時代の要件定義が難しいかというと、「既存のビジネスモデルにとらわれない」「新しいデジタル技術を活用」等の条件により、求められるシステムがあまり前例のない未知のものになる可能性が高いためだといえます。
未知のものをつくることになるため「発注者自身も作りたいものを明確に描くことができない」状態でベンダーと相談するケースが多くなるのです。

少し強引な例ですが、先のブランコの話に当てはめると次のようになります。

DX時代の要件定義の失敗イメージ
発注者は「ブランコを超える革命的な何かを作りたい」とベンダーに依頼しているが、その時点ではそれが具体的にどのようなものか誰もイメージできていない状態。

仮に、なんとか「ブランコを超える革命的な何か」の要件を決めて、結果的に「ハンモック的な何か」をつくったとしても、今度は発注者側が欲しかったものは本当に「ハンモック」なのか、また、それが「ブランコを超える革命的な何か」として市場に受け入れられるのかという疑問にも誰も答えられない。

関係者が同じ視座を持つことが大切

こうした問題が生じる原因として下記の2つが考えられます。

1. 発注者とベンダーの視座が異なる：視座が異なれば、同じ言葉からイメージするものも異なる
2. ユーザーが真に欲しているものを把握できていない：最も大切なのは「ユーザーの視座」であるが、それは発注者の視座、ベンダーの視座のどちらとも異なる可能性が高い

では、どうすれば、こうした問題を引き起こさずにシステム開発プロジェクトを進められるのでしょうか？
私たちはその解を、開発プロジェクトの関係者全員で「ユーザーの視座に立つこと」に求めました。

要件定義の際に「発注者もベンダーも同じユーザーの視座に立って考える」ことをめざすのです。わかりやすく言い換えると、事業者側（作る側）の立場からではなく、皆がユーザー側の立場で考えてみようという取り組みです。
それに対するアプローチとして、NCDCでは要件定義にUXデザインの手法を取り入れています。
（後述するUXデザインのプロセスを発注者とベンダーが協力して進めることで、「ユーザーの視座」をともに考えていきます）

もちろん、この手法により完璧な答えが導き出せるとは限りませんが、少なくとも指針や、検証するための方向性を得てから開発に取り組むことはできるようになります。

UXデザイン先行型の要件定義とは

UXデザインとはユーザーエクスペリエンスデザイン(User experience Design）の略称です。ユーザーが製品・サービスを認知した瞬間から発生する体験（ユーザーとその製品・サービスに関するやりとりの全て）を「企画・設計する」ことを意味します。

つまり、UXデザイン先行型要件定義とは「ユーザー体験の設計」を先行し、そのために必要な機能等を整理していく要件定義の進め方を指しています。
従来型の要件定義は「発注者の要望」をベンダー側が「エンジニアの知識や経験」をもとに機能に落とし込んでいくという作業が主であるため、考え方に大きな違いがあります。

次に、具体的な進め方を紹介します。

NCDCの要件定義の進め方

NCDCが実践しているUXデザイン先行型の要件定義は「発注者」や「ベンダー」という従来の立場に拘らず、プロジェクトに参画する全員が「ユーザー」という同一の視座に立つことが最大のポイントだといえます。
そのため、多くの場合、ワークショップなどを行い、お客様（発注者）とNCDC（ベンダー）で一緒に考えながら下記のプロセスを進めていきます。

ペルソナを定義する

まずは、「ユーザーの視座」に立つために、想定されるユーザーを具体的な人物として詳細（イメージ写真、氏名、職業、年齢、趣味、家族構成、など）に定義します。これを「ペルソナ」といいます。

可能な限り細かく決めた方が良いですが、どの項目まで定義するかは、作ろうとしているサービスに関連するかどうかで判断してもいいと思います。
「ペルソナ」で定義された人物になりきり、全員が同一の「ユーザーの視座」を持つことができる状態になるのが重要です。

カスタマージャーニーマップを作成する

ペルソナができたら次に「カスタマージャーニーマップ」を作成します。
「カスタマージャーニーマップ」とは、ユーザーが製品やサービスと接点を持った時の行動や思考、インサイト（簡単にいうと「本音」のようなもの）を想像し、可視化したものです。

この「カスタマージャーニーマップ」を作成することで、「ユーザーの視座」を共有しつつ、課題を抽出し、システムへの要求をまとめていきます。

「ペルソナ」「カスタマージャーニーマップ」については前回開催したセミナーでより詳しく説明しています。興味があれこちらのレポートも合わせてご覧ください。
資料公開｜実践で違いを生むUX知識『カスタマージャーニーマップの本質とは？』

解決策一覧の作成と優先順位付

次に、解決策（システムの機能）として何が必要かを全員で考えます。
そして、それぞれの機能で得られる「効果」や「実現容易性」などの条件も加味して、優先順位が高いものから開発対象とします。この時、優先順位の低いものはプロジェクトの予算やスケジュールとの調整で要否を決めていきます。

ワイヤーフレームの作成

ワイヤーフレームとは、画面遷移や各画面の構成要素を確認するための「画面の骨組み」のような資料のことです。ここで、「機能」を実際にユーザーが目にするUIに近いかたちで可視化します。
従来型の開発では画面定義書に相当するもので、ここで作るものはどちらでもかまいませんが、「ユーザーの視座」で作られているか・確認できるかが重要です。

簡単に流れだけ紹介してきましたが、NCDCではこうした手法を「UXデザイン方法論」として整理しており、その中で「新規サービスに必要な機能やUIを使用者視点で検討する場合のUXデザインモジュール​​」も用意しています。
ご興味のある方はお問い合わせください。

まとめ

下図は、ここまでの説明をもとに、従来型とUXデザイン先行型の要件定義を比較したイメージです。

UXデザイン先行型の開発は、開発者もベンダーも同一の「ユーザーの視座」を持ち、一緒に要件を検討します。
また、開発の段階で出来上がってきたものをレビューする際にも「ユーザーの視座」という共通の指標を持って臨みます。

DX時代の要件定義は「発注者が伝え、ベンダーが聞く」かたちで行うものではなく、システム開発に関わる全ての人が「ユーザーの視座を持って一緒に作る」ものです。
そうすることで、従来の開発で発生していた「食い違い」や「不明瞭感」を最小限に抑え、プロジェクト全体の成功確率を高めることができます。

質疑応答

本セミナーではたくさんのご質問をいただきました。その中から3点を抜粋してご紹介します。

回答
要件定義に関してはUXデザイン先行型の方が多くの工数がかかるかもしれません。しかし、先に説明した「視座」の違いにより、従来型のシステム開発の方が開発の段階で手戻りのリスクが高くなると思うので、結果的にUXデザイン先行型の方が総工数は少なくなる可能性が高いと考えます。

回答
初めから完成品を作るのではなく、MVP（必要最小限の機能をもつプロダクト）を作り、ユーザーの反応を見ながら検証・改善を繰り返すという方法があります。また、社内の業務システムであれば利用者である社員にユーザーテストをしてみる、ワイヤーフレームを用いたプロトタイプなどを動かして感触を確かめてもらう、といった方法があります。

回答
少なくともUXデザインについては勉強する必要があると思います。
ちなみにNCDCでは創業以来蓄積してきたUXデザインの経験に基づいて、独自の「UXデザイン方法論」を構築しています。ご興味のある方はお問い合わせください。

システム開発のご相談はNCDCへ

これから新しい技術を取り入れたシステムを企画していく方（発注者となる方）、とくに古いやり方を変革していきたい方にとって、ここで紹介したシステム開発の進め方は有効な手法の一つになると思います。

「新しいテクノロジーでこんなことを実現したい」「こんな新しいサービスを立ち上げたい」といった抽象的なご要望しかなく、従来のやり方では要件定義さえ難しいシステムの企画に携わられている方はぜひお問い合わせください。