LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

アプリ開発発注の全体フロー：8ステップの概観

アプリ開発の発注とは、スマートフォンアプリやWebアプリの企画・開発・リリース・保守を外部のシステム開発会社に委託する一連のプロセスを指します。初めて外注する担当者にとって、どこから手をつければよいかわかりにくい領域ですが、フローを8つのステップに分解すると全体像が把握しやすくなります。

発注フロー全体は、大きく「事前準備フェーズ（ステップ1〜2）」「選定・契約フェーズ（ステップ3〜4）」「開発フェーズ（ステップ5〜6）」「品質確認フェーズ（ステップ7）」「稼働後フェーズ（ステップ8）」の5つに分かれます。各フェーズで発注側が果たすべき役割は異なります。

多くの失敗は「要件が固まらないまま見積もりを取り、後から仕様変更が多発する」パターンで起こります。発注前の準備に時間をかけることが、結果としてコスト・期間両面のリスクを抑えることにつながります。

ステップ1：要件整理と社内目的の言語化

発注前にまず行うべきは、「何のためにアプリを作るか」を社内で合意することです。開発会社への相談より前に、自社の目的・対象ユーザー・解決したい課題を整理しておく必要があります。この段階が曖昧なまま進むと、見積もりの精度が下がり、要件定義フェーズで手戻りが生じやすくなります。

要件整理では、次の4点を文書化することが出発点になります。

• ビジネス目的：何を解決・達成するためのアプリか
• 対象ユーザー：誰が使うか（社内向け・顧客向け・特定業種など）
• 主要機能の概要：必須機能と「あれば望ましい機能」の区別
• 制約条件：予算感・リリース希望時期・既存システムとの連携要否

この4点をA4で1〜2枚にまとめた「要件概要書」を準備しておくと、複数の開発会社への相談がスムーズに進みます。完成度より「発注側の意図が伝わること」を優先してください。

また、社内の意思決定者が誰で、承認フローがどうなっているかを事前に把握することも重要です。開発が進んでから上長から「その機能は不要」と差し戻されると、大幅な仕様変更コストが発生します。

ステップ2：RFP作成と見積依頼

RFP（Request for Proposal）とは、発注側が開発会社に対して提出する提案依頼書のことです。「どんなシステムが欲しいか」「どんな会社に頼みたいか」の条件をまとめた文書で、見積もり精度を高めるために有効です。

RFPに記載する主な項目は以下のとおりです。

• プロジェクトの背景・目的
• 開発するアプリの概要（対応OS・プラットフォーム）
• 想定ユーザー数・アクセス規模
• 主要機能の一覧（優先度付き）
• 連携する既存システムやデータソース
• 希望納期・開発スケジュールの制約
• 予算上限（記載可能な範囲で）
• 提案期限・選定基準

RFPを整えずに「こんなアプリを作りたいのですが、いくらですか？」と問い合わせると、開発会社は仮定を積み上げて見積もりを出すしかありません。その結果、後から仕様確認のやり取りが増え、双方の工数が無駄になります。

見積依頼の際は、原則3社以上に声をかけることをお勧めします。1社のみだと比較軸が生まれず、費用の妥当性を判断できません。同じRFPを使って複数社に依頼することで、提案内容・費用・開発アプローチの違いを客観的に比較できます。

ステップ3：見積比較と発注先選定

見積もりが出揃ったら、金額だけでなく複数の観点で比較することが大切です。金額が低い提案が最善とは限りません。見積もりが低い場合、「仕様の読み取りが甘い」「後から追加費用が発生する」ケースも実務上は見られます。

比較時に確認すべき観点を下表にまとめます。

選定時には、口頭ヒアリングだけでなく、過去の類似案件の実績（ポートフォリオ）の提示を求めることをお勧めします。自社と近い業種・規模のアプリ開発経験があるかどうかは、プロジェクト推進力に大きく関わります。

ステップ4：契約形態の選択（請負 vs 準委任）

発注先が決まったら、次は契約形態を選択します。アプリ開発でよく使われる契約形態は「請負契約」と「準委任契約」の2種類です。IPA（情報処理推進機構）が公開している「情報システム・モデル取引・契約書（第二版）」では、この2つの契約形態が開発工程別に整理されており、どの工程にどちらが適するかが示されています。

2つの契約形態の主な違いを整理すると、以下のようになります。

実務では、要件定義フェーズを準委任契約、設計・開発・テストを請負契約、保守・運用を準委任契約とする「工程分割型」の組み合わせが採用されることがあります。要件が固まっていない初期工程を請負にすると、仕様変更のたびに変更契約が必要になり、双方の負担が増えます。

なお、費用・期間レンジは開発規模や機能要件によって大幅に異なります。市場参考値に過ぎず一次資料ではないため、具体的な費用は複数社から見積もりを取得して比較することをお勧めします。

ステップ5：要件定義フェーズで発注側がやること

契約締結後、開発は要件定義フェーズから始まります。このフェーズは、発注側の関与が最も求められる工程です。要件定義が甘いまま設計・開発へ進むと、後工程での手戻りが増え、追加費用や納期遅延につながります。

要件定義で発注側が果たすべき役割は主に3つです。

• 業務要件の提供：「誰が・何を・いつ・どのように使うか」を開発会社に伝える
• 優先度の決定：機能の必須・希望・将来対応を発注側が判断して伝える
• 確認・承認：開発会社が作成した要件定義書の内容に誤りや抜けがないかチェックする

発注側が「開発会社に任せればいい」という姿勢でいると、開発会社が業務を理解できないまま仕様を推測で書くことになります。その場合、完成したアプリが実際の業務フローと合わず、大幅なやり直しが発生するリスクがあります。

要件定義書の確認には、現場の実務担当者を巻き込むことが実務上有効です。情報システム部門だけでなく、実際にアプリを使う営業・現場スタッフなどの意見を要件に反映させることで、完成後の「使われないアプリ」を防ぎやすくなります。

要件定義フェーズには、「プロジェクト期間全体の中でも時間と工数が必要な工程」という認識を発注側が持つことが大切です。IPA（情報処理推進機構）の「システム開発関連コンテンツリンク集」では、要件定義・設計・開発・テスト・運用の各工程における留意点が整理されており、発注側の役割理解にも参考になります。

ステップ6：設計・開発フェーズの関与ポイント

要件定義が完了すると、設計・開発フェーズへ移行します。このフェーズは開発会社の作業が中心となりますが、発注側も定期的な確認と意思決定への参加が必要です。

設計フェーズでは、UI（ユーザーインターフェース）のワイヤーフレームや画面遷移図が提示されることがあります。この段階での確認が後戻りコストを抑えます。開発が始まってからの画面レイアウト変更は、実装済みのコードの書き直しを伴うことがあるからです。

開発フェーズでは、次のポイントを発注側として押さえておきます。

• 定例会議への参加：週次・隔週の進捗報告には担当者が出席し、懸念点を早期に共有する
• 中間デモの確認：モックアップや中間成果物の確認を通じて、方向性のズレを早期に修正する
• 仕様変更の判断：変更が生じた場合は、影響範囲と追加費用を確認した上で正式な変更依頼を行う

仕様変更を口頭で伝えて「なんとなく合意した」状態のまま進めると、後から認識の相違が生じやすくなります。変更はメール・議事録など書面で記録することが、トラブル防止につながります。

ステップ7：受入テストで発注側が確認すべき4つの観点

開発が完了すると、テストフェーズに入ります。開発会社が行う単体テスト・結合テストのほかに、発注側がシナリオを用意して行う受入テスト（UAT：User Acceptance Test）が重要です。

受入テストは、「要件定義で合意した機能が正しく動作するかを発注側が確認するプロセス」です。開発会社が自社テストをパスしていても、実際の業務シナリオで動かしてみると不備が見つかることがあります。

受入テストで確認すべき主な観点は次のとおりです。

• 機能の正確性：各機能が要件どおりに動作するか
• 業務フローとの整合：実際の業務手順でアプリを操作した際に問題がないか
• エラー処理：誤入力・通信エラー時に適切なメッセージが出るか
• 非機能要件：表示速度・レスポンス・セキュリティ要件の確認

テストで見つかった不具合は、「バグ管理票」などで一元管理し、優先度ごとに修正依頼を行います。軽微な不具合をリリース後に修正することで合意している場合は、その範囲と期限を契約・議事録で明確にしておくことが大切です。

受入検収が完了すると、発注側が「検収書」を発行します。これが法的に納品完了を意味するため、署名・発行のタイミングには注意が必要です。未解決の重要バグがある状態で検収書を発行すると、その後の修正を無償で求めることが難しくなるケースがあります。

ステップ8：リリースから保守・運用体制の確立

受入検収が完了したら、アプリのリリース作業に移ります。スマートフォンアプリの場合はApp Store・Google Playへの申請、WebアプリはDNS（ドメインネームシステム）切り替えやサーバー設定などが必要です。

リリース作業は開発会社が主導することが多いですが、発注側も次の点を事前に確認しておく必要があります。

• アカウントの所持確認：App Storeのデベロッパーアカウントやサーバー管理権限が発注側の手元にあるか
• ソースコードの納品：ソースコードが発注側に引き渡されるかどうかを契約時に確認する
• ロールバック手順：リリース後に重大な問題が発覚した場合の切り戻し手順を事前に合意する

リリース後は、保守・運用フェーズに入ります。この段階での主なコストは、バグ修正対応・OSアップデートへの追従・サーバー監視・機能改善対応です。リリース時点で保守契約の有無・対応範囲・月額費用を取り決めておかないと、トラブル発生時に対応会社がいない状態になるリスクがあります。

保守体制は、アプリの重要度や更新頻度に応じて設計することが大切です。決済や社外公開など重要度が高いアプリでは、障害対応の応答時間（SLA：Service Level Agreement）を契約に明記することをお勧めします。

発注失敗を防ぐ：工程別チェックリスト

アプリ開発の発注で起こりやすい失敗は、特定の工程で準備が不十分なことに起因します。工程ごとによくある失敗のパターンと回避策を整理します。

発注側の担当者が「開発はプロに任せればいい」と受け身になりすぎることは、プロジェクト失敗の一因になります。発注側もプロジェクトの当事者として各工程に関与する姿勢が、完成品の品質に直結します。

内製で対応が難しい場合は、要件整理や発注管理をITコンサルタントやPMO（プロジェクトマネジメントオフィス）として支援できる会社に相談するという選択肢もあります。

まとめ：発注の流れを押さえる3つの判断軸

本稿では、アプリ開発を初めて外注する担当者向けに、発注の全体フローを8ステップで整理しました。要点を3つに集約すると次のとおりです。

第一に、「発注前の準備が品質を決める」ことです。要件整理とRFPの整備が不十分なまま進むと、見積もりが不正確になり、開発中の仕様変更が増えます。発注前に自社の目的・ユーザー・機能・制約を文書化する工程に時間を割くことが、全体コストの抑制につながります。

第二に、「契約形態は工程によって使い分ける」ことです。探索的な要件定義は準委任、要件が固まった実装は請負と、工程の性質に合わせて選択することで、費用の予見性とプロジェクトの柔軟性のバランスをとれます。IPA「情報システム・モデル取引・契約書（第二版）」は契約形態の参考情報として有用です。

第三に、「発注側も工程の当事者である」ことです。受入テスト・要件定義レビュー・変更管理など、発注側が主体的に関与する工程が多くあります。開発会社任せにする工程が多いほど、想定外の品質問題や費用超過が発生するリスクが高まります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：IPA（情報処理推進機構）「情報システム・モデル取引・契約書（第二版）」（2020年）
2. *2　出典：IPA（情報処理推進機構）「システム開発関連コンテンツリンク集」

Tweet