メルマガ
バックナンバー

第62号:SEPG in San Jose レポート

2009年05月25日

  • SEPG in San Jose レポート

    先月に引き続き、SEPGカンファレンスの参加レポートをお送りします。
    私自身は2年ぶりの参加でして、4日間フルで参加するのは今回が初めてです。
    全部で20以上のセッションを見ることができたのですが、その中でも面白かった
    トピックをいくつかご紹介したいと思います。

    Guidance on Business and Project Goal Formulation in CMMI High Maturity Settings

    CMMIの高成熟度レベルに取り組む際には、ビジネスゴールや組織目標の達成に貢献するプロセスやサブプロセスを特定し、組織目標に紐づいたプロジェクト目標を確立するしくみを構築する必要があります。

    本チュートリアルは、先月のメルマガで紹介されていたビジネスゴールの記述方法以外に、組織のビジョンの策定や、ゴール達成に関連のあるプロセスやサブプロセスを可視化して、プロジェクト目標に紐付ける方法なども説明されましたので、それをご紹介します。これから高成熟度レベルに取り組んでいく人たちのご参考になれば幸いです。

    組織のビジョンから、プロジェクト目標にブレイクダウンしていくステップは以下のようになります。

    Step1:ビジョンを記述する
    組織は数年以内にどうなりたいのか、競合他社に対しどう優位に立つのか、顧客にどう見てもらいたいのか、等の組織のビジョンを確立します。
    例:○○年までに業界トップ10の会社になる
     
    Step2:ビジョン達成の障壁となる要素を特定する
    特定に使用可能な手法としては、以下のようなものがあります。
    ・特性要因図(フィッシュボーンダイアグラム)
    人、プロセス、環境、ツールや技術といった軸で分析
    ・SWOT分析
    機会、脅威、強み、弱みの要素で分析

    Step3:ビジネスゴールを明確にする
    目標は"SMART"に記述します。
    S(Specific)  表現が具体的か?
    M(Measureable) 第三者が測定可能な数値目標になっているか?
    A(Attainable) 現実的に達成可能か?
    R(Relevant)  やりたいことに対してきちんと貢献できる目標か?
    T(Timely or Time-bound) タイムリーか? 期限が決まっているか?

    Step4:Goal Decomposition Matrix(ゴール分解マトリクス)の作成
    キーとなるビジネスゴールや組織目標と関連の深いプロセスを探るのに、以下のようなマトリクスを使って分析できます。
    ┌────────┬─┬─┬─┬─┬─┬─┬─┐
    │プロセス\ゴール│G1│G2│G3│G4│G5│G6│G7│
    ├────────┼─┼─┼─┼─┼─┼─┼─┤
    │要件分析    │1*│ │ │ │ │ │ │
    │プロトタイプ  │ │X │ │ │ │ │ │
    │基本設計    │ │ │3 │ │ │X │ │
    │詳細設計    │ │ │X │ │ │ │ │
    │コーディング  │ │ │ │ │ │ │X │
    │単体テスト   │ │ │ │ │ │ │ │
    │統合テスト   │ │ │ │ │ │X │ │
    │システムテスト │X │ │ │X │ │ │ │
    │αテスト    │ │ │ │ │ │ │ │
    │βテスト    │ │2*│ │ │ │ │ │
    └────────┴─┴─┴─┴─┴─┴─┴─┘
    <ゴール分解マトリクスの作り方>
    1.横軸に、ビジネスゴールや組織目標を記入します。
    2.縦軸に、組織の中でキーとなるプロセスやサブプロセス、プロジェクトで実施される活動を記入します。
    3.各ゴールにもっとも貢献するプロセスのトップ2~3を特定し、X印をつけます。
    4.この中でどれをプロジェクトレベルに展開するかを特定します。展開するプロジェクト目標について、X印を番号にします。
    5.統計的管理を行うプロセスに*印をつけます。
     
    これで、ビジネスゴールからプロジェクト目標までブレイクダウンされました。

    説明がざっくりしているので分かりにくかったかもしれませんが、これから高成熟度レベルに取り組み始める人たちのヒントになれば幸いです。

    また、当チュートリアルは、以前SEIのWebinar上で行われたものをベースにしているようで、ほぼ同内容のスライドを以下のURLで見る事が出来ます。
    ご参考まで。
    http://tinyurl.com/qb9oqo

    Quantitative Performance Analysis in a Low Maturity Small Setting: Making the Business Case and Creating an Improvement Roadmap

    従業員25人以下の小規模な組織で、プロジェクトは場当たり的なプロセスを使用し、進行中の変更も多く、皆忙しくてプロセス改善を行う時間もない。このままじゃいけないので、なんらかの定量的な手法を使ってプロジェクトの状況や問題点を可視化して、今後の改善活動に結び付けたい。
    そんな組織に向いている方法を説明しているセッションです。

    以下のような方法を紹介していました。

    1.測定方法の設計:GQMアプローチの採用
    2.データ収集  :PSPで用いられるツールの使用
    3.分析、報告  :Excelのグラフより分析し、提案事項作成

    1) 測定方法の設計:GQMアプローチの採用
    最初のGQMアプローチでは、測定のゴールを定め、ゴールを達成するための質問を設定し、質問に答えるための尺度を設定します。このセッションでは、この質問=最終的に分析したい事項となっていました。

    ゴール(Goal):
    問題となっている領域およびコストがかかっている部分を特定する
    質問(Question):
    ・どのフェーズで時間がかかっているか?
    ・手戻りの主要な原因は何か?
    ・効果的な活動は行えているのか?
    尺度(Metrics):
    ・フェーズごとの工数
    ・欠陥タイプごとの手戻り工数
    ・フェーズごとの手戻り工数
    ・フェーズごとの欠陥修正にかけた工数
    ・基礎尺度:工数、フェーズ、欠陥タイプ、欠陥埋め込みフェーズ、
    欠陥除去フェーズ、修正時間

    2) データ収集:PSPで用いられるツールの使用
    データ収集では、PSPのツールであるタイムシートや欠陥ログを使用し、フェーズごとの工数や、欠陥タイプ、欠陥埋め込みフェーズ、欠陥除去フェーズ、修正に要した工数を記録していきます。
    ※PSP=Personal Software Process

    3) 分析、報告:Excelのグラフより分析し、提案事項作成
    収集したデータをExcelに落とし込み、
    ・欠陥タイプごとの手戻り工数、
    ・フェーズごとの欠陥修正にかけた工数
    ・フェーズごとの埋め込み&検出欠陥数および修正コストなどをグラフ化し、質問にあげている項目について分析を行っていました。

    自分たちのやり方のまずい点を定量的に把握して、今後のプロセス改善につなげるきっかけとしたり、測定分析プロセスの適用には有効な方法かと思います。

    Process Improvement and CMMI Maturity Level 3: In the Ultra-Small

    CMMIの成熟度レベル3を達成するには、最低何人くらいの組織なら可能なんだろうか、と考えた事はないでしょうか? 100人? 50人? それとも20人?このセッションでは、従業員12人というタイトル通りUltra-Smallな組織で成熟度レベル3を達成した事例を紹介していました。

    この組織はアリゾナ州の、とあるソフト会社で、12人の従業員はほぼ皆在宅勤、コミュニケーションのほとんどはメール、チャット、スカイプを駆使して行っているそうです。

    以下のような工夫が行われていたようです。

    1) プロセス構築のポイント
    ・最低限必要な作業成果物のみを生成するプロセスにする
    ・プロセスは、テンプレートやチェックリスト内に組み込み、プロジェクトはそれを適用する

    2) プロセスの構成
    ・4種類の組織方針
    品質方針、プロセス開発、トレーニング、エンジニアリング
    ・4種類のマニュアル
    プロセス管理用、プロジェクト管理用、エンジニアリング用、支援用CMMIをベースに、何(What)をすべきかを記述
    ・ハンドブック
    どのように(How)実施すべきかのガイド
    ・テンプレート、チェックリスト
    プロジェクトが使用し、実施記録となる。プロセス記述も含む。
     
    中身まで紹介されていたわけではないのですが、割としっかり作っている印象を受けました。
     
    3) プロジェクトの活動
    ・マイルストーンレビュー
    以下のタイミングで実施する。
    キックオフ(PK)、要件レビュー(SRR)、デザインレビュー(SDR)、統合開始前レビュー(IRR)、システムテスト開始前レビュー(STRR)、リリース前レビュー(RRR)、事後検討会
    顧客によるレビューも同時に行うこともある。
    SRR、SDR、IRRはゲートではないが、成功裏に完了させねばならない。
    STRR、RRRは納入前には成功裏に完了させねばならない。
    ・ピアレビュー
    ほとんどのエンジニアリング作業成果物に対して実施する。
    参加者リスト、レビュー状況、アクション項目、決定事項、チェックリストを記録として残す。
     
    マイルストーンをこのように決めてしまうのは良い手だと思います。
    小規模なプロジェクトだと、マイルストーンがどこかはっきりしないケースをよく見かけますが、組織のルールで決めてしまえば現場も迷わずにすみますし、アプレイザルの時も分かりやすいですね。
     
    4) アプレイザル実施の体制
    ・評定チームメンバは、評定ルールの最少人数である4名。
    LA、プロセスコンサルタント、GM(部長)、CTO(最高技術責任者)
    ・スポンサはQAリーダーが務める。

    小規模組織ゆえ、評定チームメンバ数や、参加者同士の利害関係がないように構成するのに苦労したようです。

    上記のようなことを実施すれば、小規模の組織でも成熟度レベル3の達成に近づけるかもしれません。