＊本コラムは、技術評論社「Software Design」2021年2月号に寄稿したコラムを掲載しています。

実際のアジャイル開発の現場では、創出しようとするサービス自体の検討が深くなされずにプロジェクトがスタートしたり、サービスを検討する側と開発を行う側が分断されていることから、あまりサービスのことが深く意識されないまま開発が始まったりといった場面が散見されます。
自己組織化されたアジャイルチームは、サービス提供に伴って発生する問題に対してどのように解決していくかをチーム内で決める必要があります。そのためには提供しようとしているサービスについて、

などを深く理解しておくことが不可欠です。つまり、アジャイル開発とサービス創出は一連の流れであり、切っても切れない関係といえます。
今回から、全2回に分けて新規サービスの創出について解説します（図1）。まずは今回の価値創出編でサービスの利用イメージを考えます。そして次回は実践編として、利用イメージを具体的なサービスに落とし込み、フィードバックを得るところまでを解説します。バックログの視点で言えば、今回はバックログに必要な要素を整理し、次回で具体的なサービスに向けてバックログを作り上げることになります。

図1　新規サービスの創出を全2回に分けて解説

サービス創出の第一歩

アジャイル開発のメンバーとして、サービス^注1をどのように創出すればよいか考えてみましょう。まずは、

という目的を達成するための「しくみ」を考えます^注2。今回は、次のような課題をテーマに簡単なサービスを試作してみることにします。
みなさんは家を出たあと、鍵をかけたかどうかが思い出せず家に引き返したことはないでしょうか？筆者は、年に何度かは家に引き返しています。ですが、たいていの場合は施錠自体はされていて、鍵をかけたことを覚えていないだけなのです。だからといって、「絶対に大丈夫」とは言い切れず、確認するために家まで引き返しているわけです。今回は、この問題を解決するサービスを考えてみます^注3。

サービスの大まかな目的を決める

ここで解決したい課題は「外出後、家の鍵をしたかどうかが思い出せない」ことです。このとき、このサービスの目的は「自分の家が防犯上望ましくない状態になっていることを防ぐ」ことだと言えます。この目的自体は十分に理解してもらえると思うのですが、ここでいきなり何かを作り始めてはいけません。サービスの目的が達成できたかを判断できるくらいまで目的の中身を明確にしたあとで、初めて実際の開発に取りかかるのです。

いつ、だれが、どのようにそのサービスを使う？

目的の中身を具体化するために、まずはいつ、だれが、どのようにそのサービスを使うかを考えてみます。そのためのツールとして、「簡易ペルソナ」と「ジャーニーマップ」を使います。

簡易ペルソナをたてる

目的の中身を具体化するために、まずはいつ、だれが、どのようにそのサービスを使うかを考えてみます。そのためのツールとして、「簡易ペルソナ」と「ジャーニーマップ」を使います。

サービスが乱立している現状では、ただモノやシステムを作って提供するだけでは利用してもらえません。サービスが利用されるためには「何を」は当然ですが、「誰に」が最も重視されるべきであり、それを深く考えるツールがペルソナです。ペルソナの設定は、ターゲット層（たとえば「30代男性」「子育て中の主婦」など）の考え方とは違って、より具体的でリアルな人物像を設定するものです。

本来、ペルソナの作成は調査の実施なども含めて難易度が高く、なかなか骨の折れる作業です。ただ、アジャイル開発を行う我々にとっては、簡易ペルソナを設定するだけで十分です。簡易ペルソナ（図2）とは、その場で検討を行っている我々が合意できる程度の人物像、つまり「この人は、サービスのユーザーとしてイメージできる」人物像のことです。「確かにこういう人がいて、このサービスを利用してくれそうだよね」というように、ユーザーのイメージをメンバー同士で共通のものとしておくことで、実現すべきサービスの方向性が明確になります。

簡易ペルソナは手軽で使い勝手の良いツールなのですが、くれぐれも自分たちの思い込みで都合のよい人物像に仕立て上げないように気をつけてください。いったん簡易ペルソナができたら第三者に見てもらうとよいと思います。

図2　簡易ペルソナの例

ジャーニーマップ

どんな人に使ってもらいたいサービスなのかは、簡易ペルソナで設定しました。ではその人は、いつどのようなタイミングでそのサービスを使いたいと思うでしょうか。そのタイミングに沿った形でサービスが提供できないと、いかに良いサービスでも使ってもらえません。そのサービスを使いたいと思うタイミング、言い換えると、本当に困ったタイミングの心情に寄り添ったサービス提供のしかたが、サービスの成否を決めるといっても過言ではありません。

ユーザーの行動や感情（不満や満足）の動きから、いつどのようにサービスを提供すべきなのかをチーム全体で俯瞰するためのしくみがジャーニーマップです。もしできるなら、ジャーニーマップと併せて実際のユーザーの実行動を2、3例見てみることをお勧めします。
図3では自分自身を対象にして、自分が家を出てから駅に向かうまでを、具体的に何を思い、どこでどう動いているかをジャーニーマップにしてみました（図中にある「△」の記号は、時間軸と行動の対応関係を表しています）。

図3　ジャーニーマップの例

そのサービスに優位性はあるか？

実は、今回の例に合致するようなサービスは、世の中にすでに存在します。自宅の鍵をスマホで開け閉めできるような市販のハードウェア、ペットを見守るためのカメラなどを使えば目的を達成できてしまいます。
通常、よっぽど斬新なアイデアでない限りは似たようなサービス、もしくは流用可能な別のサービスはほぼ100％の確率で世の中に存在する（誰かがやっている）と思ったほうがよく、そのような中で、自分たちのサービスの優位性は何か、を考えなければなりません。

本当に達成すべき目的がクリアであればあるほど、かゆいところに手が届くサービス（あるいはサービス群）となり、優位性を創出することが可能になります。たとえば今回の例でいえば「手軽に手に入る」「その場で確認できる」「複数の鍵について同時に確認できる」「自動施錠できる」などです。このような優位性を見つけ出すために、ジャーニーマップや簡易ペルソナが重要になってきます。

サービスの特徴や優位性については、ここでは2×2のマトリクス分析で検討してみます（図4、図5）。この図自体は、よく見るものですし、珍しいものではありません。みなさんも使ったことがあるのではないでしょうか？　2つの軸に対して、競合や似たようなサービスをプロットするというものです。競合のサービスがプロットされていない領域が、優位性を持っているということになり^注4、自分のサービスに競争力があるのかどうかをある程度確認できることになります。ポイントは「軸を何にするか」と「軸をどれだけ抽出するか」です。あまりたくさんの軸を考えても分析しきれませんから、サービスの狙いと優位性を見いだせる軸の組み合わせを模索し、2～3例くらいのマトリクス分析を行えばよいと思います。

今回の例では、コスト・利便性・手軽さ・利用者数あたりを軸に分析してみました。

図4　マトリクス分析の例①

図5　マトリクス分析の例②

サービスの全体像は？

ここまでで、なんとなくサービスのイメージがつかめてきました。「とにかく手軽であるほうがよい」こと、「実際には無意識に施錠していることがほとんどで、本当の心配ごとは施錠状態である」こと、「施錠・開錠の自動化などの大げさなものは不要である」ことあたりが重要な要件と言えます。また、グループでの利用も視野に入れたほうがよさそうです。これは先述のマトリクス分析（図5）から、グループでの利用が可能なら商機がありそうだと判断できるためです。

サービスの流れをシナリオに起こす

ここからやることは、具体的なサービスのイメージを確立することです。まずは、実際にサービスを「どう作るかはさておき」、こういう感じで使っていく、というストーリーに起こすことを行います。ジャーニーマップの具体化、といってもいいかもしれません。
表現方法はイメージが明確になれば何でもかまいません。簡単な4コマ漫画を描いたり、シナリオを記述してかまいません。絵心のない筆者は、シナリオでサービスを表現してみます。ここで主人公は図2で策定した簡易ペルソナであり、シナリオは図3のカスタマージャーニーに対応しています。

●シナリオ１

●シナリオ２

この想定から、「鍵がかけられていても、問題ない旨を通知したほうがいいだろうか？」という、改善のヒントになる問いが得られます。

●シナリオ３

こちらのシナリオからは、「単なる通知だとユーザーが気づかない」可能性が想定できます。通知の手段はいくつかオプションがあったほうがいいかもしれないと、こちらも新たな改善案につながりそうです。

キー技術の検証

次にやっておくべきことは、キーとなる技術の検証です。とはいえ、ここに多くの時間を割く必要はありません。上記のようなサービスを実際に開発する場合、状況によっては利用技術に制約があります。そのため、利用できる技術群の中から、目的とする機能が実現可能なのかを調べます。今回の場合だと、技術的には次の3つくらいがわかれば良さそうです。

これらがまったくできる見込みがなければ、このサービスが日の目を見ることはありません。もしあまり技術に詳しくないということであれば、技術に長けている人に相談してみましょう。
検討の詳細については割愛しますが、今回の例だと技術的には次のように実現できそうです。

リーンキャンバス

さて、ここまでくると、どんなサービスにするかイメージできてきたと思います。そこで仕上げとして、サービス提供にあたって開発者側が意識しておいたほうがよいこと、ビジネス側へ改善を提案できそうなことなどを、図6のようなリーンキャンバスなどを用いて明確にしておきます。図6の項目のうち、顧客セグメント（≒簡易ペルソナ）、ユーザーの課題（≒目的設定）、競合優位（≒2×2マトリクス分析）、価値（≒ジャーニーマップなど）はすでに検討済みですので、それ以外をざっくり考えておきます。たとえば、

などです。これらは開発者だから関係ないわけではありません。サービスを改善するためには、この部分に意識を向けることも重要です。

サービス案のフィードバックを受ける

ここまでできたら、今までの内容を別のチームの人、上司、簡易ペルソナの想定に近い人などに説明してみます。そこからはいろいろなコメントや思いもよらないフィードバックがあるかもしれません。もっと具体的ないいアイデアが出てくるかもしれません。このフィードバックを受けて、該当する箇所を更新し、そこに関連するところを直していきましょう。いきなり、完璧な発案ができることはありません。徐々に洗練されたサービスにすればいいだけなのです。

今回はシステムの中身やUIの具体的な内容については踏み込みませんでしたが、どのような背景に基づいてサービスが作られていくのか、ある程度概観できたかと思います。
今回で言いたかったことは、創出しようとしているサービスを深く理解することによって、アジャイル開発の「変化に柔軟に対応する」ことの価値が最大化されるということです。創出価値を高めるためには、サービスのどこをどう改善していくか、十分理解する必要があります。次回は、この内容をベースに「具体的に作るものに踏み込む」バックログの策定に入っていきます。

最後に、大事なことが2つありますので、それを記して今回は終わりにします。
まず1つめは、これらのタスクはシーケンシャルに進むものではないということです。1が終わると2に進み、それが終わると3に進み、前の手順に戻ることはない、というものではありません。ひとまずは直線的に進めればいいと思いますが、その後の検証結果によってはタスク間を行きつ戻りつ修正を繰り返していく必要があります。当然、サービスをリリースしたあともこの検証は続いていきます。

2つめは、分析手法を使うこと自体を目的にしないということです。分析すること自体が目的になってしまうことは往々にしてあります。「この手法を使っていないからだめだ」とか、「いろんな分析をしていないから駄目だ」という声を気にする必要はありません。自分たちがやりたいこととは何なのか、それは誰かにとって価値があるのか、このサービスはほかと比べてどこがいいのかをしっかり認識できれば良いのです。そして、すばやくフィードバックをもらい、より良いものに改善していくことにこそ価値があります。こう考えると、サービスを考えるこのフェーズも、まさにアジャイルと言えます。

図6　リーンキャンバスの例