Excel パラメータシートを正本にしない – 設計値、実装値、実機値を分ける

システム導入では、設定項目、デフォルト値、設計値、備考をまとめた Excel パラメータシートがよく作られます。表として読みやすく、顧客や非エンジニアを含むレビューにも使えるため、Excel を選ぶこと自体には合理性があります。

問題は、Excel を設定管理の正本にすることです。シートに書かれた設計値、構築担当者が投入した値、現在の実機で動いている値が別々になっても、セルを見ているだけでは差を検出できません。

必要なのは「脱 Excel」という掛け声ではありません。設計判断、望ましい状態、実装処理、実機状態、人間向けの表示を分け、それぞれの正を決めることです。

Excel パラメータシートのフォーマットやテンプレートを作る前に、まず「その表は正本なのか、レビュー用のビューなのか」を決めます。ここが曖昧なまま列を増やすと、設定管理ではなく転記作業が増えていきます。

Excel パラメータシートが使われる理由

パラメータシートに並べる情報は、表形式と相性が良いものです。

• 設定項目の名称と説明
• メーカーのデフォルト値
• 環境ごとの設計値
• 変更する理由と前提条件
• 設定可能な範囲や入力規則
• レビュー結果、担当者、備考

行を設定項目、列を環境や属性として並べれば、一覧性は高くなります。セルの色、コメント、フィルター、入力規則も、人間が確認する資料としては便利です。

しかし、読みやすいことと、変更を安全に実行できることは別です。Excel は人間向けのビューとして強い一方、差分レビュー、構文検査、依存関係、再適用、実機との照合を自動化するには追加の仕組みが必要です。

最初に 5 つの情報を分ける

Excel パラメータシートが破綻しやすいのは、この 5 つを 1 冊に背負わせるからです。設計理由を書き、設定値を書き、投入済みの印を付け、実機確認の結果を書き、顧客への提出物にもする。役割が増えるほど、どのセルが現在の正なのか分からなくなります。

設計値、投入値、実機値は同じではない

設計書に書いた値が、そのまま実機で動いているとは限りません。

• 構築時に担当者が別の値を入力した
• 投入処理の一部だけ失敗した
• 障害対応で実機だけ変更した
• 製品アップデートでデフォルト値や仕様が変わった
• 別の自動化処理が値を書き換えた
• Excel の修正が承認後の成果物へ反映されなかった

したがって、「Excel に正しい値が書いてある」だけでは運用上の保証になりません。望ましい状態を機械が読める形で持ち、実機から現在値を取得し、両者の差を検出できる必要があります。

正本は 1 ファイルとは限らない

SSOT は、すべての情報を 1 つの Excel や 1 つの Git リポジトリへ集約することではありません。情報の種類ごとに、競合しない正を決めることです。

同じ NTP サーバーの値を Excel、Ansible、Wiki、手順書へ個別に書けば、正本が増えたのではなく複製が増えただけです。どこを変更すれば他の成果物へ反映されるのかを一意にします。

望ましい状態を構造化して持つ

たとえば、サーバーの共通設定を次のような構造化データとして持ちます。

system:
  timezone: Asia/Tokyo
  ntp_servers:
    - 10.1.0.10
    - 10.1.0.11
  dns_servers:
    - 10.1.0.53
    - 10.1.0.54

metadata:
  owner: infrastructure-team
  design_decision: ADR-0042

値だけでなく、所有者や設計判断への参照を持たせると、なぜ変更したのかを追いやすくなります。このデータを Ansible の変数、テンプレート生成、検証処理、Excel 出力の入力として再利用できます。

ただし、構造化しただけで構成管理になるわけではありません。schema、型、必須項目、許容値、環境差分、秘密情報の参照方法を定義し、テストとレビューへ接続する必要があります。

Git に置けば解決するわけではない

Excel を YAML に変換して Git へ置いても、誰も適用せず、実機との差分も確認しなければ、ファイル形式が変わっただけです。

OpenGitOps は、GitOps の原則として、望ましい状態が宣言的であること、履歴を保持する形で version 管理されること、agent が自動的に取得すること、実際の状態と継続的に reconciliation することを挙げています。重要なのは Git そのものより、望ましい状態と実際の状態を継続的に近づける仕組みです。

• 構文と schema を CI で検証する
• 変更差分を pull request でレビューする
• 適用対象と環境を明示する
• dry-run、plan、check mode で影響を確認する
• 適用結果と実機状態を収集する
• drift を検出し、例外として記録する

コード化、version 管理、自動反映、状態照合は別々の能力です。どこまで実装できているかを分けて評価します。

Excel は人間向けのビューに戻す

Excel を廃止する必要はありません。正本から生成されるビューとして使えば、Excel の一覧性を保ちながら、値の二重管理を減らせます。

• Git、IPAM、CMDB などから値を取得する
• 項目名、説明、設計値、判断 ID を表へ変換する
• 生成日時、データソース、commit ID を明記する
• 生成列と、人間が追記するレビュー列を分ける
• 提出後に Excel だけが修正されない変更手順を決める

特に重要なのは provenance です。そのセルが、どのリポジトリ、どの commit、どの API 応答から生成されたのかが分かれば、Excel は行き止まりの成果物ではなく、正本へ戻れるビューになります。

Excel を入力に残す場合

現実には、顧客指定の様式、ベンダーへの提出、GUI 専用製品、API がない装置など、Excel を入力に残さざるを得ない場合があります。その場合も、Excel を無検証で人手投入するのではなく、境界を設計できます。

• 入力規則で型、範囲、必須項目を制限する
• 列名と schema の対応を固定する
• CSV や JSON へ変換し、自動検証する
• 変換後のデータを version 管理する
• 実機投入後に設定を再取得し、入力値と照合する
• 手動変更が必要な項目は、担当者と証跡を残す

Excel が入口であることと、Excel が最終的な正であることは違います。入口を変えられなくても、検証、変換、適用、照合の流れは設計できます。

GUI でしか設定できない製品をどう扱うか

GUI でしか操作できない製品では、完全な IaC は難しくなります。それでも、設定前後のスクリーンショットだけを証跡にして終わる必要はありません。

• 設定値をエクスポートできないか確認する
• 読み取り専用 API、CLI、バックアップファイルを利用する
• 自動化できない操作と、自動検証できる結果を分ける
• 変更前後の状態取得を手順へ含める
• 手動操作の順序、権限、確認者、rollback 条件を明記する

操作を自動化できなくても、状態の取得と差分確認を自動化できる場合があります。自動化できるかどうかを製品単位で二分せず、入力、適用、確認、復旧の工程ごとに見ます。

Excel パラメータシートから移行する手順

1. シートの役割を分類する：要件、設計値、投入値、実機値、説明、承認の列を分けます。
2. 情報ごとの正を決める：Git、IPAM、CMDB、Secret Manager、チケットなど、変更元を一意にします。
3. 機械可読な schema を作る：型、必須項目、許容値、環境差分を定義します。
4. 小さな範囲で自動化する：NTP、DNS、時刻帯など、影響と確認方法が明確な項目から始めます。
5. 適用前の検証を作る：lint、schema validation、dry-run、plan を CI に組み込みます。
6. 実機との差分を取る：設定取得と drift 検出を運用へ入れます。
7. Excel を生成物にする：レビューや提出に必要な列だけを正本から出力します。

最初からすべてを IaC にしようとすると、例外処理と既存運用の調整だけで止まりやすくなります。情報の正と検証方法が明確な範囲から移し、戻せる状態で進めます。

参考情報

• OpenGitOps: GitOps Principles
  宣言的な望ましい状態、version 管理、自動取得、継続的な reconciliation という 4 原則を確認できます。
• Kubernetes: Declarative Management Using Configuration Files
  構成ファイルで望ましい状態を管理し、差分を適用する宣言的管理の具体例です。
• Ansible: How to build your inventory
  管理対象、group、variable を inventory として構造化し、環境ごとの値を管理する考え方を確認できます。

参考書籍

まとめ

Excel パラメータシートは、人間が設定値を一覧し、レビューし、提出するための道具として有効です。しかし、設計値、実装値、実機値、変更履歴を同じシートのセルで管理すると、どれが現在の正なのか分からなくなります。

設定管理では、要件と判断、望ましい状態、適用処理、実機状態、人間向けビューを分けます。Git や IaC に移すことだけが目的ではなく、望ましい状態と実際の状態の差を検出し、必要な状態へ戻せることが重要です。

Excel をなくすのではなく、正本から生成される説明用のビューへ戻す。GUI 専用製品で Excel を入力に残す場合も、検証、変換、適用、照合の境界を作る。この順序で考えると、Excel の便利さを残したまま、設定管理の再現性を高められます。

関連記事

トップダウンとボトムアップの考え方 – 設計と現場理解の両方が必要になる理由 通信キャリアは土管屋なのか – ネットワーク事業者に求められる技術責任 SIer と IT 事業会社の違い – 技術経験を積める環境はどちらか 出社回帰をどう見るか – 働き方を場所ではなく成果と設計で考える ネットワークに詳しいと言う前にルーティングテーブルを読めるか エンジニアが働く企業の理想像 – 技術レイヤーと経験の質で考える 運用オペレーター的な現場ではエンジニア経験を積みにくい エンジニアと情シスの違い – 技術設計と社内 IT 運用を混同しない