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