Loading article…
構成管理( CM ) は、製品のライフサイクル全体を通して、製品の性能、機能、および物理的属性と要件、設計、および運用情報との一貫性を確立および維持するための管理プロセスです。[ 1 ] [ 2 ] CM プロセスは、兵器システム、軍用車両、情報システムなどの複雑なシステムのシステムライフサイクル全体にわたる変更を管理するために、軍事工学組織で広く使用されています。軍事以外では、CM プロセスは、 ITILで定義されている IT サービス管理内、および道路、橋、運河、ダム、建物などの土木工学やその他の産業工学セグメントの他のドメインモデルでも使用されています。[ 3 ] [ 4 ] [ 5 ]
システムのライフサイクル全体にわたってCM（構成管理）を適用することで、システムのパフォーマンス、機能、および物理的特性を可視化し、制御することができます。CMは、システムが意図どおりに動作し、想定されるライフサイクルをサポートするのに十分な詳細さで文書化されていることを検証します。CMプロセスは、機能の改訂、パフォーマンス、信頼性、保守性の向上、寿命の延長、コスト削減、リスクと責任の軽減、欠陥の修正などの目的で、システム情報とシステム変更を秩序立てて管理することを容易にします。CMの導入にかかる費用は比較的少なく、コスト削減によって何倍もの見返りが得られます。CMの欠如（または不十分な導入）は非常に高額な費用がかかる可能性があり、機器の故障や人命の損失といった壊滅的な結果を招くこともあります。
CM は、システム変更を効果的に制御するために、部品、サブシステム、およびシステム間の機能的な関係を重視します。提案された変更が悪影響を最小限に抑えるために体系的に検討されていることを検証するのに役立ちます。システムへの変更は、一貫性を確保する標準化された体系的なアプローチを使用して提案、評価、および実装され、提案された変更は、システム全体への予想される影響の観点から評価されます。CM は、変更が仕様どおりに実行され、アイテムとシステムのドキュメントがその実際の構成を反映していることを検証します。完全な CM プログラムには、コンポーネント、サブシステム、およびシステム単位ですべてのシステム情報を保存、追跡、および更新するための規定が含まれます。[ 6 ]
体系化された構成管理（CM）プログラムは、品目に関する文書（要件、設計、テスト、受入に関する文書など）が正確であり、品目の実際の物理的な設計と整合していることを保証します。多くの場合、CMがない場合、文書は存在していても、品目自体と整合していません。そのため、エンジニア、請負業者、および管理職は、変更を進める前に、品目の実際の状態を反映した文書を作成せざるを得ないことがよくあります。このリバースエンジニアリングプロセスは、人的資源やその他の資源の無駄遣いであり、CMを使用することで最小限に抑えるか、排除することができます。
構成管理は、 1950年代に米国国防総省でハードウェア資材の技術管理規律として始まり、現在では事実上あらゆる業界で標準的な慣行となっています。 CMプロセスは、1960年代後半に国防総省が「480シリーズ」（MIL-STD-480、MIL-STD-481、MIL-STD-483）と呼ばれる一連の軍事規格を開発し、その後1970年代に発行されたことで、独自の技術規律となりました。 1991年、「480シリーズ」はMIL-STD-973として知られる単一の規格に統合され、その後、標準化団体（SDO）がサポートする業界技術規格を優先して軍事規格の数を減らすという国防総省の一般的な目標に従って、MIL-HDBK-61に置き換えられました。[ 7 ]これが、現在CMに関する最も広く普及し受け入れられている規格であるANSI-EIA- 649-1998の始まりとなりました。[ 8 ]現在、多くの組織や機関で広く採用されているCM分野の概念には、システムエンジニアリング（SE）、統合ロジスティクスサポート（ILS）、能力成熟度モデル統合（CMMI）、ISO 9000、Prince2プロジェクト管理手法、COBIT、ITIL、製品ライフサイクル管理、アプリケーションライフサイクル管理が含まれます。これらの機能やモデルの多くは、技術管理に対する従来の包括的なアプローチからCMを再定義しました。CMを司書の活動に似たものとして扱い、変更制御または変更管理を独立した分野として分離する人もいます。
CM は、システムが時間の経過とともに整合性を維持できるように、変更を体系的に処理する手法です。CM は、システムの変更に伴って提案された変更を管理、評価し、変更状況を追跡し、システムおよびサポート文書のインベントリを維持するためのポリシー、手順、技術、およびツールを実装します。CM プログラムと計画は、複雑なシステムを正常に開発およびサポートするために必要な手順、機能、サービス、ツール、プロセス、およびリソースの開発と実装に対して、技術的および管理的な指示を提供します。システム開発中、CM により、プログラム管理は、受け入れから運用および保守に至るまで、ライフサイクル全体にわたって要件を追跡できます。要件と設計に必然的に変更が発生するため、変更は承認され、文書化され、システムの状態の正確な記録が作成されます。理想的には、CM プロセスはシステムのライフサイクル全体にわたって適用されます。多くの専門家は、資産管理 (AM、 ISO/IEC 19770も参照)と混同したり、混乱したりしています。資産管理は、手元にある資産をインベントリ化します。 CMとAMの主な違いは、前者は財務会計面ではなく、システムがサポートするサービスを管理すること、言い換えれば、後者（AM）はIT資産から価値を実現しようとしていることである。[ 9 ] [ 10 ] [ 11 ]
ハードウェアとソフトウェアの両方の構成アイテムに対する CM プロセスは、MIL-HDBK-61A [ 12 ]および ANSI/EIA-649 で定められた 5 つの明確な規律から構成されます。標準的な変更管理プロセスを適用することに関心のある組織のメンバーは、これらの規律を、ベースラインの設定、変更の管理と制御、進捗状況の有効性と正確性の監視と評価のためのポリシーと手順として使用します。IEEE 12207プロセス IEEE 12207.2 にもこれらの活動があり、「リリース管理と配信」が追加されています。 その5つの分野とは：
ソフトウェア構成管理（SCM）プロセスは、ソフトウェアプロジェクトにおける変更への対応策として、実務担当者から最良のソリューションとみなされています。SCMは、ソフトウェアの機能的属性と物理的属性を様々な時点で特定し、ソフトウェア開発ライフサイクル全体を通してソフトウェアの整合性とトレーサビリティを維持するために、特定された属性への変更を体系的に管理します。
SCMプロセスでは、変更履歴を追跡する必要性、および最終的に納品されるソフトウェアにリリースに含まれるはずのすべての計画された機能強化が含まれていることを検証する能力がさらに明確に定義されています。健全なSCMプロセスが実装されるように、各ソフトウェアプロジェクトで定義する必要のある4つの手順が特定されています。それらは以下のとおりです。
これらの用語と定義は、規格によって多少異なる場合があります。
ITILでは、構成管理における業界のベストプラクティスを実現する手段として、構成管理システム（CMS）または構成管理データベース（CMDB）の使用を規定しています。CMDBは、構成アイテム（CI）とそれらの間の依存関係を追跡するために使用されます。CIとは、企業内で追跡および管理する価値のあるもの、例えばコンピュータ、ソフトウェア、ソフトウェアライセンス、ラック、ネットワーク機器、ストレージ、さらにはそれらのアイテム内のコンポーネントなどを指します。CMSは、統合されたCMDBコレクションの管理を支援します。
CMS/CMDBの利点としては、根本原因分析、影響分析、変更管理、将来戦略策定のための現状評価といった機能を実行できることが挙げられます。
構成管理（CM）は、ITIL固有のITSMプロセスであり、単一のサーバーのような単純なものから、IT部門全体のような複雑なものまで、 ITシステム内のすべての構成アイテム（CI）を追跡します。大規模な組織では、構成マネージャーが任命され、CMプロセスを監督および管理することがあります。ITILバージョン3では、このプロセスはサービス資産および構成管理と名称変更されました。
情報保証の場合、CM は、情報システムのライフサイクル全体にわたってハードウェア、ソフトウェア、ファームウェア、ドキュメント、テスト、テスト フィクスチャ、およびテスト ドキュメントに加えられた変更を制御することによって、セキュリティ機能と保証を管理することと定義できます。[ 13 ]情報保証のための CM は、セキュア構成管理(SCM) と呼ばれることもあり、IT プラットフォームと製品およびその環境のパフォーマンス、機能、および物理的属性に基づいて、システム構成状態を測定するために使用される適切なセキュリティ機能と保証を決定します。たとえば、組織のインターネット境界の一部として機能しているネットワーク ファイアウォールと、内部ローカル ネットワーク ファイアウォールとして機能しているネットワーク ファイアウォールでは、構成要件が異なる場合があります。
構成管理は、複雑な資産の状態を把握し、最小限のコストで最高のサービス性を維持するために用いられます。具体的には、資産（または資産の一部）が計画寿命を超過したり、品質レベルを下回ったりすることによって、業務が中断されないようにすることを目的としています。
軍事においては、この種の活動はしばしば「任務遂行準備」と分類され、どの装備がどの種類の任務に利用可能かを明確にすることを目的としている。典型的な例としては、空母に搭載されている航空機が地上支援用の爆弾を搭載しているか、防御用のミサイルを搭載しているかといった点が挙げられる。
構成管理は、 OS構成ファイルの維持に使用できます。[ 14 ]これらのシステムの多くは、構成の定義と維持にInfrastructure as Codeを利用しています。 [ 15 ]
構成保守のプロミス理論はマーク・バージェスによって開発され、[ 16 ] [ 17 ] [ 18 ]現在のコンピュータシステムでは、リアルタイム修復と予防保守を実行できるソフトウェアCFEngineで実際に実装されています。
資産とその主要構成要素の「現状」を理解することは、保守、修理、オーバーホール、および企業資産管理システムで使用される予防保全において不可欠な要素である。
航空機、船舶、産業機械などの複雑な資産は、多くの異なるコンポーネントが正常に機能することに依存しています。この機能性は、多くの場合、新品時からの使用量、取り付け時からの使用量、修理時からの使用量、耐用年数全体における使用量、およびその他のいくつかの制限要因によって定義されます。これらの各コンポーネントの耐用年数がどの程度近づいているかを把握することは、ソフトウェアの最近の開発までは、労力を要する記録管理を伴う大変な作業でした。
多くの種類のコンポーネントは、電子センサーを使用してデータを収集し、リアルタイムの状態監視を行っています。このデータは、搭載された状態、または遠隔地のコンピューターで分析され、現在の稼働状況が評価されるとともに、現場での経験やモデリングを通じて過去の故障事例に基づいて将来起こりうる故障を予測するアルゴリズムを用いて、将来の状態も予測されるようになっています。これが「予知保全」の基礎となっています。
CM（構成管理）が運用上の価値を提供するためには、正確かつタイムリーなデータが不可欠であり、これが不足すると制約要因となることが多い。運用データを収集し、様々なサポート組織に配布することは、それ自体が一つの産業になりつつある。
機器メーカー（OEM）が提供するプログラムの増加に伴い、このデータの利用者はより多く、より複雑化している。これらのプログラムは、オペレーターに確実な稼働を保証することを目的としており、オペレーターが資産を管理する一方で、OEMがその保守性を保証する責任を負うという、より複雑な状況を生み出している。
構成管理をサポートまたは含む規格は多数あり、[ 19 ]以下はその例である。
近年では、構成管理は大規模な建設プロジェクトにも適用されています。これらのプロジェクトは非常に複雑で、文書化する必要のある詳細や変更が膨大になることがよくあります。連邦道路局などの建設機関は、インフラプロジェクトに構成管理を使用しています。[ 32 ]建設ベースの構成管理ツールは、プロジェクトがスケジュールと予算内で進むように、変更指示書やRFIを文書化することを目的としています。これらのプログラムは、インフラが完成した際の保守や変更に役立つ情報を保存することもできます。そのようなアプリケーションの1つであるCCSNetは、連邦運輸局（FTA）が資金提供したケーススタディでテストされました。このケーススタディでは、ロサンゼルス郡都市交通局（LACMTA）のレッドラインの第1セグメントと第2セグメント（53億ドルの鉄道建設プロジェクト）の約80%完了した建設を比較することで、構成管理の有効性が測定されました。この研究は、このような性質のプロジェクトで構成管理を使用することに利点があることを示す結果をもたらしました。[ 33 ]
{{cite web}}: CS1メンテナンス: アーカイブサービスは非推奨になりました (リンク){{cite web}}: CS1メンテナンス: アーカイブサービスは非推奨になりました (リンク). 構成管理ライフサイクル管理と計画 [...] 5. 構成識別 [...] 6. 構成制御 [...] 7. 構成ステータス会計 [...] 8. 構成検証と監査 [...] 9. データ管理 [...]
{{cite web}}: CS1 maint: タイトルとしてアーカイブされたコピー (リンク){{cite web}}: CS1 maint: タイトルとしてアーカイブされたコピー (リンク)