ソフト開発監査では開発プロセスの良否をまず判断する
ソフト開発監査では開発プロセとテスト技術と要件把握と設計と実装を監査します
ソフト開発監査では開発プロセスの品質とソフト開発技術力の良し悪しを評価します。ソフト開発技術はさらにテスト技術と要件把握と設計・実装３つの分野に分けて評価するので、全体では以下の４つの項目に分かれます。ソフト開発技術にはこれ以外にも様々な観点があるのですが、限られた時間で開発委託先の技術力を評価するために、ソフト開発監査ではこの３点に絞ってソフト開発技術の良し悪しを判断していました。この記事ではソフト開発監査で最初に確認する１項目の開発プロセスの良し悪しを評価する方法について紹介します。
- 開発プロセス （ソフト開発に使っている開発プロセスは良好か？）
- 開発技術：テスト技術 （リリースまでに実施しているテストの技術力は十分か？）
- 開発技術：要件把握 （開発要件を具体化し委託元と共有する技術力は十分か？）
- 開発技術：設計・実装 （ソフトの設計と実装の組織としての能力は十分か？）
それでは、開発プロセスについてどんな観点で何を確認しているのか順に紹介していきましょう。
１．開発プロセスの監査はCMM レベル２の項目を抜粋して使う
ソフト開発における開発プロセスとは、ソフトの企画検討から始まって、設計、実装、テスト、リリース、保守 へと続くソフトのライフサイクルを実現するために、ソフト開発組織が行う活動の作業手順の事です。開発プロセスつまり作業手順が良ければ、常に良いソフトが出来あがるだろうという考え方が基本にあります。開発プロセスの善し悪しを判定し、或いは開発プロセスの悪い部分を見つけてそこを改善する事で、良い品質のソフトを作り出そうというというのが開発プロセスに焦点を当てた品質改善の手法です。
プロセスの良否を判断したり改善点をみつけたりするための監査の手法としては、ISO9001 の第二者監査やCMMI による組織の完熟度レベルの認定、という手法が一般的です。どちらの手法も基本的な考え方は似ています、必要なプロセスを少し抽象的に定義してあって、①そのプロセスを自社の作業手順として具体化したルールが文書として存在しているかどうか、②実際の開発作業がルールどおりに実施されてその作業記録が残っているかどうか、③作業結果は管理者によって確認さているか、という３つの視点で開発プロセスの善し悪しを判断します。
グータラ親父のソフト開発監査は、ISO9001 の監査の手順と CMMI の監査の項目を組み合わせて作ってありますが、開発プロセスの項目は CMMI レベル２の確認項目を元に作成しています。この CMMI レベル２ではソフトウエア開発を以下の６つの領域に分けていますので、まずこの６つの領域について簡単に説明します。（CMMI をご存じの方は、ここは読み飛ばして頂いて大丈夫です）
- 要件管理 （Require Management）
- 開発計画（Project Planning）
- 進捗管理（Tracking and Oversight）
- 品質保証（Quality Assurance）
- 構成管理（Configuration Management）
- 外注管理（Subcontract Management）
要件管理のプロセス良好で確実に実行されているか
要件管理をソフト開発プロセスという視点で見ると、①要件の開発委託元とのレビュー ②要件の社内開発チーム内での共有 ③要件変更時の対処 ④開発部門のコミットメント 等を実現するためのプロセスの有無やルール化や実施の状況が、確認の対象になります。
プロセス監査ですので要件の内容に立ち入った確認を行う事はなく、開発要件の具体的な内容を開発チームに間違いなく通知する仕組みがあるかどうか、とう視点での確認が主体です。
開発計画は作成とレビューの仕組みができているか
ソフトウエア開発プロジェクトにとって開発計画はとても重要です。 ただしこの項目も開発計画書の内容に深く踏み込むのではなく、開発計画の立案の作業手順がちゃんとしているかとか、工数見積もりの方法は決められた方法で実施しているか、というような計画立案作業の仕組みに焦点をあてた確認をしていきます。 とはいえ、ソフトウエアの開発計画として重要なリスク管理の方法とかベースライン品質の確認方法とかは、少し具体的な内容に入り込んで確認する項目もあります。
進捗管理は出来高で実績をトレースする仕組みがあるか
ソフトは目に見えないので、進捗状の把握には注意が必要です。担当エンジニアからの申告だけではなく、設計の成果物の出来高も使って開発の進捗を確認する体制が必要です。ソフト開発監査では、ソフト開発の成果物である設計書やソースコードについて、出来高の実績管理を行っているかとか、開発プロジェクトのリスクと懸案を管理しているかとか、設計レビューなどの実施状況を管理していうるか、というような項目を確認します。いずれも、計画計画書の作成段階で立案された計画に対して、実績がどうなっているかをトレースし問題があれば対応する仕組みがあるか、仕組みがあるならちゃんと稼働しているのか、という観点での確認になります。
品質保証は開発プロセスの品質を確認する仕組みがあるか
ソフト開発プロセスの監査での品質保障（Software Quality Assurance）の活動とは、CMMI の定義するSQA活動なので、主には開発プロセスの実施状況を監視するSQAチームによる監視活動を指します。開発チームが定められたプロセスに従って開発作業を進めているかどうかを監視しその結果を報告しているかとか、テストが決められた手順どおりに実施されているかとか、リリースの可否判定はルールどおりに実施されているか、という様な観点での確認になります。
構成管理は設計書とソースコードと開発環境を管理する仕組みがあるか
構成管理という言葉はソフト開発の分野ではソースコードの構成管理という意味で使われる場合も多いのですが、ソースコード以外でも設計書やテスト結果、開発環境そのものも実は構成管理の対象物です。 少し荒っぽく言ってしまえば、あるバージョンのソフトを生成するために使われた各種の情報のバージョンの管理の事を構成管理と言います。
例えば、バージョン 1.1 のソフトを生成するために、A-設計書バージョン 2.3 と B-設計書バージョン1.5 が使われ、C-ソースファイル バージョン 3.2.43 と Build 環境 バージョン4.0 が使われたとします。これらのバージョンのうちどれか１つでも違ったバージョンの物を使えば、バージョン1.1 と全く同じソフトを生成する事はできなくなります。複数のソフトエンジニアが共同作業で開発を進めている状況では、全員が全く同じソフトを生成できないと仕事になりません。ですので、全てのソフトエンジニが全員、正しいバージョンの設計書やソースコードや Build 環境を使って開発作業を進めている事を保証する仕組みが必要になります。
このように、ソフトを生成するための元情報のバージョンを正しいものに維持する活動が、構成管理です。ソフトの開発監査では、設計書やソースコードや開発環境の構成管理の方法に過不足が無いか、という観点での確認を行います。
外注管理は選定や委託先管理の仕組みがあるか
当社からの開発委託を受けた受託会社が、ソフト開発の一部や全部を他の会社に開発委託（孫請け）している場合には開発委託先の外注管理の仕組みについても注意が必要です。どのような方法で開発委託先を選定しているのか、開発途中での進捗や品質の管理はどうやっているのか、開発委託した成果物はどんな条件で検収しているのかなど、外注管理の仕組みとその実施状況についての確認を行います。
開発プロセスの視点で足りないところは開発技術の視点で
ここまでで、CMMI レベル２の確認項目を元にした６つの領域についての開発プロセス監査の対象領域を紹介してきましたが、いかがですか？ 何か足りないような気がしませんか？
確かに、これまでに出て来た６つの開発プロセスの領域も大切なのですが、ソフト開発の力量を推し量るという目的からはこれだけでは不足している部分があります。テストの能力とか、非機能要件を開発に組み込む能力とか、ソフトの設計や実装の技術力とか、出来上がったソフトの品質に影響を与える大事な部分が漏れています。
そこで、グータラ親父のソフト開発監査では、これらの内容を開発技術力として整理して、開発プロセスとは別の観点から監査を行い開発委託先の力量を推し量っていました。次の記事からはこれらの開発技術に関して、テスト技術、要件把握、設計と実装の３つに分けて、説明をしていきます。