更改の検討は、計画的に始まるとは限りません。多くの場合、外部からの通知が入口になります。
もっとも多いのが、メーカーや保守ベンダーからの保守終了案内です。封筒を開けて日付を確認し、年度計画と照らし合わせる。ここから逆算が始まります。次に多いのが、更新見積もりの金額です。同等構成のつもりでも前回調達時より上振れし、そのまま稟議に出しづらい。三つ目が人の事情です。長年その環境を見てきた職員や担当者が異動する、あるいは地元の保守事業者が体制を縮小する。「触れる人がいなくなる」という状況が現実味を帯びたとき、検討が急に動き出します。
共通しているのは、準備が整う前に検討が始まるという点です。現行環境の把握が済んでいないうちに、スケジュールと予算の話が先行する。この順序の逆転が、後工程での調整を増やします。
更改の対象範囲を決める作業は、簡単そうに見えて手間がかかります。
公共機関では、庁内システム、住民向けサービス、内部事務、ネットワーク、端末、認証基盤、セキュリティー対策が相互に関係しています。1台のサーバーがファイル共有と認証と印刷を兼ねている、というのも珍しくありません。単純な置き換えのつもりで進めると、切り替え直前になって「この連携も対象だった」「この端末は別部門の管理だった」という論点が出てきます。
中小企業でも構造は同じです。ファイルサーバー、認証、業務アプリケーション、バックアップ、VPN、クラウドサービスを少人数で管理している場合、表面上は安定していても、実際には特定の担当者の記憶に支えられていることがあります。
ここで確認したいのは、機器の仕様ではなく運用の背景です。なぜその設定なのか。障害時に誰が判断しているのか。どの業務が止まると影響が大きいのか。この整理を飛ばして機器だけを新しくすると、古い課題がそのまま新しい環境に移ります。範囲を決める作業そのものが、更改の一工程だと考えたほうが実態に合います。
すべてを一度に見直せる案件は多くありません。予算、人員、スケジュール、既存システムの制約があるため、優先順位を決める必要があります。整理の起点になるのは、次の5つです。
現行資産、可用性、セキュリティー要件、運用体制、調達条件。
重要なのは、これらが独立していないことです。可用性を高めるには、冗長構成やバックアップだけでなく、障害時に誰がどう判断するかという体制が要ります。セキュリティー要件を強めれば、ログの確認や脆弱性情報の判断という運用が増えます。調達条件を固めるには、どこまでを内部で担い、どこからを外部に出すかを先に決めなければなりません。
つまり、1つの軸を動かすと他の軸が連動します。「セキュリティーは後で足せばよい」「運用は稼働してから考える」という進め方が難しいのは、この連鎖があるためです。
棚卸しでは、機器の台数を数えるだけでは足りません。確認したいのは、その基盤がどの業務を支えているかです。サーバー、ストレージ、ネットワーク機器、端末、クラウドサービス、認証基盤、バックアップ、セキュリティー製品を一覧化し、保守期限、利用部門、業務影響、管理者を並べます。
資料が古い場合は、棚卸し自体を更改プロジェクトの正式な工程として計上したほうが現実的です。ここを急ぐと、後工程で不明点が増え、結果的に調整コストが膨らみます。
可用性は、冗長化の有無だけで決まりません。どの業務が止まるとどの程度の影響が出るか。何時間以内に復旧したいか。どの時点のデータまで戻せればよいか。代替手段はあるか。この問いに答えられて初めて、必要な構成が見えてきます。
注意したいのは、すべてのシステムに同じ水準を求めないことです。重要度の低い領域まで高い要件にすると、費用と運用負荷が増えます。反対に、基幹となる業務の要件が曖昧なままだと、障害発生時に復旧方針を決められません。
セキュリティー要件は、更改の初期に整理しておきたい領域です。後から追加すると、ネットワーク構成、認証方式、ログ保存、監視設計、運用手順に影響が及びます。詳細は後段で扱います。
監視は誰が見るのか。障害対応はどこまで内部で行うのか。保守ベンダーへの連絡条件は何か。セキュリティーアラートはどの基準で上位に上げるのか。変更作業の承認は誰が行うのか。
これらが決まっていないと、基盤が新しくなっても判断は特定の人に集中します。運用ルール、手順書、役割分担まで含めて見直さない限り、体制は変わりません。
調達では、機器の価格に加えて、保守、運用支援、移行、検証、引き継ぎの範囲を分けて把握します。どこまでを必須要件とし、どこからを評価項目にするか。発注側の前提が曖昧なままでは、提案を比較する物差しが作れません。
更改後に負担として残りやすいのは、仕様書に明記されなかった領域です。代表的なものを挙げます。
移行と検証の工数。新しい環境を構築することと、既存環境から安全に移すことは別の作業です。データ移行、アカウント移行、接続確認、業務アプリケーションの動作確認、利用部門への周知、切り戻し手順。これらは構築費用の陰に隠れやすく、直前になって工数不足が判明します。
ログを誰が確認するか。取得要件は仕様書に書かれても、確認の担当と頻度、異常と判断する基準までは書かれないことがあります。ログは取得するだけでは証跡として機能しません。増やしすぎれば保管コストと確認負荷が上がり、絞りすぎれば必要なときに追えません。
保守範囲と業務復旧の差。ここは特に誤解が生じやすい点です。保守契約があることと、業務が復旧することは同じではありません。部品交換は含まれていても、システム全体の復旧や業務アプリケーションの動作確認は範囲外、というケースがあります。調達の段階で、保守範囲と復旧に必要な作業を切り分けておくと、障害時の混乱を減らせます。
引き継ぎ資料。構成図、設定一覧、運用手順、保守連絡先、障害時の確認手順。これらが残らなければ、数年後の更改時にまた同じ調査から始めることになります。更改は、次の更改への備えを作る機会でもあります。
更改が進むにつれ、当初は機器の入れ替えだった案件に、ID管理、EDR、ログ管理、脆弱性対応、バックアップ、証跡管理が加わっていく。公共案件ではよくある展開です。
ただし、後から要件を足すと、構成、費用、スケジュール、運用体制のすべてに影響します。要件を整理するときは、製品名から入らないほうが混乱しません。守るべき情報は何か、想定されるリスクは何か、必要な管理策は何か、運用で確認する項目は何か。この順に言語化してから、ID管理やEDR、ログ管理といった手段を検討します。
ID管理では、異動、退職、兼務、外部委託先の利用が重なるほど権限が複雑になります。ツールを入れても、異動情報を誰が登録するのか、承認フローをどうするのか、例外権限をどう扱うのかという運用は残ります。
EDRは、端末やサーバー上の不審な挙動を検知する選択肢です。ただし導入後に効いてくるのは、検知した後の動きです。誰が見るのか、誤検知をどう判断するのか、隔離や調査を行う条件は何か。ここが決まっていないと、アラート対応が新たな負担になります。少人数の体制であれば、外部の監視や一次対応を組み合わせる選択肢もありますが、その場合も最終判断の担当は発注側に残ります。
脆弱性対応では、適用の可否と業務影響を分けて考えます。すべての更新を即時適用できる環境ばかりではありません。業務アプリケーションとの相性、停止可能な時間帯、検証環境の有無、切り戻し手順を確認したうえで、優先順位を決めることになります。
なお、要件を最初から細部まで固めきれない場合もあります。政府機関等のIT調達では、仕様条件の決定や事業者の選定に必要な情報を、RFIやRFPによって取得することとされています。要件が定まらない段階で無理に書き切るより、情報収集を挟んで具体化する進め方は、民間の案件にも応用できる考え方です。
調達で悩ましいのは、比較しやすい指標と比較しにくい指標が混在することです。
見積金額は数字で並びます。一方、運用負荷は見積書には現れません。初期費用が抑えられている提案でも、監視設定や運用引き継ぎが限定的であれば、稼働後の作業は情報システム部門に残ります。逆に高く見える提案に、移行支援、手順書作成、監視設計、稼働後の問い合わせ対応が含まれていれば、内部工数を含めた比較では評価が変わることもあります。
政府機関等のIT調達に関する申合せでは、対象となる調達について、価格面のみでなく総合的な評価を行う契約方式を採用するものとされています。これは公共特有の手続きですが、考え方自体は、中小企業が複数のベンダーから提案を受ける場面にも当てはまります。
比較の前に、発注側で整理しておきたい情報があります。現行環境の構成、対象範囲、業務影響の大きいシステム、保守期限、セキュリティー要件、移行時に止められる時間、運用体制、外部に委託したい範囲、導入後に残してほしい資料、評価で重視する項目。これらが曖昧なままだと、提案の幅が広がりすぎて、価格差の理由を読み解けません。
外部支援を使うかどうかを検討する際、先に決めておきたいのが委託範囲と責任分界点です。
設計までなのか、構築までなのか、移行までなのか、稼働後の支援まで含むのか。障害対応は一次切り分けまでなのか、復旧作業までなのか。セキュリティーアラートは通知だけなのか、分析まで含むのか。ここが曖昧なまま契約すると、問題が起きたときに「誰が動くのか」が決まっていない状態になります。
判断の目安としては、業務上の優先順位に踏み込む領域は内部に残し、手順が定義できる領域は外部と組み合わせる、という切り分けが実務的です。どのシステムを優先するか、どの程度の停止を許容できるか、どの情報を守るべきかは、発注側が決める領域になります。現行環境の棚卸し、構成案の整理、設計、構築、移行、監視や一次対応の実施は、外部支援を活用できる領域です。
ここは、期待値を確認しておきたい部分です。
監視ツールを導入しても、通知を受ける仕組みができるだけでは運用は軽くなりません。効いてくるのは、通知後の判断ルールと対応手順が決まっているかどうかです。運用代行を利用しても、業務影響の判断や優先順位付けは残ります。ID管理ツールを導入しても、異動情報の登録と例外権限の扱いという運用は残ります。
そして、属人化は機器を更改しても自然には解消しません。設定の背景、例外運用の経緯、障害時の判断基準といった情報は、手順書に書かれていない形で個人に蓄積されています。これを解きほぐすには、更改のタイミングで資料化する以外に近道がありません。逆に言えば、更改は属人化を棚卸しできる数少ない機会でもあります。
外部支援は、判断を代わりに行うものではなく、判断しやすい状態を作るための手段と考えるほうが、期待と実態のずれが小さくなります。
更改は、必ずしも今すぐ全面刷新すべきという話ではありません。予算や業務影響を踏まえれば、延命や段階的な更改が現実的な場合もあります。ただし、見送るのであれば、どのリスクを受け入れるのかを言語化しておく必要があります。
保守期限を過ぎても、機器がすぐ止まるわけではありません。困るのは、故障が起きてからの選択肢が少ないことです。部品交換、メーカーサポート、セキュリティー更新が受けづらくなり、代替機の手配やデータ復旧、移行先の準備を短期間で行うことになれば、通常より費用も負荷も大きくなります。
属人化も、日常が回っているうちは問題として見えません。担当者の異動や長期不在が起きたときに、設定の背景や例外運用が分からず、変更作業も障害対応も止まる、という形で表面化します。
セキュリティー面では、OSやミドルウエアの更新が止まる、対応製品がなくなる、必要なログを取得できない、といった制約が出てきます。公共機関では説明責任や監査対応が、中小企業では取引先からの要求が、それぞれ後から効いてきます。
延期を選ぶ場合でも、保守範囲、代替手段、障害時の復旧手順、バックアップの復元可否、セキュリティー更新の状況は確認しておきたいところです。あわせて、いつ再判断するかを決めておくと、先送りが常態化しにくくなります。
点数を付ける必要はありません。「答えられるか、答えられないか」で分けてみてください。
現行の機器と業務システムの対応関係を、資料を見ずに説明できるか
止まると最も影響が大きい業務と、その許容停止時間を言えるか
夜間や休日にアラートが出たとき、最初に確認する担当が決まっているか
保守契約の範囲と、業務復旧に必要な作業の差を把握しているか
ログを取得している範囲と、確認する担当・頻度を説明できるか
外部に委託している範囲と、自社に残る判断を切り分けて書き出せるか
更改を延期する場合、受け入れるリスクと再判断の時期を決めているか
答えられない項目が、今回の更改で先に整理すべき領域です。
現行環境の棚卸しからです。サーバー、ネットワーク、端末、クラウドサービス、認証基盤、保守契約、バックアップ、セキュリティー対策の状況を整理します。重要なのは機器の一覧よりも、それぞれがどの業務に影響するかです。業務影響が分からないまま進めると、移行段階で想定外の停止や調整が発生します。
機器保守や物理環境の管理負荷が下がるケースはあります。ただし、必ず下がるとは限りません。クラウドでもアカウント管理、権限管理、ログ確認、費用管理、セキュリティー設定、障害時の切り分けは必要です。既存システムとの連携が多い場合、移行後の運用がかえって複雑になることもあります。自治体の基幹業務システムでも、移行後の運用経費や運用体制が論点として残っています。移行方式は、運用体制とセットで判断するのが現実的です。
製品名だけでなく、守りたい情報、必要な管理策、ログ取得、監視、脆弱性対応、保守範囲、委託先の責任範囲まで整理して反映できると、比較の物差しが揃います。ただし、最初から細部まで決めきれない場合もあります。その際は、RFIなどで情報を集めてから要件を具体化する進め方が考えられます。避けたいのは、後付けで足すことです。
保守期限、代替手段、障害時の復旧方法、バックアップの復元可否、セキュリティー更新の状況です。「まだ動いているから」という理由だけで先送りすると、障害が起きたときに選べる手が限られます。受け入れるリスクと、いつ再判断するかを決めておくとよいでしょう。
現状調査、構成案の整理、機器調達、設計、構築、移行、運用支援、セキュリティー対策の整理などは相談できる領域です。一方、業務上の優先順位、許容できる停止時間、守るべき情報、予算判断は発注側に残ります。外部支援は判断をなくすものではなく、判断に必要な情報を整え、実行を支えるものと考えると、範囲を決めやすくなります。
対象範囲の決め方、セキュリティー要件を初期に整理する順序、価格以外の観点を含めて提案を比較する考え方は、規模を問わず応用できます。委託元や取引先からセキュリティー対策の説明を求められる場面が増えており、証跡や運用体制を説明できる状態にしておく必要性は共通しています。
公共のITインフラ更改では、セキュリティー、運用、調達を別々の工程として扱うと、稼働後に負担が残りやすくなります。現行資産の把握が不十分なまま進めれば移行時の調整が増え、セキュリティー要件を後から足せば構成と費用とスケジュールに影響し、運用体制が決まっていなければ属人化はそのまま持ち越されます。
一方で、すべてを一度に刷新する必要があるとも限りません。現行資産、可用性、セキュリティー要件、運用体制、調達条件を並べたうえで、自社や自団体にとってどこから手を付けるかを決める。この順番を決めること自体が、更改の最初の作業といえます。
横河レンタ・リース株式会社では、ITインフラの機器提供に加え、設計・構築、運用支援、セキュリティー対策の整理についてご相談を承っています。更改を検討する段階で、現行環境と運用課題の整理から一緒に確認したい場合は、お気軽にお問い合わせください。