「パソコンが遅い」「パスワードを忘れた」「Wi-Fiがつながらない」。10人未満の会社では、これらの問い合わせは月に数件で、本業の合間に対応しても支障はなかったはずです。しかし社員数が30人を超えると、問い合わせの絶対数が増え、さらに社員一人ひとりのITリテラシーのばらつきも大きくなり、対応にかかる時間が読めなくなっていきます。

このガイドは、社員数30〜100人規模で、ヘルプデスク対応が本業を圧迫し始めた兼任情シス担当者が、対応する範囲と断る範囲をどう線引きし、それをどう社内に伝えるかを扱います。単なる「効率化テクニック」ではなく、兼任という立場のまま持続可能に働き続けるための境界線の引き方が主眼です。

情シス担当者が疲弊してしまうと、結局その会社のIT環境全体の質が下がります。線引きは冷たい対応のように感じられるかもしれませんが、実際には「担当者が長く健全に機能し続けるための必要な仕組み」です。このガイドを通じて、罪悪感なく線を引ける状態を作ることを目指します。

なぜ30〜100人規模で問い合わせが「質的に」増えるのか

問い合わせの増加は、単純な人数比例では説明できません。この規模で起きる質的な変化には次のようなものがあります。

  • 部署が分化し、情シス担当者が各部署の業務内容を把握しきれなくなる: 「この部署のこのツールの使い方」まで踏み込んだ質問が増え、汎用的な対応では済まなくなる
  • 中途入社者が増え、前職のITリテラシーの差が問い合わせ内容に表れる: 基本的な操作から専門的なトラブルまで、問い合わせの難易度の幅が広がる
  • リモートワークやモバイル利用が増え、対面では解決しない問い合わせが増える: 「画面を見せてもらえれば一瞬で分かる」問題が、口頭説明だけでは長引く
  • 社員同士の距離が生まれ、部署内で解決していた小さな疑問まで情シスに回ってくる: 10人規模なら隣の席の人に聞けば済んでいた質問が、部署が分かれることで「とりあえず情シスに聞こう」という流れになりやすくなる

これらが重なることで、10人規模の頃と同じ感覚で対応していると、ヘルプデスク対応だけで本業の時間が食いつぶされる事態が起きます。

線引きの前にやるべきこと: 問い合わせを記録し、傾向を見る

線引きルールを作る前に、まず1〜2週間でよいのでどんな問い合わせが、どれくらいの頻度で来ているかを記録してください。感覚だけで「多い」と感じていても、実際に記録すると特定の1〜2種類の問い合わせが全体の大半を占めている、というケースが少なくありません。

記録する項目は最低限で構いません。

  • 問い合わせの種類(パスワード忘れ、動作不良、操作方法、その他)
  • 対応にかかった時間
  • 依頼元の部署

この記録があれば、後述する「予防」と「線引き」のどちらに投資すべきかを、感覚ではなくデータで判断できるようになります。記録を1〜2週間続けると、多くの場合「パスワード忘れ」「共有フォルダのアクセス権限の問い合わせ」「プリンター関連」といった数種類の定型的な問い合わせが件数の大半を占めていることが見えてきます。この偏りを可視化することが、限られた時間で最大の効果を得る改善の出発点になります。

線引きその1: 「予防できる問い合わせ」は対応せず仕組みで減らす

問い合わせの中には、対応そのものよりも発生を予防する方が費用対効果が高いものがあります。代表例がパスワード忘れです。パスワード忘れの問い合わせは、シングルサインオン(SSO)やパスワードマネージャーの導入で構造的に減らせます。

多要素認証(MFA)やSSOの導入は、30-100人規模の会社が最初に整備すべきセキュリティ対策の順番で扱っているセキュリティ対策とも重なる部分で、セキュリティ強化とヘルプデスク負荷軽減を同時に達成できる数少ない施策です。予防で減らせる問い合わせは、線引きルールを検討する前にまず着手してください。

予防策は他にもあります。よくある問い合わせの中には、簡単な社内FAQを整備するだけで自己解決してもらえるものが少なくありません。

  • 社内Wikiや共有ドキュメントにFAQページを作る: 「Wi-Fiがつながらないとき」「プリンターの紙詰まり対応」など、頻出する定型的なトラブルの解決手順を、写真付きで簡潔にまとめておく
  • 新入社員研修に基本的なITリテラシー項目を含める: オンボーディングの段階で、社内システムの基本操作やよくあるトラブルの自己解決方法を伝えておくことで、入社後の問い合わせを事前に減らせる
  • チャットボットや自動応答の活用: 定型的な質問(パスワードリセットの手順など)は、簡単な自動応答の仕組みで一次対応を済ませられる場合がある

これらの予防策は、一度整備すれば継続的に効果を発揮します。線引きルールで「断る」対応をする前に、まず「そもそも聞かれない状態を作る」投資を検討してください。

線引きその2: 対応する範囲を職務定義として明文化する

予防で減らしきれない問い合わせについては、「対応する」「対応しない」の境界を明文化します。ポイントは、その場の判断で断るのではなく、あらかじめ決めたルールとして周知しておくことです。

分類対応方針具体例
情シス担当が対応すべき対応するアカウントロック解除、社内システムの不具合、端末故障
業務ソフト固有の使い方各部署の詳しい人・ベンダーサポートへ誘導会計ソフトの仕訳操作、CRMの入力ルール
個人所有デバイスの問題原則対応外私物スマホの不具合、個人のWi-Fiルーター設定
緊急度が低い要望受付後、優先順位に沿って後日対応UIの見た目の好み、優先度の低い機能追加要望

このような分類自体は、ひとり情シスのためのヘルプデスク効率化ひとり情シスの優先順位のつけ方。全部はできない前提で回すで扱われている考え方と共通しますが、30〜100人規模特有の論点は、この線引きを個人の裁量ではなく、部署をまたいだ「会社としての合意」に格上げする必要がある点です。10人規模であれば「担当者が忙しそうだから今回は自分で調べよう」という暗黙の配慮が機能しますが、30人を超えると、依頼者と担当者の間に距離ができ、暗黙の配慮に頼れなくなります。

分類表を作る際は、最初から完璧な網羅を目指す必要はありません。まず記録した問い合わせデータの中から頻度の高いものを対象に分類し、運用しながら未分類の問い合わせが出てきたら随時追加していく、というやり方で十分です。

緊急度と重要度で優先順位をつける

対応する範囲に分類された問い合わせであっても、すべてを即座に対応する必要はありません。緊急度(今すぐ対応しないと業務が止まるか)と重要度(影響範囲の大きさ)の2軸で優先順位をつけることで、限られた時間を効果的に配分できます。

緊急度が高い緊急度が低い
重要度が高い即座に対応(全社システム障害など)
重要度が低い手短に対応(個人のパスワード忘れなど)

「重要度は低いが緊急度が高い」に分類される問い合わせ(パスワード忘れなど)が、実は日々の問い合わせの大半を占めているケースが多く見られます。ここを前述の予防策で減らせるかどうかが、全体の負荷軽減に直結します。

断り方: 「できません」ではなく「誰に聞けばいいか」を返す

線引きルールを作っても、実際に断る場面での伝え方を誤ると、社内の反発や「不親切」という評判につながります。避けるべきは、単に「それは対応範囲外です」とだけ返すことです。代わりに、対応できない理由と、次にどこへ相談すればよいかをセットで返すようにしてください。

  • 悪い例: 「それは情シスの範囲外なので対応できません」
  • 良い例: 「会計ソフトの仕訳操作についてはベンダーサポート(連絡先はこちら)にご確認いただけますか。社内システム側の不具合であれば引き続き私が対応します」

この「誰に聞けばいいかを返す」対応を徹底するには、各業務ソフトのベンダーサポート窓口や、部署内の詳しい人の一覧を事前に整備しておく必要があります。これも問い合わせ対応そのものではなく、事前準備として時間を確保すべき作業です。

具体的には、次のような一覧を作っておくと、断る際にすぐ案内できて便利です。

  • 各業務ソフトのベンダーサポート窓口(連絡先・営業時間・対応言語など)
  • 部署ごとの「その業務に詳しい人」の一覧(正式な役職でなくても、実質的に頼られている人がいれば記載)
  • 社内FAQページへのリンク一覧

この一覧自体も、前述のアカウント台帳と同様、一度作って終わりではなく、担当者の異動やベンダーの窓口変更に応じて更新し続ける必要があります。

線引きルールは経営層の合意を得てから周知する

線引きルールを情シス担当者の判断だけで決めて社内に流すと、「勝手に対応範囲を狭められた」という不満が出やすくなります。特に30〜100人規模では、情シス担当者と経営層の距離がまだ近く、かつ現場との距離は開き始めているという中間的な立場にあるため、線引きルールは経営層の承認を得たうえで、会社としての方針として周知することが重要です。

この合意形成は、情シス専任者としての役割範囲そのものを決める話でもあります。専任1人目が着任するタイミングでどこまでの役割を経営層と合意すべきかは、情シス専任1人目が就任したときに経営層と決めておくべき役割の範囲で扱っているので、ヘルプデスクの線引きを機に、役割全体の合意形成に発展させるのも一つの選択肢です。

経営層への説明では、線引きルールが「情シス担当者を楽にするため」だけではなく、「会社全体のIT対応の質を維持するため」であることを強調してください。担当者が些末な問い合わせに忙殺されて、重要なセキュリティ対策や台帳整備が後回しになる状態こそが、会社にとってのリスクだという視点を共有できると、経営層の理解を得やすくなります。

周知方法: 一斉通知だけでなく繰り返し伝える

線引きルールを経営層の承認を得たうえで社内に周知する際、一度メールや社内チャットで告知しただけでは浸透しません。特にこの規模の会社では、社員全員が同じ温度感で情報を受け取るとは限らず、告知を見落とす人も一定数存在します。

効果的な周知の工夫としては、次のようなものがあります。

  • 初回告知に加えて、新入社員研修に組み込む: 新しく入る社員には、入社時のオリエンテーションで問い合わせのルールを伝えておくことで、最初から正しい認識を持ってもらえます
  • 社内FAQページに常時掲示する: 一度きりの告知で終わらせず、いつでも参照できる場所に固定的に掲載しておきます
  • 実際に線引きに沿った対応をした際、都度理由を添えて伝える: ルールの存在を知らなかった人にも、実際のやり取りの中で自然に周知が広がっていきます

ヘルプデスク対応の記録を振り返りに活かす

問い合わせの記録は、線引きルールを作る初期段階だけでなく、継続的に振り返りに活用してください。3ヶ月〜半年に一度、記録を見返すことで、次のような気づきが得られます。

  • 新しく増えてきた問い合わせのパターンはないか(新しいツール導入やリモートワーク拡大に伴う変化など)
  • 予防策を導入した問い合わせが実際に減っているか
  • 対応範囲の線引きが実態に合わなくなっていないか(会社の状況変化に応じて見直しが必要な項目はないか)

この振り返りを定期的なルーチンにしておくことで、線引きルールを「一度作って終わり」ではなく、「会社の変化に合わせて育てていくもの」として運用し続けられます。

振り返りの際は、単に問い合わせ件数の増減だけでなく、社員からの反応も確認してください。線引きルールの導入によって「不便になった」という声が一定数出るのは自然なことですが、それが少数の意見なのか、多くの社員が共通して感じている不満なのかを見極める必要があります。多くの社員が同じ不満を持っている場合は、ルールの運用方法や周知の仕方に改善の余地があるサインとして受け止め、次の振り返りサイクルで調整してください。

線引きが機能しない場合に考えられる原因

線引きルールを整備しても、実際にはうまく機能しないケースもあります。よくある原因とその対処法を整理します。

原因1: ルールが複雑すぎて社員が覚えられない

分類表があまりに細かいと、社員側もどう問い合わせればよいか迷ってしまいます。まずは「情シスに聞く前に、まずFAQを確認する」という1つのシンプルな導線を徹底することから始め、細かい分類は情シス担当者側の内部運用として持っておく方が実務的です。

原因2: 経営層自身がルールを守らない

線引きルールを作っても、経営層が「自分は特別」という態度で細かい依頼を続けると、他の社員にもルールが浸透しません。経営層への説明の際、経営層自身にもルールを守ってもらうことの重要性を、遠回しにでも伝えておく必要があります。

原因3: 断られた社員が別の経路で依頼してくる

正式な問い合わせ窓口では断られても、廊下での立ち話や個人チャットで依頼してくる社員がいる場合があります。この場合は、「口頭やチャットでの依頼も、正式な窓口を通してもらう」というルールをあわせて周知し、例外を作らないことが重要です。

部署ごとの「詳しい人」を育てる一次対応の分散

問い合わせ対応の負荷を根本的に減らすもう一つのアプローチとして、各部署に「その部署の中でよくある簡単なトラブルを一次対応できる人」を育てる方法があります。すべてを情シス担当者が対応するのではなく、部署内で解決できる範囲を広げることで、情シス担当者への問い合わせ自体を減らす発想です。

  • 各部署から1名、ITに比較的詳しい社員を「部署内の一次窓口」として任命する
  • その人に対して、よくあるトラブルの解決手順を簡単にレクチャーしておく
  • 情シス担当者に上がってくるのは、部署内で解決できなかった問い合わせに限定する

この体制は、正式な役職や追加の給与を伴う必要はなく、「〇〇さんは詳しいから、まず聞いてみる」という緩やかな役割分担で十分機能します。ただし、この一次対応者に過度な負担がかからないよう、対応範囲は明確に「簡単な操作案内まで」と決めておき、それ以上は情シス担当者にエスカレーションする、というルールを共有しておいてください。このエスカレーションの考え方を部署単位に取り入れることで、情シス担当者一人に問い合わせが集中する状態を緩和できます。

一次対応者を育てる体制は、100人に近づくにつれてその効果が大きくなります。部署の数が増えるほど、情シス担当者一人がすべての部署の業務内容を把握することが困難になるため、各部署内に一次対応の窓口を持たせることは、この規模で特に有効な負荷分散策です。

問い合わせ窓口の一本化: どこに聞けばいいかを迷わせない

問い合わせの負荷が増える背景には、「どこに聞けばいいか分からないから、とりあえず知っていそうな人に聞く」という社員側の行動パターンもあります。この行動が続くと、情シス担当者だけでなく、たまたま詳しい社員にまで問い合わせが分散し、会社全体として問い合わせ対応の効率が悪化します。

対策として有効なのが、問い合わせ窓口を1つに一本化することです。チャットツールに専用チャンネルを作る、専用のメールアドレスを用意する、簡単な問い合わせフォームを設けるなど、方法は会社の規模やツールの利用状況に応じて選べます。重要なのは、「ITのことで困ったら、まずここに連絡する」という導線を社内で統一することです。

窓口を一本化すると、次のようなメリットが生まれます。

  • 問い合わせの記録が自然と一箇所に集約され、前述の傾向分析がしやすくなる
  • 同じ質問が複数の経路から重複して届くことを防げる
  • 担当者が不在の際も、窓口に蓄積された過去のやり取りを参照すれば、後任や代理対応者が状況を把握しやすくなる

窓口の一本化は、線引きルールの土台としても機能します。分類・優先順位づけ・断り方のいずれも、問い合わせが一箇所に集まっていることが前提になるため、まだ窓口が分散している場合は、線引きルールの整備と並行してこの一本化にも着手してください。窓口を切り替える際は、旧来の連絡経路(個人チャットや口頭など)を急に閉じるのではなく、一定期間は新旧両方を案内しつつ、徐々に新しい窓口へ誘導していく移行期間を設けると、社員側の混乱を避けられます。

外部委託・アウトソースという選択肢

線引きルールを整備しても、なお問い合わせ対応の負荷が高すぎる場合、対応範囲そのものを外部に委託する選択肢も検討に値します。特に、次のような特徴を持つ問い合わせは、外部のヘルプデスクサービスに委託しやすい領域です。

  • 定型的で判断の余地が少ない問い合わせ(パスワードリセット、基本的な操作案内など)
  • 社内の機密情報に深く関わらない一般的なトラブルシューティング
  • 対応時間帯が業務時間外にも及ぶ場合(リモートワークで勤務時間が多様化している場合など)

外部委託を検討する際は、コストと対応品質のバランスに加えて、委託先とのSLA(サービス品質保証)を明確にしておくことが重要です。「どのレベルの問い合わせをどれくらいの時間で対応してもらえるか」を契約時に確認しておかないと、期待していた負荷軽減効果が得られない場合があります。SLAの考え方は用語集のSLA(サービス品質保証)の項目もあわせて参照してください。

外部委託は、あくまで線引きルールと予防策を一通り整備した後の選択肢として位置づけてください。線引きが曖昧なまま外部委託をしても、「委託先が対応してくれない範囲」の問い合わせが結局情シス担当者に戻ってくるだけで、根本的な負荷軽減にはつながりません。

問い合わせ対応にかかる時間を可視化して経営層に伝える

線引きルールの必要性を経営層に理解してもらう最も効果的な方法は、問い合わせ対応にどれだけの時間が奪われているかを具体的な数字で示すことです。前述の記録をもとに、次のような集計を行うと説得力が増します。

  • 1週間あたりの問い合わせ対応時間の合計
  • そのうち、本来の業務(セキュリティ対策や台帳整備など)に充てられなかった時間
  • 予防策導入前後での問い合わせ件数の変化

例えば「週に10時間を問い合わせ対応に費やしており、そのうち6時間はパスワード忘れとプリンター関連の定型対応だった」というデータがあれば、SSO導入やFAQ整備への投資判断がしやすくなります。数字による裏付けは、感覚的な「忙しい」という訴えよりも、経営層の意思決定を後押しする力を持ちます。可能であれば、対応前後の時間比較を四半期ごとに継続して示すことで、改善の効果そのものも経営層に伝わりやすくなり、次の予算確保の交渉材料にもなります。

新任担当者が線引きを導入する際の進め方

情シス担当に着任したばかりの担当者が、いきなり厳格な線引きルールを導入すると、社内の反発を招きやすくなります。着任直後は、まず既存の対応を続けながら問い合わせを記録し、傾向をつかむ期間として1〜2ヶ月程度を確保することをおすすめします。

その上で、次のようなステップで段階的に導入すると、社内の理解を得やすくなります。

  1. まず予防策(FAQ整備、SSO導入など)から着手し、目に見える負荷軽減の実績を作る
  2. 実績をもとに、経営層へ線引きルールの必要性を説明し、合意を得る
  3. 線引きルールを、既存の対応を急に変えるのではなく、新しく発生する問い合わせから段階的に適用する
  4. 数ヶ月かけて、対応範囲外の問い合わせを徐々に減らしていく

急激な変化は反発を生みますが、段階的な導入であれば、社員側も「なぜこの変化が起きているか」を理解しながら受け入れやすくなります。

着任直後の記録期間は、単に問い合わせの傾向をつかむだけでなく、社内での信頼関係を築く期間としても機能します。この期間に丁寧に対応した実績があれば、その後に線引きルールを導入する際も、「あの人は誠実に対応してくれる」という信頼を土台に、ルールへの理解を得やすくなります。逆に、着任早々に厳しい線引きだけを打ち出すと、信頼関係が構築される前に距離を置かれてしまうリスクがあるため、順序を誤らないよう注意してください。

まとめ: 線引きは「冷たさ」ではなく持続可能性のための仕組み

ヘルプデスク対応の線引きは、社員への不親切さではなく、兼任担当者が本業を止めずに、かつ情シス業務も長期的に続けられるようにするための仕組みです。まず問い合わせを記録して傾向をつかみ、予防できるものは仕組みで減らし、残りは対応範囲を明文化したうえで経営層の合意を得て周知する。この順番を守ることで、線引きは「冷たい対応」ではなく「持続可能な体制」として社内に受け入れられます。

線引きルールは一度作れば完成するものではありません。会社の成長とともに問い合わせの性質も変わり続けます。定期的に記録を振り返り、ルールを育てていく姿勢を持ち続けることが、30〜100人規模を乗り越え、その先の体制につながる土台になります。

最後に、線引きを実践する上での心構えとして意識してほしいのは、線を引くこと自体に罪悪感を持たなくてよいという点です。すべての依頼に応え続けようとすると、結局は担当者自身が疲弊し、本当に重要な業務(セキュリティ対策や台帳整備、将来を見据えた体制構築)に手が回らなくなります。それは会社全体にとっても損失です。線引きは、限られたリソースを最も効果の高いところに配分するための、合理的で必要な意思決定だと捉えてください。

30〜100人規模を乗り越えた先には、専任担当者の増員やチーム化という次のステージが待っています。それまでの間、担当者が疲弊せずに本業とのバランスを保ちながら会社のIT環境を守り続けるために、このガイドで紹介した記録・予防・線引き・周知のサイクルを、無理のない範囲で少しずつ実践していってください。

今日からできる最初の一歩は、難しいルール作りではなく、たった1〜2週間の問い合わせ記録から始めることです。記録を取り始めれば、次に何をすべきかは自然と見えてきます。焦らず、まずはそこから着手してください。小さな記録の積み重ねが、数ヶ月後には持続可能な体制へと確実につながっていきます。

記録・予防・線引き・周知。この4つのサイクルを地道に回し続けることこそが、兼任情シスとして長く健全に働き続けるための最も確実な道筋になります。

一次情報

  • IPA「中小企業の情報セキュリティ対策ガイドライン」: https://www.ipa.go.jp/security/guide/sme/about.html