DX以前の「要件」とDX時代の「ユーザーストーリー」、その最大の違いとは：大企業のDXで追求すべき「顧客価値の最大化」を考える（1）（2/2 ページ）
ユーザー企業におけるDXは、Web系企業やスタートアップで使われる手法とは違うアプローチが必要だ。SOMPOホールディングスの内製開発事例を基にデジタル開発の在り方を学ぶ。第1回は「DX時代の『ユーザーストーリー』はこれまでの要件定義と何が違うか」について。
選択と集中、そして事業部門との協働
では、具体的に実施した対策について説明します。
対策1．「選択と集中」――目的を明確化し、それ以外の要素を“割り切る”
ユーザーストーリーの検討で広げた風呂敷を畳むためには、開発範囲の「選択と集中」によってMVP（実用最小限の製品）を定義することが必要です。本案件ではヒアリング内容から導き出された「現場の課題感に直接作用する価値の実現」をMVPの対象範囲とし、以下の「3つの割り切り」をしました。基準は先に挙げた「実現する価値」と「実現する可能性」です。
画面の割り切り
通常、画面を開発するときはデザイナー要員をアサインし、UI/UX（ユーザーインタフェース／ユーザーエクスペリエンス）からデザインを始めます。本案件ではこの「デザインフェーズ」を省略し、画面デザインをフロント担当エンジニアに一任しました。画面要素も、基本的には「Vuetify」（マテリアルデザインのUIフレームワーク）で表現できる範囲にとどめました。これにより画面設計と実装の工数を極力削減しました。これは「ユーザーは特定されており（SOMPOグループ会社社員のみ）、Vuetifyで十分な価値を提供できる」と判断したからです。開発期間内において実現する可能性が高かったことも理由の一つです。
機能の割り切り
短期間で開発を進めるため、開発以外の作業を削減する必要がありました。本案件では、複数拠点が関わる業務フローの分析と業務環境のテストを大幅に削減しました。業務フローは現状踏襲を前提とし、分析作業を削減。システムの役割は「その工程において必要なデータを取得する」用途に限定し、データはテキストファイルでダウンロードさせることにしました。こうすることでシステムの業務環境依存度を下げることができるため、各コールセンターでの検証は最低限で済みました。
一方で、課題で挙がっていた「予測入電数を基にしたシフト調整や分配比率の調整」といった周辺機能については導入を見送りました。その代わり、現行で使用しているMicrosoft Excelのツールをアプリチームで改修して機能追加することにしました。Microsoft Excelのバージョンや設定などに依存すると後で改修の必要が出てくるため、マクロは使用せず、「必要な機能を全て関数で実装する」という強気な対応をしました。
これらの対応によって、各拠点の事務フローは変更せず、新システムへの習熟も必要ない、業務環境にもほとんど依存しないシステムを構築できました。
連携の割り切り
AIによる入電数予測をするためには過去の入電数といった社内データが必要になります。天気情報のような一般データであれば公開APIですぐに取得できますが、社内データの場合はそうもいきません。既存システムにあるデータをやりとりするインタフェースを新たに構築する必要があります。既存システムに手が入ると他チームを巻き込んだ作業が発生するため、今回のように開発期間が非常に短い場合は予定期間超過のリスクがあります。
そこでデータ更新頻度に注目し、連携方法を見直しました。本案件で開発するAIは、予測に必要なデータの更新は月1回程度で十分でした。そのため、AIで使う社内データのやりとりはシステム間連携をやめ、専用の画面を使ってユーザーにデータを配置してもらうことにしました。「実現する価値を下げることなく、実現する可能性が十分に高い方法を選択した」といえます。
これらの対応は一般的な開発でイメージされるような「モダンで最適なシステム」とは異なる対応です。ですが、この短期間で今回のMVPを達成するため、こうした極めて泥臭い対応を採用しました。
対策2．事業部門と協働する――B2Bにおけるアジャイル型開発の価値
事業部門と進める開発は一般的なスクラムとは異なる体制になりがちです。本案件のように、事業部門が違うオフィスにある場合、事業部門の担当者にプロダクトオーナーの立場でプロジェクトに参画してもらうことが難しくなります。
こうした一定の“分断”を含むスクラム体制で開発を進める上で意識したのは、あくまで「成果物は実際の開発物」ということです。レビューはドキュメント類を充実させるのではなく、機能デモを軸に「実際に動くもの」を確認しながら進めました。アジャイルであれば当然といえますが、本案件では対策1．の「選択と集中」を意識しつつ、B2B（Business to Business）開発における明確な戦略としてこうした進め方を採用しました。
事業部門の期待値コントロールも重要です。風呂敷を広げて進める開発は、事前に要件を狭めるウオーターフォール的なアプローチに比べて実現する範囲は広がるものの、「どこまで実現するか」を制御しにくくなります。そこで、まずは要求を制限せず、本質的な業務課題まで食い込む姿勢を事業部門に示し、割り切りを含めた開発力を見せることで「意欲と実力」をアピールします。こうすることで事業部門からの信頼を得ることができ、異なる拠点であっても事業部門と開発チームが一体となって価値の最大化を追求する「ベストエフォート型開発」を進めることができます。
まとめ――DX時代の顧客価値追求の在り方
これまで、PMは「的確にシステムや開発にかかるリソースの限界を伝える」こと、つまり要件定義フェーズにおける「事業部門の期待値を下げること」がスキルとして評価されるケースがあったように筆者は思います。
確かに、要件を「リソースの中でできる範囲」に決めてしまえば、開発した機能が事業部門の期待以下になるリスクは減少します。ですが、その制限は成果の“天井”となり、プロジェクトに覆いかぶさります。スタートアップがしのぎを削り、各社が次々と価値を生み出す現在のDX事情においては「顧客価値の最大化」の妨げになる恐れがあります。
そのため筆者は「システム部門こそが積極的に風呂敷を広げること」がDXの第一歩であり、DX時代のユーザーストーリー検討で必要となる「顧客価値追求の在り方」だと考えます。
そして、夢を語るだけではなく実現価値と実現可能性を見極め、顧客価値を下げない方法で現実に大胆に落とし込む方法を考える、すなわち「適切なMVPを定義すること」がエンジニアリングスキルの見せ所です。
時には、AI案件開発にMicrosoft Excelで作ったツールの改修を組み込むような、“泥臭い”発想こそが真の顧客価値に近づく。そんな一例として本案件の事例が読者の皆さんの参考になれば幸いです。
Copyright © ITmedia, Inc. All Rights Reserved.