Redmine on JRuby

プロジェクト管理機能を持つBTSであるRedmineを愛用して運用して、技術的に気づいた点をメモ。

【1】RedmineをJRubyで動かす方法が下記の記事で紹介されている。

Redmineを運用するためのイロハを身につけよう
第7回　Javaプラットフォームでの運用

上記の記事は、Glassfish＋JRuby上でRedmineを乗せている。

これは僕の中で最もホットな記事。
JRubyを使ってJavaアプリケーションサーバー上でRailsを安定稼動できるならば、Railsをビジネス用途で使う最大の不安が解消される。

一般のRailsアプリをTomcat上で動かすノウハウも下記で紹介されている。
仕掛けは、RailsアプリをWarblerでwarファイルにビルドして、JRuby＋Tomcatで稼動させる。

Java屋がTomcatでRuby on Railsを試すには？
Warblerでwarのパッケージ化をしよう

ここまでのノウハウが現時点で公開されているので、おそらく来年はRailsを実案件で使うタイミングもあると思う。

【2】Redmine＋Passenger(mod_rails)で、Apache上でRailsを稼動する方法が紹介されている。

Apache上でRuby on Railsアプリケーションを動かす
／Passenger(mod_rails for Apache)の利用

下記のコマンドを叩くだけで必要なライブラリがApacheにインストールされる。

gem install passenger
passenger-install-apache2-module

後は、httpd.confの設定だけ。
高負荷な使い方をしていないので分からないけど、結構安定しているし、レスポンスもいい。

Passengerの利点は、RailsがPerlやPHPと同じ感覚で運用できることだ。
Apacheは運用ノウハウや運用経験者が多いので、データセンターで運用する時にも利点になる。

今後のビジネスを考えると、業務アプリのRailsをJRubyで動かすか、Apacheで動かすか、どちらかが主流になると思う。
どちらも要注目の技術だと思う。

チケット駆動開発はアジャイル開発の実装である

【1】下記の記事を読んで、Redmineによるチケット駆動開発はアジャイル開発の実装なのだ！と改めて認識して震えた。
下記の記事はスクラムの話なので、Redmineによるチケット駆動開発と直接関係ないけれど、考えたことを書く。
＃あくまでも感想。

塹壕より Scrum と XP

◆Scrum and XP from the Trenches v.2.2　日本語訳（PDF)ダウンロード

1.Scrumのスプリント計画はRedmineのロードマップと同じ。
どのスプリントにどのストーリーを入れるか、という話は、どのバージョンにどのチケットを入れるか、という視点に置き換えられる。
XPならイテレーション計画に相当するだろう。

2.チケットの取捨選択の基準は、スコープ、重要度、見積の三角形だ。
品質を下げることは許さない。

お客はスコープ、重要度の決定権がある。
開発者は見積の決定権がある。
品質は開発者が保証するものだが、品質を下げれば、全ての作業が泥沼にはまるから、それは条件に入れない。

見積もりがお客の意見と合わなければ、スコープや重要度を変更すると書かれている。
この意見は同意する。
チケットの取捨選択の基準は、結局、実現する機能を分割して削るか、優先順位付けして削るしかないのだと思う。

無理して開発しても、デスマーチになって、品質が下がって、そのプロジェクトは誰もコントロールできなくなる。

3.スプリント計画の長さは3週間らしい。
記事では、色々試して固定してみろ、と書かれている。

僕の感覚では、ロードマップのバージョンの期間は1週間単位にしている。
つまり、月曜から作業を始めて、金曜には結果が出るようにしている。
できるだけチケットの作業は細かくした方が、開発者は動きやすいみたい。
1週間でできなければ来週に回す。

スプリントの長さは、開発チームや工数の規模で異なってくるだろう。

4.見積もり速度の話も面白い。
これは、稼働率に相当する。

1日8時間の労働とみなしても、実際の稼働率は1日6時間のことも多い。
トラブル続出で電話対応していたら、1行のプログラムも書けずにそれだけで1日が終わる。
普通は、仕様書を読んだり、ミーティングがあったり、稼働率は落ちる。

5.Techストーリーは非機能要件のタスクで、この作業を意識している。
環境構築、ビルド作業、テストデータ作成などのタスクが相当するだろう。

これらの内部作業は、お客様には見えないけれど、開発チームにとって重要だ。
だから、この工数やコストも考慮に入れる必要がある。

6.スプリントバックログこそがRedmineのチケット変更記録だ。
つまり、ステータス＝終了となったチケットの履歴一覧。

この記録から、バーンダウンチャートを描くことは可能。
「バーンダウンチャート」とは、受入テストを通過した要求数を差し引いた未完了の残要求数を
下向きグラフ化したもの。
プロジェクトファシリテーション(PF)のツールとして頻出される。

バーンダウンチャートで進捗を見える化する

残工数で進捗を把握する意味でCCPM的発想とも言える。
つまり、後何日で開発が終わるか、バーンダウンチャートが書ければ予想できる。

Redmineにはバーンダーンチャートは存在しないが、DBにチケット情報があるからプログラムを書けば実現可能だ。

7.「今日何をするか判らない」の人の扱いが面白い。

もしそれほど重要でないのなら、チームから外すようにしよう。
もしその人物が重要なら、「導き手」役のできる誰かとペアを組ませるようにしよう。

アジャイル開発といえども厳しさはある。

8.スプリントの振り返りの話も面白い。

僕は、Redmineのチケット集計結果を連想した。
Redmineでは、トラッカー・開発者・機能別などでチケットの状態などの集計結果を見ることができるから、これを見ながら振り返りができる。
リポジトリ欄の統計を見れば、開発者ごとの月別のリビジョン・コミット回数のグラフがあるから、誰が一番貢献したか、すぐに分かる。
ソフトウェア工学の知識を有効に使って、振り返りを使えば、改善点を洗い出せる。

9.この言葉にしびれた。

継続的な設計の改善は、殆どTDDの実施による自然な副産物なんだ。

10.「多分受け入れテストフェーズは回避できない」章はロードマップ作成の要注意点だ。
「Scrumチームから提供されるコード品質の最大化」のためには、下記2点が有効だという。

10-1.テスタをScrumチームに参加させる

実際の業務シナリオに沿うから、受入テスト時は手動テストが多いし、そうならざるを得ない。
その時に、選任のテスタがいれば、プログラミングでないタスクを彼が拾ってくれる。

10-2.スプリント毎の作業を減らす
チケット駆動開発を実践すると、基本は「チケットを捨てる」のが重要になってくる。
納期は決まっているのだから、作業を優先順位づけして、最優先の作業から始めて、残りは捨てる。
実際は、優先順位の低いチケットは延期する。

全ての作業(チケット)を終了させようとすれば、納期間近になった時に一つも作業が完了できていないだろう。
優先順位の決定がない完璧主義は悲惨な結果をもたらす。

特にデスマーチプロジェクトでは、タスクが溢れてしまって、完了した作業よりも積み上がる作業の方が多いだろう。
火消し役のリーダーは、まず、各メンバーにアサインされたタスクを全て降ろして気持ちを楽にさせた後、タスクの棚卸しから始めることだろう。

チケットの状態をリアルタイムに正確に把握する所から、プロジェクト管理は始まる。

11.「スプリントサイクル VS 受け入れテストサイクル」は、チケットの取捨選択の基準の一つを示している。
つまり、新規機能の開発よりも、バグ修正を優先すること。

チケット解決の優先順位の基本パターンなのだ。

12.「どうやって複数のScrumチームをハンドルするか」「チームを特化するか…否か？」はチーム運営の観点から非常に面白い。

僕は大きなチームの不利な点を踏まえてなお、一つのチームに拘るつもりだ。

13.「コードブランチ」の章は、ソース管理のブランチモデルの話。
元ネタはここだったかもしれない。

【2】もう一つ面白い記事がある。
下記の記事は、スクラムを中国で導入して成功した例と失敗した例を分析している。

改善、成功と失敗: 中国でのスクラム導入

記事によると、スクラム導入の成功と失敗の違いは、上層部の支持があるか、そして、メンバーがスクラムの概念を理解しているか、という点。
だが、スクラム導入よりも、会社やチームに改善プロセスを生む能力があるかどうか、に鍵があるような気がする。

継続的インテグレーションのメモ

継続的インテグレーション(常時統合・Continuous Integration)に関する記事をメモ。
開発の進捗はビルドプロセスと密接に関連するし、比例している。

デイリービルドは君の友達(Joel on Software)

デイリービルドは自動化された、毎日行われる、完全なソースツリー全体のビルドのことだ。

プログラマが修正したと考えている問題をテスタが指摘したとき、テスタはどのビルドでその問題が観察されたかを言うことができる。
プログラマはいつ修正をチェックインしたか調べて、それが本当に修正されているか見当をつけることができる。

継続的インテグレーション(Martin Fowler)

普通の人は、コンパイル作業とリンク作業のことをビルドだと考えている。
しかし私たちは、ビルドには少なくとも「アプリケーションを実行すること」「簡単なテストを行うこと」まで含めるべきだと考える。
(中略)これらに加えて、さらに徹底的なテストを行えば、継続的インテグレーションのもたらす価値はより大きなものとなるので、それも併せて行うほうが望ましいだろう。

自動化されたビルドを採用すると、開発者は、ある「リズム」に従ってソフトウェアの開発を行うようになる。
このリズムの最重要パートは、インテグレーションを「定期的に」行うこと、である。
我々が訪れたある部隊では、デイリービルドを実践してはいたが、チェックインは頻繁になされていなかった。
数週間おきにしか開発者がチェックインしないのであれば、デイリービルドを実践しても意味は薄いだろう。
我々のところでは、どの開発者もだいたい一日一回はチェックインを行う、というおおまかな指針を立てている。

CIツールHudsonを使いこなす

XPのプラクティスの一つが常時統合(CI・Continuous Integration)。
別名、デイリービルドと言われる。
第2世代CIツールと言われるHudsonを使って運用して、常時統合の概念について改めて書く。
#Hudsonの全機能はまだ使いこなせてないので念のため。

【1】バージョン管理(SCM)＋常時統合(CI)＋テスト駆動開発(TDD)で、初めてアジャイル開発が可能になる

【元ネタ】
バージョン管理と常時結合

豆蔵：継続的インテグレーション（CI）をしましょう

Subversionでbranches/tags/trunkでソース管理したら、次に行うべき環境構築はビルド環境。
Javaなら、Ant/Mavenでワンクリックでビルドできるようにスクリプトを作る。

今でもビルドする時に、Eclipseから手作業でビルドしているプロジェクトもままある。
ローカルマシンで手作業でビルドする弱点は、そのローカルマシンが使えなくなったらビルドできなくなること。
普通はプロジェクトリーダーがビルドとリリース作業を担当するから、彼の開発環境特有のノウハウがあったり、JDKのバージョンがマシンごとに違ったり、彼が夏季休暇でいなくなると、緊急リリースできなくなる。

だから、ビルド環境は開発サーバーで構築したい。
そうすれば、誰でもリリース可能になるし、誰がビルドしても同じバイナリのモジュールが作れる。
ビルドスクリプトもSVNでバージョン管理しよう。
そのビルドスクリプトに、JavaDoc生成、JUnit実行、各種レポート出力もあると、リリースするモジュールを作るだけでなく、納品ドキュメント一式も出力するといった作業も一発で自動化できる。

ビルド環境ができたら、SVNコミットするたびに常時統合するようにしよう。
常時統合の最大の利点は、SVNリポジトリがいつでもリリース可能である状態を保てること。

複数の開発者が一つのシステムを開発する時、インターフェイスが合わないことも知らずにSVNコミットする時がある。
常時統合するビルド環境があれば、ビルド後コンパイルエラーとしてすぐに通知できる。
更には、ビルド時に、コンパイルエラーだけでなく、テストユニットが全て通ることも必須にすれば、物理的だけでなく、仕様を満たすという意味で論理的にも正しいモジュールが作れることを意味する。
昨今のCIツールでは、画面上で結果を表示したり、メール通知したり、RSS表示などで通知してくれる。

つまり、常時統合の概念がないウォーターフォール型開発では、

コーディング→単体テスト→ビルド

の順に進んで、最後でエラーが分かるのに対し、常時統合環境ならば、ビルド時にJUnitを通過させることで単体テストも通ったプログラムかどうかチェックできる。

SCM＋CI＋TDDで初めて、プログラマ主体のアジャイル開発環境ができあがる。

【2】Hudsonはすごくお手軽で強力なCIツール

CIツールは、Continuum、CruiseControlなどあるが、第2世代CIツールと言われるHudsonを使ってみたらすごく使いやすい。
下記の記事が詳しい。

Hudsonを使ったアジャイルな開発入門

Hudsonの最大の特徴は、日本人技術者が作っているので日本語化されていること。
又、warファイルで提供されているので、Tomcatへデプロイすればすぐに操作できるのでインストールが簡単。

上記の記事を読みながら、まだ使いこなせてないが、興味深い機能について下記にまとめる。

【3】Hudsonの特徴～ビルドプロモーション

Hudsonを使ったアジャイルな開発入門
第4回　プラグインを使う
ビルドプロモーションとプラグイン

Hudsonを使ったアジャイルな開発入門
第4回　プラグインを使う
シナリオ

大規模プロジェクトで複数の開発チームでビルドしているとする。
その場合、複数のビルドモジュール(例えば、jar又はWindowsのDLL)を作り、それらを一つの実行ファイル(例えば、war又はWindowsインストーラ)にまとめることが多いだろう。

大規模プロジェクトの成功が非常に難しい理由の一つに、ビルドプロセスがうまく運用できない点がある。
例えば、チームAが作ったライブラリにインターフェイス追加の仕様変更があったのに、他チームが対応していなければビルド時にコンパイルエラーになる。
でも実際は、新規のインターフェイスに対応するのは後回しでも良い時があったりする。
チーム間のコミュニケーションで風通しが悪いと、よく起こる。

あるいは、バグ修正や仕様変更などでインターフェイスが大きく変わってしまったけれど、他チームでは、一部の新しいインターフェイスだけ欲しい時がある。

また、ビルドを通した時に、ビルドは成功するがいくつかのUnitTestは通らないけれど、そのビルドモジュールが他チームでは開発上必要な場合もよくある。

そんな時に、ビルドプロモーション機能を使う。
つまり、ビルドモジュールに、優良・不良・最終用などの状態で色付けする。
Hudsonでは、ファイル指紋という機能があり、ビルドモジュールを一意に峻別してバージョン付けすることもできる。

特に昨今のWebシステム開発はスピード重視なので、完全なビルドモジュールでなくとも、一部のインターフェイスが通るだけのライブラリがあれば、サクサク開発できる時も多い。

上記の記事では、下流ビルドのチームが上流ビルドのチームへ、これこれのバグを修正したモジュールだけ欲しいと依頼して、ビルドしたライブラリを作ってもらうという話がある。
そんな時に使えるだろう。

【4】Hudsonの特徴～分散ビルド

Hudsonを使ったアジャイルな開発入門
第3回　Hudsonによるチーム間の連携
分散ビルド

ビルドするライブラリが多くなると、最終形式のリリースモジュールを作るまでに1時間近く実行時間がかかる時がある。
特に大規模プロジェクトほどそうなるだろう。
ビルドに時間がかかると、開発者はソースコミットが慎重になり、プロジェクト全体の活動が低下して進捗がどんどん遅れる。

Hudsonには分散ビルドという機能があり、複数のビルド環境と連携して、ビルド作業を並列に実行することができる。
つまり、ビルド作業を直列ではなく並行実行することで、見かけ上のビルド時間を減らす。

詳細な設定方法は上記の記事に書かれているが、大規模プロジェクトでは非常に有効な機能だ。
特に昨今のWebアプリのように、クライアントアプリとサーバーアプリで共通ライブラリをくくりだしてビルドする場合、たった1行のソース変更で、ユニットテストも通すからビルドが1時間かかることも稀ではない。
サーバーはとても安くなったので、古いサーバーをビルド環境にして並列ビルドできれば、複数のチームによる開発でもアジャイル開発できるはずだ。

【5】Hudsonの特徴～マルチ構成プロジェクト

Hudsonを使ったアジャイルな開発入門
第5回　高度なプロジェクトタイプ
マルチ構成プロジェクト

この機能は、ハードウェアやJDK等のバージョンは違うけれど、同じビルド作業を行う時、同一のビルド設定情報を使って、複数の環境でもビルドできるようにすること。

本番環境のJDKのバージョンアップ、ハードウェアのリプレースでOSなどの環境が変わった時、この機能を使えば、Hudsonが色んな構成方法でビルドして結果を出力してくれる。

特にWindowsアプリのように色んなOSでビルドできることを確認したい時、あるいは、WebアプリでJDKのバージョンアップしてもきちんとビルドできるかを試したい時に使えるだろう。

ハードウェアやJDKのバージョンアップは、長期間続くプロジェクトでは避けられない。
だから、Hudsonの上記の機能は非常に使える。

【6】HudsonとBTSを連携する

昨今のBTSではコミットログにチケットNoを書くと、BTSチケットとソースリビジョンが紐づけできる環境がある。
Hudsonでも、ビルド結果にソースのコミットログを表示するので、プラグインを入れると、コミットログのチケットNoからBTSへリンクする機能がある。
これはすごく便利だ。

TracLightningでは、Hudsonが既に組み込まれている。
他にも、Bugzilla、Mantis、Trac、JiraなどのBTSと連携するプラグインがある。
残念なことに、RedmineはHudsonと連携するプラグインがない。
単にURLを設定するだけなので簡単だと思うが。。

常時統合という概念を生み出したXP。
CIツールとBTS、バージョン管理を上手に使えば、アジャイル開発を簡単に楽しく実現できるはずだ。

ジョエルテスト

ソフトウェア開発チームの質を3分で評価するテストがある。
ジョエルテストと言われるものだ。

ジョエル・テスト

質問は12問あり、Yes又はNoで答える。
質問内容も至ってシンプルだ。

1.ソース管理システムを使っているか？
2.１オペレーションでビルドを行えるか？
3.毎日ビルドを行うか？
4.障害票データベースを持っているか？
5.新しいコードを書くまえにバグを修正するか？
6.更新可能なスケジュール表を持っているか？
7.仕様書を持っているか？
8.プログラマは静かな労働環境にあるか？
9.買える範囲で一番良い開発ツールを使っているか？
10.テスト担当者はいるか？
11.プログラマを採用するときにコードを書かせるか？
12.「廊下での使い勝手テスト」を行っているか？

だが、その評価はとても厳しい。

１２点は完璧で、１１点は許せる範囲だ。だが、１０点以下だったら君は本当に深刻な問題を抱えていることになる。実際のところ、大半のソフトウェア開発組織は２点か３点の状態で仕事をしている。そして、彼らは本当に助けを必要としている。なぜなら、マイクロソフトのような会社は常に１２点の状態でいるのだから。

他の会社のジョエルテストは下記に書かれている。
はてなは12点満点、アプレッソは10点だそうだ。

はてなのジョエルテスト

アプレッソのジョエルテスト判定結果

プログラムの書けない手配師の会社の多くは、仕様書は書けても、その仕様書はソース管理でバージョン付けする管理はしていないだろう。

プログラミング技術が低いソフト会社の多くは、ソース管理していても、ワンクリックビルドやデイリービルドできる開発環境はないだろう。

デスマーチに陥っている会社の多くは、お客から苦情や非難の電話やメールが開発チームに溢れて、マネージャだけでなくプログラマも電話対応や無駄なミーティングに時間を浪費して、労働環境は最悪だろう。

日本の大手SIerの殆どは、ソース管理やビルドツールは持っていても、BTSでバグ報告を一貫して管理していないから、いつまで経ってもバグが収束せずに納期がズルズルと遅れているだろう。
また、プログラマの採用時にコードを書かせていないから、プログラマの品質がまちまちでプロジェクト管理が大変だろう。

ジョエルテストのチェック項目を振り返ってみよう。

2-1.XPプラクティスの一つであるコードの共同所有。
Subversion、CVSでソースだけでなく仕様書、ビルドスクリプト、ライブラリもバージョン管理しているか？

2-2.ソースをCIしたら、手作業で何度も間違えながらビルドするのではなく、ワンクリックでビルドできているか？
Windowsアプリのように複数のDLLから成るアプリケーションの場合、ビルドモジュールの依存関係まで考慮するから、ビルドは時間も手間もかかりやすい。

2-3.XPプラクティスの一つである常時統合、つまりデイリービルド。
特に大規模プロジェクトで複数チームがソースをコミットする場合、デイリービルドできていなければ、ソースのデグレが多発するだろう。

2-4.BTSでバグ管理できているか？
最近なら、プロジェクト管理機能を持つRedmineやTracを使うのが普通だろう。
RedmineなどのBTSによって「プロジェクトの見える化」がすごく簡単になる。

2-5.新規機能よりもバグ修正を優先しているか？
Redmineのロードマップでバージョン計画を作ると、チケットを優先順位付けせざるを得ない。
その時の基準がこれに当たる。
最近のオープンソースの開発でよく見られる2系統のバージョン管理戦略では、新規機能のブランチと保守ブランチを使い分けるのが普通だろう。

2-6.リアルタイムに保守されたスケジュールを持っているか？
昔なら、各メンバーにプロジェクトリーダーが逐一確認して、MS Projectでガントチャートを時間をかけて保守せざるを得なかった。
最近なら、Redmineのロードマップや、バーンダウンチャート、バグ収束曲線で簡単にスケジュールを作れるだろう。
まさに「プロジェクトの見える化」。

2-7.最近なら仕様書は、テストソースが相当することが多いだろう。
あるいは、Testlinkのように、シナリオベースのテストケースをBTSのようにWebで管理するシステムを使っているだろう。

2-8.プログラマは、割り込みタスクや雑音に惑わされず、集中できる環境にいるか？
プログラミングもできて環境構築もできるユーティリティプレーヤーほど、割り込みタスクが多くて、生産性が低い時が多い。
プロジェクトリーダーの仕事の一つは、プログラマが集中してプログラムを書ける環境を作ることだと思う。

2-9.Eclipseでコード補完する時に、イライラするぐらい遅いマシンを使っていないか？
デイリービルドできるマシンを用意しているか？
プログラマはマルチディスプレイで仕事しているか？

2-10.バグ修正フローでは、バグ修正する開発者とバグ報告を起票して検証するテスト担当者のペアで行う。
駄目なプロジェクトは、プログラマが設計、実装、テストまで全部やっている。
2人以上の目を通らないソースは、必ず漏れがある。

2-11.ソフトウェア開発チームの生産性は、プログラマの生産性にほぼ完全に依存している。
優秀なプログラマを採用するために、書いたコードで確認しているか？

2-12.「アプレッソのジョエルテスト判定結果」でも書かれているが、ユーザビリティは特に最近のWebシステムでは重要だ。
Ajax、Flex/Air、Silverlightなど、手のかゆい機能を実装する技術が最近は溢れている。
この時に、ペルソナシナリオ法を使うという考えは参考になる。

お客からの問い合わせを何度も受けてくると、そのインシデントの傾向、変更要求の傾向が見えてくるものだ。
その傾向から、顧客のキャラクターをペルソナシナリオ法で分析すれば、仮想的なキャラクター像が出来上がるだろう。
そのペルソナがシステムをどのように使うだろうか？という観点で設計や開発すれば、かなり良いシステムが作れるだろうと思う。

PMBOK/CMMI/ITILなどの重量級の開発プロセスやマネジメントのフレームワークを導入するぐらいなら、ジョエルテストをクリアできるようにチームの環境を整える方が早く問題を解決できるだろう。

日本のECサイトBEST1000

こんなHPがあったのでメモ。

日本のECサイトBEST1000 (2008年5月号 日本のECサイトBEST1000 丸わかりデータベース)

ネットショップ売上高ランキングTOP500
1位～10位（amazon.co.jp／ベルメゾンネット／ファミマ・ドットコムなど）
11位～50位（セシール／ディノスオンラインショップ／メディアミックスショッピングなど）
51位～100位（ナチュラム、三越オンラインショップ、Oisixなど）

1位のAmazonは年商が推定1500億円らしい。

Amazonと言えば、アフィリエイト、リコメンドエンジンなど、Web特有の機能が思いつく。
「Web 2.0で一番重要なのは価値あるデータベース」と言われるが、つまりこれはデータ・マイニング機能を指す。
日々の売上げデータ、大量のアクセスログを多角的に解析して、マーケティング分析する手法。

意思決定する材料は、経験や勘よりも、データマイニングで分析したマーケットのトレンドの数値に重点を置いているのだろう。

おそらく今後も売り上げが伸びるに違いない。

チケット駆動開発の背景

下記の記事を読んで、チケット駆動開発が出てきた背景について考えたことをメモ。

【元ネタ】
TRICHORDの背景

TRICHORDの背景 - (1) 何故スケジュール管理が難しくなっているのか

◆ 大火事プロジェクトで自己組織化を促すために具体的にやったこと

チケット駆動開発は、プロジェクトで発生した作業をチケットで管理し、バージョン単位にチケットをグループ化して小刻みにリリースしていくスタイル。
最近は、TracやRedmineのようなプロジェクト管理機能を持つBTSで運用することが多いだろう。

最近のビジネスの観点では、ITが業務のインフラとなっていて、機能がどんどん進化するのが前提になっている。
ビジネスの速さをシステム開発に応用しようとして、開発の現場が混乱しているようにも思える。

特に昨今のWebシステム開発は、数週間おきに小刻みにバージョンアップしていくのが普通。
開発者からすると、永遠に納品し続ける感覚に陥るぐらい、大変忙しい。

だから、ウォーターフォール型開発だとビジネスの速さについていけないから、インクリメンタルな開発、アジャイル開発が10年も前から唱えられた。
にもかかわらず、アジャイル開発の実践は難しい。
理由は、プロジェクト管理が難しいからだと思う。

デスマーチプロジェクトでは、その難しさがはっきり出てくるように思う。
例えば、下記のような現象が起きているだろう。

1-1.プロジェクト内部で発生する作業の状態、進捗が、メンバーだけでなくマネージャも分からない。
　それを知る手段もない。

1-2.各人が担当している作業をマネージャは把握できていない。
　デスマーチプロジェクトほど、担当作業は１日毎に変わる。

1-3.各人のタスクが溢れているため、メンバーのモチベーションも落ちている。

「◆ 大火事プロジェクトで自己組織化を促すために具体的にやったこと」の記事では、デスマーチプロジェクト建て直しの対策が書かれているが、それらは全て「プロジェクトの見える化」だ。

そして「プロジェクトの見える化」を行う基盤が、RedmineやTracのようなプロジェクト管理機能を持つBTSなのだ。
アジャイル開発は、BTSのようなインフラがなければ、進捗をリアルタイムに管理するのは非常に難しいはずだ。

BTSでチケット駆動開発を実施した場合、上記の現象に対して次のようになるだろう。

2-1.バージョンごとにチケットの状態、進捗をBTSで確認できる。
　マネージャだけでなく、メンバーも誰でも閲覧できる。

2-2.割り込みタスクはチケットに起票されて、BTSで定められたワークフローによって作業が進む。
　特にバグ修正のように、複数の担当者を行き来する作業は、メールやRSSで担当者へ自動通知される。

2-3.特にRedmineでは、ガントチャート・カレンダー・ロードマップ・統計などのチケット集計結果から、開発者は自分は何をこなせばよいか、自然に分かるから、自発的に行動できる。
　「プロジェクトの見える化」は、開発者のモチベーション向上に自然に役立つ。
　
最後の点が、BTS＋チケット駆動開発による「プロジェクトの見える化」がメンバーのモチベーションに大きく与える影響だと思う。

人間は、問題が何かを把握できる環境にいれば、必ず自力で解決しようとするものだと思う。
ファシリテーションで言われる「解けない問題を解ける問題に変換すると、人は自然に問題を解こうとする」という言葉を思い出させる。

Naoyaさんのトークセッション

Naoyaさんがジュンク堂で「私と技術書」を講演された感想をメモ。
＃印象深い部分だけの感想なので注意。

ジュンク堂書店大阪本店　トークセッション情報

【1】可用性、信頼性などのキャパシティ管理はLinuxカーネルのソースコードから解析する

Naoyaさんのキャリアを初めて聞いた。
Perlを中心としたWebプログラミングを中心にやってきて、はてなの最高技術責任者になって、負荷分散の技術に随分悩んだ話が興味深かった。

今までは、サーバーの負荷が高い時、どのような対処をすればよいか、対症療法しかできなかった。
だから、パッチのような対処しかできず、ずっと悩んでいた、と。

「詳解 Linuxカーネル」などを読んで、仮想メモリ、マルチタスク、I/Oディスクなどの仕組みがソースレベルで分かった。
Linuxカーネルの動きをソースコードレベルで追えたからこそ、何故負荷がかかるのか、理由をもって説明できて対策できる。
本の文章に嘘はあっても、ソースコードに嘘はないから、と。

その辺りのノウハウも含めて、「サーバ/インフラを支える技術」という本を書きました、と。

※補足：「Linuxカーネルの読み方」というスライドシェアが公開されている。

http://www.slideshare.net/naoya1977/how-to-read-linux-kernel/

「サーバ/インフラを支える技術」では、飛び道具のようなノウハウよりも、ローレベルのLinuxカーネル、ハードの計算機部分まで関係しているという部分に力を入れて書いた。
だから、著者が一番力を入れた部分を読み取って欲しいし、この本で全て書いているわけではないが、この本を手がかりにして探って欲しい、とのこと。

昨今のWebシステムが旧来のメインフレームより劣っていた部分は、運用保守にあったと思う。
何故、Cobolのような古い言語がいまだに使われているのか、という理由は、可用性や信頼性が抜群に安定しているメインフレーム上で動くからだ。
いわゆるオープン系のWebシステム、クラサバのシステムは、プログラミングという開発の生産性は抜群に素晴らしいが、24時間365日安定稼動、99.9999%の信頼性という運用保守では、20年以上ノウハウを貯めてきたメインフレームにはまだ劣るだろう。

しかし、「サーバ/インフラを支える技術」という本が出てきたように、Webシステムでも、負荷分散や安定稼動させる運用ノウハウは、以前に比べると随分たまってきたように思う。

メインフレームは大手SIer独自のハードウェアゆえ、その中身はユーザも他の開発者も知りえない。
それに対して、Webシステムが動作する殆どの基盤はLAMPを中心としたオープンソースだから、技術力さえあれば誰でも読める。
LinuxやApacheのソースコードを理解できれば、何故CPUの負荷が高いのか、メモリがオーバーするのか、その原因を突き止めるログや統計結果を自分で作ればいい。

Naoyaさんの話で興味深かったのは、OSの仮想メモリ、マルチタスク、マルチスレッドの動きは、本で書かれた概念と実際のソースに書かれている動きに違いがある、という話。

この辺りの感触も実際にソースを読んでみないと分からないのかな、とも思う。

【2】WebプログラミングからローレベルのLinuxカーネル、計算機科学、そして科学へ

最近のNaoyaさんの興味の話も目を引いた。
最初はPerlなどのWebプログラミングしか知らなかったけれど、ローレベルのLinuxカーネルを知って、負荷分散という技術にも強くなった。
そのおかげで、プログラムという抽象レイヤーのメカニズムも透けて見えるようになった。
今は、もっと深い部分であるコンピュータという計算機がどのように動いているか、という計算機科学に興味が向いている、と。

だから、今、はてなでは計算機科学のセミナーを開いている、とのこと。

NaoyaさんのようなハッカーがWebプログラミングの上層からLinuxカーネルや計算機科学のような下層へ深く掘り下げていく方向へ興味が向いていく話とその経験談がすごく興味深くて面白かった。

情報系の学部で勉強している人なら下層から上層へ進むのだろうが、NaoyaさんのようにWeb開発の経験が豊富な人は上層から下層へ掘り下げていく方が、自分の経験が理論化されて整理されていくだろうから楽しいだろうな、と思う。

プログラム開発と違うサーバー運用保守であっても、やはりプログラミング技術が基本なのだ、と改めて認識させられた。

BTSをインシデント管理などに使う

BTSをITILのインシデント管理などに使うアイデアをメモ。
#走り書きは後でまとめる。

【元ネタ】
【バグ管理の作法】Trac徹底活用！　第2回：なぜTracの導入に失敗するのか？

【1】BTSをインシデント管理にも使いたい。

ITILのインシデント管理とは、業務で支障があった時の問い合わせの管理。
開発チームとしては、ユーザであるお客自身に、画面操作やデータ不整合などの問い合わせ、バグ、機能追加の要望をBTSのチケットを書かせたい。
ユーザが、開発してもらったシステムを使い込んでいるし、どこの機能を使いやすくして欲しいか知っているからだ。
つまり、インシデント管理は、サポートデスクのFAQ管理とも言える。

インシデント管理は、やり取りの履歴を後からすぐに検索できるのが重要だ。
問い合わせを採番することで、ユーザや開発者とコミュニケーションしやすくなる。
問い合わせの現象の件は、番号XXのことですね、と。

また、似たような問い合わせは、番号XX番を見て下さい、とかわすことができる。
インシデント管理の最終目的は、顧客からの無駄な問い合わせを減らして、開発者が本来の開発に専念できる環境を作ることだと思う。

Redmineならフォーラムに要望やバグをお客自身に書いてもらうとよいと思う。
管理者がフォーラムの要望を精査して初めてチケット登録する。
何でもかんでもチケットに登録するとチケットが発散するから。
　
つまり、フォーラム機能をチケット登録前のフィルタリングとして使う。

チケットには、使い方とかパスワード失念のような問い合わせというインシデントは書かない。
チケットはあくまでも、バグ修正や機能追加など、本来の開発にかかわる作業だけにする。
チケットの内容のスコープを濃縮したいから。

つまり、ITILの問題管理はBTSチケット、ITILのインシデント管理はBTSフォーラム機能と使い分けるやり方が良いと思う。
更に、ITILの構成管理は、SVNコミットログとチケットの紐づけ、チケットの作業履歴から可能なはず。
ITILのリリース管理は、CIツール(Continuous Integration)で代用できると考える。

【2】チケットの「終了」は管理者だけが行う権限とする。

テスト担当者は「新規→担当」「解決→検証完了」は操作できるが、「検証完了→終了」は操作させない。
理由は、作業の品質を最後は管理者がチェックする必要があるから。

駄目なプロジェクトは、メンバーが勝手にチケットをどんどんOpenしてはCloseしてしまう。
チケットを乱発して担当者のタスクが溢れる。
チケットの検証が不十分なまま、担当者が勝手にCloseしてしまう。

20人以上でTracを運用した時、チケットが乱発して、担当者のタスクがすぐに溢れた。
チケットをCloseしてもバグが直っていないこともしばしばあった。
修正担当者自身がチケットをCloseしていたから。

チケットのステータスを変更する時の作業の品質管理がチケット管理の肝だと思う。

【3】1つのバグ報告票に対するテスト担当者、開発者の役割切り替えは、RSS機能、メール自動送信機能を有効に使う。
この機能で、役割の切り替え時に管理者の手を煩わせる必要が無くなる。
Excelや紙のバグ報告票でやり取りしていた頃は、必ず管理者の手を通過させていたから、管理者はすぐにタスクが溢れてしまい、バグがなかなか収束しなかった。

だが、複数の会社に担当者がまたがった場合は、調整する役割を担うマネージャが必要。
オフショア開発、下請け開発など、複数の会社というレイヤーが多いと、誰が修正するのか、というマネジメントを誰かが担当しなければ解決できない。

BTSは万能ではない。

【4】スケジュール作成は、Pullスケジュールであるべきと思う。

つまり、PLが作ったスケジュールを押しつけるのではなく、各メンバーが自然にスケジュールを引き出して考える環境を作る。

Redmineには、チケットに予定工数という欄がある。
チームメンバーに自発的に工数を見積もりをしてもらう。
見積もりは上からの押し付けでない。
開発者自身の見積もりなので、精度は高いはず。
更に、チケットの仕様についてメンバー同士で調整したりして、チケットに作業履歴を書く。
XPのタスクカードの見積もりに相当するだろう。

開発者自身の工数見積もりと実績工数から、見積もり速度、つまり、1日の稼働率が分かる。
統計を取っていないので分からないけれど、普通は、1日8時間のうち、実際の稼働率は6時間ぐらいではなかろうか？
リリース直後にトラブル続出で、5分おきにユーザから大量の苦情電話に対応していたら、それだけで1日が終わってしまう。
その場合は、稼働率は０％だろう。

大まかなスケジュールは管理者が作るとしても、細かなタスクのスケジュールは、メンバーの積極的なモチベーションを引き出すようにBTSをうまく使えばいいと思う。

BTSをITILのフレームワークに乗せるアイデアは更に考えてみたい。

BTSをBusiness Intelligenceとして使う

チケット駆動開発の戦略part3として、BTSをソフトウェア開発のBusiness Intelligenceとして使うアイデアをメモ。
#走り書きなので後でまとめる。

元ネタは、下記の記事。

Mantisのバグ情報から信頼度成長曲線作成ツール

SRATS取り扱い説明書

【1】Web2.0の重要機能「足跡」をプロジェクト管理に応用できないか？

ソフトウェアメトリクスの測定には、大きな障害がある。
それは、メンバーがプロジェクトに関する様々なデータを「入力する手間」が発生することだ。
ソフトウエア開発プロジェクトはただでさえ忙しいから、入力するデータの質は落ちやすい。

だから大手SIや銀行では、上からの命令で15分おきに生産性を入力させるような運用もしている。
つまり、彼らは従業員の実績をリアルタイムに管理したがっている。
でも、ソフトウェア技術者である僕らは奴隷じゃない。
トイレに行く時間まで管理されたくない。

Web2.0システムは、作業ログを自動収集して、色んな観点から統計結果を見せる機能がふんだんにある。
つまり、緩やかに作業ログを収集する仕組みが洗練されている。
しかもRSSなど、収集したログを集計した最新情報を自動配信する機能さえある。

この機能は、小売系WebシステムやMixiなどのSNSでは当たり前の機能だ。
データマイニングをマーケティングの一手法として使う。

例えば、レコメンドエンジンとは、eコマースサイトでよく見られる「これも一緒にいかがですか？」と関連商品を表示する機能を実現したものと言える。

特に、Amazonの最大の特徴は強力なレコメンデーション機能にあると言ってよい。

例えば、Amazonのレコメンデーション機能は協調フィルタという有名なアルゴリズムが使われている。

PVや画面遷移の履歴は簡単に採取できる。
例えば、PVや画面遷移の履歴、購入履歴から、購入画面や注文画面へ誘導するする設計を取ることもできる。
これを使って、購入履歴から売れ筋の商品をリンクさせる機能も追加できる。
この機能は、商品購入時に関連商品を表示させて、商品のレビュー履歴から関連商品をお勧めさせたいのだ。

Googleの検索エンジンのアルゴリズムpageRankも同様の発想だ。
つまり、どのHPが一番検索されて有用か？を検索履歴から集計して最新情報を常に反映させる。
これによって、商品を検索した時、特定のHPに誘導することさえできる。

mixiのようなSNSの足跡機能も同様。
特定の人へのアクセスログから、友人関係の距離を計算できる。
ここから、「スモールワールド」「世界中の任意の人とは6人の人間関係を経由すれば必ずアクセスできる」などのような社会科学の研究にもつながる。

しかも、これらの機能は、Google、Amazonのように、マッシュアップのおかげで多様なWebサービスが誰でも簡単に作れる。

この機能を更に進化させた概念がいわゆるBI(Business Intelligence)だ。

IT用語辞典では、BIは下記で説明されている。

業務システムに蓄積される企業内の膨大なデータを、分析・加工して、企業の意思決定に活用しようとする手法。
ERPパッケージやCRMソフトなどからもたらされるデータの分析を専門家に依存せず、経営者や社員が必要な情報を自在に分析し、経営計画や企業戦略などに活用することを目指す。

この機能は、マーケティングを生かした商品開発、ビジネス上の経営判断に使える。
この機能をプロジェクト管理にも使えないだろうか？

【2】BTSのチケット集計結果をソフトウェア・リポジトリ・マイニングによって、色んな角度からメトリクスを採取して、プロセス改善の材料にする。

ソフトウェアメトリクスを採取する話では、いつも「計測できないものは制御できない」というケルビン卿の話が良く出る。
つまり、ソフトウェア工学とは、ソフトウェア開発プロセスの定量化が目的の一つなのだ、と。

ソフトウェア・リポジトリ・マイニングは、ソフトウェア開発履歴からのお宝発掘。
　　SVNコミットログ
　　BTSチケット履歴
　　ビルド履歴
　　メーリングリスト
から、プロジェクトの状態、ソースの状態、作業の状態をリアルタイムに見える化する。

管理者がやりたいことは、BTSのチケット集計結果にソフトウェア工学の知識を応用して、プロジェクトのリスクをいち早く感知したいこと。
Redmine/Tracのようなプロジェクト管理機能を持つBTSは、プロジェクトのセンサー。

プロジェクトリーダーは、リアルタイムに出力されるBTSのソフトウェア・リポジトリ・マイニング機能を使いこなせれば、プロジェクトをモニタリングしながら、リスクを即座に察知できるはず。

チケット集計結果から、信頼度曲線を出力できれば、後どれくらいの工数で品質が歩溜まりに達するか分かる。
garyoさんのRubyプログラムを使うと、Mantisの出力CSVから、信頼度曲線を作ることができる。

更に、SRATSというフリーの信頼性評価ツールにチケット集計結果を食わせると、下記を出力できる。
　
2-1.Total: 対象とするソフトウェアに潜在する総フォールト数

2-2.FFProb: 現時点で対象とするソフトウェアにフォールトが存在する確率

2-3.MTBF: 次のフォールトが発見されるまでの時間

2-4.Be X Life: 次のフォールトが発見される確率が０．９となる時間
（その時間までに１つ以上のフォールトが発見される確率が９割）

情報処理試験で習ったMTBFの概念は、ハードウェア障害だけでなくソフトウェアの障害まで当てはめることができる。

この数値をプロジェクト終了後にメンバーと一緒にKPTを行えば、何が問題だったのか、次のプロジェクトでは何を試せばいいか、メンバー自身を自然にプロセス改善に誘導できる。

BTSを有効活用すれば、プロジェクトをこなすたびにメンバーを成長させるきっかけにできるはずだ。

BTSをプロジェクト管理の汎用フレームワークとして使う

チケット駆動開発の戦略part2として、BTSをプロジェクト管理の汎用フレームワークとして使うアイデアをメモ。
#走り書きは後でまとめる。

【元ネタ】

【バグ管理の作法】Trac徹底活用！　第2回：なぜTracの導入に失敗するのか？

質問「BTSについて教えて下さい」に対するgaryoさんの回答

【1】BTSはシステム開発に特化したToDo用のワークフローとgaryoさんは言っている。

--------↓引用開始↓-----------
BTS自体は非常に使いやすいToDo用のワークフローシステムです。
「バグ」として登録している所を「機能(追加・要求)」にすれば開発管理（要求管理）になりますし、汎用的に「タスク」と捕らえればプロジェクト管理になります。
流れとしてはBTS→BTS+プロジェクト管理　となっていくと思います。
---------↑引用終了↑----------

BTSのチケットの中身は、バグ報告票だけでない。
お客からの問い合わせなどのインシデントも書ける。
更には、開発者からあがったリファクタリング、環境構築、ビルドスクリプト作成などの内部作業も書ける。

つまり、バグ解決プロセスはITILのインシデント管理、問題管理、変更管理、リリース管理に簡単に流用できるはずだ。
これは、BTS(Bug Tracking System)をITS(Issue Tracking System)へ汎用化・昇華させる発想。
このアイデアを色んな角度から考察してみる。

【2】WikipediaにあるBTSの解説を読むと、バグ解決フローは下記の流れになる。

新規　opened
　起票者(テスト担当者)がバグ報告を登録する
↓
担当　assigned
　管理者(又は起票者)がバグ修正の担当者(開発者)をアサインする
↓
解決　resolved
　担当者がバグ修正してバグを解決する
↓
検証完了　verified
　起票者がバグが再現するか検証して、解決したことを確認する
↓
終了　closed
　管理者がバグ報告票を閉じる

Redmineには、ステータスとユーザーの権限マトリクスを制御する仕組みがある。
例えば、担当者は、「担当→解決」しか操作できない。
起票者は、「新規→担当」「解決→検証完了」しか操作できない。
この仕組みによって、メンバーが5人、10人のようなチームでも混乱せずに運用できる。

ユーザ権限によってステータスを制御する仕組みは、情報系の業務システムでは良く使われている。
RedmineのDBを見ると、ステータスやユーザを増やしても使えるように非常に上手に作られている。

--------↓引用開始↓-----------
バグレポートもすぐ出力できます。
ソフト担当者は後どのバグがあるかと自分は何を対策すればいいのかが分かります
（複数の人で開発していると誰がどのバグを直すかというのも決めないといけません。
そうしないとバッティングしてしまいます）

また、評価担当者は自分が起票した不具合がいつ対策されてどのバージョンで対策版がリリースされるかわかります。
---------↑引用終了↑----------

起票者と修正担当者が異なる点は重要だ。
結合テスト、システムテストのプロセスでは、バグ修正する人とテストで検証する人は分ける。
理由は、品質保持のためだ。

また、Redmineには、「検証済み」のステータスは無いが、「フィードバック」「却下」というステータスがある。

実際は、担当者がバグ修正して「解決」したとしても、起票者が検証したらNGで「フィードバック」することもありうる。
また、管理者がバグ報告票を精査して、「このバグは仕様だから修正不要」と「却下」することもあるだろう。

また「検証完了」と「終了」の違いも重要だと考える。
開発環境で「検証完了」となってリリース用モジュールをビルドできたとしても、本番リリースするまでタイムラグがあるのが普通。
「終了」とは、管理者が顧客に報告済み、あるいは、本番環境にリリースして稼動している状態を意味する。
この辺りのリリース管理がしっかりしていないため、本番リリースでトラブルが起きる開発チームもあるのではなかろうか？

【3】BTSにはステータス変更時に次の担当者へメール送信する機能がある。

つまり、バグ解決フローのイベントをメール駆動にすれば、コーディングパイプラインを管理者が逐一管理する必要は無い。

--------↓引用開始↓-----------
BTSの便利な点は、バグの処理がワークフロー化されて自動的に処理されることです。

[起票者]バグ報告→[担当者]再現性確認→[担当者]対策済→[起票者]対策確認

このそれぞれで、必要な人にメールが飛びます。

新しくバグが登録されると担当者にメールが届き、担当者がより詳細な情報が欲しい場合は再度起票者にメールが飛びと面倒を見る人が居なくても自動的に処理が進みます。

（開発者やテスターが複数の部署や会社にまたがるとこの連絡をやり取りするだけで専用の担当者が必要になります）
---------↑引用終了↑----------

バグ解決フローがシステム開発で非常にコントロールしにくい理由はいくつかあると思う。
一つは、バグはテストして初めて出てくるため、テスト工程がリリース間際になると、バグ報告票が大量発生して限られた時間内に解決できなくなること。

もう一つは、バグ解決フローは、起票者、開発者(担当者)、管理者という複数の人間の間をバグ報告票が渡り合うため、役割のコンテキストスイッチに意外に時間がかかること。

前者は、システムをバージョン単位に機能を分割リリースするイテレーション計画を作り、リリースするバージョンにチケットをふるい分けるバージョン管理戦略を取る事が多くなるだろう。

後者は、BTSのメール送信機能やRSS機能、ニュース機能で、次の担当者へ自動通知する仕組みで対応する事が多くなるだろう。

開発が遅いチームは、起票者と担当者のやり取りがスムーズにいっていない時が多い。
そうなる原因は、担当者に割り込み作業が多かったり、バグ修正の件数が多くて、担当者のタスクが溢れている時が多い。
プロジェクトリーダーは、起票者と担当者のコーディングパイプラインが滞りなく動いているか、いつも見て、タスクの量を調整する重要な役割がある。

【4】不具合Noを採番することで、構成管理のインフラに流用できる。

例えば、テスト管理WebシステムのTestLinkにあるテストケースでNGとなったら、チケットNoを採番してBTSのチケットへバグ報告票へリンクする機能がある。

--------↓引用開始↓-----------
BTSなどで一番重要なことは「不具合を採番すること」だと思います。
このことにより、「不具合管理番号○○○○○○番」の不具合と言って話が通じるようになります。

また、どの不具合のバグが何件あるかという情報が共有できます。
---------↑引用終了↑----------

Redmineのロードマップでは、バージョン単位にチケットをグループ化するから、リリースするたびに、どのチケットのバグが解決されたのか、バージョンから探すことができる。

【5】僕の考えでは、BTSによるチケット駆動開発は、成果物志向の管理は多分実現が難しく、作業プロセス単位で管理した方が構成管理は実現しやすいと思う。

つまり、Redmineならチケット管理することで構成管理も可能だろう、と考える。
理由は、チケット駆動開発では、チケット＝作業タスクとして管理するから。

構成管理はバージョン管理だけでない。
構成管理の目的は、ソフトウェアの構成(影響)を特定し、構成の一貫性、追跡性を維持すること。

チケット駆動開発は、トレーサビリティのインフラも提供するから、構成アイテム(CI)の状況、変更の影響範囲を即座に把握できる。
例えば、チケットの状態から作業プロセスの状態を把握できる。
又、チケット集計結果から信頼度曲線が作れて、品質状況を確認できる。

従って、チケットを要件と成果物のトレーサビリティ、作業の状態チェックに使えば、CMMIレベル2を自然に実現できる。
チケット集計結果をプロセス改善に使えるなら、CMMIレベル5に達することさえできる。

BTSをうまく使えば、プロジェクト管理の汎用的なフレームワークへ昇華できるはずだ。

ブロックはRuby流無名関数

Rubyのブロック、ブロック呼び出しで参考になる記事があったのでメモ。

【元ネタ】
Rubyのyieldを使った例を教えてください

yieldはブロック呼び出しに使うとのことだが、コレクションの値の総和や二乗和を求めるコードの例が凄い。

無名関数を渡す発想はオブジェクト指向ではないと思う。
関数型言語の発想だ。

ソースインスペクションを真面目にやるGoogle、MS

GoogleやMSがソースコードレビューを真面目にやっている下記の記事を何度も読んで、ソースコードレビューシステムを何とか導入できないか模索している。

【元ネタの記事】
Googleのコードレビュー

MS内部のソフトウエア開発手法の話

Review Board - コードレビューをオンラインで

VMWareの開発でも利用されているソースコードレビュー共有ソフトウェア「Review Board」

ソースコードインスペクションの重要性は、二人の目による品質管理だけでなく、設計思想を共有する重要な手段と捕らえるべきだと思う。
プログラミングは誰でも癖があり、時に品質をすごく落とす。

だから、他の人に手軽に見てもらい、チャットのようにレビューをコメントしてもらうようなスタイルにしたい。
そうすれば、ソースインスペクションという技術者同士で熱くなりがちな議論を会話するような雰囲気に持ち込みやすいから。

他の記事で、特に気になった言葉は下記2つ。

「レビューは不具合をみつけるのではなく、信頼感を醸成するためのものだ。」
「レビュー（ピアレビュー）はペアプログラミングの代替である。」

コードレビューの利点は、品質の確保だけでなく、チームメンバー全員がコードの思想を共有することだと思う。
コードレビューによって、若手のスキルは確実に上がる。

コードレビューシステムに関しても、オープンソースの開発者の方が大手SIerよりもレベルが高い気がする。
オープンソースの方がソースインスペクションのプロセスも洗練されている。

オープンソースでは、特にパッチや機能追加のソースはコミッタが必ずレビューして、どのバージョンに入れるか判断を下す。
例えば、Matzさん、ひがやすをさんのような世界トップレベルのコミッタが、送られたパッチをコミットするかどうか判断するのだから、普通の大手SIerよりも技術レベルが当然高い。

他に、分散ソース管理(例えば、Gitなど)が普及しつつある理由の一つに、コミッタ権限の無い開発者がハックするのに使うこともあげられる。
つまり、ローカルのリポジトリに自分がハックしたソースをコミットして履歴を残せる。
マスタリポジトリから定期的にローカルリポジトリと同期すればいい。

この時、マスタリポジトリにコミットする前に、ソースインスペクションで癖のあるソースを直すのにこのコードレビューシステムを使いたい。

コードレビューシステムとしては、ReviewBoardが使いやすそう。
ReviewBoardはPythonでインストールが面倒だが、Webでレビューコメントを気軽に書けるので導入してみたい。

Web2.0のシステムは、SNSのように足跡のような機能が豊富。
つまり、誰かがコミットした、チケットにコメントした、という作業ログをシステムが自動巡回してその統計結果を多角的に集計して表示することが可能なのだ。

この機能は、特に小売系Webシステムでは、マーケティングの一手法として、リコメンドエンジンのような複雑なアルゴリズムなどで実装されている。

Web2.0のそんな機能をプロジェクト管理に使えないだろうか？

（その答えは、ソフトウェア・リポジトリ・マイニング）

BTSを構成管理ツールとして使う

チケット駆動開発の戦略part1として、BTSを構成管理ツールとして使うアイデアをメモ。
#走り書きは後でまとめる。

元ネタは、下記の記事。

チケット駆動開発 ITpro Challenge のライトニングトーク

Tracの最大の利点はSubversionとの連携にあり

【1】トレーサビリティ

Redmineのチケット管理をずっと続けると、要件からソースコードまでのトレーサビリティをすごく意識する。
実際の運用は下記になっている。

要件・仕様書・テスト仕様書のリンク、説明書き、作業履歴
←→チケット
←→SVNリビジョン

何度も思うことは、本番リリース後のシステム開発は、リアルタイムに保守されない仕様書よりも、バグ有りで動くプログラムが正しいことだ。
しかも、お客も、バグありの機能を知った上の運用フローを組んでいる。

設計者は、XPのように、動くプログラムを正として、プログラムから機能仕様をリバースして仕様書を作る時がすごく多い。
つまり、実際の仕様書作りは、本番稼動しているシステムを元ネタに作る時が実に多い。

この時に、SVNリビジョンとチケットが相互リンクされているので、ソース修正の意図がチケットに書かれている。
この手法によって、ソースコードから仕様をリバースするのがかなり楽になった。
つまり、3年前に書かれたパッチの修正理由をすぐに見つけることができる。

SEの仕事は、要件から業務のインターフェイスを決めること。
そして、要件とインターフェイスがMECEで対応していること、更には、要件からソースコードまでのトレーサビリティが保持されていること。
つまり、ソースコードで実装された機能やパッチが必ず要件管理IDに基づいていることを保障するのがSEの重要な仕事だと思う。

今まではトレーサビリティを実現するインフラが今まで無くて、Excelで書かれた膨大で散在したドキュメントしかなかった。
だから、欲しい仕様を膨大で散在したExcelの中から手作業で探すしかなかった。
でも、今は、Redmineによって、仕様は全てチケットに紐づけているから、チケットの履歴から探せる。
まさに、設計そのものもチケット中心。

このアイデアはバージョン管理、構成管理につながると直感している。

【2】SVNコミットログで「refs」と「fixes」を使い分ける運用も始めた。

2-1.チケットの仕様を実装中だが、一旦コミットしたい
↓
修正中のステータスなので「refs」を使って
「～の理由でコミット refs 123」
と書く。
↓
SVNリビジョンとチケットにリンクが張られるだけ

2-2.チケットの仕様を全て実装完了した
↓
修正完了のステータスなので「fixes」を使って
「～の機能を実装 fixes 123」
と書く
↓
SVNコミット時に、チケットの進捗＝100%かつステータス＝解決に変更されて紐付けられる

この運用を入れた理由は、SVNコミットログに修正ステータスも入れたいから。
そうすれば、リリース後にSVNコミットログを集計した時に、「fixes」「refs」の単語で何かしらのソフトウェアメトリクスを採取できるのではないか、と思う。
ソフトウェア・リポジトリ・マイニングでは、SVNコミットログの精度が高いほど意味のあるメトリクスを採取できるはず。

【3】プロジェクトの見える化

チケット駆動開発の最大の利点は、プロジェクト管理とソースコードがリアルタイムに結びついていること。
プロジェクト内部で発生する作業は、Redmineのチケット一覧を見れば、今誰が担当して、今どんな状態なのか、一目瞭然。
Redmineのロードマップで、バージョン単位にグループ化されたチケットの進捗率が分かる。

他には、Redmineなら、ガントチャートでチケットの進捗が分かる。
レポートで、トラッカー・機能・起票者などの分類ごとのチケットのステータス一覧が分かる。
統計では、SVNコミット回数、リビジョン回数がグラフ化されるから、開発者の生産性も一目瞭然。

そして、作業終了となったチケットは、リリース後の集計結果からソフトウェアメトリクスを採取できるので、チームメンバーでふりかえりを行うプロセス改善の材料にもなりうる。

開発者はRedmineのロードマップを毎朝見て、どの作業が自分の担当か判断するので、僕が逐一作業指示を出す必要も無くなった。
と言っても朝会を止めたわけではない。

朝会ではむしろ、ロードマップを見ながら、バージョンの戦略やチケットを担当してもらう意味を説明することが多くなった。
特に、バージョン管理戦略は、突然の仕様変更やバグ修正で大きく変わる時もあるので、開発者の意見や見積もりも聞きながら、対応するようにしている。

【4】バージョン管理

「Ship It! ソフトウェアプロジェクト 成功のための達人式ガイドブック」によると、ソースだけでなく、仕様書もビルドスクリプトも開発環境もサードパーティのライブラリもSVNリポジトリへコミットすべきだと言う。
つまり、開発に関わる全ての成果物はバージョン管理すべきだ、と。
理由は、いつでも誰でも開発環境を再現できるようにしたいから。

実際の現場では、ソースコードはSVNで管理していても、ExcelやWordの仕様書、画像などのバイナリファイルはバージョン管理していない所が多くないか？
また、ビルドスクリプトやライブラリもバージョン管理していない所も多いのではないか？
だから、製品をリリースする時、しばらく時間が経った後に仕様変更で修正する時に、最近のビジネスのスピードについていけない時が多いだろう。

Redmineでチケット駆動開発を実施すると、バージョンという概念がシステム開発で重要なことを改めて認識させられる。
つまり、バージョンとはシステムに関わる全成果物のスナップショットなのだ。

例えば、Subversionのタグは、リリースしたソースのスナップショット。
Redmineのバージョンはリリースしたチケットの一覧。

Subversionのタグによって、ソースだけでなく、仕様書やビルドスクリプトなど一式もバージョン付けされる。

チケット駆動開発は、バージョン単位にチケットをグループ化して、システムを漸進的に進化させる開発スタイル。
バージョン履歴こそがシステム開発の作業履歴そのものなのだ。

Redmineにはニュースという機能がある。
ニュースはバージョン履歴の概略として使えるから、ここに書き記していく。

他に、Redmineチケット機能に変更記録という一覧があり、これは、ロードマップでステータス＝終了となったチケットの一覧を表示している。
これがバージョン履歴そのものと言える。

マイクロソフト製品はver3.0になって使いやすくなると揶揄された頃があった。
バージョンアップするたびに、品質が安定して、使いやすい機能が揃ってくるということ。
バージョン管理こそがプロジェクト管理の要。

【5】構成管理する目的は、下記2点に集約されるのではないか、と思う。

5-1.成果物をバージョン管理する
5-2.作業プロセスをトレースし、ソフトウェアメトリックスを採取する

5-1はSubversion(SCM)で実装可能。
5-2はRedmine(BTS)で実装可能。

組織の成熟度という話は、IT業界では、CMMIという概念がある。
CMMIでは下記の5段階が定義されている。

◆レベル1（初期段階）
　場当たり的な状態で、決まったプロセスがない
　
◆レベル2（反復可能な段階）
　初歩的管理は行われており、同じようなプロジェクトなら反復できるプロセスがある
　
◆レベル3（定義された段階）
　組織的に定義された標準プロセスがある
　
◆レベル4（管理された段階）
　プロセス・製品の精度、品質を管理し、定量的な分析が行われている状態
　
◆レベル5（最適化された段階）
　プロセス分析からのフィードバックにより、改善が継続的に行われている

BTSをプロジェクト管理のインフラにできれば、成果物をバージョン管理できて、作業をチケットでいつもトレースできるから、CMMIレベル2はクリアできる。
更にチケットの集計結果からソフトウェアメトリクスを採取して、そこからプロセスを改善できるならば、CMMIレベル5に達している。
BTSをうまく使えば、CMMIレベル5を目指すこともできるのではなかろうか？

プロジェクトリーダーはBTSを構成管理ツールとして使いこなせば、プロジェクト管理の最強インフラにできるはずだ。

チケット駆動開発の戦略

【1】チケット駆動開発は、まちゅさんが最初に提唱されている。

チケット駆動開発 ITpro Challenge のライトニングトーク

上記では「チケット無しのSVNコミットは不可」という思想が強調されている。
これは、本番リリースしたモジュールはチケット無しの場合修正不可、あるいは、プロジェクト内部の作業はチケットを作ってアサインして初めて稼動する、とも言い換えられる。

つまり、チケット駆動開発をプロジェクト管理の基本とすると、チケットに作業プロセスと作業担当者をアサインするのが前提条件になる。

そして、このチケットをバージョン単位にグループ化し、小刻みにリリースするのがチケット駆動開発。

僕がこの手法を運用して、強く意識するものは、チケットの取捨選択だ。

実際のプロジェクトでは、当初の計画した時のチケットの枚数と同じぐらい、バグ修正作業時にチケットが発生する。
つまり予期しない作業が、納期ギリギリになって、かなり発生する事実を意味する。

MSProjectでは、当初のスケジュールに途中で追加した作業と工数を組み込んで、平準化する機能がある。
この機能は確かに便利だが、スケジュールが納期を越えたら、作業の組み合わせや担当を入れ替えて、納期に間に合うようにしなければならない。
この作業がガントチャート保守であり、いつも無駄な作業だと思っていた。

僕のRedmineによるチケット管理では、ロードマップの画面で、1週間単位にチケットをアサインしている。
（但し、1週間と言うスプリントは各プロジェクトで異なると思う。）

つまり、1週間で解決できないチケットは捨てるか延期する。
今は1週間単位のスケジュールしか見ていない。

このやり方がどこでも通用するかどうか分からないけれど、手ごたえは感じている。

3ヶ月先のスケジュール作成に時間を費やすよりも、1週間先までのチケット解決に全力を注ぐ方が、成功する確率は高い。

チケット駆動開発では、ロードマップと言うバージョン単位のリリース計画を作るのが非常に重要なのだ。

【2】Redmineによるチケット駆動開発の凄い所は、下記3点だと思っている。

2-1.SVNリポジトリとRedmineチケットが紐づくので、要件とソースコードのトレーサビリティのインフラが整う。
つまり、BTSが構成管理ツールになる。

2-2.BTS(Bug Tracking System)のワークフローは、ITS(Issue Tracking System)のように、プロジェクト管理のフレームワークへ昇華・汎用化できる。

2-3.チケット集計結果をソフトウェア・リポジトリ・マイニングによって、色んな角度からメトリクスを採取して、プロセス改善の材料にできる。

今の僕の興味は、BTSを構成管理ツールにして、BTSの運用をプロジェクト管理の汎用化したプロセスにして、最後はソフトウェア工学の知識を流用して、プロジェクトを改善する材料にしたい。

これらの論点について更に考察したい。

ブランチのライフサイクル

Subversionのブランチモデルの意味もようやく分かった。

元ネタは下記の記事。

複数のアジャイルチームでのバージョン管理

Subversionでブランチを作る理由は、trunkのライフサイクルと異なるから。

1.trunkは一度作られたら永遠に残る。

2.リリースブランチは、本番リリース時に作られて、次バージョンのリリース時に廃止される。

3.タスクブランチは、タスクの実装開始時に作られて、タスクの実装完了後にtrunkにマージされて廃止される。

RedmineプロジェクトはSubversionブランチのライフサイクルと一致しているから、ブランチ廃止時にRedmineプロジェクトを非公開にすればいいだけ。

Subversionコードラインのライフサイクル

Subversionを使ったブランチモデル、バージョン管理戦略がだいぶ分かってきたのでまとめてみる。
＃走り書きなので後でロジカルにまとめる。

元ネタは下記の記事。

複数のアジャイルチームでのバージョン管理

【1】Subversionブランチが作られるタイミングは、2つある。

一つは、本番リリース直後に作るリリースブランチ。
他方は、突然やってきた大きな機能追加に対応するタスクブランチ。

【1-1】リリースブランチは普通で頻繁に作る。
リリースブランチのライフサイクルは、下記の通り。
これがVer1.0, 2.0とバージョンアップするたびに作られる。

Create：本番リリース直後にtrunkから切られたTagから作る。
↓
Update：緊急のバグ修正を反映する。当然、trunkにもマージする。
↓
Delete：次のバージョンが本番リリースされた直後に廃止される。

ここで重要なポイントは、RedmineプロジェクトとSubversionブランチのライフサイクルは一致することだ。
つまり、RedmineプロジェクトとSubversionブランチは1対1に対応し、かつCRUDのタイミングも同期する。

実際の運用では、Subversionブランチで発生したコミットには、必ずRedmineのチケットが紐づく。
これによって、Subversionブランチのソース修正の理由がチケットから必ずトレースできる。
しかも、チケットに「関係する」「先行する」リンクでチケットをツリー状に関連付けることもできる。

これによって「3年前に修正した1行のソースの修正理由もすぐに分かる」インフラが整う。
システム開発の構成管理で最も重要な点は、トレーサビリティだと思う。
ここで言うトレーサビリティとは、要件からソースコードまで論理的一貫性があるだけでなく、ソース修正の理由も要件管理IDに紐づくものであること。

つまり、プロジェクト内部で発生する作業は全て、きちんとした理由がなければならず、更に誰でもいつでも説明できるものでなければならない。

【1-2】タスクブランチの使い方もようやく分かった。
タスクブランチを使いたい状況は、下記2つがある。

一つは、SQLインジェクション対応を埋め込みたい時など、ビッグリファクタリングが必要な時。
もう一つは、大きな機能改善をtrunkのバックグラウンドで平行で行いたい場合。

「成功する要求仕様、失敗する要求仕様」を読んで目に留まった点がある。

今、バージョン3.0に向けて開発中で、大きな機能追加はバージョン4.0でリリースする計画を立てたと前提する。

その時、お客から追加要求が来た。
この時、どのように対処するか？という問いに対し、本では7つの選択肢があるのだが、最良の選択は下記であると主張している。

変更を受け入れて、リリース3.1という新たなリリースポイントを作り、変更リリース3.1に組み込む計画を立てる

これは、2系統のバージョン管理戦略の発想に似ている。
つまり、今の問いの場合、下記のような作業が発生するだろう。

Create：バージョン3.1用の追加機能を実装するタスクブランチをtrunkから作る。
↓
Update：タスクブランチ上で機能追加していく。
↓
バージョン3.0をリリースする直前：trunkからtagを切り、バージョン3.0のリリースブランチを切る。
↓
Delete：バージョン3.1のタスクブランチをtrunkへマージする。

上記でよくある例は、実際の開発で、本番リリースブランチは緊急バグ修正、trunkで次期バージョンにむけた新規開発が平行して動いている。
しかし、突然、大きな仕様追加がやってきて、受け入れざるを得なくなったとする。
この場合、開発中の次期バージョンに混ぜ込むのはすごく危険。

この時にタスクブランチを使って、次の次のバージョンポイントに大きな機能追加をリリースするのが安全なバージョン戦略。

このタスクブランチの開発は実際はすごく難易度が高いけれど、うまく設計して、仕様追加された機能そのものを疎結合にできれば、成功する確率は高まる。

チケット駆動開発とは、バージョン単位にチケットをグループ化して、小刻みにリリースしてシステムを育てていくスタイル。

チケット駆動開発を運用して管理者として意識することは、直近のバージョンにどのチケットを入れるか、というチケットの取捨選択だ。
突然降ってくる大きな機能改善を、いかにシステムの品質を損なうことなくバージョンアップしていくか、がプロジェクトリーダーの腕の見せ所だと最近はつくづく思う。

【2】開発者は基本的に、Subversionのtrunkだけ意識してもらう。
つまり、最新機能のソースはtrunkへ入れる。

いくらブランチ戦略が良いと言っても、たくさんのコードラインがあると混乱する。
特に開発者には、一つのコードラインに集中して開発して欲しい。
だから、プロジェクトリーダーの指示がない限り、trunkだけ意識してもらう。

Subversionのブランチはまるで生態系の系統図みたいだ。

【3】マージ作業は基本的に、Subversionリビジョン単位に行う。
タスクブランチへtrunkの最新ソースを差分反映する時、Subversionリビジョンを指定して上書きしたり、マージしたりする。

Subversionのマージ作業が意外と簡単にできる理由は、Subversionリビジョンが差分ソースをユニークに決めるものだから。
Subversionリビジョンはシーケンスみたいなもの。

最近公開されたSubversion1.5では、マージトラッキング機能が反映されたらしいと聞いたので、試してみようと思う。

【4】trunkには、環境の設定ファイル込みのプロジェクトで管理する。
丁度、Railsのproduction/development/test、Seasarのct/it/utと同じ。
更に、フレームワーク部分とアプリケーション部分を疎結合に設計しておくことも大事。

ソフトウェアプロダクトラインが提唱する製品ファミリーのソース管理は、製品単位ではなく、単一のリポジトリで管理すべきだと思う。
例えば、iPodが似たような仕様で多種類の製品をリリースする時、ビルド時に一つのリポジトリから製品ごとにビルドするやり方。

ビルドスクリプト内部で、開発サーバー向けか本番サーバー向けか切り替える、とか、顧客Aと顧客B向けに切り替える、とか、i386向けかPowerPC向けに切り替える、とかする。
そうすれば、開発者はtrunkにある単一リポジトリだけ専念すればいい。

でも、今まで僕が経験したパッケージ製品開発の現場では、ソース管理は製品単位に作られて、同じようなソースがあちこちの製品に散らばって、結局うまく管理できていなかった。
特に、フレームワークのバグ修正を後からマージする時が面倒で、しかも全て漏れなくマージできたのか、検証が面倒で難しい。
結局、せっかく直したと報告のあがったフレームワークのバグが直っていなかったりして、デスマーチに輪をかけたりした。

RedmineとSubversionを組み合わせたチケット駆動開発を運用して分かったことは、オープンソースに従事する開発者の方が大手SIerよりも、プログラミング技術だけでなくソース管理という最も重要なプロジェクト管理技術もレベルが高いこと。
実際、Rubyもver1.8系とver1.9系は厳密に管理されているし、Firefoxの開発も同様。

ソース管理という最も基本的で最重要な管理手法はもっと研究の余地がある。