プログラマの思索

2010年を迎えるに当たり、ITの地殻変動がどこに起こっているのか？を考えてみる。
＃自分の理解した範囲内のラフなメモ書き。

【過去の記事】
第二期アジャイルムーブメント: プログラマの思索

「塹壕よりScrumとXP」

チケット駆動開発はアジャイル開発の実装である: プログラマの思索

ITの地殻変動はどこで起きているのか？～2009年: プログラマの思索

ITの地殻変動はどこで起きているのか？～SeasarとRuby、そしてPF～2008年: プログラマの思索

ITの地殻変動はどこで起きているのか？～2006年: プログラマの思索

【Agile1.0の登場と課題】

2000年頃出現したXPによって、初めてアジャイル開発が開発者へ認知されたように思う。
XPは従来のウォーターフォール型開発のアンチテーゼとして、特に開発者に熱狂的に受け入れられた。

XPの最大の特徴は、繰り返し開発の実践プラクティスを現場の開発者へ提示したことにある。
また、テスト駆動開発(TDD)、継続的インテグレーション(CI)のように、その後の開発スタイルを変える手法も編み出された。
これらは、今となっては普通のプラクティスの一つまで普及した。

今振り返ると、XPのプラクティスの中で最も重要な概念は、小規模リリースだと思う。
繰り返し開発というアイデアは従来から知られていたが、その思想を具現化すると、小さい機能単位に分割して順次リリースしていくというスタイルが最もリスクが少なく、確実だ。

小規模リリースの利点は、変化をイテレーションと言う単位に押し込めれば、変化を受け入れることが可能なこと。
突発的なタスクの変更、仕様の追加は、小規模リリースのおかげで「変化を抱擁する」ことも可能になる。

つまり、小規模リリースは漸進型開発の主要な思想であり、繰り返し開発の中でも漸進型開発が最も実現しやすいことを示唆していた。

その後の繰り返し開発の流派においても、小規模リリースの影響は色濃く見られる。
小規模リリースの開発スタイルは、特にオープンソースの世界ではとても当たり前になった。

しかし、XPはその熱狂さとは裏腹に運用のハードルは高かった。
よく言われる問題点は二つある。
一つは、大規模プロジェクト、大規模チームのようなスケールアップが難しいこと。
もう一つは、アーキテクチャ重視、品質重視のプロジェクトでは、小規模リリースが有効に作用しないこと。

前者は、サブチームごとにイテレーションを実施しても、複数のサブチームのモジュールを結合するイテレーション無しではうまいかないことを示唆している。
大規模になるほど、複数のサブチームのイテレーションの同期を取るのが難しい。

後者は、イテレーションというタイムボックス形式の開発では、アーキテクチャや品質を作りこむのは難しいことを示唆している。
RUPはアーキテクチャ重視の繰り返し開発なので、反復型開発というもう一つの繰り返し開発のプロセスを編み出したが、これはスコープの管理が非常に難しい。
実際は1回のイテレーションしか行わない場合が多いから、結局ウォーターフォール型開発と何ら変わらない。

上記のように、初期のアジャイル開発で試行錯誤した頃をAgile1.0と呼んでおく。

【Agile2.0の舞台要素】

アジャイル開発とは別に、PMBOK、ITIL、ソフトウェアプロダクトライン(SPL)という流れも2000年代に広く普及した。

PMBOKはプロジェクトマネジメントのフレームワークを知識体系化したもの。
PMBOKを読んで衝撃的だったのは、QCDを含めた全般的なマネジメントの知識体系よりも、スコープ管理を重視していること。
特に品質管理では、スコープを超えた品質重視は「金メッキ」と呼ばれ、無駄と言っている。
即ち、スコープ・コスト・納期・品質などのバランスの中で、品質を重視する。
品質重視のあまり、コストをかけすぎたり、納期に遅れるのは、ビジネス上無意味であると主張している。

ITILはIT運用保守のフレームワーク。
従来の運用保守と異なる点は、問題(障害)管理とインシデント管理を区別していることと、変更管理でプロセスを手続き化していること。
前者は、障害と単なる問合せを明確に分離し、実際の開発チームの業務に支障が出ないようにする。
後者は、変更要求(RFC)に対し、利害関係者が変更諮問委員会(CAB)を開き、優先順位や作業手順などを決めて、計画を立てるプロセスを明確化した。

このITILの考え方は、チケット駆動開発でも非常に参考にした。
BTSは本来バグ管理システムであるから、ITILの発想と非常に相性がよい。

SPLは特に複数の製品ファミリーを持つソフトウェア開発、例えば組み込み製品やパッケージ製品の開発で行われる開発手法。
共通部品や共通アーキテクチャであるコア資産と製品独自の部品であるアプリケーション資産に分離し、別々に管理することで制御する発想。
この発想も従来から知られていたが、体系化されて認知され始めたのが2000年代だと思う。

SPLの開発プロセスはウォーターフォール型開発や反復型開発に似ている部分がある。
特に、SPLは、ソフトウェア開発は本質的に、複数のコードラインを保守せざるを得ない並行開発である、と暗示した点が重要だと考える。

つまり、組み込み製品やパッケージ製品だけでなく、Webシステムや業務システムでも、並行開発はもはや当たり前の開発スタイル。
並行開発の最大の弱点は、複数のコードラインの品質を維持するのが非常に難しいこと。
普通は1つの変更が複数のコードラインへ影響するため、開発中の機能と衝突しないようにマージするのは非常に難しい。
おそらくGitやMercurialのような分散バージョン管理を導入しない限り、根本的な解決には至らないだろうと思っている。

そんな中、Scrumというアジャイル開発手法が広く普及し始める。
Scrumの最大の特徴は、繰り返し開発の中でも漸進型開発のプロセスフレームワークを提示した点にあると思う。
スプリント計画でスプリント(イテレーション)で実現する機能を決めて、そのスプリントでは他の変更は受け入れない。
そのScrumチームには明確な役割と厳格な規律があり、スプリント単位に小刻みにリリースしながら、システムを少しずつ作っていく。

Scrumはプロセスを重視しているから、特にマネージャ層に受け入れられた。
この点にアジャイル開発に対する大きな貢献があると思う。

ScrumがXPと異なる点は、「塹壕よりScrumとXP」にもあるように、スケールアップやアーキテクチャ・品質重視の課題に対する回答の一つを提示したことにある。

スケールアップのために、サブチーム単位のイテレーション同士で同期を合わせる。
リリース後の障害修正が発生した場合、暫定的なイテレーションを作り、品質改善の作業に取り組む。

Scrumでも上記2点の課題に完全に対応できているわけではないが、色んなノウハウを試そうとしているように思える。
そして、Scrumのおかげで、アジャイル開発の運用のハードルはかなり下がってきているように思える。

後もう一つは、平鍋さんが提唱したPF(プロジェクトファシリテーション)だ。
これは日本人がアジャイル開発から編み出した手法として重要だと思う。

PFは、従来のプロジェクト管理手法が見過ごしていたコミュニケーションや人間重視の発想をサポートする。
PFが普及し始めた理由は、チームビルディングがソフトウェア開発で重要だと認識されたからだろう。

昨今のソフトウェア開発では、3～12ヶ月で新規メンバーを集めてチームを形成して、リリースしていく。
この時、かき集めたメンバーをチームとして一体化させて有機的に活動させるのは至難の業だ。
PFはチームビルディングのプラクティスに優れているように思う。

【チケット駆動開発の役割】

上記のような流れをAgile2.0と呼ぶならば、チケット駆動開発(TiDD)もその流れに含まれる。
チケット駆動開発は、まちゅさんがTracのチケット管理から提唱した手法で、Tracのチケットでソフトウェア開発のタスク全般を管理しようと言うスタイル。
これは、BTSをITS(Issue Tracking System)として扱う点として画期的だと思う。

そして、僕はRedmineにチケット駆動開発を導入する時に下記をアレンジした。

１・BTSのチケットをXPのタスクカードのように扱う
２・BTSのチケット一覧をXPのタスクボードのように扱う
３・SVNコミットログにチケットNoを必ず書く
４・チケットをバージョンでグルーピングし、順次リリースしていく

１はIssueTrackingと呼ばれるもので、チケット(Issue)でタスクの状態や進捗を追跡する。
２はチケット集計機能を生かして、ガントチャートやカレンダー、ロードマップなどを生成して、進捗管理に使う。
１と２は、さかばさんからアドバイスを受けて、気付いた点がある。

３は、まちゅさんが「No Ticket, No Commit!」と呼んでいるプラクティスで、チケットとSCM配下の成果物をリンクすることで、成果物の変更をチケットで追跡できるようにする。

４はいわゆる小規模リリース。リリース予定バージョンをXPのイテレーション、Scrumのスプリントと見なして、小刻みにリリースしていく。

TiDDの最大の利点は、突発的なタスクの変更に対応できることと、タスクの最新化・集計を自動化できるので進捗管理や品質管理をサポートしていることだ。
上記を基本ルールとして運用していくうちに、チケット駆動開発がアジャイル開発のインフラになって入るのに気付いた。

そして、チケット駆動開発はPFのプラクティスとも相性がいい。
特に、朝会やふりかえりはTiDDの運用の中で自然に生かせるし、かんばんはステータスごとのチケット集計機能として簡単に得られる。
つまり、TiDDはPFをデジタル化してくれる。

また、Agile2.0で出てくる各種技法もTiDD上で実現できる。
ITILの各プロセス、PMBOKのEVM、SPLによる並行開発も、TiDD上で試してみると、結構うまくいく。
机上の知識に過ぎなかったものが、TiDD上では一機能として実現できるはずと確信している。

これらの要素を試しながら、TiDDの可能性を考えると色々ある。
TiDDは、Agile2.0において、それらの開発インフラとして黒子役を担うはず。

TiDDで今後最も面白いと思うのは、BTSを中心として各種ツールと連携すること。
分散バージョン管理Mercurial、Gitと連携して、トピックブランチをRedmineで管理。
CIツールHudsonと連携して、チケットからビルドモジュールまでの追跡を可能にする。
テスト管理ツールTestLinkと連携して、バグ修正をRedmineで管理。
コードレビューWebシステムReviewBoardと連携して、ワークフローはRedmineで管理。
StatSVNやStatCVSと連携して、SCMメトリクス出力を行う。

多分他にも色々考えられるし、それらのツールと連携することによって、ソフトウェア開発のプロジェクト管理支援を行う。
TiDDにSW工学の知識を導入して、従来のアジャイル開発を更に補強できるのではないか？