ITシステム保守管理のPoC・プロトタイプ・モックアップ開発について

ITシステム保守管理のPoC・プロトタイプ・モックアップ開発は、見た目、操作性、実運用での実効性の順に確かめていくと、本導入の可否を判断しやすくなります。

まず3段階の違いと進め方を説明し、続けて期間と費用、移行の判断、よくある失敗を取り上げます。

▼全体ガイドの記事
・ITシステム保守管理の完全ガイド

保守管理体制PoCにおけるモックアップ・プロトタイプ・PoCの違い

モックアップ、プロトタイプ、PoCを、見た目・フォーマット、動作・操作感、概念・実効性の3段階で示す図
確認する対象が、外観から実運用に近い効果へ移っていきます。

保守管理ツールの検証では、モックアップ、プロトタイプ、PoCを検証の深さと目的に応じて使い分けます。段階ごとに確認事項を決めておくと、無駄の少ない計画を立てられます。

モックアップ(見た目・フォーマットの検証)

モックアップは、保守管理ツールの見た目を確認する最初の段階です。本契約の前に、保守ベンダーなどにサンプルを作成してもらいます。

確認するのは、報告の見せ方と中身です。

  • レポートの形式:SLA監視ダッシュボードや運用レポートの見た目。
  • 報告内容:報告の粒度やインシデント分析の質。

サンプルは1か月分を作成してもらいます。実際にシステムを動かす必要はなく、紙芝居的な資料やデザインカンプでも検証できます。

プロトタイプ(動作・操作感の検証)

プロトタイプでは、実データを投入する前に、画面や一部機能の動作と操作感を試します。試作の対象には、チケット管理システムや変更管理ワークフローなどがあります。

画面の操作性に加えて、保守業務の流れに沿って通知や承認が機能するかも検証します。

  • 通知先:エスカレーション操作で、正しい担当者に通知が届くこと。
  • 承認フロー:変更管理委員会(CAB)への申請が、実務の流れと合っていること。
  • 操作感:画面の使いやすさと、承認が正しく進む流れ。

PoC(概念・実効性の実証)

PoCは、限定的な範囲で実際の環境や運用に近づけ、「本当に機能するか」を確かめる段階です。

検証方法には、いくつかの例があります。

  • 応答テスト:ダミーまたは実際の問い合わせを使ったヘルプデスクの試験。
  • 監視精度:一部サーバーに限った、監視やアラートの精度の検証。
  • 指標の確認:SLA遵守率や対応時間が正しく計測・可視化されるかどうか。

ツールが動くかどうかだけでなく、管理指標の計測と可視化まで確かめておくと、本導入の判断材料になります。

ポイント

見た目、動作と操作感、実効性の順に確かめる対象を分けておくと、どの段階で何を判断するかが混ざりにくくなります。段階ごとの確認事項を先に決めておくことが、検証の深さを取り違えないための目安です。

進め方の基本

試験運用で実際の業務をテストし、週次定例で課題を共有して運用ルールやマニュアルを改善する循環図
業務で見つけた課題を、次の運用改善につなげます。

保守管理体制のPoCを成功させるには、目的を明確にすることと、対象範囲を絞ることが基本になります。

目的と課題の明確化

保守管理で改善したい課題は、数値や業務単位で具体化しておく必要があります。たとえば、次のような目標を設定できます。

  • 対応時間:アラート対応時間の短縮。
  • 一次切り分け:障害の一次切り分けの自動化。
  • 担当者の負担:運用担当者の負担の軽減。

目的が曖昧なままでは、十分な成果が得られず形骸化するおそれがあります。そのため、企画段階で目的の設定に時間をかけることが、成功の前提になります。

対象を絞ったスモールスタートとPDCA

運用業務全体を一度に刷新すると、現場が混乱します。そこで、試験運用は特定拠点や一部サーバーなどに対象を絞って始めます。

試験運用では、業務を通じて課題を確認し、その結果をもとに次の改善へ進みます。

  1. 実際の業務でのテスト。
  2. 週次定例などでの課題の共有。
  3. 運用ルールやマニュアルの改善。

こうしてPDCAを回すと、本導入の前に想定される問題の大半を洗い出せます。

ポイント

PoCは、目的を数値で決め、対象を一部に絞って試験運用を回すことが基本です。業務で出た課題を週次で共有し、運用ルールやマニュアルの改善に生かすと、本導入前に問題を洗い出しやすくなります。

期間と費用の目安

応答品質テストは2週間、監視・アラート試験は2〜4週間、レポート作成は2週間、移行テストは4週間程度と示す横棒図
作業ごとの期間には幅があり、並行できる工程もあります。

PoCの期間と費用は、予算化や社内稟議で確認される項目です。そのため、標準的な目安を先に把握しておくことが大切です。

PoCフェーズの期間目安

PoCでは、応答品質や監視精度、一部システムの移行を検証します。そのため、レポート作成も含めて各作業の期間を計画に反映しておく必要があります。

  • 応答品質テスト:ヘルプデスクのテストに2週間。
  • 監視・アラート試験:試験運用に2〜4週間。
  • レポート作成:モックアップの作成に2週間。
  • 移行テスト:一部システムのテストに4週間程度。

作業には並行して進められるものもあるため、全体は4〜6週間程度に収まるケースが多いといえます。

費用感とRFP段階での費用負担の明記

費用は検証の内容によって異なるため、費用負担の認識違いを防ぐには、RFP(提案依頼書)で負担者を明記しておくことが大切です。

  • 無償提案の範囲:モックアップ作成や少数のダミーテストは、無償の場合が多くあります。
  • 有償PoC:実際の監視ツールを試験導入し、エンジニアが数週間稼働する場合は、有償が一般的です。

有償PoCでは、数十万円から百万円単位の費用がかかるのが一般的です。また、提案費用をどちらが負担するかを曖昧にしたまま依頼すると、想定外の請求が生じ、ベンダーとの信頼関係を損なうおそれがあります。

ポイント

作業ごとの期間は2〜4週間程度で、全体は4〜6週間が目安です。費用は無償の提案か有償のPoCかで変わるため、RFPの段階で負担者を明記しておくと、認識違いを防げます。

本導入への移行判断基準

PoCのあとに本番環境へ移るかどうかは、確認項目の結果を見て判断します。

本導入前に確認すべき5つのチェック項目

PoCや試行運用を経て本番へ移る前には、5つの観点をチェックリストで確かめます。

  • 役割分担:AIOpsなどで自動化する範囲と、人が判断する段階の定義。
  • 既存ルールとの整合:新しいツールが、既存のエスカレーションフローや運用ルールに合っていること。
  • 独立作業:現行担当者やベンダーの支援・監督なしで、作業できる状態かどうか。
  • 知見の反映:PoCで得た知見が、運用マニュアルに入っていること。
  • 重大な懸念:週次の検証報告に、重大な懸念事項が挙がっていないこと。

週次検証報告による懸念事項の解消

5つの項目のなかでも、週次検証報告に出た懸念事項の扱いは特に見落とされやすい点です。「気になるが致命的ではない」という懸念が、複数出ることもあります。

期限を理由に懸念を残したまま本導入へ進むケースもあります。ただし、統制の仕組みである保守管理体制では、先送りが後のガバナンスリスクにつながります。

判断会議では、懸念事項をすべて洗い出します。そのうえで、対応済み・許容・要改善に分けてから意思決定することが望ましいといえます。

ポイント

本導入の可否は、5つの観点をどこまで満たしているかで見ます。週次報告の懸念は先送りせず、対応済み、許容、要改善に分けてから判断すると、移行の根拠を残しやすくなります。

よくある失敗と対策

保守管理体制のPoCには、いくつかの典型的な失敗パターンがあります。あらかじめ対策を計画に含めておけば、リスクを減らせます。

一括での全面切り替え(ビッグバン移行)

全システムの管理ツールや体制を一度に切り替えると、想定外のトラブルが多発し、現場が対応しきれないおそれがあります。そのため、段階的な移行を計画と契約にあらかじめ含め、スモールスタートを徹底することが重要です。

書面だけによる評価

RFIやRFPの回答書面だけで評価し、PoCをせずに導入すると、運用のカルチャーが合わない場合があります。さらに、実際のトラブル対応力が低いこともあります。

PoCに加えて、実運用の担当者との面談で想定外の質問を投げかけ、実際の対応力を観察する方法が有効です。

目的が曖昧なままの導入と機密情報リスク

AIツールの導入そのものが目的になると、解決すべき課題が曖昧なまま進み、成果が得られないまま形骸化するおそれがあります。ログ分析や問い合わせ自動化に生成AIなどを使う場合は、システム構成情報や顧客情報が漏れるリスクがあります。

そのため、外部サービスのデータ保存ポリシーを十分に確認し、適切なセキュリティ対策を講じてからPoCを設計することが不可欠です。

ポイント

よくある失敗は、一括での切り替えと書面だけの評価に加え、目的の曖昧さや機密情報の扱いにも関わります。いずれも、小さく始めて検証を重ね、対策を計画に含めておくことで防ぎやすくなります。

まとめ

ITシステム保守管理体制のモックアップ、プロトタイプ、PoCについて、違いと進め方を見たうえで、期間と費用、移行判断、失敗例を取り上げてきました。

モックアップでは見た目やフォーマット、プロトタイプでは動作や操作感を確かめます。そのうえでPoCでは概念と実効性を検証し、段階的に本導入を判断します。

PoCは4〜6週間が目安です。費用は無償の提案から数十万円から百万円単位まで幅があるため、RFP段階で費用負担を明記します。

本導入の前には、自動化と人の役割の分け方、既存プロセスとの整合性を確認します。加えて、独立して対応できるかと、知見がマニュアルに入っているかを見ます。

重大な懸念事項の有無を含めて5つのチェック項目を見ます。懸念は先送りせず、対応済み・許容・要改善に整理してから判断します。

ビッグバン移行や書面だけの評価は避け、目的の曖昧さや機密情報のリスクにも注意して、小さく始めて検証を重ねることが大切です。導入を検討するときは、まず自社の課題を数値で言語化しましょう。

▼全体ガイドの記事
・ITシステム保守管理の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。