お客さんは「本当に欲しいもの」を最初から言えない — ジョブ理論で考える要件定義の進め方

要件が増えていく

「最初に決めた通りに作る」。仕事の進め方としては当たり前に聞こえる。でも実際には、途中から「やっぱりこれも欲しい」「ここはこうしたい」が出てくることが多い。

システム開発では、これは日常的に起きる。スコープが膨らむ。スケジュールが押す。普通に考えれば、最初の要件定義が甘かった、管理ができていなかった、という反省になる。

でも、本当にそうだろうか。

お客さんは自分のジョブを説明できない

経営学者のクレイトン・クリステンセンは「ジョブ理論」という概念を提唱している。お客さんは製品やサービスそのものではなく、「片づけたい用事 (ジョブ) 」を解決するために買っている、という考え方だ。

この理論で重要なのは、お客さん自身も最初からジョブを正確に言語化できるとは限らないということだ。「こういう機能が欲しい」と言えても、「なぜそれが欲しいのか」「本当に解決したい課題は何か」は、本人の中でもぼんやりしていることが多い。

つまり、最初の要件定義でお客さんが言ったことは、ジョブそのものではなく、ジョブの「表面」にすぎない可能性がある。

厄介なのは、お客さん自身はそう思っていないことだ。「自分は何が欲しいかわかっている」と確信を持って要件を伝えてくる。曖昧なことを言っているわけではない。明確に、具体的に、「こうしてほしい」と言っている。だからこちらも「要件は明確だ」と受け取る。双方が確信を持って進む。そして出来上がったときに「思っていたのと違う」になる。

モックを見せて、初めて出てきた言葉

あるWebシステムの案件で、こんなことがあった。

お客さんからは「今の業務のやり方をそのままシステムに載せてほしい」と言われていた。既存のやり方をシステム化する、ストレートな話だと思っていた。

まずモックを作り、一部だけ先に動くものを見せた。動くものを見せると、それまで手作業でやっていた業務の一部が自動化される。すると、手作業に埋もれていた本質的な課題が見えてきた。お客さんの表情が変わった。「あ、最初にお伝えしていたことは本質じゃなかったですね。本当にやりたかったのはここだったんだ」。

手作業がなくなったことで、視界が変わったのだと思う。「今の業務をそのままシステムにする」のではなく、「業務のやり方自体を変えたかった」。それがお客さんの本当のジョブだった。ただ、手作業に追われている間はそこに気づけなかった。モックが確認ツールではなく、お客さんの視界を変える装置になった瞬間だった。

こちらとしても、情報が増えて提案しやすくなった。もちろん要件は増えた。でも、悪いことだとは思わなかった。要件が増えたのではなく、要件が「見つかった」のだ。

似たことは他の案件でもあった。お客さんの最初の言葉は、たいていジョブの表面だ。機能の話をしているが本当は業務の課題がある。担当者の要望と経営層の目的がズレている。言語化できている部分だけを伝えてくれるが、その奥にあるジョブは、触ってみないと出てこない。

要件が増えるのは「発見」のプロセス

この経験から思うのは、要件が増えることを「スコープ管理の失敗」と片づけるのはもったいない、ということだ。

もちろん、際限なく広がるのは問題だ。でも、初期段階で要件が増えるのは、お客さんのジョブが見つかりつつあるサインでもある。モックや動くものを見せたからこそ、「本当に欲しかったもの」が出てきた。最初から全部を決めようとしていたら、お客さんのジョブに気づけないまま作り始めていた可能性がある。

「知らなかったこと」が出尽くしたら切り替える

実際の進め方としては、最初は試しながら探るフェーズ (アジャイル) で進め、要件が固まったら決まったものを着実に作るフェーズ (ウォーターフォール) に切り替えた。

問題は、いつ切り替えるかだ。

振り返ると、これは「無知の知」の問題だと思う。

最初の段階では、お客さんもこちらも「わかっている」と思っている。要件は明確で、あとは作るだけだ、と。でも実際には、お互いに「知らないことを知らない」状態にある。何がわかっていないかが、わかっていない。

モックや動くものを見せると、「知らなかったこと」が表に出てくる。お客さんは「本当にやりたかったのはここだった」と気づく。こちらも「この要件の裏にはこういう課題があったのか」と理解する。これが探索フェーズだ。

切り替えのタイミングは、この「知らなかったこと」が出尽くした感覚があるかどうかだ。新しいモックを見せても、要件が変わるのではなく、細部の調整になっていく。大きな発見が出なくなったら、探索は終わりだ。あとは決まったものを着実に作ればいい。

遠回りに見えて、近道になる

結果として、トータルのコストは最初から全部決めて作るより少なく済んだと思う。手戻りが減るからだ。

最初に全部決めようとすると、お客さんのジョブが見えないまま作り始める。結局「思っていたのと違う」になり、やり直しが発生する。探索に時間をかけた分、構築フェーズでは迷いなく進む。遠回りに見えて、近道になる。

要件が増えるとき、それは「管理の失敗」だろうか。それとも「発見のプロセス」だろうか。

そしてお客さんとあなたの間に、まだ「知らないことを知らない」は残っていないだろうか。

もう少し深く知りたい人へ

ジョブ理論は、クレイトン・クリステンセンがハーバード・ビジネス・スクールで提唱した概念だ。有名なのはミルクシェイクの事例である。あるファストフードチェーンがミルクシェイクの売上を伸ばそうとした。味を改良し、サイズを変え、価格を調整した。しかし売上は伸びなかった。クリステンセンのチームが調査したところ、朝にミルクシェイクを買う客の多くは「長い通勤時間を退屈しのぎに過ごしたい」というジョブを片づけるために買っていた。競合はドーナツやバナナであって、他社のミルクシェイクではなかった。

この事例が示しているのは、お客さんに「どんなミルクシェイクが欲しいですか」と聞いても正しい答えは返ってこない、ということだ。お客さんは自分のジョブを製品の言葉で語る。「もっとおいしいミルクシェイクが欲しい」と言う。でも本当のジョブは「通勤時間を快適に過ごしたい」だった。

本文で触れた「今の業務をそのままシステム化してほしい」も同じ構造だ。お客さんは解決策の言葉で要件を語る。でも本当のジョブは「業務のやり方を変えたい」だった。最初の要件定義だけで本当のジョブにたどり着くのは難しい。だからこそ、モックや動くものを使って、お客さん自身が「本当にやりたかったこと」に気づくプロセスが有効になる。

本文で紹介した「アジャイル的に探索し、ウォーターフォールで作る」というアプローチは、リーンスタートアップの思想とも共通する。エリック・リースは、不確実性が高い段階ではMVP (実用最小限の製品) を素早く作り、顧客の反応を見て学ぶことを提唱した。探索フェーズでモックや一部動くものを見せるのは、まさにこのMVPの考え方に近い。不確実な段階で完璧な計画を立てようとするのではなく、小さく試して学ぶ。ジョブが見つかってから本格的に作る。この順序を守ることで、手戻りのコストを大幅に減らせる。

参考文献

• クレイトン・M・クリステンセン 『ジョブ理論——イノベーションを予測可能にする消費のメカニズム』
• エリック・リース 『リーン・スタートアップ——ムダのない起業プロセスでイノベーションを生みだす』