「増員が決まったので、来月から新しいメンバーが入ります」。この一報が来たとき、多くのひとり情シス担当者は喜びと同時に、漠然とした不安を抱きます。何を渡し、何を自分が持ち続けるのか。相手にどこまで任せられるのか。そもそも、増員が決まってから考え始めて間に合うのか。実際のところ、この不安の多くは「増員が決まってから体制設計を始める」という順序そのものに原因があります。100〜300人規模で複数人体制への移行を経験した会社の多くは、増員のタイミングよりも前に、業務の切り分け方を検討する助走期間を持っています。このガイドでは、増員が視野に入った段階から、実際に複数人体制が回り始めるまでの一連のプロセスを、時系列に沿って整理します。単発の分担決めではなく、「体制が変わり続けることを前提にした設計」として読んでください。

なぜ「増員が決まってから」では遅いのか

ひとり情シス担当者にとって、増員は基本的に歓迎すべき出来事です。しかし、増員の決定と同時に業務の切り分けを始めようとすると、次のような問題に直面しがちです。

  • 新しいメンバーの入社日までに、業務の全体像を整理する時間が足りない
  • 「とりあえずこれをお願いします」という場当たり的な割り振りになり、後から手戻りが発生する
  • 引き継ぎ資料が存在しないため、口頭説明に依存した引き継ぎになり、新メンバーの立ち上がりが遅れる
  • 既存担当者自身も、自分がどの業務にどれだけの時間を使っているか把握していないため、切り分けの基準を持てない

これらの問題の根本には、「ひとりで回している間は、業務を言語化する必要がなかった」という事情があります。全部自分の頭の中で完結していたため、わざわざ文書化する動機がありませんでした。トラブルが起きればその場で対応し、終わればまた次の業務に移る。この繰り返しの中では、「なぜこの手順で対応しているのか」「どの判断基準で優先順位を決めているのか」を言葉にする機会は、ほとんど訪れません。

しかし、複数人体制への移行を成功させている会社を見ると、共通して「増員の打診が出た時点」、あるいは「増員を要求する稟議を書く時点」から、並行して準備を始めています。増員が正式決定してから動き出すのと、検討段階から助走を始めるのとでは、入社日を迎えたときの引き継ぎ資料の完成度が大きく異なります。

「増員が正式に決まってから動き出すと、入社日までの数週間で全部を整理しようとして無理が出ます。私たちは増員の話が出た時点で、まず自分の業務を棚卸しする作業だけ先に始めました。実際に人が決まるまでの間、じっくり整理できたのが結果的によかったです」

この体験談が示す通り、増員が「決定した」タイミングと、増員を「検討し始めた」タイミングの間には、多くの場合数週間から数ヶ月の猶予があります。この猶予期間をただ待つのではなく、準備に充てられるかどうかが、移行の成否を分けます。

移行プロセス全体の時系列

複数人体制への移行は、大きく4つのフェーズに分けて捉えると、抜け漏れを防ぎやすくなります。それぞれのフェーズでやるべきことを整理します。

フェーズタイミングやるべきこと
① 助走期増員の打診・検討段階自分の業務を棚卸しし、切り分け可能な単位に分解する
② 準備期増員が正式決定してから入社まで引き継ぎ資料の骨子を作り、分担の初期案を固める
③ 移行期新メンバー入社直後〜数ヶ月OJTと並行しながら実際に業務を渡し、分担を微調整する
④ 定着期体制が一巡した後分担の見直しサイクルを確立し、属人化の再発を防ぐ

それぞれのフェーズについて、具体的に見ていきます。

フェーズ①: 助走期にやるべき業務の棚卸し

増員の話が具体化する前、あるいは検討中の段階でも、着手できる準備があります。それが自分自身の業務の棚卸しです。ひとりで回している業務を、次の3つの軸で分解してみてください。

  1. 定型業務か非定型業務か: 毎月・毎週決まった手順で発生する業務(請求書の確認、定例レポートの作成など)と、その都度判断が必要な非定型業務(トラブル対応、新規導入の検討など)を分ける
  2. 専門性が必要か、手順化すれば誰でもできるか: 特定の技術知識がなければ対応できない業務と、手順書さえあれば経験の浅いメンバーでも対応できる業務を分ける
  3. 利用者との接点があるか、裏方の作業か: 社員からの問い合わせに直接対応する業務と、社員から見えないところで完結する保守・運用作業を分ける

この棚卸しを行うと、「新しいメンバーにまず任せやすい業務」の輪郭が見えてきます。一般的には、定型業務かつ手順化しやすく、利用者との接点が明確な業務(典型的にはヘルプデスクの一次対応)が、最初に渡しやすい業務になります。逆に、非定型で専門性が高く、裏方で完結する業務(基幹システムの保守など)は、経験を積んでから任せる後回しの候補になります。

棚卸しの結果は、簡易的な一覧表にまとめておくと、次のフェーズで役立ちます。業務名・頻度・所要時間・必要なスキル・引き継ぎやすさの5項目程度で十分です。完璧な資料を作る必要はなく、「後で自分と相手が見返せる」水準であれば構いません。

この段階で見落とされがちなのが、「自分では意識していない、時間を取られている業務」の存在です。日々のメール処理、社内チャットでのちょっとした相談対応、他部署から口頭で依頼される小さな作業など、業務一覧には載らないものの、積み重なると相当な時間を占めている項目があります。1〜2週間、業務時間の使い方をメモしてみるだけでも、こうした「見えない業務」の輪郭が浮かび上がってきます。棚卸しの精度は、後の分担設計の精度に直結するため、この段階で手を抜かないことが、結果的に移行全体の負荷を下げます。

フェーズ②: 準備期に固める分担の初期案

増員が正式に決まったら、助走期に作った棚卸し結果をもとに、分担の初期案を作成します。ここで重要なのは、「最初から完璧な分担を決めようとしない」ことです。実際に一緒に働いてみないと分からない相性や適性があるため、初期案はあくまで仮の割り振りとして扱ってください。

分担の軸には、大きく分けて「システム単位」と「業務プロセス単位」の2通りがあります。どちらを主軸にするかは会社の実情によって異なりますが、100〜300人規模でチーム化を進める際の分担の決め方そのものについては、兼任が2〜3人に増えたときの担当分担、誰が何を持つかの決め方で詳しく扱っているので、あわせて参照してください。このガイドでは、分担の中身そのものよりも、分担を決めるまでの準備プロセスに焦点を当てます。

準備期に並行して進めるべきなのが、引き継ぎ資料の骨子作りです。すべてを完成させる必要はありませんが、少なくとも次の情報は、新メンバーの入社日までに用意しておくことをお勧めします。

  • 日常的に発生する問い合わせのパターンと、その対応手順
  • 定期的に発生する作業(パッチ適用、バックアップ確認など)のスケジュールと手順
  • トラブル発生時にまず確認すべきチェックポイント
  • 対応できない場合のエスカレーション先(外部ベンダー、上長など)

引き継ぎ資料の本格的なフォーマット統一は、複数人体制が実際に回り始めてから取り組む課題ですが、準備期の段階では「新メンバーが最初の数週間で迷わないための最低限の道しるべ」があれば十分です。完璧なドキュメントを目指すあまり準備期が長引き、結局入社日までに何も揃わないという事態のほうが、実務上は深刻な問題を引き起こします。

準備期にはもう一つ、見落とされがちな準備項目があります。それは「アカウント発行・権限付与の段取り」です。新メンバーが入社初日から業務システムにアクセスできる状態を整えておかないと、実質的な立ち上がりが数日単位で遅れます。どのシステムに、どの権限で、いつまでにアカウントを用意すべきかを、入社日の逆算でスケジュール化しておくと、初日からスムーズに移行を開始できます。特に複数拠点や複数部署にまたがる会社では、この段取りが後手に回りやすく、結果として新メンバーが「アカウントが揃うまで待機」という非効率な状態に置かれるケースも見られます。

フェーズ③: 移行期。OJTと並行した業務移管の進め方

新メンバーが入社した直後は、業務を一気に渡すのではなく、段階的に移管していくことが重要です。焦って全業務を渡そうとすると、新メンバーが消化しきれず、結果として既存担当者が「教える負荷」と「自分の業務」の両方を抱え込むことになり、かえって体制移行の負担が増します。

移管の進め方として、次のようなステップを踏むと無理がありません。

  1. 同席・見学フェーズ: 最初の1〜2週間は、既存担当者の対応に新メンバーを同席させ、実際の対応を見てもらう
  2. 補助対応フェーズ: 既存担当者が主導しつつ、新メンバーに一部の作業を任せてみる。判断が必要な場面は既存担当者が引き取る
  3. 主導対応フェーズ: 新メンバーが主導し、既存担当者はサポート役に回る。困ったときにすぐ相談できる距離感を保つ
  4. 独立対応フェーズ: 新メンバーが単独で対応する。ただし、この段階でもエスカレーション先としての既存担当者は明確にしておく

このステップは業務の種類によって速度が異なります。定型的なヘルプデスク対応であれば数週間で独立対応まで進めることも珍しくありませんが、専門性の高い業務や、影響範囲の大きいシステムの保守については、数ヶ月かけて慎重に移管するケースもあります。ヘルプデスク対応の窓口設計そのものについては、チーム化した情シスのヘルプデスク対応、属人対応から窓口一本化へで詳しく扱っています。

移行期で特に注意すべきなのが、「既存担当者が忙しすぎて教える時間が取れない」という事態です。これを避けるためには、移行期の数ヶ月間は、既存担当者の通常業務の一部を意図的に減らす、あるいは優先順位を下げるという判断を、上長を含めて事前に合意しておく必要があります。教える側の負荷を軽視したまま移行を進めると、結局「教える時間がないので、自分でやったほうが早い」という判断に流れ、いつまで経っても業務が移管されない状態に陥ります。

また、移行期には「新メンバーの疑問を拾い上げる仕組み」も重要です。新しく入ったメンバーは、既存の運用に対して「なぜこうなっているのか分からない」という疑問を多く抱きます。この疑問を放置せず、定期的な1on1やふりかえりの場で拾い上げることで、次の2つの効果が得られます。1つは、新メンバーの理解が深まり、独立対応への移行が早まること。もう1つは、既存担当者が当たり前だと思っていた運用に、実は改善の余地があったと気づくきっかけになることです。複数人体制への移行は、単に業務を渡す一方向のプロセスではなく、既存の運用を見直す機会でもあります。

移行期の後半になると、新メンバーが独自の判断で業務を進める場面が増えてきます。このとき、既存担当者が細部まで介入し続けると、いつまで経っても「独立対応」に到達しません。多少のやり方の違いや進め方の癖があっても、結果として業務が回っていれば良しとする度量も、移行を前に進めるためには必要です。完璧に自分と同じやり方を再現させようとすると、新メンバーの成長を妨げ、結局既存担当者への依存が続いてしまいます。

移行期にありがちな失敗パターンと回避策

移行期は、体制移行のプロセス全体の中でも最もトラブルが起きやすいフェーズです。ここでは、実際によく見られる失敗パターンを3つ取り上げ、それぞれの回避策を整理します。

失敗パターン1: 全部同時に渡そうとして共倒れになる

「早く一人前になってほしい」という善意から、複数の業務を並行して渡してしまうケースです。新メンバーはどの業務も中途半端にしか理解できず、既存担当者はあちこちのフォローに追われ、結果として両者とも疲弊します。回避策はシンプルで、渡す業務の数を意図的に絞ることです。1つの業務が独立対応フェーズに到達してから、次の業務の移管を始めるくらいの慎重さが、遠回りに見えて実は最短です。

失敗パターン2: 「聞けばすぐ分かる」を前提に資料を作らない

既存担当者が近くにいる環境では、分からないことがあればすぐ口頭で聞けるため、資料を整備するモチベーションが下がりがちです。しかし、この状態のまま数ヶ月が過ぎると、結局「聞かないと分からない」業務が大量に残り、既存担当者が異動・退職した瞬間に機能不全に陥ります。移行期のうちに、口頭で説明した内容は都度メモに残す、あるいは新メンバー自身にメモを取らせて後でレビューする、といった習慣を仕組みとして組み込んでおくことが重要です。

失敗パターン3: 評価基準が曖昧なまま「独立対応」と判断してしまう

「もう大丈夫だろう」という感覚的な判断だけで独立対応フェーズに移行させると、実際にはまだ対応しきれない場面で新メンバーが困り、対外的な信頼を損なうトラブルに発展することがあります。独立対応への移行前に、想定されるトラブルパターンをいくつか実際に体験させる、あるいはロールプレイ形式で確認するなど、判断の根拠を感覚だけに頼らない工夫が有効です。

これらの失敗パターンに共通するのは、「善意や勢いで進めてしまい、後から地盤の弱さが露呈する」という構造です。移行期は焦らず、1つずつ確実に積み上げていく姿勢が、結果的に最も早く複数人体制を軌道に乗せます。

フェーズ④: 定着期に確立すべき見直しサイクル

複数人体制が一巡し、それぞれが独立して業務を回せるようになった後も、分担は固定的なものとして扱わないでください。業務量は時間とともに変化し、新しいシステムの導入やメンバーの異動によって、最初に決めた分担が実態に合わなくなっていきます。

定着期に確立すべきなのは、次のような定期的な見直しの仕組みです。

  • 半期に1回程度、分担全体を見直すタイミングを設ける: 業務量の偏りや、特定のメンバーへの負荷集中がないかを確認する
  • 新しいシステムやツールを導入するたびに、担当を明示的に決める: なんとなく最初に触った人が担当になる、という曖昧な決まり方を避ける
  • メンバーの異動・退職が発生した際は、残ったメンバーで分担を再設計する: 抜けた分の業務を誰かが自動的に巻き取るのではなく、意図的に再配分する

この見直しサイクルを確立しておくことが、複数人体制になった後の属人化の再発を防ぐ最も現実的な方法です。ひとり体制のときの属人化は「担当が1人しかいない」ことが原因でしたが、複数人体制になっても、特定の業務を1人が長期間専任し続ければ、結局同じ構造の属人化がシステム単位・業務単位で再現されます。定期的な見直しは、この再発を防ぐための予防策です。

見直しの際に有効なのが、感覚的な「忙しさ」だけでなく、ある程度定量的な指標を持っておくことです。問い合わせ対応の件数、対応にかかった平均時間、担当システムのトラブル発生頻度などを、簡易的にでも記録しておくと、「なんとなく大変」という印象論ではなく、実際のデータに基づいた分担の調整ができます。アカウント関連の対応件数が拠点や部署の増加とともにどう変化しているかを把握することも、見直しの重要な材料になります。この視点については複数拠点・部署のアカウント管理、入退社対応の「量」が追いつかなくなったらで詳しく扱っています。

増員の判断そのものをどう固めるか

体制移行のプロセスを設計する前段階として、そもそも「今、増員すべきか」という判断自体に悩む担当者も少なくありません。ひとり情シスの業務量が限界に近づいているという実感はあっても、それを裏付ける材料がなければ、経営層への説明も難しくなります。

増員の判断材料としては、次のような観点が参考になります。

観点確認すべきこと
業務量の推移問い合わせ件数、対応時間が過去と比べてどう変化しているか
対応の遅延「対応が後回しになっている業務」がどれだけ積み上がっているか
属人化のリスク自分が長期不在になった場合、業務が止まるリスクがどの程度あるか
事業成長との連動従業員数・拠点数の増加ペースと、情シス業務量の増加ペースが釣り合っているか

これらの観点を整理し、増員の必要性を客観的に示す材料をあらかじめ用意しておくことが、増員の意思決定そのものをスムーズにします。実際にどのようなスキル・経験を持つ人材を採用すべきかという、より具体的な採用基準の設計については、100-300人規模で必要になる情シス専任の採用基準と求人の書き方で詳しく解説しています。増員の必要性を示す材料と、採用基準の設計は、実務上は同時並行で進めることになる場合が多いため、あわせて参照することをお勧めします。

増員のタイミングを逃さないための、日頃からの備え

ここまで、増員が視野に入ってからのプロセスを解説してきましたが、実はもう一段階手前の備えとして、「日頃から自分の業務を言語化する習慣」を持っておくことが、増員のタイミングを逃さないための鍵になります。増員の話が急に持ち上がったとき、すでに業務の棚卸しができていれば、助走期のフェーズを大幅に短縮できます。

日頃の業務量や優先順位づけの考え方については、ひとり情シスの優先順位のつけ方。全部はできない前提で回すでも扱っています。増員は「限界を迎えてから慌てて申請するもの」ではなく、日々の業務量を可視化しておくことで、適切なタイミングで根拠を持って提案できるものです。

また、日頃の備えという観点では、休暇取得時のバックアップ体制を整えておくことも、間接的に増員の準備につながります。自分が不在の間、誰が何をどこまで代行できるかを整理する作業は、複数人体制における分担設計の予行演習にもなるためです。この点についてはひとり情シスが安心して休むために作っておく仕組みでも扱っているので、増員の検討と並行して見直しておくとよいでしょう。

分担設計の成果を経営層にどう伝えるか

複数人体制への移行は、現場レベルの業務改善にとどまらず、経営層への報告事項にもなります。増員による人件費の増加が、業務のどのような改善につながったのかを説明できるかどうかは、次の増員や体制強化の提案がスムーズに通るかどうかにも影響します。

経営層への説明では、感覚的な「楽になった」ではなく、具体的な変化を示すことが有効です。例えば、次のような観点を移行前後で比較できるように記録しておくと、報告の説得力が増します。

  • 問い合わせへの平均対応時間が、体制移行前後でどう変化したか
  • 特定の担当者への業務集中(属人化)が、どの程度解消されたか
  • これまで手が回らず後回しになっていた業務(セキュリティ対策の強化、システムの計画的な更新など)に、どれだけ着手できるようになったか

これらの記録は、移行が完了してから慌てて集めるのではなく、フェーズ①の助走期における業務棚卸しの段階から、比較可能な形で記録を始めておくとスムーズです。「移行前はこうだった、移行後はこう変わった」という対比を示せる材料を、プロセスの初期段階から意識して残しておくことをお勧めします。

セキュリティ体制との関係も忘れずに

複数人体制への移行を検討する際、業務の分担や引き継ぎに意識が向きがちですが、セキュリティ対応の体制も同時に見直すべき重要な論点です。ひとりで対応していたセキュリティインシデントへの初動対応は、人数が増えることで役割分担が可能になる一方、責任の所在が曖昧になるリスクも新たに生まれます。従業員規模が100人を超えるタイミングで、セキュリティ対応の限界がどこにあるかを見直す視点については、従業員100人超えで必要になるセキュリティ体制、ひとり対応の限界ラインで詳しく扱っています。役割分担の設計と合わせて検討することで、体制移行がより実効性のあるものになります。

内製で採用するか、外部の力を借りるかの視点も持っておく

複数人体制への移行を検討する際、選択肢は「正社員を1人採用する」ことだけではありません。業務量の性質によっては、繁忙期だけ外部ベンダーに一部業務を委託する、あるいは定型的な保守業務をアウトソースし、社内メンバーはより専門性の高い判断業務に集中する、といった組み合わせも現実的な選択肢になります。

内製と外注のどちらを選ぶべきかは、業務の性質によって判断が分かれます。目安として、次のような整理ができます。

業務の性質内製向き外注向き
社内事情への理解が必要◎(社内の人間関係・業務フローを理解している必要がある)
専門性が高く採用が難しい△(採用市場での獲得competition が激しい)◎(専門ベンダーの知見を活用できる)
業務量が変動しやすい△(閑散期の人件費が固定費として残る)◎(繁忙期のみ委託量を増やせる)
機密性が高い情報を扱う◎(社内に情報を留めやすい)△(委託先との契約・情報管理が別途必要)

複数人体制への移行を「全員を正社員として採用する」という発想だけで考えると、選択肢が狭まり、結果として採用のハードルが上がりすぎてしまうことがあります。増員の一部を外部リソースで補うという視点を持っておくことで、体制設計の柔軟性が高まります。ただし、外部委託を選ぶ場合も、委託先との役割分担や引き継ぎの考え方は、社内メンバー間の分担設計と基本的に同じ原則が当てはまります。「誰が何を持つか」「エスカレーション先は誰か」を明確にしておくという点は、内製・外注を問わず共通する土台です。

まとめ: 分担設計は「増員が決まった瞬間」ではなく「増員を見据えた瞬間」から始まる

ひとり体制から複数人体制への移行を成功させている会社に共通するのは、増員が正式に決まってから慌てて動くのではなく、増員が視野に入った段階から助走を始めている点です。自分の業務を棚卸しし、切り分け可能な単位に分解しておくことで、実際に人が決まったときの準備期間を有効に使えます。

そして、新メンバーが入社した後も、業務を一気に渡すのではなく、同席・補助・主導・独立という段階を踏んで移管し、体制が一巡した後も定期的な見直しサイクルを確立することで、複数人体制での属人化の再発を防げます。増員は一度きりのイベントではなく、その後も継続的に調整していくプロセスだという認識を持つことが、チーム化を軌道に乗せる最大のポイントです。

助走期の業務棚卸し、準備期の資料整備、移行期の段階的な移管、定着期の見直しサイクル。この4つのフェーズを意識して進めるだけで、「増員したのに結局何も変わらなかった」「かえって混乱が増えた」という失敗を避けやすくなります。完璧な移行計画を最初から作ろうとするのではなく、まずは自分の業務を言葉にするところから、体制移行の準備を始めてみてください。

体制移行は、一度きりで完成するプロジェクトではありません。会社の規模がさらに拡大すれば、2〜3人だった体制がさらに増員される局面も訪れますし、逆にメンバーの異動で体制が縮小する局面も起こり得ます。そのたびに、このガイドで示した4つのフェーズの考え方に立ち返り、業務を棚卸しし、段階的に移管し、定期的に見直すというサイクルを繰り返すことになります。最初の複数人体制への移行を丁寧に進めておくことは、その後何度も訪れる体制変化への対応力そのものを、組織に蓄積させることにつながります。

自社の情シス体制がどの段階にあるか客観的に把握したい場合は、ひとり情シス危険度診断もあわせてご活用ください。