ソフト開発監査の目的その２：開発委託先のソフト開発能力を改善するための監査
ソフト開発の委託先の開発能力や品質保証力を改善するために行うのがソフト開発監査の２つ目の目的です
ソフト開発の委託先に対して行うソフト開発監査の３つの目的、①開発の力量を判定する ②開発の力量を改善する ③不具合対策版ソフトの品質を確保する のうち、①について前の記事で概要を紹介しました。この記事では２つ目の開発の力量つまり開発能力や品質保証力を改善するために行うソフト開発監査について紹介します。なお、実際のソフト開発監査についての具体的な紹介は、ソフト開発監査・実務 で始まるタイトルの記事にありますので、詳しい内容に興味のある方はそとらをご覧ください。
２．開発委託先のソフト開発の力量を改善したい
ソフト開発監査を実施する２つ目の目的は、既に委託先が決まっていて開発作業も開始されている状況での、委託先のソフト開発の力量の改善です。開発委託先からより良い成果物を納入してもらうために、今の時点での開発プロセスやプロダクト品質に問題が無いかどうかを調べて、問題点があれ納品までに対策を行って改善してもらう事を目的に、ソフト開発監査を行います。
この場合の開発監査は、時期としては開発が半分程度進んだ時期で、まだシステムテストが開始されていない時期に実施する事が多いです。 開発が半分程度進んだ時期が、具体的な問題点を洗い出しやすく、かつ問題点の改善を実施してもらうだけの日程的な余裕が残っているからです。開発を開始して間もない時期では、実務があまり進んでいないので具体的な成果物ができていない場合も多く、開発チームの実体が把握しずらいです。逆に納品の直前では、例え問題点が見つかっても対策を実施してもらう時間が残っていません。
ソフト開発の成果物を見ながらプロセス品質やプロダクト品質の問題点を洗い出し、最終の納品日までにその対策を実施してもらうには、開発が半分程度進んだ時期にソフト開発監査を行うのが一番効率が良いので、その様な時期に監査を行います。
ソフト開発の力量の改善はいくつかの観点で問題点を洗い出し対策を進める
ソフト開発の力量の改善を目的とした監査でも、ソフト開発監査に使うチェックリストは委託先を選定するための開発監査の時に使うチェックリストを同じ物です。同じチェックリストを使いますが、力量の改善を目的としたソフト開発監査ではソフトのプロダクト品質に影響の多い部分について、問題点が無いかを確認する事に重点を置くので、以下のような観点に重点を置いてチェックリストによる確認を行います。
- テストレベル：テスト設計やテストの管理は充分か
- バグ管理：バグやレビューの指摘事項は管理はできているか
- 開発要件：要件は委託元と委託先とで意識が合っているか
- ゲートプロセス：主要なゲートプロセスが存在して効果的に実施されているか
- 納品物：詳細なテスト報告とバグ情報は納品物に入っているか
テストの量と質のレベルは十分か
開発委託先からより良いソフト成果物を納品してもらうために、何に一番注意するのが良いかと言うと、やはり一番直接的で重要な事は、良いテストを実施してもらう事です。もちろん、良い設計や良いレビューなどの上流工程での品質良い開発も大切なのですが、複雑さを増すソフトでは机上検討だけでバグを洗い出す事は不可能です。ソフトの品質を保証するには、充分な量と質のテストを実施する事が一番大切です。ソフト開発監査で、テストの量や質に不足が見つかれば、納品までにそれらを対策してもらいます。
では、テストの量と質が充分なの不足しているのかどうして見分ければ良いのでしょうか？ まず真っ先に確認するのは、テスト計画です。 リリースまでに、どんな部署でどんな種類のテストをどの程度の量実施する事となっているのかを、テスト計画書等で確認します。どんな種類のテストを実施しているのか、例えば異常系のテストや高負荷でのテストや大規模環境でのテストなど、非機能要件を確認するテスト項目が計画されているのかといった視点でテスト計画を確認します。
特に海外にソフトの開発を委託する場合には、このテストの種類（テストカテゴリーと呼ぶ事も多いです）は注意が必要です。ソフト開発経験の少ない若いエンジニアだけで開発チームが構成されている場合などは、テストの目的を仕様書に記載された機能の動作確認だけと誤解してしまっている場合もあります。そのような場合には、各機能の正常系の動作確認をするテスト項目は有りますが、異常系や高負荷でのテスト等がテスト項目に全く入っていないという事も有り得ます。
テストの量については、一律にどの程度が良いのかは判断し難いのですが、自社で開発経験のある類似の製品の場合と比較して同程度のテスト項目数になっているかどうかを、一つの判断基準として使う事もできます。
テスト管理はできているか
テストの量と質に加えてテスト管理の状況の確認も大切です。計画されたテストがちゃんと実施されていて結果が記録として残され、その結果の良否を判定する仕組みとなっているのか、という観点での確認が必要です。テストの実行管理の体制や責任分担がしっかりと出来ていないと、開発終盤になって残り時間が少なくなった時に、テスト工程に乱れが出る、とうような事が起こるリスクが増えます。
テスト管理については、どんなツールを使って管理しているのか、どんなタイイングが誰が、どんな項目を確認して管理をしているのか、できるだけ実例や実際の記録に沿って確認すると、問題点が見えやすくなります。
バグ管理は確実に実施されているか
テストや設計レビューは実施する事が重要なのではなく、それらの活動で発見されたバグや指摘事項を修正して潜在バグを減らす事が重要です。潜在バグを減らすためには、検出されたバグや指摘事項をしっかりと記録して対処が終わるまでトレースができているかどうか、というバグ管理のプロセスについての確認も大切です。
テストで見つかったバグや設計レビューの指摘事項は、どんな方法で記録されているのか、どんなステータス管理が行われていて、誰がどんなタイミングでトレースをしているのか、どんな状態になったら終了と判断しているのか。テスト管理のプロセスと、管理の作業を進める上での判断基準が明確になっているか、等の観点でバグ管理の状況を確認していきます。
バグ管理のツールとして、EXCELのような表を使っている場合もあれば、チケットシステム等の統合管理システムを使っている場合もあります。どんなツールを使っているかは開発委託先にも色々と事情があるので様々です。ですがどんなツールを使っていようとも、そのツールを使ったバグ管理の運用が着実に実行されていないと、折角見つけたバグが対策までたどり着けずに忘れ去られてしまうなど問題が起こり得ます。 そのような事が起きないような開発プロセスができているか、という事もソフトウエア開発監査での重要な確認項目です。
開発要件は委託元と委託先とで意識が合っているか
ソフトの開発委託では、開発するソフトに求められる機能や性能や安定性などの開発要件を委託元から委託先に間違いなく伝える事がとても大切です。そのために、要件を具体的に記載したソフトの開発要件書を委託先が準備したり、開発する内容を具体的に記載した開発仕様書を委託元が作成したりして、なんらかのドキュメントをベースにして委託元と委託先が意識合わせを行います。
この時に開発要件書や開発仕様書に書かれている事は、双方の技術者が議論して確認するので、意識がズレ事はあまり起こりません。ではソフト開発監査では何に注意するのでしょうか？ 実は、開発要件書や開発仕様書に書かれている事に不足は無いかという点に注意して監査を行います。
海外のように、業務の委託/受託という仕事の仕方に慣れている組織の場合は大丈夫なのですが、自社でソフト開発をしていた組織の場合には、開発要件書や開発仕様書に機能と性能以外の要件が充分に書かれていないという場合が起きる事があります。例えば、障害回復性、保守性、安定性、セキュリティ というような、非機能要件と呼ばれる項目が開発要件書や開発仕様書に具体的に書かれているか？ という確認してみると、案外具体性が無かったりします。自社で開発している場合には、これらの非機能要件が明確に書かれていなくても、これまでの経験等から問題無く開発が進む場合もよくあります。しかし、他者に開発を委託する場合には、明確に書いてないとうまく伝わりません。
場合によっては、監査を行う前にこれらの非機能要件について委託元と委託先とに別々に具体的な項目についてのヒアリングを行っておき、両者からの回答に差異があった箇所について監査当日に詳しく確認する、という方法でソフト監査を進める事もあります。
特に、初めて開発を委託する会社の場合には、非機能要件に関する厳しさのレベルというか、その会社にとっての当り前品質のレベルが判っていない場合が多いです。その様な時には、要求仕様の非機能要件に関してできるだけ具体的に確認しておかないと、委託元と委託先との認識にズレが生じてしまい、出来上がったソフトが要求していた物とどこか違ってしまう・・・というリスクが残ります。
開発のゲートプロセスは明確になっているか
ゲートプロセスとは、ソフト開発のプロセスの中でも重要なプロセスです。責任者による承認が無いと次のプロセスに進めないような、ゲ―トキーパーの役割を持つプロセスをゲートプロセスと呼びます。何をゲートプロセスにするかは、会社によって様々ですが、例えばソフトのリリース審査は会社としてのソフトリリースの最終段階での重要なゲートプロセスです。これ以外にも、要求仕様の作成部門が設計部門に要求仕様を伝えるためのインプット審査や、設計部門での開発終了段階で成果物を確認するアウトプット審査等も、ゲートプロセスに採用される事も多いです。
開発プロセスの中からどれをゲートプロセスに位置づけるかというゲートプロセスの選定に加えて、ゲートプロセスの実施状況がちゃんと監視されているか、ゲートプロセスの承認無しに後のプロセスが開始されていないか、等の開発管理の状況は、開発プロセスの品質に影響を与える箇所でもあり、同時にソフトウエアのプロダクト品質にも大きく影響を与える項目です。
納品物は適切に決められているか
ソフト開発を委託した場合の納品物としては、設計書やソースコードやテスト報告書などが一般的です。しかし、これだけで充分でしょうか？自社でソフトを開発した時にや、これら以外にも多くの情報が残されていて、それらの情報がそれ以降のソフト開発で利用される事もあります。
そのような観点から言えばい、設計レビューの記録やコードレビューの記録、社内テストで検出された全てのバグに関する詳細な情報等も納品物として提供を受けておいた方が良い物があります。ソフト開発監査の場で確認する項目ではなく、むしろ業務委託の契約書や要求仕様書の納品物の欄で明確にしておく方が良い内容です。しかし残念ながら、ソフトの開発委託ではそこまできっちりと記載された契約書や要求仕様書が存在しない場合お多いので、ソフト開発監査の中で確認すると、案外漏れている事が多いです。
問題点が見つかったら優先順位を付けて対策をお願いする
開発委託先の開発能力を改善する事を目的にソフト開発監査を実施する時には、これまで述べてきたような重要な項目を意識しながら、委託先の開発プロセスの問題点を洗い出します。もちろん、問題点を洗い出すのが目的ではなく、問題点について改善を実施してもらい自社に納品するソフトの品質を良くしてもらう事が目的です。
ですので、ソフト開発監査で見つけた問題点については対策を立案してもらい、その対策をソフトのリリースの時までに実施してもらうという、フォローアップ活動があって初めて効果を発揮します。言い方を変えると、委託先の開発能力の改善を目的としてソフト開発監査を実施するのならば、発見した問題点に対する改善対策の効果の確認までちゃんとフォローアップしないと、監査の目的を達成した事にならないので注意が必要です。ですので、開発委託先の力量改善を目的としてソフト開発監査を行う場合には、監査での問題点の洗い出しとともに、監査の後の改善対策の着実な実施といるフォローアップもまた大事な活動となります。