［変更管理編］変更管理をExcelでやってはいけない

　皆さんの現場では、変更管理にどのようなツールを使っているだろうか。SubversionやMicrosoft Visual SourceSafe（VSS）といったツール名をすぐに思い浮かべるかもしれない。しかしそれらは構成管理ツールであって、変更管理のためのものではない。「変更構成管理ツール」と称される製品も多く、混同しがちなので簡単に整理してみよう。

　変更管理ツールは、ユーザーなどから変更依頼を受け付け、影響度や優先度を評価し、実施するかどうかを判断するためのもの。実施が決まった変更依頼には、作業指示の情報を加え、作業のステータスを管理することも含まれる。

　一方の構成管理ツールは、成果物（ドキュメントやプログラムソースなど）の変更に応じてバージョン管理したり、複数のITエンジニアが同時にアクセスしてもデグレードしないように排他制御を行ったりする。つまり変更管理では変更依頼を管理するのに対し、構成管理では変更対象となる成果物を管理するのだ。

　こう説明すると、「なるほど変更管理に関してはExcelでやっている」と思う読者がいるだろう。確かにExcelは手軽に利用できるソフトなので、変更管理をできなくはない。

　だが、変更管理をExcelでやってはいけない。手間がかかることが多く、変更管理の作業が非効率になるからだ。「Excelでやって何が悪い」と思う読者もいるかもしれないが、以下にその問題点をいくつか挙げる。

情報が共有されにくい

　Excelで変更管理を行う場合、プロジェクト専用のファイルサーバー上に、変更管理用のExcelファイルを置くことになる。これだとプロジェクトのメンバー同士での共有は図れるが、サーバーにアクセスできないユーザーや協力会社との情報共有はやりにくい。

　ユーザーとの情報共有は、変更依頼それぞれのシステムや業務に対する影響度や優先度を決めてもらうために必要だし、協力会社とは変更作業のステータス管理で情報を共有する必要が出てくる。そうなると、メールにExcelファイルを添付して送るといった手間がかかってしまう。最近ではクラウド上のスプレッドシートを使うこともできるが、前例踏襲でメールにExcelファイルを添付してやり取りしている現場はまだ多いだろう。情報共有のやりやすさを考えると、サーバーでのExcel管理は見直すべきだ。

アクセスと承認のコントロールがしづらい

　本来、変更管理では、管理項目ごとにアクセスコントロールをする必要がある。変更要求はユーザーを含めて誰が書き込んでも構わない。しかし、その要求の受け付け処理や対応状況などに関する管理項目は、プロジェクトの限られた担当者しかアクセスできないようにしないと、収拾がつかなくなる。管理項目に対する更新や参照の可否もコントロールしなければならない。

　Excelでは、こういった管理は難しい。ユーザー用とITエンジニア用の二つのExcelファイルをそれぞれ用意して、個別に入力してもらうといった、余計な手間がかかってしまう。

　承認のコントロールが難しいのも致命的だ。変更管理では変更依頼に対して、変更にかかるコストや優先度の決定、それを踏まえて実施するかどうかの判断と承認を、規定した流れで行う必要がある。Excelにはこうした承認管理の機能がないので、運用でカバーしなければならない。

作業経過の管理や集計処理がしにくい

　承認された変更は、作業指示のもとで実行する。このとき、作業の経過をステータスとして管理し、適宜報告することになる。一連の作業経過を、2次元の表形式のリストであるExcelで管理するのは難しい。

　また、Excelの場合、プロジェクトごとに一つのファイルで管理することが多い。そうなると、複数プロジェクトのデータを集計・分析したい場合、複数のExcelファイルにわたって集計しなければならず、スムーズにいかない。

　過去のプロジェクトでどのような変更がどれだけ発生するかといったことを、規模別や工程別など、さまざまな角度で集計・分析することができなければ、新たなプロジェクトの計画時に、役立てることは難しい。

　他の業界と同様、IT業界も合理化していかなければ生き残れない。そもそもITエンジニアはシステムを作るプロなのだから、本来は表計算ソフトであるExcelで、変更管理をすることに問題意識を持つ必要がある。

　変更管理のフリーソフトはたくさんあるし、自分たちでも簡単に作れるはずだ。会社や組織で共通したWebシステムで変更管理をしていくべきである。