はじめに
ITSMツールは、IT運用の業務効率化や品質向上などの目的のために使用されます。
現在、多種多様なITSMツールが存在し、ニーズに合った製品を探すことができます。しかし、実際に導入してみると、「期待していた効果が得られなかった」「現場のニーズに合わなかった」という理由で、失敗に終わる可能性があります。また、十分な予算があり、高額で多機能なITSMツールを選定したとしても、必ずしも業務効率化などの目的を果たしてくれるとは限りません。
これらの失敗の原因の一つとして、ツールの特性や機能を十分に理解せずに導入を進めたことが挙げられます。
そこで重要なのがPoC（概念実証）の実施です。
本コラムでは、PoCがITSMツール導入を成功させるために、有効な手法であることを解説します。
PoCとは
PoCは「Proof of Concept（概念実証）」の略称です。
新しい技術やアイデアが、期待通りに機能するかどうかを検証するために行われます。
机上検証だけでは、求める機能の実現可能性を正確に判断するのは難しいことです。
PoCを実施して実際の環境や条件下で機能するか試すことで、失敗のリスクを軽減することができます。
ITSMツールのPoCでは、導入の候補として選定したツールを実際に操作して確認することで、期待通りに機能するかを見極めることができます。
メーカーのマニュアルに記載された機能説明を読むだけでは、機能の理解が十分でない場合があります。
PoCを通じてITSMツールを操作することで、機能を正確に理解でき、より適切に機能の実現可能性を判断できます。
また、操作を通じて得られるツールの知見は、導入時の要件整理や運用設計の重要な基盤となることもあります。
このように、PoCはツールの評価にとどまらず、導入に向けた計画や設計に生かすための大切なステップといえるでしょう。
PoCの計画
PoCを実施するために、主に以下のような内容を盛り込んだ計画が必要です。
本コラムでは、PoC期間を3か月間とし、4か月目以降にITSMツールの導入を開始することを想定しています。
| PoCの目的・目標 | 検証の結果や目標値 |
|---|---|
| スコープ | ITSMツール全体の中で検証対象となる範囲 |
| 実施内容 | 具体的な検証内容（チェック項目など） |
| 評価基準・方法 | 検証結果を判断するための具体的な基準・方法 |
| 人員計画 | 役割分担や検証の準備（教育など）・実施の体制 |
| スケジュール | 検証の準備・実施のスケジュール |
| 管理方法 | 会議体やコミュニケーションルール、進捗管理 |
スコープ
PoCを成功させるためには、「何を検証するのか」を明確にすることが重要です。そのためには、「PoCの目的・目標」に基づき、スコープ（検証範囲）を具体的に定める必要があります。限られた期間内で検証を行うため、スコープを定める際は、評価に必要な最小限の範囲にすることが基本となります。特に、優先度の高い機能に絞り込むことで、検証コストを抑えつつ、効率的かつ効果的な評価が可能になります。
スコープが曖昧なままだと、「使いやすかった」「なんとなく目的に合いそう」といった主観的な印象だけが残り、導入判断の根拠が不明確になる恐れがあります。
こうした理由から、PoCでは検証の前にスコープを明らかにすることが大切です。
「何を評価すべきか」を定めることで評価基準が明確に整理され、関係者間の認識が揃いやすくなり、客観的かつ効果的な検証を実現できるようになります。
評価基準・方法
PoCを行う際には、「使えるかどうか」を感覚や印象に頼らず、客観的に評価するための基準を事前に決めておくことが大切です。評価方法としては、以下のような形式がよく使われます。
| 評価方法 | 特徴・概要 | メリット |
|---|---|---|
| ○／△／×評価 | 各要件に対して「満たしている」「条件付きで満たす」 「満たしていない」で評価 |
シンプルで関係者に伝わりやすい |
| スコア評価（数値） | 各項目を1〜5点などで数値評価し、平均・合計で比較 | 客観的な比較がしやすく、優劣が数字で示せる |
| コメント併記 | 各項目に対し評価理由・備考をコメント形式で記録 | なぜ○や×なのかが分かるため、後から見直ししやすい |
| 加重スコア評価 | 評価項目ごとに重要度を設定し、加重平均で評価 | 重要項目の優先度が反映される |
| ノックアウト評価 | 特定の必須要件（例：日本語対応など）を満たしていない場合は即不採用 | 最低限クリアすべき条件を明確化できる |
人員計画
PoCを成功させるために、計画段階で「誰をどのように巻き込むか」を明確にし、評価に必要な観点を網羅することが極めて重要です。様々な立場の関係者を巻き込むことで、多角的な観点からの評価が可能となります。
具体的には、目的に応じて以下のような立場の関係者が参加します。
| 関係者 | 検証において求められる観点 |
|---|---|
| 実際の業務担当者 |
日常の操作性や業務への適合性 |
| システム管理者 |
保守性、運用性、セキュリティ |
| 管理者・マネージャー |
レポート・統計機能の活用やマネジメントへの適合性 |
| 情報システム部門 |
システム要件や既存環境との整合性 |
また、注意すべき点として、実際にツールを検証する関係者が、そのツールに不慣れである場合、正確な評価が難しくなることが挙げられます。そこで重要となるのが、「教育」です。
特に、以下のような教育が必要となります。
- 事前に基本的なツール操作説明を行う
- 評価観点や評価方法を共有する
- ツール操作用の簡易マニュアルを用意する
これにより、関係者が適切な評価を行うための基盤を整えることができます。
幅広い関係者を参加させ、適切な教育を行い、評価基準を共有することで、PoCの評価の観点が偏ることなく、現場に基づいた実用的な判断材料を得ることができます。
スケジュール
スケジュールを策定する際は、前述の計画（目的、評価基準など）を踏まえて設定します。PoCでは、時間と予算が限られています。
しかし、ツールの操作方法がわからず検証が進まないなどの理由で、スケジュールが遅れる可能性があります。
トラブルを想定して余裕のあるスケジュールを策定することが、重要なポイントとなります。
検証完了後の対応
検証が終了した後は、単に「できた／できなかった」で終わらせるのではなく、検証結果を整理・評価し、次に取るべきアクションを明確にすることが重要です。
検証が成功であれ失敗であれ、そこで検証活動が止まってしまえば、PoCは単なる機能確認にとどまってしまいます。
PoCの完了はゴールではなく、導入プロジェクトのスタートとして捉えることができます。
成功だった場合
評価基準を満たし、業務要件に適合していると判断された場合は、ツール導入に向けた準備へと円滑に進むことが期待されます。| アクション | 内容 |
|---|---|
| 評価結果の正式報告 | PoCの目的や達成状況、課題、改善点を整理し、関係者（経営層など）に報告できる資料を整える |
| 本番導入計画の立ち上げ | PoCで得た知見をもとに、要件定義や基本設計へ進める。試した設定や運用案をベースに設計を推進する |
不合格だった場合
期待していた効果が得られず、「不合格」という結果になった場合でも、それを単なる失敗と見なすのではなく、検証から得られた気付きを次にどう活かすかを検討することが重要です。| アクション | 内容 |
|---|---|
| 製品再選定の即時提案 | PoCのスコープや評価基準を見直し、不合格の理由を明確化したうえで、次の製品候補のPoCを速やかに計画する |
| 既存製品への改善要望提示と再PoC交渉 | 足りない機能や課題をメーカーに共有し、改善の見込みがあれば再PoCや機能拡張の交渉を行う（チェック項目など） |
| PoCスケジュールと導入計画の見直し提案 | ITSMツール導入全体のスケジュール遅延に備え、関係者と調整して計画をアップデートする |
大切なのは検証結果を冷静に振り返り、次に取るべき選択肢を見極めることが、ツール導入の成否を分けることになります。
