業務システムの開発を外注しようと考えたとき、「まず要件を固めてから相談しよう」と思う方は多いはずです。しかし、要件を発注者だけで固めるのは難しく、固めたつもりの要件が、作り始めてから変わることもよくあります。業務システムの外注をうまく進めるこつは、要件が固まる前から開発する側と一緒に整理し、画面を早く見て、使いながら直す ことです。この記事では、frectas がシステム開発を進めるときの流れを、相談から運用までの6つの段階に分けて説明します。法人向けの動画研修の LMS（学習管理システム）、ライブイベント向けの表示サービス、大学の研究室配属のマッチングなど、これまでの開発の例にも触れます。
全体の流れ
| 段階 | やること | 発注者に用意していただくもの |
|---|---|---|
| 1. 相談 | 困っていること、いまの手順、使っている道具を聞く | いまの業務の手順、困っていること |
| 2. 見極め | 既製品で足りるか、作るならどこからかを決める | 検討した既製品があれば、その感想 |
| 3. 要件の整理 | 業務の流れ、データ、例外、つなぐシステムを書き出す | 実物の帳票・データ・画面 |
| 4. 画面の試作 | 動く画面を早く作り、触って確かめる | 試作を触った感想 |
| 5. 開発とテスト | 本番の機能を作り、検証環境で通す | 検証環境での確認 |
| 6. 本番と運用 | 本番を立ち上げ、使いながら直す | 使ってみての要望 |
それぞれの段階を順に見ていきます。
1. 相談：要件が固まる前でよい
最初の相談で、整理された要件定義書は要りません。次のことが分かれば、話を始められます。
- 何に困っているか。 「毎月の集計に時間がかかる」「同じ情報を何か所にも入力している」「担当者しか分からない作業がある」
- いまはどうやっているか。 Excel、紙、既存のシステム、メールなど、使っている道具と手順
- 誰が使うか。 社内の担当者だけか、取引先や顧客も使うか
要件が固まる前に相談するほうがよい理由は、作らなくてよいものが見つかる からです。困りごとを聞いてみると、既製品で足りる、既存のシステムの設定で済む、作るのは一部だけでよい、ということがよくあります。要件を固めてから相談すると、そのすべてを作る前提で見積もりが出てしまいます。
2. 見極め：既製品で足りるか
次に、既製品（SaaS やパッケージ）で足りるか、作るべきかを見極めます。frectas では、既製品で足りる場合はそうお伝えします。
| 観点 | 既製品が向いている | 受託開発が向いている |
|---|---|---|
| 業務の流れ | 標準的で、既製品に合わせて業務を変えてもよい | 業務の流れそのものが会社の強みになっている |
| 例外の扱い | 例外が少ない | 取引先・案件ごとの例外が多く、既製品で扱えない |
| 既存のシステム | 単独で使える、または標準の連携で足りる | 複数のシステムをつなぐ必要がある |
| データ | 既製品の形に合わせられる | 既存のデータの形を変えられない、移行が要る |
| 費用の考え方 | 月額で始めたい、すぐ使いたい | 長く使う前提で、業務に合わせて育てたい |
既製品と受託開発は、どちらか一方とは限りません。既製品を中心に使い、足りない部分だけを作ってつなぐ、という形もよくあります。たとえば、受付や顧客管理は既製品のまま使い、そこから先の自社独自の処理だけを作る、という分け方です。
3. 要件の整理：実物を見ながら
作ると決めたら、要件を整理します。ここで大事なのは、説明を聞くだけでなく、実物を見る ことです。
業務の説明には、慣れた担当者にとって当たり前すぎて語られない約束事が抜けています。卸売・運送業者の受注業務の開発では、月間の定期注文書について、打ち合わせの場で実物を見ながら読み方の訂正が入りました。1枚に1か月分が載っているものの、出荷するのはその日の分だけだったのです。説明だけで作っていれば、誤った前提のまま開発が進んでいました（事例「卸売・運送業者の受注業務を、注文書の読み取りから配車の提案まで一つの仕組みに」）。
要件の整理では、次のものを一緒に見ます。
- 実物の帳票・データ。 例外的なもの（手書きの追記、様式の違うもの）も含めて
- いまの画面や Excel。 どの列をどう使っているか
- 作業の様子。 可能なら、作業の画面を録画したものや手順のメモ
物流・運輸の会社の業務の AI 化では、作業の動画マニュアルを文字起こしし、画面の動きを読み取って手順書に起こしてから自動化に取りかかりました。手順を文字にすると、「ここで何を見て判断しているのか」が見えてきます。
4. 画面の試作：触って確かめる
要件を文章で確かめるより、動く画面を触ったほうが早く正確に 認識をそろえられます。frectas では、要件の整理と並行して、画面の試作を早い段階で作ります。
建材卸の積算のシステムでは、「動く画面」を先に見せる必要があったため、画面の開発と、図面を解析する仕組みの開発を完全に並行させました。さらに、図面の解析がつながっていない状態でも、担当者が手作業だけで業務を完結できる画面にしました。画面が先にできていれば、解析の仕組みが育つ前から業務の流れを確かめられ、使い始めることもできます（事例「建材卸の積算を、AI がなくても回るシステムに」）。
試作を触っていただくときは、次の点を見ていただくと、意見が出やすくなります。
- いつもの作業の順番で操作できるか
- 例外的なケース（取り消し、修正、差し戻し）をどこで扱うか
- 誰がどの画面を使い、誰が確定するか
試作の段階で出た意見は、本番の開発に入ってから出る意見より、ずっと少ない手間で反映できます。
5. 開発とテスト：検証環境で通してから本番へ
本番の機能を作る段階では、検証環境と本番環境を分け、検証環境で一通り動かしてから本番を立てる ことを基本にしています。卸売・運送業者の案件では、検証環境と顧客が使う環境を別のクラウドのプロジェクトに分け、変更は検証環境で通してから本番に反映しています。
データの移行は早めに試す
既存のシステムから新しいシステムに移るときは、データの移行が大きな山になります。法人向けの動画研修の LMS では、システムの構築に加えて、データベースを Firestore から PostgreSQL へ移しました。利用者・組織・研修のシリーズ・動画といったデータを、新しいデータベースの形に合わせて移しています。
データの移行で気をつけることは次のとおりです。
- 本番のデータで早めに試す。 テスト用のデータでは見つからない、古いデータの形の揺れや欠けがある
- 移した後に突き合わせる。 移行前と移行後で、件数や中身が一致するかを機械的に確かめる
- 戻す手順を決めておく。 移行に失敗したときに、元に戻せるようにしておく
つなぐ相手の「実物」で試す
既存のシステムとつなぐときも、実物で試すことが大切です。卸売・運送業者の案件では、既存の倉庫システムとの連携で、CSV で試して動いたものが、API では値の形が違って動かないことがありました。CSV では出力時に整形されていた値が、API では整形前の形で届いたためです。「別の方法で試して動いたから大丈夫」とは言えません。
6. 本番と運用：使いながら直す
業務システムは、使い始めてから要望が出てくるものです。本番を立ち上げた後は、定例で要望を確かめながら直していく前提で進めます。
継続して開発する
ライブイベント向けの表示サービスでは、イベントの運営の中で出てくる要望に合わせて、継続して開発を続けています。イベントのように本番の日が決まっている仕組みでは、本番の前に検証環境で確かめる時間を取ること、本番中に止まらないことが何より大切です。一般に、本番の日が決まっている仕組みでは、新しい機能を一度に詰め込まず、確かめきれる範囲に絞って入れるほうが安全です。
決まりごとを仕組みにする
大学の研究室配属のマッチングは、決めた規則にもとづいて配属を決める仕組みです。配属のような手続きでは、「どういう規則で決まったのか」を説明できることが大切です。規則を仕組みに書き込んでおけば、毎年の担当者が変わっても同じ手順で運用でき、結果の説明もしやすくなります。
費用も運用しながら見直す
稼働した後に、クラウドの費用を見直すこともあります。卸売・運送業者の案件では、本番のデータベースの構成を見直し、障害時の復旧を手動で行うことを受け入れる代わりに、月額を約43,400円から約14,200円に下げる見込みを立てました（請求額から逆算した概算）。最初から最小の構成にするのではなく、使われ方が分かってから、業務に合った構成に調整します。
一括で納品するか、継続して開発するか
開発の頼み方には、大きく2つの形があります。どちらが合うかは、作るものがどこまで決まっているかで変わります。
| 形 | 向いているとき | 気をつけること |
|---|---|---|
| 一括で納品する | 作るものと期限がはっきりしている。新しい事業の最初の版を、決まった日までにそろえたい | 途中で範囲が広がると、期限と費用に響く。範囲の変更の扱いを最初に決めておく |
| 継続して開発する | 使いながら要望が出てくる。業務やイベントに合わせて機能を足し続けたい | 優先順位を定例で決める。何を次の版に入れ、何を見送るかを共有する |
新しい事業の最初の版のように、範囲と期限が決まっているものは一括の形が合います。最初の版の範囲と、動かし始めてからかかる費用の目安を一緒に示すと、事業の収支を考える材料になります。
一方、ライブイベント向けの表示サービスや、法人向けの動画研修の LMS のように、使われ方に合わせて育てていく仕組みは、継続して開発する形が合います。最初の版を一括で作り、その後は継続して開発する、という組み合わせもよくあります。
相談の前に用意しておくとよいもの
最初の相談で全部がそろっている必要はありませんが、次のものがあると、話が早く進みます。
- いまの業務で使っている帳票・Excel・画面の写し。 個人情報や取引先の名前は伏せたもので構いません
- 困っている作業の流れ。 誰が、いつ、何を見て、何をしているか。箇条書きのメモで十分です
- 検討した既製品があれば、その名前と合わなかった点。 合わなかった点に、作るべき部分の手がかりがあります
- 使う人の範囲。 社内の担当者だけか、取引先や顧客も使うか。スマホで使うか
- いつまでに、どこまで動けばよいか。 補助金の申請や、事業の開始日などの期限があれば
外注で失敗しないための5つのポイント
- 要件を固めてから相談しようとしない。 困りごとの段階で相談すれば、作らなくてよいものが見つかる
- 既製品で足りるかを先に確かめる。 足りるなら、そのほうが安く早い
- 実物を見せる。 帳票・データ・画面・作業の様子。説明だけでは約束事が抜ける
- 画面を早く触る。 文章の要件より、動く画面のほうが認識をそろえやすい
- 使いながら直す前提で始める。 最初から完璧を目指すより、本番の業務で使って直すほうが、業務に合った仕組みになる
費用の目安
業務システム・アプリの受託開発は、100万円〜（税抜）が目安です。画面の数、つなぐシステムの数、データの移行の有無、使う人の範囲（社内だけか、取引先や顧客も使うか）で変わります。AI を組み込む場合の費用の考え方は「業務 AI 化・システム開発の費用の考え方」にまとめています。
サービスの内容は「システム・アプリの受託開発」をご覧ください。要件が固まっていない段階でも構いません。いまの業務の手順と困っていることを、お問い合わせから教えていただければ、既製品で足りるかどうかを含めてお答えします。
