「全部クラウドにすれば楽になる」は現場では簡単に崩れます。経営層向けのTCO比較で移行判断が出ても、現場では画面表示の遅延、PDF／帳票の改ページ崩れ、夜間バッチの遅延、問い合わせ対応手順の不備などの実務的な問題が露呈し、手戻りになります。本稿では情シスの現場観点で、PoCで必ず実測すべき3項目と承認までの最短フローを示します。
なぜTCO先行が危険か（要点）
TCOは重要ですが、ユーザー体感（画面遅延や表示崩れ）、印刷環境依存（フォント・改ページ）、運用オペレーション（問い合わせ→復旧時間）は数値だけでは見えません。承認会議でTCO表のみを根拠に移行を決めると、本番での差し戻しが発生しやすくなります。会議で合意すべきは「PoCで何を実測するか」です。
PoCで必ず実測すべき3項目（結論）
- 画面レスポンス：ユーザーが感じる遅延を主要操作で計測（例：操作応答<1秒、完全読み込み<3秒を目安に基準化）。計測CSVと録画を証跡にする。
- PDF／帳票の実機印刷：クラウド環境から実機プリンタへ印刷し、フォント埋め込み、改ページ、余白、バーコード解像度を確認。印刷結果は複数部保存して会議に提出。
- 問い合わせからの復旧手順：想定問い合わせを実地で再現し、Runbookに従って復旧時間を計測。ログの場所・アクセス権・エスカレーション経路を明文化する。
判断軸と現場シナリオ（優先順位の付け方）
判断は次の3軸で行い、それぞれに合格基準を定める：1) 問い合わせ対応（応答性・オペレーション）、2) 画面／PDF／帳票の一貫性、3) データ配置と接続制約（法令・監査）。これらのどれがクリティカルかでPoC対象の優先度を決めます。
典型的PoCシナリオ（現場で使える例）
- 問い合わせ重視：頻繁に遅延問い合わせが来る画面をPoC対象に。再現手順、必要ログの一覧を用意し、応答時間を計測して承認証跡とする。
- 帳票重視：月次帳票・請求書は必ず実機印刷で検証。印刷差異が修正不能なら帳票処理はオンプレに残す判断基準とする。
- データ配置重視：個人情報や法令で制約のあるデータはオンプレ残置やハイブリッド配置を検討。保存場所やネットワーク経路を実測して証跡を添付する。
失敗パターンと回避策（現場の実例ベース）
典型的な失敗は「証跡不足」と「代替手順不備」です。以下は起きた事例と回避手順の概要。
事例1：帳票の改ページ崩れ
承認時は問題が無かったが、本番で月次帳票の改ページが崩れ顧客対応と手作業でのPDF再整形が発生。回避策はPoCで実機印刷を必須化し、印字差が修正不能ならオンプレ継続を承認条件にすること。
事例2：夜間バッチの遅延
クラウド移行後、ネットワークピークでバッチ処理が遅れ業務開始に影響。回避策はPoCで本番負荷に近いデータでバッチ実行ログを取得し、SLAに対する許容閾値を承認基準にすること。
PoCと承認までの最短フロー（テンプレ）
PoCは3点（画面レスポンス・PDF実機印刷・問い合わせ復旧手順）を最優先で定義し、チェックリストとRunbook雛形で承認を短縮します。未解決の不一致が残る場合は移行を止める判断軸を残してください。
例：1週間のタイムライン
- Day0（キックオフ）— 検証対象の決定、担当と会議提出用の合格基準を確定。
- Day1–3 — 画面レスポンス検証：再現手順で計測、スクショ／動画／CSVで証跡保存。
- Day4–5 — PDF実機印刷：クラウド→実機プリンタで印刷、印刷見本を写真で複数部保存。
- Day6 — 問い合わせ復旧検証：想定問い合わせを再現し、Runbookで復旧時間を計測。
- Day7 — 承認資料作成：スクショ、印刷写真、バッチログをまとめて運用レビューへ提出。
PoCで出すべき最小の証跡
- スクリーンショット（操作前後で差分、日時・担当を明記）
- PDF実機印刷の写真（原本と並べた比較、プリンタ名記載）
- バッチ実行ログ（タイムスタンプ付き、最低1日分を提示）
- 問い合わせ再現手順と復旧時間の記録（時系列で誰が何分で何をしたか）
Runbook（雛形の要点）
Runbookは「誰が」「何分以内に」「何をするか」を具体化する。例：重大障害発生時は1) 5分以内に1st対応者がログ取得とスクショ、2) 15分以内に2ndへエスカレーション、3) 30分以内にオンプレ復旧手順開始、のように具体的な時間と行動を記載してください。抽象的な役割分担は避けます。
まとめ：導入判断と小さく始める順番
導入判断（即決できる基準）
- PoCの3項目が全て合格なら段階移行を進め、会議では合格証跡を添付して承認を得る。
- 1項目でも重大影響があれば、その機能はオンプレ残置または段階移行とする。
- 法令上の制約があるデータは原則オンプレまたは専用ハイブリッド配置とする。
小さく始める順番（優先度）
- 問い合わせ再現（最重要）
- 画面レスポンスの計測
- PDF／帳票の実機印刷確認
- バッチ実測（本番に近いデータ）
- データ配置・接続確認（法令・監査対応）
見送る条件（移行停止の判断基準）
- 印字崩れやフォント差異が修正不能、または運用コストで吸収できない場合
- 法令や契約でデータ移転が禁止される、あるいはログ要件を満たせない場合
- Runbookでの実地テストができず、復旧時間がSLAを満たせない場合
よくある質問（簡潔回答）
どの業務を最初にPoCすべきですか？
ユーザー影響が大きい順。問い合わせ頻度が高い画面、顧客へ送る帳票、夜間バッチで業務開始に影響する処理の順で優先します。
PDF／帳票の印字差やフォント問題はどう検証すれば良いですか？
クラウド環境から実機プリンタへ印刷し、比較写真を保存してください。フォント埋め込み、改ページ、余白、バーコードの読み取り確認を必須項目に含めます。
障害時のオンプレ⇄クラウド切替は本番で試すべきですか？
まずステージングで手順を検証し、本番では短時間のウィンドウでフェイルオーバー試験を行う。結果をRunbookに明記して承認資料としてください。
コメント