頻繁なVerUpがソフトウェア開発の本質

WF型開発とAgile開発の本質的な違いはどこにあるのか？
プロセスや技術の観点から見れば、WF型開発は本番リリースが1回しかないのに対し、Agile開発は定期的なリリースを基本とする特徴がある。
その観点をもう少し深めて考えてみた。
ラフなメモ書き。

【1】WF型開発は、シーケンシャルに工程単位に開発を行い、フィードバックプロセスをできるだけ排除するプロセス。
半年～1年に1回だけ本番リリースするのが普通だろう。

特に日本のSIは製造業から派生した会社が多いから、ソフトウェア工場の発想に影響を受けている。
つまり、前工程の品質をできるだけ確保するために、レビューやテストを事前にしっかり行い、仕様漏れや検証漏れを前工程で十分に行って、後工程のフィードバックや突然割り込んだ変更要求をできるだけ排除するやり方。
たいていは、スコープは長期間固定化するのが普通で、最後の1回の本番リリースを成功させる手法になる。

だが、人月の神話以来昔から知られているし、僕自身も何度も経験したけれど、本番リリースが1回だけのプロジェクトは必ず失敗する。
本番リリース前に作業量はピークになり、残業や休日出勤も続くから、開発者はリリースさえできれば全て丸く収まると思っているけれど、実際は本番リリース後の方が大変だ。

いくらテストをやっても、本番環境で、実際にユーザが使った実績がないから、その品質はテスト品質に過ぎず、本番品質あるいは運用品質まで至っていない。
本番環境と開発環境は物理的に全く違うから、動かしてみないと分からない部分はとても多い。
そして、実際に稼働させて、ユーザが実業務に使ってみなければ、業務に耐えうる品質なのか、分からない。

だから、本番環境で動かしてみて初めて分かるバグが、たくさんの障害報告として押し寄せる。
もちろん、軽度のバグも大量に発見されて報告されるだろう。

更に、ユーザが初めて業務で運用してみて、やっぱり使いづらい、などと言った改善要望も大量に押し寄せる。
また、半年前、1年前にあげた要望は、その後のビジネス環境の変化や、ユーザの組織構造の変化を反映していないわけだから、元々の要望から変わっている時が多い。
だから、現在のビジネス環境やユーザ環境に見合った機能へ改善して欲しいと言う要求が大量に来るだろう。

つまり、WF型開発では、最初で最後の本番リリース後に必ずデスマーチになる。
障害報告や改善要望といったたくさんのフィードバックを開発チームが処理しきれなくなるのだ。
開発チームの能力を超えたフィードバックが来た場合、もはや優先順位付けや棚卸しすらも不可能になる。
たとえチケット駆動開発であろうとも、そんな状況では役立たない。

【2】Agile開発は、イテレーション単位に定期的にリリースするのが前提のプロセス。
XPでは、この開発スタイルは、小規模リリースと言われる。
つまり、定期的なリリースで、品質を維持しながら、小刻みに機能を拡張していく開発プロセス。

Agile開発では、頻繁なリリースが最大の特徴だから、頻繁なVerUpが当たり前だ。
WF型開発と違って、複数回のリリースをあらかじめ計画に織り込んでいるから、どの機能をいつリリースするのか、という観点でスコープをコントロールすることになる。

つまり、イテレーションというタイムボックスに、顧客の要望を実現する機能を入れることができるし、新たなイテレーションを実施する前に、機能を入れ替えることも可能。
タイムボックスというサイズの制限があるから、スコープにも上限があるから、顧客にも、事前にあがってくる要望へリリースの制限をかけることができる。

XPの「変化を抱擁せよ」のキャッチフレーズと同じく、Agile開発はソフトウェアの変化を前提とする。
VerUpしないソフトウェアは価値がないのだ。

ハードウェアもミドルウェアもソフトウェアも1年後には大きく変わっている。
昨今のハードウェアの性能改善、WebサービスのUIの改善は著しい。
環境が変わったのだから、ソフトウェアも環境の変化に合わせて進化した方が使いやすくなる。

【3】しかし、不用意なVerUpはデグレを起こす危険性がある。
きちんと精査されていない機能改善は、逆にデグレを起こし、品質を落とす危険があるのだ。
特に最近は、HWやOSやブラウザ、ミドルウェアのバージョンの組み合わせが複雑になっているため、安易なVerUpですぐにソフトウェアは動かなくなる。

だから、頻繁なVerUpを安全に行うには、ITILの変更管理の考え方が必要。
本番リリース後のソフトウェアを安全にVerUPして、運用品質を維持していくには、運用保守の作業を定型化しておくのが大事。
しかし、ガチガチの変更管理プロセスは、開発チームの生産性を落とす。
複雑なドキュメントやワークフローが開発チームの機動力をなくす。

だが、チケット駆動開発なら、ワークフロー管理はチケットの種類別のステータス管理として透過的に管理できる。
ITILによる運用保守の観点をチケット駆動開発の中で運用することも可能だ。

【4】また、Agile開発は自然に並行開発になるため、構成管理の観点も重要だ。
何故なら、一度リリースしたソフトウェアはそれで終了ではなく、本番リリースブランチとして、ユーザの業務に使われて生き続ける。
更に、開発チームはその裏で、次のリリースに向けて、ガンガン機能拡張するソースをtrunkへコミットしている。
つまり、trunkと本番リリースブランチと言う二つのコードラインが発生し、その二つのコードラインの品質を常に維持し続けなければならない。

並行開発の構成管理は、パッケージ製品や組込製品の開発で従来から知られているように、とても難しい。
1本のコードラインをリリースする品質まで持って行くのも大変なのに、二つのコードラインを並行して保守せざるをえないからだ。
また、その2本のコードライン間でマージ作業が頻繁に発生するが、手作業のマージ作業はとてもミスが多い。

この状況に対する構成管理の解決手法は、メインラインモデルとして知られていて、オープンソースでは広く知られている開発スタイル。
特にMercurialやGitのような分散バージョン管理では、ブランチを管理しやすい。
チケット駆動開発はメインラインモデルとも相性がいい特徴がある。

【5】更に、Agile開発と構成管理手法を絡めると、緊急リリースをタスクブランチとして実現することもできる。
そのやり方は下記に書いた。

変更要求に対する選択肢: プログラマの思索

つまり、本番リリースブランチやtrunkとは別に、新たなバージョンを計画して、タスクブランチ上で突発的な改善要望を実現するやり方。
割り込みのバージョンを意図的に作り出して、顧客の要望とシステムの品質という相反する要素を実現しようとする。
分散バージョン管理のように、強力なマージ機能があれば、とても実現しやすいはず。

ソフトウェア開発は、頻繁にリリースしながらVerUPするたびに、機能も品質も改善していくのが王道だと思う。
例えば、AppleはiPodという製品から、iPhone/iPadという製品を派生させてVerUpさせながら、機能も品質も拡張してきている。
MSもOffice製品やWindowsOS、IEのように、Ver3.0になって初めて使い勝手も品質もよくなると言われていた。
GoogleのWebサービスも永遠のベータ版のまま、頻繁にリリースしてVerUpしながら、機能も品質も改善し続けている。

頻繁なVerUpがソフトウェア開発の本質ならば、その変化を開発者の手のひらに収まるように制御するノウハウが重要になってくる。
そのノウハウが最近になって、色々出尽くしてきたような気がする。