第102号：プロセス改善ストーリー：ある新米SEPGの1日(CMの問題点を検討する)

プロセス改善ストーリーの第９回です。
CMMIを使ったプロセス改善活動で悩むポイントなどを、初心者向け解説本でよく見かける会話形式の文章で解説していきます。

＜登場人物＞　　()は会話文中の省略形
　野比(野)：改善グループのメンバ。新米SEPG。
　土良(土)：CMMIコンサルタント。改善グループの相談に乗っている。

今回の改善グループの会議では、構成管理での問題点について話し合っているようです。

野「土良さん、先日組織内のあるプロジェクトで問題があって大変なことになっているんですよ」

土「ほう、何があったのですか？」

野「先日、お客様に納品したプログラムの一部に変更要件が反映されていなかったことが発覚しまして、それも実は今回が初めてではなくて、同じお客様の案件で過去に何度も発生していたようなんです。それでお客様がとうとう怒り出してしまいまして・・・。今、プロジェクトメンバはお客様への説明や、修正版のリリースに向けて対応に追わてている次第です」
　　
土「そうですか。まずはトラブルの収束に向けて動くことが大事ですね。後は、こういったトラブルが再発しないように、原因分析をして改善していくことが重要ですね」

野「はい、それでいろいろ調べてみると、どうやら納品前の総合テスト中の修正で、同じファイルを複数の人が同時に編集してしまって、デグレードが起こってしまったことが原因のようなんです。
まとめると、以下のような問題が確認できました。
　　
1.同じファイルに対し、複数の修正担当者がアサインされてしまった
2.修正結果の検証担当が割り当てられておらず、変更が不十分な状態の作業成果物が、ライブラリに格納された
3.納品前に、納品対象が正しいかのチェックが行われていなかった
　　
これって、構成管理がちゃんと行われていなかったことが原因ですよね？」

土「どうやらそのようですね。
CMMIの構成管理プロセス領域には、『SP2.2 構成品目に対する変更を制御する』というプラクティスがあります。
変更を行う際には、適切な変更制御ルールに基いて変更を実施し、ベースラインが完全な状態となっていることを維持しましょう、というものです。
変更開始前に変更の認可を得てチェックアウトし、修正完了後にレビューやテストなどの検証を得て、ベースラインを更新するといった活動を実施します。
今回の問題点の1、2は、このSP2.2の構成品目の制御がうまくいってなかったようですね」

野「そうですね。修正担当者や検証担当者割り当てのルールは見直しが必要なようです」

土「それから、問題点3の納品前のチェックがなされていなかった件は、『SP3.2構成ベースラインの一貫性を維持するため、構成監査を実施する』のプラクティスが関係しそうです。
御社では、構成監査にあたる活動はもう実施されていますか？」

野「構成監査の実装は何か難しそうで、後回しにしていたんですよね。具体的にどんなことをしていいか分からなくて・・」

土「構成監査は、CMMIモデルでは『結果として得られたベースラインおよび文書が、指定された標準または要件に適合していることを確認する』活動と説明されています。
　　
具体的には、作成したベースラインに含まれる構成品目、すなわち実行モジュールやドキュメントが、決められたルール通り作成されているのか、すべての変更が反映済みとなっているか、対象のモジュールが揃っているのかといったことを確認します。
　　
少なくとも、納品前に一手間かけてこれらのチェックを行っていれば、今回のような問題の発生は最終段階で防げていたのではないでしょうか？」

野「なるほど、わかりました。まずは納品前のチェックで構成監査を行なっていくことを考えたいと思います」