~ソフトウェア品質の向上とそこに関わるすべての方へ~ Software Quality Profession

ライフサイクルにおけるプロセス評価と改善からSQuBOK® を読み解く 第4回

株式会社日立システムアンドサービス シニアコンサルタント
古賀 惠子
日本ユニシス株式会社 品質保証部
大川 鉄太郎
プロムス 代表
河合 一夫

第4回の内容

 連載4回目は,「ライフサイクルにおけるプロセス評価と改善」です.ソフトウェアライフサイクルにおけるプロセス評価と改善はどのような目的でどう行われるのか,ソフトウェアの品質を考える上でどのような意味を持つのかなどを,古河課長と熊川さん[第1回「本連載の進め方」]に語って貰います.

ソフトウェアプロセスアセスメントとは

 熊川さんは,課長に呼ばれて次の調査を命じられました.
 「Y取締役が,『わが社のソフトウェアライフサイクルプロセスが,標準に概ね整合していることはよく分かった.しかしプロセスが規定されているだけでは絵に描いた餅だ.日々の仕事がプロセスどおりに行われ,期待される成果を上げているのか,継続的な改善を進めているのか,についても知りたい.』とおっしゃっている.熊川君,社内のプロセス評価と改善の現状を至急調査して改修すべき点があれば報告してくれ.」
 熊川さんは,どう手をつけてよいか分からなかったので古河課長に聞きました.「課長,この仕事にどう取り組んだらよいか分かりません.私の今の知識と経験では手に負えそうにないのですが・・・.」古河課長は「一人で抱え込んだまま時間を無為に過ごしてしまわなくなったのは良いことだ.これは大きなテーマなので,少し長くなるが詳しく説明するからよく聞いてくれ.」と言って説明を始めました.
 「ソフトウェアプロセスを評価する目的は,現状を体系的に把握して改善を進めることにある.そして結果として製品品質や開発効率を向上させるためだ.そのきっかけはざっくりいって2つある.一つは,実際に発生した品質問題を引き起こした根本原因を究明し,再発防止策を立案する過程でソフトウェアプロセスを評価する.もう一つは,ベストプラクティスの体系に照らしてプロセスを評価して,足りない部分を改善していく場合だ.この両方をバランスよく実施していくことが必要だ.」古河課長は本論に入って行きます.
 「プロセス評価については,SQuBOK®の「2.3 プロセスアセスメント・プロセス改善のマネジメント」の記述と参考文献を参照すると全体のイメージがつかめる.また体系的なプロセス評価については,歴史的な背景を少し知っておくとよいだろう.(コラム参照)
 代表的なプロセス評価モデルであるCMMIとISO/IEC15504には大きな違いがある.CMMIはソフトウェアのベストプラクティスで構成されるアセスメントモデルであり,業種固有の要件などを取り込むカスタマイズは認めていない.15504はそれ自体がアセスメントモデルではなく,アセスメントモデルとアセスメントを規定するメタモデルだ.その要件を満たせば自由に固有の要件を取り込んでいくことが可能なため,業界や業種ごとのアセスメントモデルが次々に開発されてきている.」
 熊川さんはすぐに疑問が浮かんできました.「CMMIやISO/IEC 15504と,先日伺った『ISO/IEC 12207(JIS X 0160)ソフトウェアライフサイクルプロセス』や,これを下敷きにして日本独自に作成したモデルである『共通フレーム2007』(共に連載第2回を参照)とは,どのような関係になるのですか?」古河課長はうれしそうに答えました.「良い質問だ.ただ結論から言うと直接の関係はない.CMMIは独自に定義している固有ゴールと共通ゴールを達成しているかどうかに関心があるからだが,結果としてかなりの部分をそれらのプロセスモデルはカバーしている.ISO/IEC 15504はメタモデルだが,実はそこで想定されている標準的なプロセス参照モデルは,ISO/IEC 12207やISO/IEC 15288だ.だからこれまで作られたアセスメントモデル(コラム参照)の多くはISO/IEC 12207を下敷きにして,そこに業種固有の要件を反映している.」
 最後に古河課長はこう締めくくりました.「『プロセス評価と改善』というテーマへのアプローチは選択肢が多い.君はまずそれらの選択肢を評価して,結果を報告したらどうだろうか?アプローチによっては,すぐに億単位の予算が必要になるからだ.」
 熊川さんは「全体が何とか見えてきました.何か特に注意すべき事項はありますか?」と聞きました.古河課長は「『プロセス評価と改善』というテーマへ取り組む際の重要な留意事項が2つある.1つ目はよく言われる形骸化だ.これは会社の大きな無駄につながるので,なぜそうしたことが起きるのかを自分でよく考えながら進めてくれ.ポイントは,経営層から現場までが一貫して「プロセス改善を本気で進める」という意識を共有し続けることができるかどうかだ.現場が「上位層の本音は,手をかけずに形を整えることだ」と考えるとか,上位層が必要な予算を出し渋ると,言い訳材料ができて簡単に形骸化してしまう.2つ目は,改善は継続的であることだ.我々の仕事の外部環境(市場,顧客,競合・・・)も内部環境(組織体制,要員,能力,方針・・・)も常に変化しているので,仮にある時点で最適化を達成できたとしても,次の瞬間から最適ではなくなっているからだ.」と答えました.熊川さんはこの2つのポイントを肝に銘じながら調査に着手しました.

<プロセス評価の流れ・・・>
 1980年代に日本では問題点を起点とするボトムアップ型のQC活動による改善活動が中心だった.1990年代以降はベストプラクティスの体系,言い換えるとあるべき姿のモデルに照らしてプロセスをアセスメントするアプローチが注目され,日本だけでなく世界中に普及して来た.
 この中でアセスメントの基盤とするモデル(=アセスメントモデル)が数多く提案され,使用されてきた.日本のソフトウェア業界ではISO9000シリーズが最初に注目されたが,全業種対象のため抽象度が高いことから,90年代に盛んにソフトウェアに効果的に適用する方法について議論された.一方ソフトウェアとシステムを対象とするSW-CMM,CMMIが,経済産業省の「日本版CMM構想」の影響もあって,次第に注目されるようになった.この大きな流れは各国で余り差はないが,具体的な姿は地域によってかなり違う.
 アメリカは,国防総省(DOD)の影響もあり,一貫してSW-CMM,CMMIが中心になってきた.ヨーロッパでは,90年前後から数多くのモデルが使用されてきたが,現在では15504系のモデルであるAutomotive SPICE(自動車産業),SPICE for SPACE(航空宇宙産業),Medi SPICE(医療機器産業),Banking SPICE(金融業界),などがCMMIと共に展開されている.この中で例えば自動車業界では,欧州の主要完成車メーカ(Audi, BMW, Daimler, Fiat, Ford, Jaguar, LandRover, Porsche, VW, Volvoなど)が,車載ECU(Electronic Control Unit)に向けたソフトウェアを開発するサプライヤーに対して,開発プロセス標準として定義したAutomotive SPICEに基づいたアセスメントを実施している.日本の主要自動車部品メーカもこれらの完成車メーカに部品を輸出しているため,このアセスメントを受けている.

 「ライフサイクルにおけるプロセス評価と改善からSQuBOK®を読み解く」シリーズは今回で終わりです.SQuBOK®はソフトウェア開発のいろいろな場面で活用できることを知っていただけたでしょうか.SQuBOK®には先人たちのさまざまな知恵がいっぱい詰まっています.ぜひ一度手にとってみてください.

プロフィール

古賀惠子(こが けいこ)
株式会社日立システムアンドサービス シニアコンサルタント
ソフトウェア開発に関する品質管理支援を行っている.

大川鉄太郎(おおかわ てつたろう)
日本ユニシス株式会社 品質保証部
ISO/IEC SC7 WG10委員、情報技術標準化研究センター(INSTAC) SPA WG委員
サービス品質の測定とマネジメント、ソフトウェアプロセスの改善、信頼性に取り組んでいる。

河合一夫(かわい かずお)
プロムス 代表
PMI日本支部地域サービス委員会副委員長,
ソフトウェア技術者ネットワーク(S-open)副会長
ソフトウェア開発プロジェクトの支援やソフトウェア開発支援ツールの開発を行っている.

最新号目次へ2. 人材育成へ4. トピックス(1)へ

ソフトウェア品質のホンネ
SQuBOKソフトウェア品質体系ガイド
セミナー
SQiPセミナー
SQiPセミナー開催レポート
研究会
ソフトウェア品質管理研究会
シンポジウム
ソフトウェア品質シンポジウム
資格試験
ソフトウェア品質技術者資格試験
JSTQB 認定テスト技術者資格
国際会議
世界ソフトウェア品質会議
ASQN
ニュース
SQiPニュース
webマガジン「QualityOne
コミュニティ
ソフトウェア品質確証部長の会(東京)
ソフトウェア品質保証責任者の会(大阪)
SQiPコミュニティ
SQiP SIG
SQiPアーカイブ(研究成果や実践事例集
SQiPライブラリ
ソフトウェア品質管理の宝箱
調査・研究
ソフトウェア品質実態調査
調査・研究
 SQuBOK®ガイド