DP-GUILD
初版: 2026-11
更新: 2026-11
在庫や請求の手作業を仕組みにしたい。でも、システム開発を外の会社に頼んだら、どんな順で進み、自社はいつ何を決めて、何が手元に届くのかが、外からは見えにくい。この記事では、業務の仕組みを作りたい中小企業の社長や担当の方に向けて、システム開発の流れを「頼む側の番」で並べ直します。
先に結論を書くと、弊社は、7つの段の中で頼む側が一番重い役を持つのは、何を作って何を作らないかを文書で決める「要件定義」と、実際のデータで試して受け入れるかを決める「テスト」の2つだと考えます。この2つを開発会社に任せきりにすると、出来上がった仕組みが現場で使われず、元のExcelに戻ることになりかねません。
何を作るかが決まっていなくても、無料相談で、どの作業から手を付けるとよいかを一緒に整理できます。相談だけでも大丈夫です。売り込みはしません。
システム開発の流れは、頼む側から見ると7つの段で進む
開発会社の記事では、要件定義に始まり、2段に分けた設計、プログラムを書く工程、何種類ものテスト、というふうに、作る側の工程で細かく分けて説明されます。頼む側から見ると、その多くは開発会社の中の作業です。弊社は、頼む側が覚えておく段は次の7つで足りると考えます。下の表には、7つの段それぞれで頼む側が決める物と、手に渡る物を並べました。
段 | 開発会社の作業 | 頼む側が決めること | 頼む側の手に渡る物 |
|---|---|---|---|
0. 頼む前の準備 | — | どの作業を仕組みにしたいか（困っている作業と、かかっている時間） | 社内のメモ（作業と時間の書き出し） |
1. 相談と見積り | 今の作業と表・帳票を聞き、作り方の方向と見積りを出す | 見積りに何が入り、何が入らないか | 作り方の方向と見積りの文書 |
2. 要件定義 | 作る物・作らない物・使う人と権限を文書にまとめる | 作る物と作らない物、誰がどこまで使うか | 仕様書（要件定義書） |
3. 設計 | 画面・入力の場所・データのつながりを形にする | 画面と、どこで1回だけ入力するか | 画面の案・設計の文書 |
4. 開発 | 仕組みを作り、途中で触れる形で見せる | 途中の形を触って、違う所を言う | 途中の版（触って確かめる物） |
5. テスト（受け入れ） | 作った仕組みを試し、不具合を直す | 実際のデータで試し、受け入れるか | 直した仕組み・試しの結果 |
6. 公開と運用 | 本番に移し、使い方を渡す | 誰が持ち、誰が直し、保守を頼むか | 仕組み本体・手順書・アカウント |
どの段にも頼む側の番があり、中でも2の要件定義と5のテストは、頼む側が決めないと前に進みません。開発会社は、聞いていない現場の事情までは作れないからです。
「相談の前に、社内で何を用意する？」——次は、相談の前に社内でそろえる物を順に追います。
頼む前に社内でやること：作業を数える
「システムを作りたい」と思った時、最初に考えがちなのは、どんな機能を付けるかです。弊社は、その前に、どの作業に、月に何時間、何人が使っているかを数えることをおすすめします。時間がかかっていない作業を仕組みにしても、作る費用は戻らないからです。
数えるのに、きれいな表は要りません。次の4つを、作業ごとに1行ずつ書き出すだけで、相談の中身が具体的になります。
- どんな作業か（在庫の数え直し、勤怠の集計、請求書づくり、など）
- どれくらいの頻度で、1回に何分かかり、誰がやっているか
- 同じ数字を、別の表や書類に写し替えていないか
- 決まった手順から外れる例外（この取引先だけ締め日が違う、など）はあるか
書き出してみると、専用のシステムを作らなくても、今のExcelやスプレッドシートに自動化を足すだけで済む作業や、既製のサービスで足りる作業が見つかることがあります。作るかどうかの前に、ツールや進め方から考えたい時は、中小企業のDXは何から始めるべき？やノーコードツールは中小企業に向いているか？が先に役立ちます。
あわせて、社内で最後に決める人を1人、現場の事情を答えられる人を1人、決めておくと、要件定義で話が行き来せずに済みます。
「相談の後は、どの順で何を決める？」——次は、7つの段の中身を見ていきます。
7つの段の中身：頼む側の番を1つずつ
1. 相談と見積り：金額の前に「入っていない物」を読む
相談では、今の作業の流れと、使っている表や帳票の現物を見せると話が早く進みます。届いた見積りは、金額より先に、何が含まれ、何が含まれないかを確かめます。弊社が特に見てほしいと考えるのは、今のデータの移し替え、会計ソフトなど他のソフトとのつなぎ、納品後の保守、サーバーや外部サービスの毎月の利用料の4つです。この4つが書かれていない見積りでは、始まってから別の請求が足されかねないと弊社は見ています。
2. 要件定義：作る物と、作らない物を文書で決める
要件定義は、何を作るかを文書で決める段です。情報処理推進機構（IPA）が2019年に公開した「ユーザのための要件定義ガイド 第2版」も、要件を決める責任は、作った仕組みを使って仕事をする側（頼む側）にあるという立場で書かれています。開発会社は聞き取りと文書づくりを手伝えますが、自社の業務のどこを変えるかを決めるのは頼む側です。
この段で文書に残してほしいのは、次の3つです。
- 作る物と、作らない物（作らない理由も添える）
- 誰がどこまで見られて、どこまで直せるか
- 同じ数字を写し替えずに済むよう、どこで1回だけ入力するか
「作らない物」を決めるのは、作る物を決めるのと同じくらい大事です。あれもこれもと足すほど、作る費用も、使い方を覚える手間も増えます。
3. 設計：言葉ではなく、画面で確かめる
設計の段では、画面の案や入力の流れが出てきます。文書の説明だけで「はい」と言わず、画面の案を見て、現場の担当者が毎日どの順で入力するかをなぞってみてください。入力の順が今の作業と逆、といったずれは、この段のうちに言えば直す手間が小さく済みます。
4. 開発：途中で触れる形を見せてもらう
この段で頼む側が決めておきたいのは、途中の形をいつ、どうやって見せてもらうかです。最後にまとめて見て、イメージと違うと気づくのが、直す量の一番大きい形です。途中の版を触って、違う所を早めに言うのが頼む側の番です。仕様を途中で変えたくなった時に、費用と予定をどう話し合うかも、始める前に取り決めておきます。
5. テスト（受け入れ）：実際のデータで試すのは頼む側
開発会社も作った物を試しますが、自社の業務に合うかは、自社のデータで試さないと分かりません。月末の締め、例外の取引先、担当者が休んだ日など、いつもと違う場面のデータを入れて試し、合わない所を挙げてください。ここで「受け入れる」と決めた物が、納品の物になります。
6. 公開と運用：誰が持ち、誰が直すかを決める
公開の前に、作った仕組み（表計算のファイルやソースコード）とサーバーの契約が誰の物になるか、使い方の手順書があるか、社内で直してよい範囲はどこまでか、納品の後の不具合と保守をどう頼むかを確かめます。これが決まらないままだと、小さな変更のたびに外へ頼むことになります。
「段ごとに決めても、どこで止まる？」——次は、流れが途中で止まる4つの原因を見ていきます。
流れが途中で止まる4つの原因
システム開発の流れが止まる、あるいは出来上がっても使われない原因は、弊社の見立てでは次の4つに集まり、そのどれもが頼む側の受け持ちです。
- 決める人がいない：確認のたびに、現場・管理する人・社長の全員に聞いて回っていると、要件定義も設計も前に進みません。最後に決める人を1人に絞り、いつまでに返事をするかもあわせて決めておきます。
- 例外を出し切らない：いつもの手順だけを伝えると、締め日の違う取引先や、月に1回だけの処理が抜けます。作ってから足すと、作り直しになることがあります。要件定義の段で「いつもと違う場面」を書き出しておきます。
- 途中を見ない：忙しくて途中の版を触らずにいると、最後に大きなずれが見つかります。途中の版を触る日を、始める前に社内の予定へ書き込んでおきます。
- 公開後の持ち主が決まっていない：直す人と、社内で直してよい範囲があいまいなままだと、担当者が変わった時に誰も触れない仕組みが残ります。
作る費用を払ったのに、現場は使いにくい仕組みを避けて、元の表と手作業に戻ってしまう——これは避けたい事態です。どれも、作り始める前の取り決めで避けられます。
「ウォーターフォールやアジャイルは、頼む側にも関係ある？」——次は、進め方の違いを頼む側から見ていきます。
ウォーターフォールとアジャイル、頼む側は何が違う？
開発の進め方には、段を順に1つずつ終えていくウォーターフォールと、小さく作って見せ、直しながら広げていくアジャイルがあります。頼む側にとっての違いは、決める時期と、契約の結び方です。
- ウォーターフォールは、最初に作る物を決めきるので、費用と予定の見通しを立てやすい一方、途中で変えると手戻りが大きくなります。
- アジャイルは、途中で変えやすい一方、頼む側が短い間隔で確かめて決め続ける手間がかかります。
契約の面では、経済産業省とIPAが公開している「情報システム・モデル取引・契約書」で、工程ごとに個別の契約を結び、段によって、成果物を完成させる契約（請負）と、作業そのものを頼む契約（準委任）を使い分ける考え方が示されています。どの段がどちらの契約になるかで、完成しなかった時の扱いが変わるため、見積りをもらう時点で確かめてください。
弊社は、中小企業が業務の仕組みを作る場合は、何を作って何を作らないかを先に文書で決め、そのうえで途中の形を触って確かめながら進める形をおすすめします。作る物を決めずに走り出すと、頼む側が確かめ続ける手間が重くなりやすいためです。
「頼むと決めたら、弊社ではどう進む？」——次は、弊社に頼んだ場合の段取りを順に追います。
DP-GUILDに頼む場合の流れ
弊社のシステム開発・業務の自動化では、専用のシステムを作ることを前提にせず、まず作業を数えてから、今のExcel・スプレッドシートに自動化を足すか、専用のシステムを作るかを選びます。複数の作業をつなぐ時や、専用のシステムを作る時は、次の順で進めます。
- 資料請求・ご相談：困っている作業を、ひとことお知らせください。
- ヒアリング：30分のオンライン、または文章で、今の作業の流れと、使っている表・帳票の現物を見せていただきます。
- 作り方の方向とお見積り：表計算の自動化か専用のシステムか、作らない物の見込みとお見積りを文章でお出しします。ここまで費用はかかりません。
- 棚卸しと仕様の合意：ご依頼のあと、作業を詳しく数え、何を作るか・誰がどこまで使えるかを文章で合意してから作り始めます。
- 制作：途中で触れる形でお見せし、確認しながら進めます。
- 試しの運用：実際のデータで使っていただき、合わない所を直します。
- 納品：使い方の手順書をつけてお渡しします。保守が必要な場合は別途ご相談ください。
請求書の作成だけなど、小さな自動化1つの時は、作る物とお見積りを1枚の文章にまとめて進めます。作った仕組み（表計算のファイル・ソースコード）とサーバーの契約は、納品した時点で御社の持ち物となり、契約を終えた後も御社に残ります。
この進め方の土台は代表の経歴です。ITコンサルタント・プロジェクトマネージャーを経て、官公庁の案件ではPMOとして要件定義から関わり、大手食品メーカーでデータを活用するプロジェクトでは、頼む側に立って提案依頼書の作成やベンダー選定などを担当しました。頼む側と作る側の両方の立場で仕事をしてきたことが、DP-GUILDが要件定義とテストを頼む側と一緒に詰める理由です。
作った物では、飲食業の店舗を探せるポータルサイトで、必要だと思われていた20項目を理由をつけて外し、月額の決済や公開前の審査の仕組みを作って、公開後も毎月の保守を続けています。ほかに、入力しておけば手作業で作っていた請求書がワンクリックで出来上がる仕組み（実際の業務で使われました）、接客業の勤怠管理と給与計算の自動化、畜産業の在庫管理の仕組み化を担当しました。
甲賀市を拠点にする弊社は、ご相談から納品まで文章かオンラインで進めるため、関西でも遠方でも手順は変わりません。
それでも、この進め方は誰にでも合う万能な形ではありません。試しの運用で実際のデータを入れられる方が社内にいないと、出来上がった仕組みが業務に合うかを確かめようがありません。その場合は、まず社内で確かめる役の方を決めるところから始めることをおすすめします。また、数えてみて既製のサービスで足りると分かった時は、作らずにそうお伝えします。
「何を自動にすればよいか、まだ決められない」「システム開発の流れのどこで何を決めればよいか迷っている」という状態でも、相談していただいて大丈夫です。一緒に整理するところから始められます。お申し込みは無料相談のページからどうぞ。ヒアリングとお見積りに費用はかからず、話を聞くだけで終えても問題ありません。売り込みはしません。資料「作業時間とコストを減らす仕組みの選び方」は、サービスのページからお申し込みいただけます。
この情報は2026年11月時点のものです。