ソフト開発監査チェックリスト（１）要件管理プロセス
開発プロセスチェックリストのチェック項目を紹介します
ソフト開発監査は、ソフトの開発委託先の能力を判定するためにグータラ親父が勝手に命名した監査の方法です。ソフト開発監査の概要や監査時の事前の準備や監査当日の作業内容については、他の記事で紹介しています。また、ソフト開発監査で使う監査チェクリストの使用時のポイントについても、別の記事で紹介していますので、そちらをご覧ください。
この記事では、以下の４つの監査チェックリストの個々の項目について、順番に紹介していきます。
- 開発プロセスのチェックリスト
- 開発技術の１つ目の要件管理のチェックリスト
- 開発技術の２つ目のテストのチェックリスト
- 開発技術の３つ目の設計と実装のチェクリスト
この記事ではまず、開発プロセスチェックリストの各々の項目について紹介します。なお、開発プロセスチェックリストを使う時のポイントにつては、ソフト監査実務・監査当日その７：開発プロセスのチェックのポイント の記事で解説していますので、そたらも合わせ読んで頂くと、判り易いと思います。
開発プロセスチェックリストの使い方
ソフトの開発プロセスは、当初に計画した機能や性能を持つソフトを計画した時期に完成させてリリースするというソフト開発プロジェクトの目的を、何時も安定し達成するためにとても大切な物です。開発プロセスが未熟だと、開発プロジェクトがうまく行く時もあれば失敗する時もありとなってしまい、安心してソフト開発を委託できなくなってしまいます。ですのでソフト開発監査でも、開発技術力の確認と並んで開発プロセスの確認はとても大切な項目です。
ソフト開発監査という手法そのものがグータラ親父が勝手に作って勝手に呼んでいるだけなので、これが正解という物はありません。開発プロセスのチェックリストについても、別にこれが正解という物でも無いのですが、グータラ親父は開発プロセスを確認する場合にはこんな項目に注意していましたよ、という事を紹介する意味で、以下にチェックリストの例を載せてありますので、こちらも見ながら記事をご覧ください。
チェックリストは１行１項で、横に６つの欄で構成
開発プロセスのチェックリストは１行が１つのチェック項目となっていて、横方向には６つの欄がありますのでまずは各々の欄を簡単に説明しましょう。
No. 欄は、各盲目の固有番号です。監査時に項目を示す時は、監査報告書等で項目を参照する時にこの固有番号を使います。
Category欄は、開発プロセスの大分類名(Category名）です。 このCategory名は CMMI Level2 の名称を使っています。ちなみに、No. 欄の番号の接頭後はカテゴリ名の略称を使ってあります。
Item欄は、チェック項目の概要です。チェック項目は CMM Level2 の項目を参考に作ってあります。 なお、グータラ親父が参考にした CMM は CMMI の１つ前の物なので、最新の CMMI とは微妙に違う箇所もあります。まあ、CMM Level2 の内容をグータラ親父が自分なりに解釈して作ったのがこのチェック項目なので、CMMとの対応もあまり厳密ではありません。CMMI の翻訳文書はここで公開されていますので CMMI を詳しく知りたい方はご覧ください。
Check Point 欄は、 Item 欄の内容をもう少し具体的な確認内容にブレークダウンした物です。実際のソフトウエア開発監査では、この Check Point 欄を使って確認を進めていきます。
Answer and Evidence(Pre) 欄は、監査の前に相手先の組織に記載をしてもらう欄です。記載された内容を予め見て置いて、監査当日に現地で確認する項目を決めておくために使います。監査の実際の進め方については、実務・当日までの準備 の記事で紹介していますので、そちらもご覧ください。
Comment 欄は、監査当日に気づいた事などを追記するためのメモ欄です。グータラ親父は監査当日はチェックリストを紙に印刷して、監査中に気づいた内容をこの Comment 欄に手書きしてメモ代わりに使っていました。
ここまでで開発プロセスチェックリストの概要を紹介してきましたので、次からはいよいよ各々の項目の紹介をしていきましょう。まずは開発プロセスとしての要件管理です。なお、チェックリストの種類の中に要件管理のチェックリストという物があって紛らわしいのですが、開発プロセスのチェックリストの中の要件管理の項目は要件管理のプロセスに関する確認で、要件管理チェックリストは要件の中身に関する確認です。
要件管理のチェック項目の詳細
要件管理のチェック項目は、項目番号の先頭がRM- となっている４項目です。ソフトウエア開発業務の委託では、開発要件をできるだけ正確に委託先に伝える事が大切です。開発業務を受託する側からみると、顧客の提示する開発要件をいかに正確に把握するかが大切です。顧客の開発要件を正確に把握するために、どんな開発プロセスを使っているのかという点を確認するのが、この大分類（Category)です。では項目番号の順に見ていきましょう。
【項目番号：RM-01 】
開発要件は受託した開発作業の規模や複雑さや必要な開発期間などの開発計画に大きく影響します。ですので、開発チームを組んで開発を始める前に、どの程度の規模のチームなら受託ができるかとか、どの程度のエンジニアが何人くらい要るのかとか、どれくらいの期間が掛かりそうかという事を、関連する部門を集めてレビューして適切な開発計画を作る必要があります。
そのためのレビューが開発プロセスとしてありますか、という確認です。もう少し平たく言うと、自社で受託できるかどうかよく検討しないまま営業担当が客先から受注してきて、あとは開発部門に丸投げという状況は起きないですよね、という確認です。
【項目番号：RM-02 】
受託した開発業務に従ってソフトの設計・実装・テストを進めるために業務計画書を作ります。この業務計画書に従って実際の開発業務が進むのですが、そこに不要な開発要件が混じりこんでいたり、必要な開発要件が漏れていていると困ります。
大切なのは、客先から示された要件を満たすソフトを開発するために必要な、人員と機材と期間がちゃんと計画されて業務計画書に書かれているかという事です。一言で言えば、客先の要件を実現できそうな業務計画書が作れる業務の仕組みになっていますか、という確認です。
【項目番号：RE-03】
開発要件が途中で変わる事は、残念ながらソフトの開発では良くあります。変更の量が多いと、必要な開発工数や開発納期などにも影響が出ますし、場合によってはソフトの構造の見直しも必要になるかもしれません。開発要件に変更があった時には、その影響範囲を正しく判断するために、関係者でレビューをしてから業務計画を見直して、見直した業務計画に従って開発業務を進めるようなっている事を確認します。これも一言で言えば、開発要件が増えたらそれに合わせて人を増やすか納期を伸ばすか検討する仕組みになっていますか、という確認です。
【項目番号RE-04】
開発要件に変更があった時は、前述のようにそれに従ってまず開発計画の見直しがあります。そして、実際の開発では設計書やソースコードやテスト項目などに、新たな開発要件に対応した追加や修正を加えるという作業が発生します。このような開発途中での要件の変更に対応して、実際の開発業務の内容が漏れなく変更されている事を確認する仕組みがあるかどうかを確認します。例えば、要件の１つ１つに固有のID番号を振って、設計書やソースコードやテスト仕様書に対応する要件のID番号を記載するような開発管理の手法を採っているのなら、新たに追加された開発要件のID番号が、設計書やソースコードやテスト項目に入っている事をどこかのレビューで確認するような開発プロセスがあれば良いですね。
要件管理の次は計画管理です
要件管理の確認の次は計画管理についての確認項目について、次の記事で紹介します。