前回、DXの具体的な進め方の、大きなポイントについてお話しました。
(前回記事「従来のシステム開発とDXが明確にちがう点、一言で答えられますか？」)
今回はDXプロジェクトの上流部分、構想・PoCについて要点をまとめていきます。
(次回は要件定義以降の要点を)
参考文献はこちら
企画立案からシステム開発まで 本当に使えるDXプロジェクトの教科書 著者：下田 幸祐、飯田 哲也 出版：日経BP
「DXは企業変革」「DXはデジタル化ではない」といった概念的な情報で溢れかえっている昨今、DXの具体的な手順が細かく記載されている本書をたどることで、DXがより明確に見えてきます。
従来のシステム開発にはなかった工程
従来のシステム開発は
要件定義⇒設計⇒開発⇒テスト
という流れが一般的でした。
DXプロジェクトはこの流れに「構想」「PoC」等、あたらしい工程が入ってきます。
規模によって順番は変わってくるのですが、まず「構想」が最初に来るのがDXプロジェクトの特徴です。
「構想」とは「何をするか」。誰のどんな課題に対して、どんなサービスを提供するのかを考える企画フェーズです。
従来のシステム開発である基幹システムは、社員の勤務状況を整理したり、経理情報をまとめたりなどやることが決まっています。「何をするか」が明確にある状態からスタートするため「構想」の必要がありません。
そのため従来のシステム開発の場合、最初に行うのが「要件定義」。「何をするか」をさらに具体的にしていく工程です。どんな画面にするか、どんな管理機能にするか、業務をどう変更するか、サーバーの容量をどうするか、など細部を詰めていきます。
「構想」の次は、プロジェクト規模が小さい場合は「要件定義」。大きい場合は「テストマーケティング」「PoC」と続きます。
「テストマーケティング」は、構想で決めた「何をするか」のブラッシュアップ。想定ターゲットに構想内容を確認してもらい、感想をもとに、さらに構想を煮詰める段階です。
「PoC」は、構想で決めた「何をするか」がシステムで実現可能なのかどうかを検証するフェーズです。
「テストマーケティング」「PoC」は同時進行で進めていきます。この後に、設計・開発・テストと、従来のシステム開発同様の工程が続きます。
DXの一丁目一番地「構想」フェーズ
❶サービス企画
だれのどんな課題に対し、何を提供し、どう解決するか
❷サービス要求定義
サービスを具体化するとどんな機能になるのか
❸事業戦略・計画
価格・どんな風に売り出していくか
❹次フェーズ計画
構想以降、何をしていくか
本書では「JQベーカリー」という架空の企業をモデルにして説明しています。
❶サービス企画
ターゲットと、ターゲットが抱える課題を考えていきます。
何案か考え、自社が取り組むべき案はどれか選んでいきます。企画に慣れていないと「全部やる」というふうに考えてしまいがちですが、DXプロジェクトの場合、システム (アプリなど) を開発していくことになるため、いくつもやると膨大なコストが発生します。1つのアプリにすべての案を詰め込むのも、たくさんの機能を開発することになるためコストが発生しますし、よくわからないアプリになってしまいます。
本書ではA案を採用しました。A案の課題から、サービス案を定義します。
パン屋さんのパンを買いたいが、
パン屋が開いている時間帯に帰宅できない。
買いだめして冷凍する時間もない。
できれば、健康やカロリーにも配慮したい。
▼分解すると…
①パン屋が開いている時間帯に帰宅できない
サービス案１：1度申し込めば、定期的に届けられる
サービス案 2：ネットで都度注文できる
②買いだめして冷凍する時間もない
サービス案３：冷凍した状態で自宅に配送される
③健康/カロリーに配慮したい
サービス案４：パンの組み合わせをパーソナライズして提案する仕組みを提供する
▼サービス案をまとめると…
案❶ パーソナライズしたパンを定期お届けするサービス
(サービス案 2＋3＋4)
案❷ パーソナライズしたパンを注文するサービス
(サービス案 1＋2＋3＋4)
▼2案を 効果・コスト・実現難易度 で比較検討する
コストとインパクトを加味して案❶に決定。
…という流れで考えていくのが ❶サービス企画フェーズです。
❷サービス要求定義
サービス企画を、どんな商品 (アプリなど)・どんな機能で提供するのか・どんな業務が必要になるのかなどを決めていきます。
AIを用いる場合も、この時点でインプットとなるデータや処理の内容、アウトプットのイメージなどを整理しておきます。
最後に、決まったことをシステム構成図としてまとめ、❷サービス要求定義 は終了です。
❷サービス要求定義の思考プロセスの詳細については、本書をご参照ください。
❸事業戦略・計画
サービスの収益性や戦略などを検証していきます。
サービスの収益性は、マーケティングのフレームワークとして代表的な3C・4P分析などを利用し検証していきます。
重要なのは ❷サービス要求定義 と ❸事業戦略・計画作成 を同時並行で進めること。サービス収益性の検証を行い、あまりにも収益が見込めないと判断が付けば ❶サービス企画 から見直すことが必要になるからです。
また、サービスの収益性から逆算してサービス企画を考えるという手法もありますが、そもそもDXとは「儲かるからやる」という従来のビジネスモデルの否定です。ユーザーの課題を起点にサービスを提供していくことを目指しています。
❹次フェーズ計画
❸事業戦略・計画まで終わったら、次以降のなにをしていくか考えます。
プロジェクト規模によって、次に要求定義するか、テストマーケティング・PoCするか変わってきます。
「テストマーケティング」って？
「構想」の内容を想定する利用者に確認してもらい、意見を踏まえ、構想のブラッシュアップを図るフェーズです。
「構想」を客観視するフェーズとも言えます。「構想」はどんなに気を付けていても、自社の都合や思い込みが入ってしまうものです。利用者の素直な意見を真摯に受け止めることはとても重要です。
ポイントは「新しいモノに対する興味・許容度の高い利用者」を連れてくること。いわゆる「アーリーアダプター」です。新しいモノに懐疑的な人を連れてきてしまうと、サービス内容を抜きにして批判的な意見ばかり述べてしまいます。
「PoC」って？
「構想」が実現可能か検証するフェーズです。PoCは、Proof of Concept の略で「概念実証」という意味です。
「構想」したモノが、そもそも現在のデジタル技術で作れるのかを検証するのですが、ネックになるのが「AI」です。
AIは、学習し、推測・判断することができるデジタル技術。ですがまだまだ発展途上の技術で、推測・判断の精度は100％にはなりえていません。
そのため「どのくらいの精度なら良しとするか」を決め、検証していきます。
「JQベーカーリー」の例で言えば、パンのレコメンド精度をどう検証するか。
・AIのレコメンド結果と想定する利用者の購入履歴を見比べ、レコメンドが最もらしいかどうかを判断する検証方法にする
・結果80％以上の精度が出れば良しとする (その理由もあわせて検討)
といった感じで、目的・目標値を決めていきます。機械学習エンジニアや、データサイエンティストなどの専門家にも期待できる精度について意見をもらい決められると尚良しです。
実はこの目的・目標値が、DXプロジェクトの成否を握っていると言っても過言ではなかったりします。高い精度を設定してしまうとなかなか達成できずに終わってしまいます。かと言って、低い精度ではAIを入れる意味がないと経営層は判断してしまい、DXやる必要もないという判断を下してしまったりするためです。この事象を「PoC疲れ」「PoC地獄」などと呼んでいます。
AIの精度は100％には到達しないことを前提に、どこまで人が補填するかなども視野に入れながら目的・目標値を設定し、PoCを進めていくことが重要です。
今回は、DXプロジェクト特有のフェーズである「構想」「テストマーケティング」「PoC」についてポイントを整理しました。
次回はそれ以降のフェーズ「要件定義」「設計・開発・テスト」についてお話します。このフェーズは基幹システム開発でもおなじみですが、DXプロジェクトならではのポイントがあるため、そこを整理・まとめます。
まとめ「デジタルで新規事業を考える、ということ」
DXプロジェクトの上流工程「構想～PoC」についてお話してきました。
●「構想」は、誰のどんな課題に対し何を提供するかを企画すること。
●「テストマーケティング」は、「構想」を想定利用者に見てもらい、意見を集め、構想をブラッシュアップすること。
●「PoC」は、「構想」が実現可能か検証すること。特に、AIの検証がポイント。
基幹システムにはないこれら上流フェーズは、まさに新規事業のそれです。
新規事業立ち上げに挑戦している企業は多いわけではない中で、さらにデジタル技術を使った事業を考えなければいけない。どの企業も二の足を踏んでいる状況なのではないでしょうか。
特に「構想」。利用者の課題から発想することを得意とするのは広告代理店だったりしますが、オーダーが集まっているのはコンサルティング企業です。コンサルティング企業は既存事業の課題を発見し解決策を考える会社なので、ゼロから考える「構想」には向いていません。発注先をそもそも間違えている可能性もあります。
DXは、詳細に具体的に理解していくことで見えてくることが非常に多いと感じています。
次回は、要件定義以降についてポイントを整理していきます。
■参考：
企画立案からシステム開発まで 本当に使えるDXプロジェクトの教科書 著者：下田 幸祐、飯田 哲也 出版：日経BP
執筆者
リビルダーズ編集部
