ソフト開発監査では開発要件の把握力の良否を３番目に判定する
ソフト開発監査では開発技術の中でも要件把握の能力を３番目に判定します
ソフト開発監査では開発プロセスの品質とソフト開発技術力の良し悪しを評価します。ソフト開発技術はさらにテスト技術と要件把握と設計・実装３つの分野に分けて評価するので、全体では以下の４つの項目に分かれます。ソフト開発技術にはこれ以外にも様々な観点があるのですが、限られた時間で開発委託先の技術力を評価するために、ソフト開発監査ではこの３点に絞ってソフト開発技術の良し悪しを判断していました。この記事ではソフト開発監査で３番目に確認する開発技術のうちの要件把握能力の良し悪しを評価する方法を紹介します。
- 開発プロセス （ソフト開発に使っている開発プロセスは良好か？）
- 開発技術：テスト技術 （リリースまでに実施しているテストの技術力は十分か？）
- 開発技術：要件把握 （開発要件を具体化し委託元と共有する技術力は十分か？）
- 開発技術：設計・実装 （ソフトの設計と実装の組織としての能力は十分か？）
それでは、要件把握の能力についてどんな観点で何を確認しているのか順に紹介していきましょう。
３．開発技術・要件把握では委託元との要件の認識合わせの状況を確認する
ソフト開発監査では、開発プロセスとテスト技術力と要件把握力と設計・実装力の４つの観点で技量の良し悪しを確認していきます。この記事では、３つ目の要件把握力について、どんな観点で確認していくのかを紹介していきます。
ソフトの開発委託先の技術力としてまず第一に重要なのが、委託先から成果物の出口にあたるテストに関する技術です。そしてその次に重要なのは、委託先への委託業務の入り口にあたる要件把握の技術です。この要件把握の段階で委託元と委託先の認識にズレがあると、委託先がどれほどしっかりとソフトを作ったとしても、要求からズレたソフトになってしまいます。
開発要件の定義は委託元か委託先の少なくとも一方に技術力が必要
開発を委託するソフトの開発要件、言い換えると要求仕様の相互理解の問題ですので、委託元が要件を具体的に書き出してそれを委託先に具体的に説明するのが本来の姿です。しかし、要件の明確化というのもソフト開発技術が必要な領域で、委託元が常に要件の明確化について充分な技術を持っているとは限りません。その様な場合には、開発委託先が要件を具体化して明確に把握する技術力を持っていれば、それに救われます。しかし、委託元も委託先も開発要件の明確化の技術が未熟だと、出来上がったソフトのどこかに要件に関するズレが発生してしまう場合があります。
ソフトの開発を他社に委託する場合には、要件の具体化の技術に留まらず開発に必要なあらゆる技術分野において、委託元か委託先のどちらかがその技術を詳しく知っている必要があります。しかし、委託元も委託先もその技術に詳しくなければソフトが出来てきません。 別に難しい話ではなくて、開発に必要な技術を知らなければソフトはできないという単純な話しです。
要件把握の技術力は委託元と委託先の両方の認識を突き合わせて確認する
ちょっと話が逸れてしまいました、話を開発要件の具体化に戻しましょう。ソフトの開発を委託する社内の開発部門も、要件の具体化の技術力が高いチームもあれば低いチームもあります。開発の委託先もまた、要件の具体化の技術力が高い場合も低い場合もあります。ソフト開発監査の主な目的は開発委託先の力量の把握や改善なのですが、グータラ親父は開発要件に限っては、委託元である社内の開発部門と委託先との両方について要件管理の具体化の技術力を判定していました。
委託元も委託先も、要件管理の技術力が不足している場合には、よく注意して開発要件を確認するように開発プロジェクトを指導するためです。委託先が海外の場合には特に、あたりまえ品質と呼ばれる非機能要件についての重要性の認識が、国内と大きく異なる事もあるので、注意が必要なのですが、国内の会社への開発委託でもソフトの技術力は人に大きく依存するので安心はできません。
ソフト開発監査での要件管理の確認についての具体的な方法としては、監査の事前準備として、開発委託元と開発委託先に別個にお要件確認に関するチェックリスを送付して、そのチェックリストへの回答の記入を依頼しました。 チェックリストは、非機能要件に関する具体的な内容を確認する項目が並べてあります。委託元には自分達が求めている要件をできるだけ具体的に記載してもらい、委託先には自分達が理解している要件をできるだけ具体的に記載してもらいます。
両方からの回答を突き合わせれば本来なら合致しているはずですが、、、現実はなかなかそうも行かず委託元と委託先の認識にズレがある場合が稀に、時々、、いやわりと頻繁に、、、起きていました。。。
要件でズレが起きやすいのは安定性や異常回復性や保守性や堅牢性
実際にどんな要件について委託元と委託先とで認識のズレがでるのでしょうか？ 具体的には要件管理に関するチェックリストの説明のページに詳しく記載していますが、製品に関する要件でズレが起きやすいのは、おおまかに纏めると以下のような項目です。
- 安定性 ：どの程度の時間連続稼働できる必要があるか、１日か１週間か１年か？
- 異常回復性：エラー状態からの回復方針は自己リセットかオペレータ待ちかか？
- 保守性 ：不具合からの回復や原因調査のために必要な機能は？
- 堅牢性 ：ハード故障（例えばプログラムを記録するFROMの故障）の対策は必要か？
- セキュリティ：セキュリティのテストはどのような物が必要か？
どの項目も、開発の最初の段階で委託先と委託元で内容を検討して合意してあれば、委託先でソフトを設計・実装する上でそれほど難しい項目にはなりません。 しかし、要求仕様が不明確なまま、委託先が自分達の当り前品質に沿って設計・実装して、その内容が委託元の考えと違っていると、ソフトの基本構造（アーキテクチャ）の変更が必要な項目もあり、修正にはかなり時間が掛かってしまう場合が多いです。
製品そのものの要件では無く保守サービスの要件も確認が必要です
上の文章で製品に関する要件という言葉を使いましたが、製品以外の要件って何かあるのでしょうか？実は製品を提供するベンダは製品と同時にその製品に関する保守サービスも提供する必要があります。ハードウエアが故障したり、ソフトの機能改善版を提供したりバグ修正版を提供したりという、製品を市場で快適に使い続けて頂くための保守は、製品とは別に提供されるサービスです。サービスの提供は無償の場合も有償の場合もありますが、サービスの内容や提供方法を明確にしておく事はベンダの責任です。
ソフトの開発を他社に委託した場合には、自社がユーザに提供するソフトの保守サービスが実際に提供できるように、開発委託先とはソフトの保守に関して取決めや保守契約を締結しておく必要があります。具体的には、以下のような項目について、開発要件と同じタイミングで、委託先と委託元とで合意しておく必要があります。
- 保守サービスの内容：機能改善版や不具合修正版の提供、不具合原因の調査、等何を提供するか
- 保守サービスの価格：無償保守期間/有償保守期間の有無や有償期間の費用は？
- 責任分界点 ：市場で不具合が発生した時の責任分界点はどこ？
- 一次調査担当 ：責任分解点に沿ってどちらの責任かを調査するのは誰？
これらの保守サービスに関する要件も、開発の初期段階では忘れられている場合もあるので、製品に関する要件と同時にソフトウエア開発監査の中で確認いました。
ここまでで、委託先への入り口である要件と、委託先からの出口であるテストについての確認について紹介しましたので、次は開発委託先で入口と出口を繋ぐ実際のソフトウエア設計・実装に関する技術力についての確認項目の紹介です。