バージョン1に含めるものを決める方法

あらゆるアプリ開発プロジェクトは、最初のリリースに収まりきらないほどのアイデアから始まります。それは健全なことです。問題になるのは、それらすべてをバージョン1に詰め込もうとして公開日が遅れ、最も重要な部分への注力が疎かになってしまうことです。スコープ定義とは、最初にリリースするものを意図的に選ぶ作業です。

コアとなる役割から始める

アプリが果たすべき、たった1つの核となる役割を書き出してください。次に、ユーザーがそれを完了するための最短ルートをたどります。アプリを開き、必要ならサインインし、目的を果たし、完了を確認する。このルート上にある画面はすべてスコープ内です。それ以外の画面には、含める明確な理由が必要です。

アイデアを3つに分類する

すべての機能アイデアを、次の3つのいずれかに分類します。

• 必須（Must have）： これがないとコアとなる役割を果たせないもの。
• 推奨（Should have）： コアとなる役割を明らかに向上させ、実装の負荷が小さいもの。
• 後回し（Later）： どんなに良いアイデアであっても、それ以外のすべて。

最初の「必須」は厳しく判断してください。「ユーザーが期待するだろう」機能であっても、それがなくてはアプリが成立しないのでない限り、必須ではありません。2つ目の「推奨」は調整の対象であり、一部が先送りになっても問題ありません。

目に見えない作業を計算に入れておく

機能一覧には現れなくても、リリースには欠かせない項目があります。サインインとパスワードのリセット、アカウント削除、プライバシーポリシー、エラー表示や空の状態（エンプティステート）、設定画面、クラッシュレポート、アナリティクス、ストア掲載情報などです。これらを合わせると、初回リリースの大部分を占めることもあります。最後の2週間で慌てないよう、最初から計画に組み込んでおきましょう。

可能な部分は手作業から始める

一部の機能は、裏側の手作業から始めることができます。新規アカウントの承認は、担当者が毎朝リストを確認することから始められます。週次レポートは、手動でクエリを実行することから始められます。その機能が実際に使われ、どのように利用されるかが分かってから自動化してください。本格的に構築する前に、人々が実際に必要としているものを把握するための低コストな方法です。

「後回し」の置き場所を作る

後回しにするアイデアには置き場所が必要です。そうしないと、いつの間にか開発に入り込んできます。次のバージョンのためのシンプルなリストを用意し、リリース後に実際の利用状況を踏まえて見直してください。リストの項目の中には、実際には重要でなかったと判明するものもあります。一方で、元のリストのどの項目よりも重要になるものがいくつか見つかるはずですが、それはリリースしてみなければ決して分からなかったことです。

日程を固定し、スコープを柔軟にする

スコープを固定して期日を伸ばすよりも、公開日を固定してスコープを柔軟にする方が期日を守りやすくなります。予定が延びそうなときは、日程を遅らせるのではなく、機能を次のバージョンへと回してください。これによりリリース規模を小さく抑え、より早く実際のユーザーにアプリを届けることができます。そこから有益なフィードバックが得られるようになります。

まとめ

1つの核となる役割、厳選された必須リスト、初日から計算に入れた目に見えない作業、そしてそれ以外のすべての置き場所。機能を絞り込んで丁寧に作られたバージョン1は、実践的な学びをもたらします。すべてをやろうとするバージョン1が、無事にリリースされることはめったにありません。