アプリの主要機能と目標：最初に作るべきもの

アプリの主要機能と目標を設定するときは、提案するすべての機能を、測定可能なユーザーの成果に結びつけましょう。対象ユーザーが、予約をして確定の通知を受け取るといった中心的なタスクを完了できる、最小構成のアプリを作りましょう。その成果への貢献度で機能を選び、開発が始まる前に範囲を定めましょう。

アプリの主要機能と目標とは？

アプリの主要機能と目標は、ユーザーにできることと、達成してほしい成果を結びつけます。目標とは、窓口に電話せずに予約を完了するなど、実現したい成果のことです。機能は、空いている時間を選ぶなど、ユーザーの行動を可能にします。指標は、予約を試みたうち確定まで進んだ割合など、成果を測るものです。

アプリの主要機能は、その中心的なタスクを完了できるものにしましょう。どのアプリにも当てはまる基本機能の一覧はありません。予約アプリには予約の空き状況が必要な一方で、現場報告アプリには報告の送信が必要です。想定するタスクの完了に欠かせない機能を残しましょう。

アプリの機能を選ぶ前に必要なことは？

機能を選ぶ前に、ユーザーの課題と、開発・提供上の制約を明確にする必要があります。現在の手順のどこに問題があり、初回リリースで何を実現すべきかを説明できるだけの情報を集めましょう。

• 再診を予約する患者など、対象ユーザーを明確にしましょう。
• 予約の手助けを求める問い合わせなど、課題の存在を裏づける情報を集めましょう。
• 予約の申し込みから確定まで、現在の作業の流れを説明しましょう。
• 開発と継続的な運用をまかなえる予算を設定しましょう。
• 期限と、その期限を設ける理由を明確にしましょう。
• iOSやAndroidなど、対応が必要なプラットフォームを選びましょう。

モバイルアプリの開発範囲を定めるときは、機能の数よりも、デザイン・テスト・サポートに何が必要かが重要です。カレンダー連携が1つでも、見積もりを出す前に調査が必要です。AppDesign360のモバイルアプリ開発は、合意した初期開発範囲で3,500米ドルからで、機能・対応プラットフォーム・価格・スケジュールを書面で確認します。

アプリのアイデアを測定可能な目標にするには？

ユーザー、実現したい成果、現状の数値、目標値、期限を明確にして、アイデアを目標に変えましょう。現状の数値は、比較の基準となるベースラインです。今、そのタスクがどの程度うまく進んでいるかを示します。わからない場合は、改善を約束する前に、既存の手順での実績を測りましょう。

架空のクリニックなら、目標は「再診患者の予約完了率を、公開から90日以内に60%から75%へ引き上げる」と設定できます。完了率は、確定した予約数を予約を試みた回数で割った値と定義し、一貫して同じ定義を使いましょう。これらの数値は目標の例であり、予測ではありません。

1. 選択したサービスの予約可能な日時を表示しましょう。
2. 患者が都合のよい時間を選べるようにしましょう。
3. 予約枠を確保するために必要な情報を集めましょう。
4. 予約を確定し、その後の流れを表示しましょう。

この手順で、提案された各機能の目的が明確になります。患者にとっての価値は、追加のサポートなしで予約を確定できることです。事業の収益は、それとは別に追跡する成果です。患者が詳細情報の入力フォームで離脱する場合は、予約完了に関係のない機能を追加する前に、その段階を調べましょう。

アプリのどの主要機能を初回リリースに含めるべきですか？

主なタスクの完了に必要な機能と、そのタスクを確実に完了できるようにする対策を含めましょう。この架空のクリニックでは、患者が予約枠を探し、予約して、予約確認を受け取れる必要があります。追加の機能はすべて、基本要件ではなく、採用する理由が必要な提案として扱いましょう。

患者が予約履歴の確認や予約管理を行うために、保護されたアクセスが必要なら、アカウント機能を初回リリースに含めます。予約枠の確保に前払金や料金の支払いが必要なら、決済機能を含めます。患者の来院を促すことがリリース時の目標に含まれるなら、リマインダー機能を含めます。そうでなければ、予約の仕組みが機能してから検討しましょう。

アクセシビリティ、セキュリティ、信頼性は品質要件であり、予約機能と優先順位を競う任意の追加機能ではありません。アクセシビリティとは、スクリーンリーダーで予約枠を選ぶ場合など、障害のある人もタスクを完了できることです。セキュリティとは、患者情報を保護し、アクセスを制限することです。信頼性とは、確定した予約が実際に保存されていることです。画面が動くことをタスクが機能する証拠とせず、これらの要件の確認項目を開発の対象範囲に明記しましょう。

機能に優先順位をつけ、モバイルアプリの開発対象範囲を定めるにはどうすればよいですか？

ユーザーが最初から最後まで進める最小限の流れを優先し、開発を始める前に、何をもって機能していると判断するかを定めましょう。実用最小限の製品、つまりMVPとは、中心となる成果を提供し、仮説を検証するための最小限のリリースです。クリニックの場合、その仮説は、患者がスタッフに電話せずに予約できるというものかもしれません。

ユーザーにとっての価値を、作業量、依存関係、リスクとあわせて評価しましょう。依存関係とは、クリニックの予約管理システムへのアクセスなど、機能が動作するために必要なものです。この表は、確定した見積もりではなく、調査すべき作業を示しています。予約管理システムとの接続がすでにあるかどうかで、必要な作業量は変わります。

これらの決定をもとに、モバイルアプリの開発範囲を明確に定めます。受け入れ基準とは、機能を受け入れる前に満たす必要がある、確認可能な条件のことです。予約の流れに沿って、何かが失敗した場合の動作も含めて条件を書き出しましょう。

1. 予約可能な日時の確認から予約確定通知の受信まで、対象とする一連の流れを明示し、対応するプラットフォームを指定します。
2. リピート利用特典やリマインダーなど、対象外のものを列挙し、含まれていると誰も思い込まないようにします。
3. テスト予約がクリニックの予定表に反映され、患者にも同じ予約内容が表示されることを必須条件にします。
4. 予約枠が利用できない場合や保存に失敗した場合には、誤った予約確定表示を出さず、解決に向けた手順を明確に示すことを必須条件にします。

機能の際限ない追加を防ぎ、成果を測るには？

機能を追加するたびに、コストのかからない改善ではなく、開発範囲に関する判断として扱うことで、機能の際限ない追加を防ぎます。こうした機能の追加は「フィーチャークリープ」と呼ばれ、範囲や予算、時期を見直さずに作業を増やすことを意味します。ユーザーのニーズを明確にせずに競合の機能をまねたり、人工知能（AI）を追加したりしても、その追加作業を受け入れる明確な判断基準は得られません。

開発中にクリニックからリマインダーを求められたら、患者の来院がリリース時の目標に加わったのかを確認しましょう。そのうえで、リマインダーを後回しにするか、ほかの作業を削るか、予算と日程を見直すかを合意します。リリースの成果はダウンロード数だけでなく、予約の完了状況と予約を試みて失敗する箇所から判断しましょう。リピート予約は、患者が実際に次の予約を必要とする場合にだけ追跡します。時折受診する人にとって、アプリを頻繁に使うことは有益な目標ではありません。

初回開発の範囲決めをAppDesign360はどう支援できますか？

AppDesign360は、アプリの主要機能と設定した目標を、開発に踏み切る前に確認できる開発計画にまとめます。別サービスのApp Blueprintは1,250米ドルからで、クリックして操作できるプロトタイプ、技術仕様書、開発見積もりが含まれます。プロトタイプでは提案された画面を試せます。仕様書には、アプリがどのように動作すべきかを記載します。

クリニックの場合、リマインダーを追加する前に、予約の空き状況の確認から予約確定までの流れをテストすることなどが考えられます。この確認を通じて、誰が予約をキャンセルできるかなど、まだ決まっていない点を洗い出しましょう。適切な開発範囲は、業務の流れ、扱うデータ、アプリとの連携が必要な既存システムによって変わります。

作業開始前に、所有権と引き渡し内容を明確にしたうえで、範囲、価格、リリース日を書面で合意します。コード、ホスティング、アカウントは引き続きあなたが保有します。各サービスの範囲は別々に定めているため、アプリ開発にマーケティングやAI関連の作業が自動的に含まれるわけではありません。

初めての開発について相談するには、https://appdesign360.com/contact から無料の20分間のヒアリング通話をご予約ください。ユーザーが達成したい主なタスクと、既存の試作品があればご用意ください。技術仕様書は不要です。

モバイルアプリを作る前に、ほかに知っておくべきことはありますか？

ユーザーが得られる成果に基づいて機能を選び、そのうえでビジネス上の指標を別に設定します。予約アプリなら、予約の確定がタスクの完了を示し、完了した予約1件あたりの売上が事業上の価値を測る指標になります。アプリで収益を上げる必要があるなら、両方が必要です。