業務アプリ開発を依頼する流れ｜見積〜納品の6ステップ

業務アプリの開発を外部に依頼するときの流れは、①要件の整理 → ②見積・提案 → ③契約 → ④設計・開発 → ⑤テスト・受入 → ⑥納品と保守の6ステップです。小規模な業務アプリなら、要件整理に2〜4週間、開発に1〜3か月というのが実務での目安になります。

この記事では各ステップで発注側が用意するもの・決めることを具体的に並べます。「何を渡せばいいか分からない」まま打ち合わせに入ると、見積が膨らむか、逆に安すぎて後から追加になります。手元の資料が揃っているだけで、この振れ幅はかなり縮みます。

全体像：6ステップと発注側の持ち物

期間はあくまで小〜中規模（画面が5〜15枚程度）の目安です。実際に伸びやすいのは④ではなく①と⑤で、要件が固まらない・受入の担当が出てこない、という理由で止まります。開発期間の見積もりだけを見て計画を立てると、この2箇所で遅れます。

① 要件の整理：まず「今の運用」をそのまま出す

ここで多いのが、きれいな要件定義書を自分で作ろうとして止まるパターンです。作る必要はありません。開発会社が知りたいのは理想像ではなく現状なので、次のものをそのまま渡すのが最短です。

• 今使っているスプレッドシートやExcelの実物（ダミーデータに置き換えたコピーで可）
• お客様や取引先に出している帳票・メールの実物（見積書、納品書、確認メールなど）
• 「これが面倒」という困りごとを箇条書きで10個
• 関わる人の一覧（入力する人、承認する人、見るだけの人）

特に効くのは1つ目です。現行のシートには、列名・入力規則・手作業の抜け道といった要件がすでに埋まっています。逆に、これを見せずに口頭だけで説明すると、開発側は一般論で見積を組むので金額が大きく振れます。

「今回やらないこと」を先に決める

要件整理の実質的なゴールは、機能を並べることではなく初回に入れない機能を決めることです。困りごと10個のうち、初回で解くのは3〜4個に絞ると、期間も金額も読める範囲に収まります。残りは2次開発の候補として文書に残しておけば、忘れられません。

そもそもアプリにすべきかスプレッドシートの改善で足りるのか迷う段階なら、スプレッドシート管理の限界とアプリ化の判断、およびノーコードか開発かの判断5軸を先に見ておくと、依頼の粒度が決まります。

② 見積・提案：3社に同じ資料を渡す

相見積もりを取るなら、各社に同じ資料一式を渡すのが前提です。渡す情報が違うと、見積の差が実力の差なのか情報量の差なのか判別できません。

提示された見積は、金額の合計ではなく工程の分かれ方を見ます。

データ移行の行が無い見積は要注意です。既存のスプレッドシートは表記ゆれ・空欄・重複を含んでいるのが普通で、そのまま取り込めることはまずありません。金額の目安は脱エクセルの費用相場や顧客管理システムの費用の考え方で確認できます。

③ 契約：工程を分けて結ぶ

IPAと経済産業省が公表している「情報システム・モデル取引・契約書」（第二版・2020年12月22日）では、要件定義は準委任、開発は請負というように工程ごとに契約を分ける多段階契約の考え方が示されています。中小規模の業務アプリでも、この分け方は有効です。要件が固まっていない段階で全工程を一括の請負にすると、追加要望が出るたびに「契約範囲か否か」の議論になるためです。

契約時に確認しておく項目は次の5つです。

• 成果物の所有権：ソースコードが自社に帰属するか、利用許諾のみか
• データの取り扱い：保存場所、再委託の有無、契約終了時の削除
• 受入の合否基準：何をもって納品完了とするか（⑤で使う）
• 不具合対応の期間：納品後どのくらい無償で直すか
• アカウントの名義：クラウドやドメインを自社名義で作れるか

最後のアカウント名義は見落としやすい割に、乗り換え時に効きます。開発会社名義で作られていると、解約時に環境ごと動かせません。

④ 設計・開発：発注側の仕事は「決めること」

開発が始まると、発注側の作業が無くなると思われがちですが、実際にはこの期間の判断の速さがそのまま納期に効きます。画面案や項目の確認依頼に対して、社内で1週間持ち帰ると、その1週間は素直に遅れます。

用意しておくと進みが変わるのは次の2つです。

• 決める人を1人に決める：全員の合意を毎回取ると止まります。「この人が決める、異論は事前に集める」を最初に宣言しておきます。
• 実データのサンプルを渡す：ダミーデータだけで作ると、桁あふれ・全角半角・過去の例外行がテストで一気に出ます。個人情報を伏せた実データを早めに渡すほど、後半が静かになります。

私たちもスプレッドシートを業務アプリにする開発を承っています。記事の途中で恐縮ですが、今お使いのシートをそのまま見せていただくところから始める形なので、要件定義書を作ってからでなくてもご相談いただけます。よろしければ合わせてご覧ください。

⑤ テスト・受入：合否基準を先に文章にする

受入テストで揉める原因のほとんどは、合否基準を納品直前に考えるからです。契約時点で「どうなったら受け入れるか」を文章にしておきます。粒度はこの程度で構いません。

• 現行の運用を1週間分、新アプリで再現できる
• 既存データの移行後、件数と合計金額が現行と一致する
• 入力担当者3名が、マニュアルを見ながら1件を10分以内に登録できる

3つ目のように現場の人が実際に触る条件を1つ入れておくと、「動くけれど使えない」納品を防げます。テストに現場担当が出てこないまま検収すると、稼働後に運用が回らず、結局スプレッドシートに戻ります。

⑥ 納品・保守：引き継げる形で受け取る

納品時に受け取るものを、契約書か仕様書に書いておきます。

保守については、月額に含まれる作業と都度見積の作業を表にしてもらいます。「軽微な修正は無償」という書き方は、軽微の定義が両者で違うため後で揉めます。月◯時間までのように時間で切るほうが運用しやすい形です。引き継ぎ資料が作れないまま属人化していく問題については引き継ぎ資料が作れない原因と属人化の解消3手順も参考になります。

つまずきやすい3つの箇所

1. 要件整理を自社だけで完璧にやろうとする：整った要件定義書が無いと依頼できない、というのは誤解です。現物の資料と困りごとがあれば見積は出せます。むしろ自社で作った要件定義書は、実装できない前提を含みがちです。
2. 初回で全部入れようとする：機能を足すほど納期が延び、現場が覚えることも増えます。初回は3〜4機能に絞り、稼働してから足すほうが定着します。
3. 運用の窓口を決めないまま検収する：稼働後は必ず修正要望が出ます。誰が集約して開発会社に投げるかを決めていないと、要望が個別に飛んで管理不能になります。

まとめ

業務アプリ開発を依頼する流れは6ステップですが、発注側がやることは大きく2つです。①現物の資料をそのまま渡すこと、②決める人と合否基準を先に決めること。要件定義書を作るより、今のスプレッドシートを見せるほうが早く正確に伝わります。

今の運用のどこをアプリにすべきか、まだ整理できていない段階でもご相談いただけます。お使いのシートを拝見して、切り出せる範囲からお伝えします。