DXサービスの開発において「ユースケース」がめちゃくちゃ大切な理由
DXサービス開発で「ユースケース」が重要である
DXサービスの開発において、「ユースケース」が大事という話を私の開発チームメンバーによく話している。
どれくらい大事かというと、私はDX関連のサービス開発において、二言目には「ユースケースは？」と発し続ける程度である。ユースケースを語れない倍は開発を断ることも多い、。
ユースケースとは、「どんな状況にいるどんな人が、この機能をどのように使うのか」を具体的に示したものである。
ユースケースがある世界とない世界の例
例えば、町工場向けの図面管理サービスを開発するとする。
機能概要としては
「過去案件の図面が登録されており、会社名と期間(範囲)で検索すると過去の図面が取得できる」
ものである。
この機能概要では、何を作れば良いか分かるが誰がどんな状況で使うのかが分からない。
開発メンバーは利用するシーン(ユースケース)が分からないなりに、手探りで機能開発を進める。
一方で、下記のように書かれていたらどうだろうか。
◾️現状
・町工場において毎月1000件の新着見積依頼が来ており、社員2名で捌く必要がある。1件最大30分かかる。
・実は2割にあたる200件がリピート品(過去に依頼受けたことがある)であり、過去の見積を探し出せれば1分で終わる
・ただし過去の見積依頼は10万件以上溜まっているため探し出せず、なくなく再度見積をしている。
◾️今回のプロダクト/機能
・見積依頼を担当している社員が「去年の夏くらいに見積依頼受けたことがあるな」と思った時、図面コネクトを開く
・図面に書かれている会社名と期間で絞り、該当の見積依頼を探す
・図面を見つけたら、登録されている金額を確認し、見積金額算定の参考にする
このように書かれていれば、
・なぜ会社名、期間で検索する必要があるか、他に必要に必要な検索項目がないか考える
・万が一金額を表示する項目が抜けていたら、仕様書・実装・テスト設計で気付く
・エンジニアのセルフチェック、QAでユーザー想定通りのシチュエーションでテストする
など、開発チームが必要な機能・気を付けるべきことに気付いて自走して開発を進めることが可能になる。
その結果、ユーザーにとって重要な価値をより正確に早くリリースすることができる。
ユースケースがDXサービスにおいて特に重要なのは、開発者自身がサービス利用者でないから
ユースケースがDX開発で特に重要なのは、大半の開発メンバーがサービス利用の当事者ではないためである。
エンタメやゲームなどのサービス開発であれば、「あのゲームのこの機能のようなもの」といった形で、開発メンバーが直感的に理解できることが多い。
しかし、建設業・製造業・ホテル業界などのDXサービスでは、多くの開発者が「どんな人がどんなふうに使うのか」を把握できていないことが多い。
現場での業務を経験していないメンバーが大半を占める中で、利用者の視点を理解するのは難しい。
このギャップを埋めるために、ユースケースは「理解を助けるドキュメント」として不可欠となる。
成長していたはずのDXプロダクトが行き詰まるのは、ユースケースが伝わらないまま開発が進行していくから
DXプロダクトは、成長を続ける中でユースケースが十分に共有されていないと品質が行き詰まることがある。
開発初期は、ドメイン知識の深いメンバーが少人数で開発を進めることが多い。市場の課題を的確に捉えた機能開発が行われ、プロダクトは順調に成長する。
しかし、組織やプロダクトの規模が拡大するにつれ、Web開発の経験をメインのバックグラウンドに持つエンジニアが増える。
当然業界や業務に関する知識は浅く、ユースケースが理解されないまま開発が進行する。
ユースケースが開発チームに適切に伝えられていねいため、なんのために使われるかいまいち理解していない機能実装を行い、ユーザーが実際のユースケースに沿って使った結果、正常系で不具合を踏み抜く。
正常系の不具合をエンジニア、QAメンバーが指摘されても、そもそもどう使われるかイメージごついているいないため再発防止がとりにくい。
組織が強みとしていたはずのドメイン理解がなくなり、プロダクトのドメインフィットがむしろ弱みとなっていく。
DXサービスのユースケースを開発組織に浸透させるには、PdMの立ち回りが重要
拡大している組織でユースケースが浸透した状態で開発するには、
・PdMが現場でのユースケースを理解・記述する
・ドメイン知識を啓蒙する勉強会を開く
の大きく2つがある。
ドメイン知識を啓蒙する勉強会は組織文化形成としては有用ではあるが、開発組織の土台としてはユースケースの理解・開発ドキュメントに記述することについてこの記事では触れていく。
ユースケースで押さえるべきポイント
ユースケースを作成する際には、下記を明確に記載する必要がある。
[Who]どの業界で、どのような会社の、どのような人が使うのか
[What]利用者が抱える課題や困りごと
[When]どのタイミングで、どのような目的で使うのか
[How Much]利用頻度・人数・データはどれくらいか
上記フォーマットが大事というよりは、
「ドメインの理解が浅い開発者が、誰のどんな困り事をどう解決しようとしているか分かるか」
が全てである。
事業ドメイン理解が深い開発メンバーがほとんどの組織では記述は簡潔で良いかもしれない。新規メンバーが多い組織では、そもそもどのような業界かから丁寧に解説が必要かもしれない。
組織フェーズによっても必要なユースケースの説明は異なるため、組織状況を見て情報粒度を都度調整していく必要がある。
アンチパターン①: 操作手順書に終始している
例えば、下記をユースケースとして提示された場合、「ドメインの理解が浅い開発者が、誰のどんな困り事をどう解決しようとしているか分かる」だろうか。
1.管理者がシステムにログインする。
2.見積もり検索画面を開く。
3.検索欄にキーワードを入力して検索する。
4.検索結果から必要な見積もりを選択する。
5.詳細画面で見積もり金額を確認する。
想定されている正常系テストの流れこそ分かるが、誰が何をするためのシステムなのかは伝わらない。
・見積金額はとりあえず画面に出ていればいいのだろうか、他に出す項目はないだろうか
・他に検索で必要な項目はないのだろうか
など軽く考えはするものの、考えるための情報量不足で一旦蓋をして言われた通りの実装・テストを進行するのではないだろうか。
アンチパターン②: 数字がない
下記で書かれていた場合、エンジニアは考慮すべき懸念点を洗い出して実装に盛り込めるだろうか。QAは気にするべき数値関連のテスト項目を反映できるだろうか。
◾️現状
・町工場で見積もり依頼が定期的に届いており、少人数の社員が対応している。
・過去の見積もりを探せばすぐに終わるケースがあるが、件数が多くて探し出せないことがよくある。
◾️今回のプロダクト/機能
・見積もり担当者が「前にも似たような見積もりを受けたな」と思った時に、図面を検索して参考にする。
・図面に書かれた会社名と期間で検索でき、過去の見積もりを探し出して金額を確認する。
実際の例としては10万件入れた場合の検索テストは必須であり、検索においても適切にindexが効いているかをチェックが必要である。
一方で数字が全く異なり、多くても100件未満しか登録されない&滅多に更新されないのであれば、検索効率の最大化のためにメモリに値を載せて処理することも検討できる。
アンチパターン③: 利用者についての説明がない/少ない
極端な例だが、利用者についての説明がほとんど書かれていない下記だったらどうだろうか。
◾️現状
・見積もり依頼が多く、作業に時間がかかっている。
・過去の見積もりが蓄積されているが、探すのが難しい。
・リピート品があるが、再度見積もりをしている。
◾️プロダクト/機能
・過去の見積もりを会社名と期間で検索できる機能を追加する。
・見積もり金額を確認して参考にできるようにする。
こんな例はないだろうと思うかもしれないが、
・利用している企業が大企業から中小企業まで幅広くいる。組織構造が全然違う
・複数の業種の企業が使っている。業種ごとに使い方が全然違う
ことはザラであり、どのユーザー層の話をしているかでユースケースの解釈が大きく変わってくる。
終わりに: ユースケース理解が高い開発組織は、開発のROIが高い
DXプロダクト開発ではやりたいことが溢れているため、ユースケースの理解が開発のROIに直結する。
ユースケースを知っていれば、工数を特に割くべきポイントを見極められる
やりたい機能がたくさんある中で、エンジニアの実装工数やQAのテスト工数は、特に大事なところにより多く割き、あまり使われない/重要でないところの工数は抑えることが生産性の向上に直結する。
エッジケースと思われた部分が、実は重要な利用シーンであることがある。
一方で、リソースを注いだ機能が、実際にはほとんど使われないケースもある
ことを考えると、ユースケースが伝わっていれば、開発メンバーが工数の使い所を自発的に判断できる。
ユースケース理解があると仕様の最適化が可能
エンジニアがユースケースを理解していれば、「この仕様ならもっとシンプルで良いのでは？」と提案できる。
私が図面コネクトを開発責任者として開発した際は、
「その機能のユースケースは？言えないなら開発対象外で。」
機能を50%落として開発した。
機能の50%を削ぎ落としても本質を外さない開発になっていた。
