メルマガ
バックナンバー

第19号:CMMIのキーワード, 基準の話

2005年10月25日

  • 01CMMIのキーワード

    まいどですぅ。CMMやCMMIの理解をより深めていただくために、私CMMセミナー担当の西田理恵子が、プロセス改善活動家なら必ず押さえておきたい情報を簡単に説明していきます。

    では今月は、CMMIのキーワードについて。

    ●成熟度レベル

    より成熟したプロセスに到達するように、十分に定義された段階的なステップ。
    1から5までのレベルが定義されている。

    ●プロセス能力

    あるプロセスに従うことによって、達成が可能になると期待される結果の範囲のこと

    ●プロセス領域(PA)

    プロセス能力の確立に重要であると考えられるいくつかのゴールを達成する活動のまとまり。例えば、成熟度レベル2のPAとして、要件管理、プロジェクト計画策定、構成管理などがある。

    ●ゴール

    組織やプロジェクトがPAを効果的に実施しているかどうかを判断するために用いられるPAのプラクティスの要約。CMMIは下記の2種類のゴールがある。
    ・固有ゴール(SG)
    ・共通ゴール(GG)
    各PAにSGとGGがある。

    例えば、レベル2のPAのプロジェクト計画策定では、
     SG1:見積もりを確立する
     SG2:プロジェクト計画を策定する
    と記述されている。

    ●プラクティス

    あるPAの特定のゴールを達成するのに重要だと考えられる活動。各ゴールはいくつかのプラクティスを持つ。CMMIには下記の2種類のプラクティスがある。
    ・固有プラクティス(SP)
    ・共通プラクティス(GP)

    例えば、成熟度レベル2のPAのプロジェクト計画策定では上記のSG1に対して、SP1.1から1.4までの4つのプラクティスが関係付けられている。
     SP1.1:プロジェクトの範囲を見積もる
     SP1.2:作業成果物とタスクの属性の見積もりを確立する
     SP1.3:プロジェクトライフサイクルを定義する
     SP1.4:工数と費用の見積もりを決定する

    今月は以上です。
    では、さようなら。タン ビェット。

  • 02基準の話

    今回は基準の話をします。

    CMMIの多くのPracticeでは「基準」が求められています。
    モデルのあちこちに基準という言葉が見つかります。
    これらの基準についてどのように定義し、社内に浸透させるか頭を悩ましたり、アプレイザルの中での説明に四苦八苦したりした方も多いでしょう。(私もその一人ですが)
    CMMIが重たいモデルだと言われる一要因として、これらの基準の確立・維持が大変というのが挙げられると思います。

    どうやってこれらの基準の内容を定義したらよいでしょう?
    方法としては、組織の標準で基準の内容をガイドしたり、プロジェクトで独自に定義したりする事で対応することになるでしょう。

    今日はその中でも、見落としがちな基準についてご紹介しましょう。

    REQM SP1.1 要件の意味に関して要件提供者と共に理解する。

    このPracticeのSub Practice1,2で、以下の2つの基準が登場します。
    ・要件提供者を識別する基準
    ・要件の受け入れのための客観的な基準

    要件が増大しすぎるのを避けるために、誰が要件提供者になるかを識別しよう、不十分さや手戻りをふせぐために、どのような要件の場合に受け入れるのか決めよう、という事です。

    この基準の定義の確立を見落としていると、アプレイザルの時にちょっとコワイです。
    REQMは、モデルでも一番最初に出てくるプロセスエリアなので、アプレイザルの最初にチームレビューが行われる可能性があります。
    その場合、一番最初に説明する事になるのがこの基準なので、内容を担当ミニチームが説明できないと、ひょっとしたらしょっぱなでくじかれるかもしれません。

    PP SP2.1 プロジェクトの予算およびスケジュールを確立し維持する。

    このPracticeのSub Practice6でこのような基準があります。
    ・是正処置基準を確立する。

    何を持ってプロジェクト計画からの著しい逸脱と判別するかの基準です。
    PMC SG2で扱う課題管理の起点となる基準となりますので、これが曖昧だと、本当に課題として扱うものと単なるTodoリストもごっちゃになって必要以上に管理負荷が増大してしまうかもしれません。
     
    たとえば、"QCDに影響が発生したものを課題として取り扱う"と組織標準に記述しておく等が基準として考えられるでしょう。

    CM SP1.1 構成管理下に置かれる構成品目、構成要素、および関連する作業成果物を特定する。

    このPracticeのSub Practice1でこのような基準があります。
    ・構成品目を選択する基準

    なんでもかんでも構成アイテムとして対象にしてしまうと、必要以上に構成管理の負荷がかかってしまったりします。
    基準にもとづいて適切な成果物を構成アイテムとして特定しましょう。
     
    ガイドに基準の例が載っていますので、これを組織の基準としても良いでしょう。以下のようなものです。
    ・二つあるいはそれ以上のグループが使用するかもしれない作業成果物
    ・要件の誤りまたは要件の変更が原因で、時間の経過とともに変更されることが予想される作業成果物
    ・互いに依存し、一つが変更されると他が必ず変更されるような作業成果物
    ・プロジェクトにとって重要な作業成果物

    RSKM SP1.2 リスクを分析し分類するために使用されるパラメータ、およびリスク管理作業を制御するために使用されるパラメータを定義する。

    管理すべきさまざまなリスクを比較するための首尾一貫した共通の基準を提供するために、以下のリスクパラメータが使用される、とあります。

    ・リスクの可能性(リスク顕在化の確率)
    ・リスクの重大性(リスク顕在化の影響および重大度)
    ・管理活動のきっかけとなるしきい値

    リスク管理計画の中で、これらのパラメータの値を記述すると良いと思います。

    TS SP1.1 詳細な解の選択肢と選定基準を策定する。

    技術解はホント基準が多いプロセスエリアです。
    さっきまでの説明はサブプラクティスのものでしたが、ここではPracitceの表現に「基準」という言葉が出てきます。

    基準が見えないとアプレイザルでは致命的になりかねません。
    DARもそうですが、ここは選定の根拠となる明確な基準を文書化しましょう。

    TS SP2.3 確立され維持されている基準に基づいて、包括的な成果物構成要素インターフェースを設計する。

    ここではインターフェースの基準が求められています。
    内部・外部のインターフェースに関して、インターフェース設計の元となったルールなどが組織標準(またはプロジェクト定義プロセス)に定義されている必要があるでしょう。

    この基準がないと、段階表現の場合、レベルが1つ落ちます。気をつけましょう。