ソフト開発監査の方法（４）ISO9001とCMMIでプロセスを監査し開発技術力は別に確認します
ISO9001とCMMI で開発プロセスを監査してそれとは別に開発技術力を監査します
ソフト開発能力の良し悪しを判断するソフト開発監査では、ISO9001 と CMMI の手法を使って開発プロセスを監査します。ソフト開発では開発プロセスと開発技術の両方が揃っていて初めて品質の良いソフトが出来るので、開発プロセスとは別に要件管理、テスト技術、設計・実装技術に分けて開発技術力についても監査します。
ISO9001とCMMIとは何が違うの？ （ちょっと寄り道）
前の記事ではソフト開発監査のプロセス監査に使っている ISO9001 と CMMI についてかなり端折って概要を紹介しましたが、なんとなくイメージは掴んで頂けたでしょうか？ ISO9001 は開発管理プロセスの改善を目的とし、CMMI は開発管理プロセスの評価を目的としてる、という違いがあるな～という事はぼや～とでも判って頂けた事と思います。
では、ISO9001 と CMMI とは、目的が違うのだからその手法も違うのでしょうか？ 実は、少々荒っぽい言い方にですが、どちらも考え方やその手法はほぼ同じです。
何が同じかというと、①開発管理のためのルールが有るかどうかを確認して、②そのルールに従って実際の開発管理が実施されている事を確認する、という実務的な進め方が同じなのです。 まあ、目的は違いますが、どちらもその組織の今の開発管理の現状を具体的に把握する事がまず大切なので、ルールの確認と実施状況の確認という手法は似通ってくるのですね。 現状を把握した後に、その改善に焦点を当てる ISO9001 と評価に焦点を当てるCMMI という違いが出てくる、と考えると判り易いです。
ISO90001 は、監査の結果として問題点を指摘して改善対策を要求する事で、開発管理能力を改善する事を推進します。 CMMI は、監査の結果としてその組織がどのレベルに到達しているかを評価する事で、組織の管理能力を客観的に判断できる物差しを提供します。とう程度の違いはありますが、どちらも現状を把握するために採用している手法は良く似ています。
とい言う事は、ソフトの委託先を選定する時には CMMI を使うのが良く、既に開発を委託している会社の開発管理力を改善したい時には、 ISO9001 を使うのが良いという事ですね、はいその通りだと思います。
ソフト開発監査という作業を行う場面によって、ISO9001 と CMMI とを使い分ければベストなのですが、、、２つの監査の手法を使い分けるほど充分に、ソフト開発管理の品質改善に投入できる経営資源（要するに人員ですな）があるという理想的な状況はなかなか無いというのが現実の世界でして、、、仕方が無いので ISO9001 と CMMI を足して２で割ってどちらにも使えるようにしてしまいました、というのがグータラ親父流のソフト開発監査です。
ISO9001とCMMIとを足して２で割ると
とはいえ、 ISO9001 と CMMI を足してごちゃまぜにして２え割ると、何がなんだか判らなくなるので、以下のような方針を決めた上で足して２で割ってます。
- 監査で確認する項目は CMM レベル２の確認項目から重要な物を選んで使う
- 監査の進め方は ISO9001 の方法を使う（計画、実施、報告、改善要求、フォローアップ）
要するに、ISO9001 の手順で CMMI のチェック項目を確認するという方法です。 CMMI ではなく、CMM レベル２を元にしているのは特に大きな理由はありません。ソフト開発監査を考え付いた時には CMM しか存在しなかったというのと、レベル２が出来てれば最低限必要な開発管理力が見極められるからです
監査の進め方として ISO9001 を使ったのは監査を受ける会社に説明し易いという面も大きいです。ソフト開発監査をやりますよ、と言っても相手が応じてくれない事には話が進みません。で、世の中にソフト開発監査なんていう名称の活動は無いので、まずは目的と概要の説明から始まめないといけません。
その時に、 ISO90001 の手順であれば相手の会社も ISO90001 を受けている場合が多いので、割とスムーズに話ができます。
一方で、監査の中味になるチェック項目については、ソフトに特化している CMM を使う方が、より効果的に確認できるので、こちらを使う事にしました。
開発技術力の監査はプロセス監査とは別にチェックリストを用意して行う
ソフト開発の管理力については、CMMIとISO9001 とを足して２で割る事で何とかなりましたが、これだけでは残念ながら開発委託先のソフト開発能力の善し悪しを判断すにのには情報が足りません。
ソフト開発では、設計やコーディングを実際に行う製造設備そのものもエンジニアという人です。そして、個々のエンジニアの技術力がそのままその組織の技術力になります。開発管理能力と技術力とは一般的に相互に関係しないので、いくら開発管理力が良くても、技術力が低いとよいソフトはできてきません。まあ、製造工場でも、製造設備の能力が悪ければいくら良い製造管理を実施しても良い製品が出来てこないので、ソフト開発に固有の問題ではありませんが。
開発委託先のソフトの開発能力を判断するには、その組織のソフト開発の技術力の状況についても確認する手段も必要になります。
開発技術力は要件定義と設計・コーディングとテストの３つを見る
ソフト開発の技術力と一言に行っても非常に広範囲にわたるので全てについ善し悪しを判断する事は不可能です。そこで、グータラ親父のソフト開発監査では、組み込み系のソフトの開発において特に大切になってくる ①要件定義技術、②設計とコード製造技術、③テスト技術、の３つの技術領域について、具体的なチェック項目を作って、各々の技術領域の重要性をどの程度理解しているか＆実施しているか、どい目で確認する事にしています。
①の要件定義技術は、ソフト開発の入り口です。 ここで明確に仕様を定義できていないと、この後の工程でいくら頑張っても的外れなソフトが出来上がってしまいます。 ③のテスト技術はソフト開発の出口です。要求された仕様どおりのソフトに仕上がっている事をどうやって確認するのか、ソフト品質の最後の関門です。
そして、②設計とコード製造技術が、入口の①と出口の③とを繋ぐ、実際の設計・実装の作業です。この実作業の中で、レビュー等を含めてどんな仕組みで必要な技術を維持しソフトの開発に利用しているかを見て行きます。
開発技術力の監査については、実のところかなり内容を絞り込んだチェックリストになっています。ソフト開発技術が非常に広範囲なので網羅する事は最初から考えていません。 ただ、ソフト開発は全て人が行うので、私の間違いは貴方もするでしょうの法則に従って、過去にグータラ親父が見聞きした問題点を中心にチェックリストを作っています。
実際チェックリストについては、詳細な説明の記事で説明していますので、興味のある方はそちらをご覧下さい。
もう少し詳しくは個々の記事をご覧ください
ソフト開発監査の実務についてもう少し詳しく知りたい方は、記事上部の 開発監査 のリンクで表示されるソフト開発監査のトップページに戻って頂いて個々の記事をご覧ください。以下のリンクからもソフト開発監査の実務についての個々の記事を順に辿れますので、こちらからご覧頂いても同じ記事にたどり着きます。