本日は、私たちの開発の舞台裏を少しだけご紹介します。新しい開発プロジェクトにどのように取り組むかをお伝えしたいと思います。私たちには、二つの異なるアプローチがあります。
アプリをそのまま作る
新しいアプリの規模がごく限られている場合、開発のリスクは見積もりやすくなります。たとえば一人の開発者が短期間（一か月未満）で取り組むだけなので、コストも抑えられます。この場合、私たちは機能の範囲を定め、アプリを作り、そのまま公開します。Telefonnotizen、Meetingkarten、そして Herein はこのケースに該当しました。
「ちょっと作る」には機能の範囲が大きすぎる
新しいアプリについて最初に話し合う段階で、その規模が人月の枠を超えると、すぐに分かることがあります。あるいは Merlin Project のように、その製品が戦略的に重要である場合もあります。この場合はリスクを伴う投資と捉え、当然ながらより慎重に進めます。
最初の段階では、私たちは モックアップ（Apple Keynote で作成した、アプリの完成イメージを示す画像）を作り、それをもとに将来のアプリでの操作や流れを頭の中でシミュレーションします。しかし、想像力の限界にぶつかることもあり、その際にはもう一つの手法が必要になります。プロトタイプです。
私たちにとって プロトタイプ とは、特定の技術、作業の流れ、あるいは一つのコンセプトを示すための小さなプログラムです。つまり、多くの小さなアプリを作るのです。これらのテスト用アプリは寿命がごく短いため、私たちはできるだけ早く目的に到達しようとします。ここでは美しさや整ったコードは目的ではありません。
この段階では、たいていまだ私の役割として、将来のアプリの採算性を検討します。アプリの開発にいくらかかり、それによってどれだけ収益を見込めるのか。私がいつも言っているように、「七十年代は終わりました。残念ながら、愛だけでは生きていけません」。
そしていつしか、新しいアプリのあらゆる側面を（願わくは）すべて検討し終えます。見た目を示す一連のスライドができあがります。そして必要なときには、新しい技術や重要な技術を、満足のいく結果が得られるまでプロトタイプで検証してきました。さらに、見込まれるコストと期待される収益の詳細な一覧も用意します。それから（もちろん Zoom を使ったリモートで）集まり、得られた知見について議論します。
この段階で、すでに非常に多くの新しいアプリのアイデアが頓挫してきました。基礎となるアイデアが弱かったり、技術的なハードルが低すぎたり、あるいは高すぎたりした場合です。また、想定される利用者数が少なすぎる場合にも、アプリは開発されません。もちろん、こうした見積もりは、たとえチームで下したものであっても非常に主観的であり、将来の現実と一致するとは限らないことは承知しています。それでも、いつかは決断を下さなければなりません。
MVP のスタート
新しいアプリへの確信、そしてそれを作る意欲が十分に高い水準に達したとき、私たちは開発に着手します。
ただし、ここでも慎重さが求められます。一度の失敗でチームの将来を危険にさらしたくはありません。そしてまさにここで、リスク管理 のもう一つの仕組みが働きます。実用最小限の製品を作ること です。
Wikipedia によれば、MVP という用語は Frank Robinson によって初めて生み出され、Steve Blank と Eric Ries によって広められました。その背後にある考え方は、直感的に分かりやすく理にかなっています。最も重要な中核機能だけを備えた新しい製品を作るのです。この製品をもとに、チーム内、戦略的パートナー、そして見込み顧客層の代表者とともに、その製品への関心があるか、見積もった市場が十分に大きいかを検証できます。もちろん、その際にアプリの操作性が想定どおり良好かどうかも検証します。
ProjectWizards の開発では、もう何年も前から反復的なアプローチが定着しています。
- 作成したモックアップに沿って開発する
- 少人数で結果を確認し、うまく機能するかを判断する
- 満足できない場合は、ソフトウェアの小さな問題であれば反復し、根本的な問題であればモックアップを描き直す
常に次のモットーに従います。最も速く、最も簡単な道筋が進め方を決める、と。
こうして MVP のためのすべての構成要素が少しずつ組み上げられていきます。ある時点から、誰か（たいていは私）が新しいソフトウェアを実際に触り始めます。
MVP 開発段階での最初のテスト
非常に時間がかかり、ときにはひどく苛立たしいこともありますが、コンセプトと前提は繰り返し検証しなければなりません。つまり、新しいアプリでサンプルデータを使って作業する必要があるのです。もちろん、最初はあらゆるところでクラッシュします。しかし時間の経過とともに、状況は改善していきます。
そしていつか、MVP にどれだけの時間を費やすべきか、あるいは費やさなければならないかという問いが出てきます。これには決まりも規定もありません。新しいプログラムが実際の現場で生き残れるかという問いに、自分自身で答えられるようになるまで続けるのです。
Minimum Marketable Product（MMP）との区別
実用最小限の市場性（あるいは販売可能性）を備えた製品は、少なくとも私の定義では、一歩はっきりと先へ進んだものです。
MVP が内部利用（一部の鍵となる関係者を含む）のためだけに作られ、それでまだ収益を上げることができないのに対し、MMP は本質的に一歩先へ進みます。このバージョンは販売できるのです。
オープンソースの世界の慣習とは異なり、私にとって MMP には少なくとも以下が必要です。
- バージョン番号 1.0
- ドキュメント
- ウェブサイト
- 販売パートナー（App Store、Paddle など）
- そのほか
そのため、私たちは MMP という呼称を使わず、バージョン 1 または 1.0 と呼んでいます。
MVP からバージョン 1 への移行はいつか
これは私たちにとって緩やかな移行です。MVP の完成に向けた期日は設定しますが、それは同時にバージョン 1.0 の残りの機能の開発を始める期日でもあります。
図からお分かりのように、これは順を追って進むプロセスとして計画されています。しかし現実には、その境界が部分的に大きくにじむこともあります。
MVP はいつ完成するのか
これについては、本当に定められた日付はありません。品質や機能の範囲に満足できないと判断すれば、私たちはアプリの開発を続けます。たとえそれが内部向けのバージョンであってもです。
このブログ記事についてご質問やご意見がございましたら、ぜひフォーラムへのご投稿をお待ちしております。
