仕様バグとアジャイル開発に関する考察

最近のソフトウェア開発にかかわるITベンダーと発注企業の訴訟の事例をみると、その大半がいわゆる「仕様バグ」であることに驚く。例えば、2017年11月に文化シャッターが販売管理システムの開発を受託していた日本IBMに対して、システム開発の失敗による損害賠償を求めた例も、最終的には「仕様バグ」が主原因なようである。

両社は当初、アジャイル開発とウォーターフォール開発の併用によるシステム構築を目指していたが、途中からウォーターフォール開発のみに方針を転換した。

しかし、開発が完了した後のユーザー受け入れテストで多数の不具合が発見された。受け入れテスト段階での要件の変更に当たる事項が顕在化したことが原因であり、その理由として「機能要件および外部設計に関するヒアリング・確認不十分」などが挙げられている。

日本IBMは、約1000件の不具合のうち約800件を「プログラムのバグではなく仕様の変更に当たる」と主張。文化シャッター側も異論を唱えつつも受け入れた模様である。

このような「仕様バグ」に伴うソフトウェア開発プロジェクトの失敗への対応として有効な手段がアジャイル開発である。しかしながら、文化シャッターの例では、何故かプロジェクト途中でアジャイル開発を全て止めてしまいウォーターフォールに切り替えてしまったようである。

「仕様バグ」を防ぐための手段としてのアジャイル開発および最近のソフトウェアプロダクトマネージメントを理解するためには、以下の文献が非常に参考となると思う。

「あるソフトウェア工学者の失敗　日本のITは何故弱いか」(林晋 2015?)

この内容を咀嚼し、また「仕様バグ」にフォーカスして補完した僕の理解は以下の通りである。

• Validation とは「仕様が、仕様の背景にあるそのツールにに期待される機能（要求）に対して正しいかか？」を検証すること。Verificationとは「ソフトウェアが示された仕様に対して正しいか？」を検証すること。
• Validation が十分に行われていない仕様は「仕様のバグ」となり、その仕様に基づいて開発されたソフトウェアの品質を Verification によって高めても、ユーザー要求に対して正しくはならない。
• この「仕様のバグ」の問題は相当に大きい。 後に気づいた「仕様のバグ」の変更には、「バグのある仕様」に基づき何ヶ月もかけて開発したソフトウェアの修正をしなくてはならず、相当の期間とコストを要する。
• 「仕様のバグ」を防ぐためには、プロジェクト初期に全体の労力の大半を投資して、仕様を極力最終盤に近づける「アップフロント開発」を行う必要がある。
• しかしながら、様々なユーザーが様々な使いことをするような仕様の確定が困難なソフトウェアシステムにおいては、「アップフロント開発」で莫大な労力を割いて作成した「仕様」にも「仕様のバグ」が残ってしまう。　このような不確実なソフトウェアシステムを開発するのに有効な手法が「アジャイル開発」である。
• 「アジャイル開発」はユーザー価値を生む仕様を探し出しそれを早期に実現・提供し、ユーザーからのフィードバックをもとに仕様を修正、改善していく手法である。探し出したユーザー価値を実装できているか確認するために、テスト駆動開発が行われる。
• テスト駆動開発の「テスト」は「仕様が、仕様の背景にあるそのツールにに期待される機能（要求）に対して正しいかか？」を検証する Validation であるべきである。そうではない Verification を目的としたテストは「仕様のバグ」を修正できないため意味がない。
• 仕様を明確とすべく行う「アップフロント開発」と変化への柔軟な対応を行う「アジャイル開発」の良いところ取りをする試みは、この２つの開発手法の目指すものが大きく異なるため、うまくいかない。
• 「仕様のバグ」が生じる原因は、「仕様の背景にあるそのツールにに期待される機能（要求）」を明確化できないことであり、その源流であるエンドユーザー自身の声を吸い上げる「アップフロント開発」の上流工程を担う担当者の力量に依存する。
• 「アップフロント開発」の上流工程が肥大化し関係者が増えれば増えるほど、エンドユーザーの真の要求が曖昧となり、ソフトウェアは肥大化し、それとともに「仕様のバグ」が内包されるリスクが増える。
• それを防ぐために「アジャイル開発」が有効である。そして「アジャイル開発」が有効に機能するためには、エンドユーザーとアジャイル開発チームが直接対話できることが必要である。エンドユーザーとアジャイル開発チームの間に、何人もの伝達者が入ることとなれば、それは「仕様のバグ」を生み出すこととなり、「アジャイル開発」による作成されたソフトウェアの Validation を行うことができず、単に（バグを内包した）仕様に基づくソフトウェアの Verification をすることしかできない。　

以上のように考えていくと、昨日のエントリーで述べた「プロダクトオーナーの負担軽減のためにプロジェクトマネージャー的な人をアサインする」だけでは足らず、ユーザー価値を探し出し検証するためのスタークホルダー層での組織と仕組みが必要だと考える。この組織と仕組みについては、次の機会に考えてみたい。