情シスチームが複数部署の脱Excel要望を同時に抱えたときの優先順位付け

社員が100人を超えると、脱Excelの要望が届く頻度も、届く経路も変わります。30〜100人規模のひとり情シスの時代は、要望が届くこと自体がまだ珍しく、「まず全部を自分が見て、できることから手をつける」という進め方でも何とか回っていました。しかし100〜300人規模になると、営業部・経理部・製造部・人事部といった複数の部署が、それぞれ独立して「うちのExcel運用をそろそろどうにかしたい」と申し出てくる状況が同時多発的に発生します。1人の担当者が全部署の要望を順番にさばいていた頃とは異なり、チーム体制になっても要望の総量が担当者の増員を上回るペースで増えることは珍しくありません。このガイドでは、複数部署からの脱Excel要望が同時に積み上がったとき、チームとしてどう優先順位を決め、後回しにする部署にどう伝えるかを扱います。

この記事で分かること

複数部署から脱Excel要望が集中する状況で、情シスチームが優先順位をどのような基準で決め、どうやって各部署に納得してもらうかを解説します。個々の要望に対する技術的な移行手順（データ突合や移行先選定）は扱いません。それぞれ部署をまたいだExcel台帳の重複、統合前にやるべき突き合わせ作業、チーム体制での移行先選定・承認フローに譲ります。

なぜ100-300人規模で要望が「同時多発」するのか

要望が同時に集中する背景には、いくつかの構造的な要因があります。一つは、社内での情シスチームの認知度が上がることです。ひとり情シスの時代は「そんな担当がいたのか」という認識だった部署も、チーム体制になり実績が積み上がってくると、「相談すれば対応してもらえる」という期待が社内に広がります。この期待の広がり自体は良い兆候ですが、結果として要望が一気に集まる原因にもなります。

もう一つは、Excel運用の限界が複数部署でほぼ同時期に顕在化しやすいという事情です。社員数が同じペースで増えていれば、営業部も経理部も製造部も、似たようなタイミングで「Excelファイルが重くて開けない」「複数人での同時編集で上書き事故が起きた」といった限界サインに直面します。VBAマクロで自動化されていた業務が、作成者の異動でブラックボックス化する事態も、複数部署でほぼ同時に発生することがあります。

• 社内での情シスチームへの信頼が高まり、相談件数そのものが増える
• 組織拡大のペースが部署間で似通っているため、Excelの限界に直面する時期も重なりやすい
• ある部署の脱Excel事例が社内で共有されると、「うちも」という要望が連鎖的に増える

「先着順」で受けてはいけない理由

要望が集中したとき、最も避けたい対応は「相談が来た順番に着手する」という先着順の運用です。一見公平に見えますが、実際には次のような問題を引き起こします。

先着順で進めると、たまたま声の大きい部署、あるいは経営層に近い部署の要望が優先されやすくなります。これは意図的な優遇ではなく、単に「気づいた人が先に声を上げた」だけの結果であることが多いのですが、後回しにされた部署からは「なぜあちらが先なのか」という不公平感につながります。

さらに深刻なのは、業務影響の大きさと着手順が一致しないことです。営業部の細かい不便さを解消する要望が先に着手され、経理部の月次締め作業で毎回2時間残業が発生している深刻な問題が後回しになる、というようなミスマッチが起きやすくなります。チーム体制になったからこそ、こうした場当たり的な受け方から脱却し、明確な優先順位の基準を持つ必要があります。

優先順位を決める3つの評価軸

複数の要望を比較検討する際は、次の3つの軸で評価することをお勧めします。単一の基準（例えば「先に頼んできた順」）だけで決めるのではなく、複数の軸を組み合わせることで、より納得感のある優先順位付けができます。

この3軸を掛け合わせると、「業務影響度は高いが対応工数は小さい」要望が最優先候補として浮かび上がりやすくなります。逆に、「業務影響度は低いが対応工数も大きい」要望は、優先度を下げて後回しにする判断がしやすくなります。

• 業務影響度・リスク・工数の3軸それぞれを、高中低の3段階で仮に評価してみる
• 評価は情シスチーム内だけで完結させず、要望元の部署にもヒアリングした上で行う（部署側の体感と情シス側の見立てがずれていることは珍しくない）
• 評価結果は一覧表として可視化し、要望元の部署にも共有できる状態にしておく

評価を「チームの合議」で行う意味

30〜100人規模のひとり情シスの時代は、優先順位の判断は担当者1人の裁量で決めることができました。しかしチーム体制になると、判断の妥当性を1人の主観だけに委ねると、他のメンバーから見て納得感の薄い優先順位になりがちです。

評価軸に沿った採点は、チームメンバー全員で持ち寄り、合議で最終順位を決めることをお勧めします。特に、部署ごとの担当を分けている場合、担当者によって「自分が見ている部署の要望を優先したくなる」という無意識のバイアスがかかりやすいため、複数人でチェックし合う体制が有効です。

「最初は各自が自分の担当部署の要望を強く推してしまい、収拾がつかなくなりました。今は月初のミーティングで全要望を一覧にして、3つの評価軸で点数をつけてから議論する形にしています。点数化することで、感情的な押し合いにならずに済むようになりました」

この合議のプロセス自体を、チームとしての意思決定フローの一部として位置づけると、優先順位付けだけでなく、その後の移行先選定などの判断とも一貫性を持たせやすくなります。チーム体制での意思決定フロー全体の設計については、チーム体制での移行先選定・承認フローで扱っています。

後回しにする部署への伝え方

優先順位を決めた後、避けて通れないのが「今回は対応が後回しになる」ことを要望元の部署に伝える作業です。この伝え方を誤ると、せっかく合理的な基準で決めた優先順位であっても、部署側の不満につながってしまいます。

伝える際に押さえておきたいポイントは次のとおりです。

1. 「対応しない」ではなく「いつ頃対応する見込みか」を伝える: 完全な却下ではなく、見通しを示すことで、要望元は自部署で当面どう凌ぐかを検討できるようになる
2. 優先順位の判断根拠を簡潔に説明する: 「なぜ他の部署が先なのか」を、評価軸に基づいて説明できる状態にしておく。感覚的な説明ではなく、業務影響度・リスク・工数という基準に基づいた説明であれば、納得を得やすい
3. 応急処置の提案ができないか検討する: 本格的なシステム移行までは待ってもらうとしても、Excel運用のまま実行できる応急的な改善策（Excelの同時編集ロック・上書き事故を防ぐ方法のような運用改善）を提案できると、待ってもらう間の不満を和らげられる

後回しにされる部署の担当者は、多くの場合、日々の業務で実際に困っている当事者です。「順番を待ってほしい」という伝達だけで終わらせず、その部署が待っている間にできる工夫を一緒に考える姿勢を見せることが、長期的な信頼関係の維持につながります。

優先順位を定期的に見直す

一度決めた優先順位は、固定的なものとして扱わず、定期的に見直す前提で運用してください。新しい要望が随時追加される一方、既存の要望の緊急度も時間とともに変化します。ある時点では優先度が低かった要望が、担当者の退職や業務量の急増によって、急に緊急対応が必要な案件に変わることもあります。

• 月次、あるいは隔週など、要望一覧を見直す定例のタイミングを設ける
• 新規の要望が入るたびに、既存の一覧に追加し、評価軸に沿って仮評価をつける
• 緊急度が急変した要望がないか、都度確認する

見直しの結果、優先順位が入れ替わることがあれば、その理由も含めて要望元の部署に共有すると、透明性のある運用として受け入れられやすくなります。

要望の背景にある「シャドー台帳」を見逃さない

複数部署からの要望を捌いていく過程で、実は正式に依頼される前から、各部署が独自に応急的なExcel運用を続けているケースに気づくことがあります。要望として声を上げてくる部署はまだよいほうで、声を上げないまま独自の台帳を作り続けている部署が潜んでいることも珍しくありません。

優先順位付けの作業と並行して、こうした「まだ声が上がっていないが実は問題を抱えている部署」がないか、意識的に目を配ることをお勧めします。特に、過去に一度システム化した業務領域で、再び部署ごとのローカルExcelが復活しているケースは見落とされがちです。この再発パターンについては、部署ごとのローカルExcelが復活する問題で詳しく扱っています。

優先順位の可視化がチーム内の摩擦を減らす

優先順位を決める仕組みそのものよりも重要なのが、その仕組みと結果を「見える化」しておくことです。誰がどのような基準で、どの要望をいつ対応する予定なのかが一覧で分かる状態にしておくと、チームメンバー間での「なぜあの案件が先なのか分からない」という疑問や、要望元の部署からの問い合わせにも、一貫した根拠を持って答えられるようになります。

可視化した優先順位一覧は、システム管理台帳と同様に、チームの共有資産として継続的に更新していくものと位置づけてください。単発のリストとして作って終わりにせず、定例の見直しサイクルに組み込むことで、初めて実効性のある運用になります。

優先順位付けを支えるツールと運用の型

複数部署からの要望を捌く仕組みは、専用のプロジェクト管理ツールを新たに導入しなくても、既存の環境で十分に構築できます。100〜300人規模のチームであれば、次のような要素を備えた簡易的な管理表があれば、多くの場合十分に機能します。

• 要望の受付経路を1つに統一する: メール・チャット・口頭など複数の経路で要望を受け付けていると、抜け漏れが発生しやすくなる。「要望はこのフォームまたはこのチャンネルに集約する」というルールを周知する
• 受付から評価、着手までのステータスを可視化する: 「受付済み」「評価中」「対応予定」「対応中」「完了」といった簡単なステータス区分を設け、要望元の部署からも進捗が見える状態にしておく
• 評価結果と判断理由をセットで記録する: 点数だけでなく、「なぜこの評価になったか」の一言メモを添えておくと、後から見返した際にも判断の根拠を追跡できる

このような管理表は、複雑な専用ツールでなくても、共有スプレッドシートで十分に運用できます。重要なのは、ツールの高機能さではなく、チーム全員が同じ場所を見て状況を把握できることです。

優先順位が低いと判断した要望への継続的なフォロー

一度優先順位を下げた要望であっても、そのまま放置してよいわけではありません。要望元の部署からすると、「後回しにされたまま忘れられているのではないか」という不安が残りやすく、この不安が情シスチームへの不信感につながることがあります。

1. 後回しにした要望も、定期的な見直しの対象に必ず含める: 見直しのたびに、優先度を下げた理由が今も有効かどうかを確認する
2. 状況に変化があれば、要望元に連絡する: 対応時期の見通しが変わった場合、良い方向にも悪い方向にも、変化があった時点で連絡を入れる
3. 完全に対応しない判断をした場合は、その理由を明確に伝える: 「対応しない」という結論自体は避けられない場合もあるが、理由を曖昧にしたまま放置することは避ける

このフォローを怠ると、要望元の部署は「言っても無駄」と感じ、正式な要望を出さずに独自の対応（部署内だけで完結する応急的なExcel運用など）へ流れてしまうことがあります。この現象は、統合後のシステムに対しても同様に起こりうるため、優先順位付けの運用と、シャドー台帳の再発防止は根底でつながっている課題です。

チーム内での役割分担と優先順位付けの関係

優先順位付けの仕組みを機能させるには、チーム内での役割分担も影響します。特定のメンバーが特定の部署の窓口を担当している体制では、その担当者が窓口となっている部署の要望を優先したくなる心理的なバイアスがかかりやすいことは、すでに触れたとおりです。

このバイアスを軽減するための工夫として、優先順位の最終決定には、要望元の部署を直接担当していないメンバーを最低1人は加えるという運用が有効です。第三者的な視点を意図的に入れることで、評価の客観性を保ちやすくなります。担当分担そのものの設計原則は、システム別・業務別の分担表の作り方と共通する部分が多く、優先順位付けの仕組みを作る際にも参考にできます。

経営層からの要望が割り込んできたときの扱い

複数部署からの要望を優先順位付けの仕組みに沿って運用していても、経営層から直接「これを優先してほしい」という依頼が入ることがあります。この種の割り込みは、せっかく整備した優先順位の仕組みを崩す要因になりやすいため、あらかじめ扱い方を決めておくとよいでしょう。

• 経営層からの依頼であっても、既存の評価軸（業務影響度・リスク・工数）に沿って一度評価する: 特別扱いせず、同じ土俵で評価することで、他の要望との比較が可能になる
• 評価の結果、他の要望より優先すべきと判断されれば、その理由を明確にした上で優先順位を調整する: 「経営層からの依頼だから」という理由だけで押し通すのではなく、業務影響度の観点からも妥当性を確認する
• 優先順位が変わったことで後回しになる要望には、変更の理由も含めて速やかに共有する: 突然順番が変わったと感じさせないよう、経緯を丁寧に説明する

経営層からの依頼を特別ルートとして完全に別枠で処理してしまうと、チームが積み上げてきた優先順位付けの仕組み自体の信頼性が損なわれます。同じ評価軸で扱いながら、必要に応じて柔軟に順位を調整するという姿勢が、仕組みの一貫性を保つ鍵になります。

優先順位付けの仕組みを新メンバーに引き継ぐ

情シスチームに新しいメンバーが加わった際、優先順位付けの仕組みそのものをどう引き継ぐかも重要な観点です。仕組みが個人の暗黙知として運用されていると、その仕組みを設計した本人が異動・退職した途端に、評価基準が曖昧になり、再び場当たり的な対応に逆戻りしてしまうリスクがあります。

1. 評価軸とその運用方法を文書化しておく: 業務影響度・リスク・工数という3つの軸をどう採点するか、具体的な判断基準の例とあわせて記録しておく
2. 過去の優先順位付けの事例を新メンバーに共有する: 実際にどのような要望が、どういう理由で優先・後回しにされたかの事例を見てもらうことで、評価の感覚をつかんでもらいやすくなる
3. 最初のうちは、新メンバーの評価を既存メンバーがレビューする期間を設ける: 評価に慣れるまでの間、独断で決めさせず、既存メンバーとの摺り合わせを行う

この引き継ぎのプロセスを丁寧に行うことで、優先順位付けの仕組みが特定の個人に依存せず、チーム全体の共有知として定着していきます。

優先順位付けの仕組みそのものへの部署側の理解を得る

優先順位付けの評価軸や運用ルールをどれだけ丁寧に設計しても、要望を出す部署側がその仕組みの存在自体を知らなければ、「なぜ後回しにされるのか分からない」という不満は解消されません。仕組みを整備した際は、情シスチーム内だけで完結させず、社内向けに周知する機会を設けることをお勧めします。

• 要望の出し方と、評価の流れを簡潔にまとめた案内を社内向けに共有する: 「相談すればすぐ対応してもらえる」という過度な期待と、「相談しても無視される」という不信の両方を防ぐため、実際のプロセスを可視化する
• 評価軸（業務影響度・リスク・工数）の考え方を、専門用語を避けて説明する: 部署側の担当者がITに詳しいとは限らないため、平易な言葉で伝える
• 仕組みについての質問を受け付ける窓口を明確にしておく: 「この基準はどういう意味か」といった疑問に、都度答えられる体制を整える

このような周知を行うことで、後回しにされた部署も「合理的な基準で判断されている」と理解しやすくなり、優先順位付けの仕組みそのものへの信頼が高まります。

対応不能な要望をどう見極めるか

複数部署からの要望の中には、優先順位を下げるだけでなく、そもそも情シスチームとして対応すべきではない、あるいは対応が現実的に不可能な要望が含まれていることもあります。こうした要望を見極める視点も、優先順位付けと合わせて持っておく必要があります。

• 予算・体制の制約から明らかに対応が困難な要望: 現在のチーム規模や予算では実現できない大規模な要望は、優先順位を下げるのではなく「対応不可」として早期に伝え、代替案を一緒に検討する
• 部署の業務プロセス自体に問題があり、システム化では解決しない要望: Excelの限界ではなく、そもそもの業務フローに無駄がある場合、システム導入よりも業務プロセスの見直しを先に提案すべきケースがある
• 他のツール・サービスで既に代替手段が存在する要望: 新規に開発・導入するまでもなく、既存の契約済みツールの機能で対応できる場合、その旨を案内するだけで解決することもある

これらの見極めを行わずにすべての要望を「いつか対応する」リストに積み上げてしまうと、リストが肥大化し、優先順位付けの仕組み自体が機能不全に陥ります。対応すべき要望と、そうでない要望を早期に仕分けることも、優先順位付けの重要な一部です。

優先順位付けの仕組みが機能しているかを振り返る

優先順位付けの仕組みを一度整えた後も、それが実際に機能しているかを定期的に振り返ることをお勧めします。仕組みを作った当初はうまく機能していても、要望の数や種類が変化していく中で、評価軸や運用方法が実態に合わなくなっていくことがあります。

• 評価軸に沿って優先順位をつけたにもかかわらず、結果的に納得感の薄い判断になっていないか: 評価軸自体の見直しが必要なサインかもしれない
• 優先順位付けにかかる時間が、要望の増加に見合わず膨らんでいないか: 仕組みが煩雑になりすぎている場合、簡略化を検討する
• 要望元の部署からの不満の声が減っているか、あるいは増えているか: 仕組みの実効性を測る最も直接的な指標の一つになる

こうした振り返りを、半期に1回程度のペースで行うことで、優先順位付けの仕組みそのものを、組織の変化に合わせて継続的に改善していくことができます。仕組みは一度作ったら完成ではなく、実際の運用を通じて磨かれていくものだという認識を持っておくことが大切です。

兼任メンバーが多いチームでの優先順位付けの難しさ

100〜300人規模の情シスチームは、必ずしも全員が専任担当者とは限りません。総務や経理と兼任しているメンバーがチームに含まれている場合、優先順位付けの運用にも独自の配慮が必要になります。

• 兼任メンバーが対応可能な時間帯・工数をあらかじめ考慮して優先順位を決める: 専任メンバーと同じペースで対応できることを前提にすると、兼任メンバーに割り振られた要望が計画どおりに進まない事態を招く
• 兼任業務の繁忙期を踏まえたスケジュール調整を行う: 経理と兼任しているメンバーであれば、決算期などの繁忙期に新たな要望対応を割り振らないよう配慮する
• 兼任メンバーの負荷が特定の時期に集中しないよう、年間を通じた要望対応の分散を意識する: 優先順位付けの評価軸に、対応時期の柔軟性という観点を加えることも一案

兼任メンバーを抱えるチーム構成そのものは、100〜300人規模でしばしば見られる過渡的な体制です。この体制の制約を踏まえた優先順位付けができるかどうかが、無理のない運用を続けられるかどうかの分かれ目になります。

優先順位付けの記録が次年度の計画立案に役立つ理由

日々の優先順位付けの記録は、単に目の前の要望を捌くためだけのものではなく、蓄積していくことで、翌年度以降の情シスチームの体制計画・予算計画を立てる際の貴重な材料になります。

• どの部署から、どのような種類の要望が多く寄せられているかの傾向が見えてくる: 特定の部署からの要望が継続的に多い場合、その部署の業務プロセス自体に構造的な課題がある可能性を示唆している
• 対応工数の見積もりと実績の差異を振り返ることで、次回以降の見積もり精度が上がる: 「思ったより時間がかかった」という記録が積み重なれば、次の計画で余裕を持った見積もりができるようになる
• 後回しにし続けている要望が一定数残っている場合、それはチームの体制強化を検討すべきサインになる: 優先順位付けの限界そのものが、増員や体制変更の必要性を示す根拠として使える

このように、優先順位付けの記録を単なる作業ログとして扱うのではなく、チームの意思決定を支えるデータとして活用する視点を持つことで、日々の運用がより大きな価値を生み出すようになります。

要望のカテゴリ分けで判断のスピードを上げる

要望の件数が増えてくると、毎回一から評価軸に沿って詳細に検討していては、判断そのものに時間がかかりすぎてしまうことがあります。過去の要望を振り返り、典型的なパターンをあらかじめカテゴリ分けしておくと、新しく寄せられた要望の評価を素早く進められるようになります。

• 過去に対応した要望を、内容の似た系統ごとに分類してみる: 「顧客管理系」「勤怠・経費系」「社内共有・掲示系」のように、業務領域ごとにグルーピングする
• 各カテゴリについて、典型的な業務影響度・リスク・工数の目安をあらかじめ整理しておく: 新しい要望が来た際、まず似たカテゴリがないかを確認し、大まかな評価の当たりをつけられるようにする
• カテゴリに当てはまらない特殊な要望だけ、個別に詳細な評価を行う: すべての要望に同じ手間をかけるのではなく、典型的なパターンは効率化し、特殊な案件に評価の労力を集中させる

このカテゴリ分けは、要望の件数が一定以上に増えてきたチームにとって、評価作業そのものの負荷を下げる実務的な工夫になります。

まとめ: 優先順位付けは「断る技術」でもある

複数部署からの要望が同時多発する状況で最も重要なのは、限られたチームのリソースをどこに配分するかを、納得感を持って決め、伝えることです。業務影響度・リスク・工数という3つの評価軸を軸にした優先順位付けは、チームとしての判断に一貫性を持たせるだけでなく、後回しにせざるを得ない部署への説明責任を果たす土台にもなります。

「全部の要望に応えられない」という現実は、チーム体制になっても変わりません。変わるのは、その現実にどう向き合い、どう説明責任を果たすかという姿勢です。評価軸を明確にし、判断のプロセスを可視化し、後回しになる部署にも誠実に向き合う。この積み重ねが、情シスチーム全体への信頼を保ちながら、限られたリソースで最大の効果を上げる道につながります。