ソフト開発監査の監査当日（８）要件管理のチェックのポイント
要件管理は開発委託先と開発委託元とで認識があっているかを確認します
この記事では前の記事に続いてソフト開発監査の４つのチェックリストのうち２つ目の、要件管理のチェックリストについて、チェックリストを使って監査を行う時のポイントを紹介します。開発プロセスのチェックリストと同じように、各々のチェック項目については ソフト監査実務・チェックリストその８：開発技術・要件管理（管理全般）ソフト監査実務・チェックリストその８：開発技術・要件管理（管理全般） の記事で紹介していますので、具体的な項目に興味のある方は先にそちらの記事をご覧ください。
以下にチェックリストの例を載せてありますので、こちらも見ながら記事をご覧ください。
（クリックするとpdf が開きます）
要件管理のチェックリストは他の３つとは目的が違います
ソフト開発監査のチェックリストの中で要件管理のチェックリストは、他の３つとは目的が少し違います。他の３つのチェックリストは監査先の会社のソフト開発の力量を把握する事が目的です。要件管理についても、監査先の会社の要求仕様を把握する力量（要件管理力）を把握するという目的もあるのですが、それよりも優先度の高い目的があります。それは、当社と開発委託先とで要求仕様ついての認識が合っているか（要件管理がちゃんとできているか）を確認するという物です。
そんな事は、ソフト開発監査で実施する事ではなく開発を委託する自社の設計部門が開発委託先と実施する内容だろう！ と言われそうですが、、、はい全くそのと～りです。そのと～りなのですが、開発委託先が海外の場合には、非機能要件についてよく確認しておかないと双方の認識にズレが出てしまう事が良く起こります。このあたりは、海外の会社へのソフト開発委託に慣れている組織なら問題無いのですが、グータラ親父の務めていた組織はあまり経験が無かったので結構認識のずれが有って苦労しました。
そのためにソフト開発監査の確認項目に要求仕様書という項目を入れ込んであります。海外の会社へのソフト開発委託に慣れている人は、この部分は読み飛ばして頂くのが良いのですが、そうでも無い人はそんな事もあるのか～程度に読んでもらうと良いと思います。
なぜ海外の会社とは要求仕様の認識にズレが出るの？
少し横道に入ってしまいますが、なぜ海外の会社とは要求仕様書の非機能要件についての認識にズレが出るのでしょうか？ それは、製品が使われる環境が国によって・地域によって様々なので、「こんな使い方が当然でしょう」という製品の利用方法についての常識にズレがあるからです。
グータラ親父が経験した判り易い実例を１つ紹介しましょう。もう数年前になりますが、モデム端末の開発・製造を委託している海外の会社にソフト開発監査に行った時の事です。テストの内容について確認している時に、モデム端末の安定性を確認するための長時間通電試験の仕様について確認をしていました。通電による安定性確認の試験にもさまざまな加速条件を組み合わせた実施方法がありますが、一番簡単なのは通常の利用状態で１週間とか１ヶ月とか通電し続ける試験です。
当時のグータラ親父は、最低でも通電試験は７日間程度は必要と自分なりの判定基準を決めて、ソフト開発監査を進めていました。ところが、７日間の通電試験の必用性について監査先の会社のテストリーダもソフトの開発リーダも、全く理解してくれません。「なぜそんなテストが必要なのか？」と何度も何度も聞いてくるのです。
それまでの監査チェックリストの確認のやりとりを通して、彼らが決してテストやソフト開発の技量が低い訳ではない事は判っています。自分達の製品をよくするためであれば、他人の意見も積極的に取り入れようとするなど、向上心が強い事も知っています。そんな彼らが７日間の通電試験の必要性について理解してくれなくて、10分以上も議論をしていました。議論をしながらグータラ親父は、何かおかしい・何かズレているという感覚があったのですが、言葉の壁もありそのズレはなかなか見つかりませんでした。
しかし、あるタイミングで開発リーダが「モデムは使う時に電源を入れて使い終わったら電源を切るだろう、このモデムは個人が自宅で使う事を想定した製品なので、１日以上電源を入れてる様な使い方は無くて毎回起動処理から開始されるのだから、長時間の通電試験なんて意味が無いじゃない？」 と言いました。グータラ親父としては、「えっ？？？」と言葉を失いました。
当たり前品質は国によって変わる
そうなのです、日本ではその当時はもうインターネットの常時接続が普通になっていて、モデムは設置時に電源を入れたらあとはほったらかしで、24時間365日部屋の片隅で普通に安定して動き続けるという使い方がごく普通のものでした。そのような使い方が常識となっているので、電源を入れて数日でハングするような製品はそもそも製品として認められません。一旦電源を入れたらずっと安定して動き続ける事が、モデムという製品が持っていて当然とだれもが考えている常識的な品質です。品質の世界では「あたりまえ品質」と呼ばれる領域です。
でも、日本でも少し時代を遡れば従量制の通信の時代があって、その時はパソコンもモデムも「使う時だけ電源を入れて、使い終わったら電源を切る」のが当然だったのです。その様な場合の「あたりまえ前品質」は電源をいれてから電源を切るまでの数時間安定して動き続ける、なのです。そして、その時の開発委託先の国の通信事情はまさにその状況だったのです。
つまり、テストリーダや開発リーダの言っている事はその国のモデムの利用環境では正しくて、グータラ親父の言っている事は日本のモデムの利用環境では正しかったのです。どちらも、相手の国の通信事情に思いが至らず、自分達の常識で判断して最適な解答を探っていたので、10分議論しても平行線を辿っていたのです。
判ってしまえばたわいもない笑い話なのですが、誰でも自分の生きている世界の常識という枠で物事を考えるという癖がついています。そして、困った事に常識的な事は相当意識しないとわざわざ仕様書に書き出す事はしません。ここに、要求仕様の認識の落とし穴がポッカリと口を開けていることが時々あります。
そんな事があったので、その後にソフト開発監査のチェックリストに要件管理のチェックリストを追加して、主に非機能要件についての認識のズレが無いかの確認をする事にしました。
要件管理のチェックリストの使い方
横道が随分長くなってしまいましたが、要求仕様の確認のためのチェックリストの目的は判って頂けたかと思います。要するに、その製品が使われる市場での当たり前品質が、非機能要件として明確に要求仕様書に書かれていて、その内容について当社と開発委託先とで認識が合っているかどうか、を確認するのが要件管理のチェックリストの目的です。
という事は、大前提として当社開発委託元の部門が作った要求仕様書等に非機能要件がちゃんと書きだされている事が必要です。そこに書かれている非機能要件について、当社と開発委託先との認識が合っている事を順番に確認していく事になります。なるのですが、なっていてほしいのですが、なっていたらいーな、、、、なってないやん！！！
残念ながら、グータラ親父の務めていた会社では、海外の会社へのソフトの開発委託の経験が少なかったので、非機能要件の書き出しが不十分な場合がよく有りました。これでは、要求仕様書に書かれている項目をベースに相互の意識のズレを確認するという方法が採れません。
仕方が無いので、要求資料のチェックリストでは、非機能要件で具体化を忘れそうな項目をリストアップしておき、監査の準備段階でチェックリストを監査対象の会社に送るのと同時に、開発委託元である自社の開発部門にも送りつけて、双方にチェクリストの項目についてのそれぞれの認識を記載して貰う事にしました。
自社の開発部門には、チェックリストの項目について「どんな仕様で製品が出来上がって来る事を想定しているか」を書いてもいらい、開発委託先には「どんな仕様で製品を作る予定か」を書いて貰いました。両方から提出された内容を逐一見比べて、認識の差異がある部分を洗い出すという方法で、非機能要件の項目の漏れや認識のズレを確認するというやり方をしていました。
要件管理のチェックリストを使った要求仕様のチェックの注意点
これまでの説明でもお判りのように、要件管理のチェックリストを使った確認では、自社の開発委託元部門に書いてもらった内容と開発委託先に書いてもらった内容とを見比べて、双方に認識の違いが無いかを確認していきます。
当社から提供している要求仕様書に記載してある項目については、開発委託先がその項目をどの様に実装するのか、どのようなテストで確認するのかを説明して貰います。説明の内容と要求仕様書に書いてある内容とを比べて、開発委託先が当社の要求仕様を正しく理解しているかどうかを確認します。
要求仕様書を書いたソフトエンジニアは自社の開発委託元の人なので、その文章を読めばどの様な事を要求しているのかを理解するのは、同じ会社の社員である監査員にとってはそれほど難しい事ではありません。しかし、開発委託先の会社のエンジニアは、異なる常識を元にその内容を誤解しているかもしれません。ですので、具体的な実装やテストの内容を聞いて、その内容が要求仕様書の内容とズレていないかを確認します。
当社から提供している要求仕様書に記載されていない項目については、仕様が具体的に開発委託先には伝わっていない可能性もあります、というか殆どの場合ちゃんと伝わっていません。その様な場合は、開発委託の契約の形態にも寄りますが、開発委託先が自社の基準で実装を進めてくれている事が多いです。この場合、開発委託元が期待している仕様と開発委託先が実装している仕様にズレがある場合があるので、その確認が必要です。
１つ１つの要求仕様についてできるだけ具体的に確認してみる
まずは開発委託部門が監査チェックリストに記載した内容を、できるだけ具体的に開発委託先に説明します。そして、この様な仕様を開発委託元が要求しているが開発委託先の実装内容と認識のズレは無いですか？ と質問します。もし、何等かの認識のズレがありそうなら、その項目について開発委託元とよく検討して認識のズレを無くすように依頼します。
要求仕様書には、機能要件と非機能要件が記載されているのですが、機能要件に記載が漏れている事は殆どありません。 しかし非機能要件には、性能や安定性、異常回復性、保守性、高負荷耐性、保守性、可用性 等いくつかの小分類があり、これらは記載が漏れている場合もあります。 記載が漏れている項目についての認識が合っていないと、製品となるソフトウエアが完成してからいろいろと問題が起きます。 ソフトウエア開発監査の目的とは微妙に違うのですが、監査の時点でできるだけ仕様の認識ズレを無くしておく事も重要な事です。
要件管理の次はテスト技術の確認です
以上が要件管理について監査をする時に、グータラ親父が注意していた点です。ソフト開発監査の作業はソフト監査チェックリストに従って１つ１つ具体的なルールと実際の作業を確認してくのですが、その確認作業を進める時に、どんな観点に注意していたかをまとめるています。皆さんがソフト開発委託先を評価する時の参考になれば、幸いです。
それでは次の記事では、ソフト開発監査でテスト技術についての監査を行う時の注意点を紹介します。