ICTソリューション総合誌　月刊ビジネスコミュニケーション

ホーム >  要求工学 >  2008年10月号 >  第48回：要求モデリングと誤り

今回は要求モデリングと誤り検出の関係について、まず米国標準技術局のデータに基づいて修正コストの観点から議論する。次いで要求誤りを抑止するという観点から、共通フレームワークのV字型開発モデルの限界についても議論し、新たな開発モデルが必要になることを示そう。また、多くの開発現場で起こりうるようなシステム開発の課題と要求モデリングの関係についても考察したい。

誤りの構造

まず、誤りの構造を復習しておこう。

◆誤り（error）

誤りには、知識の誤りと行為の誤りがある。行為が正しくても知識が間違っていれば、要求には欠陥が生じる。これに対して、正しい知識に基づいているが、正しくない行為によって作成された要求にもやはり欠陥が生じる。知識も行為も誤っていれば、欠陥が生じるのは当然である。

◆欠陥（defect）

知識や行為の誤りによって、文書やコードに現れる正しくない記述を欠陥という。

◆失敗（failure）

欠陥に基づいて発生した望ましくない結果を失敗という。文書の欠陥は、その文書を用いて作成された文書のレビュやコードの動作時に望ましくない結果をもたらす。コードの欠陥は、システムの実行時に望ましくない結果をもたらす。

誤り検出の問題点

米国標準技術局（NIST）では、システム開発における誤りの発生と検出について、次のようなデータを報告している[1]。

• 要求定義からシステム設計、アーキテクチャ設計、コンポーネントソフトウェア設計、製造までの上流工程で発生する誤りはシステム開発全体の約70％である。これに対して、上流工程で検出される誤りは約3.5%に過ぎない。
• 単体試験で発生する誤りは約20%である。単体試験で検出される誤りは約16%である。
• 結合試験で発生する誤りは約10%である。結合試験で検出される誤りは約50.5％である。
• 受入試験で発生する誤りは0%である。受入試験で検出される誤りは約９％である。
• サービス開始後に検出される誤りは約21％である。

この結果を図示すると図１と図２のようになる。図１では工程ごとの誤りの発生件数を比較している。図２では工程ごとの誤りの検出件数を比較している。受入試験とサービス開始後には誤りが発生していないが、検出件数の比率は大きいことがわかる。

ここで、上流工程、単体試験工程、結合試験工程、システム試験工程、サービス開始後の誤り修正コストの比をたとえば1：5：10：15：30とすると現状の誤り修正コストは次のようになるだろう。

3.5×1＋16×5＋50.5×10＋9×15＋20.5×30＝1338.5

これに対して、誤りを発生した工程で検出して修正できるとすれば、修正コストは次のようになるはずだ。

70×1＋20×5＋10×10＋0×15＋0×30＝270

両者を比較すると、約4.96倍の差があることになる。逆に言えば上流工程の誤りをきちんと除去できると、試験コストを理想的には５分の１にできることをNISTのデータは示していることになる。

実際にはそこまでは無理だとは思うがもし試験コストを半分にできれば、試験工程の工数が開発工数全体の50％だとすると約25％の開発工数を削減できることになるから、これは大きい。

では、上流でどのようにして誤り検出効率を向上するか、そのためにどんな手法が必要となり、その手法の教育にどれだけの経費が必要になるかということが次の課題になる。

システム開発のV字モデル

ところで共通フレーム2007にあるように、要件定義や設計とテストの関係をV字モデルで明確にすることが求められている。たとえばV字モデルでは、企画した内容が運用に入って事業の観点から、要件定義は正しかったかどうかを確認するとしている。また、システム仕様の正しさはシステム試験で確認する。ところが図３に示したように、この方法では要求モデルの誤りを受入試験まで持ち越すことになりかねない。前述したNISTのデータで示されるように上流工程の誤りを試験工程で検出修正するアプローチでは、仕様の責任者を明確にするということはあるかもしれないが、システム開発コストを削減する上では限界があることが分かる。

このようにV字モデルには、要求モデルは要件定義工程で確定できるという暗黙の前提がある。もし要求モデルが確定できているなら、そこに誤りはないことになる。だから受入試験で検出される誤りは要求の実現誤りだけということになる。しかし現実の開発プロジェクトでは、要求誤りが後続工程で検出されることなく受入試験まで持ち越されていく。受入試験で検出された要求誤りを修正すると、それに続くすべての工程を再度繰り返すことになる。この問題を解決するには、要求誤りを可能な限り受入試験以前、とくに上流工程の中で検出して修正する必要がある。

動的V字モデル

それではどうしたらいいかといえば、先行工程が完了して後続工程に入った段階で先行工程の生産物を評価するのである。これによって、先行工程で発生した誤りを可能な限り早期に検出し修正することができる。図４に示したように、工程間の境界ごとに前工程の生産物を段階的に見直すのである。このような開発モデルを動的V字モデルと名づけよう。

たとえば、システム要件定義の段階で検出された要求モデルの誤りは、修正されて新しい要求モデルが作成される。システム方式設計で検出されたシステムモデルの誤りは、修正されて新しいシステムモデルが作成される。このシステムモデルを用いて再び要求モデルが改訂される。このようにして新たな後続モデルが作成される度に、先行して作成されたモデルの誤りを検出する。したがって、開発工程の各段階で最新かつ正確なモデルから試験項目を作成することができる。誤りが混入されたままの状態で試験項目を作成しても正しい試験を実施することはできないであろう。

この考察から言えることは、要求モデルはシステム開発工程全体にわたって管理する必要があるということだ。

動的V字モデルは、一見すると繰り返し上流生産物を修正することになるのでコストが増加するように思われるかもしれないが、緊密に確認を繰り返すことで修正量は段階的に削減されていくはずである。ドキュメントの誤りが発生するごとに、可能な限りすばやく修正する方がコードを作成してから試験によって誤りを検出して修正するよりも経済的である。

ところで、このような動的V字モデルを実践するためには、比較可能で試験可能な要求モデルを作成する必要がある。この理由は、もしシステムモデルやアーキテクチャモデルと比較できなければ、誤りを検出できないからである。また試験できなければ、受入試験項目を作成できないからである。

この動的V字モデルに対して、従来のV字モデルを静的V字モデルと呼ぼう。静的V字モデルでは要求モデルを要求定義工程で完全に正しく確定できると仮定しており、後続工程では修正されることはないとしている。しかし、現実のシステム開発で静的V字モデルのこの前提を守ることは難しい。一方動的V字モデルでは開発工程の進行に従って要求モデルが改訂されていく。現実的には要求モデルの完全性が最初から低ければ、開発過程で正しく改訂し続けていくことも難しい。したがって、やはり要求定義工程では可能な限り、誤りを検出して完全性の高い要求モデルを作成し、もし後続工程で誤りを検出したらきちんと要求モデルを修正するというアプローチが必要になる。

システム開発の問題

システム開発では、以下のような事態に遭遇することが多いのではないだろうか。

［P1］サービス開始を急ぎたいので、開発期間が充分に確保できない。

［P2］監督官庁からサービスの認可を受けるため、サービス内容を確定するまで時間がかかるだけでなく、途中で内容が変わることもあり、要求確定が遅くなる。

［P3］業務約款のような文書類を、システム要件に落とす場合に抜け・漏れがある。業務専門文書読解力と、システム実現方式の両方を熟知した人間が必要になる。

［P4］システム要件が大体決まってきてから、実開発（設計工程）を立ち上げるまでの重要工程に、スキルフルな社員が足りない。

［P5］要件定義漏れや設計ミスなどを試験工程で見抜けず、本番トラブルが発生してしまう。

以下では、これらの問題と動的V字モデルの関係について考えてみよう。

［P1］サービス開始を急ぎたいので、開発期間が充分に確保できない。

■考え方

開発期間が短縮できない最大の原因をつぶす必要がある。たとえば、前述した動的V字モデルを採用して試験修正工数全体を削減することが考えられる。そうすれば要求モデルに基づいて試験項目を作成できるだけでなく、上流工程での欠陥発見効率も向上できる。

これにより試験工程での欠陥修正工数を削減することができるだろう。

［P2］監督官庁からサービスの認可を受けるため、サービス内容を確定するまで時間がかかるだけでなく、途中で内容が変わることもあり、要求確定が遅くなる。

■考え方

サービス内容を確定するまでが遅くなることは、監督官庁の手続きであるから避けられないことである。したがってサービス内容の変更を想定して対処するしかない。たとえば、アクタと横断的関心事の観点から、内容を分割整理しておくことにより、変更の影響を可能な限り限定することなどが考えられる。

また動的V字モデルを用いて要求モデル、システムモデル、アーキテクチャモデル、ソフトウェアとの緊密な対応関係が管理できていれば、要求モデルの変更の影響範囲を容易に限定できると思われる。要求確定が遅くなったとしても、後工程のモデルとの関係が明確になっていれば開発の手戻りを抑制できるだろう。

［P3］業務約款のような文書類を、システム要件に落とす場合に抜け・漏れがある。業務専門文書読解力と、システム実現方式（アーキテクチャ）の両方を熟知した人間が必要になる。

■考え方

両方を熟知した人間を育成するためには、業務約款制度とシステム要件との対応関係を識別・整理することにより、知識をまず可視化して共有可能にする必要がある。

たとえば、保険約款制度に登場するアクタ（観測対象としての関係者）とそのイベント（観測事象）を体系的に整理する。次いで、システムの機能とそれがもたらすアクタへの効果をアクタとイベントに対応付けて網羅的に整理することができる。

この問題も、要求モデルとシステムモデルとの一貫性が管理されていれば自然に解決できると思われる。したがって動的V字モデルを実践することで、業務知識に対応する要求モデルとシステムモデルとの対応関係を確認していく過程で習得できるようになると考えられる。

［P4］システム要件が大体決まってきてから、実開発（設計工程）を立ち上げるまでの重要工程に、スキルフルな社員が足りない。

■考え方

システム開発のマネジメントでは「反省」が重要である。反省するという言葉の意味は、「振り返って省くこと」だそうである。開発作業の中で、「事後分析の文化」を醸成する必要がある。事後分析の文化とは何かといえば、前工程を次工程で振り返り誤りを省くことである。つまり動的V字モデルを実践することだ。この過程で蓄積された前工程と次工程の対応関係に関する知識を、ベストプラクティスとして共有することができるだろう。知識が蓄積されれば、必要なスキルを識別してスキル認定していくことも考えられるようになる。

「システム要件に対してこの設計でよいか」を確かめる３つの問いを紹介しよう。

• ◆的確であるか
• ◆簡潔であるか
• ◆洗練されているか

これらの問いを開発の中で投げかけ続けることで、良い設計を実践できる経験を社員が習得できるのではないだろうか。

［P5］要件定義漏れや設計ミスなどを試験工程で見抜けず、本番トラブルが発生してしまう。

■考え方

すでに見たように、上流の誤りを試験工程だけで堅守しようとするところにまず無理がある。動的V字モデルを活用することが有効だろう。

しかし、要件定義不足、技術者経験・スキル不足、短期開発、ソフト開発社管理不足など様々の問題を一度に解決することはできない。最も上流の要件定義プロセスから改善に取り組む必要がある。

---

要件定義が明確になれば、開発管理が明確にできる。誤りを事前に検出できるようになれば、要件漏れや設計ミスを軽減でき、本番トラブルを抑制できるだけでなく、短期開発も可能になると考えられる。プロセスが明確になれば技術者もスキルを容易に習熟できるようになる。

このようにして上流から段階的な開発プロセスの改善に取り組む必要がある。

モデル調達

最近、モデル調達という新しいソフトウェアの調達プロセスがボーイングやハネウェル、エアバスといった航空機産業のソフトウェア調達で2010年代の実用化を目指して議論が進んでいる。

モデル調達の概略はこういうことである。

システムインテグレータが製品仕様に対して、仮想部品リポジトリ内にある仮想コンポーネントを用いてシステムアーキテクチャを作成する。ここで、ボーイングなどの航空機製造事業者がシステムインテグレータである。

システムインテグレータは、システムを構成する部品仕様を部品供給事業者に提示して、部品供給者が作成した部品モデルをシステムに仮想統合する。このとき部品供給者は、システムインテグレータが指定した仮想コンポーネントを用いて部品モデルを作成する。この仮想統合に適合した部品モデルに対して、システムインテグレータが部品を部品供給者に発注する。

航空機産業の場合には、仮想コンポーネントといっても物理的なデバイスや製品が対応しているので、モデル化しやすいといえるかもしれない。

モデル調達によって、あらかじめ良い部品モデルを提示できた部品サプライヤだけが開発できるというわけだ。仮想統合によってテストがなくなることはないと思うが、テスト効率が向上することは間違いない。

航空機向けソフトウェア開発と違ってエンタープライズ系のソフトウェアの場合には、共通的なソフトウェア部品をリポジトリとして流通させるのは必ずしも容易でない面があるかもしれない。しかし2020年代には、エンタープライズ系もSaaSを活用したシステム構築が普及して、モデル調達が主流になっているかもしれない。

まとめ

今回は要求モデリングについて主に誤り検出とその効果という側面から議論した。要求モデルを作成すればいいというものではない。作成した要求モデルをどんな目的のために使うかということだ。今回は要求モデルに基づいてシステム設計を評価したり、受入試験項目を作成するという立場で話題を提供した。もちろん要求モデリングの用途の一つに、設計のための下書きという場合もあることは認識しているし、それを否定しているわけではない。

そうはいってもシステム開発現場の多くでは、可能な限り正確で望ましい要求をきちんと管理していくことが、システム開発を成功させることにつながるのではないかと期待している。またそういう要求モデルが数多く流通することで、モデル調達のような新たなシステム開発方式が登場する可能性も見えてきたのである。

さて連載第48回目ということで、この連載も4周年になる。これも読者の皆様のご支援のおかげである。これからも要求工学の展開と産業界への浸透に向けて努力していきたい。

 

---

■参考文献

• [1] NIST, Planning report 02-3, The Economic Impact of Inadequate Infrastructure for Software Testing, May 2002
• [2] ソフトウェアエンジニアリングセンター編，経営者が参画する要求品質の確保，SEC BOOK,2005
• [3] ソフトウェアエンジニアリングセンター編，共通フレーム2007～経営者，業務部門が参画するシステム開発および取引のために，SEC BOOK, 2007