派生開発プロセスの工夫(その16)

品質確保に効果のあった派生開発プロセスの工夫#16

掲題の派生開発プロセスに関する、シリーズ・エントリです。
派生開発の設計品質確保について問題意識を持たれている方は、ご一読頂けると幸いです。
レポートの要約、および背景については第一回を参照ください。

エントリ内容の目次

まずはこのレポートの主旨について述べた後、一般的な派生開発の現状を俯瞰する。その後、派生開発プロセスの1つであるXDDPと、当方の開発プロセスの工夫についての概要を述べる。

時間のない場合は、ここまでの内容(1部 レポート・サマリー)だけでも、本論述の概要はつかめると考える。その次の2部から、詳細なレポート内容を述べていく。

もちろん2部から読み始めても構わない。そちらのほうが、概要説明ではなく詳細な論述を行っているため、理解しやすい可能性がある。1部はサマリーのみであり、詳細情報は把握できないだろう。

(1)このレポートの概要と背景について
   ⇒記事はこちら

1部 レポート・サマリー------------
(2)派生開発を巡る現状
   ⇒Part1
   ⇒Part2

(3)XDDPでの問題提起と解決策の概要
   ⇒記事はこちら

(4)当方が遭遇した派生開発の問題と解決策の概要
   ⇒記事はこちら

2部 レポートの詳細--------------
(1)派生開発の課題とプロセス改善について
 1.派生開発の課題
   ⇒part1
   ⇒part2
   ⇒part3
  
 2.派生開発のプラクティス、プロセス
   ⇒part1
   ⇒part2
   ⇒part3

(2)派生開発プロセスの内容
 1.対処検討プロセス群
   ⇒part1
   ⇒part2
   ⇒part3
   ⇒part4
   ⇒part5(本記事が該当)

 2.開発プロセス群
 3.検証プロセス群

(2)派生開発プロセスの内容

1.対処検討プロセス群(part5)

対処検討プロセスを順に解説していく。今回は「1.4 対処案の検証」の解説を行う。

 ・1.1 原因特定
 ・1.2 スコープ定義
     ├─1.2.1 要求コンセプトの明確化
     └─1.2.2 要求仕様の特定
 ・1.3 対処案の特定
 ・1.4 対処案の検証
 ・1.5 対処決定

※プロセスの全体像を参照したい場合はこちら

1.4 対処案の検証

1.4.1 プロセスの目的・概要

対処案の検証プロセスは、特定された対処案の調査アイテムに従って、ソースコードやドキュメントを調査し、必要に応じてスペックアウトを行いながら、対処案が正常に動作することを検証するプロセスである。

対処案をリストアップした時点では、設計情報やソースコードの詳細までを確認しているわけではない。そのため、詳細な調査を行った結果、当初検討した対処案では要求仕様を満足できないことが判明する場合もある。

対処案の検証では、対処案が要求仕様を満足していることを徹底的に調査する。対処案の正常性を確認するのではなく、対処案が要求仕様を満たしていない事項がないかを検証していく。

1.4.2 ツールと手法

以下に、本プロセスで用いるツールと手法について示す。

(1)スペックアウトの実施
スペックアウトは、既存のドキュメントに記載されていないソフトウェアの動作仕様を、ソースコードからリバースエンジニアリングすることで、現状の動作仕様を明らかにしたドキュメントのことである。

スペックアウトは、対処案の検証を行う際、既存の動作仕様がどのようになっているのかを調査する際に用いる手法である。なお、スペックアウトという表現はXDDPにて規定しており、その用途や役割も、本書で示すものと同じである。そのため、XDDPの用語であるスペックアウトをそのまま流用している。

派生開発では、既存のドキュメントに記載不足があったり、度重なる保守によってソースコードとドキュメントに乖離が発生していたりすることが多い。このため、母体動作を理解するうえでの唯一の手がかりがソースコードしかない場合がある。

こうした時に、現状の動作仕様を把握したうえで設計を行うために、既存ドキュメントに不足している動作仕様をリバースエンジニアリングして、ドキュメントに起こし補足する必要がある。

スペックアウトを行うことのメリットは以下である。

  • 調査結果や調査過程をアウトプットすることで、担当者本人が後から参照できるようになり、何度も同じ調査を繰り返さずに済む。
  • スペックアウトを繰り返すことで、現状の動作仕様だけでなく、設計思想や設計アーキテクチャをボトムアップ的に把握することが可能になる。設計思想を把握できれば、ソフトウェア全体の動作を推測することが可能になり、変更による影響度の把握などが行いやすくなる。
  • 調査結果や調査過程をアウトプットすることで、第三者にも動作仕様が理解できるため、レビューや検討が行いやすくなる。
  • スペックアウト資料を、後の開発工程で既存ドキュメントに盛り込むことで、後から他の保守者が動作仕様を理解しやすくなり、保守効率が向上する。

XDDPで想定するスペックアウト資料は、現行のシステム動作を示す断片的なメモや資料になっている場合がある。ただし、本書のスペックアウト資料は「2.開発プロセス群」において、正式なドキュメントとして取り込まれるため、できるだけ正式なドキュメントの目次構成や記載方法などのルールに則って作成することが望ましい。

こうすることで、スペックアウトする担当者自身の単なるメモ書きにとどまらず、第三者が参照しても理解できる水準のアウトプットが保証される。担当者の単なるメモ書きになってしまうと、スペックアウトによる前述のメリットを享受することはできない。

スペックアウトの書式は、既存の設計ドキュメントなどと同様に、シーケンス図やクラス図、フローチャートなどの形式を採る。またマトリクス表記によって既存動作を網羅的に整理すると、母体動作の理解が深まるだけでなく、母体動作での検討漏れや誤りを摘出できる場合もあり、更なる品質の向上が図れることがある。

このため、要素分解、バリエーション網羅、マトリクス表記の手法を組み合わせてスペックアウトを行うことが有効である。

●欠陥是正要求に対するスペックアウトの作成方法
一口に派生開発といっても、機能追加・変更と欠陥是正では、求められるスペックアウトの作成方法に大きな違いが発生することが多い。

一般的に、母体システムの既存ドキュメントの構成は、機能単位であることが多い。大機能を中機能や小機能にブレイクダウンし、記載が行われている。これは、機能単位でドキュメントのトレーサビリティが確保されている状況であるといえる。

こういった特徴があるため、機能追加・変更の場合はどの機能に変更が発生するのかを既存ドキュメントから追跡しやすい。これは、機能追加・変更による影響箇所を調査する際のドキュメントを参照する「視点」が、機能単位になっているからである。

機能単位でドキュメントが構成されていることから、ドキュメントが作成された場合のトレーサビリティの「視点」と、機能追加・変更を行う場合に影響箇所を調査する場合の「視点」が一致している。

このため、既存ドキュメントを活用することで母体システムの概要を把握することが比較的容易である。ドキュメントに不足している箇所をソースコードでトレースして確認する、といったような流れでスペックアウトを作成することになる。

これに対して欠陥是正の場合は、母体の既存ドキュメントを調査する際の「視点」が異なっている

欠陥は、ある機能の中のある関数の一部に混入している。あるコードの一部分によって、複数の機能や動作に影響を及ぼし、複雑なメカニズムによってシステム上の不具合を露呈させている。

欠陥が混入している一部の処理を修正したり、修正による影響箇所を調査するには、機能という単位ではなく、欠陥の混入している関数の呼び元を辿ったり、関連メモリにアクセスする処理を検索したりすることが必要になる。

つまり、プログラムの構成要素の関連というトレーサビリティの「視点」から調査を行うことが必要になる。また欠陥の内容によって、関連するプログラム構成要素やシステムの機能などは異なるので、欠陥是正案件の1つ1つで異なる「視点」から、欠陥に関連する母体システムの動作を把握しなければならない。

欠陥の修正内容が妥当なのか・デグレードは無いのか、を確認するためには、欠陥原因や対処方針といった1点から、関連する処理や機能などを網羅的に調査するといった「視点」で既存ドキュメントやソースコードを参照しなければならない。

もちろん既存ドキュメントは、欠陥が混入した1点を起点として、網羅的に関連する要素をピックアップするための「視点」では作成されていないため、欠陥の内容に応じて都度調査を行わなければならない。

その結果として、既存ドキュメントをそのまま活用できる程度が低くなり、結局はソースコードを参照しないと影響範囲を把握できなくなることが多い。

欠陥是正の際のスペックアウト作成方法は、今回の欠陥是正案件の視点から、関連する動作仕様などの情報を、既存ドキュメントやソースコードの調査を行って集めてまとめる、といった流れになる。

もし既存ドキュメントに関連する動作仕様が全て記載されていたとしても、その動作仕様が今回の欠陥是正案件からしてどのように関連するのかを検討しなおすことが必要になる。つまり、「既存ドキュメントに記載されているシステム動作仕様を、欠陥是正要求に対応するために検討しやすいような形に編集する(欠陥是正に必要なトレーサビリティの視点に編集する)」ことが必要なのである。

具体例を示す。
例えば複数の装置において、ある装置状態の組み合わせのときに欠陥事象が発生するような欠陥是正案件があったとする。

既存のドキュメントは、機能という視点からトレーサビリティが確保されていることから、個々の装置の状態毎のふるまいが個別に記載されているだけである。

これだけでは、複数の装置のどのような状態の組み合わせにおいて対処を盛り込まなければならないのかが判断できない。

そのため、複数の装置状態を一覧的に網羅しマトリクス表にまとめることで、複数の装置のどの状態が組み合わさった時に問題事象が発生するのかを一覧化するような資料に編集することが有効である。

このような、既に存在している動作仕様などを、今回の案件に適したトレーサビリティの「視点」に対応するように編集し直すことも、スペックアウトに含まれる。

そして、こうしたスペックアウトを作成するための視点を階層的にブレイクダウンし、漏れなく動作仕様を把握するための手法としても、先に述べた「要素分解」、「バリエーション網羅」、「マトリクス表記」を活用することが効果的だと考えている。

(2)フロントローディング
フロントローディングとは、下流工程で行う作業を先取りし、上流工程で実施することである。これによって開発リードタイムの短縮と、上下工程間の早期のすり合わせやフィードバックによる高品質化・上流設計力の強化を図る手法である。

本プロセスで行うフロントローディングの目的は、上流工程の設計ドキュメントと、下流工程のソースコードが一致していることを検証し、上流と下流の制約事項の早期のすり合わせによる高品質化・上流設計力の強化を狙うものである。リードタイムの短縮を主な目的として狙うものではない。

対処案の検証を行うため調査アイテムに従って検討を行う場合は、スペックアウトも併用しながら、必ず上流ドキュメントからソースコードまでの整合性を確認しつつ調査を行う。こうすることで、思い込みや理解不足をなくし、早期に妥当な設計内容を把握することができるようになる。

派生開発ではドキュメントが不足していたり、最新の情報でなかったりすることが多い。

このため、上流の設計ドキュメントをベースに対処案の検証を行っても、実際にはソースコードは設計ドキュメントと一致しておらず、検証結果を誤る可能性がある。

このため、上流工程のドキュメントだけをインプット情報として対処案の検証を行うのではなく、下流工程のソースコードもインプット情報に含めて調査しなければ、調査結果の妥当性が保証できない。調査結果の妥当性を保証するために、下流工程の前倒し検証を行うことが高品質な設計につながる。

ただし全ての調査アイテムに対してフロントローディングを行うことは、多大な工数がかかるため現実的ではない場合がある。このため、設計ドキュメントとソースコードとの一致化の程度を早期に把握しておく必要がある。

例えば、基本設計書に記載されている動作仕様のうち、ある一部の内容を調査したときに、ソースコードでは異なる動作をしていたとする。

この場合は、基本設計書の内容は一致化の程度が低いと判断する。一致化の程度が低いインプット情報を基に検証を行った場合は、検証結果が誤りである可能性が高くなる。

一方、詳細設計書のフローチャート情報については、ソースコードとの一致化の程度が高かったとする。この場合は、フローチャートについてはある程度の信頼性があると判断する。そして、調査アイテムの検証を行う際にインプットとして用いた情報源を明記する。

フローチャートであれば一致化の程度は高いので信頼性があり、基本設計書のみをインプットとした場合は信頼性が低く、リスクを含んでいると考えられる。

インプット情報を明らかにすることで、信頼性に基づいて、どこまで(どの下流工程まで)フロントローディングを行うのかを意思決定することができる。

なおフロントローディングを行った結果、ドキュメントとソースコードの不一致を摘出した場合は、正しい内容のドキュメントをスペックアウトし、今後の保守の効率化を図る。

フロントローディングを行うほど、対処案の検証結果の妥当性は増すが、調査工数も増大する。ただし、事前に下流工程で行うはずであったソースコード調査を、前倒しして実施したと考えれば、後工程での作業工数の削減につながるため、トータルでの工数が増加するわけではない。むしろ、事前のフロントローディングによるリスク低減効果、手戻りの削減効果のほうが大きいと考えられる。

一般的に上流工程のドキュメント量のほうが、下流工程よりも少なく、内容も基本的かつ概要的な事項のみにとどまる。

新規開発の場合であれば概要設計情報を、工程を経る度に詳細化していけば、矛盾なくシステムを開発することができる。

しかし派生開発の場合は、すでに下流工程のソースコードまで存在しており、上流工程では検討されていなかった暗黙の制約条件が存在している可能性が高い。

そのような派生開発において、新規開発と同じようなウォーターフォール型の開発モデルを採用した場合、上流工程では対処案を矛盾なく設計できるかもしれないが、詳細設計工程や製造工程に進むにつれ、上流設計ドキュメントには記載されていない細かな制約事項が増えてくるため、上流工程で検討した対処案が必ず実現できるという保証がない。その結果、下流工程に入ってから大幅な手戻りが発生する可能性がある。

このような特徴があるため、派生開発ではウォーターフォール型の開発モデルを採用するのはリスクが高いということを認識しておく必要がある。

派生開発の特徴に対応するためには、フロントローディングを行ったり、小さな要求仕様ごとに開発プロセスを繰り返したりするといった、スパイラル・モデル(インクリメンタル・モデル)を採用することがベターである。

本書では、ウォーターフォール型の開発プロセスを前提にしているが、対処検討プロセス群においてフロントローディングを十分に実施することで、この問題への対策としている。

フロントローディングが十分に機能した場合は、「2.開発プロセス群」においては、新たに設計を行ったり、ソースコードの調査をしたりすることがほとんどなくなる。

事前に作成していたスペックアウト資料を、既存のドキュメントにマージしたり、対処検討資料に記載されている調査済みの設計情報やソースコード情報に従って、マスターのソースコードを更新したりするだけの作業となるため、相当量の作業工数が削減できる。

逆に「2.開発プロセス群」に入ってから新たな事実が判明したり、新たな設計が必要になったりした場合は、フロントローディングが十分に機能しなかったことを示しており、手戻りが発生する可能性も高くなる。

XDDPでもソースコードの修正時間の短縮、という現象で、フロントローディング施策と同様の結論を見ている。

XDDPは、変更箇所を見つけ次第にソースコードを変更するという従来のやり方 と比べると、ソースコードの変更にかかった時間が大幅に短縮されると述べられている。これは十分に上流工程で設計やレビューを行った結果である。本派生開発プロセスにおいても、フロントローディングでしっかりと設計を行うことで、開発工程のなかで製造工程が最も短い工期で完了できるようになる。

(3)前提・制約条件の設定
本手法は、要求コンセプトを実現する上で、すでに存在している前提条件や制約条件を明らかにするものではなく、調査アイテムの検討を行っている最中に、スコープを縮小したり作業量を減らしたりするために、意図的に前提条件や制約条件を付与することである。

この視点から意図的に作業スコープを見直すことは、通常あまりやらないが、とても重要な視点である。

「1.2.1要求コンセプトの明確化」プロセスにおいて、作業スコープは最大に広がった状態となる。ただし作業スコープが広すぎると、それだけ多くの対応工数が必要になる。

その結果、納期を守れなかったり予算を超過したりするといった問題が発生する。このため、一旦広げたスコープを意図的に縮小し、コントロール可能な状態にする方法が必要になってくる。この手法が、前提・制約条件の設定である。

派生開発では、母体動作の完全理解を前提としていない。担当者が関わっていないプログラムは、部分理解のまま開発を進めなければならない。

部分理解の前提においては、「要素分解」「バリエーションの検証」を繰り返している中で、どうしても調査や検証が困難である(調査に多大な時間がかかる)調査アイテムが出現してくる。

例えば、欠陥修正でA機能の修正をするケースにおいて、A機能はB機能が正常に動作した場合に、はじめて正常に動作できるといった関係になっていることがある。

派生開発では部分理解が前提であるため、B機能が正しく動作するのかどうかは現時点で判断することができない。判断するためには、時間を割いてB機能の検証を行う必要があるが、検証する時間が足りない場合がある。

こうしたときは、前提条件として「B機能が正常に動作できるものとする」を仮定することで、B機能の正常性を検証せずとも、B機能が正常に動作する前提で、A機能の変更を検討することができる。

設計書に従えばこう動くはず、という仮定も前提条件の1つである。

確実性を求めるならば、設計書とソースコードが一致していることを検証しなければならない。その検証工数を削減するために前提条件を定めることができる。

もちろん、この前提条件(仮定)が正しいかどうかは、後工程でテストをしてみないと分からない。

母体品質が悪い場合は、その前提条件によっていくつかの欠陥が混入する可能性もあるし、テスト工程において母体欠陥が摘出されることもある。

しかし、設計工程で前提条件を置きスコープを縮小することで、本来行いたかった設計作業に時間を割くことができる。

前提条件を置くことは、単に問題や課題を先送りにすることではない。

納期や予算といったプロジェクト制約を加味した上でのトレード・オフを、ステークホルダに宣言することである

明確に前提条件が設定されるので、事前に関係者間で前提条件のリスクを十分に協議することができる。

前述の具体例でいえば、「B機能が正常に動作できるものとする」という前提条件が成立しない場合のリスクを事前に関係者で協議する。その結果、B機能が正常に動作しないことで、後々の作業に多大な影響を及ぼす(リスクの影響が大きい)と判断したのであれば、前提条件が成立しているかどうかを、やはり工数を確保してでも事前検証するという意思決定ができる。

また、B機能が正常に動作しない場合でも、テスト工程で欠陥修正をする工数と期間をあらかじめ確保できる(リスクの影響が小さい)と判断した場合は、そのリスクを前提条件として受容するという意思決定をすることもできる。

このように、前提条件を意図的に設定することで、前提条件で定めた内容をブラックボックス化し、スコープを縮小することが可能になる。

繰り返しになるが、派生開発では部分理解の制約のもと、短期間での開発が求められているため、すべての不明点を調査し検証し尽くすことは現実的ではない。そのため、あえてリスクを抱えたまま前提条件を設けることで、ステークホルダにもリスクの度合いや影響度を明示できる形で、効果的なプロジェクト運営を行うことができる。

プロジェクト運営で一番問題となるのは、「何が分っていて何が分っていないのかが分っていない」状態である。

どんなリスクがあり、どの程度の影響度が想定され、リスクへの対応策をどのように打ち、最悪ケースではどのような結果になるのか、といったことがおおよそでも判明していれば、関係者間の合意を得る事はできるし、プロジェクト運営も破綻しない。

また、制約条件を設定することでも、スコープを管理可能な範囲に縮小し、コントロールすることが可能である。

欠陥修正の水平展開をした場合に、あまりにも変更しなければならない箇所が多く、期間内に修正できないような場合がある。

こうした場合は、変更が必要な箇所のうち、例えば発生確率が低いルートについては、修正対象としない、といった意思決定をすることができる。

この場合も、修正対象にしなかった箇所で問題が発生する確率と影響度を関係者間で評価し、リスクを受容してもその影響度がごく小さいことの合意を得ることができる。このようにして、納期や予算といったプロジェクトの制約条件を考慮した作業スコープの設定を意図的に行うことが可能となる。

(5)要素分解
(6)バリエーションの検証
(7)マトリクス表記

これらの詳細化手法もあわせて用いることで対処案を検証していく。

次回は「1.5 対処決定」以降を説明する。

このエントリーをはてなブックマークに追加

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です