中小企業が繰り返す、コストのかかるアプリ開発の8つの失敗

うまくいかないアプリプロジェクトには、認めにくい事実があります。コードがおかしく見え始めた頃には、プロジェクトはもう数週間前に失われているのです。中小企業のアプリ開発における高くつく失敗は、キーボードの前ではほとんど起きません。何気ない会話の中で起きるのです。きちんと書き留められなかった要件、「ついでに」と誰かが足した機能、友人が薦めたからという理由で選んだ開発者。その時点ではどれも決断とは感じられません。そのすべてが、あとであなたにコストを払わせるのです。

私は多くの小さな企業が初めてのアプリを発注するのを見てきましたし、後始末の救済を頼まれたことも数知れません。経営者が不注意な人であることはまれです。鋭く、慎重で、事業運営に長けています。しかしソフトウェアには、彼らの仕事人生のどこにも存在しない独自の落とし穴があり、誰も警告してくれませんでした。だから彼らは毎回、ほぼ同じ順番で、同じ8つの落とし穴へまっすぐ突き進んでしまうのです。

これは、すべての経営者が一銭でも使う前に手にしておくべきだと私が思うリストです。理論ではなく、実際に繰り返される失敗と、それぞれのプロジェクトを救えたであろう小さな軌道修正です。これからアプリを作ろうとしている方、あるいはすでに開発の途中で何か違和感がある方は、まずこれをお読みください。その多くは、早く気づけばまだ直せます。

失敗1：誰かが欲しがると証明する前に作り始める

もっとも高くつく失敗は、同時にもっともよくある失敗でもあります。アプリが、人がお金を払う、あるいは使う価値のある問題を解決するという実際の証拠がないうちに、本格的な開発に踏み切ってしまうことです。経営者にはそのアイデアが自明に思えます。もちろん顧客は欲しがるだろう、と。その確信こそが危険なのです。確信は需要の裏づけのように感じられます。しかしそうではありません。

需要の検証とは、友人10人にアイデアが好きか尋ねることではありません。みな親切心から「いいね」と言うものです。検証とは、可能なかぎり小さな版を、実際の状況の中で本物のユーザーの前に置き、彼らが実際に何をするかを観察することです。クリックできる試作、登録数を測るランディングページ、自動化を手作業で装う「コンシェルジュ」版――どれも、勘で作り上げた完成アプリよりも多くを教えてくれます。順番が肝心です。安く需要を証明し、それから高くつく開発をする。これを逆にすると、誰も二度と開かないものを磨くために予算をすべて使い果たしかねません。

失敗2：野心を装ったスコープクリープ

どんなアプリも、最初は無駄なくすっきりと始まります。やがて「ついでに」が始まります。予約画面を作るついでに、ギフト券も扱えないか。ポイント制度も。紹介システムも。一つひとつはそれぞれもっともらしく聞こえます。合わさると、スケジュールと請求額を静かに3倍にし――そしてリリースをはるか先へ押しやって、当初の勢いを消し去ってしまうのです。

解決策は、良いアイデアに「ノー」と言うことではありません。それを取っておくことです。あらゆる輝くアイデアが順番を待つ、目に見える「バージョン2」リストを用意しましょう。これは実務的にも心理的にも効きます。自分のアイデアの居場所が後にちゃんとあると信じられれば、人は最初のリリースに機能を詰め込もうと争うのをやめるのです。最初の版は、一つのことを本当にうまくやるべきで、十のことを中途半端にやるべきではありません。一つの業務フローを完璧にこなすアプリは使われます。すべてを半分しかこなさないアプリは見捨てられます。

失敗3：書かれた要件がない――共有された頭の中の絵だけ

これは噛みつかれるまで見えません。経営者の頭の中には明確なアプリがあります。開発者の頭の中にも明確なアプリがあります。キックオフでみなうなずきます。誰もきちんと書き留めません――そして二つの絵は、ふたを開ければ、一度も同じ絵ではなかったのです。あなたはこれを途中で気づきます。作られているものが思い描いていたものではなく、そして誰が何と言ったかをめぐる言い争いが始まるのです。

100ページの仕様書は要りません。必要なのは、新しく来た誰でも読んで理解できる数ページです。誰がこのアプリを使うのか、その人がアプリで必要とする3つか4つのことは何か、成功した結果はどのようなものか。主要画面のラフなスケッチを添えましょう。それだけです。要件の目的は官僚主義ではありません。記憶と現実がずれ始めたとき――それは必ず起きます――二人がともに指し示せる共有の拠りどころなのです。

失敗4：間違ったやり方で開発者を選ぶ

ほとんどの経営者は、二つの心もとない手がかりのどちらかで最初の開発者を選びます。最安の見積もりか、別業種の誰かからの個人的な紹介です。どちらも運がよければうまくいきます。しかしどちらも、相応の額のお金と、事業の将来の数か月を託す相手を選ぶ信頼できる方法ではありません。

最安の見積もりはソフトウェアでは特に厄介です。見積もりと完成時のコストの開きが、巨大で、しかも見えないからです。手戻りを3周必要とし、2週間姿を消し、他の誰も保守できないコードを残していく安い開発者は、少し高くても一度で正しく仕上げる開発者よりはるかに高くつきます。価格は目に見えるもの。総コストは実際に支払うものです。

実際に確認すべきこと

彼らがリリースし、今も稼働しているものを見せてもらいましょう。可能なら、開発者を同席させずにそのクライアントと話してください。プロジェクト途中の変更にどう対応するかを尋ねましょう。変更は必ず起きるからです。完成時にコードとアカウントを誰が所有するのかを尋ねましょう。答えは常にあなたであるべきです。そして、彼らが良い質問を返してくるかに注意してください。指示を受けるだけの開発者は、間違ったものをきわめて効率的に作り上げます。良い開発者は反論し、あなたの考えの抜けを指摘し、要件を会話の出発点として扱います。固定の買い物リストとしてではなく。

失敗5：開発の予算は組んでも、残りを忘れる

アプリは、印刷したパンフレットのような一度きりの買い物ではありません。餌を与え続ける必要のある生き物です。経営者は決まって開発の予算だけを組み、それ以外は組まず、あとから来るコストに不意打ちされます。ホスティング、アプリストアの手数料、スマホOSの更新に追従するための保守、そして本物の人々が使い始めた途端に避けられない、修正と細かな改善の一巡です。

賢明な目安はこうです。開発にいくらかかろうと、その意味のある一部を、運用の最初の1年のためにもう一度取り分けておくのです。正確な数字はさまざまですが、失敗は普遍的です――リリース当日を、実際にはスタートラインであるのにゴールとして扱ってしまうのです。リリースされたのち、保守する予算がないために静かに見捨てられるアプリは、この分野全体で最も悲しく、最もよくある結末の一つであり、事前の正直な計画で完全に避けられるものです。

失敗6：ユーザーではなく自分のために設計する

あなたは自社を隅々まで知っており、それゆえアプリが使いやすいかどうかを判断するのに最もふさわしくない人物です。あなたには当たり前のこと――専門用語、作業をこなす順番、何も考えずに取る近道――は、初めてのユーザーには理解しがたいものです。経営者には完璧に筋が通り、他の全員を戸惑わせるアプリは、どれほど賢く作られていても失敗です。

処方箋は安く、少しばかり謙虚にさせられます。リリースの前に、本物の人々が使う様子を見るのです。すでに仕組みを知っているあなたのチームではなく――一度も見たことのない実際の顧客やスタッフです。アプリを渡し、課題を与え、何も言わないでください。彼らがためらい、誤って違うところを押し、ため息をつくところ、それがあなたの設計へのフィードバックです。最悪の問題をあぶり出すには5人で十分です。この一手を飛ばすと、誰も見つけられない「送信」ボタンや、挑んだ人の半分を取りこぼす登録フローを抱えたままアプリが世に出るのです。

• テスターには案内ではなく本物の課題を与える――「来週の火曜に予約を取って」と言ったら、黙る。
• 最終的に成功したかどうかだけでなく、手と表情を見る。
• あらゆるためらいを書き留める。間は、内側からは見えない設計上の問題。
• 説明したい衝動を抑える――説明しなければならないなら、それはアプリがやるべきだった。
• 5人でテストし、明らかな失敗を直し、もう一度テストする。

失敗7：必要もないのにiOSとAndroidのネイティブを作る

初日から、iPhoneとAndroidの両方に「ちゃんとした」アプリを、大手ブランドがやるように完全ネイティブで作りたくなる反射があります。ほとんどの小さな企業にとって、それはユーザーが決して気づかない利点のために、2〜3倍のコストと複雑さを払うことです。さらに悪いことに、あなたは今や二つの別々のコードベースを永遠に保守し、将来のあらゆる修正を倍にすることになります。

正しい最初の一手は、そもそもネイティブアプリではないことがよくあります。どのスマホのブラウザでも動くよく作られたウェブアプリや、一つのコードベースから両方のストア版を生み出すクロスプラットフォームの手法は、より速く、より安く市場へ届けてくれます――そして実際の利用がその価値を証明すれば、いつでもあとから完全ネイティブにできます。問うべきは、抽象的に「ネイティブかウェブか」では決してありません。問いはこうです。本物のユーザーが中核の仕事をこなせる、最も小さく、最も安いものは何か? それを作り、そこから学び、そして推測ではなく証拠をもって大きなお金を使うのです。

失敗8：リリースを仕事の終わりと考える

8つ目の失敗は、アプリが公開された時点でプロジェクトは終わったと信じることです。終わってなどいません――そこからが本当のプロジェクトの始まりです。ユーザーの手に届ける計画もなく、彼らの考えを聞く手立てもなく、学んだことに基づいて改善する意図もないアプリは、数か月のうちに色あせていくアプリです。開発は簡単な部分でした。普及こそが難しい部分であり、ほとんど誰もそれを計画しません。

リリースの前に、三つのことを知っておきましょう。人はどうやってアプリの存在を知るのか、彼らが本当に使っているかをどう測るのか、そして次の一巡の作業を推測ではなく現実が導くよう、彼らが語ることをどう集めるのか。どれもお金はかかりません。ただ別の心構えなのです――アプリは仕上げて立ち去るものではなく、保ち続ける関係です。それを理解する経営者は、時とともにより役立つようになるアプリを手にします。理解しない経営者は、リリース当日の急上昇と、長く静かな下降を手にするのです。

8つすべてを一度に避ける方法

まとめて読むと、これらの失敗には一つの共通の根があります。証拠の上をゆっくり進む代わりに、思い込みの上を速く進むこと。どれもが、丁寧な一歩を飛ばすほうが安く思えた場所です。そしてどれもが、開発のあとより前に対処するほうがはるかに安くつきます。8つすべてを静かに避ける順序がこれです。

1. 1
   作る前に需要を証明する

   試作、ランディングページ、または手作業の版。予算を投じる前に、誰かがこれを欲しがるという実際の証拠を得る。
2. 2
   要件とバージョン2リストを書く

   誰でも理解できる数ページの明確な文書に、v1を脱線させないよう、あらゆる「ついでに」のアイデアを置く駐車場を添える。
3. 3
   開発者は価格ではなく実績で選ぶ

   リリース済みの仕事、紹介先への確認の電話、コードとアカウントの所有権の明確さ、そして良い質問を返してくる相手。
4. 4
   開発だけでなく最初の1年全体の予算を組む

   ホスティング、保守、修正、サポート。リリース当日はスタートラインなので、運用そのものに資金を充てる。
5. 5
   仕事をこなせる最小のプラットフォームを選ぶ

   多くの場合、まずウェブかクロスプラットフォーム。利用がそれを求めるときだけ、証拠をもってあとから完全ネイティブへ。
6. 6
   本物のユーザーでテストし、それからリリースを計画する

   見知らぬ5人が使う様子を見て、明らかな失敗を直し、人がどう見つけ、利用をどう測るかを前もって決める。

よくある質問