モバイルアプリ開発者はビジネスに何をもたらす？

モバイルアプリ開発者は、業務で行う作業を、顧客やスタッフが使えるスマートフォンアプリに落とし込みます。仕事には、コードの記述、業務システムとの連携、テスト、保守が含まれます。発注する側にとって大切なのは、購入するサービスの機能、公開時の責任分担、所有権、サポートを定めた対応範囲の書面です。

モバイルアプリ開発者はどんな仕事をする？

モバイルアプリ開発者は、利用者が作業を完了できるようにするスマートフォンアプリを開発し、保守します。モバイルアプリ開発は、その作業をどのような仕組みで行えるようにするかを決めるところから、公開したアプリを動かし続けるところまでを含みます。中心となるのはコードを書くことですが、事業者側でも画面、データへのアクセス、公開後の責任分担について決める必要があります。

利用者が相談員との面談を予約できるようにしたい非営利団体を例に考えてみましょう。設計段階では、開発者がデザイナーや団体のチームと協力して、利用者が空き枠を見つけて予約を確定するまでの流れを決めます。その後、開発者は画面が操作に応じて動き、予約を一件ずつ記録するためのコードを書きます。

システム連携とは、ソフトウェアのシステム同士をつなぐことです。この例では、アプリと非営利団体がすでに使っているカレンダーをつなぐ場合があります。その連携には、キャンセルや、同じ予約枠への申し込みが重なった場合のルールが必要です。テストではこうした状況に加え、利用者が予約確定の表示を見る前に通信が途切れた場合にどうなるかも確認する必要があります。

一人の開発者が複数の役割を担うこともありますが、デザイン、テスト、ストアへの申請まで含まれているとは限りません。AppDesign360のモバイルアプリサービスにはApp StoreとGoogle Playへの申請が含まれ、機能と対応プラットフォームは書面で確認します。どの提供会社に依頼する場合も、不具合の修正や基本ソフト（OS）の変更への対応といった公開後の保守を含め、それぞれの作業を誰が担当するのか確認しましょう。

モバイルアプリの開発費用と期間はどのくらい？

モバイルアプリ開発の費用と期間は、合意した対応範囲、つまり契約に含まれる機能、プラットフォーム、作業によって決まります。AppDesign360のモバイルアプリ開発は、合意した初期の対応範囲で3,500米ドルからです。これはサービスの最低価格であり、市場の平均価格でも、あらゆる予約アプリに当てはまる見積額でもありません。

この非営利団体の場合、予約を申し込み、手動での確認を経て確定の連絡を受け取る仕組みと、複数の相談員の空き状況をリアルタイムで表示する仕組みでは、対応範囲が異なります。後者には、予約が重複した場合のルールと、最新のカレンダーデータへのアクセスが必要です。「予約機能」という説明だけで十分とせず、どのような業務の流れが見積もりに含まれるのか、開発者に明確にしてもらいましょう。

初期開発費とアプリの運用費は分けて考えましょう。AppDesign360の料金規定では、ホスティング費用やその他のサービス提供事業者への支払いは別途とされており、モバイルアプリの見積書で該当する費用が確認できます。有料のメッセージ送信サービスやカレンダーサービスの費用があれば、それらと保守の契約内容も予算に明記しましょう。それぞれの請求を誰が支払うのか、どのアカウントを自社で管理できるのかを確認してください。

実用的なスケジュールには、依存関係、つまり別の準備が整うまで進められない作業が明記されています。カレンダーへのアクセス、画面の承認、合意した端末でのテストは、いずれも計画に影響する可能性があります。ストアの審査も別の依存関係にあたるため、審査への提出日と一般公開の予定日を分けて示してもらいましょう。AppDesign360は、モバイルアプリの開発日程を、作業範囲を定めた書面で確定します。同社が公開しているSaaS、つまりオンラインサービスとして提供するソフトウェアの開発スケジュールは、依頼するスマートフォンアプリの日程の目安ではありません。

必要なのは独自開発のアプリ、ノーコードの作成ツール、それともウェブサイトですか？

利用者が目的を達成でき、データに関する要件も満たせる方法のうち、最もシンプルなものを選びましょう。面談などの予約であれば、まずはモバイル対応のウェブサイト、つまりスマートフォンの画面で使えるように設計されたサイトで対応できるかを確認してください。非営利団体は、たまに予約を申し込むだけの利用者に、アプリのインストールを求めるべきではありません。

ノーコード開発とは、アプリケーションのコードを自分で書く代わりに、視覚的に操作できるツールでソフトウェアを作ることです。独自開発とは、要件に合わせて開発者がコードを書くことです。どちらを選ぶかは、必要な予約ルールやスマートフォンの機能に加え、将来の変更をどの程度自分たちで管理する必要があるかによって決まります。

作成ツールの採用を決める前に、予約の一連の流れをテストしましょう。空き枠を表示できるツールでも、既存のカレンダーとキャンセル情報をやり取りできないことがあります。利用者情報と予約記録を使える形式でエクスポートできるか、想定する利用量でプラットフォームの継続的な料金がいくらかかるかを確認してください。

よりシンプルな方法では必要な業務フローや端末機能に対応できない場合、独自開発を検討する価値があります。たとえば、相談員がインターネットに接続できない環境で出席を記録する必要があるなら、方法を決める前に、オフラインでのデータ保存と、その後の更新をモバイルアプリ開発者に実演してもらいましょう。ブラウザー上の予約フォームで実際のニーズを満たせるなら、ウェブサイトも選択肢に残し、明確なメリットのないアプリに費用をかけるのは避けましょう。

アプリ開発はネイティブとクロスプラットフォームのどちらを選ぶべきですか？

好みのプログラミング言語ではなく、必要なスマートフォン機能のうち最も実装が難しいものを軸に、開発方法を選びましょう。ネイティブ開発とは、iOSやAndroidなど、特定のプラットフォーム専用に開発することです。クロスプラットフォーム開発では、コードの多くを複数のプラットフォームで共有しますが、それぞれのバージョンでテストは必要です。

AppDesign360は、iOS向けにはSwift、Android向けにはKotlinを使ってネイティブアプリを開発し、FlutterとReact Nativeを使ってクロスプラットフォームアプリを開発しています。SwiftとKotlinはプログラミング言語です。FlutterとReact Nativeはフレームワークで、アプリを作るためのツールや再利用可能な部品をまとめたものです。モバイルアプリ開発者には、要件に照らして選択の理由を説明してもらいましょう。

非営利団体の予約アプリで、スタッフがスマートフォンのカメラを使って出席確認用のコードを読み取る必要があるとします。本格的な開発を決める前に、使用予定のスマートフォンで動く小規模なデモを依頼しましょう。そのテストでは、読み取りに成功する場合だけでなく、カメラへのアクセスが許可されていない場合や、コードを読み取れない場合も確認する必要があります。

必要な機能を共通の部品で実現できるなら、クロスプラットフォーム開発は検討に値します。プラットフォーム固有の作業が多く必要になるなら、提案されている保守計画にどう影響するかを尋ねましょう。どちらの方法でも、予約の一連の流れを確認する必要はなくなりません。

依頼する前にアプリ開発者のスキルをどう確認すればよいですか？

開発者のスキルを確認するには、関連する機能が実際に動く証拠と、判断の理由についてのわかりやすい説明を求めましょう。ポートフォリオのスクリーンショットから画面の見た目はわかりますが、予約ルールを誰が実装したのか、リクエストが失敗した場合を誰がテストしたのかまではわかりません。非営利団体向けのアプリでは、関係のない洗練された画面よりも、カレンダー連携の実績のほうが重要です。

1. 関連するアプリを確認し、一般公開されていない場合は説明付きのデモを依頼しましょう。エラーやキャンセルの場合も含め、1つの操作の流れを最初から最後まで確認します。計画している業務の流れと似ているのはどの部分かを尋ねましょう。
2. 候補者本人が担当した内容を確認しましょう。画面設計、コーディング、業務システムとの連携、リリース作業を誰が担当したのかを尋ねます。1つの画面に関わった人を、製品全体を完成させた人と同じように評価すべきではありません。
3. 具体的な状況を示して、技術的な判断力を評価しましょう。2人の利用者が同じ予約枠を申し込んだ場合や、送信後に接続が切れた場合にどうなるかを尋ねます。その問題をどう防ぎ、どう検知するのか、わかりやすく説明できるかを確認しましょう。
4. 打ち合わせ後の書面でのやり取りを通じて、コミュニケーション力を評価しましょう。開発者には、前提条件、未解決の疑問点、次に決めるべきことを記録してもらいます。専門用語を自分で読み解かなくても、何に承認が必要なのかを理解できることが大切です。
5. 同じ依頼概要に照らして、書面の提案を比較しましょう。どの提案にも、対象プラットフォーム、連携機能、テストの担当範囲が含まれているかを確認します。提示価格を同じ条件で比較できるものと考える前に、対象外の内容を候補者に説明してもらいましょう。

チームにすべての役割がそろっていると思い込まず、必要な業務を誰が担うか明確な体制を選びましょう。担当範囲が限定されていて、ほかの協力者との調整ができるなら、フリーランスも適切な選択肢になり得ます。担当者間の引き継ぎを管理できない場合は、役割をまたいで納品に責任を持つ担当者を指名してもらいましょう。

企画からアプリの公開までに、何を受け取るべきですか？

各段階では、次の段階への合意をする前に確認できる成果物が必要です。ディスカバリー（事前調査・要件整理）とは、解決すべき事業上の課題と初回リリースの範囲について合意することです。その非営利団体の場合は、予約とキャンセルを対象にし、ボランティアのシフト調整は初期開発の対象外にするといった内容が考えられます。

AppDesign360が別途提供するApp Blueprintは1,250米ドルからで、クリックして操作できるプロトタイプ、技術仕様書、開発見積もりが含まれます。クリックして操作できるプロトタイプは、画面と画面間の移動を示すもので、実際に稼働する本番用アプリではありません。その中で予約までの流れを確認できますが、予約が保存されることや、カレンダーの更新が機能することを証明するものではありません。

1. ディスカバリーは、合意済みの要件概要書をまとめて完了しましょう。そこには、利用者、利用者が完了する必要のある作業、初回リリースの範囲を明記します。コンテンツと既存システムへのアクセスを誰が提供するかも記録しましょう。
2. 実際の利用を想定した操作でプロトタイプを確認しましょう。予約枠を探し、予約を変更し、キャンセルしてみます。わかりにくい画面については、実際に動くソフトウェアとして実装される前に、決定事項を記録しましょう。
3. アプリがどのように動作すべきかを文書で記述した技術仕様書を承認しましょう。採用するプラットフォーム、データ要件、連携の詳細に加え、受け入れ基準も求めましょう。受け入れ基準とは、機能が完成したことを示す、確認可能な条件です。
4. 開発中は、実際に動くビルドを確認しましょう。失敗するリクエストも含め、テスト用の予約を使った実演を依頼します。承認した変更と、それが合意済みの作業に及ぼす影響を記録しておきましょう。
5. ストアへの申請前に、テストの実施結果を確認しましょう。対応するスマートフォン、アカウントの権限、予約の失敗に関するテスト結果を求めます。未解決の不具合のうち、公開前に修正しなければならないものについて合意しましょう。
6. 申請の準備が整っていることと、引き継ぎ内容を確認しましょう。ストア掲載用の説明文、スクリーンショット、必要なアカウントへのアクセスを確認し、その後でコード、セットアップ手順、所有権に関する書類を受け取ります。申請は承認を意味しません。ストアからの質問に誰が回答し、公開後の問題に誰が対応するかを記録しましょう。

アプリ開発契約を結ぶ前に、どのような失敗を避けるべきですか？

納品、所有権、責任が契約書で明確になるまでは、契約を結ばないようにしましょう。「予約アプリ一式」といった表現では、未確定の部分が多すぎます。スタッフが予約をキャンセルできるのか、カレンダー連携に失敗した場合に誰が修正するのかがわかりません。依頼先のモバイルアプリ開発者には、こうした期待を、確認・評価できる具体的な約束に落とし込んでもらいましょう。

• 作業開始前に、作業範囲、料金、公開日を書面で提示してもらい、依頼側からのコンテンツ提供やストア審査など、進行を左右する前提条件も明らかにしましょう。
• 対象外となる項目は明記しましょう。含まれない管理者用画面、データ移行、既存システムとの連携も記載します。
• 追加作業が始まる前に、変更依頼の承認方法と料金の決め方について、納期への影響も含めて合意しましょう。
• 作業を承認するための確認可能な条件である、受け入れ基準を定めましょう。たとえば、予約をキャンセルすると、その予約枠が空くことなどです。
• ソースコード、ホスティング、アカウントの所有権と引き継ぎについて確認しましょう。別の開発者に依頼する際に必要となるアクセスも含めます。
• 不具合の修正は、継続的な保守や新機能の追加と区別し、サポートの担当範囲と料金を書面に残しましょう。
• ストアの審査通過を保証する提案は断り、却下通知への対応、修正、再申請を誰が担当するのかを明確にしてください。

AppDesign360では、新規開発したアプリに30日間の修正対応が含まれ、公開後も開発を担当したチームからサポートを受けられます。ただし、無制限の保守契約ではないため、修正対応期間がいつ始まり、何が対象になるのかを確認してください。予約アプリの場合、合意したテストに通らないキャンセル機能の修正と、キャンセル待ちリストの追加は別のものです。後者は対応範囲の変更になります。

AppDesign360への相談は、何から始めればよいですか？

まずは改善したい業務を整理し、AppDesign360の無料の20分間ヒアリングで相談してください。たとえば非営利団体なら、スタッフがメールをやり取りしなくても、利用者が予約できる仕組みが必要かもしれません。その業務、現在の予約手順、既存ソフトウェアへのアクセスに必要な条件があれば、それらを相談時に共有してください。

AppDesign360は、2018年設立のMango Consulting LLCが展開する、ウェブサイト、SaaS、カスタムソフトウェア開発のブランドです。SaaSとは、オンラインサービスとして提供されるソフトウェアのことです。Mango Consulting LLCは、米国中小企業庁（SBA）認定の、軍務に起因する障害のある退役軍人が所有する中小企業（SDVOSB）であり、連邦政府の優先発注枠の案件も受注しています。

当社の地域チームはニュージャージー州ティーネックとニューヨーク州クイーンズを拠点とし、ノースバーゲン、バーゲン郡、ニューヨーク市に対応するほか、米国とカナダ全域にリモートでサービスを提供しています。小規模企業や成長中の企業、創業者、非営利団体を支援しています。モバイルアプリに加え、テンプレートではなく独自にコードを書くウェブサイト、業務ソフトウェア、顧客ポータルを開発し、AIサービスやマーケティングも提供しています。

1. スタッフが対応しなくても顧客が予約やキャンセルをできるようにするなど、実現したい成果を説明しましょう。
2. 既存の画面や試作品を用意し、現在のソフトウェアとアカウントを誰が管理しているかを明確にしましょう。
3. 実装を決める前に、必要なのが計画の策定、新規開発、既存アプリの評価のどれなのかを相談しましょう。
4. 作業を承認する前に、所有権や引き継ぎの条件も含め、書面に記載された作業範囲、料金、公開日を確認しましょう。

コード、ホスティング、アカウントの所有権は引き続きお客様に帰属し、引き継ぎについては契約で定めます。動作する試作品がある場合と、紙にまとめたアイデアだけの場合では、次に必要なステップが異なりますので、すでにあるものを説明してください。https://appdesign360.com/contact でプロジェクトについて相談し、初回のヒアリングをお申し込みください。