Develop：実装するのはプログラムではなく価値【第10回】

仮説は必ず検証する

　このように、Developの基本的な流れは、「MVP仮説」を基に「実証実験」を実施し、「仮説」として考えたことの正当性を「実証」する。このときの検証方法には、大きく2つのアプローチがある。

（1）インタビューによるアプローチ ：利用者に実際にインタビューし、その反応をKPI（重要業績評価指標）とする（定性）
（2）データ指向のアプローチ ：プロダクトを実際に利用してもらったときのアクセスログや記録をKPIとする（定量）

　それぞれの仮説が、どの手段によって検証可能であるかを示したのが図1である。仮説の検証方法は、予め検討しておく必要がある。

図1：仮説と、その検証方法

　実際にMVP（動くプロダクト）を開発し、仮説検証を行う場合には、操作ログなどのデータから分かることも多いため、操作ログの取得も忘れずに実装する必要がある。プロダクトから考えていると、プロダクトバックログである要件には取り組みにくいため、機能一覧に出てこない可能性が高いからだ。

　なお今回は詳細には触れないが、モックアプリや、代替えのアプリケーションシステムで検証する場合は、データ指向のアプローチは利用できないため、インタビューで検証する。

フィードバックを「ユーザーストーリー」として管理する

　MVPの開発において最も重要なことは、ステークホルダーからプロダクトへのフィードバックを得ることだ。このフィードバックや、そこから生まれた新たな仮説は、サービス仕様や機能に落とし込むために「プロダクトバックログ」として表現する。

　アジャイル開発では、プロダクトバックログを「ユーザーストーリー」という形で表現する。ユーザーストーリーは5W1Hで表現できる。

　例えば、「配送担当者は、朝、配送拠点で、タブレット端末を使用して、顧客に効率的に配送するため当日配送する荷物の一覧を取得する」というストーリーは、表1のような5W1Hになる。

　IBM Garageでは、「ユーザーストーリー」は1日単位で実装できるレベルまでとしている（図2）。アジャイル開発に代表されるスクラムでは、開発規模を表す「ストーリーポイント」が大きすぎないことが推奨されている。IBM Garageの規定は、1回のスプリント期間をすべて費やすストーリーが無駄にならないようにするためだ。

図2：バックログの粒度とやり直しの影響

　IBM Garageの制限は、筆者の経験では、初期リリース以後の運用と保守開発を同じチームで実施する際にメリットが大きかった。

　具体的には、小規模なアプリケーション開発のため、通常時の日次の運用作業量は多くなく、運用担当者が開発も担当していた。ただスプリント中のインシデントに対する問い合わせ量によっては、担当するストーリーの実装が遅れがちになっていた。

　その理由は、大きなストーリーポイントの作業を担当していたからだった｡その後、ストーリーポイントのレベルを極限にまで小さくすることで、スプリント内で中途半端に実装できない状況を避けられた。かつスプリントごとのストーリーポイントを正確に見積もれるようになった。