広告業のシステム導入にコンサルタントをいれてもあまり意味がない場合も｜業務ノウハウがないアドバイスは危険、ベンダーと直接話をするメリット

広告業のシステム導入では、業務を理解しないコンサルタントの助言が、現場に合わない要件や追加費用につながることがあります。ベンダーに業務を直接伝え、機能や費用、運用条件を確認する判断基準と、コンサルタントが有効なケースを紹介します。

1. 広告業のシステム導入でコンサルタントが必要とされる理由

広告業のシステム導入では、製品の機能を比較するだけでなく、現場の業務や導入目的を整理し、関係者間で認識をそろえる必要があります。社内に要件定義やプロジェクト管理を担う人材がいない場合、コンサルタントが第三者として進行を支援することで、検討を進めやすくなります。

ただし、コンサルタントに判断を任せきりにするのではなく、業務上の要望や優先順位は自社が決めることが重要です。IPAの「ユーザのための要件定義ガイド 第2版」でも、要件定義では業務部門のユーザーが主体的に関与する必要性が示されています。

1.1 要件定義や製品選定を第三者に任せられる

導入するシステムに求める機能や条件を整理する工程が、要件定義です。コンサルタントは、現状の業務や導入目的を聞き取り、必要な機能、対象業務、予算やスケジュールなどを要件としてまとめます。

要件が整理されていれば、複数の製品やベンダーを同じ条件で比較しやすくなります。自社だけでは比較基準を定めにくい場合も、第三者の支援を受けることで、各製品の機能だけでなく、業務上の要望にどこまで対応できるかを確認できます。

1.2 複数の部署や関係者の意見を整理できる

営業、制作、経理など複数の部署がシステムを利用する場合、部署ごとに必要な機能や優先したい課題が異なることがあります。コンサルタントは各部署へのヒアリングや会議の進行を通じて、意見の共通点や相違点を整理し、検討事項として可視化します。

たとえば、営業部門が案件の進捗管理を重視し、経理部門が請求や売上データの確認を重視する場合、それぞれの要望を並べて、導入目的に照らした優先順位を話し合えます。関係者間の合意形成を支援することは、要件の認識をそろえるうえで役立ちます。

1.3 導入計画やプロジェクト管理を支援してもらえる

システム導入では、要件の検討、製品選定、設定や開発、データ移行、テスト、利用者への説明など、複数の作業を順序立てて進めます。通常業務と並行してこれらを管理するのが難しい場合、コンサルタントがスケジュールや担当者、確認事項を整理し、進捗を管理する役割を担えます。

また、決定が必要な事項や作業の遅れを関係者に共有し、対応を促すことで、課題を把握しやすくなります。どの作業をどこまで支援するかは契約内容によって異なるため、導入計画の作成だけなのか、会議運営や進捗管理まで含むのかを事前に確認することが大切です。

2. コンサルタントを入れてもあまり意味がない場合

コンサルタントの支援が有効かどうかは、会社の規模だけでは決まりません。広告業の業務フローを理解し、現場の実態を要件に反映できるかが重要です。次のような場合は、支援を受けても導入判断に必要な情報が得られない可能性があります。

2.1 広告業特有の業務フローを理解していない

広告業では、案件ごとに広告主への見積・請求だけでなく、媒体社への発注や制作会社への外注が発生することがあります。媒体費、制作費、手数料などの扱いも案件によって異なります。

こうした取引の流れを理解していないコンサルタントが、一般的な受発注や請求の流れだけを前提に要件を整理すると、現場の業務とシステムの管理単位が合わないことがあります。打ち合わせで、見積から発注、売上・原価の管理、請求までを具体的に確認せず、機能の説明に終始する場合は注意が必要です。

2.2 現場の課題を聞かずに一般論で要件を決める

管理職へのヒアリングだけで要件を決め、営業、媒体、制作、経理など実際にシステムを使う担当者の業務を確認しない場合、日々の処理に必要な条件が抜けるおそれがあります。たとえば、案件の登録方法や原価の入力時期、請求の締め方が部署ごとに異なるのに、現場の手順を確かめずに共通ルールを設定するケースです。

要件定義では、システムの利用者となる企業と開発するベンダーが、業務やシステムに求める内容をすり合わせることが大切です。IPAも、業務部門から要求を聞き出す重要性を要件定義の解説で示しています。

2.3 システムの機能比較が中心で運用を見ていない

機能一覧や価格の比較に偏り、導入後に誰がどの情報を入力し、どのタイミングで確認するかまで整理しない場合、製品を選べても実際の運用を決められません。

たとえば、案件の売上や原価を管理できる機能があっても、入力担当者や更新のタイミング、確認する部署が決まっていなければ、各案件の情報を同じ基準で管理するのは難しくなります。提案書に機能の比較は詳しく書かれていても、現行業務との対応関係や導入後の手順が示されていない場合は、運用面の検討が十分か確認しましょう。

2.4 提案内容がベンダーの説明の言い換えにとどまる

ベンダーから聞いた機能や導入スケジュールを整理して伝えるだけでは、コンサルタントを介することで得られる独自の判断材料は限られます。自社の業務に照らした適合性や、提案された要件の優先順位、確認が必要な前提条件が示されているかを見極める必要があります。

たとえば、ベンダーの説明をそのまま紹介するのではなく、「この機能はどの業務を対象にしているか」「標準機能で対応できない条件は何か」といった点を自社の業務に沿って整理できているかが判断材料になります。質問への回答を取り次ぐだけで、提案内容の比較や検証がない場合は、支援範囲を改めて確認してください。

3. 業務ノウハウがないアドバイスが危険な理由

システム導入では、要件定義の内容が実際の業務や運用と合っているかを確認する必要があります。IPAの「ユーザのための要件定義ガイド」でも、利用部門やシステム部門、ベンダーなどが協調して要件を定めることが示されています。広告業の実務を十分に把握しないまま要件を決めると、導入後に現場の処理とシステムの想定がかみ合わず、追加作業や費用が発生する場合があります。

問題は、コンサルタントを利用すること自体ではありません。広告業の業務実態を確認せず、一般的な業務モデルだけで要件や運用方法を決めることが、導入後の不整合につながるおそれがあります。

3.1 見積や進行管理など実務に合わない要件が生まれる

広告案件では、提案・見積から受注、制作や媒体への発注、納品、請求まで、案件の進行に応じて処理が変わります。見積時点では金額が確定していない費用があったり、受注後に作業内容や発注先が変わったりすることもあります。

こうした実務上の条件を確認せずに要件を定めると、たとえば「見積書の金額が確定してから受注登録する」「案件の担当者だけが進捗を更新する」といった運用が前提になり、実際の承認手順や情報共有の流れと合わない場合があります。現場がシステムの手順に合わせるために、別の管理表やメールで補うことになれば、導入の目的である業務の一元管理を実現しにくくなります。

要件にする前に、誰が、どの時点で、何を確定・承認するのかを実際の業務フローに沿って確かめることが重要です。

3.2 媒体や案件ごとの違いがシステムに反映されない

同じ広告会社でも、媒体、制作物、取引先、契約条件によって、発注や進行管理、費用の計上方法が異なることがあります。たとえば、媒体費と制作費を分けて管理する案件と、複数の作業をまとめて受注する案件では、必要な入力項目や確認手順が同じとは限りません。

業務の違いを確認せずに共通の処理だけを要件にすると、案件ごとに必要な情報を登録できなかったり、実態に合わない区分で集計したりする可能性があります。その結果、担当者が案件名や費目の付け方を個別に工夫し、部署や担当者によってデータの扱いがばらつくことも考えられます。

すべての例外をシステム化する必要はありません。どの違いを標準機能で管理し、どの違いを個別の運用として扱うかを、現場と確認したうえで決めることが大切です。

3.3 導入後に手作業や二重入力が増える

現場で必要な情報や処理手順が要件から漏れていると、システムだけでは業務が完結しないことがあります。たとえば、案件の進行状況はシステムに登録していても、媒体への発注内容や社内確認の記録を別の表で管理する運用が残るケースです。

また、会計システムや顧客管理システムなど、既存システムとのデータ連携を考慮していない場合、同じ情報を複数のシステムに入力する必要が生じることがあります。入力項目や更新のタイミングが異なると、情報の転記漏れや更新遅れが起き、案件の進捗や金額を確認する際に複数の資料を照合しなければならなくなります。

こうした事態を防ぐには、機能の有無だけでなく、案件情報がどの工程で作成され、誰が更新し、次の業務へどう引き継がれるかまで確認して要件に反映する必要があります。

3.4 追加開発や運用コストが膨らむ

要件定義の段階で業務上の条件や例外を十分に整理できていないと、製品の標準機能では対応できない部分が導入後に見つかり、追加開発や設定変更が必要になる場合があります。改修費だけでなく、追加の打ち合わせ、テスト、操作説明、運用手順の見直しにも工数がかかることがあります。

一方、業務の違いをすべて個別開発で解決しようとすると、導入時の費用だけでなく、将来の改修や保守にも影響する可能性があります。標準機能で対応できる範囲、運用で補う範囲、個別開発が必要な範囲を分けて検討することが重要です。

IPAの非機能要求グレードの解説では、発注者と開発者の認識の行き違いを防ぐため、要求を整理して段階的に確認する考え方が紹介されています。広告業のシステム導入でも、費用や納期だけでなく、運用・保守、既存システムとの連携、変更時の対応を含めて、関係者間で認識を合わせておくと、導入後の想定外の負担を抑えやすくなります。

要件整理で見落としやすい点	導入後に起こり得ること
見積から受注、発注、請求までの実際の手順	現場の承認や進行管理に合わず、別の表やメールで補う
媒体・制作物・取引条件による案件ごとの差	必要な情報を管理できず、登録や集計の方法がばらつく
既存システムとのデータ連携や入力担当	二重入力や転記漏れが発生する
標準機能と個別開発の境界	追加開発や保守、運用変更に想定外の工数がかかる

4. ベンダーと直接話をするメリット

ベンダーと直接話すと、製品の説明だけでなく、自社の業務をどのようにシステムで扱えるかを具体的に確認できます。広告業では、案件の進行に応じて見積・発注・売上計上・請求などの処理が異なることがあります。実際の業務例を伝え、標準機能で対応できる範囲や運用上の条件を聞くことが大切です。

なお、ベンダーの説明だけで判断せず、回答内容や費用、対応範囲を資料に残して比較しましょう。要件を決める際には、利用部門とベンダーの認識をすり合わせることも重要です。IPAの要件定義に関する解説でも、ユーザー企業とベンダー企業が業務・システムの要件について認識を合わせる必要性が示されています。
https://dx.ipa.go.jp/youken-teigi

4.1 自社の業務に対するシステムの適合性を確認できる

自社の業務フローをベンダーに説明すれば、各工程をシステム上でどのように処理するのか確認できます。たとえば、広告案件の見積作成から受注、媒体社への発注、売上・原価の管理、請求までを一例として示し、どの画面や機能を使うのか尋ねます。

確認時は、通常の案件だけでなく、追加発注や金額変更、複数媒体を扱う案件など、現場で発生する例も伝えます。自社の業務例に沿った操作や処理の説明を受けることで、導入後の運用を具体的にイメージできます。

4.2 機能の制約や標準対応の範囲を把握できる

製品紹介資料に掲載された機能が、自社の希望する運用にそのまま使えるとは限りません。標準機能で対応できる範囲、設定変更で対応する範囲、追加開発が必要な範囲を分けて確認します。

確認する項目	ベンダーへの質問例
標準機能	見積から請求まで、標準機能で管理できる業務はどこまでですか。
設定変更	帳票や承認経路は、利用者側で設定を変更できますか。
制約	案件や取引先ごとに異なる処理で、対応できない条件はありますか。
外部連携	会計システムなどと連携する場合、必要なデータ形式や条件は何ですか。

回答を機能一覧や提案書に記載してもらうと、口頭説明との認識違いを防ぎやすくなります。デモでは、説明を聞くだけでなく、担当者が実際の業務例を使って操作を確認します。

4.3 要望への対応方法や追加費用を具体的に確認できる

自社の要望を伝えたうえで、対応方法ごとの費用や作業内容を確認できます。要望が標準機能で実現できるのか、設定変更や追加開発が必要なのかによって、導入費用や導入後の保守内容が変わるためです。

追加対応が必要な場合は、見積書や提案書で、対応範囲、費用、納期、検収条件、追加費用が発生する条件を確認します。また、要望を実現する別の運用方法があるかも尋ねると、開発以外の選択肢を比較できます。

4.4 導入後のサポートや保守の条件を直接聞ける

導入後に問い合わせできる窓口や対応時間、障害時の連絡方法、操作方法に関する支援の範囲を確認します。システムの利用開始後、設定変更や担当者の交代があった場合に、どのような支援を受けられるかも聞いておきましょう。

保守契約については、月額費用に含まれるサービスと、別料金になる作業を分けて確認します。導入時の支援と稼働後のサポートの範囲を文書で整理しておくことで、必要な支援を受けられる条件を社内で共有できます。

5. 広告業のシステム導入を成功させる進め方

5.1 現場の業務フローと課題を洗い出す

最初に、システムを使う部署や担当者にヒアリングし、案件の相談から受注、制作・媒体手配、納品、請求までの流れを整理します。広告会社によって担当範囲や業務手順は異なるため、自社の実態に沿って確認することが大切です。

各工程で「誰が」「何を受け取り」「どの情報を登録し」「次に誰へ引き渡すか」を書き出します。見積の承認、外注費の確認、案件情報の変更など、通常とは異なる処理も確認しておくと、導入後に必要な機能や運用ルールを検討しやすくなります。

あわせて、転記や二重入力、確認待ち、情報の探しにくさなど、現場が困っている点を具体的に記録します。現状の業務フローと課題を可視化する方法は、IPAの要件定義に関する解説も参考になります。

5.2 必須要件と改善したい要件を分ける

洗い出した課題をもとに、システムに求める要件を「導入時に欠かせないもの」と「実現できれば業務改善につながるもの」に分けます。すべての要望を同じ優先度で扱うと、要件が膨らみ、選定や導入の判断が難しくなるためです。

区分	整理の基準	広告業の例
必須要件	満たせない場合、主要な業務が続けられない、または運用上の支障が大きいもの	案件情報を一元管理する、見積から請求まで必要な情報を引き継ぐ
改善要件	導入後の効果や実現方法、費用を確認したうえで優先度を判断するもの	帳票作成を効率化する、案件状況を一覧で把握しやすくする

要件には、必要とする理由や利用する担当者も添えます。「便利にしたい」といった表現だけでなく、「どの作業に何分かかっているか」「どの情報を誰が確認するか」まで整理すると、対応の要否を判断しやすくなります。

5.3 ベンダーに実際の業務を説明して提案を受ける

要件を整理したら、ベンダーには機能一覧だけでなく、実際の業務の流れや例外処理も伝えます。例えば、案件の受注後に制作や媒体手配が並行する場合、担当者間でどの情報を共有し、どの時点で進捗を更新するのかを説明します。

そのうえで、各要件が標準機能で対応できるのか、運用の変更が必要なのか、追加開発が必要なのかを分けて回答してもらいます。提案内容は、要件ごとに対応方法と前提条件が分かる形で記録し、社内で確認できるようにします。

自社の業務に当てはめて説明を受けることで、機能の有無だけでは分かりにくい運用上の条件や、導入前に決めておくべき事項を把握できます。

5.4 現場担当者を交えてデモや検証を行う

デモでは、担当者が日常的に行う業務を題材にして操作を確認します。例えば、案件を登録し、見積や発注に必要な情報を入力し、進捗を更新して、請求に使う情報を確認するまでの流れを試します。画面を見るだけでなく、実際の業務手順に沿って確認することがポイントです。

検証では、必須要件を満たすかに加え、入力項目、権限設定、帳票出力、既存システムとのデータ連携など、自社で必要な条件を確認します。テスト用データを使い、通常の案件だけでなく、修正や差し戻しなどの処理も試すと、運用時の確認事項を見つけやすくなります。

確認結果は、要件ごとに「対応できた」「条件付きで対応できた」「未確認」に分けて記録します。現場担当者が操作した結果を導入判断に反映し、未確認の項目は契約や導入計画を確定する前に確認します。

6. コンサルタントを活用したほうがよいケース

コンサルタントの活用が有効かどうかは、会社の規模だけでなく、社内の人員や導入範囲、必要な検証の内容によって変わります。自社だけでは進めにくい作業を特定し、その部分を補う目的で依頼すると、支援範囲や費用の妥当性を判断しやすくなります。

6.1 社内にシステム導入を進める人材がいない

システム導入では、現場への確認、課題の整理、社内の意思決定、ベンダーとの調整など、通常業務と並行して進める作業が発生します。担当者が決まっていない場合や、担当者にプロジェクト管理の経験がない場合は、コンサルタントに進行管理や会議の運営を依頼する方法があります。

たとえば、検討事項や決定事項を記録し、担当者と期限を整理して、未決事項の対応状況を確認してもらうことができます。ただし、業務上の優先順位や要件を決めるのは自社です。現場の担当者と判断権限を持つ人を社内で定めたうえで、コンサルタントには進行を支援してもらうことが重要です。

6.2 複数の拠点や部門をまたぐ大規模な導入を行う

複数の営業所や部門が対象となる導入では、案件の登録方法や承認手順、管理する情報が拠点ごとに異なることがあります。各部門の意見をそのまま要件にすると、システムの設定や運用が複雑になり、導入後の管理にも影響する可能性があります。

このような場合、コンサルタントに部門間の調整や論点の整理を依頼できます。各拠点の運用を比較し、全社で統一する業務と、個別運用を残す業務を分けて検討する支援が考えられます。対象部門が多いほど、誰が最終判断を行うのかを導入前に決めておくことが大切です。

6.3 第三者による要件や見積の確認が必要である

社内にシステム導入の経験者が少なく、提案された要件や見積の妥当性を判断しにくい場合は、第三者に確認を依頼する選択肢があります。たとえば、業務上必要な要件が提案に含まれているか、追加開発として提示された内容が標準機能では対応できないものか、費用の内訳に不明点がないかを確認してもらいます。

確認を依頼するときは、対象資料と確認範囲を明確にします。また、コンサルタントが特定のベンダーから紹介料や販売手数料を受け取る契約になっていないかなど、利害関係も確認が必要です。第三者の見解だけで決定せず、ベンダーにも判断の根拠や対応条件を確認することで、社内で比較・検討しやすくなります。

7. コンサルタント選びで確認したいポイント

7.1 広告業の業務やシステム導入の実績がある

広告業の業務を理解しているかは、会社案内の実績数だけでなく、担当者が過去のプロジェクトで何を担ったかまで確認します。広告会社や広告制作会社での導入支援経験があるか、要件整理・製品選定・導入後の定着支援のどこまで関わったかを尋ねましょう。

実績を確認するときは、自社と近い事業規模や組織体制の事例があるかも見ます。導入企業名を開示できない場合でも、企業規模、対象業務、導入時の課題、支援内容を説明できるかで、経験の具体性を判断できます。広告業での実績があることだけで決めず、自社が解決したい課題に近い経験があるかを確かめることが大切です。

7.2 現場へのヒアリングを重視している

初回の打ち合わせで製品や一般的な導入手順の説明に終始せず、現場の担当者から現在の業務や困りごとを聞く姿勢があるかを確認します。担当者だけでなく、営業、制作、経理など、システムを使う部門や関連する部門の意見をどう集め、整理するのかも質問しましょう。

ヒアリング後に、聞き取った内容を業務フローや課題一覧などにまとめ、認識に誤りがないか確認する進め方を示せるかも判断材料です。IPAの「ユーザのための要件定義ガイド」でも、業務部門の利用者が要件定義に主体的に関与する重要性が示されています。コンサルタントに任せきりにするのではなく、現場の意見を要件に反映する方法を具体的に説明できるかを見極めましょう。

7.3 ベンダーとの利害関係や報酬体系が明確である

コンサルタントが特定のベンダーから紹介料や販売手数料を受け取る場合は、その有無や金額の決まり方を事前に確認します。特定の製品を推奨する理由を説明できるか、比較対象となる製品や選定基準を明らかにできるかも確認しましょう。利害関係があることだけで不適切とは限りませんが、選定への影響を依頼側が把握できる状態にしておく必要があります。

報酬については、固定報酬、時間単価、成果報酬などの算定方法に加え、支援範囲、納品物、追加費用が発生する条件を契約前に確かめます。どの立場から助言し、何を成果物として提出し、どの条件で費用が変わるのかを書面で確認しておくと、契約後の認識違いを防ぎやすくなります。

8. まとめ

広告業のシステム導入では、コンサルタントを入れること自体ではなく、広告業の業務フローを踏まえた支援を受けられるかが重要です。現場の課題を整理し、必須要件と改善要件を分けたうえで、ベンダーに業務を説明し、機能や制約、追加費用、導入後のサポートを直接確認しましょう。社内に推進人材がいない場合や、複数部門にまたがる導入では、実績や利害関係を確認してコンサルタントを活用する方法もあります。広告業の業務管理でお困りの方は、サイネット株式会社へご相談ください。