サーバー更改の稟議書に何を書くか｜EOL・障害影響・TCOの整理例

稟議が止まるのは、技術の正しさが伝わっていないからとは限らない

要点 : 差し戻しの多くは、技術の説明が足りないからではなく、判断に必要な比較材料と時期の根拠が揃っていないことに起因します。

現場では、次のような状況が起こります。保守終了の一覧を添えて申請したものの、「なぜ今なのか」「他の方法はないのか」と問われて止まる。あるいは、いったん保留となり、翌年度に同じ資料を作り直すことになる。担当者としては必要性を説明したつもりでも、決裁者の側には比較の材料が届いていない、という状態です。

判断基準は単純です。提出した資料の中に、対象、期限、選択肢、費用の範囲、見送った場合に残る状態という5つが揃っているかどうか。不足しているのが情報量なのか、それとも比較できる形式になっていないのかを最初に切り分けます。情報量が不足している場合は追加調査が必要ですが、形式の問題であれば、手元にある情報の並べ替えで解決できることがあります。

注意点として、承認の手順や決裁権限は企業ごとに異なります。本記事では一般的な承認プロセスを前提とせず、どの企業でも共通して問われる判断材料の中身に絞って扱います。

なぜ更改の順序と時期を説明しにくいのか

説明が難しくなるのは、期限、影響、費用、体制という性質の異なる情報を、ひとつの軸で語ろうとするためです 。

保守終了を迎える機器が複数あり、それぞれ期限も業務上の重要度も異なる。この状態で「更改が必要です」とまとめて説明しようとすると、話が散らかります。期限が近いものと業務影響が大きいものが一致しないことも珍しくありません。担当者が1人、あるいは兼任という体制であれば、調査そのものに割ける時間も限られます。

判断基準として、まず情報を4つの性質に分けて扱います。

そのうえで、単体で申請するか、複数年の計画としてまとめて申請するかを決めます。一括申請は全体像を示せる一方、承認後に停止調整と作業負荷が同時期へ集中します。単体申請は個々の説明が軽くなりますが、同じ説明を繰り返す手間が残ります。どちらが優れているというものではなく、自社の体制で実施しきれる形を選ぶという判断です。

更改そのものの実務工程については、【 対象の洗い出しから更改までの進め方 】で扱っています。本記事はその内容を社内説明へ変換する部分を担います。

期限の情報と影響の情報は別に扱う

期限は外部から与えられる条件であり、社内の都合では動きません。一方、影響は自社の業務構造によって決まります。この2つを同じ表に混ぜて優先度を1つの数値にまとめると、決裁者が根拠を追えなくなります。分けて示したうえで、両方を見て順序を決めた理由を添える形が扱いやすくなります。

担当者が1人の場合に起きること

調査、見積もり取得、業務部門との調整、資料作成が同じ人に集中すると、期限が近い対象から順に処理せざるを得なくなり、影響の大きい対象が後回しになることがあります。これは判断の誤りではなく体制の制約です。稟議の中で体制上の前提として明示しておくと、実施時期の説明との整合が取りやすくなります。

稟議の対象を洗い出し、現行環境とEOL・EOSL状況を書き出す

要点 : 稟議に載せる対象は、ハードウェア、OS、ミドルウェア、業務アプリケーション、保守契約、周辺機器の6区分で確認すると漏れが減ります。

サーバー本体の保守終了だけを見て申請し、承認後にデータベースやバックアップソフトウェアのサポート期限、あるいはUPSやネットワーク機器の状態が判明する。追加申請が必要になり、実施時期がずれる。こうした手戻りは、対象範囲を機器単位で捉えたときに起こりやすくなります。

判断基準は、同時に期限を迎える構成要素があるかどうかです。同時期であればまとめて1件として扱う余地があり、離れていれば分割したほうが説明が簡潔になります。

注意点として、EOL・EOSLの時期や保守の提供条件は、メーカーおよび契約によって異なり、変更される場合があります。個別製品の期限は、必ずメーカーの公表情報で確認してください。参照した時点もあわせて記録することが望まれます。段階の名称と順序もメーカーによって異なるため、対象製品のメーカーが使う名称に合わせて確認してください。

管理表そのものに持たせる項目や更新のルールは、【 台帳に持たせる管理項目と更新ルール 】で扱っています。

ハードウェアとソフトウェアで期限が揃わない場合

先に期限を迎える側に合わせると、後から迎える側の更改が短期間で再度必要になることがあります。逆に遅い側へ合わせると、その間の保守が受けられない期間が生じます。どちらを選ぶ場合も、揃わないという事実と、選ばなかった側にどのような状態が残るかを稟議に明記しておくと、後の追加申請の説明が容易になります。

保守契約の更新条件を確認する

保守を延長できるかどうかは、契約の内容によって決まります。延長できる場合でも、対応時間、部品の供給条件、対象範囲が従来と同じとは限りません。契約先へ更新可否を確認する際に、更新後の条件がどう変わるかまであわせて確認しておくと、次章以降の比較で使える情報になります。

対象の区分ごとに何を確認するかは、手元で一覧にしておくと申請時の抜け漏れを防げます。

対象一覧の記入枠、洗い出しから実施後の記録までの工程チェック、停止調整のメモ欄をまとめたシートです。すべての項目を一度に埋める必要はなく、どこまで進んでいるかを確認する用途で使えます。

影響度と緊急度を、決裁者が比較できる形に変換する

要点 : 障害影響は、停止する業務、影響を受ける人数と拠点、代替手段の有無、復旧に必要な体制の4点に分けると、比較できる形になります。

「止まると業務に支障が出ます」という説明だけでは、複数の申請が並んだときに順序の根拠になりません。決裁者は、どれを先に承認すべきかを比べる必要があるためです。技術的な深刻さと、業務上の影響の大きさは必ずしも一致しません。

判断基準として、対象ごとに次の4点を同じ粒度で記述します。

このうち、決裁の場で効くのは代替手段の欄です。代替手段があるなら緊急度は下がり、ないなら順序は上がります。技術的な指標よりも、業務が続けられるかどうかのほうが判断材料として機能します。

影響が大きい対象と期限が近い対象が一致しない場合は、どちらを先に申請するかを決める必要があります。期限を優先すれば保守の空白は避けられますが、業務リスクの高い対象が残ります。影響を優先すればその逆です。いずれの場合も、選ばなかった側について、次にいつ判断するかを併記しておくことが実務上は重要です。

注意点として、障害の発生確率や想定被害額を、根拠のない数値で補わないでください。数値を置くのであれば、自社の障害記録や業務部門への確認結果など、出所を示せるものに限ります。

優先順位そのものの評価手法については、【 EOL・障害影響・運用負荷で優先順位を評価する方法 】で扱っています。本記事は、その評価結果をどう記述するかに絞っています。

対応方針の候補を同じ基準で並べる

要点 : 延命、更新、クラウド移行、レンタルの利用、第三者保守の活用は優劣ではなく、期限までの猶予、業務要件、体制、契約条件のどれを優先するかで適合が変わります。

更新前提で1案だけを提出すると、「他の方法は検討したのか」と問われて差し戻される。逆に選択肢を並べすぎて、どれも中途半端な情報量になり、比較にならない。どちらもよくある状態です。

判断基準は、各案について同じ項目数で記述できているかどうかです。1案だけ詳しく、他は簡略という書き方は、検討したという形式だけを整えたものとして受け取られます。

以下は判断材料として整理した比較観点であり、個別環境での適合を保証するものではありません。各選択肢の実際の条件は契約内容とメーカーの公表情報によって決まるため、申請前に自社の対象製品について確認してください。

注意点として、いずれの選択肢についても、特定の提供元や方式を優れている、あるいは適さないと断定しないでください。表に入るのは条件であり、評価ではありません。横河レンタ・リースが提供する選択肢も、この表の中では他と同じ基準で扱う対象です。

各選択肢の技術的な判断条件は【 延命と更新の4つの選択肢と判断条件 】で、Windows Server環境固有の確認点は【 OS・AD・アプリ・保守を分けて確認する 】で扱っています。

比較表に「更改しない」を1行入れる理由

更改しないという選択肢を空欄のままにすると、更新を前提に検討したと受け取られることがあります。廃止や統合が短期間で確定している場合は現実的な選択肢であり、確定していない場合でも、判断を保留したときに残るリスクと再検討の時期を書くことで、他の選択肢との比較が成立します。この1行があることで、他案を検討した事実が形式ではなく内容として示せます。

費用をTCOで整理し、予算化の形にする

要点 : TCOは、調達、構築、移行、運用、保守、撤去・返却までを対象範囲として定義し、確定値と概算値を区別して記載します。

見積もりに書かれた導入費用だけで申請し、承認後に移行作業の外部委託費、既存機器の撤去や返却にかかる費用、あるいは運用開始後に継続して発生する支出が判明する。金額そのものより、想定の範囲が事前に示されていなかったことが問題として残ります。

判断基準は、費用項目の一覧が対象範囲として先に定義されているかどうかです。金額が確定していない項目があること自体は、申請の妨げにはなりません。確定していないという事実と、その前提条件が書かれていれば判断材料になります。

社内工数を金額として計上するか、体制上の制約として記述するかは、自社の扱いに合わせます。金額化しない場合でも、必要な作業時間と担当者の状況は書き残しておくと、実施時期の説明と整合します。

注意点として、本記事では勘定科目、資産計上の条件、耐用年数、仕訳例、税務上の取り扱いは扱いません。これらは自社の経理部門または専門家の領域です。また、金額の相場を一般的な水準として示すことも避けます。同じ構成でも、契約条件や既存環境によって変わるためです。

調達方式によって支出の実態がどう変わるかは【 調達方式によって支出の実態がどう変わるか 】で、費用の全体像の捉え方は【 TCOと投資判断の基本的な考え方 】で扱っています。

確定値と概算値を分けて書く

同じ表の中で混在させると、全体が概算として扱われるか、逆に全体が確定として受け取られます。列を分けるか、注記で区別してください。概算の項目には、何が決まれば確定するのかを1行添えておくと、追加承認の要否を判断しやすくなります。

複数年で申請する場合の分割

年度をまたぐ場合、初年度に発生する支出と、次年度以降に継続して発生する支出を分けて示します。分割の単位を機器ごとにするか、工程ごとにするかで説明のしやすさが変わるため、社内の予算の区切り方に合わせて決めます。

実施スケジュールと停止影響、関係者調整を先に示す

要点 : 時期の根拠は、期限からの逆算で、調達リードタイム、事前検証、移行、業務部門との停止調整の4区間を明示することで示せます。

承認は得たものの、業務部門との停止調整が付かず、実施が期限に間に合わない。あるいは、事前検証の期間を見込んでいなかったため、切り替え当日に想定外の事象が出て切り戻すことになる。承認の可否だけを目標にすると、こうした状態が起こります。

判断基準は、期限から逆算した各区間について、実施内容と調整相手が書かれているかどうかです。

事前検証やPoCを実施範囲に含めるかどうかは、判断が分かれる部分です。含めれば期間と費用が増え、含めなければその分の不確実性が残ります。省略する場合は、何が確認されないまま残るのかを稟議に明記しておくことが実務上の要点です。

注意点として、調達にかかる期間や作業に必要な時間は、構成、時期、調達先の状況によって変わります。一般的な目安として書かず、自社が取得した見積もりや回答を根拠としてください。

実施体制が社内で確保できるかどうかについては、【 保守と運用の体制をどこまで自社で担うか 】が判断の参考になります。

事前検証を申請に含めるかどうか

既存の業務アプリケーションが動作するか、既存システムとの接続が維持できるかは、構成が変わるほど確認の必要性が高まります。逆に、同一構成での機器更新であれば、確認範囲を絞れる場合があります。含める、含めないのどちらかを一律に推奨するのではなく、構成変更の度合いに応じて範囲を決める形が扱いやすくなります。

停止時間の伝え方

停止する時間の長さだけを伝えると、業務部門は判断できません。どの業務が、いつからいつまで、どの範囲で使えなくなるのか。切り戻す場合の判断時刻はいつか。この3点を添えると、調整が具体化します。

決裁者向けに要点をまとめ、見送った場合の状態も示す

要点 : 決裁者が最初に必要とするのは、対象、期限、選択肢、費用の範囲、判断を先送りした場合に残る状態の5点です。

資料は揃っているのに、決裁の場で説明が長くなり、結論が出ない。多くの場合、原因は情報の不足ではなく、読む順序が決裁者向けになっていないことです。調査の経緯から順に並べると、結論に到達するまでが遠くなります。

判断基準として、冒頭に置く5点が1ページに収まっているかを確認します。詳細な調査結果は後段に置き、冒頭では比較に必要な情報だけを示します。

先送りした場合に残る状態は、次の4点について自社で確認した内容を記述すると、推測を含まない説明になります。

いずれも確認結果をそのまま記載し、確認できていない項目は未確認であることを明記します。断定できない事項を強い表現で書くと、記述の信頼性そのものが問われるためです。

また、本記事では稟議書の様式や文例そのものは示しません。記載する項目と提示する順序までが、どの企業でも共通して使える範囲だからです。保守終了後にどのようなリスクが生じうるかの全体像は、【 EOL・EOSLの違いと保守終了後に生じるリスク 】を参照してください。

承認後に残る作業と、次回の稟議を軽くする継続管理

要点 : 更改後に台帳へ戻す情報は、構成、契約条件、次回の期限、判断の根拠の4点であり、これが次回の稟議の初期資料になります。

更改が完了した時点で作業を終えると、数年後に同じ調査を一から行うことになります。当時なぜその選択をしたのかが残っていないため、次の担当者は判断の前提から作り直すことになります。担当者が交代している場合は、この負担がそのまま属人化の再生産になります。

判断基準は、更新の責任者とタイミングが決まっているかどうかです。項目が整っていても、更新されなければ次回には使えません。

このうち、次回に最も効くのは判断の根拠です。選ばなかった選択肢とその理由が残っていれば、次回は前提が変わった部分だけを検討すればよくなります。

注意点として、台帳の項目設計そのものを一から作り込む必要はありません。既存の管理表がある場合は、上記4点が含まれているかを確認する形で足ります。詳細は【 台帳に持たせる管理項目と更新ルール 】を参照してください。運用を引き継げる状態にしておく視点については、【 運用を引き継げる状態にしておく視点 】が参考になります。

よくある質問

Q1. 稟議書に決まった様式はありますか

様式や承認の流れは企業ごとに異なるため、共通する様式はありません。本記事では、様式ではなく記載する項目と提示する順序を整理しています。自社の規程や過去の申請書式を確認したうえで、本記事の項目を当てはめてください。

Q2. EOLとEOSLのどちらを期限として書けばよいですか

段階の名称と順序はメーカーによって異なります。他社の例を当てはめず、対象製品のメーカーが公表している情報を確認し、その名称と時期をそのまま記載してください。参照した時点もあわせて記録しておくと、後の更新時に役立ちます。用語そのものの違いは【 EOL・EOSLの違いと保守終了後に生じるリスク 】で解説しています。

Q3. 費用が概算しか出せない段階でも申請できますか

概算であること自体は問題になりにくく、確定値と概算値が区別されていないことのほうが判断を妨げます。概算の項目には、何が決まれば確定するのかを添えてください。

Q4. 更改しないという選択肢も書く必要がありますか

比較の妥当性を示すうえで、同じ基準の1行として並べておくことを検討する価値があります。この行がないと、更新を前提に検討したと受け取られることがあります。

Q5. 勘定科目はどう書けばよいですか

本記事では扱いません。個別の会計処理は自社の経理部門または専門家の領域です。調達方式によって支出の実態がどう変わるかという考え方は、【 調達方式によって支出の実態がどう変わるか 】で整理しています。

まとめ

サーバー更改の稟議で問われるのは、機器の新しさではなく、判断に必要な材料が比較できる形で揃っているかどうかです。本記事で扱った判断軸は次の5つです。

• 対象を6区分で確定させること

• 障害影響を4項目に分けて記述すること

• 選択肢を同じ項目数で並べ、更改しない場合も1行として含めること

• TCOの対象範囲を先に定義し、確定値と概算値を区別すること

• 期限から4区間で逆算し、実施できる時期を示すこと

次に行う作業としては、まず手元の管理情報を6区分に当てはめ、どの区分の情報が不足しているかを確認するところから始められます。不足が情報量の問題なのか、比較できる形式になっていないのかを切り分けたうえで、影響の記述と選択肢の比較へ進みます。承認後は、判断の根拠を台帳へ戻しておくことで、次回の検討を前提の確認から始められます。

お問い合わせ (総合) | 法人向けパソコン (パソコン) ・計測器レンタルなら横河レンタ・リース