ソフト開発監査の監査当日（７）開発プロセスのチェックのポイント
開発プロセスのチェックリストは開発管理の確認が主体
ソフト開発監査のメインの作業は、以下の４種類のソフト監査のチェックリストを使った項目毎の確認です。
- 開発プロセスのチェックリスト
- 開発技術の１つ目の要件管理のチェックリスト
- 開発技術の２つ目のテストのチェックリスト
- 開発技術の３つ目の設計と実装のチェクリスト
各々のチェック項目の詳細については、ソフト監査実務・チェックリストその１：開発プロセス（要件管理）の記事から順に紹介しますが、詳細な項目の説明の前にまず、これらの４種類のチェックリストを使う時のポイントについてこの記事と続く記事で説明していきます。
まずは開発プロセスのチェックリストです
この記事では、１つ目の開発プロセスのチェックリストを使う時のポイントについて紹介しますが、このチェックリストの目的はソフト開発の管理能力が充分にあるかどうかの確認です。開発プロセスのチェックリストは、CMM レベル２のチェック項目から重要なアクションを選択して作ってあり、このチェックリストに沿って開発プロセスの実施状況を確認する事でソフト開発管理の能力を推測していきます。
以下にチェックリストの例を載せてありますので、こちらも見ながら記事をご覧ください。
開発管理は企業がソフトを作る時には重要
ところでソフト開発管理とはどんな物で、何故必要なのでしょうか？ 実は、ソフトの開発においてソフト開発管理は必ずしも必要なわけではありません。ソフトエンジニアがソースコードを書いて、そのソースコードがエラーなくビルドできれば、ソフトは出来上がります。個人が趣味で作るソフトの場合には、これでも全く問題無くてソフト開発管理は特に必要ありません。
しかし、企業で製品用のソフトを開発する場合には、ソフト開発管理が必要になってきます。ソフト開発管理とは、要件の管理や工数（開発費用）の管理、開発スケジュール（リリース時期）の管理や品質の管理です。これらがちゃんと管理できていないと、必要な機能が漏れていたり何時リリースできるか判らなかったりどれだけ開発費用が掛かるか判らなかったりリリース時に品質がボロボロだったりと、色々な問題が起きます。このような問題が起きると、企業としてソフトを開発して世の中に提供していく場合には困ってしまうのです。
開発管理は目的どおりにソフトを開発するための手段
ところで、開発管理とは何でしょう？ 余りにも基本的な言葉なので突然聞かれると戸惑う人も居られるのではないでしょうか？ 管理とは目標を決めて、実績を計って、実績が目標に合うように対策をする事で目標を確実に実施するための手段です。ですので、ソフト開発管理とは、開発の要件や費用やスケジュールや品質について、目標を決めて、開発作業を進める段階でその実績を計って、目標からズレそうなら挽回策を実施して、目標を達成するようにソフト開発プロジェクトをコントロールする事です。そして、この開発管理を行うための色々な仕組みが開発プロセスです。
良いソフト開発プロセスが決まっていて、開発組織がその開発プロセスを守って開発を進めていれば、開発管理が正常に機能します。その結果として、思っていた通りのソフトが、予定していた納期に間に合って、必要な品質を保って、完成する「はず」です。
「はず」なのですが、世の中そんなにうまく行かないのは常なので、開発プロセスにどこか不味いところが無いかを確認して、不味い所があればこれを直しましょう、という事を目的として、ソフト開発プロセスをチェックします。
開発プロセスのチェクリストは CMM レベル２ の確認項目から重要な物をピックアップしています。 CMM のレベル２は、以下の 6つの領域に分けて開発プロセスを確認していますので、開発プロセスのチェックリストもこの6種類に分けてあります。
- 要件管理（Require Management）
- 計画（Project Plammming）
- 進捗管理（Tracking and Oversight）
- 品質保証（Quality Assurance）
- 構成管理（Configuration Management）
- 外注管理（Subcontract Management）
ソフト開発管理を考える上で、最低これだけは必要な領域をピックアップしたのが CMM レベル２の６つの領域ですので、これに沿って相手先の会社のソフトウエア開発プロセスを確認します。ただし、CMMも何にでも効果の出る万能薬ではありません。CMMもまたツールなので、その特徴や限界を知った上で効果的に使う必要があります。
それでは、ここからはグータラ親父が開発プロセスの確認をする時に注意していた点を、紹介していきましょう。
開発プロセスチェックの注意点・その１：開発組織の規模
開発プロセスを確認する上で注意する必要があるのは、適切な開発プロセスは組織の規模によって変わるという事です。これは別にソフト開発に限った事ではなくて、一般的な企業の業務についても同じです。親父さんが１人でやってる八百屋と従業員1000人を抱える総合商社とでは、適切な業務プロセスは違います。
開発プロセスのチェックリストは、大規模開発の場合を想定して様々な確認項目が書いてあります。ソフト開発の組織の規模が大きければ全ての項目で必要になりますが、数人の小規模な開発組織なら必要の無い項目もあります。例えば進捗管理のための実績の把握は、組織の規模が大きい場合には何等かの社内システムを使わないと全貌を把握する事が難しくなります。でも３人のチーム開発でエンジニアが机を並べて作業をしているのなら、社内システムなんて必要は無くて、ちょっと横を見て隣の人の顔色をみれば状況は判ります。
進捗管理は組織の規模の大小に関係なく大切ですが、それを実施するための最適な開発プロセスは組織の規模によって変わってきます。このように、開発プロセスのチェックをする場合にはまず開発組織の規模を把握して、その規模の組織に最適なプロセスが使われているかどうか、という視点を常持ちながらチェックリストの項目を確認する事が大切です。
開発プロセスチェックの注意点・その２：開発計画書
組織の規模の次に注意して確認するのが、ソフト開発計画書です。 管理は目標を決める事から始まるので、最初に目標が決まっていないとそもそも管理ができません。そして最初に決めた目標が書いてあるのがソフトの開発計画書のはずですので、開発計画書に必要な目標が漏れなく書いてあるか？ は大切な確認点になります。
なお、要件管理に必要な開発要件は通常は要求仕様書等に書かれている事が多いのでそちらを確認する事になります。しかし要件以外の工程計画、費用計画（機材や工数）、テスト計画、品質目標、開発を行う組織や人員、等の重要な事柄はソフトウエアの開発計画書に書かれている事が多いです。ですので、これらの項目ががちゃんと開発計画書に書かれているかどうかを注意して確認します。
開発プロセスチェックの注意点・その３：開発委託先の管理
ソフト開発計画書の次に注意するのは開発委託先の管理です。ソフト開発監査は当社からソフトの開発を委託している相手先に対して行う第２者監査ですので、相手先は開発の元請会社になります。この元請会社が、当社から受託したソフト開発の全部や一部を、さらに別の会社に委託する（子請けや孫請け）という事も、ソフトの開発では良くある事です。このような場合には、その元請会社から子請けや孫請けの会社に対する開発管理と保守継続性の確認が大切になってきます。
まずはソフト開発監査を実施している元請会社で、社外にソフト開発を委託をする場合のルールが決まっているかどうかを確認します。ルールがあれば、そこに ①委託先の選定の方法 ②委託した業務の管理方法 ③委託先からの納入品の検収の基準 ④納入後の保守 についての規定が書いてあるかどうかを注意して確認します。ルールが無ければ、、、そんな会社にはソフト開発を委託したくは無いですね。
また最近ではOSSのソースコードが開発に使われる事も増えてきました。OSSの利用についてはライセンス条件の確認や品質状況の確認など、注意する項目が何点かあります。これらの注意点については当社からの要求仕様書等で開発委託先である元請会社には伝わっているはずですが、それと同じ内容を元請け会社から子請けや孫請けの会社にも確実に伝えるようなルールになっているか、も確認のポイントです。
そして、開発終了後の保守をどうするのかについても、開発委託をする場合のルールに記載があるか確認が必要な点です。ソフトは初版の出荷後も保守が続くので、子請けや孫請け会社が担当した部分についても元請会社が保守をできる体制でないと、出荷後の保守ができなくなってしまいます。
開発プロセスチェックの注意点・その４：ドキュメントの管理
開発委託先管理の次の注意点は、ドキュメントの管理です。ソフトの開発終了時に納品されるドキュメントに何が含まれるかは要求仕様書や契約書に明記されているはずです。それらのドキュメントは、納品されたソフトのバージョンに対応していないと困ります。
例えば、納品されたソフトに機能Ａのバージョン2.1 が含まれている場合には、機能Aに関する設計書やテスト報告書もバージョン2.1 に対応する物でないと、役に立ちません。ソフトの設計書や報告書は一般的に複数のバージョンがあるので、納入されたソフトとその元になったドキュメントのバージョンとの整合性を取るための仕組みが存在していて、ちゃんと運用されている事が大切です。
ソフト開発ではソースコードのバージョン管理はしっかりされています、というかソースコードのバージョン管理ができていないとソフトが出来上がらないので、ソースコードのバージョン管理が問題になる事は殆どありません。一方で、ソースコードの元になる設計書やテスト報告書などのドキュメントのバージョン管理は、開発リーダがしっかりと意識して実施していないと、正しく実施されていない場合もあります。
例えば良くある例が、開発終盤のデバッグ段階でソースコードに加えられた修正の内容が、対応する設計書の修正が間に合わなくてソースコードと設計書が対応していないという事態です。ソースコードがちゃんと修正されているので、テストも問題無くパスしてソフトとしては問題無いように見えます。ですが、リリースの数年後に市場で問題が発生してソフトを調査しようとした段階で、設計書の記述とソースコードの内容とが合っていないと、設計書を信じる事ができなくなりとても困った状況に陥ります。
その様な事にならないように、リリースされたソフトを構成するソースコードとドキュメントは、バージョンの整合性を維持する仕組みが必要です。ソフト開発の世界では、これは開発のベースラインと呼ばれる事もあります。厳密には、開発のベースラインには開発環境等他の要素も含まれるので少し違うのですが、ドキュメントとソースコードは開発のベースラインの主要な構成要素なので、開発のベースラインの維持の仕組みがあるかという観点で確認するという手もあります。
開発プロセスチェックの注意点・その５：保守体制の有無
開発プロセスチェックの最後の注意点は、当社から開発を委託したソフトに関する保守のサービスや体制です。ソフトはリリースの後には保守作業が発生します。保守作業とは少し言葉を追加すると保守サービスの提供です。ソフトの保守サービスには機能改善版のソフトの提供や不具合修正版のソフトの提供、問題が発生した時の調査や回避策の提示、ソフトを利用するための技術情報の提供、等様々な物があります。
保守サービスは、通常は製品出荷後一定期間例えば１年間は無償でサービスを提供し、無償期間が過ぎらた有償でサービスを提供するという形態をとる事が多いですね。そしてソフトを販売した会社がこの保守サービスを提供するためには、ソフトの開発を行っていた時と同様の開発用の機材や人員が必要になります。
ソフトの開発を他の会社に委託している場合には、委託先の会社でソフト保守サービスを提供する仕組みができていないと、顧客に対する保守サービスの提供が滞ってしまいます。ですので、ソフト開発監査でも、監査先の会社がどんな保守サービスを提供してくれるのか、有償期間や無償期間がどうなっているか、等について確認する事が大切です。開発が終わった後も、保守サービスの提供のために開発機材やチームを残しておいてくれるのか、それは何時までか、有償/無償の保守契約は結べるのか、等保守サービスに必要な仕組みの有無を確認します。
実はこれらの事は、取引基本契約や保守契約として明文化されているのが本来の姿なのですが、ハードの製造とソフトの開発を込みで他社に委託している場合には、ハードの保守については契約書に記載があっても、ソフトの保守に関する項目が漏れている事が多いので、監査で注意して確認しておくが良いです。
開発プロセスの次は要件管理の確認です
以上が開発プロセスについて監査をする時に、グータラ親父が注意していた点です。ソフト開発監査の作業はソフト監査チェックリストに従って１つ１つ具体的なルールと実際の作業を確認してくのですが、その確認作業を進める時に、どんな観点に注意していたかをまとめるとこれまでに説明した５つに集約されます。皆さんがソフト開発委託先を評価する時の参考になれば、幸いです。
それでは次の記事からは、ソフト開発監査で要件管理についての監査を行う時の注意点を紹介します。