ソフト開発監査チェックリスト（２）計画管理プロセス
開発プロセスチェックリストの２番目は計画管理です
この記事では、ソフト開発監査に使う監査チェックリストの個々の項目についての紹介をしていきます。監査チェックリストは①開発プロセス ②要件管理 ③テスト ④設計と実装 に分かれていて、この記事では①開発プロセスの中の計画管理の個々の項目について紹介します。（チェックリストそのものはソフト監査実務・チェックリストその１：開発プロセス（要件管理）の記事に載っていますので、そちらをご覧下さい）
計画管理のチェック項目
計画管理に関するチェック項目は、項目番号の先頭がPP- となっている６項目です。ソフト開発に限らないですが管理のためにはまず計画が必要です。漏れのない開発計画を作るために、どんな開発プロセスを使っているのかという点を確認するのが、この大分類（Category)です。では順番に見ていきましょう。
【項目番号：PP-01】
ソフトの開発部門は、客先や社内の製造部門等に対して、ソフトのリリース時期や搭載する機能や性能などの約束（コミットメント）を行います。この開発部門が行うコミットメントに従って、客先は新しいソフトの導入計画を検討したり、社内の製造部門は製造ラインの計画を作ったりします。
ソフトの開発部門が組織の外に対して行う約束は、開発部門の外の組織や個人の活動に大きな影響を与えるので、一度宣言したコミットメントはあまり軽々しく変更しては信頼が無くなります。ですので、開発部門の外に対してコミットメントを行う時には、開発部門の責任者が必ずその内容をレビューしておく必要があります。そのような業務の仕組みになっていますか、というのが確認する内容です。
【項目番号：PP-02】
開発計画を作る時に一番最初に検討するのが、開発工数です。開発要件を満たすソフトの規模（何KLOCのコードが必要か）を見積もり、その規模のソースコードの設計・実装・テストに何人月の開発工数が掛かるかを見積もり、必要な開発人員の計画をたてると、開発納期が見えてきます。
こう文章にすると簡単なのですが、同じ開発規模でも求められている品質や動作環境が違うと必要な開発工数が大きく変わるなど、変動する要素が多いので精度の高い開発工数の見積もりはなかなか難しいです。おまけに、こうやって見積もればよいという汎用的な見積もりの方法も無いので、見積もりをする人の経験によって見積もった開発工数が大きく変わる場合もあります。
そのような変動をできるだけ少なくするためには、見積もりの方法についてルールを決めて、皆が同じルールで見積もりをする必要があります。そのような見積もり方法を書いたルールがありますか、というのが確認する内容です。
【項目番号：PP-03】
開発計画には最低これだけは書いていないといけない項目があります。開発費用と必要機材と必要な人材と納期と技術的な懸案事項です。特に技術的な懸案事項は、開発を始める時点で洗い出しておき、開発作業を進める中でその懸案事項に対する対策を進めないといけません。
どんな技術的件懸案事項があって、それは誰が何時までに対策を行うのか、その内容を開発計画書に書き出しておく事が大切です。これらの項目が開発計画書に漏れなく書いてあって、その内容をレビューする仕組みができているか、というのが確認する内容です。
【項目番号：PP-04】
相当小規模なソフトでない限り、全てのソースコードを自社で開発するような場面は減ってきました。逆に、既存のソフトに機能を追加したり機能を削除したり、フリーソフトのOSの上にアプリケーションを搭載したり、という方法で開発されるソフトが増えてきました。そのような開発の元になったソフトを開発のベースソフトと呼んでいます。そしてこのベースソフトの品質は自社の製品となるソフトの品質に大きく影響するので、品質をしっかりとい確認しておく事が大切です。
そこで、元になったソフトの品質をどんな方法で確認しているのか、例えば何等かのテストを自社でやっているのか、自社ではテストできないなら市場の稼働実績から品質の良し悪しを推定しているのか、ベースソフトがちゃんとした手順で設計/実装/テストが実施されているのか、などの点を確認します。
【項目番号：PP-05】
ソフトを開発するには、各種の機材やターゲットとなるハードウエアや動作確認・デバッグのための統合開発環境など、いろいろな物が必要になってきます。また、設計ドキュメントの維持にはドキュメント管理システムを、バグの管理にバグトラッキングシステムを、というように社内システムを使う場合も多いです。このような、開発環境や機材や社内システムについて、必要な数量や時期が計画されているか、等の点を確認します。
【項目番号：PP-06】
顧客からの要求仕様に沿った開発の場合には、開発の途中でも定期的に顧客と連絡をとり、開発要件、進捗、品質 などの情報を共有しておく事で、開発計画を維持する力が働きます。多くのソフト開発プロジェクトは、残念ながら要件の増加や当初計画の無理な工程のために、開発計画が遅れる傾向にあります。
しかし、客先と定期的な打ち合わせを持つ事で、社内の開発遅れを挽回するための活動に力が入って結果として遅れを最小限に留める事もあります。また、どうしても計画が遅れそうな場合でも、早めに顧客と相談する事で、影響を最小限に留める事もできます。そのような事を考えると、顧客との定期的な情報共有はしんどい事です、がプロジェクトの成功につながる１つの大切な方法なので、開発計画でその具体的な方法が決められている事を確認します。
計画管理の次はトラッキングです
計画管理の確認の次はトラッキング（計画の実績追跡）についての確認項目について、次の記事で紹介します。