CMMIという切り口
「出荷後の不具合が多いので何とかしたい」、「変更要求が多すぎて納期に間に合わない」、「プロジェクトが混乱してどういう状態にあるのか誰もわからない」、「いつも手が付けられなくなってから報告がくる」・・・
ソフトウェア開発現場の開発者や管理者が抱える問題は様々で、プロセス改善を推進する担当者にとってはどこから手を着けたらよいのか頭の痛いところである。うまくやらないと、プロセス改善に賛成した現場開発者や管理者が、改善内容の各論になって「そんなことを改善したいのではない」と抵抗勢力に化けることもある。
改善を行う場合、まずは現状を把握し、その上で改善に取り組む必要があるが、この現状把握を網羅的に行うのがコツである。通常、改善を行いたい組織やプロジェクトはいくつも問題を抱えている。ひとつ解決すればすべて片が付く「銀の弾丸」的な解決方法はなく、１つ改善すれば別の問題が表面化してくるので、包括的に網羅的に問題を捉えることが必要になる。
この現状把握において、CMMIモデルをよく使っている。ご存知の方も多いと思うが、CMMIにはソフトウェア開発組織に必要なプロセス領域が体系的に定義してあり、組織の成熟度にあわせて達成すべきプロセス領域がガイドしてある。各プロセス領域に達成すべき事が記述されているので、それと現状を比較することでプロセス領域毎に実行できているか、できていないか診断することができる。問題を整理できるだけでなく、組織やプロジェクトで起きている問題をプロセス領域間の関連を考慮して論理立てて説明できるはずである。
ただし、多くの問題点を一度に解決するのは非常に現場の負担が高くなり、改善したいという気持ちと裏腹に抵抗感で改善が進みにくくなるので、即効性や投資対効果等を考慮しながら、優先順位を付けて改善計画を立て推進していくことが肝要だ。問題点が整理され、どのように改善していくかが可視化されるので、開発者の理解や、改善のための投資を行う管理者層の理解も得やすいはずだ。
このCMMIを切り口として問題点を可視化し改善を進めていく方法は、いかがだろうか。
（なお、少し宣伝になるが、昨今のように複雑化し開発規模が増大している組込みソフト開発においては、協調して開発を進めるメカ・エレキ部門等も含めた全体的な改善・改革活動が不可欠となるため、弊社では先駆けて、CMMIの要素も取り込み、製造組織全体を診断できるツールITID INDEXを用意している。）
ここまでお読みになりＣＭＭＩを切り口とした手法に興味をもたれた方に、少し現実的な話をする。 上記のCMMIを切り口として現状把握を行う手法は、やり方として正当で、かつ比較的実施は容易なので非常に魅力的に感じられたと思うが、その後の改善活動で少なからず乗り越えなければならない壁が存在することを忘れてはならない。
【プロセス開発・改善上の乗り越える壁】
・CMMIのプロセス領域を咀嚼せずそのまま使って改善しようとして痛い目にあっている組織は少なくない。CMMIにはWhat（何を）が記述してあるが、How（どのように）の記述はない。「空を飛ぶ」というWhatに対して、「空を飛べ」というHowでは改善にはならない。翼や早く飛ぶにはさらにエンジンも必要というHowを考えることが改善なのである。
・開発の規模、分野、範囲によって改善すべき優先順位も変わるのにひとつのプロセスしか無かったり、開発者のレベルを無視してプロセスを導入したり、改善が内向きで問題を作り出している外因には手が付けられていない等、プロセス改善が混乱を生む場合も少なくない。
【プロセス適用上の乗り越える壁】
・中間管理者が変化を恐れ抵抗する。上級の管理者が指示していても、中間の管理者が現場の開発者が反対しているからと理由をつけて断る。現場の開発者は何も聞かされてないこともあり、現場の開発者は現状が改善されるのであれば実はウェルカムなのである。
・プロセスだけあっても人は動かない。山本五十六の名言「やって見せ、言って聞かせて、させてみて、誉めてやらねば、人は動かじ」である。また、プロセスに従い進捗の遅れを管理し可視化はしているが、是正せず放置しまま問題に手を打たない管理もよく見られ、実践上の教育も不可欠である。
上記の例以外にも様々な壁が存在するが、最悪の場合、推進者が改善活動の中で敬遠され孤立し改革が頓挫するだけでなく、改善を敬遠する組織風土をつくりかねない。改善する以上は多少のハードルを乗り越える必要があり、乗り切る覚悟とパワーが必須である。改革・改善活動の初期に、改善推進者を支え、うまくガイドできる経験あるコンサルタントが必要とされる理由がここにある。
なお、上記の壁の話を読んで改善・改革に尻込みすることは全くない。
経験あるコンサルタントは弊社に限らず存在するし、CMMIのような体系的改善を実施して成功している企業はたくさんあるのだから。
さて、経済産業省から報告された「2007年版組込みソフトウェア産業実態調査の概要」によると、高品質の組込みソフトウェア開発ができる企業とそのような体制が構築できていない企業に二極化しているようだ（＊）が、読者の会社はどっちだろうか？
引用文献
（＊）経済産業省 ニュースリリース 2007．6．27 「2007年版組込みソフトウェア産業実態調査の概要」， 1頁
（2）組込みソフトウェア品質の二極化が拡大
製品出荷後の品質問題を起こした製品の比率は、この3年間で、「なし」が8％から30％へと増加し、高い品質の製品供給が急拡大しています。 その一方で、品質問題を発生している製品の比率が「30％以上」の企業も14％から27％と倍増しています。 このことは、高品質の組込みソフトウェア開発ができる企業が増加しているとともに、そのような体制が構築できていない企業も増加しており、組込みソフトウェアの信頼性という観点から見て企業の組込みソフトウェア開発能力が二極化していると考えられます。
執筆：高野 昌也
※コラムは執筆者の個人的見解であり、ITIDの公式見解を示すものではありません。
