部署の担当者が個別に開発会社へ要望を出してしまう状態を防ぐ方法

社員が10人を超え、営業・製造・管理部門といった部署が分かれ始めると、開発会社とのやり取りに新しい問題が持ち上がります。それは、各部署の担当者が「ちょっとこの機能を直してほしい」「この画面にこの項目を追加してほしい」と、それぞれ個別に開発会社へ連絡してしまう状態です。10人未満の頃は要望を出す人がそもそも社長ひとりに限られていたため起きなかったこの問題は、部署が複数化した瞬間から急に表面化します。

開発会社にとっては、複数の窓口から矛盾する指示や優先順位の異なる要望が飛んでくると、どれを優先すべきか判断がつかなくなります。結果として、本来もっと重要な改修が後回しにされたり、逆に緊急性の低い要望が先に着手されて追加費用だけが積み上がったりする事態が起こります。社内側でも、「誰が何を頼んだのか」を誰も把握していない状態が続き、予算やスケジュールの管理が破綻していきます。

このガイドでは、なぜこの混乱が起きるのか、放置した場合にどんなリスクがあるのか、そして専任の窓口担当者をまだ置けない段階でも実行できる、要望を収拾するための社内ルールの作り方を解説します。

なぜ部署が増えると要望が分散するのか

要望の分散は、多くの場合、悪意や不注意から起きるものではありません。むしろ、各部署の担当者が「早く解決したい」という真面目な動機から、開発会社に直接連絡してしまうことのほうが多いのです。この背景には、10〜30人規模特有の事情があります。

• 開発会社の連絡先を複数の従業員が知っている: 少人数の会社ではメールアドレスや電話番号が共有されやすく、誰でも直接連絡できてしまう
• 「誰に相談すればいいか」が明確に決まっていない: 情シス担当という専任の役割がまだ存在しないため、各部署が自己判断で動いてしまう
• 過去に成功体験がある: 以前、担当者が直接開発会社に連絡して素早く対応してもらえた経験があると、その方法が「正しいやり方」として定着してしまう
• 部署間の情報共有の仕組みがない: 他部署がどんな要望を出しているか把握できないため、同じような要望が別々のルートで重複して伝わることもある

これらの要因は、会社が急成長している段階では特に強く働きます。部署が増えるスピードに、社内のルール整備が追いついていない状態と言い換えることもできます。

要望が分散すると起きる4つの問題

要望の分散を放置すると、次のような問題が段階的に積み重なっていきます。

特に見落とされがちなのが「予算の見えない超過」です。各部署が個別に「ちょっとした修正」を依頼していると、1件あたりの金額は小さくても、月末に開発会社から届く請求書の合計額が想定を大きく超えていることがあります。これは、経理が請求内容を検証する体制が整っていない場合、さらに発覚が遅れます。請求内容の確認体制については開発会社からの請求内容を経理と一緒に確認する体制の作り方で詳しく扱っています。

窓口一本化が「まだ」できない段階でも打てる手

理想を言えば、開発会社との窓口を1つに統一し、すべての要望をそこに集約するのが最も確実な解決策です。しかし、専任の情シス担当者を置く余裕がない10〜30人規模の会社では、窓口一本化をすぐに実現するのが難しい場合もあります。このガイドでは、窓口一本化が完成する前の段階でも実行できる、要望の収拾方法を段階的に紹介します。

ステップ1: 「開発会社に直接連絡しない」というルールを周知する

最初の一歩は、技術的な仕組みではなく、社内への周知です。「システムに関する要望は、まず窓口担当者(または一次受け)に伝える。開発会社に直接連絡しない」という原則を、経営者から全部署に向けて明確に伝えます。この周知がないまま「なんとなく直接連絡しないでほしい」と個別にお願いするだけでは、ルールとして定着しません。

ルールを個別の担当者にお願いする形で広めようとすると、伝わる範囲にムラが生まれます。経営者から全社への周知という形を取ることで、初めて「会社としてのルール」だという認識が共有されます。

ステップ2: 要望を受け付ける「入り口」を1つ用意する

窓口となる担当者が正式に決まっていなくても、要望を書き込む共有シートやフォームなど、「要望の入り口」を1つ用意することはすぐに始められます。次のような項目を記録できれば十分です。

この入り口があることで、各部署は「勝手に開発会社に連絡する」以外の選択肢を持てるようになります。重要なのは、入り口を用意しただけで満足せず、実際にそこに要望が集まる状態を作ることです。

ステップ3: 定期的に要望を棚卸しし、優先順位をつけてから開発会社に伝える

集まった要望は、都度バラバラに開発会社へ転送するのではなく、一定の周期(週1回や月1回など)でまとめて棚卸しし、優先順位をつけたうえで開発会社に伝えます。この棚卸しの頻度は、開発会社との定例の頻度と揃えておくと運用がシンプルになります。定例を月1回にしている場合の進め方については小規模開発案件で開発会社との定例を月1回にする際の進め方で扱っています。

優先順位をつける際の簡易的な基準

複数部署からの要望を並べたとき、何を優先すべきか判断に迷うことがあります。厳密な優先順位付けの手法を導入する余裕がない段階では、次の3つの軸で簡易的に判断するだけでも十分機能します。

1. 業務が止まっているか: 現在進行形で業務に支障が出ている要望は最優先で扱う
2. 影響を受ける人数: 特定の1人だけの要望より、複数部署・多くの従業員に影響する要望を優先する
3. 費用対効果の見込み: 小さな修正で大きな業務改善が見込めるものを、優先度を上げて検討する

この基準は、あくまで社内での一次的な整理に使うものであり、最終的な優先順位の決定には経営者や意思決定者の判断を仰ぐ場面も出てきます。特に、部署間で優先順位の意見が対立する場合は、担当者レベルでの調整に固執せず、早めに上位の判断者にエスカレーションすることをお勧めします。

「緊急」を名乗る要望への対処

要望を一元化しようとすると、必ず出てくるのが「これは緊急だから、今すぐ開発会社に伝えてほしい」という声です。緊急度の高い要望を棚卸しのサイクルまで待たせるのは現実的ではありませんが、一方で「緊急」を無条件に信じてルールを毎回崩してしまうと、一元化の仕組みそのものが形骸化します。

このジレンマを解消するには、あらかじめ「何をもって緊急とみなすか」の基準を決めておくことが有効です。

• 業務システムが実際に停止・エラーで使用不能になっている場合は、緊急扱いとして即座に窓口担当者を経由して開発会社に連絡する
• 「早く直してほしい」という感覚的な緊急性のみで、業務に実害が出ていない場合は、通常の棚卸しサイクルで扱う
• 緊急扱いにするかどうか迷う場合は、窓口担当者が一次判断し、必要であれば経営者に確認する

この基準があることで、窓口担当者は「本当に緊急かどうか」を毎回悩まずに判断でき、各部署も「何が緊急として扱われるか」を事前に理解した上で要望を出せるようになります。

一元化の仕組みが機能しない典型的な失敗パターン

要望の一元化を試みても、うまく機能しないケースがあります。よくある失敗パターンを整理しておきます。

失敗パターン1: ルールを伝えただけで、入り口の仕組みを用意していない

「開発会社に直接連絡しないでほしい」と伝えるだけで、代わりにどこに要望を出せばよいかを示さないケースです。行き場を失った要望は、結局これまで通り個別に開発会社へ流れていくか、あるいは要望自体が出されずに放置されてしまいます。

失敗パターン2: 窓口担当者が要望を止めるだけで、進捗を戻さない

各部署から集めた要望を窓口担当者が受け止めたあと、その後どうなったかを部署側にフィードバックしないケースです。要望を出した部署は「言っても反応がない」と感じ、次第に窓口を経由せず直接開発会社に連絡する方法に逆戻りしてしまいます。要望を受け付けた後は、対応状況(検討中・対応予定・見送りなど)を定期的に部署側へ共有することが、ルールの定着に欠かせません。

失敗パターン3: 経営者自身がルールを守らない

現場にはルールを守るよう求めながら、経営者自身が「これは急ぎだから」と開発会社に直接連絡してしまうケースです。この状態が続くと、現場も「結局ルールは形だけだ」と受け止め、一元化の取り組み全体が形骸化します。ルールは経営者を含む全員が同じ基準で守ることで、初めて機能します。

エスカレーションが必要な要望の見極め方

窓口担当者が要望を一元的に受け止めるようになると、今度は「自分の判断だけでは決められない要望」に直面する場面が増えます。金額の大きい改修、部署間で優先順位が対立する要望、契約条件そのものに関わる相談などは、窓口担当者が単独で開発会社に回答すべきではなく、経営者や上位の意思決定者にエスカレーションする必要があります。エスカレーションの一般的な判断基準や進め方についてはエスカレーションの考え方が参考になり、トラブル時の交渉術: 感情的にならずに解決するでも扱われています。

一元化の仕組みを整える際は、「窓口担当者が自分の判断で開発会社に伝えてよい範囲」と「経営者の判断を仰いでから伝えるべき範囲」をあらかじめ線引きしておくと、窓口担当者が過度なプレッシャーを抱えずに運用できます。

開発会社側にも一元化の方針を伝えておく

社内でのルール整備と並行して、開発会社側にも「今後は窓口(または一次受け)を経由した要望のみ正式なものとして扱ってほしい」と伝えておくことが重要です。開発会社側にこの方針を共有せずにいると、これまでの慣習で部署の担当者から直接連絡が来た場合に、開発会社側がそのまま対応を進めてしまうことがあります。

開発会社への伝え方としては、次のような形が実務的です。

• 定例ミーティングの場で、正式に方針転換を伝える
• 「今後、〇〇部署の担当者から直接連絡があった場合は、窓口を通すよう案内してほしい」と具体的に依頼する
• 移行期には、開発会社側にも混乱が生じ得ることを見込み、しばらくは並行して確認を入れる

多くの開発会社にとって、発注元の窓口が整理されることはむしろ歓迎される変化です。複数の担当者から矛盾する指示を受け取るリスクは、開発会社側にとっても業務効率を下げる要因になっているためです。

属人化した「あの人に聞けば早い」を崩す難しさ

要望の一元化を進める中で、最も根強い抵抗になるのが「あの人(特定の従業員)に直接頼めば早く対応してもらえる」という、社内に定着した成功体験です。これは一種の属人化した状態であり、ルールを整備しただけではすぐには崩れません。

この抵抗を和らげるには、一元化されたルートを経由しても対応スピードが落ちないことを、実績として示していく必要があります。棚卸しのサイクルを守り、優先順位をつけた要望が確実に開発会社に伝わり、対応状況がフィードバックされる――この一連の流れが機能しているのを見た部署の担当者は、次第に「窓口を通したほうが確実だ」という認識に変わっていきます。逆に、一元化したルートの対応が遅い、または放置されると感じられれば、旧来の「直接連絡」に逆戻りしてしまいます。

要望の一元化と現場のスピード感のバランス

一元化のルールを導入する際、現場から最もよく上がる反対意見は「窓口を経由すると対応が遅くなるのではないか」という懸念です。この懸念は、まったくの杞憂とは言い切れません。実際、窓口担当者が要望を溜め込みすぎたり、棚卸しの周期が長すぎたりすると、現場が感じる「遅さ」は本物になります。

このバランスを取るために、一元化のルールを設計する段階で、次の点を意識しておくとよいでしょう。

• 棚卸しの周期を、案件の性質に対して長すぎない頻度に設定する(月1回で足りない業務領域があれば、そこだけ週1回にするなど部署ごとに調整する)
• 緊急扱いの基準を明確にし、本当に急ぐものは棚卸しを待たせない
• 窓口担当者が要望を受け取ってから開発会社に伝えるまでの社内での滞留時間を、目安として決めておく(例: 受付から3営業日以内に開発会社へ伝える)

一元化は「現場のスピードを犠牲にして統制を優先する」ためのものではなく、「無秩序な個別対応によって発生する二次的な混乱を防ぎながら、結果的に組織全体としての対応速度を安定させる」ための仕組みです。この目的を窓口担当者自身も、要望を出す現場側も共有できていることが、制度の定着に欠かせません。

部署ごとに異なる「要望の質」に配慮する

10〜30人規模の会社では、部署によって開発会社への要望の性質が大きく異なることがあります。たとえば、営業部門からの要望は顧客対応に直結する緊急性の高いものが多く、製造・バックオフィス部門からの要望は業務効率化を目的とした計画的なものが多い、といった傾向です。

すべての部署の要望を同じ基準・同じフォーマットで一律に扱おうとすると、かえって現場の実態に合わなくなることがあります。要望の入り口となる共有シートやフォームは統一しつつも、部署ごとの傾向を踏まえて、優先順位判断の際に部署特有の事情を加味する柔軟さも必要です。この柔軟さを持たせるためには、窓口担当者だけで判断を完結させず、必要に応じて各部署の責任者に確認を取る運用を組み込んでおくとよいでしょう。

中長期的には一次受けの設置へ移行する

要望の一元化ルールが定着してきたら、次の段階として、各部署に「一次受け」の役割を置くことを検討してください。一次受けとは、部署内で発生した要望をまず部署内で取りまとめ、整理してから窓口担当者に渡す役割です。この役割があることで、窓口担当者は個々の要望を1件ずつさばくのではなく、すでに部署内で優先順位づけされた要望のかたまりを受け取るだけで済むようになり、負荷がさらに軽減されます。

一次受けの設置は、要望の一元化ルールがある程度定着し、各部署にもルールの意義が浸透してから進めるのが現実的です。ルールが定着する前にいきなり一次受けを置こうとすると、「誰が一次受けをやるのか」という新たな調整コストが発生し、かえって混乱を招くことがあります。段階を踏んで移行することをお勧めします。

よくある質問

Q. 要望の入り口をフォームにするか、口頭やチャットでの相談も受け付けるべきですか。

10〜30人規模の会社であれば、フォームに厳密に統一する必要はありません。口頭やチャットで相談を受けた場合でも、窓口担当者がその内容を共有シートに転記する運用で十分機能します。重要なのは、最終的にすべての要望が1箇所に集約される状態を作ることであり、入力経路そのものを厳格に制限することではありません。

Q. 経営者から現場への周知は、どのようなタイミングで行うのが効果的ですか。

朝礼や全社会議など、すでに存在する社内の情報共有の場を活用するのが最も定着しやすい方法です。新しいルールを発表するためだけに特別な場を設ける必要はなく、既存の場に「今後はこのように進める」という一文を加える形で十分です。あわせて、要望の入り口となる共有シートやフォームのリンクを、社内の目につきやすい場所(社内ポータル、チャットの固定メッセージなど)に掲示しておくと、周知の効果が長続きします。

Q. 一元化のルールを導入した直後、旧来の直接連絡がゼロにならないのは失敗ですか。

ルール導入直後に、これまでの習慣がすぐに消えることは稀です。むしろ、数回の移行期の混乱を経て徐々に定着していくのが一般的な流れです。直接連絡があった場合は、責めるのではなく「今後はこちらの窓口を通してもらえますか」と都度案内し続けることで、時間をかけて定着させてください。

記録が後々の交渉材料になる

要望を一元的に記録しておくことは、日々の混乱を防ぐだけでなく、開発会社との交渉においても有効な材料になります。追加費用の妥当性を確認する際、「いつ、どの部署から、どんな要望が出て、それがどう対応されたか」という記録があれば、開発会社からの請求内容と照合しやすくなります。この記録と請求確認を組み合わせる体制については開発会社からの請求内容を経理と一緒に確認する体制の作り方で扱っていますので、あわせて確認してください。

追加開発の依頼の仕方そのものについては追加開発の頼み方: 小さな改修を安く早く進めるコツにも実務的なポイントがまとまっています。一元化のルールと組み合わせることで、部署からの要望を無駄なく、かつ低コストで開発会社に伝えられるようになります。

複数の開発会社に要望が分散するケース

要望の分散問題は、1社の開発会社との関係の中だけで起きるとは限りません。10〜30人規模の会社では、基幹システムとホームページ、業務アプリを別々の開発会社に依頼しているマルチベンダーの状態もよく見られます。この場合、部署の担当者は「どの要望をどの開発会社に伝えればよいか」自体を把握していないことがあり、混乱がさらに複雑化します。

複数の開発会社と取引がある場合は、要望の入り口となる共有シートに「どのシステム・どの開発会社宛ての要望か」を明記する項目を追加しておくとよいでしょう。窓口担当者が要望を受け取った時点で、適切な開発会社に振り分けられるようにしておくことで、部署の担当者が発注先を誤って混乱するリスクを減らせます。

要望のログが後任者への引き継ぎ資産になる

要望を一元化して蓄積していく取り組みは、日々の混乱防止だけでなく、中長期的には貴重な引き継ぎ資産にもなります。窓口担当者が異動・退職する際、これまでどんな要望がどんな経緯で対応されてきたかという記録が残っていれば、後任者はゼロから開発会社との関係を理解し直す必要がなくなります。

逆に、要望のやり取りが個人の記憶やメールボックスの中だけに閉じていると、担当者が交代するたびに過去の経緯が失われ、同じような要望が形を変えて何度も浮上する、あるいは過去に見送った要望が「なぜ見送られたのか」分からないまま再検討される、といった非効率が繰り返されます。要望の一元化は、目の前の混乱を防ぐ効果と、将来の引き継ぎコストを下げる効果の両方を持つ取り組みだと捉えてください。

セルフチェック: 自社の要望はどの程度分散しているか

次の項目に当てはまる数が多いほど、要望の分散によるリスクが高い状態にあると考えられます。

• 複数の部署の担当者が、それぞれ開発会社の連絡先を知っている
• 過去1年で、部署の担当者が個別に開発会社へ直接連絡した事例がある
• どの部署がいつ何を依頼したか、社内でまとめて把握している人がいない
• 開発会社からの請求書を見て、身に覚えのない項目に気づいたことがある
• 「あの人に直接頼めば早い」という認識が社内に定着している
• 要望を受け付ける共有の窓口や仕組みが存在しない

3つ以上当てはまる場合は、まず「開発会社に直接連絡しない」という周知と、要望の入り口を1つ用意することから着手することをお勧めします。窓口そのものを1人に集中させすぎないための考え方は開発会社とのやり取りを総務兼任者1人に集中させない体制の作り方もあわせて参照してください。

一元化の取り組みを評価する指標

一元化のルールがうまく機能しているかどうかは、感覚だけでなく簡単な指標で振り返ることができます。次のような点を、四半期に一度程度の頻度で確認してみてください。

• 直近3ヶ月で、部署から開発会社への直接連絡が何件あったか(ゼロに近いほどルールが定着している)
• 要望の入り口から開発会社に伝わるまでの平均日数が、想定した目安(例: 3営業日以内)に収まっているか
• 開発会社からの請求内容と、社内で記録している要望の対応履歴が一致しているか
• 部署からの「対応が遅い」という不満の声が、導入前と比べて増えていないか

これらの指標は厳密な数値管理を目的としたものではなく、一元化の仕組みが形骸化していないかを定期的に点検するための目安です。指標が悪化してきた場合は、棚卸しの頻度や緊急対応の基準など、運用ルールのどこかに無理が生じている可能性があるため、早めに見直しを検討してください。

新入社員・中途入社者への周知も忘れない

一元化のルールが社内に定着してきた後も、新しく入社した従業員には改めて周知する必要があります。特に、以前勤めていた会社で「困ったら開発会社に直接連絡すればいい」という文化に慣れていた中途入社者は、悪気なく従来の習慣で直接連絡してしまうことがあります。

入社時のオンボーディング資料や説明の中に、「システムに関する要望は窓口経由で」という一文を組み込んでおくことで、ルールの形骸化を防げます。人の入れ替わりが起きるたびにルールが少しずつ崩れていくのを防ぐには、既存社員への周知だけでなく、新規入社者への周知フローも仕組みとして組み込んでおくことが重要です。

まとめ

部署が複数化した10〜30人規模の会社では、各部署の担当者が個別に開発会社へ要望を出してしまう混乱が起きやすくなります。この問題は、専任の情シス担当者を置き、窓口を完全に一本化するまで放置してよいものではありません。「開発会社に直接連絡しない」という周知、要望を受け付ける入り口の設置、定期的な棚卸しと優先順位付け――この3ステップは、専任担当者がいない段階でも今日から着手できる備えです。

要望の一元化は、ルールを1回伝えただけで定着するものではなく、対応状況のフィードバックや経営者自身の遵守を通じて、少しずつ社内の習慣として根付いていきます。混乱を放置すればするほど、予算の見えない超過や部署間の対立といった実害が積み重なっていくため、早い段階での着手をお勧めします。