マネージドサービスプロバイダーにとって、ドキュメントは「あると便利」ではなく「プロダクトそのもの」です。Trupeerなら、無料のMSPドキュメントテンプレートから始めて、ブランドガイドラインでカスタマイズし、クライアント向けのドキュメントを、どの技術者でも使える動画のウォークスルーに変えることで、MSPドキュメント作成にかかる何時間もを節約できます。

MSPドキュメントとは何で、何が社内ITドキュメントと違うのですか？

MSPドキュメントとは、マネージドサービスプロバイダーが他社のテクノロジーを運用するために書き残すすべてのことです。資産台帳、ネットワーク図、資格情報、ランブック、エスカレーションパス、クライアント固有のクセ、そしてクライアントが見るレポートやレビューが含まれます。

構造的に社内ITドキュメントと異なるのは2点で、ほとんどのテンプレートはその両方を無視しています。

あなたは、自分が所有していない環境をドキュメント化しています。クライアントには、あなたが書いた内容の一部について権利があり、残りについては権利がありません。そしてこの線引きは、商業的にも契約上も、関係が終わる当日にも重要になります。

さらに、同じ手順を複数の環境にまたがって一度にドキュメント化しています。社内チームは、1つのバックアップ復元ランブックを書きます。MSPは1つ作ってから、誰も完全には覚えていない違いがある30〜40もの環境に対して、それを正しく保ち続けなければなりません。

2つ目の問題は、MSPの利益率を静かに食い潰すもので、このページの出発点です。単一環境版では、当社のITドキュメントテンプレートが一般的なケースをカバーします。

なぜ「1つのランブックを40部」作るのが本当の問題なのか

ほとんどのMSPは同じ出発点から始まります。まずは良いランブック一式を作る。クライアントをオンボードする。その後、チケットを扱うエンジニアがすべてを1か所で参照できるように、ランブックをそのクライアントのフォルダやスペースにコピーする。繰り返す。

これは自然な発想で、しかしゆっくりとした大惨事を生みます。4年ほどで30社ほどのクライアントを抱えると、1,000を超えるドキュメントができ、その多くは互いにほぼ重複しているのに、どのコピーが最新かを判断する方法がありません。

失敗の原因は、ドキュメントが悪いことではありません。作った時点では、各コピーは正しかったのです。問題は、手順の改善を今では30回適用しなければならず、誰かが緊急の案件に引っ張られるまでに5回か10回適用されてしまうことです。

次にエンジニアが行う作業が高コストです。環境に合っていないランブックで2度火傷した技術者は、ランブックを読むのをやめます。代わりに、最初からの原理で作業するようになります。これは遅く、整合性も低く、チケットはまだクローズされるため、レポーティング上では完全に見えません。

そのため、MSPドキュメントの構造は、標準更新を1か所で行える必要があります。以下はすべて、その考え方から導かれます。

Trupeerでこのテンプレートをカスタマイズする方法

ステップ1：テンプレートセクションを開く

メインナビゲーションからテンプレートセクションへ移動します。

ステップ2：テンプレートを選択して開く

作業したい任意のテンプレートをクリックして開きます。

ステップ3：テンプレートビューを展開する

必要に応じて、テンプレートビューを展開し、レイアウトと詳細をはっきり確認します。

ステップ4：テンプレートを編集する

編集をクリックして、選択したテンプレートの変更を開始します。

エディター内で、次のことができます：

• 新しいセクションを追加

• 書式ルールを定義または更新

• ロゴを追加し、その位置および関連設定を調整

ステップ5：カスタマイズしたテンプレートを保存する

必要な変更をすべて行ったら、保存をクリックして更新済みのテンプレートを自分のものとして保存します。

ステップ6：プレビューしてテンプレートを微調整する

カスタマイズしたテンプレートがどのように表示されるかを確認したいときは、プレビューを開きます。

プレビュー画面から、必要に応じて直接調整を続けることができ、テンプレートが希望どおりに表示されることを確認できます。

MSPドキュメントテンプレートを使うと、次のことができます：

• 作成時間を節約：MSP運用向けに構造化された空白ページをスキップできます。

• MTTRを短縮：明確なドキュメントがあれば、どのテクニカルサポートでも、どのクライアントでも素早く対応できます。

• ブランドを維持：Trupeerのブランドキットで、ロゴ・フォント・カラーを適用できます。

• 技術者をより早くオンボード：新しい技術者は、わかりやすい動画ベースのドキュメントで素早く立ち上がります。

• 監査に備え続ける：内蔵セクションがSOC 2、ISO 27001、クライアント監査をサポートします。

• グローバルチームに対応：1クリックでMSPドキュメントを65以上の言語に翻訳できます。

優れたMSPドキュメントこそが、マネージドサービス事業をスケール可能にします。これらのテンプレートを使って、すべてのクライアント、すべてのシステム、すべての手順を明確かつ一貫した形で記録しましょう。

標準は1度だけ記録し、差分だけ記録する

1つの標準ライブラリ。各ドキュメントは1つのコピー。バージョン管理され、所有され、手順が存在する唯一の場所です。

そしてクライアントごとに、標準からどこが異なるかを記録する短いドキュメントを1つだけ作成し、それ以外は記録しません。編集したランブックのコピーではありません。例外の一覧です。

クライアント差分台帳がすべてのコツです。クライアントが別のバックアップ製品を使っているなら、それは1行。ファイアウォールが別のベンダーなら、それも1行。財務担当ディレクターが営業時間外の作業を承認する必要があるなら、それも1行。台帳に載っていないものは定義上すべて標準です。つまりエンジニアは、1つのフォルダを探して「そこにあるコピーが最新かどうか」を期待するのではなく、2つのドキュメントを読むだけで済みます。

台帳は小さく保てます。実際には成熟したクライアントは8〜20行程度に収まり、1つの台帳を書く作業をすると、どこにも記録されていなかった差分が3〜4件ほど見つかるのが普通です。

もう1つ、後になって見えてくるメリットがあります。クライアントに関して標準でないことをすべて短くまとめたリストは、非常に良い営業資料であり、利益率を左右するドキュメントにもなります。差分のところに、あなたの時間が使われます。

クライアント差分台帳と、そこに入れる内容

差分ごとに1行、5つの項目です。

何が異なるか。 標準に対して記載します。「バックアップは標準のVeeamではなくDatto」など、「Dattoを使っている」ではなく、標準との差分として書きます。

どの標準ドキュメントに影響するか。 参照先です。ランブックを読むエンジニアが、ここを指し示せるようにします。

なぜか。 クライアントの希望（過去のプロバイダーから引き継いだもの）、コンプライアンス要件、技術的制約など。ここで、差分を削除する価値があるかどうかが決まります。

いつからか、いつ見直すか。 日付です。オンボーディング時に引き継がれた差分は、誰も見直さないため、何年も残りがちです。

工数またはリスク。 それがあなたにかかるコストを短くメモします。これにより、台帳は技術的なものだけでなく、商業的なドキュメントにもなります。

台帳のヘッダーとして、クライアント名、当該台帳が書かれている標準ライブラリのバージョン、アカウントオーナーを記載します。台帳は四半期ごとにレビューします。理由もコストもない差分は標準化の候補であり、その作業は通常、MSPができるドキュメント改善の中でも最も回収率が高いものです。

カテゴリ別：MSPが実際に必要とするドキュメント

ほとんどのMSPは1行目と5行目は強く、3行目は弱いのですが、これは完全に逆です。3行目が2行目を使えるようにしているからです。

このうち2つは、それ自体に使う価値のあるテンプレートがあります。資格情報とライセンス在庫は、当社のアプリケーションおよび資格情報台帳に自然に収まります。また、ランブック自体は、当社のIT SOPテンプレートにある構造に従っています。

無料のMSPドキュメントテンプレート：構築するための標準ライブラリ

ここからコピーしてください。これは最小限の標準ライブラリで、多くのMSPが想定しているよりも小さくなっています。

オンボーディングパック。 調査チェックリスト、サイト監査、資産の取得、資格情報の取得、差分台帳の初期入力、初月のレビュー。1つのドキュメントで、クライアントごとに1回実行します。

ランブック（反復タスクごとに1つ）。 バックアップ復元、ユーザー作成と無効化、メールボックス復元、エンドポイント再構築、パスワードリセット、VPNアクセス、プリンタの展開、証明書の更新、パッチ例外。すべてを網羅しようとせず、最もチケットを生む10のタスクから始めてください。

エスカレーションとオンコール。 チケットがどのようにエスカレーションされるか、各ティアで誰に連絡するか、緊急とは何か、営業時間外の承認ルール。

インシデントと変更。 インシデント後のレビュー形式、そしてクライアントのインフラに対する計画変更のための手順の方法形式。

クライアント向けレポート。 月次レポート、四半期ビジネスレビュー、サイト監査の出力。固定形式で、クライアントデータを入力します。

オフボーディングパック。 クライアントが受け取るもの、あなたが保持するもの、どの形式で、いつまでに。必要になる前に書いておきます。

差分台帳テンプレート。 上記の5つの項目です。

ここにコピーしてください。ランブック10〜15本に加えて、6つの定型ドキュメントがあれば、実用的なライブラリになります。最初にランブックを40本書こうとする直感が、多くのMSPドキュメントプロジェクトを2か月目で止めてしまう理由です。

社内向けと社外向けのMSPドキュメント、そして誰が所有するのか

多くのガイドが引く区別は、社内向けかクライアント向けかで、トーンを決めるのに役立ちます。しかし、より重要なのは所有権で、オフボーディングで現実になります。

大まかに言えば、契約や管轄によって多少異なりますが、クライアントのデータはクライアントのものです。機器を説明する資産台帳、ネットワークトポロジー、資格情報、ライセンスの権利、設定などです。あなたはそれを所有するのではなく、サービスとして保持します。

あなたの方法はあなたのものです。標準ランブック、レポート形式、構築の標準、料金モデル、社内手順。クライアントが離れる場合、あなたのランブックライブラリに対する権利はありません。

差分台帳はその中間にあり、だからこそ契約で明示的に名前を付ける価値があります。差分台帳はクライアントの環境を記述するため「クライアント側のもの」と言えますが、あなたの標準に基づいて書かれているため「修正・伏せ字版としての扱いが必要」とも言えます。

出口の時点で揉めるのではなく、サービス契約の中で書面にして決着させましょう。このページは法的助言ではなく、契約や管轄によって立場が異なるため、弁護士にドキュメントの所有権と返還条項をレビューしてもらってください。1回やるだけなら1時間で済みます。オフボーディング中にやると、下記のとおりかなり高くつきます。

1,360ドキュメントと9つの陳腐化したランブックを抱えるMSP

Thornbury ITは、22名のスタッフ（うち9名がエンジニア）で、34社のクライアントに対してマネージドサービスを提供していました。オンボーディングのたびに、ランブック一式を新しいクライアントのスペースにコピーしていました。その結果、4年目には、クライアントあたり約40ドキュメント、合計で約1,360ドキュメントになっていました。

問題はインシデントの最中に表面化しました。あるエンジニアが、1社のクライアントの復元ランブックに従って失敗したバックアップを処理していました。その復元ランブックは、Veeamのジョブ命名規則を参照していました。クライアントは14か月前に別のバックアップ製品へ移行していました。標準ランブックは更新されていましたが、そのクライアントのフォルダにあるコピーは更新されていませんでした。

その後、彼らは12社のクライアントの復元ランブックをサンプルで確認しました。9社は現在の標準と異なり、その9つの違いのうち5つは、意図的な変更ではなく単なる陳腐化でした。

測定可能なコストは、対応時間の中にありました。事業全体の平均ティア2対応時間は47分でした。ランブックが陳腐化していたクライアントでは71分でした。これらのアカウントのエンジニアは、ドキュメントを信頼しなくなり、その都度考え直していたからです。

別件として、3年目にあるクライアントが離脱し、ドキュメントの提供を求めました。Thornburyは、そのクライアントのフォルダを送付しました。そこには、クライアント自身の標準ランブックが、クライアントの資産台帳や資格情報と混ざった状態で入っていました。誰も線引きをしていなかったのです。クライアントが何を受け取る権利があるのかをめぐる議論は6週間続き、両社の弁護士が関与しました。

再構築には、1人の作業時間で1か月かかりました。1つの標準ライブラリ、単一コピー、バージョン管理。クライアントごとに差分台帳のみ。台帳の平均的な長さは11行でした。

1,360ドキュメントは、40の標準ドキュメントと34の台帳になり、合計74になりました。ティア2の対応時間は、すべてのアカウントで44分に収束しました。そしてオフボーディングパックは、その後契約で定義されました。クライアントは資産台帳、資格情報、図面、そして差分台帳を受け取り、Thornburyは標準ライブラリを保持します。

GitHubに無料のMSPドキュメントテンプレートはありますか？

はい。現実的な期待値を持って見てみる価値があります。

見つかるのは、ランブックのコレクションに関するコミュニティリポジトリ、埋め込みドキュメント付きのPowerShellスクリプトライブラリ、markdownベースのドキュメントフレームワーク、そして時には採用やマーケティングのためにMSPが公開した完全なドキュメント構造です。markdownやdocs-as-codeと一緒にMSPのランブックやITドキュメントを検索すると、大部分が見つかります。

それらのリポジトリで本当に役立つのは、構造とカバー範囲です。きちんとしたMSPが維持しているランブックの一覧は、あなた自身のチェックリストとして良い指標になります。一方で、コンテンツが役立つことはあまりありません。ランブックはツールスタックに固有であり、他社のバックアップ製品やRMMに対する復元手順は、テンプレートというより「実例」に近いからです。

注意点が2つあります。商用ドキュメントライブラリに取り込む前にライセンスを必ず確認してください。寛容なライセンスはよく見かけますが、普遍ではありません。そして、実在するクライアント識別子、ネットワークの詳細、資格情報に類するものを含むリポジトリは決して流用しないでください。そうした情報は、本来あるべきでない形で公開リポジトリに出てくることがあります。

また、docs-as-codeのアプローチ自体（つまりバージョン管理でのmarkdown）は、MSPにとって正当な選択肢であり、単一コピー問題をうまく解決します。弱点は、時間に追われるエンジニアがリポジトリにコミットしないことがあるため、導入の成否はツールよりも運用面が制約要因になりがちな点です。

MSPドキュメントソフトウェアとベンダーロックイン問題

MSP向けに作られたドキュメントプラットフォームは、自分でゼロから作るのが難しい部分に強みがあります。構造化された資産の関係、RMMやPSAとの連携、監査証跡付きの資格情報の取り扱い、そして権限によるクライアントごとの分離です。

トレードオフは、ドキュメントが相手のデータモデルに合わせて形作られてしまい、使える形で取り出すのが、営業プロセスが示す以上に難しくなることです。エクスポートは通常、エンジニアが実際に使う「読みやすいドキュメント」ではなく、「一連のレコード」になります。

コミットする前に確認すべき質問は2つです。1つ目は、別のプロダクトを買わなかったとしても使える形式で、関係や添付ファイルを含めてすべてエクスポートできますか。2つ目は、クライアント全体に適用できる単一の標準ドキュメントを維持できますか。それともモデルによってクライアントごとにコピーが強制され、このページで扱っているまさにその問題が再発しますか。

2つ目の質問は、想像以上に多くの製品を除外します。プラットフォームがクライアントごとのコピーを強制する場合は、標準ライブラリをその外に置き、よりシンプルなものにしておき、プラットフォームはクライアントの環境データに使うのがよいでしょう。プラットフォームが本当に得意なのはそこです。当社のナレッジベーステンプレートは、その標準ライブラリがどこに置かれても構造化できるようにカバーしています。

クライアントが離れたら、ドキュメントはどうなる？

オフボーディングの段階で、ドキュメントの品質が見えるようになります。多くの場合、すでに不満を持っている人たちに対してです。

パックの内容を契約で定義してください。妥当な立場は、クライアントが資産台帳、ネットワーク図、ライセンス在庫、資格情報を安全に移管された形で受け取り、差分台帳を受け取り、さらにクライアントが支払ったドキュメントは成果物として提供される、というものです。あなたは標準ランブック、レポート形式、社内手順を保持します。

同じ条項内で、期間と形式を決めてください。「ドキュメントは提供される」というだけでは、紛争が始まる場所になります。30日と、指定された形式が一般的です。

資格情報の引き渡しは、スプレッドシートではなく適切なプロセスで行い、何がいつ移管されたかを記録してください。後で何かがアクセスされた場合に、双方を守る記録になるからです。

離脱が社内ではなく別のプロバイダーへの移管である場合、ドキュメントをまとめて渡すよりも、構造化された引き渡しのほうがかなり安く済みます。そして当社のナレッジトランスファーSOPでは、その進め方をカバーしています。

MSPドキュメントテンプレートをPDFで入手できますか？

PDFは2つには適していて、残りには適していません。

クライアント向けドキュメントには適しています。月次レポート、四半期レビュー、サイト監査の出力です。これらは「ある時点のスナップショット」であり、それを固定するのは正しいことで、ブランドも反映させるべきです。

一方で、ランブック、差分台帳、資産台帳には適していません。これらはすべて変わり、検索可能である必要があります。PDFのランブックライブラリは、上記の実例の問題を遅い形で再現したものです。PDFでは、読者に「最新ではない」ことを伝えられないからです。

標準ライブラリについては、エンジニアが実際にプレッシャー下で検索するものを使い、1つのコピーを維持してください。クライアント向けの成果物については、別に管理するのではなく、その元データからPDFを生成します。

すべてのクライアントで標準ライブラリを最新に保つには

この構造全体は、標準ライブラリが本当にメンテナンスされていることに依存しています。そして通常それができない理由は、ランブックの更新が「誰かがツールの使い方をすでに知っている前提で、スクリーンショットを撮って切り抜き、手順を書き直す」作業になってしまうからです。

Trupeer AIが、そのほとんどを取り除きます。エンジニアがカメラで一度だけタスクを実行すると、出力は、手順と画面がすでに配置された整形済みのランブックになります。書くのではなく、レビューするだけの状態で準備できます。10本のランブック更新が、四半期ではなく1日になります。

記録する。ブランド化する。翻訳する。Trupeerする。

クライアント向けの素材では、ブランドが商業的に重要です。ブランドキットを使うと、クライアントが受け取るレポートやガイドが、テンプレートから作られたものではなく「あなたのもの」に見えます。Documentationとtechnical documentationは、標準ライブラリとクライアントの環境記録を一緒に保ち、SOP creatorはランブック自体をカバーします。セットアップ手順はドキュメントテンプレートセットアップガイドにあります。

よくある質問

PDFの無料MSPドキュメントテンプレートはありますか？

このページの構造はすべて無料でコピーできます。分け方としては、ランブックと台帳は検索可能な形で保持し、クライアント向けレポートはPDFにエクスポートするのが合理的です。限定ダウンロードもフォームもありません。参照用に標準ライブラリのPDFが欲しい場合は、別途維持するのではなく、ライブのコピーから生成してください。

無料のMSPドキュメントテンプレートでおすすめは？

最適なセットは、最小で、かつ最新に保ち続けられるものです。最もチケットが多い領域をカバーするランブック10〜15本、オンボーディングパック、エスカレーション用のドキュメント、差分台帳の形式、そしてクライアント向けレポート形式を3つ。テンプレートライブラリは、「標準」と「クライアント別の例外」を分けられているかどうかで判断してください。そこが、30社を超えても生き残れるかどうかを決める部分だからです。

MSPはドキュメントをどこに保管すべきですか？

クライアントの環境データは、RMMとPSAと連携し、資格情報を適切に扱えるプラットフォームに置くべきです。標準ライブラリは、エンジニアが最も速く検索できる場所に置くべきで、同じプラットフォームである場合もあれば、よりシンプルな別の場所である場合もあります。決め手は、そのプラットフォームが「すべてのクライアントに適用できる1つのドキュメント」を維持できるかどうかです。

新しいクライアントのオンボーディング時に、どれくらいのドキュメントを渡すべきですか？

標準ライブラリは渡さず、クライアント自身の環境データはすべて渡します。実務上、クライアントがオンボーディングで価値を感じる成果物は、資産台帳、ネットワーク図、そして「調査して分かったこと」と「おすすめすること」のシンプルな要約です。オンボーディング時にランブックを送るのはよくある発想ですが、商業的な見返りがないまま、あなたの方法を渡してしまいます。

クライアントは、私たちがクライアントのシステムについて書いたドキュメントを所有しますか？

通常、クライアントのデータはクライアントのものです。あなたの方法は通常、あなたのものではありません。境界線は、出口で揉めるのではなく、サービス契約に書き込むべきです。資産台帳、図面、資格情報、設定は、その所有物を説明しています。あなたの標準ランブックとレポート形式は、あなたの知的財産です。条項は必ず自社の弁護士にレビューしてもらってください。契約や管轄によって立場が異なるためです。

エンジニアがドキュメントを飛ばすのをどう止めますか？

まずは標準ライブラリを信頼できるものにします。エンジニアがドキュメントを飛ばすのは、読むのが嫌だからではなく、以前に間違っていたからです。単一コピー問題を解消し、対応時間が収束するようにすれば、行動は自然に変わります。チケットクローズ時にドキュメント更新を求めるだけでは、ライブラリが更新する価値のある状態になっている場合にしか機能しません。