過剰品質

過剰品質について考えたことを書く。

【元ネタ】
ITILのキャパシティ管理

【1】SW開発が製造業と決定的に違う点は、品質はトレードオフにならないことだ。
製造業のプロセス改善で頻出するQCD(品質、コスト、納期)の三角形によるマネジメントは有用でない。
SW開発でも特にXP等のアジャイル開発は、機能、コスト、スケジュールの三角形でマネジメントする。

品質をトレードオフにしない理由は、品質が落ちれば、SW開発プロジェクトの存続そのものが成り立たなくなるからだ。
実際、メンバーの作業の品質が落ち、成果物の品質が落ちる症状が出始める。
最終的には、バグだらけのシステムそのものをリリースできなくなる。

【2】品質を確保するためにSW開発では色んな手段を選ぶ。

ITILのキャパシティ管理では、需要を制限して品質を確保する需要管理という手法がある。
これは、機能やユーザビリティを制限して品質を確保すること。

需要管理でよく出る例は、災害時の電話網だろう。
阪神大震災や新潟の震災のような大規模な災害では、通信インフラの能力が落ちている上に、被災地へ普段の倍以上のアクセスが集中し、すぐに通信インフラが麻痺する。
本当に役立つ救助活動で通信インフラは必要なのだから、電話などのアクセスを大幅に制限して、通信インフラの品質を確保する手段を取る時が多い。

でも、もっとお金をかけて通信インフラを拡張すべきかと言われると、実際はコスト面から現実的でない時が多い。
つまり、需要を制限することで品質を確保する。

ITILが言うITインフラのキャパシティは、技術力でスケーラビリティ、ユーザビリティを拡張しやすい面がある。
実際、IT業界では、ムーアの法則に従って技術革新が行われてきた歴史がある。

しかし、99%から99.9999%へ品質向上するのは非常にコストがかかる上に技術的にも難しい。
このような要件は、金融や工場など、1度のミスも許されないシステムが多いだろう。

そもそも限られたリソース、資本で可能なのか？
この考えでは、品質はコストとトレードオフ。

ITILのキャパシティ管理の発想なら需要制限、アジャイル開発の発想なら機能の制限によって、品質とコストのバランスを取ろうとする。

トレードオフの基準は、そもそものビジネス要求を満たすための条件が「good enough」であるかどうかだ。
XPならスコープ(機能)・コスト・納期の三角形で「good enough」かどうか決める。

【3】ソフトウェアの品質にはマネジメントも含むのだと最近ようやく分かってきた。
ソフトウェアの品質を確保するために、コスト、納期、機能などのバランスを考えながら、顧客や開発者などのステークホルダーと駆け引きする。
その状況では、プロジェクトリーダー、あるいはアーキテクトは調停者の役割を果たす。
色んなステークホルダーの利害関係から、妥協点を探り出し、リリースまで持ち込む。

だから、SW開発はマネジメントがより重要になってくる。
アーキテクチャやプログラミング技術で解決していくのは、IT業界にいるなら当たり前。
むしろ、プロジェクトリーダーの仕事の大半は、機能の優先順位付けだ。

顧客は、機能や納期を決める権限を持つ。
開発者は、その機能の実装コストを決める権限を持つ。
当然、顧客の要求と開発者の工数見積は衝突しやすい。

しかし、スケジュール延期は、昨今のビジネスのスピードからして難しい時が多い。
工数がかかるから大量の人員を投入すれば解決する、という手法は、昔から失敗すると知られている。

その両者の関係のバランスを取るには、機能に重要度と優先度を付けて、機能を削るか、機能を小さく分割して小刻みにバージョンアップする戦略を取るのが一番現実的。

チケット駆動開発では、イテレーション単位でチケットの取捨選択を行う手法が、それに当たる。
これが本来のマネジメントなのだ。