月曜の朝、出社してメールを開いた瞬間から「Wi-Fiがつながらない」「見積もりソフトが起動しない」「新入社員のアカウントを今日中に作ってほしい」という依頼が立て続けに届く。そこに経営者から「例のセキュリティ対策の件、そろそろ進めておいて」と声をかけられ、片手には先月から手つかずのままのシステム管理台帳作成タスクが残っている——。ひとりで社内のIT関連業務を担っていると、こうした状況は特別な繁忙期の話ではなく、ほとんど毎週のように起こります。
厄介なのは、依頼のひとつひとつは決して無理な内容ではないのに、同時に積み重なると絶対的にこなしきれる量ではなくなる点です。しかも依頼してくる相手は、他の依頼がどれだけ溜まっているかを知りません。目の前の担当者に頼めば何とかなると思って、悪意なく依頼を重ねてきます。その結果、優先順位を決める役目は、他の誰でもなく担当者自身に委ねられることになります。
本記事では、「全部はできない」という前提に立ったうえで、何を先にやり、何を意図的に後回しにするかを判断するための考え方を整理します。精神論ではなく、緊急度と影響範囲という2つの軸で仕分けるフレームワーク、経営層やスタッフへの後回しの伝え方、そして優先順位づけ自体を仕組み化して一人の判断に依存させない方法まで、実務でそのまま使える形でまとめました。
結論: 優先順位は「緊急度」と「影響範囲」の掛け算で決め、後回しにした理由を言語化して残す
先に結論を書きます。ひとりで担当する業務量が処理能力を超えている状況では、依頼が来た順番やお願いしてきた相手の役職の高さで優先順位を決めるべきではありません。判断基準にすべきは、次の2つの軸です。
- 緊急度: 対応が遅れることで、被害や損失が今日・今週のうちに拡大するか
- 影響範囲: 問題が起きたとき、影響を受けるのが一人の社員か、部署全体か、会社全体か
この2軸を掛け合わせて優先順位をつけ、後回しにした依頼については「なぜ今はやらないのか」を短くてもよいので言葉に残す。この2つを徹底するだけで、優先順位づけの負担と、後から「なぜあれをやらなかったのか」と問われたときの説明負担の両方が大きく下がります。以下、それぞれを詳しく見ていきます。
なぜ「全部はできない」という前提から出発する必要があるのか
優先順位づけの話をする前に、まず認めておくべき前提があります。それは、ひとりで担当している以上、物理的に処理できる業務量には上限があるという事実です。
専任の情報システム部門であれば、複数人でタスクを分担し、担当領域ごとに専門知識を蓄積できます。しかし一人(あるいは総務や経理と兼任)で担っている場合、同じ量の業務を一人の時間とスキルでこなさなければなりません。1日の稼働時間が有限である以上、依頼が増え続ければ、どこかで必ず「対応できない依頼」が発生します。
この前提を認めないまま「全部何とかしなければ」と考えてしまうと、次のような悪循環に陥りやすくなります。
- すべての依頼に対応しようとして、一つひとつの対応が中途半端になる
- 中途半端な対応がトラブルの原因になり、余計な後始末の時間が発生する
- 後始末に追われて、本来優先すべきだった重要な依頼への着手がさらに遅れる
- 「あの人に頼んでも遅い」という評判が広がり、催促の連絡が増えてさらに時間を奪われる
こうなってしまうと、優先順位づけどころではなくなります。逆に言えば、「全部はできない」と最初に認め、意図的に何を後回しにするかを決める方が、結果的にすべての依頼への対応品質を保ちやすくなります。
「頑張れば全部できるはず」という前提に立ってしまうと、優先順位をつける行為そのものが「サボり」のように感じられてしまいます。しかし実際には、優先順位づけは業務量を減らす行為ではなく、限られたリソースの中で最大の効果を出すための技術です。
優先順位マトリクス: 緊急度と影響範囲で4象限に仕分ける
それでは、具体的な仕分け方法に入ります。基本となるのは、縦軸に「緊急度」、横軸に「影響範囲」を置いた4象限のマトリクスです。
- 緊急度が高い: 数時間〜1日以内に対応しないと、被害・損失が拡大する(例: 不審メールを開いてしまった、基幹システムが完全停止した)
- 緊急度が低い: 数日〜数週間の猶予がある(例: 新しいツールの導入検討、マニュアルの整備)
- 影響範囲が広い: 会社全体、または複数部署の業務が止まる・危険にさらされる
- 影響範囲が狭い: 特定の一人、あるいは一部の業務にとどまる
この2軸で分類すると、対応の順番はおおむね次のようになります。
| 象限 | 緊急度 | 影響範囲 | 対応方針 |
|---|---|---|---|
| 第1象限 | 高い | 広い | 最優先。他の作業を中断してでも即対応 |
| 第2象限 | 低い | 広い | 計画的に対応。スケジュールに組み込む |
| 第3象限 | 高い | 狭い | その日のうちに対応。ただし他業務を止めない範囲で |
| 第4象限 | 低い | 狭い | 後回し、または依頼者自身に一次対応を促す |
例えば「ランサムウェアに感染した疑いがある」という報告は、緊急度・影響範囲ともに高く、第1象限に入ります。これは他のすべての作業を止めてでも即座に対応すべき事案です。一方で「個人のパソコンの壁紙を変えたいので設定を教えてほしい」という依頼は、緊急度・影響範囲ともに低く、第4象限に分類されます。
判断に迷いやすいのは、第2象限と第3象限の扱いです。第2象限(緊急度は低いが影響範囲が広い)の典型例が、多要素認証(MFA)の全社導入や3-2-1ルール(バックアップ)に沿ったバックアップ体制の見直しです。今日明日で何かが起きるわけではありませんが、放置すると会社全体を揺るがすリスクにつながります。ここを後回しにし続けると、いつまで経っても「守りの体制」が整わないまま、日々の火消し対応に終始することになります。第2象限の作業を意図的にスケジュールへ組み込むことこそが、ひとり情シスの優先順位づけで最も難しく、最も重要な部分です。
第3象限(緊急度は高いが影響範囲は狭い)は、「その人にとっては今すぐ困っている」案件です。例えば特定の社員のパソコンが起動しないといった依頼が該当します。無視はできませんが、他の重要な作業を止めてまで対応する必要はなく、その日のうちの対応で十分なケースがほとんどです。
緊急度を見誤りやすい3つのパターン
マトリクスの考え方自体はシンプルですが、実際の依頼をどちらの象限に分類するかで判断を誤りやすい場面があります。特によくある3つのパターンを挙げます。
1. 「声の大きさ」を緊急度と混同してしまう
強い口調で急かされたり、役職の高い人から直接依頼されたりすると、実際の緊急度以上に優先度を引き上げてしまいがちです。しかし、依頼者の伝え方の強さと、業務上の本当の緊急度は必ずしも一致しません。「今すぐ」と言われた依頼ほど、一呼吸置いて「これは今日中に対応しないと、具体的に何が困るのか」を確認する価値があります。
2. セキュリティ関連の依頼を後回しにしてしまう
パソコンの不調やソフトのエラーは「今すぐ画面に見えている問題」なので緊急度が高く感じられますが、パッチマネジメントの適用漏れや古いアカウントの放置といったセキュリティ上の課題は、問題が「今は起きていない」ため、緊急度が低く見えてしまいます。しかし、これらは第2象限(緊急度は低いが影響範囲が広い)に分類すべき典型例であり、放置している間にリスクは静かに蓄積し続けています。
3. 「簡単そうだから」で影響範囲を見誤る
対応そのものにかかる時間が短いからといって、影響範囲まで小さいとは限りません。例えば、退職者のアカウント削除は数分で終わる作業ですが、削除が遅れれば元社員が社内システムやデータにアクセスし続けられる状態が続きます。作業時間の短さと、放置した場合の影響範囲は別の軸として評価する必要があります。
後回しにする判断を、相手にどう伝えるか
優先順位づけで悩ましいのは、順位を「決める」ことよりも、後回しにすると決めた依頼を、依頼した相手にどう伝えるかという点です。何も説明せずに放置すると、「無視された」「軽く見られた」という不満につながり、後々の協力関係に響きます。
伝え方のポイントは、次の3つです。
- 対応しないのではなく、いつ対応するかを伝える: 「今は難しいですが、来週の水曜日までには対応します」のように、具体的な見通しを示す
- 後回しにする理由を、業務都合として説明する: 「今、システム障害の対応中で手が離せません」のように、個人の判断ではなく業務上の事情として伝える
- 一次対応でしのげる方法があれば、あわせて案内する: すぐに解決できなくても、「この手順で一時的に回避できます」といった代替策を示せると、相手の不満が和らぎやすい
特に経営者から直接依頼された案件を後回しにする場合は、慎重な言葉選びが必要です。「今できません」とだけ答えるのではなく、「Aの案件を優先すると、Bの対応は来週になります。どちらを優先しますか」というように、判断そのものを相手に委ねる形で伝えると、一方的な先送りという印象を避けられます。この際、依頼が重なっている状況を可視化できる材料があると説明がしやすくなります。次の見出しで扱う「見える化」の仕組みが、ここで役立ちます。
優先順位づけを「その場の判断」から「仕組み」に変える
ここまで紹介したマトリクスは、あくまで個々の依頼が来たときの判断基準です。しかし、依頼の数自体が多い状態が続くと、そのつどマトリクスに当てはめて考える余裕すらなくなってきます。そこで重要になるのが、優先順位づけの負担そのものを減らす仕組みです。
依頼を一元管理する窓口を作る
口頭やチャットの個別メッセージで依頼が飛び交っていると、今どれだけの依頼が溜まっているのかを把握することすら難しくなります。依頼専用のフォームやチャットチャンネルなど、依頼の入り口をひとつにまとめるだけで、「今の依頼件数」と「それぞれの緊急度」を一覧で確認できるようになり、マトリクスへの仕分けも格段に楽になります。
定型的な依頼はマニュアル化して、判断のテーブルから外す
パスワードの再発行手順や、よくある印刷トラブルの対処法など、繰り返し発生する定型的な依頼は、そもそも優先順位を毎回考える対象から外してしまうのが得策です。手順書を整備して依頼者自身に自己解決してもらうか、対応を定型作業として即座に処理できるようにしておけば、判断が必要な依頼だけがマトリクスに残ります。
定期的な棚卸しで「隠れた第2象限」を洗い出す
日々の対応に追われていると、緊急度が低く影響範囲が広い第2象限の課題は、意識しないと視界に入ってきません。月に一度など定期的なタイミングを決めて、社内のシステムや契約状況を棚卸しする時間を確保することをおすすめします。社内のシステム構成を一覧化した台帳のような形で現状を整理しておくと、「対応が漏れている重要な課題」を定期的に洗い出しやすくなります。
経営層への定期報告で、優先順位の判断基準を共有しておく
優先順位づけが「担当者個人の勝手な判断」に見えないようにするためには、判断基準そのものを事前に経営層と共有しておくことが有効です。「セキュリティに関わる依頼は最優先で対応する」「個人的な設定変更の依頼は後回しになる場合がある」といった方針を、あらかじめ稟議や定例報告の場で合意しておけば、実際に後回しにする場面が来ても、その場で一から説明し直す必要がなくなります。
優先順位を上げるべき「守りの課題」を見落とさないために
ここまで紹介したマトリクスの中で、最も見落とされやすいのが第2象限、つまり緊急度は低いが影響範囲が広い「守りの課題」です。日々の対応に追われるひとり情シスほど、目の前の火消しに時間を取られ、この領域への着手が後回しになりがちです。
しかし、この領域を放置し続けた結果として実際に問題が表面化すると、一気に第1象限(緊急度・影響範囲ともに高い)の緊急事態に転じます。例えば、多要素認証を導入していないアカウントが不正ログインされる、バックアップを取っていなかったデータがランサムウェアで失われる、といった事態です。第2象限を後回しにし続けることは、将来の第1象限の火種を積み上げている行為だと捉えると、優先度の感覚が変わってきます。
自社がどの守りの課題を先に着手すべきか、体系的に把握できていないという場合は、まず現状の危険度を洗い出すところから始めることをおすすめします。当メディアでは、ひとり情シスの状況を10の質問でチェックできる診断コンテンツを用意しています。手を動かしながら自社の弱点を確認したい方は、あわせて参考にしてください。
よくある依頼を象限に当てはめてみる
ここまでの考え方を、実際によくある依頼のパターンに当てはめてみると、判断の感覚がつかみやすくなります。以下は典型的な依頼を4象限に仕分けた例です。あくまで一般的な目安であり、実際の業種や社内のシステム構成によって判断は変わる点に注意してください。
| 依頼の内容 | 象限 | 考え方 |
|---|---|---|
| 不審なメールを開いてしまった・添付ファイルを実行してしまった | 第1象限 | 情報漏えいやマルウェア感染の可能性があり、被害が拡大する前の初動が重要 |
| 基幹システムやサーバーが完全に停止し、複数部署の業務が止まっている | 第1象限 | 単一障害点(SPOF)が顕在化した状態。全社的な業務停止に直結する |
| 退職者・異動者のアカウント削除や権限変更 | 第3象限に見えて実は第2象限寄り | 個人単位の作業に見えるが、放置期間が長引くほど不正アクセスのリスクが積み上がるため、期限を決めて計画的に処理すべき |
| 新入社員のパソコン・アカウントの初期設定 | 第3象限 | 対応が遅れても影響は当人にとどまるが、初出社日という明確な期限があるため優先度は高め |
| 特定の社員のパソコンが起動しない | 第3象限 | 当人の業務は止まるが、他部署への波及は限定的。その日のうちの対応で足りることが多い |
| セキュリティソフトのライセンス更新・契約の見直し | 第2象限 | 期限を過ぎると保護が切れるリスクがあるため、更新期限から逆算してスケジュールに組み込む |
| 個人の好みによるパソコンの表示設定変更 | 第4象限 | 業務への影響がほぼない。手順書を渡して自己解決を促してもよい |
この一覧からも分かる通り、依頼が来た瞬間の「見た目の焦り度合い」と、実際に分類すべき象限は必ずしも一致しません。特に退職者のアカウント削除のように、単発の作業としては軽く見えても、期限管理を怠ると重大なリスクに発展する依頼は、意識して第2象限寄りに引き上げて扱う判断が必要です。
複数の緊急案件が同時に発生したときの対処
優先順位づけが最も試されるのは、第1象限に分類される緊急案件が同時に複数発生した場面です。ひとりで対応している以上、物理的に同時進行できる作業には限りがあります。こうした場面では、次の順番で考えると判断がぶれにくくなります。
- 人的被害・法的リスクに直結するものを最優先にする: 個人情報の漏えいなど、対応の遅れが法的な問題に発展しうる案件は、他の技術的な障害より優先度を上げて考える
- 被害が「今も拡大し続けているか」を確認する: すでに実害が確定していて、これ以上手を打っても状況が変わらない案件よりも、対応の遅れがそのまま被害の拡大につながっている案件を優先する
- 一時的な代替手段で影響を抑えられる案件は、応急処置だけ先に打っておく: 完全な解決に時間がかかる場合でも、被害の拡大を止める応急処置だけを先に済ませ、本格対応は後回しにするという判断も有効
- 対応できない案件は、早い段階で「誰かに助けを求める」判断をする: 開発会社の保守窓口、契約しているセキュリティベンダーのサポート、詳しい社員など、一人で抱え込まずに済む相手がいないかをまず確認する
同時多発的な緊急対応は、平常時のマトリクス判断だけでは対応しきれない場面です。あらかじめ「複数の緊急案件が重なったときは、この順番で考える」という自分なりのルールを一度決めておくと、実際にその場面が来たときに慌てず動けます。
一人で抱え込まず、外部の力を借りる判断基準
優先順位づけを工夫しても、そもそもの業務量が物理的な処理能力を超えている場合は、仕組みの改善だけでは解決しません。ここで検討すべきなのが、業務の一部を外部に委託する、あるいは保守契約の範囲を見直すという選択肢です。
外部委託を検討すべきサインとしては、次のようなものが挙げられます。
- 第2象限(緊急度は低いが影響範囲が広い)の課題が、着手できないまま何ヶ月も積み上がっている
- 専門知識が必要な判断(セキュリティ設計、システムの選定など)を、独学だけで補いきれていないと感じる
- 緊急対応の頻度が増え、本来の業務(総務・経理など)に支障が出始めている
こうした状況を経営層に伝える際は、「忙しいので人を増やしてほしい」という感覚的な訴えではなく、対応しきれていない業務の種類と、それを放置した場合に想定されるリスクをセットで説明すると、判断材料として受け取ってもらいやすくなります。既存の保守契約の対応範囲を見直し、これまで自分で対応していた業務の一部を保守契約に含めてもらうという交渉も、選択肢の一つです。外部に何をどこまで任せるかの整理は、優先順位づけと表裏一体の課題であり、内製と外部委託の役割分担を見直すきっかけにもなります。
優先順位づけの記録を、次の交渉材料に変える
後回しにした依頼とその理由を都度メモしておくと、単なる備忘録以上の価値を持つようになります。数ヶ月分たまった記録を振り返ると、「どの種類の依頼が繰り返し発生しているか」「どの依頼を継続的に後回しにせざるを得ないか」というパターンが見えてきます。
この記録は、次のような場面でそのまま交渉材料として使えます。
- 人員増強や外部委託の予算を経営層に相談する際の裏付け資料として
- 特定のシステムやツールが繰り返しトラブルの原因になっている場合、リプレイスの必要性を説明する根拠として
- 自分自身の業務内容を棚卸しし、評価面談などで担当業務の実態を説明する材料として
日々の対応に追われていると、こうした記録を残す余裕がないと感じるかもしれません。しかし、後回しにした案件を一言でもメモしておく習慣は、数ヶ月後の自分を助けるだけでなく、担当業務の実態を周囲に正しく理解してもらうための最も具体的な証拠になります。凝った記録である必要はなく、日付・依頼内容・後回しにした理由の3項目を表計算ソフトやメモアプリに書き留めるだけで十分に機能します。
優先順位を可視化する簡易フォーマット
記録や交渉材料としての価値を高めるために、依頼を書き留める際のフォーマットを簡単に決めておくと、後から見返したときの使いやすさが変わります。凝った管理ツールを新たに導入する必要はなく、普段使っている表計算ソフトやメモアプリで次の項目を並べるだけで十分機能します。
- 受付日: いつ依頼が来たか
- 依頼内容: 何を頼まれたか(一言でよい)
- 緊急度・影響範囲: 4象限のどこに分類したか
- 対応状況: 対応済み/対応予定日を設定して保留中/後回し中
- 後回しの理由: 対応しなかった場合、なぜそう判断したか
この5項目があれば、月末や四半期ごとに振り返ったときに、「後回しにした依頼のうち、結局どれだけの期間放置してしまったか」「同じような依頼が何度も繰り返し来ていないか」といった傾向を確認できます。特に、対応予定日を設定したまま先延ばしを繰り返している依頼があれば、それは第2象限の課題が実質的に機能不全に陥っているサインです。定期的な棚卸しのタイミングで、このリストを見返す習慣をつけておくとよいでしょう。
また、このフォーマットは経営層への報告にもそのまま転用できます。月次や四半期の報告の場で「今月対応した依頼は何件、後回しにした依頼は何件、その理由は何か」を数分で説明できる状態にしておくと、担当者の業務量が経営層にとって具体的にイメージしやすくなり、人員体制やツール導入の相談もしやすくなります。感覚的な「忙しさ」の訴えよりも、こうした記録に基づいた説明の方が、はるかに説得力を持ちます。
優先順位づけがうまくいかないときに疑うべきこと
マトリクスに沿って優先順位をつけているつもりでも、うまく回らないと感じる場合、次のような構造的な問題が背景にあることがあります。
- そもそも依頼の全体量が処理能力を大幅に超えている: この場合、優先順位づけのテクニックだけでは根本解決せず、外部への一部委託や人員体制の見直しを経営層に提案する材料が必要になります
- 緊急度の判断基準が社内で共有されていない: 担当者一人の感覚だけで緊急度を決めていると、周囲から「その判断はおかしいのでは」と疑問を持たれやすくなります。判断基準を明文化し、経営層の合意を得ておくことが有効です
- 後回しにした案件が記録に残らず、繰り返し同じ依頼が来る: 対応待ちの案件を一覧化する仕組みがないと、依頼者が「無視された」と感じて再度催促し、二度手間が発生します
これらの構造的な問題は、優先順位づけのテクニックの改善だけでは解決しきれません。業務量そのものが物理的に一人の限界を超えている場合は、優先順位を工夫する以前に、業務の一部を外部に切り出す、あるいは体制そのものを見直す判断が必要になります。
日々の優先順位づけの延長として、自分が長期不在になる場面への備えも避けて通れません。ひとり情シスが安心して休むために作っておく仕組みで、休暇前に整えておくべき体制を解説しています。
まとめ: 優先順位づけは「判断」ではなく「仕組み」で支える
ひとりで社内のIT関連業務を担う以上、すべての依頼に同じ熱量で対応することはできません。緊急度と影響範囲という2つの軸で依頼を仕分け、後回しにする理由を言葉にして残す。この基本を押さえるだけで、日々の判断の負担は大きく軽くなります。
そのうえで、依頼の一元管理、定型業務のマニュアル化、定期的な棚卸し、経営層との判断基準の共有といった仕組みを整えていくと、優先順位づけを「その都度のつらい判断」から「あらかじめ決めたルールに沿って処理するだけの作業」に変えていくことができます。優先順位づけに正解は一つではありませんが、判断の軸を持っているかどうかで、日々の負担も、周囲からの理解のされやすさも大きく変わってきます。
まずは自分が今抱えている依頼を書き出し、緊急度と影響範囲でマトリクスに仕分けるところから始めてみてください。特別なツールを新たに導入しなくても、手元の表計算ソフト1枚あれば今日から始められます。大切なのは完璧な分類ではなく、依頼を「見える化」し、後回しにした判断を意識的に言葉にして残す習慣そのものです。この習慣が積み重なることで、日々の場当たり的な対応から、根拠を持って説明できる業務運営へと少しずつ移行していけます。
そのうえで、自分の立場そのものをもう一度整理したいという方は、ひとり情シスという働き方の全体像を扱った記事もあわせて参考にしてください。日々の個別業務を体系立てて見直したい場合は、IT資産管理やアカウント管理、バックアップ設計など、守りを固めるための各実務記事も役立つはずです。優先順位づけは一度決めたら終わりではなく、会社の成長やシステム構成の変化に合わせて、判断基準そのものを見直していく継続的な取り組みでもあります。
優先順位づけに悩む依頼の一つとして、取引先から届くセキュリティチェックシートの回答実務のような、期限付きで急に降ってくる依頼もあります。緊急度と影響範囲の軸で仕分ける際の具体例として参考にしてみてください。
日々の依頼の中でも件数が多くなりがちな「ヘルプデスク対応」を効率化したい場合は『ひとり情シスのためのヘルプデスク効率化』、その中でも定番の「パソコンが遅い」という問い合わせへの対処フローは『「パソコンが遅い」問い合わせの対処フロー』で個別に扱っています。




