整理券発行システム開発の発注/外注/依頼/委託方法について

整理券発行システムの発注・外注は、既製サービスで足りる範囲と個別開発が必要な範囲を切り分け、現場の受付ルールをRFPに落とし込んで同じ条件で見積比較することが成功の近道です。

病院・クリニック、飲食店、自治体窓口、商業施設、イベント会場では、紙の番号札だけでなく、Web受付、QRコード、LINE通知、モニター表示、予約・抽選・決済連携まで求められる場合があります。本記事では、発注形態の選び方、RFPと要件整理、契約形態、費用相場、委託先の選定、見積書の比較方法を、整理券発行システムの外注を検討する担当者向けに順を追って解説します。

▼全体ガイドの記事
・整理券発行システム開発の完全ガイド

整理券発行システムの発注・外注では何を決めますか？

整理券発行システムの発注では、発券機を購入するだけか、受付から呼出・分析までの業務システムを導入するかを最初に分けて考えます。費用や期間を左右するのは、来訪者数だけではなく、ピーク受付数、窓口数、通知方法、個人情報の有無、既存システムとの連携範囲です。

整理券発行システムとは、受付順や予約順に番号を付け、スタッフが順番を管理し、利用者へ呼出状況を伝える仕組みです。紙の番号札と音声呼出だけのスタンドアロン型、タブレットとプリンターを使うクラウド型、WebやLINEから受付できるSaaS、予約・抽選・決済・顧客管理まで組み込む個別開発型に分けられます。

発注前に「整理券を出したい」とだけ伝えると、ベンダーによって見積の前提が変わります。発券、窓口別の呼出、待ち時間表示、再呼出、保留、キャンセル、集計、権限管理、外部連携のどこまでを含めるかを、業務の流れに沿って言語化することが重要です。

最低限、1日あたりの平均受付数とピーク受付数、営業日・営業時間、窓口や診療科の数、利用者が待つ場所、スマートフォンを使わない人の割合、通知に使える手段を整理します。さらに、呼出に応じなかった場合の保留・再呼出、二重発券や順番変更、通信断・停電・用紙切れのときの代替運用も確認します。

医療や自治体で氏名・電話番号・予約情報を扱う場合は、保存する情報、保存期間、閲覧できる担当者、操作ログ、委託先と再委託先まで発注条件に含めます。番号と時刻だけで運用できるなら、データを最小化することが費用とセキュリティリスクの両方を下げます。

整理券発行システムの発注形態はどれを選びますか？

発注形態は、既製のSaaS、機器とクラウドの組み合わせ、既存システムへの機能追加、フルスクラッチ開発の順に自由度と責任範囲が大きくなります。最も高機能な方式を選ぶのではなく、業務上譲れない条件を満たす中で、導入期間と運用負担が小さい方式から検討します。

1店舗・1窓口で、発券、待ち組数の表示、番号呼出、簡単な集計ができればよい場合は、既製サービスが候補です。Airウェイトは無料プランに加えて、ベーシックが月額11,000円（税込）、スタンダードが月額22,000円（税込）で、オンライン受付や外部ディスプレイ、窓口別呼出などが段階的に追加されます（出典: 株式会社リクルート「Airウェイト 有料プランについて」、2026年8月確認）。

シチズン・システムズのCQ-S257系には、ネットワーク接続なしで発券する構成と、スマートフォンやモニターで順番を確認するクラウド構成があります。公式仕様では月額使用料無料の機種と、月額3,300円（税込）のクラウド機種が示され、導入検討者向けの2週間無料デモ機貸出も案内されています（出典: シチズン・システムズ株式会社「整理券システム」、2026年8月確認）。ただし、端末本体、プリンター、モニター、設置、通信、保守は別に見積もる必要があります。

店外から受付させたい、待ち時間に買い物や別の用事を済ませてもらいたい、通知で離脱を減らしたい場合は、WebやLINE受付型が適しています。matocaはLINEミニアプリで、店頭タブレット、スタッフ発券、QRコードからの店外発券に対応し、公式サイトでは導入企業380社超、導入店舗2,200店突破と掲載されています（出典: 株式会社ブレイブテクノロジー「matoca」、2026年8月確認）。

一方で、LINEを使わない利用者を残すなら、紙発券、電話通知、店頭スタッフによる代行受付を組み合わせます。デジタル導線だけに寄せると、高齢者、外国人、端末を持たない人が受付できないため、利用者層に応じた複線化が発注条件になります。

既存の電子カルテ、予約、POS、会計、施設サイネージ、会員基盤と連携する必要があり、既製サービスの運用ルールに合わせられない場合は、個別開発を検討します。たとえば、診療科ごとに異なる呼出順を制御する、整理券と時間予約を同じ窓口で処理する、イベントでランダム発番と抽選を行うといった要件は、追加開発の対象になりやすいです。

ただし、独自機能を増やすほど、要件定義、テスト、障害対応、将来の改修を発注者が負担します。競争優位に直結しない機能まで作り込まず、既製品で実現できる部分を残し、連携や業務固有の部分だけを外注するハイブリッド方式も有効です。

整理券発行システムの発注・外注はどう進めますか？

発注は、相談、現場調査、RFP提示、提案・見積比較、契約、要件定義、設計・設定、テスト、教育、本番導入、運用改善という流れで進めます。発注先に丸投げするのではなく、業務上の目的と受入基準を自社で持つと、納品後に使われないシステムになりにくいです。

最初に、混雑する曜日や時間帯を観察し、来訪、受付、発券、待機、呼出、対応完了、キャンセルの流れを記録します。スタッフが紙に書いている情報、口頭で伝えている例外、利用者から多い問い合わせを洗い出すと、単なる機能一覧では見えない要件が見つかります。

目的は「行列をなくす」ではなく、「待ち時間を見えるようにする」「受付スタッフの問い合わせを減らす」「呼出不在による機会損失を減らす」のように測れる言葉にします。導入後は、ピーク時の受付処理時間、待合場所に滞留する人数、呼出後の不在率、電話問い合わせ件数などで効果を確認します。

全拠点への一括導入を前提にせず、まず1窓口・1店舗で試します。利用者が自分で発券できるか、番号の呼出が聞き取れるか、用紙補充や再発券をスタッフが迷わないか、通信が切れたときに紙運用へ戻せるかを、通常日と繁忙日の両方で確認します。

受入基準は「画面が表示される」では不十分です。「ピーク時に同時接続が何件でも受付できる」「呼出から一定時間経過した番号を保留にできる」「操作ログから担当者と時刻を確認できる」「障害時に手作業で未処理番号を復元できる」のように、業務結果で定義します。

システムが完成しても、スタッフが呼出・保留・取消・再発券を使えなければ現場は紙へ戻ります。担当者別の操作研修、短い業務マニュアル、問い合わせ窓口、繁忙日の立ち会い、旧運用との並行期間、障害時の連絡先を契約前に確認します。

本番後の改善も、初期契約の保守範囲と追加開発の扱いを分けておきます。通知文の変更や窓口追加のような設定変更と、データ構造や外部連携の変更では工数が異なるため、変更依頼の受付方法、回答期限、見積承認の手順を決めておくと運用が安定します。

RFPと要件整理には何を書けばよいですか？

RFPは、発注者の課題、対象業務、利用者、必要機能、非機能要件、連携、導入条件、見積・提案の回答形式をまとめた依頼書です。細かな画面仕様を最初から断定するより、現状と達成したい結果を示し、提案者が複数方式を比較できる余地を残します。

RFPには、利用者がどこから受付するか、何を入力するか、整理券を受け取った後どこで待つか、いつ・どの手段で呼び出すかを記載します。受付順と予約順の優先順位、複数窓口への振り分け、同じ番号を再呼出する回数、遅刻・不在・キャンセル・重複発券の扱いも、具体的なシナリオで示します。

「通常時」だけでなく、プリンターの用紙切れ、タブレットの故障、インターネット断、電源断、想定を超える来訪、スタッフの交代も記載します。外注先には、障害時に自動復旧するのか、管理者が手動で復旧するのか、紙の代替運用をどう記録へ戻すのかを提案してもらいます。

機能要件は、必須のMUST、できれば欲しいSHOULD、将来検討のCOULDに分けます。MUSTには発券、現在番号の管理、呼出、保留・取消、現地発券を置き、Web受付、LINE通知、予約、抽選、決済、会員連携、詳細分析は業種と目的に応じて優先順位を付けます。

各機能には「誰が」「いつ」「何を入力し」「何が起こり」「どの記録が残るか」を書きます。たとえば「受付担当が診療科を選択して発券し、受付番号と発券時刻を保存し、患者には番号だけを表示する」と書けば、画面、データ、権限、プライバシーの議論を同時に進められます。

非機能要件には、ピーク時の同時受付数、画面応答時間、稼働時間、バックアップ、障害復旧目標、保守受付時間、対応言語、アクセシビリティを含めます。イベントでは短時間にアクセスが集中するため、通常日の受付数ではなく、販売開始・開場直後などの最大負荷を前提にします。

API連携では、既存システムの名称、データ項目、連携方向、連携頻度、エラー時の再送方法、認証方式を整理します。個人情報を扱う場合は、利用目的と保存期間、権限、操作ログ、委託先・再委託先、国外保管の有無、削除手順を確認します。個人情報保護委員会の通則編ガイドラインを参照し、安全管理措置を契約・運用へ反映します（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年8月確認）。

契約形態は請負と準委任のどちらが適していますか？

契約形態は、納品物と完成条件を明確にする請負と、作業時間や専門知識の提供を重視する準委任を基本に比較します。どちらが正解ということではなく、要件が固まっている部分と、検証しながら決める部分を分けて契約することがポイントです。

請負契約は、要件定義書、画面、プログラム、テスト結果、操作マニュアルなど、納品する成果物を定め、発注者の検収を経て対価を支払う方式です。既製サービスの初期設定や、仕様が確定した発券・呼出機能には適用しやすい一方、要件変更が頻発すると追加費用や納期変更が発生しやすくなります。

検収条件は、画面の完成度だけではなく、受入テストのシナリオ、性能、権限、ログ、バックアップ、障害時の復旧、マニュアルと研修の完了で定義します。検収後に見つかった不具合の無償修正期間、瑕疵対応の範囲、第三者サービスの障害責任も契約書で確認します。

準委任契約は、発注者と外注先が一定期間、要件整理、設計、技術調査、プロジェクト管理、運用改善などを協力して進める方式です。複数の現場を見ながら最適な発券方法を探す、既存システムとの連携可否を検証する、PoCの結果で本開発へ進むといった局面に向いています。

準委任では、成果物の完成を無条件に保証する契約ではないため、作業範囲、担当者、稼働時間、定例会、報告内容、成果の評価方法を具体化します。発注者側にも意思決定者と現場代表を置き、確認を先送りしないことが、期間だけが延びるリスクを抑えます。

整理券発行システムでは、最初の要件定義・PoCを準委任で行い、仕様が固まった発券・呼出・連携部分を請負で開発し、運用保守を別契約にする組み合わせが現実的です。契約を分ける場合は、要件定義の成果物を次工程へ引き継ぐ方法、責任分界、データやソースコードの権利、契約終了時の引き渡しを決めます。

見積書に「一式」とだけ記載された場合は、契約形態と内訳が見えません。要件定義、設計、開発・設定、機器、連携、試験、移行、研修、保守を分け、固定費・従量費・追加変更費のどれに該当するかを確認します。

整理券発行システムの費用相場はいくらですか？

整理券発行システムの費用は、簡易発券なら初期数万円から数十万円、クラウド型なら月額数千円から数万円、連携や個別開発を含めると数百万円から数千万円まで広がります。以下の金額は、公開料金と類似業務システムの相場から整理した目安であり、整理券専用開発の確定価格ではありません。

既存タブレットを利用し、1窓口で発券と呼出だけを行うなら、設定・プリンター・用紙・掲示物を含む初期費用は0万〜20万円程度、月額は0円〜2.2万円程度が入口の目安です。専用発券機、待ち状況モニター、音声呼出、複数窓口を加えると、機器・設置・ネットワークを含む初期費用は20万〜100万円程度まで見ておくと比較しやすいです。

無料プランや月額無料の機器でも、タブレット、プリンター、モニター、通信回線、用紙、設置、故障交換、電話サポートは無料とは限りません。SMSや電話通知は従量課金になることがあるため、月間受付数と通知数を掛け合わせた年間総額で確認します。

POS、予約、CRM、電子カルテ、自治体の窓口管理などと連携する小〜中規模案件は、整理券側のAPI開発、個人情報、複数拠点、テスト、移行を含めて100万〜800万円程度が推定レンジです。これは公開統計ではなく、NotebookLMで確認した類似業務システムの相場と、整理券側に必要な連携・運用工数から組み立てた目安です。

複数施設・複数部門に加え、予約枠、抽選、決済、会員連携、分析ダッシュボードまで作る場合は、300万〜1,500万円程度を見ます。データ連携先が増えるほど、相手側の仕様確認、エラー処理、権限、総合テストの費用が増えるため、機能数だけで判断しないことが大切です。

小規模な専用受付をスクラッチ開発する場合は800万〜2,000万円、複数拠点・外部連携・高負荷イベント対応まで含める場合は2,000万〜5,000万円以上という推定レンジになります。開発期間も4〜18か月程度と幅があり、整理券専用の公開相場ではなく、類似する業務システムやPOSの開発規模を基にした試算です。

このレンジを予算の断定値として使うのではなく、既製品で置き換えられない要件を抽出するために使います。発注前には「既製品で実現」「設定変更で実現」「追加開発で実現」「新規開発が必要」の4分類を作り、それぞれの初期費用、月額、保守費、将来変更費を見積書に分けてもらいます。

委託先の選定と見積比較では何を見ますか？

委託先は、会社名や機能の多さだけで決めず、自社と似た業種・受付規模で運用した経験、障害時の支援体制、連携実績、提案の透明性で評価します。整理券発行システムでは、開発会社だけでなく、機器メーカー、SaaS事業者、導入支援会社が候補になるため、どこまでを自社で提供し、どこからを外部委託するのかも確認します。

実績を見るときは、単に「導入社数」ではなく、1日ピーク受付数、窓口数、紙とスマートフォンの併用、複数部門、外部連携、障害時の運用まで聞きます。EPARKの公式法人向け情報では、店頭発券後に待ち状況を確認でき、不在者を保留にして後で再呼出する運用が紹介されています（出典: 株式会社EPARK「順番待ちシステム」、2026年8月確認）。自社に必要な例外処理が実際に運用されているかを、画面デモと導入事例の両方で確認します。

医療なら患者の氏名を大声で呼ばず番号で案内できるか、自治体なら窓口・言語・申請種類をどう振り分けるか、イベントなら短時間の集中アクセスや抽選をどう処理するかが選定ポイントです。導入後の現場訪問、電話受付の時間帯、休日の障害対応、代替機の発送条件も、見積前に質問します。

候補は2〜3社に絞り、同じRFP、同じ受付数、同じ窓口数、同じ通知条件で提案を依頼します。比較表では、初期費用、月額、従量課金、機器・設置、データ移行、連携、テスト、教育、保守、追加変更、解約時のデータ返却を分けます。「導入費一式」や「保守一式」は、作業内容と数量を質問して分解します。

安い見積が必ずしも有利とは限りません。要件の抜け、連携の別料金、繁忙期の性能増強、SMS・電話通知の従量費、問い合わせの受付時間、障害時の代替運用が含まれていない可能性があります。初年度総額と3年間の総保有コストを並べ、価格・適合性・継続性の3軸で評価します。

選定時は、必須要件への適合を最優先にし、次に現場の使いやすさ、連携とセキュリティ、導入期間、初期費用、運用費、サポート体制を点数化します。価格だけを重くすると、現場が使いにくく、結局スタッフが紙で二重管理するリスクを見落とします。

候補会社には、想定する弱点も説明してもらいます。スマートフォンを使わない人への対応、通信障害時の復旧、番号の重複、呼出不在、個人情報漏えい、データ返却、ベンダー変更時の移行を質問し、回答が契約書やSLAに反映されるかを確認します。

発注後の失敗を防ぐにはどうしますか？

発注後に起こりやすい失敗は、要件不足、現場教育不足、通知手段の偏り、例外処理の未定義、保守範囲の誤解です。システムを導入すれば行列が自動的に消えるわけではなく、受付ルールと人員配置、案内表示、利用者への説明を一緒に整える必要があります。

クラウド型でも、受付現場が完全にオンラインへ依存すると、通信障害の数十分が業務停止につながります。紙の番号札、手書きの呼出記録、復旧後の再入力、利用者への案内文、予備のプリンターや用紙の保管場所を決め、年に数回は障害訓練を実施します。

端末の故障時は、誰が代替機を手配し、何時間以内に復旧を目指し、どのデータを復元するのかを確認します。バックアップの頻度や保存期間、復元テストの実施有無を聞き、SLAや保守契約に書かれていない口頭の約束を残さないことが大切です。

番号で呼び出す運用は、氏名を表示・音声案内しないことでプライバシーに配慮できますが、番号を取り違えれば別の利用者を案内する事故になります。発券券面、モニター、通知文、窓口画面で表示する情報をそろえ、本人確認が必要な場面と番号だけで進める場面を分けます。

スタッフには、管理者権限を共有しないこと、受付情報を私物端末へ転送しないこと、不要なデータを保存しないこと、問い合わせ時に本人確認を行うことを研修します。導入後はアクセスログと権限を定期的に見直し、担当者の異動や委託終了時にはアカウントを停止します。

整理券発行システムの発注・外注に関するよくある質問

発注前に多い疑問を、費用・開発方法・運用の観点から回答します。公開料金は更新されるため、ここで示す金額や仕様は2026年8月に確認した情報と、リサーチノートに基づく目安として扱い、最終判断では候補先の最新見積を確認します。

無料プランや月額無料の発券機はありますが、端末、プリンター、用紙、通信、設置、通知、保守まで含めて無料とは限りません。小規模なら無料または月額数千円から始められる場合がありますが、3年間の機器・運用費を合算して判断します。

既製品では対応できない業務ルール、複数システム連携、強い独自性、高負荷イベントなどがある場合に限り、スクラッチ開発を検討します。発券・呼出・通知だけなら、既製SaaSや機器を使い、連携部分だけを追加開発する方が、初期費用と保守負担を抑えやすいです。

対応できますが、店頭発券機、紙の番号札、スタッフによる代行発券、番号表示、音声案内を残す設計が必要です。LINEやWebを主な導線にする場合でも、利用者が選べる受付方法を用意し、画面の文字サイズ、言語、案内文を実際の利用者に試してもらいます。

APIやファイル連携など、相手システムの仕様と契約条件が合えば連携できます。RFPでデータ項目、連携方向、頻度、認証、エラー時の再送、個人情報の扱いを示し、候補先から「標準機能」「設定」「追加開発」「連携不可」の回答を分けてもらうと、見積差の理由が分かります。

整理券発行システムの発注・外注方法まとめ

整理券発行システムを外注するときは、最初に「誰の待ち時間を、どの業務で、どの指標で改善するか」を決めます。そのうえで、既製SaaS・発券機・WebやLINE型・個別開発を比較し、MUST要件を満たす方式から選びます。

RFPには、業務フロー、例外処理、ピーク受付数、窓口数、通知方法、個人情報、連携、障害時の代替運用、受入基準を記載します。候補先には同じ条件で提案を依頼し、初期費用だけでなく月額、従量課金、機器、保守、追加開発、解約時のデータ返却まで比較します。

契約形態は、要件が固まった部分を請負、検証や伴走が必要な部分を準委任とするなど、プロジェクトの状態に合わせて設計します。通信断、用紙切れ、呼出不在、権限管理、保守窓口を本番前に確認し、現場が安心して使える体制まで含めて発注先を決めることが、整理券発行システムを定着させるポイントです。

自社の受付業務と将来の拡張方針を整理したうえで、同一条件の見積を2〜3社から取り、初年度と3年間の総額、機能適合、サポート、契約上の責任範囲を比較することが重要です。

▼全体ガイドの記事
・整理券発行システム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。