社員が100人を超えたあたりから、情シスに届く外注の相談は「うちの部署のシステムを何とかしてほしい」という単発の依頼ではなくなっていきます。ある月には営業部から「顧客管理システムを刷新したい」という相談が来て、同じ月に製造部から「在庫管理をシステム化したい」という要望が上がり、さらに経理部が「請求書発行を自動化する外注先を探している」と言い出す。それぞれの部署は自分たちの困りごとしか見えていないため、他部署が同時に似たような相談を情シスに持ち込んでいることを知りません。結果として、情シス担当者だけが「今、社内で外注ニーズがどれだけ積み上がっているか」を唯一把握できる立場に置かれます。この状態で情シスが果たすべき役割は、単なる技術的な窓口ではなく、複数部署の要望を横から見て交通整理する調整役です。このガイドでは、その調整役としての立ち位置をどう作り、どう機能させるかを扱います。

この記事で分かること

複数部署から同時多発的に外注要望が寄せられる状況で、情シスが調整役としてどう振る舞い、どんな仕組みで要望を集約し、部署間の利害調整をどう進めるかを解説します。個々の外注案件についてRFPを作成し要件を固める具体的な手順は、事業拡大期の基幹システム発注、要件を複数部署から集める進め方に譲ります。また、集約した要望に対してどう予算を配分するかという金額面の判断は、100-300人規模の開発予算、複数プロジェクトを同時に抱えたときの配分で扱います。この記事は、その手前にある「そもそも要望をどう受け止め、誰がどう交通整理するか」という立ち位置の話に焦点を当てます。

  • 複数部署から要望が同時多発する背景にある構造的な理由
  • 情シスが担う「調整」と、部署長・経営層が担う「決定」の境界線
  • 要望を1か所に集約するための仕組みの作り方
  • 部署間で対立する要望が出たときの調整の進め方
  • 声が上がりにくい部署の要望をどう拾い上げるか
  • 経営層への定期報告を調整役としての信頼構築にどうつなげるか

なぜ調整役が必要になるのか

30〜100人規模のひとり情シスの時代は、外注の相談自体がそれほど頻繁ではなく、来たとしても順番に対応すれば済んでいました。100〜300人規模になると事情が変わります。部署の数そのものが増え、各部署に予算の裁量を持つ管理職が置かれるようになり、「外注してでも解決したい」という課題感を持つ部署が同時に複数存在する状態が常態化します。

この変化が生む問題は、単に忙しくなることだけではありません。部署ごとに独立して外注を進めようとすると、次のような弊害が起きやすくなります。

  • 複数の部署がそれぞれ別の開発会社に、実質的に似た機能(例えば案件管理や進捗共有)を別々に発注し、結果的に似たようなシステムが社内に並立する
  • ある部署の外注案件が、別の部署が管理しているデータや業務フローと連携する必要があるにもかかわらず、情シスを介さずに話が進んでしまい、後から連携不可能なことが判明する
  • 各部署が個別に開発会社とやり取りすることで、契約条件やSLA(サービス品質保証)の水準が部署ごとにバラバラになり、全社的な保守運用の負荷が上がる
  • 経営層から見て、外注にどれだけの予算が全社で動いているのか、誰も横断的に把握していない状態になる

これらの弊害は、部署の担当者が悪いわけではありません。それぞれの部署は自分たちの業務を良くしたいという正当な動機で動いているだけです。問題は、部署をまたいで全体を見渡す役割が組織内に存在しないことにあります。情シスがこの役割を引き受けることで、初めて全社的な整合性が保たれます。

調整役と「決定権者」は違う

調整役を担うにあたって最初に押さえておきたいのは、情シスが担うのは「調整」であって「決定」ではないという線引きです。この線引きを曖昧にすると、情シスが本来持っていない権限を行使しているように見え、部署間の摩擦を招きます。

具体的には、次のように役割を分けて考えると整理しやすくなります。

役割情シスが担うこと情シスが担わないこと
情報の集約どの部署がどんな外注ニーズを持っているかを一元的に把握する
論点の可視化部署間で重複・矛盾する要望がないかを洗い出し、関係者に示す
優先順位の「叩き台」提示業務影響やリスクをもとに、優先順位の案を提示する最終的な優先順位の決定
予算配分の判断各案件の概算費用感を整理し、比較できる形にする予算そのものの承認・決裁
経営層への報告全社の外注ニーズの状況を定期的に報告する経営判断そのもの

情シスの役割は、あくまで判断材料を整え、関係者が合意形成しやすい土俵を用意することです。最終的にどの案件を優先するか、どこまで予算をかけるかという決定は、部署長や経営層が担うべき領域として明確に切り分けておくことをお勧めします。この線引きを最初に関係者と共有しておくと、「情シスが勝手に順番を決めた」という不満を避けやすくなります。

「以前は、複数部署からの要望を私が個人的な感覚で順番付けしていました。ある部署の責任者から『なぜうちが後回しなのか、勝手に決めるな』と言われて初めて、自分がいつの間にか決定権者のように振る舞っていたことに気づきました。今は判断材料を出すところまでが自分の役割だと決めています」

この線引きは、一度決めて終わりではなく、事あるごとに関係者へ確認し直す必要があります。特に、情シスチームが実績を積み重ね、社内での発言力が増してくると、周囲から「情シスが決めてくれるだろう」という期待が自然と大きくなっていきます。この期待に応えようとして、いつの間にか調整の範囲を超えて決定そのものを担ってしまう、という変化は本人も気づきにくいものです。定期的に「自分たちは今、決定しているのか、材料を出しているだけなのか」を自問する習慣を持つことをお勧めします。

調整役に必要な最低限の業務知識

調整役を担ううえで、情シス担当者がどこまで各部署の業務を理解しておくべきかは、悩ましい論点です。深く理解しすぎようとすると時間が足りなくなる一方、業務への理解が浅すぎると、要望の背景にある本質的な課題を見誤るリスクがあります。

実務上のバランスとしては、次の水準を目安にすることをお勧めします。

  • 各部署の業務フローの大枠: どの部署が、どんな業務プロセスで、何を扱っているか(詳細な手順までは不要)
  • 部署間のデータのつながり: ある部署のアウトプットが、別の部署のインプットになっている関係性
  • 繁忙期・繁忙のタイミング: 各部署が忙しい時期を把握しておくと、ヒアリングや導入時期の調整がしやすくなる
  • 過去にトラブルになった経緯: 部署間で過去に対立があった案件や、失敗した導入事例があれば、その経緯

この水準の理解は、一度に集中して学ぶものというより、日々の要望対応やヒアリングを通じて少しずつ蓄積していくものです。特に、部署間のデータのつながりを把握しておくことは、要望が単発の依頼として見えても、実は複数部署に影響が及ぶ案件かどうかを見抜くための重要な手がかりになります。

要望を集約する仕組みを作る

調整役として機能するための最初のステップは、バラバラに届く要望を1か所に集約する仕組みを作ることです。口頭やチャットの個別メッセージで要望が届く状態のままでは、情シス担当者自身も全体像を把握しきれません。

集約の仕組みとして、最低限次の要素を備えた一覧を用意することをお勧めします。

  1. 要望元の部署と担当者: 誰が、どの部署の立場で要望しているか
  2. 要望の内容: 何を解決したいのか、簡潔な要約
  3. 現状の困りごと: 放置した場合にどんな業務影響が出ているか
  4. 要望が上がった日付: いつから要望として存在しているか
  5. 現在のステータス: 未着手・情報収集中・外注先選定中・進行中など

この一覧を、部署側からも参照できる状態にしておくと、「自分たちの要望が今どうなっているか分からない」という不満を防げます。一覧の運用は、システム管理台帳と同じ発想で、作って終わりにせず継続的に更新するものとして位置づけてください。

  • 新しい要望が来たら、必ずこの一覧に追記してから対応を検討する習慣をつける
  • 口頭で相談された要望も、後で必ず一覧に転記する(その場限りで終わらせない)
  • 一覧の更新を定例のタイミング(週次や月次)で見直す機会を設ける

部署間の利害がぶつかったときの調整の進め方

要望を集約すると、次に直面するのが部署間の利害の衝突です。よくあるのは、複数の部署が同じシステムや同じデータ領域に関わる要望を、それぞれ異なる優先度・異なる方向性で持ち込んでくるケースです。例えば、営業部は「顧客情報をもっと自由に編集できるようにしたい」と要望する一方、経理部は「顧客情報の変更履歴をすべて記録し、勝手な編集を防ぎたい」と正反対の方向性を求めていることがあります。

このような衝突が起きたとき、情シスが両部署の間に立って調整する際に有効な進め方は次のとおりです。

  1. 双方の要望の背景にある業務上の理由を、それぞれ個別にヒアリングする: 表面的な要望だけでなく、なぜその要望が必要なのかという業務上の事情を掘り下げる
  2. 対立点を整理し、両部署が同席する場で共有する: 情シスが一方の肩を持つのではなく、対立の構造そのものを可視化して見せる
  3. 両立できる案がないか、技術的な選択肢を提示する: 例えば「通常は自由に編集できるが、変更履歴は自動的に記録される」というように、双方の懸念を満たす設計上の折衷案がないか検討する
  4. どうしても両立できない場合は、業務上の優先度が高い側を経営層に判断してもらう: 情シス単独で片方に軍配を上げるのではなく、決定権者に材料を渡して判断を仰ぐ

この進め方のポイントは、情シスが「技術的に中立な立場」であることを一貫して保つことです。どちらかの部署の肩を持っていると受け取られると、以降の調整役としての信頼が損なわれます。

声が小さい部署を見落とさない

複数部署の要望を調整する際に陥りやすい落とし穴が、声が大きい部署の要望ばかりに目が向いてしまうことです。経営層に近い部署や、日常的に情シスとやり取りの多い部署の要望は自然と目に入りやすい一方、拠点が離れていたり、普段あまり情シスと接点のない部署の困りごとは、要望として上がってくること自体が少なくなりがちです。

  • 定期的に、各部署の管理職に「困っていることはないか」を情シス側から能動的に聞きに行く機会を設ける
  • 要望の集約一覧を眺めたときに、特定の部署からの要望がゼロであれば、それは「困っていない」のではなく「声を上げにくい」可能性を疑う
  • 拠点や部署をまたいで似たような業務課題がないか、あえて横断的に確認する

こうした能動的な聞き取りは、事業拡大期の基幹システム発注、要件を複数部署から集める進め方で扱う個別プロジェクトのヒアリングとは目的が異なります。ここでの聞き取りは、まだ具体的なプロジェクトとして形になっていない、潜在的な要望を拾い上げるためのものです。

能動的な聞き取りを行う際は、聞き方にも工夫が要ります。「困っていることはありますか」という漠然とした質問だけでは、相手も何を答えればよいか分からず、「特にないです」という表面的な回答で終わってしまうことが少なくありません。次のような、具体的な業務シーンを想定した聞き方のほうが、実質的な情報を引き出しやすくなります。

  • 「月次の締め作業で、時間がかかっている手作業はありますか」
  • 「他部署とのデータのやり取りで、二重入力や転記が発生している場面はありますか」
  • 「ここ半年で、システムが原因で困った・ヒヤリとした出来事はありますか」

こうした質問は、部署の担当者自身も普段「当たり前」だと思って意識していない業務上の負担を掘り起こすきっかけになります。声を上げにくい部署ほど、日常業務に忙殺されて「これは相談すべきことだ」という自覚を持てていないケースが多く、情シス側から具体的な問いを投げかけることが、要望の顕在化につながります。

調整役に求められる社内での信頼の積み重ね方

調整役としての立ち位置は、仕組みを整備しただけで自動的に確立するものではありません。各部署から「情シスに相談すれば、公平に扱ってもらえる」という信頼を積み重ねて初めて、調整役としての機能が実効性を持ちます。この信頼は、次のような日々の積み重ねによって育ちます。

  1. 約束した対応期限を守る: 「来月中に検討状況をお伝えします」と伝えたら、たとえ結論が出ていなくても、期限までに何らかの状況報告を行う
  2. 後回しにした理由を毎回言語化する: 「今回は難しい」で終わらせず、業務影響度・リスク・工数のどの観点で判断したかを具体的に伝える
  3. 一度出した判断を安易に覆さない: 声の大きい部署から後日圧力を受けても、当初の評価基準に基づいた判断を貫く(状況が変化した場合は、その変化を理由として明示したうえで見直す)
  4. 技術的な説明を、相手の業務言葉に翻訳して伝える: 専門用語をそのまま使わず、相手の部署の業務に置き換えて説明する

これらは特別なテクニックというよりも、地道な積み重ねです。しかし、複数部署が関わる調整役という立場では、一度でも「あの部署だけ優遇されている」という印象を持たれると、その後の調整が一気に難しくなります。逆に、公平さへの信頼が蓄積されていれば、多少厳しい優先順位の判断を伝えても、部署側が受け入れやすくなります。

よくある失敗パターンとその回避策

複数部署の調整役を担う中で、情シス担当者が陥りやすい失敗パターンがいくつかあります。あらかじめ知っておくことで、同じ轍を踏むリスクを減らせます。

失敗パターン1: 声を上げた部署から順に「なんとなく」着手してしまう

明確な評価基準を持たないまま対応を始めると、結果的に声を上げた順、あるいは付き合いの長い部署の順に着手することになりがちです。これは本人に悪意がなくても、周囲からは「えこひいき」に見えてしまいます。評価軸を事前に定め、要望が来るたびに機械的にでも当てはめる習慣が、この失敗を防ぎます。

失敗パターン2: 調整の経緯を記録に残さず、口頭のやり取りで済ませてしまう

部署間で対立があった案件ほど、後から「言った・言わない」の水掛け論になりやすいものです。ヒアリングの内容、対立点、合意に至った経緯は、簡潔でよいので必ず文字として残しておくことをお勧めします。議事録やチャットのログとして残すだけでも、後日の説明責任を果たしやすくなります。

失敗パターン3: 自分がすべての部署の業務を完全に理解しようとしてしまう

情シス担当者は技術の専門家であって、各部署の業務の専門家ではありません。すべての部署の業務を深く理解しようと抱え込みすぎると、時間がいくらあっても足りなくなります。業務の詳細は各部署の担当者から都度ヒアリングする前提で、情シス側は「業務影響を評価するための最低限の理解」にとどめる割り切りも必要です。

経営層への定期報告を調整役の武器にする

調整役としての立ち位置を安定させるうえで効果的なのが、経営層に対する定期的な状況報告です。個別の要望が来るたびに都度報告するのではなく、一定の周期(月次や四半期)で、全社的な外注ニーズの状況をまとめて報告する場を持つことをお勧めします。

報告に含めるとよい要素は次のとおりです。

  • 現在集約している要望の総数と、部署別の内訳
  • 対応済み・進行中・未着手の件数と、それぞれの概況
  • 部署間で調整が必要になった案件と、その調整結果
  • 情シス側のリソースで対応しきれていない領域(外部委託や増員が必要な可能性がある箇所)

この定期報告があることで、経営層は「情シスが場当たり的に対応している」のではなく「全社の外注ニーズを横断的に管理している」という認識を持ちやすくなります。結果として、優先順位の判断や予算の承認を求めた際にも、報告の積み重ねが説得材料として機能します。予算配分の交渉における考え方は、100-300人規模の開発予算、複数プロジェクトを同時に抱えたときの配分で詳しく扱っています。

報告の頻度や粒度は、会社の規模や経営層の関心度に応じて調整してください。月次で細かく報告することを好む経営層もあれば、四半期に一度、要点だけをまとめた報告を好む経営層もあります。重要なのは頻度そのものよりも、「情シスに聞けば、今の全社的な外注状況がいつでも把握できる」という安心感を経営層に持ってもらうことです。この安心感があると、個別の案件について経営層から不意に質問された際にも、慌てず即座に状況を答えられるようになり、結果として情シスチームへの信頼がさらに積み上がっていきます。

報告資料の作成自体も、毎回ゼロから作るのではなく、要望の集約一覧をベースに、必要な項目を抜き出して整形する仕組みにしておくと、報告作業自体が過度な負担にならずに済みます。集約の仕組みと報告の仕組みを別々に運用すると、同じ情報を二重に入力する手間が発生しやすいため、可能な限り同じデータソースから両方を生成できる形を目指すことをお勧めします。

調整役を1人で抱え込まない

情シスチームが複数人体制になっている場合、調整役の機能を特定の1人だけに担わせるのは避けたほうがよい運用です。調整役の担当者が休職・異動・退職した場合、集約の仕組みそのものが機能を失うリスクがあるためです。

  • 要望の集約一覧は、担当者個人のPCやメモではなく、チーム全員がアクセスできる場所で管理する
  • 部署との調整のやり取りも、可能な限り議事録やチャットログとして残し、特定の担当者の頭の中だけに情報が閉じないようにする
  • 定期報告の作成・実施は、複数人でローテーションできる体制を検討する

調整役という機能自体をチームの資産として位置づけることが、属人化を防ぐ最も現実的な方法です。

拠点が複数ある場合の調整の難しさ

事業拡大期の会社では、部署だけでなく拠点そのものが複数に分かれているケースも珍しくありません。本社の他に支社や工場、店舗といった拠点があると、調整役としての難易度はさらに上がります。同じ「営業部」という括りであっても、本社の営業部と地方拠点の営業部とでは、業務フローや使っているツールが微妙に異なっていることがあり、要望を集約する際にこの違いを見落とすと、片方の拠点だけに最適化された要件でシステムを発注してしまうリスクがあります。

拠点をまたぐ調整では、次の点に特に注意してください。

  • 本社の声だけを「全社の声」として扱わない: 本社に情シスの拠点があると、物理的に距離のある拠点からの要望は届きにくくなる。定期的なオンラインでのヒアリングなど、距離のハンデを埋める仕組みを意識的に作る
  • 拠点ごとの業務フローの違いを前提にヒアリングする: 同じ部署名でも、拠点によって実際の業務手順が異なる場合があることを踏まえ、「本社と同じですか」と一括りに確認するのではなく、拠点ごとに個別の実態を確認する
  • 拠点間の要望の違いが、拠点特有の事情によるものか、単なる好みの違いかを見極める: 例えば法令や条例が拠点の所在地によって異なる場合(labor law上の扱いや、業種によっては都道府県ごとの規制など)は、業務上の必然性として扱う必要がある

複数拠点にシステムが散らばる問題そのものへの対処は、拠点ごとの資産や契約の整理という別の切り口からも扱う価値のあるテーマです。調整役としての役割は、あくまで「拠点をまたいだ要望の声を正しく拾い、公平に扱う」という部分に集中し、拠点ごとの資産管理の詳細は別途整理することをお勧めします。

調整役としての立場を経営層に理解してもらう

情シスが調整役という機能を担っていること自体、経営層や各部署の管理職に明示的に理解されていないケースは意外と多くあります。「情シスは頼めばシステムを作ってくれる部署」という認識に留まっていると、調整役としての判断(例えば、ある部署の要望を後回しにするという判断)が、単なる情シスの都合や能力不足と誤解されてしまうことがあります。

この誤解を防ぐためには、情シスが調整役としての機能を担っていること自体を、組織として明文化しておくことが有効です。具体的には、次のような取り組みが考えられます。

  • 情シスの役割・業務範囲を示す文書(業務分掌や部署紹介の資料など)に、「複数部署からの外注要望の集約・調整」という機能を明記する
  • 新任の管理職向けのオリエンテーションなどの機会に、外注要望はまず情シスに相談してほしいという窓口の一本化を周知する
  • 経営会議などの場で、調整役としての活動内容(要望の集約状況、調整の実績など)を定期的に共有し、役割の存在を可視化する

こうした明文化と周知は、地味な作業に見えますが、調整役としての正当性を組織の中で確立するための土台になります。個々の担当者の人柄や実績だけに頼った調整役では、担当者が変わるたびに一から信頼を築き直す必要が生じます。組織としての役割として位置づけておくことで、担当者が交代しても機能が引き継がれやすくなります。

まとめ: 調整役は「板挟み」ではなく「翻訳者」

複数部署から同時に外注要望が届く状況で、情シスが担うべき役割は、部署間の板挟みになって疲弊することではありません。それぞれの部署が持つ業務上の事情を正確に理解し、他部署や経営層に分かる形で翻訳し、判断材料として提示する「翻訳者」としての役割です。

要望を集約する仕組みを整え、決定権者との線引きを明確にし、声の小さい部署にも目を配り、経営層への定期報告を積み重ねる。この一連の動きが、情シスを単なる技術窓口から、全社の外注活動を俯瞰する調整役へと押し上げます。100〜300人規模でこの立ち位置を確立できるかどうかは、その後さらに組織が拡大したときに、情シスが場当たり的な対応に追われ続けるか、戦略的な役割を担えるかを大きく左右します。

調整役としての機能は、一度確立すれば自動的に維持されるものではなく、日々の要望対応・ヒアリング・報告の積み重ねによって、少しずつ強化されていくものです。焦らず、目の前の要望一つひとつに誠実に向き合いながら、集約と可視化という基本の仕組みを地道に運用し続けることが、結果的に最も確実な道になります。個々のプロジェクトの進め方や予算配分の判断は、この調整役としての土台があって初めて、納得感を持って実行できるようになります。

複数部署から要望が同時に押し寄せる状況は、情シスにとって負荷の高い局面である一方、組織全体を横断的に見渡せる稀少な立場でもあります。この立場を、単なる負担としてではなく、全社的な信頼を積み上げる機会として捉え直すことができれば、情シスチームは調整役としての役割を通じて、組織にとって欠かせない存在へと成長していきます。焦って全てを一度に解決しようとせず、一つひとつの要望への向き合い方を積み重ねていく姿勢こそが、長い目で見て最も確実に信頼を築く道筋になります。