第44号：CMMI for Acquisition Version 1.2 出ました。

2007/10/31～11/2の３日間で行われたSPI Japan 2007に参加してきました。
SPI Japanは、日本SPIコンソーシアム主催のSPI(ソフトウェアプロセス改善)のカンファレンスです。SPIに関する事例発表、情報共有の場として年１回行われています。

今回は私が参加したセッションや感じたことなどをレポートしてみたいと思います。

今年は、富山県の富山国際会議場にての開催でした。開催地が東京から結構離れ場所になったため、参加者が少ないだろうとの予想もあったようですが、300名という非常に多くの方々が参加されていました。当メルマガ読者の方で参加されてた方もいらっしゃるかと思います。

カンファレンスは、１、２日目に基調講演と各セッション、３日目にパネルディスカッションとチュートリアルという構成で行われました。セッションは２日間で４０もあります。全部見たかったのですが、同時に３セッションが行われるので、残念ながらどれか１つに絞らねばなりません。そんなジレンマと戦いながら参加しました。

全体的には、どうやって組織全体を見えるようにするかの「見える化」や、現場が主体的に改善を実施する「ボトムアップ型の改善」などのセッションが印象に残りました。一通りCMMIやISOなどのモデルベースでの取り組みが一段落し、さらなる浸透を目指してる企業が増えてるということかもしれませんね。

では気になったいくつかのセッションをご紹介します。

CMMIの「測定と分析(MA)」のプロセス領域を満たすために、無理矢理メトリクスを決めて、現場に測定を強いた結果、そのうち誰もやらなくなって形骸化してしまった、そんな経験ありませんか？

このセッションでは、現場における課題に対して、現場で改善を行ない、メトリクスを使って改善の効果を実感していく、という当たり前のようでなかなか出来ない事を、事例を交えて紹介していました。

やり方はこんな感じです。
ある改善課題が発生したら、
　0) 課題を課題一覧(Excel上の一覧)に記入し、
　1) 原因を推測(現状と理想のギャップより判断)し、
　2) 測定尺度(どんなメトリクスを使えば推測が確認出来るか)を決めて、課題一覧の列に追加し、
　3) 分析(測定分析し、推測の結果を確認)し、
　4) 改善策(現実的ですぐ出来る事)を決め、
　5) 改善を実施し、
　6) 結果を確認(効果の実感)する。

事例として以下が紹介されていました。
「バグ対応工数削減」という課題に対して、
・開発者から現状をヒアリング
・原因を推測
・バグ対応工数、対応件数を測定して推測結果を分析
・バグ対応のフェーズ化、熟練者の手順の文書化、ホワイトボードによる対応状況の見える化などの実現が容易ですぐ出来る改善を実施
・その結果、バグ対応時間が削減され、開発者に効果を実感してもらい、改善意識の向上につなげられた。

プロジェクトや改善チーム内でもよく課題一覧を使いますが、この方法の違いは改善の効果を推測し結果を確認するためのメトリクスを設けている事です。これを使って測定・実施・結果確認することで、効果が可視化され、現場での手ごたえをつかむことに役立っているのだと思います。

SNS(ソーシャルネットワーキングサービス)が世間で認知され始めて結構たちます。最大手のミクシィの会員は 1190万人もいるそうですね。読者の中にも利用者はいらっしゃるのではないでしょうか？　このセッションは、そんな SNS をSPI に活用してみよう、というものです。

SPI活動の活性化および情報共有の場として、「オフライン」の集会と「オンライン」の社内SNS上のコミュニティの２種類を活用するという事例が紹介されていました。

集会では、事例発表や課題に対するディスカッションなどを行います。SNS上ののコミュニティの方では、SNSの特徴であるトピックに対するディスカッションを行ったり、集会の活動状況を公開する場として利用します。

オフラインとオンラインの両方を活用する事で、それぞれの弱点をもう片方が補完する事で相乗効果を生み、参加者のモチベーションアップや情報共有、人脈を広げる事に役立っているという点が非常に興味深かったです。
例えばこんな感じです。
・集会では時間と場所の制約があり、やむなく出席出来ない事もある
　→SNS上のトピックで続きを議論
・活動結果の公開範囲が限られる
　→SNS上で活動結果を公開し、全社に見える化
・集会で新規メンバが参入しにくい
　→SNSで新規メンバを募集
　　SNS上で知り合ってから集会に参加
・SNSは文字情報だけなので想いが伝わりにくい
　→集会で顔をつき合わせて深い議論をする

「ウチの組織は部門間に壁がある」「隣の人は何する人ぞ」「よその部門の事例を知りたい」という組織には、結構効果があるのではないでしょうか？

派生開発という言葉を聞いた事がありますか？　既存システムのソースコードがあり、機能追加・変更などを行い、新バージョンのソフトウェア製品として開発する形態のことを言います。

派生開発では、一般的に部分理解の中で短期間での開発を強いられ、思い込みや勘違いによる間違った対応を行ってしまい、生産性の低下、バグの頻発をまねくということになりがちです。その原因は、実施しているプロセスが派生開発用のプロセスになっていないからということだそうです。

当チュートリアルは、清水氏が考案したXDDPという派生開発用のプロセスを解説したものです。昨年のSPI Japanで、その原型であるUSDMという「要件を仕様化する技術」が紹介され、私はそれを受講してましたので、続編である今回のチュートリアルを非常に楽しみにしていました。

XDDPでは、次の３つのドキュメントを必須としています。
　1) 変更要求仕様書
　2) トレーサビリティマトリクス(TM)
　3) 変更設計書

1)は、USDMの技法を使い、変更要求、理由、変更仕様を記述します。
　変更が及ぶ範囲を明確にするために、変更要求を記述します。
　変更要求を適切に分割・階層化します。
　変更要求はbefore・afterで表現します。
　変更要求の適切性判断の支援のために、理由を記述します。
　変更仕様を、変更要求の下に記述します。
3)に、具体的なモジュールレベルでの変更方法を記述します。
2)は、1)と3)をつなぐ文書として作成します。
　縦軸に変更仕様、横軸に変更するモジュールを並べ、その交点に対応する変更設計書を割り当てます。TMを作成する事で、変更箇所を確認するのが容易になり、不整合にも気づきやすくなります。

1)2)3)をレビューしたら、後は一気にソースコードを変更します。
最後に、関連する公式文書(設計書等)を更新します。

清水氏は100余りのプロジェクトをこの方法で成功させているそうです。

この方法は、CMMIの要件開発(RD)や要件管理(REQM)、構成管理(CM)と非常に相性が良さそうなんですよね。CMMIに取り組まれている皆さんの会社でも、多くの場合、新規開発をベースに標準プロセスを構築されているのではないでしょうか？
派生開発で問題が起こっている場合は、次なる改善でこのXDDPも一つ参考になさってみてはいかがでしょうか？

さらに詳しく知りたい方は、こちらの書籍を参考になさって下さい。
『「派生開発」を成功させるプロセス改善の技術と極意』
http://tinyurl.com/22c6mp
『要求を仕様化する技術・表現する技術 -入門＋実践 仕様が書けていますか?』
http://tinyurl.com/29z92t
　　出版社： 技術評論社

いかがでしたでしょうか？　ご紹介させて頂いたのはプログラムのほんの一部です。日本SPIコンソーシアムのHPで、これまでのプログラムや予稿集などが公開されていますので、こちらも参考になさって下さい。今回の予稿集も直に公開されるかと思います。来年は関西開催のようですので、興味のある方は是非参加してみてはいかがでしょうか。

　日本SPIコンソーシアム
　http://www.jaspic.jp/

おかげ様で、今回も非常にたくさんのヒントを得る事が出来ました。カンファレンスの開催にご尽力頂いたスタッフの皆様、当メルマガでご紹介させて頂いた皆様、および貴重な事例やアイディアを発表頂いた全ての皆様に感謝いたします。

CMMI for Acquisition Version 1.2 が出ました。
少しだけご紹介します。CMMI for Acquisition は、下記のように22のプロセス領域で構成されます。

┌──────────────────────┬──────┬────┐
│Process Area　　　　　　　　　　　　　　　　│Category　　│Maturity│
│　　　　　　　　　　　　　　　　　　　　　　│　　　　　　│Level 　│
├──────────────────────┼──────┼────┤
│Agreement Management (AM) 　　　　　　　　　│Acquisition │　 ２ 　│
├──────────────────────┼──────┼────┤
│Acquisition Requirements Development (ARD)　│Acquisition │　 ２ 　│
├──────────────────────┼──────┼────┤
│Acquisition Technical Management (ATM)　　　│Acquisition │　 ３ 　│
├──────────────────────┼──────┼────┤
│Acquisition Validation (AVAL) 　　　　　　　│Acquisition │　 ３ 　│
├──────────────────────┼──────┼────┤
│Acquisition Verification (AVER) 　　　　　　│Acquisition │　 ３ 　│
├──────────────────────┼──────┼────┤
│Causal Analysis and Resolution (CAR)　　　　│Support 　　│　 ５ 　│
├──────────────────────┼──────┼────┤
│Configuration Management (CM) 　　　　　　　│Support 　　│　 ２ 　│
├──────────────────────┼──────┼────┤
│Decision Analysis and Resolution (DAR)　　　│Support 　　│　 ３ 　│
├──────────────────────┼──────┼────┤
│Integrated Project Management (IPM) 　　　　│Project 　　│　 ３ 　│
│　　　　　　　　　　　　　　　　　　　　　　│Management　│　　　　│
├──────────────────────┼──────┼────┤
│Measurement and Analysis (MA) 　　　　　　　│Support 　　│　 ２ 　│
├──────────────────────┼──────┼────┤
│Organizational Innovation and Deployment　　│Process 　　│　 ５ 　│
│(OID) 　　　　　　　　　　　　　　　　　　　│Management　│　　　　│
├──────────────────────┼──────┼────┤
│Organizational Process Definition (OPD) 　　│Process 　　│　 ３ 　│
│　　　　　　　　　　　　　　　　　　　　　　│Management　│　　　　│
├──────────────────────┼──────┼────┤
│Organizational Process Focus (OPF)　　　　　│Process 　　│　 ３ 　│
│　　　　　　　　　　　　　　　　　　　　　　│Management　│　　　　│
├──────────────────────┼──────┼────┤
│Organizational Process Performance (OPP)　　│Process 　　│　 ４ 　│
│　　　　　　　　　　　　　　　　　　　　　　│Management　│　　　　│
├──────────────────────┼──────┼────┤
│Organizational Training (OT)　　　　　　　　│Process 　　│　 ３ 　│
│　　　　　　　　　　　　　　　　　　　　　　│Management　│　　　　│
├──────────────────────┼──────┼────┤
│Project Monitoring and Control (PMC)　　　　│Project 　　│　 ２ 　│
│　　　　　　　　　　　　　　　　　　　　　　│Management　│　　　　│
├──────────────────────┼──────┼────┤
│Project Planning (PP) 　　　　　　　　　　　│Project 　　│　 ２ 　│
│　　　　　　　　　　　　　　　　　　　　　　│Management　│　　　　│
├──────────────────────┼──────┼────┤
│Process and Product Quality Assurance (PPQA)│Support 　　│　 ２ 　│
├──────────────────────┼──────┼────┤
│Quantitative Project Management (QPM) 　　　│Project 　　│　 ４ 　│
│　　　　　　　　　　　　　　　　　　　　　　│Management　│　　　　│
├──────────────────────┼──────┼────┤
│Requirements Management (REQM)　　　　　　　│Project 　　│　 ２ 　│
│　　　　　　　　　　　　　　　　　　　　　　│Management　│　　　　│
├──────────────────────┼──────┼────┤
│Risk Management (RSKM)　　　　　　　　　　　│Project 　　│　 ３ 　│
│　　　　　　　　　　　　　　　　　　　　　　│Management　│　　　　│
├──────────────────────┼──────┼────┤
│Solicitation and Supplier Agreement 　　　　│Acquisition │　 ２ 　│
│Development (SSAD)　　　　　　　　　　　　　│　　　　　　│　　　　│
└──────────────────────┴──────┴────┘

より詳しい情報は下記のURLをご覧ください。
http://www.sei.cmu.edu/about/press/CMMI-ACQ/index.html
http://www.sei.cmu.edu/cmmi/models/ACQ-v12-announce.html
http://www.sei.cmu.edu/publications/documents/07.reports/07tr017.html