製品志向のエンジニア (Japanese Edition)

第7章 製品発見の道程 シミュレーションを通じて

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

顧客体験から始め、技術へと逆算して進めなければならない。技術から始めて、それをどこで売ろうか考えるのは無理だ。

スティーブ・ジョブズ

第6章では顧客を発見した。顧客が誰で、どんな問題を抱えているのかを知りたかったのだ。そうすることで、その人たちに最適な素晴らしい製品とは何かという高次元の主張である製品仮説を洗練させた。

しかし、解決策については深く考えないことにした。

この章では、その扉を開き、製品の発見に焦点を当てる。

つまり、ユーザシナリオを構成するキャラクターとシミュレーションについて、現時点で持っているのはキャラクターだけだ。今こそシミュレーションを書く時だ。

だが、構築しようとしているこの製品や機能は、現時点では存在しない。それに関する物語はこれまで語られたことがない。最初から正しく作り上げる希望があるなら、ユーザが与えられる新たな超能力をどう活用するかを予測する、ミニチュアSF物語を紡がねばならない。

こうして製品の世界からシステムの世界への大いなる旅が始まる。

構想から要件へ

ソフトウェア開発における厄介な問題の一つは、 開発初期に気づかなかった遅れて出てくる製品要件だ。ユーザフィードバックから得られることもあれば、設計・実装中に新たな課題に気づくこともある。これによりロードマップが遅延し、スコープが拡大する。こうした不愉快なサプライズの大きな原因は、不十分な発見作業にある。

驚きを最小限に抑えるため、中規模から大規模プロジェクトで効果的だと私が発見した手順を提示する。チームごとに働き方は異なるため、特定のプロセスや文書テンプレートを規定するのではなく、重点を置くべき重要な点を説明する。

• 製品構想を、 の「北極星シナリオ」と呼ばれるユーザシナリオで完成させる。

• それらの北極星シナリオを、ユースケース集という形で要件にスライスする。

• ロードマップを作成し、要件の重要性が高い最初のマイルストーンに焦点を当てる。

• 最初のマイルストーンで構築する内容を提案せよ。詳細なストーリーを具体化せよ。ユーザーフローを示す場合は 、ユーザインタフェースを示す場合は と呼ぶ。

• 選択した各ユースケースに対して詳細なシステム要件を追加し、必要に応じて元の要件にフィードバックする。

• ユーザフローとシステム要件に基づき、達成すべきタスク（ jobs to be done）のリストを作成する。

この段階では、発見から定義へと移行している。定義段階では通常、より詳細な設計が行われ、これについては後続の章で扱う。

どんなプロセスも全てを見通せるわけではない。サイクルの後半で驚くべき事実が明らかになるのは自然だ。しかし、そうした驚きは規模がはるかに小さく、製品にとって致命的でないことを願う。

図7-1は、 の製品発見プロセスを3つの文書に分割したワークフローを示している：

プロダクト概要

全員の目標を一致させるための「 構想文書」を作成する。これは「問題概要」や「ワンページ資料」と呼ばれることもある。最低限、製品テーゼ／アンチテーゼとターゲット層（第6章）、追跡すべき目標または製品メトリック（第5章）、後述する「北極星シナリオ」を含む。 ダブルダイヤモンドプロセスモデルでは、発見の障害を取り除くことが目的だ。

プロダクト要件文書

長期的な視点だけでなく、最初の成果物やマイルストーンを提案しつつ、指示性を最小限に抑えながら、そのような製品が持つべき属性を具体化する。目標は定義の障害を取り除くことだ。 ...