ITの地殻変動はどこで起きているのか？～チケット駆動開発が進むべき道

2011年になって、ITの地殻変動がどこに起こっているのか？を改めて考えてみる。
ラフなメモ書き。

【元ネタ】
チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07)

チケット駆動開発が進むべき道part1～ソフトウェア開発のベストプラクティスをオープンソースのツールで実現する: プログラマの思索

チケット駆動開発が進むべき道part1～ソフトウェア開発のベストプラクティスをオープンソースのツールで実現する: プログラマの思索

現代のAgile開発が抱える課題: プログラマの思索

Agile開発が指摘したソフトウェア開発の特徴: プログラマの思索

【ソフトウェア開発の課題】
ソフトウェアは変化するのが宿命。
ハードがこれだけ日進月歩で進化しているのに、VerUpしないソフトウェアは価値がない。

しかし、SW開発はとても繊細。
たった1行のソース修正でシステムはすぐに動かなくなる。
ハードやOS、ブラウザを安易にバージョンアップすると、システムは不安定になる。
ソフトウェア開発は製造業よりもはるかに繊細だ。

だから、変更管理が重要。
どのコンポーネント、どのソースをどのように直したのか、どのモジュールをリリースしたのか、をきちんと記録して、あらかじめ作業手順をレビューして承認していくフローが必要になる。
だが、そのワークフローは大量のドキュメントとたくさんの承認フローによって、すぐに重厚長大となり、ソフトウェア開発の速度を落とす。

開発案件が大規模になるほど、承認フローや意思決定が複雑になる。
サブシステム間の課題や作業のやりとりをチームレベルではなく、もう一つ上の層で意思決定する場が必要になってくる。
従来の課題管理会議では、開発チームのリーダークラスが集まって、チーム間の課題やプロジェクトの方向性について議論して、組織としての方針を決定する。
しかし、大規模化するほど、会議は長引き、決まるのが遅くなり、組織そのものの進捗も遅くなる。

だが、ソフトウェア開発の本質から生じる上記の諸問題に対し、アジャイル開発は過激な主張を持って解決しようとしている。
「変化を抱擁せよ」のキャッチフレーズ通り、アジャイル開発の最大の特徴は変化に強いこと。
XPが提唱するソースの共同所有、テスト駆動開発、継続的インテグレーション、小規模リリースなどのプラクティスによって、開発者が作業するインフラが整う。
そして、Scrumが提唱するバックログ、スプリントなどの諸概念によって、アジャイル開発のプロジェクト管理のフレームワークも整った。

しかし、アジャイル開発の最大の弱点は、従来の環境のままでは変化が激しいタスク管理やイテレーション管理を制御するのが難しいこと。
そして、アジャイル開発の事例は小規模プロジェクトが多かったため、つい最近まで、大規模プロジェクトではアジャイル開発は適用しにくい、アジャイル開発は設計や品質の作り込みが弱い、と言われ続けてきた。

【チケット駆動開発の意義】
チケット駆動開発はTracのチケット管理から生まれた。
発端はまちゅさんが提唱されている。

チケット駆動開発の特徴は、BTS(バグ管理システム)のチケットを障害だけでなく、仕様変更やリリース作業などあらゆるタスクを管理する方向へ拡張した点にある。
これがいわゆるIssue Trackingと呼ばれる特徴だ。
だから、TracやRedmineはBTS(Bug Tracking System)ではなく、ITS(Issue Tracking System)と呼ばれている。

そして、チケット駆動開発の最大の意義は「BTSチケットをXPのタスクカードのように扱う」ことによって、アジャイル開発のプロジェクト管理に応用できる点にある。
＃この発想はさかばさんが提唱された。

TracやRedmineでは、単にチケットを障害管理に使えるだけでなく、ガントチャートやカレンダーなどの進捗管理機能、ロードマップやリリース履歴などのリリース計画機能、チケットの種類(トラッカー)に応じた柔軟なワークフロー管理、構成管理との連携によるトレーサビリティ、チケットの集計機能を使った品質管理機能など、各種の機能が豊富にある。

BTS(ITS)の優れたプロジェクト管理機能を使って、アジャイル開発のプロジェクト管理を容易に構築して、更にブラッシュアップすることも可能になった。

この発想は、生物進化の前適応の話を連想させる。
前適応とは、ある適応された形質が形作られる場合に、以前から存在した別の機能を持つ形質が用いられたことを指す。

前適応 - Wikipedia

大量絶滅 - Wikipedia

前適応の例は、恐竜から鳥へ進化した経緯が分かりやすい。
恐竜は、数億年前、生物の大絶滅で酸素が急激に減った環境から生まれた。
そのため、恐竜は低酸素の環境でも生存できるように、気嚢と呼ばれる優れた酸素ガス交換機能を持つようになり、その機能が鳥にも引き継がれた。
実際、鳥を解剖してみると、気嚢とよばれる器官が肺から体中に伸びていて、新鮮な酸素を体中に行き渡らせることができているらしい。
その機能のおかげで鳥は、ヒマラヤの高山の空という低酸素の空間でも飛ぶことができる。

更に、小型化した恐竜は体温を維持するために、羽毛を持つようになった。
その羽毛が翼に進化して、鳥は飛べるようになったという説がある。

つまり、鳥が持つ気嚢や羽毛は、本来恐竜が生存していくために作り出した機能だったが、鳥はそれらの機能の目的を変えて、自分たちの都合の良い機能へ意味を変えたわけだ。
だから、鳥は生きた恐竜の化石とも呼ばれているらしい。

前適応の話を聞いて、障害管理からチケット駆動開発へ発展した話と全く同じ構造を持っているような印象を持った。
チケット駆動開発の特徴であるプロジェクト管理機能(チケット管理、進捗管理、構成管理やビルド管理との連携によるトレーサビリティ機能、強力なワークフロー管理など)は、本来は障害管理に必要な機能として発展してきたのだが、目的を変えるだけで、アジャイル開発のプロジェクト管理にも使える、と世界中の人達が気付いたわけだ。
そして、世界中の開発者が、アジャイル開発のプロジェクト管理を実現するツールをどんどん作り出している。
その可能性はとてつもなく大きいと思っている。

【チケット駆動開発の可能性】
僕が今後試してみたいのは、Redmine上でチケット駆動開発を行う事によって、アジャイル開発の運用のハードルを下げるだけでなく、アジャイル開発の新しい運用方法も提唱してみたいことだ。
チケット駆動開発にXP・Scrum・CMMI・PMBOK・ITIL・SW工学・原価計算・PFなどの知識を詰め込んで、チケット駆動開発を理論として強化していきたい。
Redmineを単なるプロジェクト管理ツールだけでなく、SW開発の全ての業務を支援するツールへ高めたいのだ。

つまり、XP・Scrum・CMMI・PMBOK・ITIL・SW工学・原価計算・PFなどの理論や概念は本来それぞれの目的があるだろうが、チケット駆動開発を支援するための手段や道具とみなして、チケット駆動開発をソフトウェア開発の体系的な理論として骨付して肉付けしていきたいのだ。

ラフなイメージは下記の通り。
以下は書きかけ。
少しずつ考えていきたいと思っている。

【1】ロードマップによるリリース計画作り
　小規模リリース
　イテレーションとリリース予定バージョンを同一視する
　タイムボックス的な開発
　漸進型開発と反復型開発の違い

【2】バックログによる要件管理
　要件のイテレーション管理
　　チケットの親子関係
　　　RedmineのSubstasking
　　期限の無いリリース予定バージョンで管理する方法もある
　　チケットをイテレーション間で移動する
　サスペンドリンク
　　要件変更の影響範囲
　　仕様変更の工数を予測可能になる

【3】SCM連携によるトレーサビリティ
　レコメンドエンジンの実装
　　ソース修正時に過去に修正した関係ソースやチケットを表示する
　　同類バグの調査
　　設計漏れをなくす
　分散バージョン管理との連携
　　構成管理パターン
　　　ブランチ管理
　　　マージ機能
　　イテレーションとコードラインの関係性

【4】テスト管理ツールとの連携、ビルド管理ツール、コードレビュー管理ツールとの連携
　メトリクスの使い方
　　信頼度成長曲線
　　　SRATS
　　テスト消化曲線
　　　TestLinkCnvMacro
　品質管理の考え方
　　ブロックやみなしバグの影響範囲を示唆する
　　同類バグの範囲を自動的に示唆する
　移植性
　　再利用性
　　ソフトウェアプロダクトライン
　　派生開発
　　XDDP
　保守性
　　リファクタリング
　　変更容易性
　コードレビュー
　ビルド管理
　　並行ビルド
　　本番環境の仮想化
　RestfulAPI
　　外部ツールと連携
　　エンドユーザコンピューティングのためのクライアントツールと連携

【5】ワークフロー管理
　変更管理の考え方
　　自然なペア作業
　　チケットをCloseする時は必ず二人の目を通す
　ITILの考え方
　　サーバー監視ツールが障害を検知したら、メール送信する時にチケットも自動登録
　　Hudsonがビルドエラーを検知したら、メール送信する時にチケットも自動登録
　　トラッカー単位に集計してプロセス改善
　　オペレータが対処できないチケットは、上位管理職へエスカレーションする
　ワークフローの可視化

【6】大規模アジャイルの運用方法
　アジャイルリリーストレイン
　スクラムオブスクラム　
　アーキテクチャ助走路
　分散開発は？
　　プロジェクトファシリテーションを分散開発のチームビルディングへ拡張する

【7】PMBOKのEVM、活動基準原価計算(ABC)
　予定・実績工数の管理から原価管理
　プロジェクトの製造原価、コスト、利益をシミュレーションする

【8】PMBOKの応用
　クリティカルパスの計算
　ボトルネックの探索
　PMIS
　アジャイル開発のプロジェクト管理の概念をPMBOKで支援する

【9】PF(プロジェクトファシリテーション)のプラクティスと連携
　朝会
　KPTによるふりかえり
　　プロセス資産
　ニコニコカレンダー、かんばんをデジタル化
　オフショア開発のように場所が離れた場合のチームビルディング方法
　　オープンソースでは当たり前

【10】Excelをエンドユーザコンピューティングとして使う
　マネージャや顧客が欲しいデータはCSVで渡せばいい
　　好きなようにカスタマイズしてくれればいい
　　何も全ての機能をRedmineで実現する必要は無い
　　　業務システムが全帳票を作る必要はなく、CSVでデータ提供する機能を実装しておくのと同じ