arclamp

ITアーキテクト 鈴木雄介のブログ

システム開発で曖昧な要望を形にしていく方法

このブログはグロースエクスパートナーズ Advent Calendar 2021の10日目です。

社内メンバーから要望があったので、僕自身がどのようにシステム開発の初期段階において、どのように要望を整理し、形にしていっているのかについて書きたいと思います。

なお内容は弊グループの案件を前提にしているので、システム開発は以下のような状況が一般的です。

  • クライアントは直接契約(プライム)
  • 要望を出すのはクライアント企業内で事業運営側の人で、システム開発にかかわった経験がないことがある
  • 対象システムはSoE/mode2で、一般消費者や取引先などの外部ユーザーと、社内で業務を回す内部ユーザーがいる

相手の話を整理するフレーム

まず、相手から得られる情報を4つの階層にわけて整理する必要があります。

  • 目的:達成すべきこと
  • 戦略:目的を確実・効率的に達成するためのシナリオ
  • 戦術:戦略を実行するための具体的な手段や操作
  • 兵站:戦術を実行するためのリソース(人やシステムや物やデータ)

多くの場合、クライアントは「目的」と「戦術」しか話してくれません。「〇〇を達成したいから、□□というシステムを作ってくれ」というわけです。ところが、これだけだとシステム設計がなかなか進みません。それには2つの理由があります。


1つ目の理由は、何かを達成するためのシナリオはたくさんあって、どのシナリオを選ぶかによって、具体的な操作が異なります。お店で売上を伸ばすとして、新規顧客を増やすのか、購入金額をあげるのか、既存顧客の繰り返し購買を増やすのか、によって作るべき機能は異なります。つまり、戦略が決まらないことには戦術を決めようがないのです。

2つ目の理由は、そのシステムを使うことの実現性です。例えばクーポン機能を作っても、どんなクーポンを発行すべきか決める人がいなければ意味がありません。既存顧客の繰り返し購買を増やそうとメッセージ通知機能を作っても、既存顧客の連絡先を知らなければ効果は出ません。つまり、どんな兵站が確保されるのかがわからないと戦術の実現性が判断できないのです。

というわけで、システム開発の初期段階では、戦術を確定するために戦略の立案と、兵站の確認をしていく必要があります。

戦略と兵站は一度に考える

実は「戦略の立案」と「兵站の確認」は同時に行なっていく必要性があります。両方が成り立たないと戦術が決められないのに、片方だけを真面目に考えても意味がありません。よくある失敗は、まず戦略を一生懸命考えて戦術に落とし込んだ結果、兵站がともなわず使われないシステムが作られてしまうことです。

一般消費者や取引先などの外部ユーザー向けのサービスの場合、戦略はカスタマージャーニーなど、顧客に対する価値提供で考えればよいです。どんな価値を提供すれば顧客がお金を払ってくれるのか、というのが、まさに戦略です。カスタマージャーニーには、その価値を実現するためのシナリオを明確にしてくれます。これがフロントステージ(表舞台)。

一方で、兵站というのは社内の業務部門の担当者やシステム、デバイスなどが対象になります。これらはアクター(登場人物)と呼ばれるものです。これがバックステージの登場人物。

華やかなフロントステージをうまく回すために、バックステージの登場人物たちが何をすべきか?ということを決める必要があります。このためにおすすめの手法がサービスブループリントです。

f:id:arclamp:20211209221757p:plain
from デジタルサービスデザイン(UI/UX) | Graat(グラーツ)-グロース・アーキテクチャ&チームス株式会社

サービスブループリント

サービスブループリントの書き方は、UMLのアクティビティ図や、いわゆる業務フロー図と同じです。ただし、重要なことはフロントステージにおける顧客の行動から、バックステージの登場人物までを1つの時間軸の中で記載することです。これによって戦略→戦術→兵站の全てを俯瞰しながら、それぞれを行き来して整合性を確認することができるようになります。

では、少しケーススタディをやってみましょう。あるECサイトでは、限定商品の販売をするたびに先着順で買ってもらっていたものの、転売屋が多くて困っていたとします。そこで担当者から「<目的>お客さまに公正な購入をしてもらいたいから、<戦術>抽選機能を作ってくれ」という要望があったとします。

そこでサービスブループリントを使って検討を進めてみました。それが、この図です。

f:id:arclamp:20211209230548p:plain
サービスブループリントの例
  1. お客さまが応募フォームから申し込みを行う
  2. 社内の販売企画担当者が応募者リストを管理画面からダウンロード
  3. 社内の販売企画担当者が当選者を手作業で選んで応募者リストにマーキングし、管理画面にアップロード
  4. システムが当選メールを送信

もともとは「抽選機能」が欲しいということで検討されていましたが、応募機能と通知機能だけを作り、当選者を選ぶ本丸の抽選機能そのものは手動で実施することになりました。なぜなら転売屋を弾くためのロジックがよくわからなかったからです。ブラックリストを作るにしても、最初からブラックリストは存在しません。自動生成されたような怪しげなメールアドレスは抜くにしても、何を持って怪しげかはわかりません。そういったことを考えていくと「まずは手動で1回でもやってみて、それから考えよう」ということになりました。

これは、あくまでもケーススタディなので、これが正解ということではありません。ただ、大事なことは戦略と戦術と兵站を一緒に考えることで「その戦術は価値を実現できるのか?」「兵站が確保され戦術に実現性があるのか?」といったことを整理していくことです。

宣伝

サービスブループリントは目的→戦略→戦術→兵站という流れを一貫して俯瞰することで有効に機能します。グロースエクスパートナーズグループには、こうしたプライム案件が数多くあるので携わってみたいなという人は応募してみてはどうでしょうかっ!

クライアントと一緒に設計したり開発したいよ → 株式会社GxPの採用ページ
サービスデザインでコンサルしたいよ →Graatの採用ページ