「なんとなく詳しい人」に依存した社内IT、辞めたら詰む前にやること

社員5人の会社に、必ずと言っていいほど1人はいる人物がいます。「パソコンのことなら、とりあえずあの人に聞けば何とかなる」という存在です。前職がIT系だった、学生時代からパソコンをいじるのが好きだった、あるいは単に最初に困って自分で調べたのがきっかけで、いつの間にか社内の「なんとなく詳しい人」になってしまった人です。

この人物は、多くの場合、正式に情シス担当として任命されたわけではありません。本来の業務は営業だったり、経理だったり、製造の現場だったりします。それでもプリンターが動かなくなれば呼ばれ、Wi-Fiが不安定になれば相談され、新しいツールを導入するときは「とりあえず聞いてみよう」と頼られます。本人としても、頼られること自体は悪い気がしないため、断りきれずに引き受け続けているうちに、いつしか「その人がいないと社内ITが回らない」という状態が出来上がります。

このガイドでは、この「なんとなく詳しい人」への依存状態が、なぜ創業期に特に生まれやすいのか、そしてその人が辞めたときに何が起きるのか、さらにその依存を本人の負担を増やさずに解消していく方法を具体的に解説します。

なぜ創業期に「なんとなく詳しい人」が生まれやすいのか

10人未満の会社には、専任の情シス担当を雇う予算的な余裕がないことがほとんどです。売上がまだ安定していない段階で、直接利益を生まない管理部門にコストを割く判断は難しく、結果として「今いるメンバーの中で、一番詳しそうな人」に自然発生的に役割が集まっていきます。これは会社側が意図的に選んだ体制ではなく、成り行きで生まれた体制であるという点が重要です。

成り行きで生まれた体制には、明文化された役割定義がありません。「あなたの業務範囲はここまでです」という取り決めがないまま、聞かれれば答え、頼まれれば対応するという形で、際限なく業務が広がっていきます。本人も「これは自分の仕事なのか、それとも親切心でやっているだけなのか」を明確に区別できないまま、日々の対応に追われることになります。

さらに創業期特有の事情として、経営者自身がIT分野に疎く、「詳しい人に任せておけば安心」という判断をしがちな点も見逃せません。経営者からすれば、コストをかけずに社内のIT課題が解決しているように見えるため、あえて体制を見直す動機が生まれにくいのです。しかし、これは本質的には属人化と呼ばれる状態そのものであり、その人物に何かあった瞬間に、会社は無防備な状態に陥ります。

「詳しい」と「情シスができる」は別の能力である

ここでもう一つ、創業期の会社が見落としがちな視点を補足しておきます。それは、「パソコンに詳しい」ことと「情シス業務を体系的にこなせる」ことは、似ているようで別の能力だという点です。「なんとなく詳しい人」は、目の前で起きたトラブルにその場で対応する力には長けていることが多い一方、セキュリティポリシーの設計、契約管理、中長期的なIT投資計画といった、体系立てた情シス業務の経験を持っているとは限りません。

これは本人の能力を否定する話ではなく、そもそも求められている役割が違うという話です。目の前の火消しが得意な人に、体系的な仕組み作りまで一手に背負わせてしまうと、本人にとっても荷が重く、結果として「その場しのぎの対応の積み重ね」から抜け出せないまま時間だけが過ぎていきます。依存からの脱却を考える際は、「その人に足りない能力を責める」のではなく、「その人が得意なこと・苦手なことを会社として整理し、苦手な部分は外部の力も借りながら補う」という視点を持つことが重要です。

まとめ: 「詳しい人」がいることは悪くない。依存しきることが問題

この状態を放置することのリスクは、大きく3つに整理できます。

• 退職・異動リスク: 最も直接的なリスクです。その人物が転職や独立で会社を離れると、それまで頭の中で処理していたトラブル対応のノウハウ、設定変更の手順、契約情報へのアクセス方法がすべて一緒に失われます
• 過負荷によるバーンアウトリスク: 本業と兼任している場合、IT対応の負荷が積み重なることで本業のパフォーマンスが落ちたり、本人が疲弊して体調を崩したりするリスクです。頼られることに応え続けた結果、限界を超えてしまうケースは少なくありません
• 判断の属人化リスク: 「このツールを導入すべきか」「このセキュリティ設定でよいか」といった判断が、その人物の知識と経験だけに基づいて行われ、会社としての合意形成やチェック機能が働かないまま意思決定されてしまうリスクです

3つのリスクのうち、退職・異動リスクは分かりやすい一方、過負荷によるバーンアウトリスクと判断の属人化リスクは、平時には見えにくいという特徴があります。特にバーンアウトのリスクは、本人が「大丈夫です」と言い続けている間は周囲も気づきにくく、限界を超えてから初めて表面化することが多いため、注意が必要です。

「頼られる側」から見た景色: よくある本音

依存状態を解消する際、対策を立てる前に理解しておきたいのが、「なんとなく詳しい人」自身が普段どう感じているかという点です。ヒアリングを重ねていくと、次のような本音が語られることが多くあります。

• 「頼られるのは嬉しいが、いつまでこの状態が続くのか不安」
• 「本業の評価は落ちているのに、IT対応の分は誰にも評価されていない気がする」
• 「休みの日にも連絡が来ることがあり、心が休まらない」
• 「自分が辞めたらどうなるのか、正直自分でも分からない」
• 「もっと専門的に学びたい気持ちはあるが、目の前の対応に追われて時間が取れない」

これらの本音は、いずれも「頼られること自体への不満」ではなく、「終わりが見えない負担への不安」に集約されます。裏を返せば、会社側が「この状態を変えていく意思がある」と明確に示すだけでも、本人の心理的な負担は大きく軽減されます。依存の解消に着手すること自体が、本人へのメッセージになるという点は、対策を進める上で覚えておく価値があります。

「なんとなく詳しい人」が辞めたらどうなるか: 具体的なシナリオ

実際にこの人物が退職すると何が起きるのか、時系列で見てみましょう。まず退職の申し出があった直後、周囲は初めて「この人がどれだけの業務を担っていたか」に気づきます。プリンターの設定、Wi-Fiルーターの管理画面、各種SaaSの管理者権限、社内Wi-Fiのパスワード変更手順――これらすべてが、引き継ぎ資料として残っていないことに気づくのは、たいてい退職日が迫ってからです。

退職後、最初に表面化するのは軽微なトラブルです。新入社員のパソコンセットアップ、共有プリンターの紙詰まり対応、Wi-Fiの接続不良といった、これまで「あの人に聞けばすぐ解決した」問題が、誰にも解決できないまま放置されるようになります。次第に、より重大な問題が発生します。契約更新の期限が来ても誰も気づかない、セキュリティソフトの更新が滞る、退職者本人のアカウント権限が残ったままになる、といった具合です。

最も深刻なケースでは、業務システムに障害が発生した際に、原因を特定できる人が社内に誰もいないという事態に陥ります。この段階まで来ると、外部の開発会社や専門家に緊急で相談することになりますが、状況を一から説明する必要があり、対応にも時間と追加費用がかかります。「あの人がいた頃は無料で（あるいは本業の範囲内で）解決していたことが、いなくなった途端に外部委託費用として発生する」という構図は、多くの会社が経験する典型的な失敗パターンです。

依存から抜け出す第一歩: 本人へのヒアリングから始める

依存状態からの脱却は、いきなり体制を変えるのではなく、まず本人へのヒアリングから始めることをお勧めします。ここで大切なのは、「あなたに頼りすぎているのが問題だ」という否定的な切り口ではなく、「あなたの負担を減らし、会社としてもリスクを減らしたい」という前向きな切り口で話を進めることです。多くの場合、本人自身も「自分がいなくなったらどうなるんだろう」という漠然とした不安を抱えていることが少なくなく、会社側から歩み寄る姿勢を見せることで、協力的に進められるケースが多くあります。

ヒアリングでは、次のような質問を投げかけてみてください。

1. 普段、どんな相談や作業が発生していますか（頻度も含めて）
2. その中で、マニュアル化されていない・自分にしか分からない作業はどれですか
3. もし今日突然休むことになったら、何が一番困ると思いますか
4. 本来の業務とIT対応の時間配分は、体感でどれくらいですか

この4つの質問に答えてもらうだけで、これまで見えていなかった業務量と、優先的に文書化すべき作業が浮かび上がってきます。特に3番目の質問は、本人自身が普段意識していない「実は自分にしか分からないこと」に気づくきっかけになります。

ステップ1: 頻出する対応をパターン化して記録する

ヒアリングの結果をもとに、まず着手すべきは頻出する対応のパターン化です。例えば「新入社員のパソコンセットアップ」「Wi-Fiの接続トラブル対応」「共有プリンターの用紙詰まり対応」など、繰り返し発生している作業から優先的に手順書化していきます。

手順書は完璧な文書である必要はありません。スクリーンショット付きの簡易メモ程度でも、無いよりは遥かにましです。まずは次のような簡易フォーマットで記録を始めてください。

この形式で、頻度の高いものから順に5〜10件ほど記録していくだけでも、依存度は大きく下がります。すべてを網羅する必要はなく、「これさえあれば、本人がいなくても8割の問い合わせは他の人でも対応できる」というラインを目指してください。

ステップ2: 権限とアクセス情報を分散させる

手順の記録と並行して重要なのが、権限とアクセス情報の分散です。「なんとなく詳しい人」は、業務の性質上、様々なシステムの管理者権限を単独で持っていることが多くあります。この状態自体が、その人物が不在になった際の最大のボトルネックです。

管理者権限は、可能な限り複数人でシェアする体制に切り替えてください。パスワード管理ツールを使ってアクセス情報を共有ボールトに移す方法については、社長しか知らないパスワードとアカウント、10人になる前に洗い出す方法で詳しく解説していますので、あわせて参照してください。権限の分散は、単に「もう1人にもパスワードを教える」というだけでなく、「その人が実際に一度は操作を経験しておく」ところまで含めて初めて機能します。パスワードだけ渡されても、操作方法が分からなければ、いざというときに使えません。

外部リソースを部分的に借りるという選択肢

社内の「なんとなく詳しい人」への依存を減らすもう一つの現実的な方法として、外部リソースを部分的に借りるという選択肢も検討に値します。すべてのIT業務を外部委託するのではなく、専門性の高い一部の業務――例えばサーバーの保守やセキュリティ設定の初期構築など――だけをスポットで外部の専門家に依頼し、日常的な軽微な対応は引き続き社内で回すという役割分担です。

創業期の会社は、外部委託というと「継続的な高額契約」をイメージして及び腰になりがちですが、単発のスポット契約や、月数時間程度のアドバイザリー契約から始められるサービスも数多く存在します。社内の「なんとなく詳しい人」が抱えている業務のうち、専門知識が特に必要な部分だけを外部に切り出すことで、本人の負担を減らしつつ、対応の質も担保できます。

外部リソースを使う際は、丸投げにせず、対応内容を必ず社内の台帳や手順書に反映してもらうよう依頼してください。外部の専門家が設定した内容がブラックボックスのまま残ってしまうと、今度は「外部の特定の会社にしか分からない」という、形を変えた属人化が生まれてしまいます。

ステップ3: 判断基準を明文化し、独断にしない仕組みを作る

3つ目のリスクとして挙げた「判断の属人化」への対策として、新しいツールの導入やセキュリティ設定の変更といった意思決定を、その人物単独の判断に委ねない仕組みを作ることも重要です。例えば、月額数千円を超えるSaaSの契約や、社内データに関わる重要な設定変更については、社長や他のメンバーも交えて簡単な確認を挟むルールを設けるだけでも、判断の属人化はかなり防げます。

この際、稟議のような重厚な仕組みを新設する必要はありません。創業期の会社であれば、チャットツールで「このツールを導入しようと思うけど、月額はこれくらいで、こういう理由です」と一言共有し、簡単な合意を得るだけでも十分な効果があります。重要なのは形式ではなく、「1人の頭の中だけで意思決定が完結しない」という状態を作ることです。

本人のモチベーションを損なわない進め方

依存からの脱却を進める際、最も気をつけたいのが本人のモチベーションです。「あなたに頼りすぎているのを解消したい」という意図が、本人には「自分の役割を奪われる」「これまでの貢献が否定される」というように受け取られてしまうことがあります。この誤解が生まれると、協力を得られないどころか、かえって情報の共有に消極的になってしまうリスクすらあります。

進め方として有効なのは、脱却の目的を「本人の負担軽減」として一貫して伝えることです。「あなたがいなくても回る仕組みを作ることで、あなたが本来の業務に集中できるようにしたい」「急な休みも取りやすくなる」というメリットを具体的に伝えると、本人にとっても納得感のある取り組みになります。実際、多くの「なんとなく詳しい人」は、頼られることへの誇りと同時に、負担の重さへの疲れも感じています。このアンビバレントな心情を理解した上でコミュニケーションを取ることが、円滑な脱却の鍵になります。

「自分がいなくなったら会社が困る」という状態は、本人にとって一見誇らしいことのように思えるかもしれません。しかし実際には、休暇も取りづらく、退職の決断もしづらくなるという形で、本人自身を縛る足かせにもなります。仕組み化は、本人を自由にするための取り組みでもあるのです。

兼任からの卒業を見据える: 10人を超えたタイミングでの再検討

10人を超えて会社の規模が拡大してきたら、「なんとなく詳しい人」への依存を仕組みで薄めるだけでなく、正式な担当者を置く、あるいは外部の専門家と契約するといった選択肢も現実的になってきます。この段階になると、これまで兼任で対応してきた人物を正式に「情シス担当」として任命し、業務時間の一定割合をIT対応に充てられるようにする会社も増えてきます。

正式な担当者を置く場合でも、これまで述べてきた手順書化・権限分散・判断基準の明文化は無駄になりません。むしろ、これらの土台があることで、正式な担当者への引き継ぎもスムーズに進みます。この先の90日の動き方については、ひとり情シスに任命されたら、何からやれば会社を止めずに済むか（最初の90日）で詳しく扱っていますので、規模が拡大したタイミングであわせて参照してください。

依存解消にかかる期間の目安

最後に、実際に依存を解消するまでにどれくらいの期間を見込めばよいかについても触れておきます。10人未満の会社であれば、頻出するトラブル対応の手順書化だけであれば数週間、パスワード・権限の分散まで含めても2〜3ヶ月程度で、依存度を大きく下げることが可能です。もちろん本業との兼ね合いで作業時間が限られるため、無理に急ぐ必要はありませんが、「いつまでに、どこまでやるか」という大まかな目安を最初に決めておくと、取り組みが尻すぼみになりにくくなります。

進捗の目安としては、まず1ヶ月目で頻出トラブルの手順書化を3〜5件、2ヶ月目でパスワード・権限の分散、3ヶ月目で判断基準の明文化と定期的な棚卸しルールの定着、という段階を踏むイメージを持つとよいでしょう。焦って一気に進めるよりも、本業との両立を前提にした無理のないペースで進めることが、結果的に長続きする仕組みにつながります。

パスワード台帳・IT台帳との連動

「なんとなく詳しい人」への依存解消は、単独で進めるよりも、パスワードとアカウントの棚卸しやIT台帳の整備と同時並行で進めるほうが効率的です。実際、この人物こそが最も多くのパスワードとアカウント情報を頭の中に抱えている当事者であることが多く、台帳化の作業を進めるにあたって最も頼りになる情報源でもあります。

台帳化の具体的な手順については社長しか知らないパスワードとアカウント、10人になる前に洗い出す方法を、最小構成のIT台帳の作り方については社員10人未満で今すぐ作るべき「IT台帳」はA4一枚でいいを参照し、本人へのヒアリングと合わせて一気に進めることをお勧めします。属人化の解消は、一度に完璧を目指さず、優先度の高いものから着実に潰していくアプローチが現実的です。

「詳しい人」自身が独立・起業予備軍であるケースへの備え

創業期の会社で「なんとなく詳しい人」を務めている人物は、しばしば技術志向が強く、将来的にフリーランスとして独立したり、自ら起業したりする傾向を持つ人材でもあります。これは会社にとって歓迎すべき人材であると同時に、依存のリスクという観点では特に警戒すべき対象でもあります。技術に強い人材ほど、社内で唯一無二の存在になりやすく、いざ独立の話が出たときの引き継ぎの負荷も大きくなりがちだからです。

このタイプの人材と接する際は、日頃から「いずれ独立するかもしれない」という前提を持ちながら、依存度を計画的に下げていくスタンスが有効です。これは本人への不信感からではなく、むしろ本人のキャリアを応援する姿勢とも両立します。「いつ抜けても会社が困らない状態」を作っておくことは、本人が心置きなく次のキャリアを選択できる環境を用意することでもあるからです。実際、円満退職や独立後も業務委託として関係が続くケースは、こうした準備がなされていた会社に多く見られます。

属人化に気づくためのセルフチェック

自社が「なんとなく詳しい人」への依存状態にあるかどうかを判断するために、次のセルフチェックを活用してください。当てはまる項目が多いほど、依存度が高い状態にあると考えられます。

• ITやパソコンに関するトラブルは、特定の1人にしか相談しない・できない
• その人物が休みの日にトラブルが起きると、業務が止まってしまう
• 各種システムの管理者パスワードを、その人物しか知らない
• 新しいツールを導入する際の判断が、その人物の一存で決まっている
• その人物が退職・異動した場合の引き継ぎ計画が存在しない
• 「あの人に聞けば分かる」という言葉が社内で頻繁に使われている
• その人物の本業の評価が、IT対応の負荷によって圧迫されている

7項目のうち3つ以上に当てはまる場合は、依存度が高い状態にあると考えてよいでしょう。5つ以上当てはまる場合は、早急に本ガイドで紹介した対策に着手することをお勧めします。

経営者が果たすべき役割: 「ありがとう」だけで終わらせない

依存状態の解消を進めるうえで、経営者の役割は極めて大きいものです。多くの創業期の会社では、経営者が「なんとなく詳しい人」に対して感謝の言葉をかけることはあっても、その負担を構造的に軽くするための投資判断を後回しにしがちです。「いつも助かっているよ、ありがとう」という言葉だけでは、本人の負担も、会社としてのリスクも減りません。

経営者が取るべき具体的なアクションは、まず本人のIT対応にかかっている時間を正しく把握することです。多くの場合、経営者はこの時間を過小評価しています。実際に1週間、本人にIT対応に費やした時間を記録してもらうと、想像以上の時間が割かれていることに気づくケースが少なくありません。この事実を把握した上で、パスワード管理ツールの導入費用、手順書作成のための時間確保、必要であれば外部専門家への部分的な委託といった投資判断を、経営者自身が主体的に行う必要があります。

依存の解消は、本人の善意や頑張りだけに任せていては進みません。経営者が「これは会社としてのリスクマネジメントの一環である」と位置づけ、必要な時間とコストを正式に認めることで、初めて実効性のある取り組みになります。

小さな成功体験を積み重ねる進め方

依存の解消は、一度に全てを完璧にしようとすると挫折しやすい取り組みです。おすすめは、最も頻度の高いトラブル1つだけに絞って、まず手順書化からスタートすることです。例えば「Wi-Fi接続トラブル」だけを手順書化し、実際に別のメンバーがその手順書を使って対応できるかを試してみる。この小さな成功体験が、次のトラブルへの手順書化のモチベーションにつながります。

逆に、いきなり「すべての業務を洗い出して、全部を仕組み化しよう」と大きな目標を掲げると、着手する前から疲弊してしまい、結局何も進まないまま元の依存状態に戻ってしまうことが多くあります。10人未満の会社であれば、着手すべき業務の絶対数もまだ限られているはずです。1つずつ、確実に潰していく地道なアプローチが、結果的には最も早く依存状態を解消する道になります。

まとめ: 「詳しい人」がいることは悪くない。依存しきることが問題

最後に強調しておきたいのは、社内に「なんとなく詳しい人」がいること自体は、決して悪いことではないという点です。むしろ、専任の情シス担当を雇う余裕がない創業期の会社にとって、こうした人物の存在は貴重な財産です。問題なのは、その人物の存在に会社全体が無自覚に依存し、何の備えもしないまま日々を過ごしてしまうことです。

このガイドで紹介した手順書化・権限分散・判断基準の明文化は、どれも本人の役割を奪うものではなく、本人の負担を軽くしながら、会社としてのリスクを減らすための取り組みです。10人未満というこの段階で着手しておけば、作業量はまだ限られています。会社の成長とともに依存が深まる前に、今日から少しずつ着手してください。

依存が解消されていく過程では、「なんとなく詳しい人」自身の役割も少しずつ変わっていきます。すべてを1人で抱え込む「便利屋」の立場から、会社全体のIT方針を一緒に考える「相談相手」の立場へ。この変化は、本人のキャリアにとっても、会社にとっても望ましい方向への移行です。属人化の解消は、リスク管理であると同時に、社内で最もITに詳しい人材の力を、より価値のある形で活かしていくための取り組みでもあります。

10人未満というこの段階で依存の芽を摘んでおけば、会社が20人、50人と成長していく過程で、同じ問題が形を変えて再発するリスクも大きく下げられます。逆にこの段階で手を付けないまま規模が拡大すると、依存の構造そのものが会社の文化として定着してしまい、後から解消するコストは何倍にも膨れ上がります。今日、この記事を読んでいるタイミングこそが、最も低いコストでこの問題に着手できる機会です。自社の依存度を客観的に把握したい場合は、ひとり情シス危険度診断もあわせてご活用ください。