DX以前の「要件」とDX時代の「ユーザーストーリー」、その最大の違いとは：大企業のDXで追求すべき「顧客価値の最大化」を考える（1）（1/2 ページ）

ユーザー企業におけるDXは、Web系企業やスタートアップで使われる手法とは違うアプローチが必要だ。SOMPOホールディングスの内製開発事例を基にデジタル開発の在り方を学ぶ。第1回は「DX時代の『ユーザーストーリー』はこれまでの要件定義と何が違うか」について。

[西野大介，SOMPOホールディングス株式会社]

　本連載は、SOMPOホールディングスの内製開発部隊「SOMPO Sprint Team」が、デジタルトランスフォーメーション（DX）の実現に向けて最も重要視している「顧客価値の最大化」について、具体的な開発事例を基に解説していきます。

日本における「ユーザー企業間のコミュニティー化」を目指して

　本題に入る前に、本連載の趣旨について説明します。

　オープンソースソフトウェアの発展を見れば分かるように、IT業界の発展において「互いに情報を公開すること」は重要な要素だと筆者は考えます。これはDXにおいても同様で、公開されているデジタル活用のさまざまな事例や成果を参考にすることで自社のDXを加速させることができます。経済産業省が選定するDX銘柄のように、優れた実績を評価、公開する動きも活発です。

　しかし、多くの事例が公開されているにもかかわらず、ある調査によれば「DXの取り組みを始めている国内企業は3割に満たない」というデータもあります。これはなぜなのでしょうか。

プレスリリース「一般社団法人日本能率協会、『2020 年度（第 41 回）当面する企業経営課題に関する調査』を実施」から引用。全体で「既に取り組みを始めている」「検討を進めている」の合計は5割を超えるが、「既に取り組みを始めている」に限定すれば3割に満たない

　幾つか理由は考えられますが、筆者は「公開されている事例の内容に偏りがあるから」だと思います。

　公開されている事例は大きく「成果（アウトプット）の公開」と「過程（プロセス）の公開」に分けられます。筆者が見る限り、前者が多く、後者が少なくなりがちです。プロセスの公開が少ない理由は「見栄えの良くない、開発の“泥臭い”部分も見せなければならないから」でしょう。しかし、アウトプットの情報（＝成功のイメージ）だけでDXを実現することは困難です。価値のあるアウトプットは適切なプロセスを経て初めて出来上がるものだからです。

　そこで本連載は「価値のあるDX推進の情報」を提供するため、プロセスの公開に重きを置きます。

　連載の目的としてはプロセスを公開することで企業のDXを加速させることですが、可能であればDXを実現した企業が本稿のように事例を紹介する流れができればいいと考えています。本稿をきっかけに、ユーザー企業間で積極的に（見栄えのよくないものも含めた）プロセスに関する情報交換が活発になり、「ユーザー企業間のコミュニティー化」が進むことで、日本のDXが発展することを期待しています。

　第1回のテーマは「DX時代の顧客価値追求の在り方」です。

ケース1．「AIによる入電数予測システム」

　その案件は、SOMPOグループのコールセンターにて受ける電話の件数（入電数）を予測するAI（人工知能）システムを構築するプロジェクトでした。自動車の事故受付をするコールセンターの入電数は日々異なるため、何らかの方法で事前にその数を予測し、それを基に出勤するオペレーターの人数やシフトを決める必要があります。

　予測数は業務において非常に重要な数値です。多過ぎれば余剰人員が発生し、少なければコールセンターがパンクしてしまいます。一方で当日の天気などの不確定要素にも左右されるため、予測は非常に難しいという特徴があります。従来は経験による予測をしていましたが、AIを活用することで、予測にかかる工数の削減と予測数値の精度向上を実現しようとしました。

　開発チームは2チーム体制を取りました。予測数値を算出するAIチームと、ユーザーが操作する画面機能やAI実行に必要となるバックエンドを作るアプリチームです。筆者の担当はアプリチームでした。

社内向けシステム開発に立ちふさがる3つの壁

　案件の始動に当たり、主に3点の課題がありました。

課題1．開発期間が非常に短い

　アプリチームの開発期間は4週間でした。筆者の所属するチームでは原則「1スプリントは2週間」の設定にしていたため、スプリントは2回しか回せません。トライ＆エラーがほとんどできないため、最初に開発の方向性を見誤れば、スケジュールの遅延やプロジェクトの失敗を招いてしまいます。

課題2．業務の環境やフローが統一されていない

　SOMPOグループのコールセンターは全国に展開しており、それぞれシステムを利用する環境（ネットワークやPC、ブラウザなど）が異なっていました。シフトの調整は「Microsoft Excel」を利用したツールでやりとりされており、各コールセンターでどのように利用されているかは明文化されていない状況でした。そのため、新しく開発するシステムは各コールセンターで正しく動作するかどうか検証する必要があり、明文化されていない業務フローを整理する必要もありました。

課題3．ステークホルダーとの関係性が構築できていない

　事業部門と進める開発は今回が初めてで、前提情報がほとんどない状態でした。一般的な開発であればまずはお互いの進め方を確認し、懸念点を解決してから進めると思いますが、今回は短期間の開発にもかかわらず、お互いのことがほとんど分からない状況で進めければなりませんでした。こうした状況では各種承認フローや現場の決定権などプロジェクト進行のボトルネックになり得る要素が見えにくくなります。

「その夢、全て実現しましょう」と発言した理由

　これら3つの課題を踏まえ、筆者は本プロジェクト推進の責任者として方針を立てました。それは「開発の都合で要求を絞らず、ユーザーと対話をする」という方針です。

　本案件は「AIによる入電数予測」が軸となりますが、事業部門にヒアリングしたところ、今回の案件でシステム対応を予定していた部分以外の課題が浮かび上がってきました。予測された入電数を基にオペレーターの勤務シフトを組む作業や、コールセンターのどの拠点に電話をつなぐのか、という「分配比率」を入電システムに設定する作業なども全て手作業で実施していたため、入電予測数の算出以外でも多くの工程で作業負荷が高まっていました。

　しかし、本案件のスコープは「AIによる入電数予測」のみです。そのために準備した期間や要員の中で、案件の成功率だけを高めるのであれば、ヒアリングの内容は全て「当案件のスコープ外」として切り捨ててもおかしくありません。

　ですが、われわれはその真逆のアプローチを取りました。打ち合わせの場で「このプロジェクトで課題を全て解決する“夢”を実現しましょう」と宣言したのです。なぜなら、この案件は単発的なIT開発ではなく、当社の「DXを進めるためのピース」の一つだと考えたからです。

　DX以前のシステム開発における「要件定義」においては、システムの制約を適切に伝え、広がりがちなユーザーの希望に「システムの現実」を伝えるのが、プロジェクトマネジャー（PM）に必要な役割でした。しかし、DX時代における「ユーザーストーリー」では、真に価値のあるプロダクトを生み出すために本質的な課題解決を事業部門と一緒に考える必要があります。これが本稿の主題である「要件とユーザーストーリーの違い」です。

　「その夢、全て実現しましょう」と風呂敷を広げ、宣言することで、開発スタンスに対する事業部門の信頼を勝ち取ることが重要だと考えました。ただし、ここで強調しておきたいのは、上記はユーザーの意見を何でもその通り取り入れるわけではなく、受け止めるのはあくまで「ユーザーの思い」です。ヒアリングの場に出てくるユーザーの強い思いを一つ一つ受け取りながら、それぞれの「実現する価値を冷静に見極めること」「実現する可能性が高い方法に落とし込むこと」が必要です。