業務システム開発の進め方：現場ヒアリングから運用定着まで

業務システム開発の進め方で最も大切なのは、現場で実際に行われている仕事の流れと、その中に紛れている例外処理を正確につかむことです。業務システムは、使う人が限られ、毎日同じ画面を何度も操作するという性質を持っています。だからこそ、一つの入力項目の多さや、一つの例外に対応していないことが、そのまま現場の負担や「使われないシステム」につながります。

この記事は、受発注、案件管理、作業報告、申請・承認といった社内業務をシステム化しようとしている企業の担当者、とくに初めて業務システムの開発を外部に発注する方に向けて書いています。現場ヒアリングの進め方、例外業務の扱い方、要件の絞り方、導入方式の選び方、段階的な導入、運用定着までの流れを、発注側が何をすべきかという視点で説明します。

先に要点をまとめると、業務システム開発は「目的を決める」「現場の実態を集める」「やることとやらないことを決める」「小さく導入して直す」「定着を見届ける」の五つの段階で進めます。開発そのものより、その前後にある現場との対話と、導入後の手直しに時間を割くことが、結果的に使われるシステムへの近道です。

業務システム開発が難しくなる理由

業務システムは、ECサイトや会員向けアプリのように不特定の利用者を想定するものとは違い、特定の業務と特定の担当者のために作られます。この性質から、次のような難しさが生まれます。

• 業務の実態が文書になっていない：マニュアルがあっても実際の手順とずれていたり、担当者の経験や判断に頼った部分が多かったりします。
• 例外が多い：通常の流れは全体の一部で、急ぎの対応、取引先ごとの特別ルール、差し戻し、訂正などが日常的に発生します。
• 関係者の立場が違う：経営層は管理や見える化を、現場は入力の手間の少なさを、管理部門は正確さや統制を求め、要望がぶつかります。
• 現在のやり方への慣れ：Excelや紙での運用が長く続いていると、多少不便でも慣れたやり方を変えることへの抵抗が生まれます。

これらは技術の問題ではなく、業務とその周りの人の問題です。業務システム開発の進め方は、この人と業務の問題に正面から向き合うことを前提に組み立てる必要があります。

進め方の全体像

業務システム開発の流れを、発注側の主な仕事とあわせて整理します。

各段階の終わりには、次の段階に進んでよいかを確認する場を設けます。たとえば要件の決定が終わった時点で、責任者と現場の代表者が要件一覧を確認して合意してから設計に進む、という区切りを設けると、後になって前提が覆る事態を減らせます。

この表のうち、発注側の仕事が特に重いのは、現状の把握と要件の決定、受入・導入、定着・改善です。開発会社は業務の専門家ではないため、業務の実態と判断のルールは発注側が持ち込む必要があります。

発注側の体制と役割分担を先に決める

業務システム開発では、開発会社を決める前に、発注側の体制を決めておくことが欠かせません。体制が曖昧なまま始めると、質問への回答が遅れ、判断が後回しになり、結果として期間も費用も膨らみます。最低限、次の三つの役割を誰が担うかを決めておきます。

• 責任者：システム化の目的と予算に責任を持ち、部署をまたぐ判断や優先順位の最終決定を行う人。経営層や部門長が担うことが多くなります。
• 窓口担当：開発会社との日常的なやり取り、質問の取りまとめ、社内の関係者への確認を行う人。業務の全体像を理解していることが望ましい役割です。
• 業務の代表者：実際にシステムを使う現場の担当者の中から、ヒアリングや画面の確認、受入テストに参加する人。部署ごとに一人ずつ選ぶと、現場の声を拾いやすくなります。

小さな会社では一人が複数の役割を兼ねることもありますが、その場合も「誰が最終的に決めるのか」だけは明確にしておきます。決める人が不在のまま会議を重ねると、意見が出そろっても結論が出ず、開発会社は作業を進められません。また、窓口担当が本業と兼務する場合は、週に何時間をこのプロジェクトに使えるかを事前に上司と合意しておくと、途中で手が回らなくなる事態を防げます。定例の打ち合わせの頻度や、課題を記録して追いかける方法も、この段階で開発会社とすり合わせておきます。

現場ヒアリングの進め方

現場ヒアリングは、業務システム開発の質を最も大きく左右する工程です。ヒアリングで得た情報が浅いと、あとで「こんなケースもある」という指摘が次々と出て、仕様変更と手戻りが続きます。

ヒアリングの前に準備すること

1. 対象業務の範囲を決める：どこから始まりどこで終わる業務を対象にするか（例：「見積もり依頼の受付から受注登録まで」）を決めます。
2. 関係者を洗い出す：その業務に関わる担当者、承認者、データを受け取る後工程の担当者を一覧にします。
3. 実物の資料を集める：使っているExcelファイル、紙の帳票、メールのテンプレート、システムの画面のスクリーンショットを集めます。
4. 質問の枠組みを用意する：「何をきっかけに」「誰が」「何を見て」「何を判断して」「何を作って」「誰に渡すか」を順に聞けるように準備します。

ヒアリングで聞くこと

ヒアリングでは「どう変えたいか」より先に「いまどうしているか」を聞きます。要望から聞き始めると、現在の不満に引きずられ、業務全体の流れがつかめなくなります。具体的には次の点を確認します。

• 一日、一週間、一か月の中で、その業務がいつ、どのくらいの頻度で発生するか
• 作業のきっかけになる情報（メール、電話、帳票）と、作業の結果として作るもの
• 判断が入る箇所と、その判断の基準（誰が決めているか、基準は文書化されているか）
• うまくいかないとき、急ぎのとき、間違いがあったときに何をしているか
• 業務の中で最も時間がかかっている作業と、最もミスが起きやすい作業

可能であれば、実際の作業の様子を横で見せてもらうことをおすすめします。口頭の説明では省略されがちな「別のファイルを開いて確認する」「担当者に一声かける」といった動きが見えてきます。

ヒアリングの記録は、その日のうちに要点をまとめ、話を聞いた担当者に確認してもらいます。聞き手の解釈が混じったまま次の工程に進むと、後で「そういう意味ではなかった」というずれが生じます。また、同じ業務でも担当者によってやり方が違うことがよくあります。その場合はどちらが正しいかをその場で決めず、違いがあること自体を記録し、後の要件決定の段階で標準のやり方を決めます。

ヒアリングの結果は業務フロー図に整理すると、関係者の間で認識をそろえやすくなります。図の書き方は業務フロー図の書き方：システム化の前に現状を可視化する手順で詳しく説明しています。

例外業務の扱い方

業務システムの要件で最も扱いに困るのが例外業務です。例外を一つずつ全部システムに入れると、画面と設定が複雑になり、開発費用も保守の負担も増えます。かといって例外に対応しないと、現場はシステムの外で処理を続け、二重管理が生まれます。

例外業務は、次の観点で分類してから扱いを決めます。

ここで大切なのは、「システムで対応しない」と決めた例外にも、手順と記録の残し方を決めておくことです。何も決めないと、例外が起きるたびに担当者が独自の方法で処理し、属人化が進みます。

要件を絞り込む判断基準

ヒアリングを重ねると、要望は増え続けます。すべてに応えようとすると、開発期間が延び、最初のリリースまでに業務の状況が変わってしまうこともあります。要件は次の基準で絞り込みます。

• 目的に直結するか：最初に決めた目的（例：「受注登録の転記作業をなくす」）に直接効くかどうか
• 頻度と影響：毎日発生するか、ミスが起きたときの影響は大きいか
• 代替手段があるか：システム外の手順や既存のツールで当面しのげるか
• 後から追加しやすいか：最初に作らなくても、後で追加するときに大きな作り直しが必要にならないか

この基準で要件を「最初のリリースで必須」「次の段階で追加」「当面は対応しない」に振り分けます。現状をそのままシステムに写すのではなく、あるべき姿との差分から要件を決める考え方は、As-Is/To-Be分析で業務システムの要件を固める進め方と注意点で詳しく扱っています。決まった要件は、要件定義書の書き方：発注側が埋めるべき項目とテンプレートの使い方を参考に文書にまとめておくと、開発会社との認識合わせがしやすくなります。

導入方式の選び方：パッケージ・ノーコード・個別開発

業務システムを用意する方法は一つではありません。業務の特性と求める柔軟性に合わせて選びます。

共通業務まで個別開発する必要はありません。会計や勤怠のように業界で共通化された業務は、SaaSを使う方が早く確実です。個別開発が意味を持つのは、自社の競争力に関わる独自の業務の流れや、複数のシステムをまたぐデータの流れを一つにまとめたい場合です。

段階的な導入と受入テスト

業務システムは、全部門・全機能を一斉に切り替えるより、段階的に導入する方が失敗を小さくできます。

1. 試験導入する部署や担当者を決める：協力的で、業務の量がほどほどの部署を選びます。
2. 試験期間中は旧手順と並行する：新システムの結果と旧手順の結果を突き合わせ、ずれがないかを確認します。
3. 問題点を集めて直す：入力の手間、画面の分かりにくさ、対応していない例外を集め、優先順位を付けて修正します。
4. 展開の範囲を広げる：試験導入で固めた運用ルールと操作説明を使い、次の部署に展開します。
5. 旧手順を停止する：全員が新システムで業務を回せることを確認したうえで、旧手順を明確に終わらせます。

受入テストでは、開発会社が用意したテストだけでなく、発注側が業務のシナリオに沿ったテストケースを用意することが重要です。普段の流れだけでなく、例外業務の代表的なケースも含めます。受入テストの進め方は受入テストの進め方：発注側が用意するテストケースと検収の基準で解説しています。

架空の例：工事会社の作業報告システム

現場作業員が紙の作業報告書を書き、事務所で事務担当がExcelに転記している工事会社を考えます。まず一つの現場チームで、スマートフォンから作業報告を入力する仕組みを試験導入しました。試験期間中に「電波の届かない現場がある」「写真を後からまとめて添付したい」「同じ作業を複数日に分けて報告したい」といった実態が分かり、下書き保存と後からの写真添付を追加したうえで、他のチームに展開しました。最初から全チームに展開していたら、これらの問題がいっせいに噴き出し、紙に戻ってしまっていたかもしれません。

運用定着までを計画に入れる

システムが完成しても、使われなければ効果は出ません。業務システム開発の計画には、導入後の定着の期間を最初から含めておきます。

• 操作説明は、業務の流れに沿った形で用意する（画面の説明ではなく「この作業をするときはこの画面」という形）
• 導入直後の質問を受ける窓口と担当者を決める
• 利用状況（ログイン、入力件数、旧手順の残り具合）を定期的に確認する
• 改善要望を集める仕組みを用意し、優先順位を付けて対応する
• 旧手順の停止日を決め、二重運用を長引かせない

現場で使われない原因とその対策は、業務システムが現場で使われない原因と、定着させる導入の工夫で詳しく扱っています。

よくある失敗とその避け方

• 管理者の要望だけで要件を決める：管理や集計の機能ばかりが充実し、入力する現場の負担が増えて使われなくなります。現場担当者をヒアリングと試験導入に必ず巻き込みます。
• 現状の業務をそのままシステムに写す：紙やExcel時代の非効率な手順まで再現してしまい、システム化の効果が出ません。システム化をきっかけに、不要な承認や転記をなくせないかを検討します。
• 例外を後回しにしすぎる：「例外は後で」と言い続けた結果、リリース後に現場がシステム外で処理を続け、二重管理になります。最低限、例外の記録と訂正の手段は用意します。
• 発注側の担当者が業務を把握していない：窓口の担当者が現場の業務に詳しくないと、開発会社からの質問に答えられず、判断が遅れます。業務を知る担当者を窓口か、少なくとも判断役に入れます。
• 導入後の改善予算を確保していない：リリース直後は改善要望が多く出ます。その対応の予算と体制を最初から計画に含めておきます。

発注前のチェックリスト

• システム化の目的を一文で説明できる
• 対象業務の範囲（始まりと終わり）を決めている
• 現場担当者がヒアリングや試験導入に協力できる体制がある
• 現在使っている帳票、Excel、画面の実物を集めている
• 主な例外業務を洗い出し、扱いの方針を考えている
• 最初のリリースで必須の機能と、後回しにする機能を分けている
• 試験導入する部署と期間の候補がある
• 導入後の問い合わせ窓口と改善の予算を考えている

よくある質問

Q. 現場が忙しく、ヒアリングの時間がとれません。

一人あたり一時間程度のヒアリングを数回に分ける、作業の様子を見せてもらう時間に置き換える、といった方法で負担を抑えられます。ヒアリングを省略すると、リリース後に現場から指摘が集中し、結局はより多くの時間を使うことになります。現場の協力が得られるよう、目的と現場にとっての利点を先に説明しておくことが大切です。

Q. 要件定義は開発会社に任せてもよいですか？

要件を整理し文書にまとめる作業は、開発会社に支援してもらえます。ただし、業務のルールや優先順位の判断は発注側にしかできません。判断を伴う部分は発注側が持ち、開発会社には整理と技術的な選択肢の提示を求める、という役割分担が現実的です。

Q. どのくらいの期間を見込めばよいですか？

対象業務の範囲、例外の多さ、他システムとの連携の有無によって大きく変わります。期間を見積もる際は、開発期間だけでなく、ヒアリングと要件決定、受入テスト、試験導入、定着までを含めて考えてください。

Q. 小さく始めると、後で作り直しになりませんか？

最初のリリースで扱わない機能も、データの持ち方や画面の構成を考えるときに視野に入れておけば、大きな作り直しは避けられます。後から追加する予定の機能を要件一覧に残しておき、設計の段階で開発会社と共有しておくことが大切です。

Otsumuに相談できること

対象業務が一つの部署で完結していて、業務の流れが比較的単純な場合は、ノーコードツールやSaaSを使って社内で進められることが多くあります。この記事のチェックリストを埋め、現場と一緒に試しながら整えていくところまでは、自社で取り組んでみてください。

外部の力を借りた方がよいのは、複数の部署やシステムにまたがる業務を一つの流れにまとめたい、例外が多く要件の整理が進まない、社内に開発会社とやり取りできる担当者がいない、といった状況です。業務の実態とシステムの両方を見ながら、何を作り何を作らないかを決める役割が必要になります。

Otsumuは、現場ヒアリングと業務の整理から一緒に行い、目的から逆算して必要な機能に絞ったうえで、小さく導入して直しながら定着まで伴走します。AIを活用した開発で少人数・短期間に試作し、現場に早い段階で触ってもらいながら進めることができます。業務システムの開発については業務システム開発のページをご覧ください。費用は範囲に応じて個別にお見積もりします。

何をシステム化すべきか決めきれていない段階でもご相談いただけます。30分の無料相談で、現在の業務の状況をお聞かせください。

この記事について

Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。

執筆：Otsumu株式会社 ／ 編集日 2026.10.01