アプリ開発の本当のスケジュール：アイデアからローンチまで

アプリの開発期間を10社に尋ねれば、自信に満ちた答えが10通り返ってきますが、そのどれ一つとして本当ではありません。正直に言えば、初日に正確な期間を告げられる人はいません。しかし、実際にソフトウェアを世に出したことのある人なら、その「かたち」を語れます。どんな段階があり、どれが静かにカレンダーを食い潰し、どこでご自身の判断が物事を加速させたり止めたりするのか。これがその「かたち」を率直に書き出したものです。

私は、スケッチからApp Storeまできれいに一直線に進むことを期待してアプリ案件に臨む中小企業の経営者を数多く見てきました。ところが実際に得られるのは、いくつもの停滞と突然の跳躍の連続のように感じられるものです。何も起きていないように見える数週間が続き、ある日突然すべてがかみ合う。そのどれもが、何かおかしいという兆候ではありません。ソフトウェアとはそうやって作られるものです。そして各段階に名前を付けられるようになれば、このプロセス全体は、お金を払って最善を祈るだけのブラックボックスではなくなります。

ですから、現実的な期待値を設定しましょう。業務アプリの絞り込まれた最初のバージョン、つまり広がりすぎたプラットフォームではなく、一つの仕事をうまくこなす最初のバージョンであれば、本格的な着手から実際のローンチまで、おおむね3〜5か月の幅で見ておくのが普通です。その幅のどこに落ち着くかは、技術よりも、どれだけ明確であるか、どれだけ早く意思決定するか、ローンチ前にどれだけ詰め込もうとするかで決まります。順を追って見ていきましょう。

提示された見積もりがおそらく間違っている理由

「6週間」という数字は、まったくの嘘というわけではありません。それは誰もが思い描ける部分を作るのにかかる時間です。画面。ボタン。デモできるもの。その数字が静かに無視しているのは、目に見えるアプリの周りにあるすべてです。意思決定、データ、すでにお使いのツールとの連携、テスト、アプリストアの審査、そして避けられない「実は、これもできない？」のひと回りです。

考え方として役立つのは、コーディングがボトルネックになることはまれだという点です。ボトルネックは明確さです。開発者が判断を待つ1時間、つまりどの決済事業者か、予約がキャンセルされたら何が起こるか、誰が何を見られるか、を待つ1時間は、そのままスケジュールがずれる1時間です。早く終わる案件は、最高の技術者がいる案件ではありません。経営者が質問に2週間ではなく1日で答える案件です。

ですから以下の各段階を読む際は、ボールがあなたのコートにある瞬間に注目してください。そこが、案件が勢いを保つか、メール一通の未返信で静かに3週間止まるかの分かれ目です。スケジュールは共同の責任であり、人が見くびりがちなのはまさにクライアント側の半分です。

段階1：要件定義とスコープ策定（1〜3週間）

誰かが1画面でも設計する前に、進捗には見えないのにすべてを左右する段階があります。何を実際に作るのか、そしてより重要なこととして何を作らないのかを見極めることです。ここで漠然としたアイデア（「顧客向けのアプリ」）が、バージョン1のための具体的で完成可能な機能リストになります。

うまくやれば、要件定義はほとんど対話と難しい問いです。誰がどの端末で使うのか。見事にこなさなければならない一つのことは何か。バージョン2まで待てるのは何か。良いパートナーはここで押し返してきますし、そうしてほしいものです。いま削る機能はすべて、取り戻せる週数になります。成果物はたいてい、短い文章のスコープと粗いワイヤーフレームで、手に取ってそう、これだと言えるものです。

段階2：デザインとプロトタイプ（2〜4週間）

ここでアプリは、本物のコードが一行も書かれて縛られる前に、見てクリックできるものになります。デザイナーはワイヤーフレームを本物の画面に仕上げます。色、流れ、使ったときの実際の感触を、たいていはご自身のスマートフォンでタップして進めるインタラクティブなプロトタイプとして作ります。

この段階が値千金なのには理由があります。デザインの変更は安く、作り込んだソフトウェアの変更は高いからです。プロトタイプでボタンを動かすのは5分。コーディングされ、テストされ、データに接続された後で動かすと1日かかることもあります。ですからここは、こだわり、数名の実際のお客様やスタッフに見せ、「ああ、これは誰も分からない」という問題を、まだ無痛で直せるうちに捕まえる場面です。

この段階が長引く最も多い原因はデザイナーではなく、あなた側の迷いです。終わりのない細かな手直しの応酬や、決して意見の合わない拒否権を持つ3人。誰が承認するかを早く決め、フィードバックを少しずつではなくまとめて渡せば、この段階は引き締まったままになります。

段階3：構築（6〜12週間）

ここは「アプリを作る」と聞いて誰もが思い浮かべる部分で、単一の工程としては最も長い区間です。ただし、最初の2段階がきちんと行われていれば、最も予測しづらい区間になることはまれです。開発者はアプリを塊ごとに作り、たいていは短いサイクルで進めます。3か月姿を消して完成品とともに現れるのではなく、1〜2週間ごとに動く部分をご覧いただきます。

そのリズムが大切です。あなたには、進捗報告ではなく、本物の動くソフトウェアに早くから反応していただきたいのです。4週目に予約フローを実際に使えるようになれば、どんな仕様書でも捉えられなかったことに気づきます。そしてそれを4週目に直すほうが、10週目に直すよりはるかに安く済みます。良い構築プロセスは、最後だけでなく、アプリを継続的にあなたの目に見える状態にします。

構築を静かに引き伸ばすもの

何よりも構築を膨らませるものが二つあります。一つ目は連携です。アプリが話さなければならない外部システム（決済事業者、既存の予約ツール、会計ソフト、配送サービス）はそれぞれ作業を増やし、それぞれが独自の驚きを投げてきます。二つ目はスコープクリープです。一つひとつは些細に思える小さな追加が絶え間なく続き、合わさるとローンチを1か月先延ばしにします。どちらも管理できますが、それは到来を見据えている場合に限ります。

• 外部連携はそれぞれ数日、ときに数週間を加えます。無料だと思い込まず、明示的に予算に入れてください。
• 「もう一つだけ小さな機能を」は、ローンチ日を逃す断トツで多い原因です。
• 実データはテストデータより込み入っています。表計算が静かに見逃していた例外を扱う時間を見込んでください。
• ユーザーアカウント、決済、通知は見かけによらず奥が深く、いつも見た目より高くつきます。
• あなたがチームに渡すべき承認やコンテンツ（ロゴ、文章、法的文言）は、バグと同じくらい確実に構築を止めます。

段階4：テストと修正（2〜4週間）

存在を忘れられがちで、現れると恨まれる段階がこれです。アプリが完成したら、さまざまなスマートフォンで、悪い回線で、作っていない人たちによって、誰も予期しなかったことをされながら、徹底的に試さなければなりません。テストは形式ではありません。お客様が信頼するアプリと、最初のクラッシュでアンインストールされるアプリの分かれ目です。

ここでバグや粗のリストが浮かび上がると見込んでください。それは構築がまずかった兆候ではなく、この段階のまさに目的です。すぐ直せるものもあれば、見直すべき判断をあらわにするものもあります。これをうまく扱うチームは、これを正常で計画された作業の一部として扱います。緊急事態でもなければ、ローンチが迫っているからと飛ばすものでもありません。テストを飛ばしても時間は節約できません。バグをあなたのテスト端末からお客様の端末へ移すだけで、そこでは修正に10倍の費用がかかります。

段階5：ローンチとアプリストアの待ち時間（1〜2週間＋審査）

ローンチは単一の瞬間というより、慎重な段階的展開です。ウェブアプリなら、タイミングは完全にあなたの管理下にあり、準備ができたらスイッチを入れます。AppleのApp StoreやGoogle Playに出すなら、スケジュールの一部を彼らに委ねることになります。審査プロセスは1日から1週間超までかかり、ときには修正点とともに差し戻されます。これはお客様に約束したローンチ日が不意打ちにならないよう、前もって知っておく価値があります。

賢いローンチの仕方は、全顧客への大々的なお披露目ではありません。まず小さなグループへの静かなリリースです。好意的なお客様やご自身のスタッフ数名に出し、全員が見る前に現実世界の問題を捕まえます。それから扉を広げます。退屈なほど何事もなく感じられるローンチは、うまくいったローンチです。

1. 1
   小さなグループへソフトローンチ

   まず好意的なユーザーやスタッフ数名に公開します。実際の利用は、リスクを目一杯下げた状態で、テストが見逃したものを見つけます。
2. 2
   アプリストアに出すなら早めに申請

   審査の時計を握るのはAppleとGoogleで、あなたではありません。審査の遅れや却下が約束した日を吹き飛ばさないよう、余裕をもって申請してください。
3. 3
   最初の1週間を注意深く見守る

   素早く対応できるよう誰かを待機させてください。最初の1週間は、どんなテスト環境でも出てこない現実世界の例外をあらわにします。
4. 4
   ローンチ前に翌日以降の作業を計画する

   アプリはローンチ時点で『完成』することは決してありません。避けられない小さな修正と最初のフィードバックに誰が対応するかを、前もって取り決めてください。

スケジュール全体をまとめる

端から端までつなげると、これらの段階は現実的な全体像を描き出します。どれも特殊なものではありません。人がつまずくのは、地味な段階、つまり要件定義、テスト、アプリストアの待ち時間が、丸め誤差ではなくカレンダー上の本物の時間だと忘れることです。絞り込まれた最初のバージョンが、月単位でだいたいどう分布するかを示します。

足し合わせれば、本物の最初のバージョンに3〜5か月が正直な幅である理由、そして6週間を約束する人々が「アプリ」の意味を静かに定義し直している理由が見えてきます。これは悲観ではありません。実際に守れる日付と、案件の間ずっと謝り続ける日付の違いです。

本当に速める方法（と、そうでない方法）

速く進めることはできますが、本当のてこは人が手を伸ばしがちなものではありません。半ば定義の曖昧な案件により多くの開発者を投入すると、たいてい速くなるどころか遅くなります。正直な加速装置は地味です。何を外すかを決める、質問に素早く答える、そして構築途中で何かを足したい衝動に抗うことです。

断トツで大きいのは、容赦のないスコープです。最初のバージョンが小さく明確であるほど、早くローンチします。そして稼ぎを生む公開済みのアプリは、さらに2か月の計画よりも2週間で多くを教えてくれます。後からいつでも足せます。誰も望まなかった機能の構築に費やした月日は、取り戻せません。

声に出して言う価値のある関連した真実があります。そもそもすべてが受託アプリである必要はありません。本当の問題が、自動化で静かに片付くひと続きの手作業で、アプリが要らない場合もあります。良いパートナーは、より大きな構築を売りつけるのではなく、それが当てはまるときにはそう告げます。最も安いアプリとは、作らずに済んだアプリだからです。

よくある質問