ソフト開発委託先の開発能力はソフト開発監査で見切る
開発委託先の能力は監査でプロセスと要件管理とテストと設計実装力を見て判断する
ソフトの開発を委託する開発委託先の開発能力や品質保証力を把握するために、グータラ親父はCMMIとISO9001 を元に作ったソフト開発監査を行ってきました。ソフト開発監査では、プロセス品質の保証力とプロダクト品質の保証力の２つの面からソフト開発能力を判断します。プロセス品質の保証力はCMMIの考えに沿って重要な開発プロセスが実行されているかを確認します。プロダクト品質の保証力についてはソフトの開発委託にとって重要な要求仕様や要件を確定する技術力、テスト技術力、設計実装技術力、について確認をします。
ソフトがどんどんと大規模化していく現在では、全てを自社で開発する事は多くの企業にとって不可能です。その結果、同業他社やソフトハウスなどの開発業務を受託してくれる会社に、ソフト開発の一部や全部を業務委託するという事も多くなってきました。開発委託先のソフト開発能力を予め正確に知る良い方法があれば嬉しいのですが、エンジニアの技量の大きく依存するソフト開発の能力はなかなか測れません。グータラ親父は開発委託先のソフト開発能力を判断する方法として、ソフト開発監査を行ってきました。この一連の記事ではグータラ親父流のソフト開発監査について紹介します。
ソフト開発監査は ISO9001 と CMMI にプロダクト品質確認を合わせた監査方法です
ソフト開発監査という言葉は一般的ではありませんし、そのような規格や規定が決まっているわけでもありません。ISO9001 の監査の仕組みと CMMI の重点的な確認項目を使ったプロセス品質の確認と、要件定義/テスト/設計実装 を確認するプロダクト品質の確認を組み合わせて、グータラ親父が勝手に作ってその様に読んでいる独自の監査方法です。とはいえ、20年近くをかけて多くのソフト開発委託先を監査してきたので、ソフト開発監査の進め方の中には皆さんがソフト開発委託先を監査する時の参考になる情報もあるかと思います。この記事分類ではグータラ親父流のソフト開発監査について紹介していきます。
ソフトの機能・性能・品質は開発チームの力量で決まります
ソフトの開発現場に長く居ると見えて来るのですが、ソフトの開発委託先を選ぶ時に、会社の経歴とか開発実績とかよりももっと重要な事があります。それは、今回の開発を請け負ってくれる開発チームの力量です。どんな開発プロセスを使い、どんな開発管理を行い、どんな開発技術力を持っているか、これらを総合した開発チームの力量が、出来上がって来るソフトの機能・性能・品質に大きく影響します。
作業の殆どが、技術者の頭の中で行われる設計/実装作業で成り立っているソフトの開発の結果は、結局のところ技術者一人一人の力量に依存します。そして、技術者の集りである開発チームの力量が、出来上がって来るソフトの機能・性能・品質を決めます。
ですので、開発を受託してくれる予定の開発チームの力量を知る事ができれば、その会社にソフトの開発を委託しても大丈夫かどうかの判断をする事ができます。 も、開発チームの力量ってなかなか判りませんよね、実際にソフトが出来上がってくれば、機能・性能・品質の善し悪しは判るので、その結果から開発チームの力量を知る事はできます。でもそれでは遅いですね、さてどうしましょう？
ソフト開発監査って聞いた事ありますか？
ソフト開発監査という言葉は聞き慣れないと思います。 ソフトの業界でもまだ一般的とは言えるものでもなく、幾つかの取り組みが始まっている段階です。 IPA では 2010年頃から「ソフトウエア品質監査制度」の検討を進めておられましたが、この活動は第三者によるソフトウエアの検証作業の制度化なので、今回紹介するソフト開発監査とは主旨が事なる活動です。
まあ、ソフト開発監査という言葉はグータラ親父が勝手にそう呼んでいるだけなので、世間一般には存在しない勝手な造語かも知れませんので、この呼称自体はあまり気にしないで下さい。
なんじゃそりゃ！ と突っ込みたくなった人はまっとうな知識と判断力をお持ちです。 実はソフト開発監査とは、ISO9001 の第二者監査の方法と CMMI のソフト開発組織の能力判定の方法とを組み合わせてプロセス能力を判定する方法に、要件管理・テスト技術・コーディング技術という技術レベルの確認項目を合わせ込んだ、ごった煮状態の手法にグータラ親父が勝手に付けている名前です。
ISO9001 と CMMI の組み合わせで開発プロセスの良し悪しを判断
グータラ親父も別に好き好んで、ソフト開発監査という何やら怪しげな方法を思いついた訳ではありません。 ある時に、開発委託をしていた製品のソフトで大きな問題が起きてしまい、このままその会社に開発委託をし続けても良いかどうかを判断しないといけない事態が起きました。 その時に、ISO9001 の監査の方法と CMMI の監査項目を組み合わせて、ソフト開発監査の原型になるような監査を行い開発プロセスの状態を確認しました。
ISO9001の監査という言葉は、聞いた事がある人も多いますが、製造現場の品質担保能力を改善する事から発展してきた、業務全般に渡るプロセスの品質確認と改善のための監査の枠組みです。 似たような活動にソフトウエアの世界では CMMI がありますが、こちらは監査ではなくて認定です。 ISO9001 は監査という方法で製造プロセスの善し悪しを元に合否を判定しますが、その目的はより良い製造プロセスへの組織の改善/向上を推進する事です。 ですので、監査の指摘事項に対する改善とそのフォローアップに重点が置かれます。 一方の CMMI は、ある時点における組織のソフトウエア開発管理能力を５段階で評価します。 その時点で、その組織がどのレベルの開発管理力を有しているのかを絶対値で判断するために、判断基準に重点が置かれます。
CMMI ではだめなのでしょうか
グータラ親父が必要としていたのは、ある会社にソフトの開発を委託しても良いかどうかの判断なので、CMMI の手法で良かったのです。 ですが、実際にソフトの開発監査を行うのは、ある会社に開発を委託しても良いかどうかの判断をしたいという場面だけではなく、既に開発を委託している会社に対して、良いソフトを開発して納品してくれるように指導して改善したい、という場面のも多く起こります。 この指導と改善という目的に対しては ISO9001 の監査の枠組みの方がよく出来ています。
という事で、グータラ親父は ISO9001 の監査の枠組みと CMMI の認定の判断基準とを組み合わせて、ソフト開発のプロセスの状態を確認し改善の指導にも使える仕組みに作り直しました。 これがソフト開発監査の原型です。
原型にプロダクト品質の確認を加えてっソフト開発監査に進化？
このソフト開発監査の原型を使って、何社かの監査を実行していくうちに、困った事に気付きました。 ISO9001 も CMMI もソフト開発プロセスに対して、善し悪しの判断や改善の指導をする事を目的に作られています。 ソフト開発プロセスも当然大切なのですが、私たちが本当に良い物であってほしいのは、ソフトのプロダクトの品質です。
もう少し具体的に言うと、プロダクト品質を決定付けるテストの能力や、要件定義の能力、設計/実装の能力に等のソフトの技術力に関する部分は、ISO9001 や CMMI の仕組みではよく判らないのです。 IS9001 も CMMI も良いプロセスを採用する事で結果的に良い製品ができるでしょう、という前提でプロセスを良くする事を目的として考案された物です。ですので、プロダクト品質そのものの善し悪しの判定がその範囲外なのはしかた無いのですが、それではグータラ親父としては痒いところに手が届かないという状況になりました。
じゃー改善してしまえ、、、という事で、テスト能力、要点定義能力、設計/実装能力を確認する項目を追加して、プロダクト品質の良し悪しの判断や改善の指導に使えるような項目を、グータラ親父の経験を元に付け足して、最終的なソフト開発監査の方式に仕立て上げました。
プロセス品質については ISO9001 と CMMI の合体、プロダクト品質については経験に基ずく独自項目の追加という事になって、メデタクソフト開発監査ができあがりました。 なんか、色々な物を適当にくっつけたごった煮状態なのですが、、、
とはいえ、これでプロセス品質とプロダクト品質の両方について、監査対象の会社の能力を判断し、改善の指導を進める事ができるので、実務上は結構役に立ってきました。 かなりグータラ親父の独断と偏見で出来上がっている部分が多いのですが、グータラ親父流のソフト開発監査の方法や実施方法について以下の記事で具体的に紹介していきますので、興味のある方は御付き合いください。
できるだけ判り易く紹介しようと思います
ソフト開発監査の生い立ちの説明になってしまいましたが、要するにソフト開発監査とは、世間一般には無いグータラ親父が勝手に作った方法なので、色々と判り難い点もあるかと思います。 できるだけ判り易く紹介していきますが、理解し難い部分もあるかも知れません。 でもまあ、ここに書いてある事はあくまでもグータラ親父の経験に過ぎないので、全てを正確に理解する必要は有りません。
判り難い所があっても、そこは記事を読まれた人が自分自身でやり易い内容に読み変えていかれれば、それで良いと思っています。 ここに書いてある事自体も、完成された最終形ではなく作成途中のような物です。 そんな物でも、皆さんの参考になればと思い紹介させて頂きます。
それぞれの記事のタイトルの先頭にはソフトの開発監査に関する小分類を付けてあります。小分類に続くサブタイトルが具体的な記事の概要です。 読む順番は特に決まりはありませんので、気になる記事から順にご覧ください。 全体をざっと理解したい人は、小分類が概ソフト監査概要となっている記事をご覧ください。 概要の記事に書いてある事をもう少し詳しく知りたい方は、ソフト監査実務の個々の記事をご覧頂くか、概要の記事の文末からリンクされている個々の記事を順番に読み進めて頂くと良いと思います。