システムの構成管理について

構成管理とは

システムを開発する際には、様々なソフトウェアを組み合わせて使用する必要があります。
使用するソフトウェアは、将来更新される可能性が高いため、何が用いられているのかを把握するのが構成管理です。
構成管理の対象は、ソフトウェアだけでなく、ハードウェアやネットワークなど、システムを構成する全ての要素を含みますが、ここではソフトウェアの構成管理に着目したいと思います。

ソフトウェアの構成管理では一般的に、使用しているソフトウェアが何者であるか、つまり、名称、バージョン、ベンダー、契約等が記載、管理されます。従来のシステムでのソフトウェアは、オンプレミスのマシンルームに置かれたサーバにインストールされて使うことが前提でした。
従来から言われている構成管理も、このような「オンプレミスのマシンルームに置かれたサーバにインストール」されたソフトウェアの管理という観点から発展してきたものと考えられます。
サーバにインストールされるソフトウェアには、
・OSやその周辺
・DBMSやアプリケーションサーバなどのミドルウェア
・開発したソフトウェア
・開発したソフトウェアが使用する各種ライブラリ等
・暗号化、認証やシングルサインオン、信頼性向上、その他様々な役割のソフトウェア
などがあります。
さらに、現代のシステムは、クラウドを縦横無尽に使い、IaaS、PaaS、SaaSサービスを混在させて構成するようになってきました。

構成管理の現状

システムがクラウド上で稼働すると、構成管理対象のシステムの範囲があいまいになってきます。
SaaSで提供されるサービスは、インストールするソフトウェアではなく、購入資産でもなく、バージョン管理の必要もないので、従来の基準だと構成管理の対象外です。
しかし、求める機能を実現するための必須要素であることについては、疑いの余地はありません。
また、ソフトウェアの開発自体も、市場から(主にオープンソースで)調達できる様々なライブラリやツールを駆使して行うようになっており、その複雑さに対応するため、Makeからの拡張で、コンパイル時に必要とされるライブラリを自動的に適切な状態にする、JavaのMavenなどのツールが使われています。
また、コンピュータの稼働環境の構成を管理し、自動で設定するツール(Ansible)も使われるようになってきています。
つまり、現在の構成管理は、管理対象が広がっている中で、昔からあるミクロな構成管理は自動化の流れが存在している状況です。
そこで問題になるのは、「構成管理」という言葉の意味が広がっていることです。従来の構成管理を意図している場合、クラウドサービスを含めたこれからの構成管理を意図している場合、ミクロな自動化できる範囲を意図している場合がありえます。構成管理という言葉は、単独で使うと誤解される可能性があると意識する必要があります。

これからの構成管理

構成管理の対象が広がったことから、対象物を適切に分類し、それぞれの特性に応じた情報を管理・把握する必要性が高まっています。
そのためには、対象物を明確に認識、定義できる必要があります。
(1)自社独自機能を適切に分割し、それぞれに固有名を付与すること。
(2)他社製品・サービスの、商品構造を理解して、適切な単位で管理すること。
(3)どこで使うのかを管理すること。
これらが重要となってきます。

(1)については、一般的には同時期に開発したシステムが一つのモノとして扱われることが多いと思われます。しかしながら開発時期とその時の対象範囲は予算や経営上の意志決定によって決まるものであり、システムの構造として適切な単位となっていない場合が多いと考えられます。
システムの機能は、「次回更新する際の取り扱い最小単位」を意識して分割すると良いです。これは、業務的・システム的に疎結合となる(にできる)箇所でシステムを分割することに繋がります。すると、長期的なシステムの更改、改良の取り扱い単位を小さくでき、無駄な投資を避け、必要な改善がタイムリーに実施できるシステムにできます。

(2)については、製品提供元が商品やサービスのグループに名称を与えている場合に、どの粒度で商品やサービスを識別すべきかという問題です。
例えば、Microsoft Office(以下Office)という製品があり、ここにはMicrosoft Excelという製品が含まれています。構成管理の対象として、OfficeとExcelの両方を対象とすると、Excelは重複管理されることになります。また、Officeだけを管理すると、Officeはライセンスモデルによって含まれるソフトウェアの構成が異なるので、管理対象をソフトウェア毎に特定できません。
では、Officeのライセンスモデルで管理するという方法もありますが、ライセンス毎の商品構成は販売元の都合で変わりうるので、管理対象が不明になるリスクがあります。
このことから、他社販売の商品やサービスの管理は、販売されている商品・サービスの最小単位に分解して管理しておく必要があります。
そうすることで、商品・サービスの提供側による変更に対して、影響範囲を最小に留め、対策を行うことが可能になります。
従来の構成管理は、購入時の購入単位毎に行われることが多いと思いますが、購入単位は購入時の時点情報(そのときに正として確定する情報)に過ぎません。システムの構成管理は、システム利用期間中必要となるものなので、時点情報に依存すること無く、商品・サービスの固有の性質に基づいて管理されるべきです。

(3)については、もともとオンプレミスのサーバ環境だけ考えていればよかったところが、クラウドサーバやSaaSも構成に含まれるようになったことによります。
オンプレミスのサーバ環境では、どのサーバ上で何が動くかを管理すれば十分でした。サーバが仮想化されても多重化されても、1つのサーバという実体は明確に定義できました。
システム全体構成の中の必須要素としてPaaSのサーバだけでなく、SaaSが含まれるようになったとき、SaaSで提供されるサービスは構成管理の対象となり、そのサービスがどのサーバで動いているかは意味を持たなくなります。
システムの構成要素の管理項目として、「どのサーバ」ではなく、「どこで、どのようにして」稼働するものかを加える必要があります。

管理責任の所在

構成管理の対象物は、多岐にわたります。購買の対象物だけでなく、ダウンロードしたオープンソースもあります。つまり、構成管理はシステム全体を把握しないと実施不可能です。
システム毎に構成管理を行うこともありますが、システム間の接続性はこれからさらに重要になってきます。SaaSなどでは、同一のサービスや類似の競合するサービスを部門毎に導入するようなこともあるかもしれませんが、当然費用の無駄に繋がります。
ユーザ部門の利便のための企画、購買、予算措置といった行為をユーザ部門でまかなうことに問題はありません。一方、情報処理システムは、部門毎に独立したモノではありません。個々の機能のユーザは特定部門に集中するかもしれませんが、ネットワークを介してシステム間が連携して会社の業務全体が実現されています。
つまり、システムの構成管理は、各部門が使用するシステムの相互依存関係を把握する必要があると言えます。そのため、全社システムを横串でとらえることができる部門が管理責任を持つことが必須となります。
一方で、全体構成が管理された中で、個々の構成要素をそれぞれの部門が面倒を見るというのは現実的なやり方だと思います。

あらためて、これからの構成管理

・組織全体のシステム構成を把握すること。そのココロは、いまや全てのシステムが連携しているか、将来連携できるようにするため。
・構成要素を適切に設定し、それぞれに適切な名前を付与することで、実体として認識できるようにすることはとても重要。
・クラウドのサービスも構成要素として管理する。
・クラウドサービスが要素として加わることで、管理項目も変わる。動作環境・場所の把握がより重要になる。
・購買単位での構成管理は、実情と合わなくなるので良くない。購入したモノの実体を把握して、構成要素そのもので管理するべき。

(2021/11)