この記事は，「日経エレクトロニクス」と「日経バイト」が刊行した別冊『組み込みソフトウエア2006---品質管理と開発技法の実践的改革A to Z』の掲載記事を抜粋したものです。別冊の詳細はこちら。
それではソフトウエアの品質向上のための取り組みの基本について，いくつかを簡単に解説していこう。まずは，プロジェクト・マネジメントである。組み込みソフトウエア開発では，ソフトウエアのマネジメントだけでなく，機械系や電気系の部隊との調整や連携，同期が必要となる。
プロジェクト・マネジメントを行う上で，「PMBOK（project management body of knowledge）」に記載されている内容は基本知識である（図3）。とはいえ組み込みソフトウエア開発の現場では，突然起こった大規模化の波に対応できるプロジェクト・マネージャはそれ程多くはないため，実際にはPMBOKを読みこなすだけで精一杯という組織もあるだろう。特に，組み込みソフトウエア開発では，機械系や電気系などのハードウエアとの関わりが多いため，放っておくとどうしてもそれら他の組織のしわ寄せが来てしまう。
図3 PMBOK程度のことは基本知識
プロジェクト・マネジメントにおいては，PMBOKで扱っている程度の知識は基本として把握しておく必要がある。
このため組み込みソフトウエアのプロジェクト・マネジメントでは，ハードウエア部隊といかに協調していくか，製品全体のマネジャーにソフトウエアの重要性をいかに理解してもらうかが，大事な作業になる。例えば，組み込みソフトウエア管理者・技術者育成研究会（SESSAME）では，「ハードウエア出身のマネージャに分かっておいてほしい7つのこと」という文書を作成し，公開しているほどである注1）。規模にもよるが，スマートな組織は上意下達のプロジェクト体制というよりも，互いの意図を伝え合い，先を読むことで，組織同士の連携を円滑にする分権型の体制を構築している。
「PMBOKを読んでおけ」だけでは不十分
次に重要なのが，リスクの把握である。過去の事例を整理して蓄積し，自組織のマネジメント上の弱点を改善していく。単にリスクを予測して手を打つことだけでなく，リスク・マネジメントそのものを改善していく必要もある。その際に，リスクの兆候となる出来事をどれだけ社内から集めてこられるかがポイントとなる。
得られた兆候を整理したら，どのようなリスクが発生するか，それがどのような損失につながるかをメカニズムとして把握する。そして費用対効果の高い対策をタイミング良く講じていく。単に，リスク表を準備してPMBOKを読んでおけという体制では，有効なリスク・マネジメントは期待できない。
さらにプロジェクト・マネジメントでは，組織内のエンジニアのモチベーションに気を配ることも重要である。筆者はコンサルティングを行う際，まず現場に行って，現場のエンジニアのモチベーションを観察することにしている。エンジニアと飲みに行かないと聞けないこともあるが，「もう本当にいやになる」という言葉が聞かれる組織は大抵，納期は遅れがちで品質も悪い。逆に「もっと改善したい」という言葉が出てくる企業は，実はその時点で既に品質が良いことが多い。
モデルに頼らなくても改善はできる
次に，プロセス改善について述べよう。プロセス改善は，何もCMM（capability maturity model）などを使わなくとも，いくらでも取り組める。日々の仕事をどのように改善していくかが，プロセス改善の本質だからだ。よくあるのが，プロセス改善のことを標準化だと誤解しているケースである。何かマニュアルのようなものを作成したり，標準プロセスを作ってそれを展開したりすればいいのだと誤解していることが多い。こうした組織では，改善活動そのものが硬直化・重量化してしまう。
もう少し高い段階，CMMでいえばレベル4～5の組織の場合には別のことが起きる。メトリクスを計測しても品質改善に結びつかず，コストばかり高まってしまい，現場に定着しないという問題だ。
メトリクスの計測が目的ではない
「取れるメトリクスはすべて取り，後で統計分析などを行って改善ポイントを見つけるのがよい」という話を聞くことがあるが，経験上これはあまり上手くいかない。本来，プロセス改善とは，問題点は何なのかを把握した上で，自分たちがどういう改善をしていくのかを考える活動である。
多くの現場は，メトリクスを計測しなくても，日々の業務のムダや製品の悪さを感じ取っているものだ。そのことに思い至らず，ただやみくもにメトリクスを計測して統計分析を行うくらいなら，現場が感じているムダや悪さの情報を集め，そのムダをメトリクスでどう表現するかを考えた方がよい。大事なことは，メトリクスを検討し計測する過程で，日々の業務のムダや製品の悪さを敏感に感じ取る能力を鍛えることである。そうすれば，メトリクスの計測が品質の改善につながっていくことだろう。
プロセス改善の理想は，顕在化した問題点を改善することにあるのではなく，問題点が顕在化する前に防止することにある。そのためには，問題の根本原因やメカニズムを「なぜなぜ分析」などで把握することが必要となる。
手戻りが1割以下の組織では，こうした施策が既に打たれているはずだ。改善活動そのものの改善も手がけているだろう。CMMのレベルというのは，こうした改善活動を継続的に進めていける組織になるためのステップである。従って，レベル3を目標にしてもあまり意味はない。自律的に改善活動を続けていけるレベル5になって初めて，真の効果が得られるのである。
まずは自社の品質マネジメント・システムを見直せ
組み込みソフトウエアを開発する多くの企業では，TQMやシックス・シグマなどハードウエア部門で何らかの改善活動を手掛けていることだろう。CMMの導入だと騒ぐ前に，まずはそうした自社組織の品質マネジメント・システム（QMS）を見直してみることをお勧めする。
全社で導入しているQMSを，自分達のソフトウエア開発に適用するとどうなるか。それをしっかり考え抜いた上で， 改めてCMMに取り組む方が得策だ。結局，世の中でいろいろなモデルが提唱されてはいるものの，本質はみな同じであるからだ。
