兼任が2〜3人に増えたときの担当分担、誰が何を持つかの決め方

ひとり情シスに2人目、あるいは3人目のメンバーが加わるタイミングは、社員数100〜300人規模の会社にとって重要な転換点です。しかし、この移行は単純に「人が増えて楽になる」というだけの変化ではありません。むしろ、担当範囲を明確に切り分けないまま人数だけを増やすと、同じ作業を複数人が重複して行う無駄が生まれる一方で、誰も担当していない業務の隙間が新たに生まれるという、皮肉な事態を招きます。ひとりで回していた頃は、少なくとも「担当が誰か分からない」という問題は存在しませんでした。全部自分の担当だったからです。複数人体制になった瞬間から、この明快さが失われます。このガイドでは、2〜3人体制に移行する際の担当分担を、どのような軸で、どのように決めていけばよいかを具体的に解説します。

なぜ「なんとなくの分担」がうまくいかないのか

多くの会社では、2人目のメンバーが加わる際、明確な基準を設けないまま「とりあえずこっちを担当してもらおう」という形で分担が決まりがちです。この「なんとなくの分担」は、短期的には機能しているように見えても、時間が経つにつれて次のような問題を引き起こします。

まず、責任の所在が曖昧なシステムが必ず生まれます。既存のひとり情シスがすべてのシステムを把握していた状態から、業務を分割する過程で、「これはどちらが担当するのか」が明確に定義されないまま宙に浮くシステムが出てきます。トラブルが起きたときに、両者が「相手が担当だと思っていた」と食い違う事態は、この曖昧さが原因です。

次に、業務量の偏りが是正されにくくなります。感覚的な分担では、声の大きい方や、最初に手を挙げた方に業務が偏りやすく、後から不公平感が生まれる原因になります。明確な基準がないまま分担を進めると、後になって「なぜこの分け方になったのか」を説明できず、調整も難しくなります。加えて、基準のない分担は、後から新しいメンバーが加わった際の説明もしづらくなります。「なぜこの分け方なのか」を言語化できていないと、新メンバーへの引き継ぎもその都度場当たり的になってしまいます。

分担の軸は「システム別」か「業務別」かをまず決める

担当分担を設計する際、最初に決めるべきは分担の「軸」です。主に2つの軸があり、どちらを採用するかで、その後の分担表の構造が大きく変わります。

どちらか一方だけを選ぶ必要はなく、実際には多くの会社が両方を組み合わせています。例えば、基幹システムのような重要度の高いものはシステム別に固定担当を置きつつ、日常のヘルプデスク対応は業務別にローテーションで回す、といった形です。重要なのは、分担表を作る前に「この会社にはどちらの軸がより実態に合っているか」を一度立ち止まって考えることです。

システム別分担表の作り方

システム別に分担する場合、まずは台帳に載っている全システムを一覧化するところから始めます。台帳の運用設計については100人を超えたら属人化台帳をどう運用に乗せるかで扱っていますが、分担表を作る前提として、まず「何を分担すべきか」の全体像が正確に把握できている必要があります。

システムを一覧化したら、次の観点で分担を割り振っていきます。

1. 利用部署との親和性: 経理システムなら経理業務に理解のあるメンバー、営業支援システムなら営業部門とのコミュニケーションが得意なメンバー、というように、システムの利用実態に近い経験を持つ人に寄せる
2. 技術的な専門性: クラウドインフラに強いメンバー、ネットワーク機器に強いメンバーなど、個人のバックグラウンドに応じて技術要素の強いシステムを割り振る
3. 業務量のバランス: 単純にシステムの数で均等に割るのではなく、問い合わせ頻度やトラブル発生頻度を加味して、実質的な負荷が偏らないよう調整する

分担表には、単に「誰が担当か」だけでなく、「主担当」と「副担当（バックアップ）」の両方を明記することを強くお勧めします。主担当が不在の際にも対応できる体制を最初から組み込んでおくことで、特定の1人にしか対応できないシステムが生まれることを防げます。この副担当の仕組みは、後述する「単一障害点」の考え方とも関係します。特に情シスチームが2人しかいない段階では、お互いが唯一の副担当になるため、両者の連携がそのままチームの可用性を左右することになります。3人目が加わることで初めて、副担当をローテーションできる余地が生まれ、特定の2人だけに負担が集中する構造から脱却できます。

業務別分担表の作り方

業務別に分担する場合は、情シスが担う業務プロセスをまず洗い出すところから始めます。典型的には、次のような業務カテゴリに分けられます。

• アカウント・権限管理: 入退社時のアカウント発行・削除、権限付与の申請対応
• ヘルプデスク: 日常的な問い合わせ、トラブルシューティングの一次対応
• セキュリティ: パッチ適用、セキュリティインシデントへの対応、社内ルールの策定
• 契約・調達: SaaSの契約更新、新規導入の稟議対応、ベンダーとのやり取り
• インフラ運用: サーバー・ネットワークの保守、バックアップの確認

これらの業務カテゴリを、2〜3人のメンバーに割り振ります。業務別分担の利点は、利用者から見た問い合わせ窓口が明確になることです。「アカウントのことならAさん」「パソコンの調子が悪いことならBさん」というように、社内での認知が定着しやすくなります。この認知の定着は、問い合わせ対応の初動を早める効果もあり、利用者が「誰に聞けばよいか分からず結局放置する」という状態を防ぐことにもつながります。

一方で、業務別分担には注意点もあります。業務プロセスは互いに独立していないことが多く、例えば「入退社時のアカウント削除」はアカウント管理の担当者だけでなく、セキュリティ担当者の関与も必要になる場合があります。分担表を作る際は、業務ごとの主担当を決めると同時に、複数の担当者にまたがる業務については、誰が最終的な意思決定者になるかも明記しておくとよいでしょう。

分担表に必ず含めるべき「エスカレーション先」

システム別・業務別どちらの分担表を採用する場合でも、共通して含めるべき項目が「エスカレーション先」です。担当者本人の手に負えない問題が発生した際、次に誰に相談すべきかを明記しておきます。

「対応可能な曜日・時間帯」は、兼任メンバーが多い100〜300人規模の会社では特に重要な項目です。専任の情シス担当者が1人もいない、あるいは1人しかいない状態から複数人体制に移行する過程では、多くの場合、新しく加わるメンバーも他の業務と兼任していることが少なくありません。それぞれの本来業務との兼ね合いで、対応できる時間に制約があることを分担表上で可視化しておくと、利用者側の期待値調整にも役立ちます。対応可能時間が限られていることを隠さずオープンにしておくことは、利用者からの過度な期待を防ぎ、結果としてメンバー自身の負担軽減にもつながります。

分担の見直しタイミングをあらかじめ決めておく

一度決めた分担表は、固定的なものとして扱うのではなく、定期的に見直す前提で運用してください。業務量の偏りは、実際に運用してみないと見えてこない部分が多く、最初の設計が完璧であることは稀です。分担を決めた直後は、あくまで仮の割り振りだと捉え、数ヶ月の運用実績を経てから初めて「実態に合った分担」へと調整していく、という前提で臨むことをお勧めします。

見直しのタイミングとしては、次のような契機が考えられます。

• 半期に1回など、定期的な見直しのタイミングを決めておく
• 新しいシステムを導入したとき、既存の分担にどう組み込むかを都度検討する
• メンバーの異動・退職があったとき、残ったメンバーで分担を再設計する
• 特定のメンバーへの業務集中が明らかになったとき、臨時で調整する

見直しの際は、単に「誰の負荷が高いか」という感覚的な判断だけでなく、可能であれば問い合わせ件数やトラブル対応時間などの記録を参考にすると、より客観的な調整ができます。記録の残し方については、日々の業務を可視化する仕組みづくりとも関係しており、チーム内の「聞けば分かる」を「見れば分かる」に変える情報共有の仕組みで扱う内容とも重なります。

見直しの結果、分担を変更する場合は、変更のタイミングにも配慮が必要です。年度の途中で突然分担を組み替えると、利用者側の混乱を招くだけでなく、引き継ぎの準備が不十分なまま切り替わってしまうリスクもあります。可能であれば、期初など区切りの良いタイミングに合わせて変更を実施し、変更前には関係者への周知期間を設けることをお勧めします。

分担が固定化しすぎることのリスクにも注意する

担当分担を明確にすることは重要ですが、一度決めた分担を固定化しすぎることには別のリスクがあります。特定のシステムを1人だけが長期間担当し続けると、結局そのシステムに関しては再び「その人しか分からない」という、複数人体制に移行する前と同じ属人化の構造が、個人単位ではなくシステム単位で再現されてしまいます。

これを防ぐためには、主担当と副担当を固定するだけでなく、定期的に担当を入れ替える、あるいは副担当が実際に一次対応を経験する機会を意図的に作るといった工夫が有効です。すべてのシステムについて全員が同じ深さで理解している必要はありませんが、「主担当が長期不在になっても、最低限の初動対応は副担当ができる」水準を維持することが、分担表を機能させ続けるための最低条件です。

副担当が実際の対応を経験する機会としては、主担当が休暇を取る前に、あえて簡単な作業を副担当に任せてみる、あるいは月に一度、主担当と副担当が一緒にそのシステムの状態を確認する時間を設ける、といった小さな積み重ねが有効です。大掛かりな引き継ぎ研修を実施するよりも、日常業務の中に自然に組み込むほうが、負担なく継続できます。

「最初はAさんが会計システム、私が営業支援システムという分け方で始めましたが、半年経って見直したときに、実はヘルプデスクの問い合わせ対応に時間が偏っていることが分かり、そこだけ業務別の分担に切り替えました。システム別と業務別、どちらかに固執せず、実態に合わせて柔軟に組み合わせるのがコツだと思います」

このように、最初に決めた分担の型に固執せず、実際の業務量や問い合わせの傾向を見ながら柔軟に組み替えていく姿勢が、2〜3人体制を軌道に乗せる上での重要な心構えです。分担表は一度で完成させるものではなく、チームの実態に合わせて育てていくものだと捉えてください。

分担表と引き継ぎ書・台帳の関係

担当分担表は、単独で存在するものではなく、台帳や引き継ぎ書と密接に連動させることで初めて機能します。台帳の「システムオーナー」欄、引き継ぎ書の更新責任者、そして分担表の「主担当」は、基本的に同じ人物を指すように整合性を保っておくことをお勧めします。これらがバラバラに管理されていると、どの資料を見れば正しい情報にたどり着けるのか分からなくなり、結局形骸化していきます。

引き継ぎ書のフォーマット統一についてはチーム化する情シスの引き継ぎ書、個人の作業メモから組織のドキュメントへで、台帳の運用設計については100人を超えたら属人化台帳をどう運用に乗せるかで、それぞれ詳しく解説しています。分担表・台帳・引き継ぎ書の3つを一体として設計することで、複数人体制への移行が初めて実効性を持ちます。

分担決定のプロセス: トップダウンかボトムアップか

担当分担をどのように決めるかというプロセス自体も、後々の運用のしやすさに影響します。大きく分けて、経営層やマネージャーが分担を決定するトップダウン型と、メンバー同士の話し合いで決めるボトムアップ型の2つのアプローチがあります。

トップダウン型は、意思決定が速く、責任の所在も明確になりやすい利点があります。一方で、現場の実情を十分に反映できず、後から「実際にやってみると想定と違った」というミスマッチが生じやすい面もあります。ボトムアップ型は、メンバー自身が納得感を持って分担に取り組める利点がありますが、話し合いが長引いたり、声の大きい人の意見に偏ったりするリスクもあります。

現実的には、両者を組み合わせたハイブリッド型が機能しやすいことが多いです。まず経営層やマネージャーが大まかな方向性（システム別か業務別か、それぞれの領域の粒度など)を示した上で、具体的にどのメンバーがどの領域を担当するかは、メンバー間の話し合いで決める、という進め方です。この場合、最終的な分担案について、マネージャーが承認するプロセスを設けておくと、決定の透明性と納得感の両方を確保しやすくなります。

分担決定時に考慮すべきメンバーの経験・志向

分担を決める際、単純にシステムの数や業務量だけで機械的に割り振るのではなく、メンバー個々の経験やキャリアの志向性も考慮に入れることをお勧めします。例えば、将来的にセキュリティ分野を専門にしていきたいと考えているメンバーがいれば、セキュリティ関連の業務を優先的に割り振ることで、本人のモチベーション向上にもつながります。

逆に、特定の分野に強い苦手意識を持つメンバーに、その分野の業務を無理に割り振ると、パフォーマンスの低下だけでなく、離職のリスクにもつながりかねません。分担を決める際は、業務の効率性だけでなく、メンバーの中長期的なキャリア形成という視点も加味して検討することが、持続可能なチーム運営につながります。

• 得意分野を伸ばす配分: 既に強みを持つ領域をさらに深めてもらうことで、チーム全体の専門性を底上げする
• 育成目的の配分: あえて未経験の領域を担当してもらい、成長の機会とする（ただしバックアップ体制を厚めにする配慮が必要）
• 本人の希望を聞く機会を設ける: 定期的な1on1などで、担当領域についての希望や不満を聞き取る場を設ける

トラブル発生時の指揮系統を分担表に組み込む

平常時の担当分担がうまく機能していても、大規模なトラブルが発生した際には、通常の分担の枠を超えた対応が必要になることがあります。例えば、基幹システムの障害で複数の業務が同時に止まってしまった場合、担当者1人だけでは対応しきれず、チーム全員が協力して対応にあたる必要が出てきます。

このような緊急時に備えて、分担表とは別に、トラブルの規模に応じた指揮系統を事前に定めておくことをお勧めします。

このような段階的な対応体制をあらかじめ決めておくことで、実際にトラブルが発生した際に「誰が指揮を執るのか」で時間を浪費することなく、迅速に初動対応へ移れます。特に、大規模なトラブルが発生した際の連絡フロー（誰が誰に、どの順番で連絡するか）は、実際の緊急時にはパニックに陥りやすいため、事前に紙やドキュメントの形で明文化しておくことが重要です。

分担表を社内に周知する方法

分担表は、情シスチーム内だけで共有していても十分ではありません。利用者である一般社員が「誰に何を相談すればよいか」を知らなければ、結局特定の1人にだけ問い合わせが集中してしまい、せっかく分担した意味が薄れてしまいます。分担表を社内に周知する際は、次のような工夫が有効です。

• 問い合わせ窓口の一本化と裏側での振り分け: 利用者からの問い合わせは、まず共通の窓口（チャットツールの特定チャンネルや、共通の問い合わせフォームなど）に集約し、そこから担当者へ振り分ける運用にすることで、利用者が分担の詳細を覚えていなくても迷わず相談できる
• 社内ポータルや掲示での明示: 「アカウントのことはAさん、パソコントラブルはBさん」といった簡易的な一覧を、社内ポータルや共有スペースに掲示し、いつでも確認できるようにする
• 入社時のオリエンテーションでの案内: 新入社員向けの説明資料に、情シスへの相談窓口と大まかな分担を含めておく

特に「問い合わせ窓口の一本化」は、100〜300人規模の会社で特に効果的な手法です。利用者にとっては、誰が担当かを覚える負担がなくなり、情シス側にとっても、問い合わせの一元管理によって対応漏れを防ぎやすくなるという、双方にメリットのある仕組みです。

兼任メンバーの本来業務との両立を前提にした設計

100〜300人規模の会社では、情シス業務を専任で担うメンバーがまだ少なく、総務や経理などの本来業務と兼任しているケースが多く見られます。分担表を設計する際は、この兼任という制約を無視した理想論ではなく、実際に確保できる時間を前提にした現実的な設計にすることが重要です。

兼任メンバーの負荷を考慮する際は、次のような観点でバランスを取ることをお勧めします。

1. 本来業務の繁忙期を避けた分担: 経理担当者が兼任している場合、決算期など本来業務が忙しい時期には、情シス業務の負荷を軽くする調整を検討する
2. 緊急対応と計画的対応を区別する: 緊急性の低い業務(棚卸しやドキュメント整備など)は、兼任メンバーの手が空いているタイミングにまとめて対応してもらう一方、緊急性の高いトラブル対応は優先的に時間を確保できる体制にしておく
3. 専任化のタイミングを見極める: 兼任のままでは業務量が限界に達しつつある場合、専任化を検討するタイミングの判断材料として、分担表上の負荷の偏りを活用する

兼任メンバーが疲弊してしまうと、結局その人が離脱し、また属人化状態に逆戻りしてしまうという悪循環を招きかねません。分担表は、単に業務を割り振るための道具ではなく、メンバーが無理なく持続的に業務を続けられる状態を維持するための調整ツールでもあると捉えてください。

分担にまつわるよくある質問

Q. 分担を決めても、結局特定の人に問い合わせが集中してしまいます。どう対処すればよいですか。

分担表を作っただけでは、利用者側の行動はすぐには変わりません。前述の「問い合わせ窓口の一本化」を導入し、利用者が個人を指名して連絡する経路自体を減らす工夫が有効です。また、特定の人に問い合わせが集中する背景には、その人が「一番早く対応してくれる」「一番親切に教えてくれる」といった実績への信頼がある場合も多く、これは悪いことではありません。ただし、その人が不在になったときに業務が回らなくなる状態は避けるべきなので、対応品質を他のメンバーにも波及させる工夫（対応マニュアルの共有、同席での対応など）を並行して進めてください。

Q. 2人体制から3人体制に増える際、既存の分担をどう調整すればよいですか。

新しいメンバーが加わる際は、既存の分担をゼロから見直すのではなく、まず新メンバーに任せる領域を明確に切り出すところから始めるのが現実的です。多くの場合、既存メンバーの負荷が最も高かった領域、あるいは新メンバーの経験が活かせる領域を、優先的に切り出すとよいでしょう。全体の再設計は、新メンバーがある程度業務に慣れた段階（3〜6ヶ月後など）で改めて実施することをお勧めします。新メンバーがまだ引き継ぎ書や台帳に十分に慣れていない初期の数ヶ月は、既存メンバーが並走してサポートできる体制を組んでおくと、立ち上がりがスムーズになります。

Q. システム別分担と業務別分担、どちらから始めるべきですか。

会社の業務特性によりますが、迷った場合はシステム別分担から始めることをお勧めします。システム別のほうが担当範囲の境界が明確で、責任の所在も分かりやすいためです。運用してみて、日常のヘルプデスク対応など横断的な業務の負荷が特に高いと分かった段階で、その部分だけを業務別の分担に切り替えるという、部分的な組み合わせ方が現実的な進め方です。

Q. 外部の開発会社やベンダーとの窓口も、分担表に含めるべきですか。

含めることをお勧めします。ベンダーとのやり取りは、システムのトラブル対応と密接に関わるため、どのベンダーの窓口を誰が担当しているかを分担表に明記しておくことで、トラブル発生時のエスカレーションがスムーズになります。特に、担当者が変わった際にベンダー側への連絡が漏れると、過去の経緯を一から説明し直す手間が発生するため、ベンダーとの窓口情報は台帳・分担表の両方で一貫して管理しておくことが望ましいです。

まとめ: 分担の目的は「隙間を作らないこと」

2〜3人体制への移行における担当分担の最大の目的は、業務を均等に割ることそのものではなく、「誰も担当していない隙間」を作らないことにあります。システム別・業務別いずれの軸を選ぶにせよ、すべての領域に主担当と副担当を明示し、エスカレーション先まで含めて可視化することで、この隙間を防げます。

分担表は一度作って終わりではなく、実際の運用を通じて見えてくる偏りに応じて調整し続けるものです。完璧な分担を最初から目指すのではなく、まずは「誰が何を持つか」を言語化するところから始め、半年ごとの見直しを通じて実態に合った形へ育てていってください。

分担の仕組みが整っていくにつれて、チームは単なる「ひとり情シスの延長」ではなく、それぞれが専門性と責任範囲を持つ「チーム」として機能し始めます。100〜300人という規模の会社にとって、この分担の設計こそが、ひとり体制からチーム体制への移行を実質的に成立させる、最も土台となる仕組みだといえます。分担表という一枚のドキュメントが、実際には「誰が何に責任を持ち、いざというときに誰に頼れるか」というチームの信頼関係そのものを言語化したものであると考えれば、その整備にかける時間は決して無駄にはなりません。