設定制御–手錠を離せ!

業界や垂直セクターにわたるすべてのビジネスのグローバル性がますます複雑化しており、急速な”インターネットタイム”ビジネスモデルと相まって、変 変化を効果的に管理する能力は、競合他社の間で差別化の鍵として浮上しています。これにより、組織はビジネスモデルや製品ラインを進化させ、現在の経済の機会を満たすのに十分な速さでギアを変更することができます–競争に先んじて。

組織がこの環境でプロジェクトを管理するのに苦労しているため、構成管理（CM）はますます重要なコンポーネントになり、変更を管理するためのフレー

CMの規律は、EIA-649(ANSI)で定義されている六つの専門分野で構成されています, 2004))

• CM Planning and Management(CMPM)、
• 構成識別(CI)、
• 構成変更管理(CCM)、
• 構成ステータス会計(CSA)、
• 構成検証&監査(CVA)、およびデジタルデータの
• CM。

しかし、ISO10007(ISO,2003)はCMを四つの分類に分類している。:

• CI、
• 構成制御（CC）、
• CSA、および
• 構成レビューおよび監査（R&A）。

(CCMとCCは、CVAとR&Aと同様に、すべての実用的な目的のために同一です。)

構成制御については、この記事で説明していることに注意してください。 構成変更管理と変更制御は、同じプロセスを記述するために使用される用語でもあります。

多くのプロジェクトマネージャーは、構成制御を、製品開発を妨げるように設計されたシステムであり、通常はプロジェクトのスケジュールに悪影響を与 残念なことに、武器や医療システム開発などの大規模で複雑なプログラムのために設計された一般的なCCプロセスは、他のタイプのプロジェクトに これらのプロセスは、Web開発や新製品のロールアウトなどのニーズを満たすように調整されていません。 これは最終的にCCプロセスと”手錠”効果との強い欲求不満につながります–プログラムのニーズを満たすように設計されていないプロセスが進歩に負

プロジェクトマネージャは、変更を制御および追跡するための構成制御を実装します。 プロセスは、適切なレベルが変更を承認するために使用され、これらの変更が利用可能な最良の情報に基づいていることを確認するように設計され このプロセスは、変更レビューのためのフレームワークを提供します。 これにより、チームは変更を実施することが許容できるかどうかを評価し、潜在的な問題を適時に特定することができます。 これらのプロセスは口径測定を可能にし、必要ならば、それ以上の修正。

本当の問題は、構成制御を実装するかどうかではなく、どのレベルの構成制御を実装するかです。 組織では、すべてのプロジェクトで”会社標準”構成制御パッケージが必要な場合があります。 このタイプのシステムは、多くの場合、構成制御の欠如の歴史とその結果として生じる財務的影響のためにプロジェクトチームに課されます。 プロジェクトマネージャーは、”万能”アプローチが機能しないことを認識し、過去の間違いを繰り返さないように適切なコントロールが整っていることを実証しなければなりません。

構成制御動作中

典型的な開発プロジェクトでは、主要な武器システムのレベルで構成制御プロセスを必要としません。 チームに適切なレベルの柔軟性を与えながら、チェックとバランスのシステムが整っていることを保証することが重要です。 あらゆるシステムの鍵は、プロセスに必要な文書化とともに、プロセスを文書化するのに必要な努力です。 以下に説明するサンプルCCプロセスは、中小規模のアプリケーション開発プロジェクトの要件を満たすように設計されています。

プロジェクトチームはまず、プロジェクトに対する構成制御の適切な役割を分析する必要があります。 これは、少なくともソフトウェアプロジェクトでは、すべてのコードファイルを内部的に文書化するというテーマと、ある種の外部文書化を伴います。 カバーする追加の領域には、変更承認と変更文書プロセスが含まれます。 関係する参加者による単純なコンセンサスで十分です。 もちろん、定期的に招集された構造化されたボードが優れています。

それでは、単純な構成制御プロセスのさまざまな側面に入りましょう。

ドキュメント

構成管理計画(CMP)はCCプロセスを定義します。 ＣＣプロセスがかなり詳細であるいくつかのアプリケーションでは，構成制御計画（ＣＣＰ）が開発される。 いずれの場合も、構成制御を実行するためのすべてのプロセスと手順がカバーされます。

変更文書自体(後述)は、発信者からの追加情報を必要としないという点で自明な十分な情報を提供しなければなりません。 これは、変更が実装されるまでにオリジネーターが利用できない可能性があるために必要です。

プロセス

CCプロセスは簡単です（別紙1）。 個人はアイデアを持っているか、現在のシステムでエラーを見つけます。 この個人は、特定のプロジェクトのすべてのバグ、変更、または機能強化をログに記録するために使用されるフォームであるエンタープライズ変更要求（ECR） 変更要求は、レビューのためにピアとスーパーバイザにルーティングされ、承認されて実装されます。

別紙1-単純な構成制御プロセス

変更ドキュメント

変更を文書化することは、構成制御システムの最も重要な部分で 文書化の詳細は、文書化されている情報ほど重要ではありません。 ただし、文書化された情報には変更内容が記載されており、少なくとも以下の情報が含まれている必要があります。 文書化のための最小限の要件は次のとおりです:

もちろん、ドキュメントに含まれる情報が多ければ多いほど、再作成、回復、分析、修正が容易になります。 さらに、これはプロダクト配達のための最終的なドキュメンテーションを援助する。

個人が現在のプロジェクトでエラーまたは要件を発見した場合、必要な変更を文書化します。 変更要求には、要求に関する情報が含まれており、エラーを検出したシナリオ、検出したユーザー、検出した日時、および推奨される修正が記述されています。 また、要求では、可能であれば影響を受ける構成項目を識別し、承認された場合にこの変更がいつ発生するかを識別するために、何らかの重大度または優先度のコードを配置する必要があります。

変更承認

変更承認は、変更の影響に関する”全体像”ビューを持つ指定されたプロジェクト監督者からのものでなければなりません。 ピアレビューは、変更のすべての側面を検証し、変更の影響を受けるすべての領域に対処するための非常に効果的な手段です。 顧客に変更に同意させることは、機能強化に有益です。 しかし、小規模な開発プロジェクトでは、ほとんどの変更は”バグ修正”タイプであり、顧客は変更の影響を見ないでしょう。

データ収集

データ収集は、同様のアイテムの情報を回復し、傾向や傾向を発見する上で不可欠です。 この情報は電子的に存在する必要があり、データの簡単な回復とステータス会計とメトリックのデータ操作が可能になります。 この情報は、技術的改善のために組織全体に配布される”教訓”レポートをコンパイルするために使用することができます。

実装を変更します。

すべての適切な承認が得られると、実装のタスクが開始されます。 実装の各ステップでのテストは、プログラムの他の側面への影響が最小限であることを確認します。 すべてのテストが完了し、変更はプログラム全体に実装されます。

閉ループプロセス

変更元が最終製品に表示される前に変更の最終結果を知る閉ループプロセスは、成功のための重要な要素です。 これは、建設から製造、ソフトウェアに至るまで、あらゆる種類の産業に当てはまります。

この閉ループプロセスは、変更プロセスで異なる役割を持つ制御ボードを設定します（別紙2）。 各理事会は、憲章の完全な文脈における変更を検討し、各変更について決定的な決定を下す義務があります。 もちろん、理事会はその決定を下す前に追加情報を必要とするかもしれませんが、これは最小限に抑える必要があります。

構成管理研究所（ICMHQ）は、構成管理のためのCMII（CMIIU）の方法論を教えており、閉ループ変更プロセスのこのビューを開発しました。 このプロセスは、終了アイテムで開始および終了します。 構成変更の管理は、ループ内の3つの異なるレベルで表示されることに注意してください。 各領域は、異なる定義され、特定の役割と責任を持っています。

• 技術レビュー-すべての詳細評価と実現可能性分析が完了していることを確認します。
• 変更審査委員会(CRB)-変更のビジネスへの影響を評価します。 この変更は当社のビジネス環境に有効ですか？ それは私たちの戦略的目標の一つを満たしていますか？ それは私達の視野の声明に合うか。 承認された変更により、CRBは、競争力のある予測とビジネスリスクに応じて、変更の時間枠を示すことができるかどうかを示すことができます。
• 変更実施委員会(CIB)-必要な資金を配分し、変更実施時間枠を決定する。 これには、変更がいつ有効になるかを指定する変更の有効性の割り当ても含まれます。 有効性は、日付、ビルド、シリアル番号、またはロット番号に関連する可能性があります。 これは終了項目に依存します。

ループのファストトラックオプションは、CCのすべての痛みが解放され、所有者が数日対数分で承認された変更を得ることができる場所です。 もちろん、これの鍵は、各製品の適切なドキュメントツリーです。 各文書には、作成者とユーザーが割り当てられている必要があります。 変更が低レベルのドキュメントにのみ影響する場合は、Fast Trackが順調であり、変更はCCプロセスを通じて悲鳴を上げます。

概要

構成制御プロセスを成功させるための鍵は、プロジェクトチーム全体からのバイインです。 チームメンバーは、プロジェクトの要件を満たすように設計されていない管理インフラストラクチャのために、健全な判断と管理を放棄するように求め 構成制御プロセスは、障害のリスクを軽減し、成果物が時間と予算に確実に満たされるように設計されています。 プロジェクトチームが初期構成制御フレームワークの確立に参加すると、プロジェクトチーム全体の参加と受け入れが加速され、確立されたインフラストラクチャがビジネス目標をサポートします。