Excel パラメータシートからの解放 – 設定管理を表計算から構成管理へ移す

エンジニアとして業務の中で退屈に感じやすい作業の一つに、製品やシステムのパラメータシートを Excel で作る作業があります。設定項目を洗い出し、デフォルト値を書き、設計値を書き、備考欄に注意点を残す。業務として必要なのは分かりますが、これを延々と Excel で管理することにはかなり限界があります。

ただし、Excel を全面的に否定したいわけではありません。表形式で情報を整理する道具として、Excel は非常に強力です。パラメータ一覧を人間が読む、レビューする、顧客に説明するという場面では、今でも便利な道具です。

問題は、Excel のパラメータシートを設定管理の正本にしてしまうことです。設計値、実装値、履歴、差分、レビュー、反映状態まで Excel に閉じ込めると、運用の再現性がかなり弱くなります。

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

パラメータシートが Excel で作られやすい理由は分かります。設定管理は、見た目としては表にしやすいからです。

• 設定項目の名前
• 設定項目の説明
• デフォルト値
• 設計値または設定値
• 値を変更する理由
• 備考や注意点

このような項目は表形式と相性が良いです。だから Excel で作ること自体は自然です。特に、非エンジニアを含めたレビューや説明では、Excel の方が伝わりやすい場面もあります。

しかし、表として見やすいことと、設定管理の正本として適切であることは別です。

Excel を正本にすると何がつらいのか

Excel パラメータシートを正本にすると、設定がどのように変わったのかを追いにくくなります。セルの変更は Git の差分として扱いにくく、レビューもしづらく、なぜその値になったのかを後から追うのが難しくなります。

さらに、Excel に書かれた値が実際のシステムへ反映されているとは限りません。Excel 上の設計値、構築時に投入した値、現在稼働している値がずれていても、気づきにくい構造になります。

• 差分がレビューしにくい
• 変更理由が履歴として残りにくい
• 実機との差分を検出しにくい
• 自動テストや構文チェックに乗せにくい
• 再構築時に同じ状態を再現しにくい

この状態では、Excel は設計書でありながら、実際には運用の負債にもなります。

設定管理はコードに寄せた方がよい

結論として、設定管理はできるだけコードに寄せた方がよいと思います。Linux サーバーであれば Ansible、Kubernetes であれば YAML や Helm、ネットワーク機器であれば設定テンプレートや自動化ツールなど、環境に合わせた形で正本を持つ方が自然です。

たとえば、設定値を次のような構造化されたデータとして管理できれば、差分、レビュー、再利用、自動反映がしやすくなります。

ntp_servers:
  - 10.1.0.10
  - 10.1.0.11

dns_servers:
  - 10.1.0.53
  - 10.1.0.54

timezone: Asia/Tokyo

このような形式であれば、設定値がどこにあるのか、いつ変更されたのか、どの環境に適用されるのかを追いやすくなります。Excel のセルに値を埋め込むより、構成管理の文脈に乗せやすいです。

Excel は補助資料に戻す

Excel を完全になくす必要はありません。むしろ、説明資料やレビュー用の一覧として使うなら十分に価値があります。

ただし、正本は Excel ではなく、構成管理側に置くべきです。Excel はそこから生成される資料、または人間向けのビューとして扱う方が健全です。

• 正本は Git 管理された構成ファイルに置く
• Excel はレビュー用、説明用、提出用のビューにする
• 実機との差分確認を自動化する
• 変更理由はコミットやレビュー履歴に残す
• 再構築できることを前提に設計する

この形にすると、Excel は便利な表現手段に戻ります。Excel が悪いのではなく、Excel に正本、履歴、反映、証跡のすべてを背負わせることが問題なのです。

GUI でしか操作できないものがつらい理由

個人的には、GUI でしか操作できない製品や設定がかなり苦手です。理由は単純で、構成管理に乗せにくいからです。

GUI 操作は、人間がその場で何をクリックしたかに依存します。手順書を書けば再現できるように見えますが、実際には画面のバージョン、権限、操作順、入力ミス、確認漏れに左右されます。

一方で、設定をコードとして扱えれば、少なくとも変更内容をレビューできます。再実行できます。差分を確認できます。失敗した時に戻しやすくなります。運用の安定性という意味では、この違いはかなり大きいです。

業務設計としての脱 Excel

脱 Excel とは、Excel を使わないことではありません。Excel に向いている役割と、向いていない役割を分けることです。

パラメータシートを Excel で作る文化は、レビューや提出の形式としては理解できます。しかし、設定管理そのものを Excel に閉じ込めると、エンジニアリングとしての再現性が落ちます。

設定値は、できるだけ機械が読める形で管理する。人間向けの一覧は、その正本から生成する。この順序に変えるだけで、運用の質はかなり変わると思います。

関連記事

• VBA を扱う人をエンジニアだと思う企業は非 IT 企業 – 技術職の理解不足を見抜く
• エンジニアと情シスの役割構造の違い – 技術設計と社内運用を混同しない
• AI を中途半端にしか使えない理由 – プロンプト術より構造化が重要
• エンジニアのキャリアは良い経験を積めるかで決まる – 技術責任を持てる環境を選ぶ

まとめ

Excel パラメータシートは、情報を一覧化する道具としては便利です。しかし、設定管理の正本として使うには限界があります。差分、履歴、レビュー、再現性、実機との差分確認に弱いからです。

これからの設定管理は、できるだけ IaC や構成管理に寄せた方がよいと思います。Excel は正本ではなく、人間向けのビューや補助資料に戻す。その方が、設計も運用もずっと健全になります。

私は、IaC にできないもの、GUI でしか操作できないものがかなり苦手です。なぜなら、それは運用を人間の記憶と手作業に戻してしまうからです。設定は、できる限り再現可能で、レビュー可能で、機械的に扱える形にしておきたいと思います。

Related posts:

IT エンジニアは会社ではなくスキルに所属する ネットワークエンジニアのキャリア 出張で使うホテルはプリペイドカード付きにしてお得にしよう スマートフォンの業務利用には優れたアプリが必要 求人票で「高いコミュニケーション能力」と書く企業が危険な理由 – 要件定義できない組織を見抜く SIer はオワコン論と中途半端な IT 事業会社の比較 IIJ の否めない中途半端感 プロンプトエンジニアリングに惹かれる人は非エンジニア層なのか – AI 活用と構造化能力の違い エンジニアの仕事は一般とは全く違うことを理解しましょう Shift という会社は高度なエンジニアが入社するべきではない VBA を扱う人をエンジニアだと思う企業は非 IT 企業 – 技術職の理解不足を見抜く 情シスの正体 – 企業文化が生んだ「狭く浅い IT」