文書が試されるのは、書いた人が誰もいなくなった日
MESの寿命は10年を超えることが珍しくありません。その間に起きることは決まっています。発注側の担当者は異動し、ベンダーの構築メンバーは別プロジェクトへ移り、口頭で共有されていた「なぜこの設計にしたか」は失われます。文書整備とは、この必然に対する備えです。
ところが実際の現場で見る文書の状態は、両極端に分かれます。一方の極は、納品時の設計書が数百ページ揃っているが、その後の改修が反映されておらずどこが現状と違うのか誰にも分からない状態。もう一方は、規制対応で文書の版管理は厳格だが、監査向け文書に偏り、障害対応や変更調査に使える技術文書がない状態です。どちらも「文書はある」のに、運用では使えません。
使える文書体系の条件は、量でも網羅性でもなく、次の2つです。
- 更新される仕組みが文書ごとに決まっていること（更新トリガーと責任者）
- 調べたいことから文書へたどり着けること（体系と索引）
この2条件から逆算すると、文書は少ないほど維持しやすいという原則が出てきます。10年維持する前提で、増やす判断は慎重に、減らす判断は大胆に、が基本姿勢です。
文書体系の全体像──4分類で持つ
分類そのものより重要なのは、全体索引を1枚持つことです。「どんな文書が、どこに、どの版まであるか」の一覧がないと、文書は存在していても使われません。索引には文書名・保管場所・版数・最終更新日・更新責任者を載せ、これ自体を年1回棚卸しします。
各分類の代表文書のうち、IF仕様書の書き方はMESインターフェース仕様書の書き方で、教育文書はMESの教育計画で個別に扱っています。
文書は「事件」で腐る──更新トリガーを決める
文書が現状と乖離するのは、怠慢よりも構造の問題です。文書を変えるべき「事件」が起きたとき、その事件の担当者に文書更新の義務が紐付いていなければ、更新されないのが自然だからです。対策は、事件の種類ごとに更新すべき文書と責任者をあらかじめ対応表にしておくことです。
| 事件（トリガー） | 更新すべき文書 | 責任者 | 組み込む場所 |
|---|---|---|---|
| 改修・設定変更のリリース | 設計文書の該当箇所、パラメータ一覧 | 変更を実施したベンダー／担当 | リリース手順のチェック項目 |
| バージョンアップ | 構成図、運用手順、教育文書 | 保守担当 | アップグレード計画のタスク |
| 業務ルール変更 | 業務フロー、例外時手順、教育文書 | 業務側キーユーザー | 変更承認の条件 |
| 障害発生 | 障害対応手順（新パターンの追記） | 対応した担当 | 障害報告書のクローズ条件 |
| 組織変更・人事異動 | 連絡体制、権限一覧 | 情シス | 異動時の定型タスク |
ポイントは右端の列です。更新を「心がけ」にせず、既存のプロセスの完了条件に埋め込むこと。リリース手順書に「設計書更新済み」のチェック欄を1行足すだけで、乖離の大半は防げます。逆に、どのプロセスにも紐付かない文書は、維持されない文書です。維持する仕組みを用意できないなら、その文書は最初から作らない判断も含めて検討すべきです。
ベンダー納品文書に、自社で足すべき3つの文書
納品文書は「システムがどう作られているか」を説明しますが、運用で本当に困ったときに開きたいのは別の文書です。次の3つは、ベンダーからは納品されないため自社で書く必要があります。
1. 設計判断の記録（なぜこうしたか）。 実績の粒度をなぜロット単位にしたのか、なぜこの工程だけ手入力を残したのか。設計書には結果だけが書かれ、理由は書かれません。数年後の改修検討で「これは変えてよい設計か、何かの制約か」が分からず調査に数週間かかる事態は、判断の記録が1行ずつあれば防げます。プロジェクト中の主要な決定を、決定・理由・却下した代替案の3点で記録する台帳を作り、体系の設計文書に含めてください。
2. 障害対応の一次切り分けガイド。 「画面が開かない」「ラベルが出ない」「ERPに実績が届かない」という症状から、確認箇所と連絡先へ最短でたどるフローチャートです。ベンダーの障害対応資料は自社の全体構成（ネットワーク、周辺機器、他システム）を知らないため、症状起点のガイドは自社でしか書けません。夜勤帯に情シス不在で障害が起きたとき、現場が読む前提で書きます。
3. 環境固有情報の台帳。 サーバ・端末・プリンタの一覧と設置場所、IPアドレス、証明書の期限、ライセンスの内容と更新日、外部接続の一覧。散在しがちな情報を1か所に集めるだけの文書ですが、障害時と更新時の調査時間を大きく削ります。証明書期限切れによる停止は、この台帳と期限アラートで確実に防げる障害の代表です。
これらを書く過程は、MES技術者を社内で育てるで述べた育成とも直結します。書ける人を育てることと、文書を維持することは、実務では同じ活動の両面です。
よくある質問
規制産業のバリデーション文書と、この文書体系はどう関係しますか？
バリデーション文書（URS、機能仕様、テスト記録、トレーサビリティマトリクス）は本記事の4分類の「設計文書」の一部を規制要件の様式で厳格化したものと位置づけられます。二重管理を避けるコツは、規制が要求する文書を体系の正本とし、同じ内容の非公式版を作らないことです。一方、運用文書・教育文書の維持の仕組み（更新トリガー）は規制文書のチェンジコントロールと同じ発想であり、規制産業の実務者にはむしろ馴染みやすいはずです。
既に文書が現状と乖離しています。どこから手を付けるべきですか？
全文書の一斉改訂は、ほぼ確実に挫折します。優先順位は、①全体索引の作成（現状把握。乖離していてもまず一覧化）、②環境固有情報の台帳（調査すれば書ける事実情報で、効果が即出る）、③IF仕様書とパラメータ一覧（変更・障害対応で最頻繁に参照される）、の順です。設計文書の本文は、次にその箇所を改修するタイミングで該当部分だけ現行化する「触った所から直す」方式が現実的です。
文書はどのツールで管理すべきですか？
ツールの選択より、①版管理ができる（誰がいつ何を変えたか）、②全文検索ができる、③現場・ベンダーを含む関係者がアクセスできる、の3条件を満たすことが重要です。ファイルサーバのExcel/Wordでも版管理ルールを決めれば成立しますし、Wikiや文書管理システムでも運用が決まらなければ腐ります。避けるべきなのは、個人のローカルフォルダと共有場所に同名文書が併存する状態で、正本の場所を全体索引で一意に宣言することが、どのツールを選ぶ場合でも前提になります。
