開発会社とのやり取り担当が社長ひとりという状態のリスクと備え

社員10人未満の会社でシステム開発を発注するとき、開発会社とのやり取りは、ほぼ例外なく社長が担っています。要件を伝えるのも社長、見積もりを見るのも社長、進捗を確認するのも社長、追加費用を交渉するのも社長です。従業員数が少ない段階では、これは自然な状態です。専任の担当者を置く余裕もなく、そもそも社長自身がやりたいことを一番よく分かっているため、間に誰かを挟むより直接話したほうが早いという事情もあります。

しかし、この「窓口が社長ひとり」という状態は、会社が成長するにつれて、あるいは何らかのきっかけで社長が動けなくなったときに、思わぬ形でリスクとして表面化します。このガイドでは、なぜこの一極集中が起きるのか、放置するとどんな問題が起きるのか、そして本業で忙しい社長でも無理なく実行できる最低限の備えを解説します。

なぜ社長ひとりに集中するのか

10人未満の会社で開発会社との窓口が社長に集中する背景には、いくつかの構造的な理由があります。まず、システム開発の発注は経営判断そのものであることが多いという点です。何を作るか、いくら払うか、いつまでに欲しいかは、事業の方向性に直結する意思決定であり、他の誰かに完全に委ねにくい性質を持っています。

次に、初期の発注では要件がまだ固まりきっておらず、社長の頭の中にあるイメージを開発会社に伝える役割が、社長本人にしか果たせないという事情もあります。従業員に「これを開発会社に伝えておいて」と依頼しても、事業の背景や優先順位のニュアンスまでは伝わりきらず、結局「社長に直接聞いてください」という流れに戻ってしまいがちです。

さらに、10人未満の会社では、システム開発の窓口を専任で置けるほどの人員的な余裕がそもそもありません。経理も総務も営業も社長が兼務しているような組織では、「開発会社とのやり取り」という業務だけを切り出して誰かに任せるという発想自体が生まれにくいのです。

窓口一極集中が引き起こす3つの問題

窓口が社長ひとりに集中している状態は、平時には特に問題を起こしません。問題が表面化するのは、何らかの理由で社長が動けなくなったときです。想定される問題を整理すると、大きく3つに分けられます。

• 意思決定の停滞: 社長が出張中・体調不良・他の商談で手一杯のとき、開発会社からの確認事項に誰も答えられず、プロジェクトがそのまま止まってしまう
• 情報の欠落: 過去のやり取りの経緯や、なぜその仕様になったのかという背景が社長の記憶やメールの中にしかなく、他の従業員がプロジェクトの全体像を把握できない
• 交渉力の低下: 追加費用や納期の相談が発生した際、社長以外に状況を客観的に判断できる人がおらず、開発会社の言い分をそのまま受け入れざるを得なくなる

これらの問題は、単発では大きな実害に見えないかもしれません。しかし、複数のプロジェクトを同時に抱えるようになったり、社長が経営全体の判断に忙殺されるようになったりすると、開発会社とのやり取りの質が目に見えて落ちていきます。「返信が3日来ない」「言った言わないの水掛け論になる」といった摩擦は、多くの場合、窓口の一極集中が引き金になっています。

社長が倒れたら、というシナリオで考える

窓口一極集中のリスクを具体的にイメージするために、「社長が1週間、連絡が取れなくなったらどうなるか」というシナリオで考えてみましょう。入院、家族の緊急事態、あるいは単純な多忙による対応不能――理由は何でもかまいません。重要なのは、そのとき開発会社から届いた「この仕様で進めてよいですか」という確認メールに、誰も答えられない状態になることです。

開発会社側も、返信がなければ判断に迷います。多くの開発会社は、確認が取れない項目については保留にして他の作業を進めるか、最悪の場合は独自の判断で進めてしまいます。前者であればプロジェクト全体の進行が遅れ、後者であれば「頼んでもいない仕様で作られてしまった」という食い違いが生まれます。どちらのケースも、社長が復帰してから軌道修正するために、余計な時間とコストがかかります。

この事態を防ぐために必要なのは、複雑な体制の構築ではありません。「社長以外に、最低限の状況を把握し、緊急時に一次対応できる人が1人いる」というだけで、多くの停滞は回避できます。

最低限やっておきたい3つの備え

窓口の分散といっても、10人未満の会社でいきなり専任担当者を置くのは現実的ではありません。ここでは、本業を圧迫せずに実行できる、優先度の高い3つの備えを紹介します。

1. 副窓口を1人決めておく

まず着手すべきは、社長が動けないときに一次対応できる「副窓口」を1人決めておくことです。この人物が開発会社とのやり取りをすべて代行する必要はありません。「緊急の連絡が来たら、まず内容を確認し、社長に取り次ぐ、あるいは簡単な判断であれば対応する」という役割で十分です。

副窓口には、開発会社とのメールのCCに常に入ってもらう、あるいはチャットツールのプロジェクト用チャンネルに参加してもらうといった形で、日常的にやり取りの様子を見える状態にしておくことが重要です。いきなり緊急時に「初めて見る画面で、初めて聞く話」という状態では、副窓口としての役割を果たせません。

2. やり取りの経緯を最低限記録する

社長の頭の中にしかない情報を減らすため、開発会社とのやり取りのうち、重要な意思決定に関わる部分だけでも記録に残しておくことをお勧めします。すべてのメールやチャットを議事録化する必要はありません。次の3点だけは、簡単なメモでよいので残しておいてください。

この3点さえ社長以外の誰かが把握していれば、社長が不在の間に開発会社から連絡が来ても、「詳細は分からないが、状況は把握している」という状態を作れます。記録の形式は、共有のスプレッドシートでもチャットのピン留めメッセージでも構いません。重要なのは、社長のメールの受信箱だけに情報が閉じ込められている状態を避けることです。

3. 開発会社側にも「窓口は社長だけではない」と伝えておく

意外と見落とされがちですが、開発会社側に対しても、緊急時の連絡先として副窓口の連絡先を共有しておくことが有効です。多くの開発会社は、発注元の窓口が1人しかいないことを把握していれば、その人物が不在のときに配慮した進行をしてくれることもあります。逆に、副窓口の存在を伝えていなければ、開発会社側も「社長からの返信を待つしかない」という状態になり、双方にとって非効率です。

初回の打ち合わせや契約時に、「基本的には私が窓口ですが、緊急時は〇〇にも連絡してもらえますか」と一言添えておくだけで、この備えは機能し始めます。開発会社との最初の打ち合わせの心構えについては、少人数企業が開発会社との最初の打ち合わせで舐められないためにはでも扱っていますので、あわせて参照してください。

定例ミーティングの仕組みを借りる

窓口の分散を進める際、既存の定例ミーティングの仕組みをそのまま活用できる場合もあります。定例ミーティングの回し方そのものについては開発プロジェクトの定例ミーティングの回し方で詳しく解説されていますが、10人未満の会社であれば、この定例に副窓口を同席させるだけでも、情報の断絶を大きく減らせます。

社長ひとりで定例に出席していると、その場での判断や合意事項が、議事録が残らない限り社長の記憶だけに依存してしまいます。副窓口が同席していれば、社長が後から「あのとき何を話したっけ」と思い出せなくても、もう1人の記憶や簡単なメモで補完できます。定例の頻度が月1回程度であれば、副窓口の時間的な負担も大きくありません。

「社長がすべてを把握している」という誤解に注意する

一極集中のリスクを考えるうえで、もう一つ注意したい点があります。それは、社長自身が「自分がすべて把握しているから大丈夫」と思い込んでいるケースです。実際には、日々の細かいやり取りの中で、社長自身も過去の合意事項を正確に覚えていないことは珍しくありません。

• 「前回、追加費用は発生しないという話だったはずだが、記憶が曖昧」
• 「仕様変更を依頼した経緯を、開発会社に聞かれても答えられない」
• 「見積もりのどの項目にいくらかかっているか、詳細を覚えていない」

こうした「社長ですら把握しきれていない」状態は、記録がないことの裏返しです。副窓口を置くこと自体が、社長自身の記憶の負担を減らし、結果として社長の判断の精度を上げることにもつながります。

開発会社との関係において、窓口の分散は「社長の仕事を減らす」ためだけでなく、「社長ひとりの記憶に依存した曖昧な合意」を防ぐためのリスク管理でもあります。

副窓口に向いている人物のタイプ

副窓口を誰に任せるかは、10人未満の会社にとって悩ましい問題です。専任の担当者を置く余裕がない以上、既存の従業員の中から選ぶことになりますが、次のような条件を満たす人物が向いています。

1. 事業内容や業務フローを一定程度理解している(新入社員よりは、多少勤続年数のある人物)
2. 文章でのやり取りに抵抗がない(メール・チャットでの意思疎通が中心になるため)
3. 「分からないことは分からないと言える」性格である(無理に自己判断せず、社長への確認を優先できる)

技術的な知識は必須ではありません。副窓口の役割は、あくまで一次的な取り次ぎと記録であり、専門的な技術判断まで求めるものではないからです。この点を誤解して「エンジニア経験がないと務まらない」と決めつけてしまうと、候補者が見つからず、結局社長ひとりの状態が続いてしまいます。

属人化との関係

窓口の一極集中は、社内の属人化の一種と捉えることもできます。社内のITに詳しい人物への依存と同じ構造で、「社長にしか分からない、社長にしかできない」という状態が、会社にとってのリスクになっています。属人化への一般的な対策については、他の記事でも詳しく扱っていますが、開発会社との関係に限定した場合、記録の残し方や副窓口の置き方は、通常の業務属人化対策よりもシンプルに始められる部類に入ります。開発会社とのやり取りは、頻度が限られており(多くの場合、週1回の定例や月数回のメールのやり取り程度)、記録すべき情報量もそれほど多くないためです。

納品後・保守フェーズでも窓口の分散は続ける

窓口の分散は、開発中だけでなく、納品後の保守フェーズにおいても同様に重要です。むしろ、保守フェーズに入ると連絡の頻度は下がるものの、いざ障害が起きたときの緊急対応では、窓口の一極集中がより深刻な問題として表面化します。納品時に何を受け取っておくべきかについては納品後に「あとはよろしく」と言われて何をどう受け取ればいいか、保守契約の範囲については月1万円台の格安保守契約、契約時点で「範囲外」を確認するで扱っていますので、あわせて確認してください。

保守フェーズにおける社内と開発会社の役割分担の考え方は、運用フェーズの体制: 社内と開発会社の役割分担でも解説されています。10人未満の会社では体制そのものを大きく変えることは難しいものの、「誰が一次対応をするか」を決めておくことだけは、規模に関わらず実行可能です。

社長自身が退任・離脱するケースへの備え

窓口一極集中のリスクを考えるとき、多くの経営者は「自分が一時的に動けなくなる」ケースは想像しても、「自分がこの会社から離れる」ケースまでは想像しないものです。しかし、共同創業者への事業承継、M&Aによる経営権の移動、あるいは病気や事故による長期離脱など、社長自身が完全にプロジェクトから外れる可能性はゼロではありません。

このとき、開発会社との関係が社長の個人的な信頼関係の上にしか成り立っていないと、後任者は文字通りゼロから関係を構築し直すことになります。開発会社からすれば、「これまでのプロジェクトの経緯を知らない、初めて話す相手」に対応することになり、これまで蓄積された暗黙の了解や配慮が一度リセットされてしまいます。

これは大げさな話ではなく、実際に創業社長が交代するタイミングで、開発会社との契約条件や優先順位の認識が食い違い、トラブルに発展するケースは珍しくありません。副窓口を育てておくことは、こうした万一の経営交代の場面でも、開発会社との関係を大きく損なわずに引き継ぐための保険としても機能します。

契約書・見積書の宛名と連絡先を確認する

窓口の分散を考える際、見落とされがちなのが契約書類上の連絡先です。10人未満の会社では、契約書や見積書の「発注者」欄に社長個人の名前や個人の携帯番号が記載されているケースが少なくありません。会社としての正式な連絡先ではなく、社長個人の連絡先が唯一の窓口として契約書に固定されてしまっていると、副窓口を立てても、書類上は社長しか正式な窓口として認識されない状態が続いてしまいます。

契約更新や新規契約のタイミングでは、次の点を確認しておくとよいでしょう。

• 発注者の連絡先欄に、会社の代表番号やグループメールアドレスなど、個人に紐づかない連絡先を併記できないか
• 緊急連絡先として、副窓口の連絡先を契約書の別紙やメールで正式に共有できないか
• 請求書の送付先が社長個人のメールアドレスになっていないか(経理担当がいる場合は経理のアドレスも追加する)

契約書の名義が個人になっていることのリスクは、開発会社との関係だけでなく、契約全般に共通する論点でもあります。個人名義での契約が引き起こす問題については「社長名義」の契約、10人になる前に会社名義へ切り替えるで詳しく扱っていますので、契約書を見直す際にはあわせて確認することをお勧めします。

副窓口を育てる際によくある失敗パターン

副窓口の必要性を理解していても、実際にうまく機能しないケースもあります。ここでは、10人未満の会社でよく見られる失敗パターンを3つ紹介します。

失敗パターン1: 名前だけ決めて、実質的な引き継ぎをしていない

「〇〇さんを副窓口にする」と決めただけで、実際にはメールのCCにも入れず、定例ミーティングにも同席させていないケースです。この状態では、いざというときに副窓口が状況を把握しておらず、結局機能しません。副窓口を決めたら、必ず日常的な情報共有の仕組み(CC・チャンネル参加・定例同席のいずれか)とセットで運用してください。

失敗パターン2: 副窓口に全権限を委ねようとして失敗する

逆に、副窓口を決めた途端に「もうこの件は任せた」と、意思決定の権限まで丸ごと委ねてしまうケースです。10人未満の会社では、事業の意思決定は依然として社長が担うべき場面が多く、副窓口に求められるのはあくまで一次対応と取り次ぎです。権限の範囲を曖昧にしたまま任せると、副窓口本人が「どこまで自分で判断していいのか分からない」というプレッシャーを抱え、機能不全に陥ります。

失敗パターン3: 副窓口が退職して、また社長ひとりに戻ってしまう

副窓口として育てた人物が退職・異動してしまい、後任を決めないまま元の一極集中状態に戻ってしまうケースです。副窓口は一度決めて終わりではなく、退職や異動のたびに見直しが必要な体制であるという認識を持っておく必要があります。

エスカレーション基準を決めておく

副窓口を置く際、もう一つ決めておきたいのが「どこまでは副窓口の判断でよく、どこからは社長の判断が必要か」というエスカレーションの基準です。基準が曖昧なままだと、副窓口は些細なことでも社長に確認を取ろうとして機能が形骸化するか、逆に本来確認すべきことまで独断で進めてしまうかのどちらかに偏りがちです。

10人未満の会社であれば、次のような簡単な基準を決めておくだけでも十分機能します。

この基準表は完璧である必要はなく、口頭での合意でも構いません。重要なのは、副窓口が「これは自分で答えていいのか、それとも社長に確認すべきなのか」を毎回迷わずに判断できる状態を作ることです。

セルフチェック: 自社の窓口体制はどの程度リスクを抱えているか

自社の状態を客観的に把握するために、次のチェックリストを活用してください。当てはまる項目が多いほど、窓口一極集中のリスクが高い状態にあると考えられます。

• 開発会社とのメール・チャットのやり取りを見られるのは社長だけである
• 社長が1週間連絡が取れなくなった場合、誰も開発会社の問い合わせに答えられない
• 過去の見積もり・追加費用の合意内容を、社長以外の誰も把握していない
• 契約書・見積書の連絡先が社長個人のメールアドレス・携帯番号のみになっている
• 開発会社側も、社長以外の連絡先を把握していない
• 副窓口を決めたことがない、あるいは決めたが機能していない

6項目のうち3つ以上に当てはまる場合は、早めに副窓口の設置に着手することをお勧めします。5つ以上当てはまる場合は、現時点で社長が動けなくなった瞬間にプロジェクトが停止するリスクが高い状態にあると考えてください。

このチェックリストは、開発会社との関係に限定した簡易版です。社内のIT体制全般における属人化のリスクをより広く点検したい場合は、社内のパスワード・アカウント管理の棚卸しや、IT台帳の整備もあわせて進めることをお勧めします。窓口の分散だけを単発で行っても、他の属人化リスクが残っていては、根本的な解決にはなりません。開発会社との窓口という一点に絞ってでも今日から着手できることが、このチェックリストの価値です。

ツールを使った情報共有の工夫

副窓口との情報共有を続けるうえで、特別なシステムを導入する必要はありません。10人未満の会社であれば、次のような身近なツールの組み合わせで十分に運用できます。

• メール: 開発会社とのやり取りに使うメールアドレスを、社長個人のアドレスではなく、共有のグループアドレス(例: dev@自社ドメイン)にする。あるいは個人アドレスのまま、副窓口を常時CCに入れる運用にする
• チャットツール: Slack・Chatwork等を使っている場合は、開発会社とのやり取り専用のチャンネル・グループを作り、副窓口を必ず参加させる
• クラウドの共有フォルダ: 見積書・契約書・仕様書などの書類を、社長個人のパソコンやメールの添付ファイルとしてだけでなく、Google DriveやDropboxなどの共有フォルダにも保存しておく

これらはいずれも、多くの会社がすでに契約しているツールの範囲内で完結します。新たに情シス的なツールを導入する必要はなく、「今使っているツールに、副窓口も参加させる」というだけで、情報のブラックボックス化をかなり防げます。

開発会社側から見た「窓口が1人しかいない発注者」

視点を変えて、開発会社側がこの状況をどう見ているかにも触れておきます。開発会社にとって、発注者の窓口が社長ひとりに固定されていること自体は、必ずしも悪いことばかりではありません。意思決定が早く、話が通りやすいというメリットもあるためです。

一方で、開発会社側にとっても、窓口が1人しかいない発注者には特有のリスクがあります。その社長と連絡が取れなくなった瞬間に、プロジェクト全体が止まってしまうという構造は、開発会社にとっても進行管理上の不安要素です。実際、経験豊富な開発会社であれば、契約時や初回の打ち合わせで「緊急時の連絡先は他にありますか」と尋ねてくることもあります。この質問をされたときに、即答できる状態を整えておくことは、開発会社に対して「発注者側もリスクを理解している」という安心感を与えることにもつながります。

逆に、この質問をされて初めて「そういえば決めていなかった」と気づくケースも少なくありません。副窓口の設置は、開発会社との信頼関係を築くうえでも、地味に効いてくる備えだと考えてください。

段階的に進める: いきなり完璧を目指さない

ここまで紹介した備えを、すべて一度に整えようとする必要はありません。10人未満の会社であれば、まずは副窓口を1人決めることから始めてください。次に、直近の重要な合意事項だけでも簡単な記録を残す習慣をつける。そして余裕があれば、開発会社側にも副窓口の存在を伝える。この順序で進めれば、本業を圧迫せずに、無理のない範囲でリスクを減らしていけます。

会社の規模が10人を超え、総務や情シスの役割を担う人が明確になってくると、この窓口の分散はより自然な形で定着していきます。逆に言えば、10人未満のこの段階で「窓口は社長ひとり」という状態に慣れきってしまうと、規模が拡大したあとも同じ構造が温存され、開発会社とのやり取りの質が組織の成長に追いつかなくなるリスクがあります。

まとめ

開発会社との窓口が社長ひとりに集中している状態は、10人未満の会社にとって自然な出発点です。問題は、この状態を「当面はこれでいい」と放置し続けることにあります。副窓口を1人決める、重要な合意事項を簡単に記録する、開発会社側にも共有しておく――この3つは、いずれも大きなコストや体制変更を必要とせず、今日からでも着手できる備えです。

窓口の分散は、社長の負担を減らすだけでなく、開発会社との関係そのものを安定させる効果もあります。社長が不在のときにプロジェクトが止まらない、合意事項が曖昧にならない、開発会社側も安心してやり取りを続けられる。こうした状態は、結果的に開発コストの無駄な増加や、トラブル時の交渉力の低下を防ぐことにもつながります。

10人未満という規模は、体制の変更コストが最も低いタイミングでもあります。従業員が数十人、数百人と増えてから窓口の分散に着手しようとすると、すでに定着した「社長に聞かないと分からない」という組織文化を変えるのに、相応の時間と労力がかかります。今、開発会社とのやり取りが社長ひとりに集中していると感じたら、まずは副窓口を1人思い浮かべることから始めてみてください。それだけで、この記事で紹介した備えの半分は、すでに動き出しています。自社の窓口体制がどの程度リスクを抱えているか気になる場合は、ひとり情シス危険度診断もあわせて活用してください。