社内で共有されている情報の出どころを、一度たどってみてください。ニュース記事か、販売店からの連絡か、他社の担当者から聞いた話か。出どころによって、自社に当てはまるかどうかは変わります。
自社の条件が書かれているのは、契約書と注文書、窓口からの正式な案内、販売元が公開している情報の三つです。順番が重要です。まず契約書で自社が何をどう契約しているかを特定し、そのうえで公開情報を見れば、どの条件に該当するかを照合できます。逆の順序だと、公開情報の一般的な条件を自社の条件だと思い込むことになります。製品名が同じでも、Versionや契約時期が違えば条件は異なります。
契約書を開いても、どこを見ればよいか分からない状態は珍しくありません。ソフトウェアの契約は、次の四つの観点で該当箇所を探すと整理しやすくなります。
契約の期間。買い切りか、期間を定めた契約か。契約書の冒頭か期間に関する条項にあります。
数量の数え方。契約書に数量は記載されていますが、その数字が何を数えたものかは単位の定義を見ないと分かりません。不明なまま自社の構成に当てはめても、試算は成立しません。
製品のまとまり。単体の契約か、複数の機能をまとめた形か。まとめた形なら、何が含まれるかの一覧が必要です。
サポートの区分。問い合わせができるかだけでなく、修正プログラムの提供が含まれるか、期間はいつまでかを確認します。
この四つは契約書のどこかに書かれています。読み取れない場合、それ自体が確認事項です。
判断に必要な情報が社内の複数の場所に分かれていることも、把握を難しくします。例えば次のような状況が考えられます。影響額を出すよう指示されたが、契約書が見つからない。調達部門に聞くと機器の購入に含まれていたはずと言われ、注文書を探すと確かに一行だけ記載がある。しかし数量の単位も更新日も書かれていない。販売店に問い合わせると担当者が変わっており、確認に一週間かかると言われた。技術的な検討に入る前に二週間が過ぎた、というケースです。
技術部門は構成規模を把握していても、契約の主体や購入経路を知らないことがあります。機器と一緒に手配された場合や前任者の時代の契約では、社内に確認できる人が残っていない状況も考えられます。販売店経由では確認に時間がかかることがあるため、判断期限から逆算して早めに動き出す必要があります。
確認は契約側の情報に絞ります。構成側の棚卸しとは作業を分けた方が効率的です。確認するのは次の七項目です。
|
確認対象 |
具体的に見る内容 |
確認先 |
見つからない場合 |
|
契約書と注文書 |
契約の名義、契約日、対象製品、契約期間 |
社内の契約書類、調達部門 |
調達部門・経理の記録を確認し、販売店へ照会する |
|
対象製品とVersion |
製品名、エディション、Version |
契約書、管理画面の登録情報 |
管理画面の登録情報から特定する |
|
購入経路 |
直接購入か、販売店経由か、機器との同時購入か |
注文書、調達部門、経理 |
機器の注文書に含まれている場合がある |
|
数量と単位 |
契約している数量と、その数え方 |
契約書、管理画面の登録情報 |
管理画面の登録情報を確認する |
|
更新時期 |
次の更新日、更新の手続き期限 |
契約書、販売店 |
販売店へ照会する |
|
保守の終了時期 |
サポートがいつまで受けられるか |
契約書、販売元の公開情報 |
販売元の公開情報を確認する |
|
問い合わせ窓口 |
条件を確認できる相手が誰か |
過去のやり取り、調達部門 |
過去の見積書・請求書の発行元をたどる |
最も見落とされやすいのが対象製品とVersionです。契約条件は製品とVersionの組み合わせで決まるため、ここが特定できないと、公開情報を見ても自社がどれに該当するか判断できません。管理画面の登録情報と契約書の記載が一致しているかも確認します。
検証環境や拠点分が別契約の場合があります。本番環境だけで試算すると後から対象が増えるため、契約の一覧を作る際は対象範囲の網羅性を先に確認してください。
契約書だけで分からない項目は窓口に照会します。うまくいかないのは、値上げの影響を教えてほしいという聞き方です。相手は自社の構成を知らないため、一般的な回答しか返せません。特定できている情報を先に示し、確認したい項目を列挙してください。
|
問い合わせ文面の例 |
|
弊社の下記契約について、条件の確認をお願いいたします。 |
|
【 確認できている情報 】 |
|
【 確認したい事項 】 |
|
【 背景 】 |
5番目と6番目が本題です。1番目から4番目を先に示すことで、相手は契約を特定したうえで回答できます。時間がかかる項目を先に把握できれば、社内の日程も組み直せます。
確認内容は契約ごとに一枚にまとめます。ばらばらの場所にあると、説明のたびに集め直すことになります。契約書で確認できたこと、窓口の回答 ( 回答日と回答者を含む ) 、未確認事項 ( 照会先と照会日 ) を分けて記載してください。空欄のままだと、未確認なのか確認しても分からなかったのかが区別できません。
なお、ホストや仮想マシンの構成そのものの洗い出しは、VMware環境の棚卸し方法|移行検討前に確認する構成・契約・依存関係で扱っています。本記事は契約側、そちらは構成側という分担です。両方そろうと、影響の試算ができるようになります。
回答が得られたら、影響を費用、サポート範囲、構成変更の制約、更新作業の負荷に分類します。
|
分類 |
確認する内容 |
見落とすとどうなるか |
|
費用 |
契約の単位と数え方、自社構成での試算 |
金額の議論だけが先行する |
|
サポート範囲 |
区分に含まれる範囲、使える機能、修正プログラムの提供と期間 |
移行後に必要な機能や修正が受けられない |
|
構成変更の制約 |
増設・構成変更を行う際の考え方 |
想定外の費用が後から発生する |
|
更新作業の負荷 |
更新の手続き、社内での予算計上の方法 |
更新のたびに社内調整が発生する |
費用は、契約の単位や数え方が自社の想定と違っていた場合、同じ構成でも算出方法が変わります。窓口から得た数量の定義を自社の構成に当てはめてください。定義が未確認のままの試算は、根拠のない数字です。
サポート範囲は、修正プログラムの提供が含まれるか、期間はいつまでか、現在使っている機能がその区分で使えるかを分けて確認します。提供が受けられないと、脆弱性が公表されても適用できるものがない事態が起こり得ます。自社の環境でどの範囲まで提供が必要かを先に整理しておくことが、条件確認の判断軸になります。これはセキュリティ運用の要件そのものです。
構成変更は、契約の単位が変わると増設時の考え方も変わります。同じ感覚でホストを追加すると、想定外の費用が発生します。契約形態が変われば、更新手続きや予算計上の仕方も変わります。
費用だけを議題にしないでください。増加分だけを取り出すと、議論が値上げにどう対抗するかに偏ります。運用面の制約は、その後の数年間の動き方を左右します。
なお契約側では、更新の意思表示がいつまでに必要かを押さえてください。契約書記載の更新日ではなく、手続きの期限です。ただし実際の判断期限は、保守期限、移行に必要な期間、予算計上の時期から逆算します。手順はVMware移行はいつ始めるべきか|今すぐ動く環境・待てる環境の判断基準で扱っています。
経営層が判断できる資料には、影響額の根拠、対応しない場合のリスク、判断期限の三つが必要です。経営層は費用の増加そのものより、業務が止まるかどうかといつまでに決めるべきかを問う場合があります。
影響額の根拠では、試算の前提を明示します。どの契約を対象に、どの構成で、どの条件で試算したのか。その条件をどこから得たのかも書きます。契約書の記載か、窓口の回答か、まだ推定か。前提のない数字は、質問が出た時点で説明できなくなります。
対応しない場合のリスクは、現状のまま更新した場合の費用と、使い続けた場合に受け入れるリスクを並べます。判断期限は、逆算した期限を根拠とともに示します。いつまでに決めないとどの選択肢が使えなくなるか、という形にすると先送りされにくくなります。確認中の項目は、そのまま確認中と書く方が結果的に信用されます。
報告の前に、次の六項目が埋まっているかを確認してください。
試算の前提 ( 対象契約・構成・条件 ) と、その情報の出どころを明示している
確定していることと、未確定のことを分けて書いている
対応しない場合に何が起きるかを書いている
判断期限とその根拠を書いている
費用以外の三つ ( サポート範囲・構成変更・更新負荷 ) に触れている
数字には試算であることを明記している
自社の契約が特定できていない可能性があります。契約名義、注文書番号、対象製品とエディション、Version、数量を先に示し、確認したい項目を番号を振って列挙してください。相手が契約を特定できれば、回答は具体的になります。それでも得られない場合は、契約書記載の窓口へ照会します。
契約の形態、対象製品とVersion、契約時期、購入経路、構成によって異なるため、一般的な目安は示せません。他社の事例や記事の数字を当てはめると、実際とかけ離れる可能性があります。自社の契約内容と構成を確認し、対象となる構成を明示して窓口に試算を依頼してください。
契約条件の変更が自社にどう効くかは、自社の契約書と窓口からしか分かりません。伝聞で議論を進めると、報告の段階で根拠を示せません。本記事で扱った判断軸は次の五つです。
自社の条件が書かれているのは、自社の契約書と窓口からの正式な回答だけであること
契約書は、契約の期間、数量の数え方、製品のまとまり、サポートの区分の四つの観点で読むこと
窓口への問い合わせは、特定できている情報を先に示し、確認事項を列挙すること
影響は費用、サポート範囲、構成変更の制約、更新作業の負荷の四つに分けて捉えること
確認結果は、契約書で確認できたこと、窓口の回答、未確認事項に分けて記録すること
次に行う作業としては、まず手元の契約情報を七項目に当てはめ、どの項目が不足しているかを確認するところから始められます。契約側が揃ったら、次は構成側との突き合わせです。候補の比較へ進む段階については、VMware代替候補をどう比較するか|技術・運用・契約・移行の判断軸で扱っています。
契約書の所在が分からない、購入経路がたどれない、対象製品とVersionが特定できない。こうした状態で止まっている場合、確認の進め方を外部の視点で整理する方法もあります。
横河レンタ・リース株式会社では、日本ヒューレット・パッカード社のPlatinumパートナーとして、仮想環境のアセスメントから設計、構築、移行、運用保守までを提供しています。契約情報と構成情報の突き合わせや更新期限の整理からご相談いただけます。