やりたいIT施策が多すぎるとき、何から始めるか｜優先順位を決める4つの視点

「やりたいことは一通り挙がっているのですが、どれから手を付けるべきか決められなくて」—クラウドや社内基盤の見直しを検討している企業から、そうした相談をいただくことがあります。

老朽化したサーバーの更新、認証の強化、生成AIの導入、日々の運用改善。どれにも取り組む理由があります。それでも、予算と担当者の時間には限りがあります。

「何が必要か」は分かっていても、「何から始めるか」を決めるのは難しい。この記事では、その判断に使う4つの視点を整理します。先に一つだけ書いておくと、実際に施策を並べてみると、多くの施策が同じ一点で止まっていると分かる場面がよくあります。

この記事でわかること

• 施策の優先順位を決めるときに見る4つの視点

• 視点が衝突したときに、どれを先に使うか

• 「やりたいことが多すぎる」と感じるときに、実際に起きていること

※本記事は、クラウド・インフラ領域の施策を中心に想定しています。個々の製品選定ではなく、複数の施策をどう並べるかに絞っています。

4つの視点は、同列ではありません

優先順位を決めるときに見るのは、期限・依存関係・業務への影響・実行体制の4つです。ただし、この4つは役割が違います。

期限と依存関係は、動かせない制約です。これを満たさない施策は、そもそも選択肢になりません。業務への影響は、並べるための材料です。制約を満たした施策の中で、順番を決めるために使います。実行体制は、最後の確認です。決めた順番が実行できるかを確かめます。

つまり、使う順番は制約で絞る → 材料で並べる → 体制で確かめるです。先に「どれが一番重要か」から考え始めると、重要ではあるが今は着手できない施策の検討に時間を使うことになります。制約から入ったほうが、結果的に早く決まります。

1. 期限：いつまでに判断し、着手する必要があるのか

期限がある施策は、その日付と根拠を確認します。

サポート終了、契約更新、拠点移転といった外部要因による期限と、社内で設定した希望日は分けて考えます。前者は動きませんが、後者は調整できます。混ぜたまま議論すると、動かせるものと動かせないものの区別がつかなくなります。

そのうえで注意したいのが、サポート終了日や契約更新日そのものは、本当の期限ではないということです。本当の期限は、そこから逆算した着手期限です。調達や申し込みにかかる期間、検証の期間、そしてメンテナンスウィンドウ—止められる日は限られます—を積み上げると、動き出さなければならない時期は、思っているよりかなり手前になります。

実際にあった相談を一つ挙げます。契約更新の1か月前に、「Azureのサブスクリプションを移動したい」というご相談をいただいたことがありました。

ヒアリングを進めると、移したいのはサブスクリプションだけではなく、テナントそのものでした。新しいテナントの開設、サブスクリプションの新設、VPN回線の新規申し込み。必要な作業を書き出すと、1か月に収まる量ではありません。サブスクリプションの移動だけであれば、ぎりぎり間に合う可能性はありました。しかし契約まわりの手続きと、回線の開通にかかる期間を踏まえると、ご要望どおりの期日でお応えすることはできませんでした。

最終的には期間を見直し、計画を立て直したうえで移行を完了しています。「いつまでに終わらせたいか」ではなく「その日に終わらせるには、いつ動き出す必要があるか」から考える必要があるのは、こういう理由です。

なお、期限があるからといって、求められている対応をすべて一度に実施するとは限りません。当面必要な範囲と、その後の改善を分けられるかも検討します。

この節の着地点: 「締切が近い順」では判断しません。期限の根拠、間に合わなかった場合の影響、準備に必要な時間をそろえます。

2. 依存関係：先に整えなければ、進められないことは何か

施策は、それぞれ独立しているとは限りません。優先度の高い施策を実現するために、別の準備を先に終えておく必要がある場合があります。

そして、クラウドやインフラ領域では、この依存の多くがIDに集まります。

• 社内文書を参照する生成AIの展開 … 誰がどの文書にアクセスできるかが整理されていなければ、展開できません

• デバイス管理の開始 … ユーザーとデバイスの紐付けが前提になります

• 条件付きアクセスによるアクセス制御の強化 … 前提そのものがIDです

• ファイルサーバーのクラウド移行 … 権限設計が、そのままIDのグループ設計になります

• 退職者対応・監査対応の整備 … 起点はIDの棚卸しです

方向性の違う施策が、同じ場所を通っています。

つまり、「やりたいことが多すぎる」と感じているとき、実際には複数の施策が同じ一点で止まっていることが少なくありません。 施策の数が多いのではなく、前提が一つ欠けている状態です。

IDの整備は、思っているより重い

さらに見落とされやすいのが、その前提であるIDの整備そのものが、調査から始まる重い作業になりやすいという点です。

最近よくいただくのが、「PCはActive Directoryに参加しているが、Microsoft 365経由でEntra IDも使っている。この状態から、ID管理をEntra IDへ移していきたい」というご相談です。定石としては、まずADとEntra IDを連携し、そこから段階的に移していく進め方になります。

ただ、実際に現状を確認すると、ADのドメインが `.local` のままだったり、Entra ID側のアカウントが初期の onmicrosoft.com ドメインのままだったりします。ゴールは明確でも、現状との隔たりが大きく、影響を一つずつ整理しながら進める必要が出てきます。

さらに、「ADをなくしたい」という話であっても、証明書の発行やプリンターの認証など、気づかないうちにADに依存しているシステムが残っていることがあります。長く運用されている環境ほど、担当者が何代か替わり、引き継がれないまま塩漬けになっている設定が出てきます。

依存関係は、施策と施策の間だけでなく、いま動いている環境の中にも隠れています。 そしてIDの整備は、「先に片付けておく小さな前提」ではなく、現状調査から始まる一つの施策です。

だからこそ、後回しにすると影響が大きくなります。順位が変わるのではなく、前提が変わるわけです。

ただし、すべての基盤整備が終わるまで他を止める必要があるかは、別の判断です。利用者や対象データを限定すれば、準備と並行して試せる場合もあります。「IDが整うまで何もしない」は、多くの場合やりすぎです。

この節の着地点: 実現したい施策から逆算して、先に必要な準備と、並行して進められる作業を分けます。複数の施策が同じ前提を待っているなら、その前提の優先度は自動的に上がります。

3. 業務への影響：何が、どれだけ変わるのか

ここからは、制約を満たした施策を並べるための材料です。施策名だけを並べても、重要性は比較できません。誰のどの作業が軽くなるのか、障害時にどの業務がどれだけ止まるのか、放置するとどうなるのか。それぞれを具体化します。

ここで難しいのは、インフラの施策は「やらないと何が起きるか」が見えにくいことです。動いているうちは価値がゼロに見えるため、新しく何かを生み出す施策と並べられると、予算の議論で負けやすくなります。

有効なのは、効果ではなく止まったときのコストで語ることです。「サーバーが古い」ではなく「このサーバーが止まると、どの業務が何日止まり、代わりの手段がない」と説明できれば、判断する側にも比較ができるようになります。

この節の着地点: 効果は金額だけに限りません。業務時間、停止の影響、対応負荷など、判断に使える形で説明します。

4. 実行体制：導入から運用まで、誰が担えるのか

最後に、決めた順番が実行できるかを確認します。予算が確保できても、実行できるとは限りません。確認するのは次の4点です。

• 社内で判断・調整を担う人は誰か

• 現場の検証や教育に必要な時間を確保できるか

• 外部へ依頼する範囲と、社内で担う範囲は明確か

• 導入後の問い合わせや保守を誰が受け持つか

特に見落とされやすいのが、最後の項目です。「導入する人」と「運用する人」が違う場合、その引き継ぎを設計しておかないと、運用が始まってから止まります。

導入は企画部門、運用は情報システム部門、という体制はよくあります。以前、企画部門がAWSを前提に進めていたものの、運用を引き継ぐ情報システム部門はAzureが主戦場だった、という場面に出会ったことがあります。引き継ぎの直前になって、運用担当者がAWSをまったく触ったことがないと分かりました。結果として、個別の作業手順だけでなく、AWSそのものの初期運用の手引きから用意することになりました。

前提となる技術が違えば、手順書を渡すだけでは引き継げません。「誰が運用するのか」は、製品や基盤を選ぶ段階から判断材料に含めておく必要があります。

この節の着地点: 重要性に加えて、実行できる条件を確認します。体制が足りなければ、対象を絞る、段階を分ける、支援を確保するといった方法を考えます。

「今やる・準備する・保留する」に落とす

4つの視点で整理すると、判断は次のような形になります。実際の支援現場でも、こうした組み合わせをよく見かけます。

3行目に注目してください。IDの棚卸しは、単体では地味で後回しにされやすい作業です。しかし2つの施策がこれを待っていると分かった瞬間に、優先度が変わります。もちろんこの順序は一例で、セキュリティ上の切迫した問題があれば判断は変わります。

そして、保留する施策にも再検討の時期や条件を付けておきます。「担当者が確保できたら」「限定した検証で効果を確認できたら」など、次の判断につながる形で残します。条件のない保留は、そのまま忘れられます。

まとめ

優先順位を決めるときに見るのは、期限・依存関係・業務への影響・実行体制の4つです。使う順番は、制約で絞り、材料で並べ、体制で確かめる。この順で進めると、議論が早く収束します。

そして、「やりたいことが多すぎる」と感じたときは、施策の数を疑う前に、複数の施策が同じ前提を待っていないかを確認してみてください。多くの場合、そこにIDの整備があります。

それぞれの施策について「なぜ今やるのか」「なぜ準備にとどめるのか」を関係者で共有しておけば、状況が変わったときにも見直しやすくなります。

まずは、検討中の施策を3つ挙げて、この4点を一枚に整理してみてください。情報が足りない項目が見えれば、次に何を調べるべきかも、そこで明確になります。