「DXをやれ」ある日そんな号令のもと企画立案からシステム開発までを任される。そんな時困らない、迷わないためDXプロジェクトを数多く手がけてきたプロのノウハウを伝授。
DXプロジェクトを理解する
テストマーケティングは、PMF（Product Market Fit：プロダクトマーケットフィット）を確認するために実施します。開発しようとしている製品やサービスが、マーケットつまり利用者のニーズに適合しているかを検証するものです。数千万円や億円単位の多大なコストをかけて、誰も使わないサービスができたという悲劇は現実によくあります。これを避けるため、モックアップやプロトタイプなどのMVP（Minimum Viable Product：検証可能な必要最小限のプロダクト）を用いて、想定する利用者にサービスのイメージを確認してもらい、早めにフィードバックを受けて、PMFのミスマッチを少しでも防ぐことが重要です。PoCやテストマーケティングを実施したら、その結果を検証します。実用に耐える精度なのか、顧客ニーズに応えるサービスなのかなどを検証し、このまま開発を進めるべきか、PoC期間を延長すべきか、サービス内容自体を見直すべきかなどの再計画を行います。仮に先に進む場合でも、そのまま進行することはまれです。多くの場合、PoCの結果やテストマーケティングの結果を受けて、企画・要件の見直しが必要になります。
DXプロジェクトと今までの基幹業務システム開発との違いを理解した上で進行しないと齟齬が生まれる。早めのフィードバックでミスマッチをできるだけ少なくするのが常道。
設計が終わったらいよいよ実装
設計が終わったら、基本・詳細設計ドキュメントを基に実装を進めます。ただし前述の通り要件や仕様が変わりやすいため、その都度テスト仕様書を作っているとメンテナンスが追いつきません。そのため、CI（Continuous Integration：継続的インテグレーション）の一環である自動テストなどの仕組みを導入するとよいでしょう。自動テスト以外のテストももちろん実施します。既存のCRM（顧客関係管理）システムと連携する、基幹システムからデータを取得するなど、連携システムがある場合は、外部結合テストをしっかり実施する必要があります。このときに気を配るべきは、ユーザー企業内の関係部門との事前調整です。IT部門など連携システムの管理担当者は、柔軟なスケジュールで対応してくれることはほとんどありません。期日に余裕を持って事前相談をし、スケジュールやテスト内容の調整をしましょう。最終品質保証のテストである総合テストは、DXのサービス開発であっても必須です。単体で動作する簡易なツールレベルのサービスであれば不要ですが、複数のシステムで構成される場合、すべてを接続した状態でのテストは必須です。また、本番データ相当での性能テストや、システム運用を想定したテスト、OSやブラウザーなどの環境動作確認といった非機能要件面のテストも求められます。サービスによっては脆弱性診断も必要です。このあたりの品質保証の考え方は基幹系システム開発と変わりません。ユーザーテストも重要です。企業側のDXチームの担当者たちによる操作感や機能検証を行い、フィードバックを上げていきます。クローズドβ（ベータ）と呼びますが、一部の実利用者（消費者）だけにサービスを使ってもらいフィードバックをもらう手法もあります。利用者からのフィードバックが得られたら、サービスの見直しや修正をします。フィードバック内容がサービスの中核機能やUX（ユーザーエクスペリエンス）に関わる場合は、改善後、その結果をもう1度利用者に確認してもらいます。フィードバックの内容が軽微なものであれば、1度のユーザーテストでよいでしょう。ここまで済んだら、いよいよリリースです。なおベータ版リリースのように、ユーザーテストを経ずにリリースし、広く利用者に使ってもらってフィードバックを得る方法もあります。
ユーザーテストを広く行いフィードバックを得るのもよいでしょう。実装段階ではよりよいUX（ユーザーエクスペリエンス）も大事になってきます。使い勝手を決める重要な点なので意見を聞きつつ練り上げていきましょう。
要件定義フェーズの進め方
新サービスの開発でAI（人工知能）を活用するケースが増えている。AI機能の要件定義が通常のシステム開発と異なるのは「学習する」要素があることだ。学習の要素を踏まえたAI機能の要件定義のプロセスと、まとめるべき4つの要件を解説する。近ごろの新サービス開発では、AIを活用するケースが多いでしょう。4-4では、新サービス開発系のDXプロジェクトの要件定義のうち、AI機能の要件定義の具体的な作業内容を説明します（ 図1）。 和田：AI機能要件定義って何をやればいいんだろう。 平川：いやぁ想像もつかないですね、AI自体詳しくないですし。 和田：うーん、しかしベンダーに丸投げするのもなぁ、我々としてどこまで何をやればいいんだろう。 三宅：AIの技術の中身まで分かる必要はありませんが、AIで何をしたいのか、どんなデータをAIに与えるかは、発注者であるユーザー側が決める必要があります。AIを使った機能も、入力データを処理し、出力するという視点で見れば、通常のシステムと変わりありません。異なるのは「学習する」要素がある点です。学習して答えを出す機能を、「学習モデル」や「学習器」と呼びます。ここでは、学習モデルという言葉を使います。学習モデルが、通常のシステム機能における処理（プロセス）に当たります。学習モデルが学習する処理の仕組みのことを「学習アルゴリズム」と呼び、どのアルゴリズムを採用するかで精度が変わります。AIで取り組みたい課題の特性によって、適切なアルゴリズムが異なるのです。 学習アルゴリズムには、決定木、ロジスティック回帰、CNN（畳み込みニューラルネットワーク）など様々なものがあります。もちろん知識があるに越したことはありませんが、昨今では適切なアルゴリズムを自動選定する機械学習フレームワークなどもあります。発注者であるユーザー側の立場でDXプロジェクトに参加している場合は、それほど気にする必要はありません。代表的なアルゴリズムの名称や、高い精度が出るアルゴリズムは課題によって異なるということを理解しておけばよいでしょう。ただ、要件定義はきちんとする必要があります。発注者であるユーザーやITベンダーがAIに関してまとめるべき要件は、大きく分けて以下4つあります。 （1）アウトプット（出力データ）定義：AIで何を得たいのか （2）インプット（入力データ）定義：AIにどんなデータを与えるか （3）前処理要件定義：データをどう加工するか （4）教師データ（正解ラベル）定義：AIでどんな出力が得られたら正解とするか（教師あり学習の場合）
AIの活用となると特殊なスキルを持った担当者の選出が必要に。場合によっては社外にそれを求める場合も。こうしたところの連携も課題。
「DXやれ」と言われて何それデラックス？というような中小企業の担当者は意外と多いのかもしれない。流行りに乗って自社でも導入して競争力をと思ったトップの鶴の一声で始まったDXプロジェクトを成功に導く手引書。
【サブスク】 Kindle Unlimited
僕が利用している読書コミュニティサイト
【本が好き】https://www.honzuki.jp/
【シミルボン】https://shimirubon.jp/