アジャイル開発が問題点をすり替えた品質特性～機能性と信頼性

アジャイル開発はソフトウェアの品質特性のうち、機能性と信頼性の問題点をすり替えることによって、ソフトウェア開発特有の特徴をうまく取り入れているように思える。
考えたことをメモ書き。

【参考】
ソフトウェア品質特性(ISO/IEC9126)の解説

ソフトウェア品質特性について

ISO 9126 - Wikipedia

品質改善.com - 品質特性とは

アジャイル開発が重視する品質特性～保守性と移植性: プログラマの思索

【1】ソフトウェアの品質を話す時、普通は、機能性と信頼性が暗黙のうちに前提にされている。
仕様書に書かれた機能がシステムに反映されていてそもそも使えるのか、そして、システムの障害が少なくて安定稼働しているか、という点。

ウォーターフォール型開発では、詳細な仕様書を作り、手戻り作業がない前提でシステムを作り始める。
一括請負契約が理由でもあるが、外部設計で決定した仕様に基づいて開発するため、確定した仕様は全て実装しなければならない。
だから、機能性の評価は、仕様書通りに作られているか、というシステムテストや受入テストで検査される。

特に、ウォーターフォール型開発では、「仕様凍結」という言葉がキーワードの一つ。
そうでなければ、いつまでもあいまいな仕様のままで製造工程に入ることができないから、納期がズルズルと延びてしまうからだ。

【2】だが、アジャイル開発では、システムに全ての仕様が反映されているか、という観点ではなく、顧客にとって価値ある機能が実装されているか、という観点に置き換える。
つまり、無駄な機能を実装しても無意味であり、シンプルで使いやすいシステムであるべき、という思想がアジャイル開発にはある。

XPの計画ゲームの背景には、2～4週間の間隔で常にストーリーを吟味して、必要な機能は追加するが、優先度の低い機能は思い切って削るという意思決定も含まれている。
この考え方は、ウォーターフォール型開発に慣れている人ならば、過激な思想だと思う。
何故なら、外部設計で決まった仕様であろうとも、開発途中で顧客が不要と判断したならば、その機能は削除するオプションが含まれるため、当初の見積りと狂ってしまうからだ。

でも、アジャイル開発では、そもそも作られた機能の大半はユーザに使われないという経験則を元に、ソフトウェアの機能を定期的に見直しながら、頻繁にバージョンアップして機能拡張も品質改善もしていく。

この考え方はソフトウェアの特徴をよく表していると思う。
ソフトウェアはそもそも頻繁にVerUpするものであり、VerUpしないソフトウェアは死んだも同然。
常にVerUpする要因によって変化するものであるならば、機能は凍結すべきではなく、頻繁に見直しをかける仕組みが必要だ。

Scrumのバックログという概念はこの手法をうまく表したネーミングだと思う。
顧客の要望はバックログに一旦入れておき、常に優先順位を付け直して、優先度の高い機能から実装していく。
機能性の評価は、仕様凍結した仕様で評価されるのではなく、変化の激しいビジネスの状況を反映すべき、という観点で置き換えられる。

【3】また、ウォーターフォール型開発では、障害を起こさないようにバグを摘み取り、稼働率を高めようとする。
つまり、障害故障間隔（MTBF）を長くすることによって稼働率を高める。
この考え方は、ハードウェアのような製品の品質管理の手法を受け継いだものといえる。

だが、アジャイル開発では、障害修復時間(MTTR)を短くすることによって稼働率を高めようとする。
その考え方は以前書いた。

Mantisのチケット集計機能にある最大放置日数と平均完了日数: プログラマの思索

アジャイル開発と品質管理の関係: プログラマの思索

SRATSの使い方: プログラマの思索

つまり、障害が発生したとしても、即座に障害を修復できるならば、高い稼働率を保持することができる。
この発想は、XPのリファクタリングで保守性を高めたシステムだからこそ容易でもあるし、テスト駆動開発で常に即座に自動テストできる環境があるからこそ可能だし、AmazonEC2のようにサーバーインフラがクラウド化されたことによって、常に稼働できるような仕組みが整ったからこそ、実現できるもの。

昨今は、iPhoneや携帯のシステムアップデートのように、後から機能追加だけでなくバグ修正も反映する仕組みができたので、障害があったとしても後から直すことが容易になった。
「後追いテスト」というテスト手法も、組み込み機器のソフトウェアアップデートが可能になったからこそ選択できる手法と言える。
また、継続的インテグレーションを発展させた継続的デプロイ、継続的デリバリーの概念によって、ワンクリックでデプロイできれば、より楽になる。

つまり、最近の技術革新のおかげで、壊れないシステムを作るよりも、素早く問題修復できる仕組みが実現されたことで、逆転の発想が可能になったとも言える。
特に、オープンソースソフトウェアのように、ユーザの力を利用して問題発見のフィードバックや問題修復を図ることができたことも大きい。

【4】機能性や信頼性の問題点をアジャイル開発は意図的にすり替えた背景は何か？
現在のビジネスの状況は、あらかじめ全てが分かった状況で開始できることはあまりない。
むしろ試行錯誤しながら開発せざるを得ないし、突然金融危機が起きて状況が一変するような時代だからこそ、途中で変更できるオプションが欲しいもの。
そして、仕様があらかじめ確定しているマーケットアウトの製品よりも、市場の反応を見ながら少しずつ機能拡張していくマーケットインのWebサービスの方が、今のビジネスに向いている背景があるのだろう。

アジャイル開発は、機能性の問題を「全ての仕様が反映されているか」から「必要な機能が実装されているか」、信頼性の問題を「いかに壊れないシステムを作るか」から「いかに素早く直せるシステムにするか」に置き換えた。
その意義はとても大きいと思っている。