開発会社とのやり取りを総務兼任者1人に集中させない体制の作り方

社員が10人を超え、営業・製造・バックオフィスといった部署が分かれ始めると、「情シス担当」という肩書きはなくても、いつの間にか総務や経理の担当者が開発会社とのやり取りの一切を引き受けている状態になっていることがあります。最初のきっかけは、単に「パソコンに詳しいから」「以前システム導入を担当したから」といった程度の理由でした。ところが会社が成長し、各部署が別々の要望を持ち込むようになると、この担当者は本来の業務のかたわらで、開発会社との連絡・調整・トラブル対応のすべてを1人で抱えることになります。

10人未満の会社であれば、窓口が社長1人に集中していても、意思決定の速さという利点もあり、大きな実害にはなりにくいものです。しかし10〜30人という段階では事情が異なります。部署が複数化し、要望の数も種類も増える一方で、窓口を担う兼任担当者には決裁権も専門知識も十分に与えられていないケースが大半です。権限のない人に情報だけが集中し、しかもその人がいなくなった瞬間にすべてが止まる――これが10〜30人規模で最も起きやすい「窓口の一極集中」の実態です。

このガイドでは、なぜこの段階でこの問題が起きやすいのか、放置した場合に何が起きるのか、そして専任の情シス担当を置く余裕がまだない中で、本業を圧迫せずにできる現実的な分散策を解説します。

なぜ10〜30人の会社で「隠れ窓口」が生まれるのか

10〜30人規模の会社の多くは、専任の情シス担当者を置いていません。総務省・経済産業省が公表する中小企業のIT人材に関する調査でも、情報システム専任者を置く企業の割合は従業員規模が小さいほど低く、多くの企業が兼任または不在という状況が繰り返し指摘されています。この会社では、経営者が「誰かが開発会社とのやり取りをやってくれている」と認識していても、実際には特定の1人に業務が偏っている「隠れ窓口」状態になっていることが少なくありません。

この隠れ窓口が生まれる背景には、10〜30人という規模特有の事情があります。

• 部署は増えたが、IT担当は増えていない: 営業部・製造部・管理部と組織図上は分かれても、開発会社とのやり取りをする人員は最初に担当した1人のまま据え置かれる
• 経営者の目が届きにくくなる: 10人未満の頃は社長がすべてのやり取りを直接把握できたが、規模が大きくなると経営者は他の意思決定に手一杯になり、開発会社との日々のやり取りを兼任担当者に任せきりにする
• 「頼れる人」に要望が集まる構造: 各部署の担当者は、開発会社に直接連絡する方法を知らない、あるいはその権限がないため、結局「あの人に頼めば伝えてくれる」という兼任担当者に要望を持ち込み続ける

結果として、兼任担当者は本業の合間に、営業部からの要望、製造部からの不具合報告、管理部からの追加費用の相談を同時に受け止める立場に置かれます。しかも、この状態は多くの場合、会社側が意図して設計したものではなく、なし崩し的に固定化されたものです。

窓口一極集中が10〜30人規模特有に生む3つのリスク

10人未満の会社における「社長ひとり窓口」のリスクは、主に意思決定の停滞でした。しかし10〜30人規模では、窓口を担うのが決裁権を持たない兼任担当者であるため、リスクの性質が変わります。

この3つのうち、特に見落とされがちなのが「部署間の要望が競合する」問題です。10人未満の段階では要望を出す人自体が少なく、優先順位の調整もその場の会話で済んでいました。ところが部署が複数化すると、兼任担当者は技術的な判断以前に「誰の要望を優先するか」という社内調整に追われるようになります。この社内調整の負荷は、開発会社との技術的なやり取りよりもむしろ重く、兼任担当者が疲弊する最大の要因になっているケースが多く見られます。

「その人がいなくなったら」で考える

窓口一極集中のリスクを具体的に把握するには、「その兼任担当者が急に1ヶ月休んだら何が起きるか」というシナリオで考えるのが有効です。多くの会社で、次のような事態が想定されます。

1. 開発会社からの請求内容の確認が誰にもできず、内容を検証しないまま支払いが続く
2. 各部署から新しく出た要望が、誰にも取り次がれずに宙に浮く
3. 進行中の改修について「なぜこの仕様になったのか」を説明できる人がいなくなる
4. 開発会社側も、連絡先が1つしかないため、緊急の確認事項を保留にせざるを得なくなる

これらはいずれも、致命的な事故ではなく「じわじわと進行する機能不全」です。派手なトラブルにならないぶん、経営者が異常事態として気づきにくく、兼任担当者が体調を崩したり退職したりして初めて表面化することが少なくありません。

分散すべきは「窓口」だけでなく「記録」

窓口の一極集中を解消しようとするとき、多くの会社は「担当者を増やす」ことだけを考えがちです。しかし、担当者を増やしても、その人たちが開発会社とのやり取りの経緯を共有できていなければ、単に「隠れ窓口が2人になる」だけで根本解決にはなりません。分散させるべきものは、窓口という役割そのものと、その窓口が持っている情報の両方です。

1. 部署ごとの「一次受け」を決める

まず、各部署からの要望を兼任担当者に直接持ち込ませるのではなく、部署ごとに要望を取りまとめる「一次受け」の役割を決めます。一次受けは開発会社と直接やり取りする必要はなく、自部署内の要望を整理し、優先順位をつけたうえで兼任担当者に渡す役割です。この一段階を挟むだけで、兼任担当者が個別の要望をさばく負荷は大きく減ります。部署が複数化した段階で個別要望がバラバラに開発会社へ流れてしまう問題については、部署の担当者が個別に開発会社へ要望を出してしまう状態を防ぐ方法で詳しく扱っています。

2. やり取りの記録を「個人のメール」から「共有の場所」に移す

兼任担当者個人のメールボックスやチャットのDMだけにやり取りが残っている状態は、その人がいなくなった瞬間に情報が失われる典型的な構造です。次の3点だけでも、部署を横断して見られる場所(共有スプレッドシート、社内チャットの共有チャンネルなど)に移してください。

この記録は議事録のように精緻である必要はありません。重要なのは、兼任担当者の頭の中とメールボックスだけに情報が閉じ込められている状態を解消することです。記録を怠った結果、契約書や仕様書そのものが所在不明になってしまうケースの復元手順は30-100人規模で基幹システムの契約書・仕様書が見当たらないときの復元手順でも扱っていますので、記録の型に迷う場合は参照してください。

3. 副窓口を最低1人、権限とセットで決める

10人未満の会社と同様、10〜30人の会社でも「副窓口」を1人決めておくことは有効です。ただし10〜30人規模では、単に取り次ぎ役を置くだけでなく、「どこまでの金額・内容であれば副窓口の判断で進めてよいか」という権限の範囲もあわせて決めておく必要があります。権限が曖昧なまま副窓口を置くと、結局すべての判断が主担当者に戻ってきてしまい、分散の効果が薄れます。

権限を伴わない窓口の分散は、実質的には分散していません。「誰が」「どこまで」判断できるかをセットで決めることが、10〜30人規模での窓口分散の要点です。

定例ミーティングを情報共有の場として活用する

窓口の分散を進めるうえで、既存の定例ミーティングを活用する方法もあります。多くの会社では、開発会社との定例が主担当者1人だけの出席で行われていますが、ここに副窓口や各部署の一次受けを月1回程度でも同席させることで、情報の断絶を大きく減らせます。定例の頻度そのものを兼任体制に合わせて見直す方法については小規模開発案件で開発会社との定例を月1回にする際の進め方で扱っています。定例ミーティングの一般的な運営方法は開発プロジェクトの定例ミーティングの回し方にまとまっていますので、あわせて確認してください。

経理との連携も窓口分散の一部

意外と見落とされがちですが、請求内容の確認を主担当者1人だけが担っている状態も、窓口一極集中の一種です。保守費や追加費用の請求は経理と共有し、金額の妥当性を複数の目で確認できる体制にしておくことで、主担当者が不在でも支払い業務が止まらずに済みます。この観点については開発会社からの請求内容を経理と一緒に確認する体制の作り方で詳しく扱っています。

兼任担当者自身が「窓口一極集中」を作ってしまうケース

ここまでは、組織構造として窓口が1人に集中してしまう経緯を中心に説明してきました。しかし実際には、兼任担当者本人の行動が、意図せず一極集中を強めてしまっているケースも珍しくありません。よくあるのが、次のような心理です。

• 「自分が窓口を離れると、開発会社に迷惑がかかるのではないか」という責任感から、休暇中もメールを確認し続けてしまう
• 「他の人に任せると自分より対応の質が落ちるのではないか」という不安から、権限移譲に消極的になる
• 「引き継ぎの資料を作る時間があるなら、目の前の対応を進めたほうが早い」という判断で、記録を後回しにし続ける

これらはいずれも、担当者個人の責任感の強さや業務の忙しさから生じるものであり、責められるべき態度ではありません。しかし結果として、組織側が窓口を分散しようとしても、担当者本人が無意識に情報を抱え込み続けてしまい、分散が進まないという事態が起こります。窓口分散の取り組みは、組織側の仕組みづくりと同時に、担当者本人に「抱え込まなくてよい」と伝える経営側からの明確なメッセージがセットで必要です。

経営者が果たすべき役割

窓口一極集中の解消は、兼任担当者本人の努力だけでは達成できません。経営者には、次の3つの役割が求められます。

1. 一次受けや副窓口に、実際に判断できる権限を与える: 「相談してよい」というだけでなく、「この金額までは決裁不要」といった具体的な線引きを経営者自身が示す
2. 部署間の要望の優先順位付けに関与する: 兼任担当者に「どちらを優先すべきか」の板挟みを丸投げせず、部署を横断した優先順位の最終判断は経営者が担う
3. 記録や引き継ぎのための時間を業務として認める: 記録作成を「本業の合間にやること」ではなく、正式な業務時間として扱う

特に3点目は見落とされがちです。記録や引き継ぎ資料の作成は、目に見える成果物(納品されたシステムや解決した不具合)と違って評価されにくく、後回しにされがちな業務です。経営者が「記録を残すことも仕事の一部である」と明言し、業務時間の一部として認めることで、初めて兼任担当者は安心して記録作成に時間を割けるようになります。

開発会社側から見た「窓口が変わる」ことへの受け止め方

窓口の分散を検討する際、社内側の事情だけでなく、開発会社側がどう受け止めるかも考慮しておくと、移行がスムーズになります。多くの開発会社にとって、発注元の窓口が複数人いること自体は珍しくなく、むしろ歓迎されることもあります。理由は次の通りです。

• 窓口が1人しかいない場合、その人の休暇や体調不良のたびにプロジェクトが止まるリスクを、開発会社側も感じている
• 複数人が状況を把握していれば、確認事項への回答が早くなり、開発会社側の作業も滞りにくい
• 誰が最終的な決裁権を持つかが明確であれば、開発会社側も見積もりや提案をどのレベルの相手に出せばよいか判断しやすい

一方で、窓口が増えることで「言った・言わない」の食い違いが増えることを懸念する開発会社もあります。この懸念を払拭するには、「誰が最終決裁者か」「複数の窓口がいる場合、それぞれの役割は何か」を、開発会社に対しても明確に伝えておくことが有効です。窓口体制を変更する際は、社内調整だけで完結させず、次の定例や打ち合わせの場で開発会社にも一言共有しておくとよいでしょう。

移行期に起きやすい混乱と対処

窓口を1人体制から複数人体制に移行する過程では、一時的に混乱が生じることがあります。よくあるパターンと対処法を整理します。

これらの混乱は、体制を変える以上ある程度避けられないものです。重要なのは、混乱が起きた時点で「やっぱり元の1人体制のほうが楽だった」と後戻りしないことです。移行期の摩擦は、分散体制が定着する過程で自然に減っていきます。

属人化との関係で考える

開発会社との窓口一極集中は、社内の属人化の一種です。ただし、通常の業務属人化と異なり、開発会社という「社外の相手」が関わる分、情報が完全に社内に閉じていない点は救いです。開発会社側にやり取りの記録や見積もりの控えを保管してもらっている場合、社内の記録が失われても開発会社に照会すれば一部は復元できます。とはいえ、開発会社に依存しきった復元は時間もコストもかかるため、あくまで社内での記録を基本線とすべきです。

なお、このガイドで扱っているのは「開発会社との窓口」という特定の業務に絞った一極集中です。IT対応を担う兼任者1人が抜けた場合に会社全体でどの業務が止まるかを広く洗い出したい場合は、総務1人が退職したら止まる業務を今のうちに数える方法でより網羅的なチェック手順を扱っていますので、あわせて参照してください。

複数の開発会社と取引がある場合はさらに複雑になる

10〜30人規模の会社では、基幹システムはA社、ホームページはB社、業務アプリはC社というように、複数の開発会社と個別に契約しているケースも珍しくありません。この場合、窓口一極集中の問題はさらに複雑になります。兼任担当者は1社とのやり取りだけでなく、複数社それぞれの契約条件・連絡先・進行中の案件を同時に管理することになり、負荷は単純な足し算以上に膨らみます。

複数の開発会社を抱える状態は、いわゆるマルチベンダーの状態です。この状態自体が悪いわけではなく、それぞれの分野に強みを持つ会社を使い分けること自体は合理的な選択肢です。しかし、窓口が1人に集中したまま複数社との関係を管理しようとすると、次のような問題が起きやすくなります。

• どの会社にどの依頼をしたか、記録がなければ本人以外は追えなくなる
• 契約条件(保守範囲・請求サイクル・緊急連絡先)が会社ごとに異なるため、覚えておくべき情報量が単純に倍増する
• ある会社との調整で手一杯になっているあいだ、別の会社からの確認事項への返信が滞る

複数社と取引がある会社ほど、窓口の分散と記録の共有化は優先度の高い課題になります。1社であれば担当者の記憶でなんとか回っていた管理も、複数社になると記憶だけでは確実に破綻します。まずは取引のある開発会社を一覧化し、それぞれの契約範囲・連絡先・担当者を共有の記録として残すところから始めてください。

記録を残す際に使えるツールの選び方

記録の共有化を進める際、多くの会社が「何のツールを使うべきか」で悩みます。結論から言えば、10〜30人規模でこの目的のために新しいツールを導入する必要はほとんどありません。すでに社内で使っている表計算ソフトやチャットツールで十分に対応できます。

• 表計算ソフト(Excel・Googleスプレッドシート): 依頼内容・金額・ステータスを一覧管理するのに向いている。ただし更新が滞ると形骸化しやすいため、更新のタイミング(定例後・要望受付時など)をあらかじめ決めておく
• チャットツールの共有チャンネル: 日々のやり取りをリアルタイムで共有するのに向いている。ただし過去の経緯を後から探しにくいため、重要な合意事項だけは別途一覧にまとめる運用と併用するとよい
• クラウドストレージ内の共有フォルダ: 見積書・契約書・議事録などの書類そのものを保管するのに向いている。個人のメールに添付ファイルとして埋もれさせない受け皿として機能する

新しいツールを導入すること自体が目的化してしまうと、かえって定着せずに終わるケースが多く見られます。まずは今あるツールの中で「どこに何を残すか」というルールを決めることを優先してください。

兼任担当者の異動・退職に備えた引き継ぎの最低ライン

窓口の分散を進めていても、主担当者の異動や退職が急に決まることはあります。その場合に備え、最低限これだけは引き継ぎ資料として残しておくべき、という項目を整理しておきます。

1. 取引のある開発会社の一覧: 会社名・担当者名・連絡先・契約している範囲(基幹システム、ホームページ、業務アプリなど)
2. 契約条件の要点: 保守費の金額と支払いサイクル、契約更新の時期、解約条件
3. 進行中の案件・要望の状況: 現在依頼中の改修や相談中の追加費用について、どこまで話が進んでいるか
4. 過去の主要なトラブルとその解決方法: 同じトラブルが再発した際に、過去の対応を参考にできるようにする

これらの情報が引き継ぎ資料として1箇所にまとまっていれば、後任者は開発会社との関係をゼロから構築し直す必要がなくなります。逆に、この最低ラインすら整理されていない状態で担当者が抜けてしまうと、後任者は開発会社に一つひとつ経緯を聞き直すところから始めることになり、双方にとって大きな時間のロスになります。引き継ぎ資料は、担当者が退職する直前に慌てて作るものではなく、日々の記録の延長として少しずつ蓄積しておくのが理想です。

よくある質問

Q. 副窓口を置くと、開発会社への説明責任が二重になって逆に手間が増えませんか。

短期的には、副窓口への情報共有という手間が増えるように感じられるかもしれません。しかし中長期的には、主担当者が不在の際に発生する「代わりに誰かが一から状況を把握し直す」手間のほうがはるかに大きくなります。副窓口への日常的な共有は、緊急時の手戻りを防ぐための先行投資と捉えてください。

Q. 部署ごとの一次受けを決めても、結局その人も忙しくて機能しないのではないですか。

一次受けの役割は、開発会社と直接やり取りすることではなく、自部署内の要望を整理して兼任担当者に渡すことに限定するのがポイントです。役割を絞り込めば、一次受けにかかる負担はそれほど大きくありません。役割が曖昧なまま「窓口っぽいこと全般」を任せようとすると、一次受け自身が疲弊し、機能しなくなります。

Q. 経営者が忙しく、権限の線引きを決める時間が取れません。どうすればよいですか。

完璧な線引き表を最初から作る必要はありません。まずは「この金額までは兼任担当者の判断で進めてよい」という金額の目安を1つ決めるだけでも、日常的な相談の多くはその場で解決できるようになります。細かい線引きは、運用しながら少しずつ具体化していけば十分です。

セルフチェック: 自社の窓口はどの程度集中しているか

次の項目のうち、当てはまる数が多いほど窓口一極集中のリスクが高い状態です。

• 開発会社とのやり取りを見られるのが特定の1人だけである
• その人が1ヶ月休んだ場合、誰も開発会社との過去の合意内容を答えられない
• 各部署からの要望が、すべてその人を経由してからでないと開発会社に伝わらない
• 請求内容の妥当性を確認しているのがその人だけで、経理は金額を見ていない
• 副窓口を決めたことがない、あるいは決めても権限の範囲が曖昧なままである
• その人の異動・退職の予定が特にないという理由で、この状態を放置している

3つ以上当てはまる場合は、まず「一次受けの決定」と「記録の共有化」の2点から着手することをお勧めします。自社全体のIT管理の危険度を客観的に把握したい場合は、ひとり情シス危険度診断もあわせて活用してください。

30人を超えて専任担当者を置くタイミングの見極め

窓口の分散を進めていく中で、いずれ「そろそろ専任の担当者を置くべきか」という判断に直面します。10〜30人規模では兼任体制のまま乗り切れることが多いものの、次のような兆候が重なってきたら、専任化を検討する時期に来ていると考えられます。

• 一次受けや副窓口を置いても、なお主担当者への相談件数が減らない
• 開発会社とのやり取りに割く時間が、本業の業務時間を恒常的に圧迫している
• 取引先の開発会社の数が増え、契約条件の管理だけで一定の工数がかかっている
• 新しいシステム導入やAI活用の検討など、片手間では判断しきれない相談が増えている

これらの兆候が複数当てはまる場合、会社の規模としてはまだ30人に届いていなくても、実質的には「ひとり情シス」を専任で置くべき局面に近づいています。専任担当者を置いた後の最初の90日の動き方についてはひとり情シスに任命されたら、何からやれば会社を止めずに済むかにまとめていますので、専任化を検討する際の参考にしてください。逆に言えば、今この段階で窓口の分散と記録の共有化を徹底しておくことは、将来専任担当者を置く際の引き継ぎコストを大きく下げることにもつながります。属人化した状態のまま専任担当者にバトンを渡すと、後任者は本ガイドで挙げたのと同じ「隠れ窓口」の問題を一から解きほぐす羽目になります。

まとめ

10〜30人という段階での窓口一極集中は、10人未満の「社長ひとり窓口」とは異なり、決裁権のない兼任担当者に情報と調整負担だけが集中するという、より厄介な構造を持っています。部署が増えるにつれて要望の数も種類も増える一方で、窓口を担う人員は据え置かれたままというケースが大半です。

この状態を放置すると、担当者の退職や異動をきっかけに、開発会社との関係そのものが振り出しに戻るリスクがあります。一次受けの設置、記録の共有化、権限を伴う副窓口の設置――これらは大きな組織変更を必要とせず、今の体制のまま段階的に進められる備えです。専任の情シス担当を置く余裕がまだない会社こそ、窓口という「見えない負荷」の分散から着手することをお勧めします。