新サービスの要件が固まらずシステム開発に着手できない――。こんな言い訳はもう通用しない。要件が曖昧だろうとシステムは作れる。ITエンジニアが採用する人気の手法を紹介しよう。
デジタル変革や新サービス開発では、やりたいことがたくさん出てくる。だが、最初に出てくる要求は、曖昧で雑多な「アイデア」に過ぎない。システム開発に進むには「こうしたシステムを作れば変革や事業が成功するだろう」とプロジェクトの関係者が納得した、確度の高い「仮説」を立てる必要がある。経験豊富なITエンジニアが試行錯誤を繰り返して、その方法を編み出した。
具体的には、プロジェクトの目的を明確にし、実装すべき機能の候補を見つけ出すフェーズを設ける。実施するのはプロジェクトの最初。新しい体験やサービスを創り出す方法論「デザイン思考」と、新事業創出の方法論「リーンスタートアップ」を、システム開発向けにカスタマイズして使うのがポイントだ。
デザイン思考やリーンスタートアップは事業企画や事業計画の方法論のため、システム開発で利用するには過剰な面もある。グロース・アーキテクチャ＆チームスの浅木麗子執行役員は「方法論のうち、システム開発に役立つ部分を利用する。部分的であっても、事業の全体像を意識しながら作業できるメリットが大きい」と話す。デジタル変革や新サービス開発では、事業として成立させることも求められるからだ。
5日でアイデアを仮説に変換
アイデアを仮説にするフェーズの流れを理解するため、新日鉄住金ソリューションズのデジタル変革担当部門「BXDC（Beyond Experience Design Center）」が実践している「デザインスプリント」を紹介しよう。全5日間で構成され、1日ごとに仮説へ近づいていく。
1日目は現状業務とユーザーについての「理解」を実施する。まずはエンドユーザーへのインタビューを実施。これを基に開発担当とビジネス担当が話し合って、取り組むべき課題を決める。
2日目は課題を解決する案を出し合う「発散」を実施する。開発担当とビジネス担当によるブレーンストーミング（自由に意見を述べてアイデアを生み出す会議の方法）で、できるだけ多くの案を出す。
3日目は有力な解決策を「決定」する。開発担当とビジネス担当が話し合って、1～2個の課題解決案（システムの機能）に絞り込む。これがシステム開発の仮説に当たる。
4日目は動くモックアップを作成する「試作」、5日目はモックアップのテストをする「評価」だ。エンドユーザーに評価してもらい、仮説の確度を検証する。
「4日目の試作を除いて、ビジネス担当と開発担当がそろって参加しないと意味がない」（新日鉄住金ソリューションズの斉藤康弘システム研究開発センターBXDC上席研究員UXデザイナー）。課題や仮説を皆で認識して、プロジェクトの目的を明確にするのが狙いだからだ。
作業を効率的に進めるには、手法やツールの活用が欠かせない。以下では、デザイン思考やリーンスタートアップの手法やツールの中から、多くのITエンジニアが活用しているリーンキャンバス、カスタマージャーニーマップ、プロトタイピングツールの3つを紹介しよう。
リーンキャンバス
顧客と課題、解決策を明確化
リーンキャンバスとは、ビジネスモデルの概略を1枚の紙にまとめる手法だ。紙を9つの領域に分け、マスを埋めていく。グロース・アーキテクチャ＆チームスの浅木執行役員はリーンキャンバスの使い方を独自にアレンジして、顧客セグメント、課題、ソリューション、主要指標の4つのマスを利用する。
最初は「顧客セグメント」を検討する。ブレーンストーミングでシステムのユーザーはどんな人や組織なのかを話し合い、付箋に書いて貼っていく。一通り出たら付箋をグループに分けて、重要と思うセグメントを3つ選ぶ。「実際のプロジェクトでは顧客セグメントや解決したい課題があらかじめ決まっている場合が多い。その場合は、まずは決定事項に基づいて顧客セグメントを書き出せばいい」（浅木執行役員）。
続いて「ユーザーが今困っていること」についてブレーンストーミングで話し合い、付箋に書いて「課題」のマスへ貼り付けていく。一通り挙げたら、課題の緊急性を検討して、ユーザーが困っている順に付箋を並び替える。ユーザーが課題解決のために使っている代替品があれば、その名称も付箋に書いて貼る。
挙がった課題と優先順位を見ながら、顧客セグメントに「アーリーアダプター（サービスを今すぐ欲しいと思う人）」を書いた付箋を追加する。そして、アーリーアダプターにとっての緊急性を考え、課題を上位3つに絞り込む。
最後に「ソリューション」のマスに課題に対する解決策の上位3つを挙げる。「ゼロから検討するなら、どういう機能があれば課題を解決できるかを話し合う。実際のプロジェクトでは、機能の候補一覧が最初にある場合が多い。その場合は、課題に対応する機能の候補は何かを検討する」（浅木執行役員）。ソリューションとセットで、リリース後に計測すべき指標を「主要指標」のマスに挙げていく。
リーンキャンバスの本来の主役は「独自の価値提案」のマスだが、浅木執行役員は「可能ならば書くという程度にしている」という。システムの価値を明快な1文で表すのが教科書的なセオリーだが「大企業だと一言では書けないことが多いし、関係部門が多くて社内調整が難航することもある」と明かす。開発するシステムのイメージを統一するメリットがある半面、実務ではやぶ蛇になる恐れがある点に注意しよう。
