事業拡大期の基幹システム発注、要件を複数部署から集める進め方

事業が拡大し社員数が100人を超えてくると、情シスが向き合う発注案件の性質そのものが変わります。30〜100人規模の頃は、ある部署の困りごとに対して、その部署の要望をそのまま整理すればRFPの土台になりました。ところが基幹システム、たとえば販売管理・在庫管理・会計連携をまとめて刷新するような案件になると、利用者は1部署に留まりません。営業部は受注入力のしやすさを求め、製造部は在庫の引き当て精度を求め、経理部は仕訳データとの連携精度を求める。それぞれの部署が異なる立場から異なる要件を持ち込むため、情シス担当者が1人でヒアリングして要件をまとめようとすると、部署間の要望の食い違いに気づかないまま、あるいは一方の要望だけを反映したRFPを作ってしまうリスクが生まれます。このガイドでは、複数部署が利用者になる基幹システムの発注において、部署横断のヒアリングをどう設計し、集まった要件をどうRFPへ落とし込むかを扱います。

この記事で分かること

事業拡大期に基幹システムを発注する際、複数部署からヒアリングを行い、要件を整理してRFPに落とし込むまでの進め方を解説します。RFPそのものの様式や最低限の記載項目については、すでにRFPは必要？中小企業の現実的な進め方で扱われているため、この記事ではその手前にある「複数部署からどう要件を集めるか」というヒアリング設計に焦点を当てます。集めた要望をチームとして優先順位づけし、部署間の調整を行う立ち位置の話は複数部署から同時に外注要望が来たときの情シスの調整役の果たし方に譲ります。

• なぜ基幹システムの発注では1部署のヒアリングだけでは要件が不十分になるのか
• ヒアリング対象部署をどのような観点で漏れなく洗い出すか
• 個別ヒアリングと合同ヒアリングをどう使い分けるか
• 部署ごとの要望を具体的な機能要件としてRFPに落とし込む方法
• 部署間で要望が対立したときの整理の手順
• ヒアリングに協力してくれた部署へのフィードバックの重要性

なぜ基幹システムの発注は1部署のヒアリングでは足りないのか

基幹システムという言葉が指す範囲は会社によって異なりますが、共通しているのは「複数部署の業務データが1つのシステムを介してつながっている」という性質です。販売管理システムを例にとると、営業部が入力した受注情報は、製造部の生産計画や在庫の引き当てに影響し、最終的には経理部の売上計上や請求処理にまでつながります。

この構造がある以上、1つの部署だけにヒアリングして要件を固めると、次のような事態が起こりやすくなります。

• 営業部の使いやすさを優先した入力項目の設計が、実は製造部が在庫を正確に引き当てるために必須の情報を欠いていた
• 経理部が求める仕訳の粒度が、営業部の入力習慣とかみ合わず、結局手作業での転記が残ってしまう
• 発注時点では存在を知られていなかった部署(海外拠点や新設された事業部など)が、後になって「自分たちも使う前提だったはずだ」と主張し、要件の手戻りが発生する

これらは、どの部署が悪いという話ではありません。基幹システムほど利用範囲が広いシステムの場合、要件を1部署の視点だけで固めることそのものが構造的にリスクを孕んでいます。事業拡大期は特に、部署の新設や役割分担の変化が頻繁に起きるため、「今、このシステムを使う可能性がある部署は本当にこれで全部か」という確認から始める必要があります。

ヒアリング対象部署の洗い出し方

部署横断ヒアリングを始める前に、まず「どの部署にヒアリングすべきか」を洗い出す作業が必要です。この洗い出しを漏らすと、後になって想定外の部署から要望が上がり、RFP自体を作り直す事態になりかねません。

洗い出しの観点として、次の3つを確認することをお勧めします。

1. 直接の利用部署: システムに実際にデータを入力・参照する部署(営業部、製造部、経理部など)
2. データの下流にいる部署: 直接システムを操作しないが、そこから出力されるデータや帳票を業務で使う部署(経営企画部が月次レポートに利用する、など)
3. 将来的に利用範囲が広がる可能性がある部署: 現時点では対象外だが、事業計画上、数年以内に利用者となる見込みがある部署(新設予定の事業部、海外拠点など)

この3つの観点をあわせて確認することで、「今すぐ声を上げている部署」だけでなく、「今は静かだが後で影響を受ける部署」まで含めて漏れなく洗い出せます。

この洗い出し作業自体を、情シス担当者だけで完結させず、事業責任者や各部署の管理職に確認しながら進めることをお勧めします。組織図の上では見えていない業務上のつながりが、実際の業務フローを追うことで見つかることは珍しくありません。

洗い出しの際、既存の類似システムやExcel運用がすでに存在している場合は、そのアクセス権限やファイルの共有先を確認することも有効な手がかりになります。誰がそのファイルを開く権限を持っているか、誰が定期的にデータを更新しているかを追うと、組織図には表れない実際の利用実態が見えてくることがあります。特に、事業拡大期は組織図の更新が業務の実態に追いついていないことも多く、肩書きや部署名だけで利用範囲を判断すると、実際の利用者を見落とすリスクがあります。

ヒアリングの進め方: 個別ヒアリングと合同ヒアリングの使い分け

対象部署が洗い出せたら、実際のヒアリングに入ります。ヒアリングの形式には大きく「個別ヒアリング」と「合同ヒアリング」の2種類があり、それぞれ向いている場面が異なります。

個別ヒアリングは、各部署の担当者に対して、他部署の目を気にせず本音の要望や現状の困りごとを引き出す場面に向いています。部署間の力関係がある場合(例えば製造部が営業部に遠慮してしまうなど)、合同の場ではっきり要望を言えない担当者もいるため、まずは個別に話を聞くことで、率直な情報を集めやすくなります。

合同ヒアリングは、部署間の要望の食い違いをその場で可視化し、認識をすり合わせる場面に向いています。個別ヒアリングだけで進めると、後になって「実は経理部と営業部で正反対の要望があった」と情シス担当者だけが気づく状態になりがちです。合同の場を設けることで、対立点を当事者同士に直接認識してもらえます。

実務上は、次のような順序で組み合わせることをお勧めします。

1. 個別ヒアリング(1巡目): 各部署の現状の業務フローと困りごとを聞き取る
2. 要件の仮整理: 情シス側で、部署ごとの要望を一覧化し、重複や矛盾がないか確認する
3. 合同ヒアリング: 矛盾や対立が見つかった論点を中心に、関係部署が同席する場で認識をすり合わせる
4. 個別ヒアリング(2巡目、必要に応じて): 合同ヒアリングで積み残した細部を、個別に詰める

すべての要望に対して合同ヒアリングを行う必要はありません。対立がない要望まで全員を集めて確認すると、参加者の時間を無駄に消費してしまいます。事前の仮整理で対立点を絞り込んでから合同ヒアリングを設定することが、限られた時間で効果的にすり合わせを進めるコツです。

合同ヒアリングを設定する際は、参加者の人選にも注意が必要です。各部署から現場の担当者だけを呼ぶと、業務の詳細には強いものの、その場で意思決定を伴う判断ができないことがあります。逆に管理職だけを呼ぶと、現場の具体的な業務実態が正確に伝わらないことがあります。可能であれば、各部署から現場担当者と、判断ができる管理職の両方に参加してもらう体制が理想的です。人数や日程の都合でそれが難しい場合は、少なくとも「その場で判断できる人」を各部署から1人は含めるようにしてください。

ヒアリング項目の設計: 「何が欲しいか」だけを聞かない

ヒアリングの質を左右する大きな要因が、質問の設計です。「新しいシステムに何を求めますか」という聞き方だけでは、各部署が思いつきで挙げた要望の羅列になりがちで、要望同士の優先度や背景が見えてきません。

次の4つの観点を組み合わせてヒアリングすることをお勧めします。

• 現状の業務フロー: 今、どのような手順でその業務を行っているか(現行システム、Excel、紙のいずれか)
• 困りごとの具体性: 「使いにくい」ではなく、「月次締めの際にA部署から受け取ったデータをこう加工する手間がかかっている」というように、具体的な作業として語ってもらう
• 困りごとの頻度と影響: その困りごとが週に何回発生し、どの程度の時間的・人的コストがかかっているか
• 理想の状態: 困りごとが解消された後、業務がどう変わってほしいか

特に重要なのが「困りごとの具体性」です。抽象的な要望(「もっと使いやすくしてほしい」)のままRFPに載せても、開発会社側は何を作ればよいか判断できません。具体的な業務シーンに落とし込んでヒアリングすることで、後のRFP作成時に、開発会社が理解しやすい要件として記述できます。

「最初は各部署に『欲しい機能は何ですか』とだけ聞いていました。返ってくる答えはバラバラで、優先順位のつけようがありませんでした。今は『その作業を今どうやっていて、何にどれだけ時間がかかっているか』を必ず聞くようにしています。困りごとの重さが数字で見えるようになり、部署間の要望を比較しやすくなりました」

ヒアリングの場では、担当者が事前に用意してきた要望だけでなく、雑談的な会話の中から出てくる情報にも注意を払う価値があります。「そういえば、こういうときにも困るんですよね」という形で、本題からやや外れた話の中に、実は重要な業務課題が隠れていることが少なくありません。ヒアリングの時間を厳格に区切りすぎず、多少の余白を持たせて進行することも、質の高い情報を引き出すための工夫の一つです。

部署間で要望が対立したときの整理の仕方

ヒアリングを進めると、部署間で要望が正面から対立する場面に必ず遭遇します。前述の例で言えば、営業部が求める入力の自由度と、経理部が求めるデータの正確性・統制は、しばしばトレードオフの関係になります。

このような対立を整理する際は、次の手順が有効です。

1. 対立を「好み」と「業務上の必然」に分類する: 単なる使い勝手の好みの違いなのか、それとも業務上どうしても譲れない制約(法令対応や監査要件など)なのかを見分ける
2. 業務上の必然が絡む要望は優先度を上げる: 好みの違いは調整の余地があるが、法令や社内規程に関わる要望は簡単に譲れない
3. 両立可能な設計上の折衷案を探す: システムの機能として、両部署の要望を矛盾なく満たせる設計がないか、開発会社の候補やベンダーに相談してみる
4. どうしても両立できない場合は、業務影響の大きさで判断する: 最終的にどちらを優先するかは、情シス単独で決めず、事業責任者や経営層に判断を仰ぐ

この整理のプロセスと、部署間の利害調整における情シスの立ち位置については、複数部署から同時に外注要望が来たときの情シスの調整役の果たし方で扱っている考え方がそのまま当てはまります。RFP作成の場面は、その調整役としての機能が最も試される場面の一つです。

ヒアリングを主導する担当者の決め方

複数部署にまたがるヒアリングを進める際、情シスチームが複数人体制であれば、誰がヒアリングを主導するかという役割分担も検討が必要です。全員でバラバラに各部署へヒアリングに向かうと、質問の粒度や聞き方が担当者ごとに異なり、後で要件を統合する際に情報の質にばらつきが出てしまいます。

実務上は、次のような分担の考え方が有効です。

1. ヒアリング全体を統括する担当者を1人決める: ヒアリング項目の設計、進捗管理、要件の統合作業を一貫して担う。複数人が個別に動く場合も、最終的な取りまとめ役を明確にしておく
2. 各部署へのヒアリングは、その部署と接点のあるメンバーが担当する: 普段からその部署とやり取りのあるメンバーが聞き手になったほうが、担当者側も本音を話しやすい
3. ヒアリング項目のテンプレートを事前に統一する: 誰が聞いても同じ粒度の情報が集まるよう、質問項目のフォーマットをあらかじめ用意しておく

この役割分担によって、複数人でヒアリングを分担しながらも、情報の質を一定水準に保つことができます。特に、ヒアリング項目のテンプレート化は、後の要件整理・RFP作成の効率にも直結するため、最初に時間をかけて設計しておく価値があります。

ヒアリング内容を文書化する際の粒度

ヒアリングで得られた情報をどの程度の粒度で文書化するかも、実務上悩ましいポイントです。詳細に書き起こしすぎると文書量が膨大になり、後で読み返す担当者の負担が増えます。逆に簡潔にまとめすぎると、後になって「具体的にどういう状況だったか」が分からなくなり、要件の背景を追跡できなくなります。

目安として、次の3層構造で記録することをお勧めします。

生の発言記録は、後になって「なぜこの要件が入ったのか」を振り返る際の一次資料として保存しておきます。この要件定義の土台となる記録が丁寧に残っていると、RFP提出後に開発会社から質問を受けた際にも、背景を説明する材料としてすぐに参照できます。逆に、いきなりRFP掲載用の簡潔な記述だけを残していると、後から「本当はこういう意図だった」という細かいニュアンスを説明できなくなるリスクがあります。

集めた要件をRFPへ落とし込む: 部署ごとの要望を「機能要件」に変換する

ヒアリングで集めた部署ごとの要望は、そのままの形でRFPに転記するのではなく、開発会社が理解・見積もりできる「機能要件」の形に変換する作業が必要です。この変換作業を怠ると、部署の生の声(「もっと使いやすく」「営業部にとって便利に」)がそのままRFPに並び、開発会社側が具体的な提案を作れない事態になります。

変換の際に整理しておきたい項目は次のとおりです。

特に「対立の有無」の欄は見落とされがちですが、この情報を開発会社に伝えておくことで、提案段階で技術的な折衷案が示される可能性が高まります。情シス側だけで対立を解消しようとせず、専門知識を持つ開発会社の視点を借りるという発想も有効です。RFPの基本的な様式や、削ってはいけない最低限の項目については、RFPは必要？中小企業の現実的な進め方を参照してください。

変換作業を行う際、部署から出た要望のすべてを機能要件として残すべきかどうかも判断が必要です。中には、業務上の課題ではなく、単なる好みや慣れの問題に起因する要望が混じっていることもあります。こうした要望は無理にRFPに盛り込まず、運用でカバーできないか、あるいは今回のシステム刷新の対象外とすべきかを、要望元の部署と丁寧にすり合わせたうえで判断してください。全ての要望を機能要件化しようとすると、RFP自体が肥大化し、開発会社側の見積もり精度もかえって下がってしまいます。

ヒアリング結果を要求元部署にフィードバックする

RFPを完成させて発注プロセスに進む前に、忘れずに行いたいのが、ヒアリングに協力してくれた各部署への結果のフィードバックです。ヒアリングした要望のうち、どれが要件として採用され、どれが今回は見送りになったのかを、各部署に説明する機会を設けます。

このフィードバックを省略すると、次のような不満につながりやすくなります。

• 時間を割いてヒアリングに協力したのに、その後の経過が分からず、要望がどう扱われたか不透明なまま
• 見送られた要望について、理由の説明がないまま「聞いてもらえなかった」という印象だけが残る
• 完成したシステムが稼働してから、初めて自分たちの要望が反映されていないことに気づき、不満が表面化する

要件が採用されなかった場合は、SOW（作業範囲記述書）の範囲外とした理由や、代替案(次期フェーズでの対応、運用でカバーする方法など)を添えて説明すると、納得を得やすくなります。この一手間が、次回以降のヒアリングへの協力度合いにも影響します。

フィードバックの方法は、必ずしも大がかりな報告会を開く必要はありません。ヒアリングに協力してくれた部署の担当者に、要件一覧の該当箇所を示しながら簡潔にメールやチャットで伝えるだけでも十分に機能します。重要なのは「協力してもらった結果がどうなったか、必ず何らかの形で本人に返す」という一貫した姿勢を保つことです。この積み重ねが、次に大きなシステム刷新を行う際にも、各部署が前向きにヒアリングへ協力してくれる土壌を作ります。

ヒアリングから発注までのスケジュール感

複数部署を巻き込むヒアリングは、1部署だけの場合に比べて明らかに時間がかかります。個別ヒアリングの日程調整、合同ヒアリングの参加者調整、要件整理とフィードバックのサイクルを含めると、部署数や対象範囲にもよりますが、数週間から数ヶ月単位のスケジュールを見込んでおく必要があります。

このスケジュール感を事前に経営層や関係部署と共有しておかないと、「なぜこんなに時間がかかっているのか」という不満につながります。ヒアリングのフェーズごとに大まかな期間の目安を示し、進捗を定期的に共有することをお勧めします。

• ヒアリング対象部署の洗い出しと個別ヒアリングの日程調整: おおむね1〜2週間
• 個別ヒアリングの実施と要件の仮整理: 部署数にもよるが2〜4週間
• 合同ヒアリングによるすり合わせ: 対立点の数に応じて1〜3回程度、各回1〜2週間の準備期間を挟む
• RFPへの落とし込みとフィードバック: 1〜2週間

このスケジュールはあくまで目安であり、対象部署の数や、繁忙期と重なるかどうかによって大きく前後します。特に、決算期や繁忙期に差し掛かっている部署は、ヒアリングの日程調整自体が難航しやすいため、事前に各部署の年間スケジュールを把握したうえで、ヒアリングの開始時期を計画することをお勧めします。無理に急いでヒアリングを進めると、担当者が十分に考えずに回答してしまい、後になって「実はこういう事情もあった」という要件の抜け漏れにつながりやすくなります。

複数の外注プロジェクトが同時進行している状況では、このヒアリング期間もチーム全体のリソース配分の一部として計画に組み込む必要があります。プロジェクト間の予算・人員配分の考え方は、100-300人規模の開発予算、複数プロジェクトを同時に抱えたときの配分で扱っています。

ヒアリングを通じて見えてくる「隠れた利用部署」

複数部署へのヒアリングを丁寧に進めていくと、当初は対象外だと思っていた部署が、実は基幹システムと深く関わっていたことに気づく場面が出てきます。例えば、営業部・製造部・経理部を中心にヒアリングを進めていたところ、実はカスタマーサポート部門が、営業部の入力した顧客情報を日常的に参照して問い合わせ対応を行っており、システムの仕様変更が自分たちの業務にも直結することが、ヒアリングの過程で初めて判明する、といったケースです。

このような「隠れた利用部署」を見逃さないためには、ヒアリングの終盤で次のような確認を挟むことが有効です。

• 「この情報は、他にどの部署が見たり使ったりしていますか」と、ヒアリング対象部署に逆質問する
• システムから出力される帳票やデータの配布先を、実際の配布リストやメール送信履歴から確認する
• 過去に類似システムの導入・変更があった際、影響を受けた部署の記録が残っていれば参照する

隠れた利用部署が発注の後半で見つかると、要件の手戻りや発注済み内容の再検討が発生し、プロジェクト全体のスケジュールに影響します。可能な限り、ヒアリングの初期段階でこうした発見的な問いかけを組み込んでおくことで、後工程でのやり直しを防げます。

まとめ: ヒアリングの質がRFPの質を決める

基幹システムの発注におけるRFP作成の巧拙は、実はRFPそのものの書き方よりも、その手前にあるヒアリングの設計で大きく決まります。どの部署にヒアリングすべきかを漏れなく洗い出し、個別と合同のヒアリングを使い分け、対立する要望を業務上の必然性に基づいて整理し、機能要件として言語化する。この一連のプロセスを丁寧に踏むことで、初めて開発会社が正確に見積もり・提案できるRFPが完成します。

事業拡大期の基幹システム発注は、1部署の要望を整理していた頃とは難易度が異なります。しかし、複数部署が関わるからこそ、システムが完成したときの業務改善のインパクトも大きくなります。ヒアリングにかける手間を惜しまないことが、結果的に発注後の手戻りやトラブルを減らし、投資対効果の高いシステム刷新につながります。

複数部署からのヒアリングは、一見すると回り道に見えるかもしれません。しかし、実際には発注後の要件の手戻りや、稼働後になって「一部の部署だけ使いにくい」という不満が噴出する事態を防ぐための、最も確実な予防策です。ヒアリングにかけた時間は、プロジェクトが進んでからの手戻りコストと比較すれば、決して大きな投資ではありません。事業拡大期のタイミングだからこそ、腰を据えて複数部署の声を集める価値があります。

基幹システムの発注は、社員数が100人を超えた会社にとって数年に一度の大きな投資判断です。だからこそ、目先のスケジュールの短縮よりも、複数部署の実情を正確に反映した要件を固めることを優先してください。丁寧なヒアリングの積み重ねが、稼働後に長く使われるシステムを生み出す土台になります。焦って要件を固めた末に稼働後の作り直しが発生すれば、結局は最初から丁寧にヒアリングするよりも多くの時間と費用を費やすことになります。