品質確保に効果のあった派生開発プロセスの工夫#13
掲題の派生開発プロセスに関する、シリーズ・エントリです。
派生開発の設計品質確保について問題意識を持たれている方は、ご一読頂けると幸いです。
レポートの要約、および背景については第一回を参照ください。
エントリ内容の目次
まずはこのレポートの主旨について述べた後、一般的な派生開発の現状を俯瞰する。その後、派生開発プロセスの１つであるＸＤＤＰと、当方の開発プロセスの工夫についての概要を述べる。
時間のない場合は、ここまでの内容（１部 レポート・サマリー）だけでも、本論述の概要はつかめると考える。その次の２部から、詳細なレポート内容を述べていく。
もちろん２部から読み始めても構わない。そちらのほうが、概要説明ではなく詳細な論述を行っているため、理解しやすい可能性がある。１部はサマリーのみであり、詳細情報は把握できないだろう。
（１）このレポートの概要と背景について
⇒記事はこちら１部 レポート・サマリー－－－－－－－－－－－－
（２）派生開発を巡る現状
⇒Ｐａｒｔ１
⇒Ｐａｒｔ２（３）ＸＤＤＰでの問題提起と解決策の概要
⇒記事はこちら（４）当方が遭遇した派生開発の問題と解決策の概要
⇒記事はこちら２部 レポートの詳細－－－－－－－－－－－－－－
（１）派生開発の課題とプロセス改善について
１．派生開発の課題
⇒ｐａｒｔ１
⇒ｐａｒｔ２
⇒ｐａｒｔ３
２．派生開発のプラクティス、プロセス
⇒ｐａｒｔ１
⇒ｐａｒｔ２
⇒ｐａｒｔ３（２）派生開発プロセスの内容
１．対処検討プロセス群
⇒ｐａｒｔ１
⇒ｐａｒｔ２（本記事が該当）２．開発プロセス群
３．検証プロセス群
（２）派生開発プロセスの内容
１．対処検討プロセス群(part2)
対処検討プロセスを順に解説していく。今回は、1.2.1 要求コンセプトの明確化から解説を行う。
・1.1 原因特定
・1.2 スコープ定義
├─1.2.1 要求コンセプトの明確化
└─1.2.2 要求仕様の特定
・1.3 対処案の特定
・1.4 対処案の検証
・1.5 対処決定
※プロセスの全体像を参照したい場合はこちら。
1.2.1 要求コンセプトの明確化
1.2.1.1 プロセスの目的・概要
要求コンセプトの明確化プロセスの目的は、派生開発における欠陥是正要求や変更要求に含まれる真の目的をあぶり出し、作業スコープを最大限に拡張することである。
スコープを広げることで、欠陥是正要求や変更要求を実現する際に、同時に対応しなければならない派生的な要求事項を見逃さないようにする効果が得られる。
派生開発におけるスコープの幅は、本プロセスで最大になり、以降のプロセスを経るに従い次第に具体化され縮小していく。
要求コンセプトの明確化が効果を発揮するケースは、ソフトウェアの具体的な欠陥是正要求が到来した場合である。
欠陥是正要求は、実際に発生している個別具体的な欠陥事象やその発生原因をふまえて発行されるため、はじめの要求時点から、かなり具体的な対処方針や修正内容を含んでいる場合がある。
例えば、「対向システムの回線障害検出論理を変更するため、○○処理の□□動作を、△△へ改修する」といった内容である。要求内容が具体的であればあるほど、担当者はすぐに具体的な修正内容の検討に着手しようとする。
その結果、同種の原因による他の欠陥が潜在していないかを水平展開して洗い出す作業が漏れたり、そもそもの要求で依頼された内容に誤りがあったりすることを見逃しやすくなる。
先の例で言えば、「対向システムの回線障害検出論理を変更する」ということが目的になってしまうが、実際にはこれは手段であり、本来の目的は「対向システムの回線障害の誤検出を防止する」であるかもしれない。
その状態を保証するための１つの手段として「対向システムの回線障害検出論理を変更する」という内容があり、実は水平展開すると、本来の目的である「対向システムの回線障害の誤検出を防止する」を阻害する他の問題がまだ潜在していることもある。
この例でいう要求コンセプトとは「対向システムの回線障害の誤検出を防止する」が該当する。
一般に要求コンセプトを明確化すると、作業スコープは拡大する。なぜなら具体的な欠陥是正の要求内容だったものを、コンセプト化することで抽象化・汎化するからだ。
一旦コンセプト化しスコープを広げることで、検討すべき視点や範囲が拡大するので、その後の検討漏れが起こりにくくなる効果が得られる。
初めから局所的な視点やスコープで作業をしていると、その背景にある要求の検討や盛込みが漏れてしまい、対処不十分といった結果になる可能性がある。
以上までに見るように、本プロセスは、目的と手段の関係を、妥当と考えられる粒度まで引き上げて、要求内容の本当の目的をシンプルにコンセプト化することで、本来達成しなければならなかった目的を見落とさないことを保証するプロセスである。
1.2.1.2 プロセス実施による効果
要求コンセプトを明確化せず、目的を誤った欠陥対応を行うことでの問題点を以下に述べる 。こうした問題に対して効果を持つ。
- 目先の欠陥対応に留まってしまい、本来システムやソフトウェアで達成すべき目的を実現できずに、類似問題が再発する可能性がある。その場合、客先からすると「同種の問題が再発した」ように見える。前回の問題発生時になぜ水平展開が漏れたのかを追求されたり、度重なる類似問題の再発で信頼関係が悪化したりする可能性がある。
- 目先の欠陥対応を小手先で何度も繰り返してしまうと、ソフトウェアの設計思想や動作仕様に矛盾が生じやすく、保守性の低いソースコードになる可能性がある。また、開発工程の後半になってから予期せぬ既存動作仕様との矛盾に気付き、手戻りが発生する可能性もある。
1.2.1.3 ツールと手法
以下に本プロセスのインプットをアウトプットに変換するためのツールと手法を示す。本プロセスは作業スコープを適度に拡大することが狙いであるため、主にスコープ拡張の手法について示す。
（１）目的の手段化
ある目的について、その目的を達成しなければならない更なる理由を探っていくことで、当初の目的を、より上位の目的を実現するための手段に変換する手法である。
具体的には、“なぜこの目的を達成しなければならないのか？”、“この目的を達成する理由は何なのか？”といったなぜなぜ分析を行うことで、ハイレベルな目的（真の目的）を見つけ出していく。場合によっては、妥当な真の目的を設定するためにこのサイクルを何度か繰り返す必要がある。
ハイレベルな目的を設定することによって、当初実現しようと考えていた目的が、ハイレベルな目的を達成するための１つの手段でしかなかったことに気付き、視野が広がることで、目的を達成するための手段が他にも存在していないのか、不足していないのかを検討できるようになる。
・図表1.2.1-1 目的の手段化
要求コンセプトの明確化プロセスにおいては、設定した真の目的がそのまま要求コンセプトに該当する。
1.2.1.1節で述べたように、欠陥是正要求の場合は、顕在化している問題事象のみを修正したいと考える誘引が働きやすい。しかし、そういった対応をしていると類似する他の欠陥が潜在していることを見逃したり、片手落ちの対処を盛り込んでしまったりする可能性がある。
例えば、ＡシステムがＢシステムへ周期的にKeep Aliveメッセージを送信し、Ｂシステムの生存監視を行っているとする。
ただし、Ａシステム内において、周期でKeep Aliveメッセージを送信するＡ１プロセスが、何らかの理由でダウンしてしまった場合、Ａシステム内でＢシステムからのKeep Alive応答を監視するＡ２プロセスにて、一定時間の応答がないためにＢシステムが障害であると判断し、Ｂシステムのサービスを停止してしまう、といった問題があるとする。
ここでの対処は、ＡシステムでＢシステムをサービス停止する前に、ダウンしたＡ１プロセスを立ち上げてKeep Aliveメッセージを送信し直すことが求められているとする。
このような欠陥是正要求が到来した場合の対処スコープとしては、「Ａ１プロセスダウンを検知し、Ａ２プロセスでKeep Alive応答なしと判断する前に、Ａ１プロセスを再起動する」というように認識するであろう。
しかし本問題にあるような、Ａシステムからの送信メッセージに対して、Ｂシステムからの応答が無い場合に、Ｂシステムをサービス停止状態にする処理は他にも存在する。
データ送信に対する応答であったり、イベント通知に対する応答であったりと様々だ。こうしたKeep Alive以外のメッセージについても、同様に送信プロセスがダウンしてしまうと、応答を監視するプロセスではＢシステムからの応答が無いために、Ｂシステムをサービス停止状態にしてしまう可能性がある。
前述の欠陥是正要求に対するスコープの認識をしてしまうと、こうした類似問題が他にも存在しているのかどうかを見逃してしまう。
こうした場合は、問題事象や原因を抽象化して目的の手段化を行うことが有効である。「Ａ１プロセスダウンを検知し、Ａ２プロセスでKeep Alive応答なしと判断する前に、Ａ１プロセスを再起動する」のは、どのような目的を達成するための手段なのか、と考える。
すると「Ａシステム内のプロセスダウン（もしくは、異常動作）によって、誤ってＢシステムのサービス停止をしないため」であることがわかる。
Ａ１プロセスダウンへの対策は、この目的を実現するための、手段の１つであることが認識できる。このように考えると、Ａシステム内の他のプロセスダウンによって、同様の問題が発生する箇所はないのか、といった観点から問題を眺めることができる。
その結果、類似の欠陥が存在するかどうかの調査作業や、類似欠陥の修正作業など、母体システムに潜在する類似の欠陥の存在を含めたスコープで検討を行うことができる。この点でスコープが拡大している。
なぜ母体システムに潜在する欠陥までスコープを広げて検討をしなければならないか、その理由については、扱うシステムやプロジェクトの特性に依存する部分がある。
ミッションクリティカルシステムや、インフラシステムなど、欠陥の発生による影響が大きく、高い信頼性が求められているようなシステムは、システムの納入先において類似の問題の発生を許容しないであろう。
前述した例で述べると、Ａ１プロセスダウンによる問題も、Ａ２プロセスダウンによる問題も、システム納入先から見れば、全て同じ「プロセスダウンへの設計不足による欠陥」と判断される。つまり、何度も同じ原因の問題を繰り返し発生させていることと認識される。
同じ原因の問題を何度も繰り返すということが、どれだけビジネスにインパクトを与えるのかは想像に難くない。
その結果、納入先から再発防止策の実施や、実施計画の遂行状況など、事細かな進捗状況を監視されることになり、二度と類似原因での問題を再発させることができない状況になるであろう。
こうした理由があるため、欠陥対応は類似する欠陥が潜在していないのかどうかも検討スコープに含めることが妥当であると考える。
（２）水平思考（ラテラル・シンキング）
目的の手段化は、物事を上下方向（垂直）に汎化・特化する思考方法であるが、水平思考は物事を左右方向（水平）に展開する連想方法である。
例えば、「スマートフォンは高齢者には使いにくい」という問題があったとする。
この問題を解決する際に、垂直思考であれば、スマートフォンが高齢者に使いにくい原因を細分化していき、特定した１つ１つの原因に対して対策を打つ。「機能が多すぎる」「取り扱いにネットワークの知識を求めすぎる」などの特定された原因に対して、「機能を削る」「ネットワーク設定がされた状態で出荷し、初期設定量を減らす」などの対策を打つ。問題をブレイクダウンして原因を探るという垂直的な階層構造で考える方法である。
これに対し水平思考では、スマートフォンが使いにくい原因を探ることはせずに、高齢者に使いにくいと言われている他の電子機器は何かを水平的に考える。または、高齢者が使いやすい他の電子機器は何かを考える。
例えば、銀行ＡＴＭ操作では高齢者にも扱いやすいように、手順に沿って画面が自動的に遷移すると共に、必要なタイミングで必要な情報が文字だけでなく音声でも流れる。これをスマートフォンに流用し、初期設定は設定ウィザードが手順に沿ったガイド役になり、要所で音声による確認を促すようにする、といった対策を水平的に考える思考方法である。
このように水平思考は、物事を構成する要素を他の要素に置き換えることで、類似する他の事象へと対象範囲を拡大する方法である。前述の例では、「高齢者に使いにくい（使いやすい）」という要素は固定しているが、対象となる物の要素を「スマートフォン」から「他の電子機器」へと置き換えることで、銀行ＡＴＭからアイディアを流用した。
要求コンセプトの明確化プロセスにおいては、要求事項を水平方向に展開し、スコープを拡張する際に用いる。例えば、「サブシステムＡにおいて、対向サブシステムとの間の回線障害を誤検出した」といった問題を水平展開する場合は、サブシステムＡだけではなく、他のサブシステムでも同じ問題が発生していないか、またはサブシステム間の回線障害だけでなく、サブシステム内の内部回線でも同じ問題が発生していないか、といった考え方で、作業スコープを拡大していく。この時点で、調査対象となるサブシステムの数が拡大しており、当初のスコープよりも広い範囲を検討できるようになっている。
水平思考は、要求コンセプトを決定することはできないが、物事の連想力を強化し、要求事項や要求コンセプトが対象とするスコープを拡張する役割を果たす。
（３）前提条件分析
（４）要素分解
（５）バリエーションの検証
（６）マトリクス表記
（３）～（６）は、いずれもスコープを詳細化し、限定（縮小）していくための手法である。要求コンセプトのスコープが広すぎる場合には、これらの手法でスコープを縮小することが必要になる。これら手法は「1.2.2 要求仕様の特定」にて詳述しているため、そちらを参照されたい。
1.2.1.4 プロセス実施上の留意点・考慮点
要求コンセプト次第でその後の作業スコープが大きく変動するため、できるだけ早めに要求コンセプトを関係者間で合意して作業を進めることが望ましい。そのため本プロセスは、スコープ定義の一番初めに行う。
場合によっては、明確にした要求コンセプトが、欠陥是正要求に対してあまりにも広いスコープを持っており、不適切だと思える場合がある。
例えば、変更したい内容が「販売管理システムの商品登録情報に、もう１つのパラメータを付与する」といったものであるのに対し、要求コンセプトが「販売管理の効率化を通じて、組織経営のスピード向上・コストダウンに貢献する」といった場合である。
行き過ぎた「目的の手段化」は、むやみなスコープ拡張につながり、過剰な工数と工期を求められることになる。この事例において妥当と思われる要求コンセプトの詳細度は、せいぜい「パラメータ追加により、販売データから新たな統計情報を集計できるようにする」程度であろう。
要求コンセプトが大きすぎる（スコープが広すぎる）場合は、後述する「前提条件分析」「要素分解」「バリエーションの検証」といった手法を用いて、スコープを詳細化・限定化する。これらの手法を活用するのは「1.2.2 要求仕様の特定」プロセスであるため、具体的な方法についてはそちらを参照されたい。
なお、妥当な要求コンセプトの粒度については、プロジェクトやシステムの特性、開発プロセスの特徴などを踏まえて、各プロジェクトで定義が必要である。妥当性の基準は組織やプロジェクト、開発プロセス、開発モデルに依存する事項であり、本派生開発プロセスの規定するところではない。本派生開発プロセスでは、スコープを広げたり狭めたりする手法とプロセスを規定するだけにとどめる。
次回は「要求仕様の特定」についてプロセスを見ていこう。
