要件が曖昧でもITシステムを作れる。ただし、方法論を知らずしてそれは叶わない。要件手前のアイデアを「仮説」に変換する技術など、システム開発を迅速に進めるための方法論を押さえよう。

 デザイン思考などの手法を用いてシステム開発の「仮説」を立てたら、次はそれを実際に動くシステムとして開発していく。とはいえ、仮説はプロジェクトの目的やユーザーが抱える課題、その解決案の候補を短い文で挙げただけ。システムの開発を始めるには曖昧すぎる。開発に入る前に、仮説を「システムへの要求」に詳細化する必要がある。

 デジタル変革や新サービス開発では、「システムを世に出してみないと分からないことがたくさんあり、一番力を入れた機能がユーザーに受け入れられないという場合もある」(アクセンチュアの山根圭輔テクノロジーコンサルティング本部インテリジェントソフトウェアエンジニアリングサービス グループ統括マネジング・ディレクター)。システムへの要求を考える際には、こうした特徴を押さえておくことが重要となる。

 多数のITエンジニアがこの難題に挑み、次のようなやり方が見えてきた。新事業創出の方法論「リーンスタートアップ」と、小刻みにソフトウエアを開発する手法「アジャイル開発」を組み合わせたシステム開発である。

 まずは仮説から考えられるシステムへの要求を洗い出す。アジャイル開発の「ユーザーストーリーマッピング」という手法を用いるITエンジニアが多い。

仮説を検証できる最小限のシステムをまずリリース
仮説を実現するシステムへの要求を検討する。仮説の正しさを検証するために最小限必要な要求を見極め、それを早期にリリースして軌道修正できるようにする。
[画像のクリックで拡大表示]

 洗い出したシステムへの要求の中から「仮説を検証できる最小限の機能」を見つけ出す。こうした実用最小限の機能を実装したシステムを、リーンスタートアップでは「MVP(Minimum Viable Product)」と呼ぶ。MVPの見極めにはさまざまなやり方がある。今回は代表例として「ディスカバリー&フレーミング」という手法を紹介する。

 この先はアジャイル開発の進め方に沿って、システムへの要求のうち重要度の高い機能から開発をする。MVPに相当する機能を開発できたら、初回のリリースとなる。リリースしたシステムについて、ユーザーの声を聞いたり、主要指標を計測したりして反応を見る。これが仮説の検証に当たる。ユーザーの反応が良ければ機能の開発を進め、ユーザーの反応が悪ければ軌道修正をする。

 MVPがユーザーに受け入れられなかった場合は、仮説が誤っている可能性が高い。仮説そのものを見直すなどの、方向転換を検討する。使いにくいといった問題が見つかれば、機能を改良する。リリース予定がずっと先の機能を求める声が挙がるなど想定外の反応があれば、開発に着手する順番を変更する。ビジネス担当や開発担当が新たなアイデアを思いつく場合もある。

 アジャイル開発はこうした変化への対応を得意とする。

ユーザーストーリーマッピング
システム機能の見取り図を作る

 ユーザーストーリーマッピングとは、時系列で並べたユーザーの行動に沿って、システムへの要求を洗い出す手法だ。ビジネス担当と開発担当が話し合い、模造紙と付箋を使ってシステムへの要求の見取り図を作成する。

システムへの要求を見つけ出す「ユーザーストーリーマッピング」
仮説の実現に向けた、システムへの要求の全体像を明確にする。同時にシステムへの要求に取りこぼしがないかを確認する
[画像のクリックで拡大表示]

 具体的な流れは以下の通り。まず、模造紙の一番上に業務の大まかな流れを書いた付箋を貼る。続いて、業務の流れの各段階で、ユーザーが実施する作業をステップに分解して、その内容を付箋に書く。付箋は左から右へと時系列に沿って横に並べて貼っていく。役割が異なるユーザーが複数いて混乱しそうな場合は、2段目の作業のステップを複数行に分ける。

 各作業のステップの下に、それを実現するシステムの機能を縦方向に貼っていく。教科書的には、付箋は「[ユーザーの役割]が[機能]をできる。それは[目的]のためだ」といったユーザーストーリー形式で書く。アジャイル開発に詳しいエバンジェリズム研究所の長沢智治代表は「実務ではあまりユーザーストーリーの形式にこだわる必要はない。単なる機能名でもいいので、まずは考えつく限りの全てを出し切る」とアドバイスする。

新日鉄住金ソリューションズのチームがユーザーストーリーマッピングを実施している様子(出所:新日鉄住金ソリューションズ)

 一通り出し切ったら、優先順位が高い機能が上にくるよう並び替える。そして、MVPとなる機能を選択して線を引く。これが初回のリリースとなる。それ以降のリリースで提供したい機能を想定して、2回目以降のリリースの線も引く。

 伊藤忠テクノソリューションズの松村和美流通・EPビジネス企画室アプリケーションビジネス推進部エキスパートエンジニアは、実践的なテクニックとして「特定ユーザーの細かい作業のステップで議論が白熱して、必要な機能を見逃してしまう場合がある。模造紙の左側にビジネスやプロジェクトの目的、ユーザーの一覧を書いておくと、話し合いが偏らずに取りこぼしを防ぎやすくなる」と助言する。

ディスカバリー&フレーミング
最も効果のある解決策を発見

 システムへの要求の全体像だけでは、MVPに実装する機能を見極めるのが難しい。富士通の中村記章デジタルフロントビジネスグループエグゼクティブアーキテクトはこの問題に対応するため、ディスカバリー&フレーミングという手法を用いている。最も効果のある解決策を見つけ出す手法だ。

MVPの見極めに効果的な「ディスカバリー&フレーミング」
最も重要な問題を定義(ディスカバリー)し、それに対する最も効果のある解決策を見つけ出す(フレーミング)。フレーミングの結果がMVPに実装すべき要求となる
[画像のクリックで拡大表示]

この先は有料会員の登録が必要です。「日経SYSTEMS」定期購読者もログインしてお読みいただけます。今なら有料会員(月額プラン)が4月末まで無料!

日経 xTECHには有料記事(有料会員向けまたは定期購読者向け)、無料記事(登録会員向け)、フリー記事(誰でも閲覧可能)があります。有料記事でも、登録会員向け配信期間は登録会員への登録が必要な場合があります。有料会員と登録会員に関するFAQはこちら