アセスメント事例

これまで、日本のメーカー数十社の組込型ソフトウェア開発プロジェクトに対して CMM アセスメントを実施した。以下に、その結果を紹介するとともに、共通に見られる傾向について解説する。

これまでアセスメントを実施した中にはレベル２を満足する組織は存在しなかった。成熟度レベル２というのは反復できる段階（Repeatable）と呼ばれる状態であり、ソフトウェア開発プロジェクトを基本的なしくみにしたがって進めることができる状態を意味する。ソフトウェア開発について話をするためのテーブルにつくことができるレベルといってもいいだろう。

しかし、アセスメントを実施した全ての組織において、このような基本的なレベルさえも達成していない。この結果に対して、評価方法が厳しすぎるという意見もあるかも知れない。しかし、これまでの経験からは、組込型ソフトウェアにおける開発プロセスレベルは確かに低いといわざるを得ない。メーカーの中でも、コンピュータ関連や交換機関連のソフトウェア開発は一般的に高いレベルの開発プロセスを持っていることが多かった。また、ＨＰやアジレントなどの米国メーカーも高い開発プロセスを持っていることが多い。これらの組織に較べると、日本の組込型ソフトウェアの開発プロセスは見劣りするのは確かである。多くの組織である程度のしくみは存在しているが、レベル２を満足するような取り組みを総合的に実施できているところは非常に少ない。

それでは、以下に成熟度レベル２（反復できる段階；Repeatable）と成熟度レベル３（定義された段階；Defined）それぞれについての詳細なアセスメント結果を紹介する。

レベル２（反復できる段階；Repeatable）と評価されるためには、次の六つの KPA (Key Process Area) を満たす必要がある。

• 要件管理（Requirements Management）
• ソフトウェアプロジェクト計画（Software Project Planning）
• ソフトウェア進捗管理（Software Project Tracking and Oversight）
• ソフトウェア外注管理（Software Subcontract Management）
• ソフトウェア品質保証（Software Quality Assurance）
• ソフトウェア構成管理（Software Configuration Management）

アジレントが実施しているアセスメントでは、各 KPA を最低点の１から最高点の５までの五段階で評価している。そして、４以上でその KPA を満足していると判断している。５はその KPA の実現形態としてベストプラクティス・レベルであること、３以下はその KPA を満足するための要素が欠如しているという評価である。１から３は欠如の度合いをあらわす。図（アセスメントサマリー　レベル２）には、レベル２の各 KPA ごとにアセスメントの最高点と最低点、そして、平均点を示している。

グラフから、ソフトウェア進捗管理の最高点が３にとどまっており、そのためにレベル２を満たす組織が存在しないことがわかる。平均点もソフトウェア進捗管理が一番低い。その他に ソフトウェアプロジェクト管理と要件管理の平均点が低い。以下では、このような評価となった原因を分析する。

ほとんどの組織で、進捗管理に定量的指標が使われていないことが、ソフトウェア進捗管理の評価が低い原因である。CMM のソフトウェア進捗管理で要求しているのは、計画と実績との差分を計測しその差が大きくなった時点で是正措置をとるしくみである。さらに、計画と実績との差は、単にスケジュール表（線表）上での遅れ把握ではなく、データ（たとえば、開発工数や規模などの基本指標）を使って把握することが要求されている。アセスメントを実施した中にはこれらの条件を満たす組織は存在しなかった。開発工数や規模などのデータを取っている組織であっても、データはプロジェクト終了後の評価やレポートに使っているだけで、進捗管理に使っているところはなかった。筆者は、データによる進捗管理ができていない原因を次のように考えている。

これまでの組込型ソフトウェア開発スタイル、つまり、個人を主体とした開発スタイルでは、中心となる技術者に全てを任せていれば大きな問題はなく、進捗管理におけるマネジャーの主業務は、スケジュール（線表）通りに進んでいるかどうかの確認だけだった。そのため、工数やプログラムサイズなどの基本的なデータですら、収集し進捗管理に使う必要性を感じていなかったのである。しかし、ソフトウェアが大規模化し、納期遅れ、品質低下、工数増大といった問題が起きている状況で、従来の進捗管理スタイルでは無理があることは明白である。しかし、私たちが目にするのは、従来通り線表通りに進んでいるかどうかだけを神経質に確認しているマネジャーの姿である。彼らは自分の進捗管理の方法に疑問を感じながらも、線表を使った進捗把握以上のことを思いつかず成功体験もないため、どうすればいいのかわからずに悩んでいる。

ソフトウェアプロジェクト計画、要求管理も評価が低いが、これらが十分でないことも、進捗管理ができていないことの原因になっている。適切な見積もりによる適切な開発計画がなければ、適切な進捗管理はできないからである。

進捗管理のレファレンスとなるのは事前に作成される開発計画であり、開発計画を立てるためには適切な見積もりが必要である。しかしながら、多くの組込型ソフトウェア開発の現場での見積もりは完全に個人的な経験や感覚に基づいたものであり、その妥当性や正当性を他人にロジカルに説明することができない。したがって、見積もり精度を向上させるための議論もできない。見積もりや予測というとエンジニアリング的な感じがする言葉だが、このような現状に合っているのは。もっと感覚的な感じのする「予想」という言葉ではないだろうか。

適切な開発計画が作れていない現実は、開発現場に深刻な問題を引き起こしている。それは、マネジャーと技術者との間の相互不信である。技術者は個人的な「予想」をもとに開発計画を立ててはみるものの、度重なる開発遅れのため、マネジャーは技術者に対して不信感を持ってしまう。そして、そのようなマネジャーの姿勢に技術者は見積もり方法の改善や適切なスケジュール立案に対する意欲を失ってしまう。このような組織は数多く存在している。相互に信頼関係が築けていなければ、改善ができるはずない。

また、適切な見積もりが実施できない原因には要求管理のレベルが低いことも関係している。適切な製品仕様や企画がなければ開発作業のブレークダウンはできない。したがって、このような状況では開発作業を見積もり、計画を立てることはできない。

多くのソフトウェア開発組織における製品仕様の問題は、与えられた期間やリソース（人，費用，技術など）で、文書化された仕様を実現することができるかどうかの検討が実施されないことである。ユーザや営業サイドからの要求や、トップマネジメントの要望を文書としてまとめただけで、実現妥当性を検証した開発のための製品仕様にはなっていないのである。このような仕様をもとに開発計画を立てること自体ナンセンスである。

レベル３（定義された段階；Defined）と評価されるためには、次の七つの KPA を満たす必要がある。

• 組織プロセス重視（Organizatoin Process Focus）
• 組織プロセス定義（Organization Process Definition）
• トレーニングプログラム（Training Program）
• ソフトウェア統合管理（Integrated Software Management）
• ソフトウェアプロダクトエンジニアリング（Software Product Engineering）
• グループ間調整（Intergroup Coordination）
• ビアレビュー（Peer Reviews）

レベル２を満足している組織が存在しないため当然ともいえるが、図（アセスメントサマリー レベル３）に示すように、レベル３での評価は KPA 全般に低い。特に弱いのは、ソフトウェア統合管理、組織プロセス重視、トレーニングプログラムの三つの KPA である。以下にその原因について解説する。

CMM でのソフトウェア統合管理は、組織として標準的な開発プロセスを確立した上で、プロジェクト固有の事情に合わせて開発プロセスを生成することができるしくみを要求している。これが低い理由は、開発規定や開発プロセスマニュアルといった形で開発プロセスが文書化されている組織であっても、開発の現場で規定された開発プロセスが遵守されておらず、ほこりをかぶった状態となっているケースが非常に多いからである。つまり、現実のプロジェクトで使える開発プロセスにはなっていないのである。この最大の原因は、現状の開発プロセスが以下に示すような組込型のソフトウェア開発の特性を考慮したものになっていないからである。

組込型ソフトウェア開発においては、新製品開発といっても既存製品の流用率が非常に高い。図（流用率によるプロジェクト分布）はコンサルティングを通じて収集した流用率の実態である。ここでの流用率は、製品全体のプログラム量に対して既存製品のプログラムをそのままの形で使っている量である。図の横軸は流用率を高い方からの逆順にしている。折れ線グラフはプロジェクト数の累計だが、流用率 70 % 以上のプロジェクトが全体の半数近くもあることがわかる。多くのマネジャーは流用率が高いという、このような現実を認識していない。このため、開発規定や開発ガイドラインといった現状の開発プロセスは、全く新規に開発することを想定した内容となっており実状には合っていない。これでは開発規定やガイドラインを遵守しろという方が無理がある。流用することを前提とした開発プロセスが必要なのである。

次に、組織プロセス重視が低い原因について考えたい。これは、本書全体で述べていることでもあるが、開発におけるプロセスの重要性が認知されていないことだと考えられる。技術力や個人の技術スキルばかりを優先し、組織としてのしくみ作りは片手間にしか実施していないのである。個々のプロジェクトで独自にルール作りをしたり、タスクフォースと称して無理して空けた中途半端な時間を使って品質保証活動を実施したり、マネジャーが個人的にガイドラインを作成したり、というようなレベルでしか開発プロセス整備に取り組んでいない。