Redmineを使って気づいたことpart2～バグ収束曲線

Redmineを運用して気づいたことを書いてみる。

【1】活動欄にプロジェクトの活発度合いが現れる

Redmineには活動欄という画面がある。

システムへ機能追加してテストすると、たくさんのバグ報告があがる。
それらを一つずつチケットに登録して、担当者をアサインする。
この時に、活動欄はチケットの起票で埋まる。

その後、修正したらSVNコミットするので、SVNコミットログが活動欄に現れる。
それから、テストで検証し、問題なければチケットは終了する。
この時に、活動欄に「チケット(終了)」と現れて、ロードマップのチケットに取消線が入る。

つまり、下記の流れが活動欄に出てくる。

チケット起票、アサイン(新規、担当)
↓
SVNコミット
↓
チケット終了(終了)

活動欄が少ない場合、チケットの状態変化もSVNコミットも少ない。
つまり、プロジェクトの進捗が停滞していることを意味する。

逆に活動欄が多い場合、チケットの起票や終了が頻繁で、SVNコミットも多い。
つまり、プロジェクト内部で開発者やテスト担当者が活発にやり取りしていることを意味する。

チケットがたくさん起票されるということは、バグがたくさん出たということなので、リスクが表面化したこと。

SVNコミットやチケットがたくさん終了したことは、バグが解消されて、品質が安定し始めたこと。
リスクが減ってきていることを意味する。
つまり、プロジェクト終盤にはバグ報告のチケットは減っていく。

だから、活動欄にたくさんのトランザクションが発生することは、リスクの顕在化という観点からすると、重要だと考える。

ロードマップに取消線のチケットが増えていくのを見ると、何故か楽しくなってくる。
タスクやバグ修正を確実に終了させた充実感を感じるからだ。

【2】チケットの状態変化をバグ収束曲線で表現できないか？

バグ収束曲線という図がある。
つまり、システムテストのバグ発生件数を時系列で描いた図。
この図は普通は、前半は指数関数的に増えて、後半は対数関数のような傾きになり、最後は上限で頭打ちになる。
バグ収束曲線のメリットは、品質の分溜りが後どれくらいの時間必要なのか、を予測できること。

上記のチケットの状態変化を追跡してみると、バグ収束曲線のような曲線になっていることが感覚的に分かる。

Redmineにはバグ収束曲線の表示機能はないが、DBにチケットの状態があるはずだから、プログラムさえ書けば表示は可能なはず。
しかも、Railsなので、DBさえ分かれば書けるはずだろう。

Redmineによるチケット駆動開発(TiDD)を実践してみて重要なポイントは、チケットの状態変化をきちんとトレースすることだ。
チケットを単に起票して終了するだけでは意味が無い。

今、チケットが増えているのは、バグ収束曲線から類推して、良いことなのか？
あるいは、チケットが減っているのは、バグ収束曲線から類推して、もうすぐ品質も安定する兆候なのか？
それとも、単にバグ報告があがっていないだけなのか？

それらを見極めることが大事。

2系統のバージョン管理戦略

OpenPNEというオープンソースのSNSのブランチの説明があったので、メモ。
非常に参考になる。

OpenPNEレポジトリ構造

OpenPNEソースコードは主に4種類のブランチで成り立っています。

1.最新の開発版を反映するトランク
2.リリースの安定版を反映するリリースブランチ
3.将来本線に取り込まれることを予定した、プロジェクトブランチ
4.開発者がバグ修正時や研究時に利用するワークブランチ

最近のソフトウェア開発は、短い期間でリリースしなくてはならない。
特に、1次開発後に機能追加して拡張していく場合、最近はリリース間隔が非常に短くなっている時が多い。

基本的な戦略は、バグ修正と機能追加のバージョン管理を上手に使い分けること。

一つの解決策としては、リリースブランチでバグ修正しながら裏では、trunkで機能追加しながら品質を確保する2系統戦略があるだろう。
例えば、奇数バージョンが保守ブランチ、偶数バージョンが大幅機能追加のブランチのような戦略。

この戦略の利点は、バグ修正と機能追加のブランチが区別されているので、品質を確保しやすいこと。
バグ修正のブランチは、修正していくほど、品質は安定していく。
機能追加のブランチは、追加するほど不安定になるので、試行錯誤しながら手を加えていく。
だから、表のリリースブランチの裏で時間をかけて行う。

2つのバージョン管理とマージ作業、それらに伴うプロジェクト管理の手法は、Redmineのようにプロジェクト管理機能を持つBTSでないと、もはやプロジェクトを運営できなくなっているだろう。
つまり、2系統のバージョン管理に伴う作業をBTSチケットに紐付けて、きちんと状態をトレースすることが大事。

最近の2系統のバージョン管理戦略とプロジェクト管理機能を持つBTSはセットで運用すべきだと思う。

Googleのアーキテクチャ

Googleのソフトウェアの3つの中核となる要素、「GFS（Google File System）」「BigTable」「MapReduce」に関する記事があったので、メモ。

グーグルデータセンターの内側--明らかにされた独自性 2

そのアーキテクチャの特徴は、並列処理とフォールトトレラント(耐障害性)。
もはやハードウェアは使い捨て。
ソフトウェアで冗長性まで実現してしまう。

「次世代スーパーコンピュータ施設の立地地点を神戸に決定」という記事があったけれど、時代とマッチしていないように思う。
安いサーバーを1万台、並列処理させた方がコスト的にも速くないだろうか？

恐るべしGoogle。

ウォーターフォール型開発はバージョンの概念が無い

RedmineやTestlinkを運用して気づいたこと。
アジャイル開発の基本構造はまさに、チケット駆動開発(TiDD)なのだ、ということ。

アジャイル開発のスタイルは、短いイテレーションで小刻みにリリースすること。

この時、イテレーションとはシステムのバージョンのことだ。
Redmineならバージョン、Testlinkではビルドに相当する。
つまり、リリースするマイルストーンを指す。
実際の手順は、リリースする時に、Subversionにバージョンというタグを付ける。

すると、チケット駆動開発では、1個のプロジェクトで、たくさんのイテレーション、つまりバージョンが発生し、その単位でリリースすることになる。

そのイテレーションに、実現する機能(ストーリーカード)を作業(タスクカード)に分解して、どれを優先するか、チケットをふるいにかける。

イテレーションの日数とメンバーの人数から、機能を実現できる工数は限られる。
だからこそ、限られた工数内で、チケット(タスクカード)に優先順位を付ける。

この時、バグ修正のチケットが機能追加よりも優先する。
理由は、品質を最優先にするからだ。
バグが多く出れば、機能追加は次のイテレーションに延期するしかない。

BTSのチケット管理は自然に、限られたリソース(工数、人、時間)でやり繰りするようになる。
バージョン履歴こそがプロジェクト管理の要なのだ。

しかし、ウォーターフォール型開発は、リリースが最後の1回だけ。
マイルストーンを区切ったとしても、要件定義が終わった、設計が終わったというだけで、動くシステムは形すらできていないのが普通。
システムのバージョンという発想そのものが欠落している。

その理由は、人月ビジネス、受託開発スタイルにあると思う。
かき集められたプログラマは、リリース後はプロジェクトからいなくなる。
彼らにとって、システムを育てていくという発想がそもそも契約上ないから。

ソフトウェア開発では、バージョンという概念が一番大事。
バージョンUpしながらシステムを育てていく、という発想をチケット駆動開発は支えてくれるはずだ。

TestLinkがExcelのテスト仕様書よりも素晴らしい点

TestLinkはオープンソースのWebのテスト管理ツール。
TestLinkがExcelのテスト仕様書よりも素晴らしい点を書く。

【0】インストールが超簡単

XAMP＋TestLinkが一体化されたパッケージがある。
解凍して起動するだけ。
USBメモリに入れて持ち歩くことさえできる。

【1】テストケースを再利用しやすい

シナリオベースのテストケースは、運用保守や2次開発でも頻繁に使う。
実際は、1次開発で使ったテストケースを複製して、仕様変更や追加機能を反映させる。
この時、Excelのテスト仕様書から該当のテストケースを抽出したり、変更するのに手間がかかる。

また、テストケースは書く人によって、粒度や書式が大きく異なる時が多い。
後の保守で再利用できなかったりする。

TestLinkの場合、テストケースはDBにあるから複製が簡単。
また、TestLinkの入力フォーマットが固定されているので、テストケースの書式を統一化できる。
テストケースの属人性を排除することが可能になる。

【2】テスト結果をリアルタイムに集計できる

DBにあるから色んなクエリで集計可能だ。
ユーザ単位、機能単位などで集計結果を表示できる。
しかも、Webで入力できるから、リアルタイムに集計結果を表示できる。

JaSST関西では、「バグ収束曲線や信頼度曲線を描くことはできるか？」という質問があった。
JaSST関西はソフトウェアテスト技術者のイベントなので、テスト技術者らしい質問。

バグ収束曲線を描くことができれば、後どれくらいの工数で品質が分溜まりに達するか予測できる。
TestLinkにはそんな機能はまだ無いが、DBにテスト結果があるから、プログラムを書けば実現可能だ。
うまく使えば、ソフトウェア工学の知識を使える。

【3】テストフローを一元管理できる

RedmineのようなBTSと同じく、ユーザ単位の権限管理もできる。
テスト担当者はテスト結果書き込みだけで、テストケースの修正は不可など。
つまり、テストのワークフローを設定できる。

また、Webだからどこでも誰でも入力がOK。
オフショア開発のように、テスト部隊と開発部隊が地理的に離れている場合、TestLinkでテスト結果を共有することも可能だ。
大人数のテスト担当者を管理するのも随分楽になるはず。

ここで、TestLinkにおけるテストのワークフローを確認しておく。

3-1.テストプロジェクトを作成
　プロジェクト単位になる。

3-2.ビルドを作成

　TestLinkコミッタに聞いたら、これは「製造番号」のことだそうだ。
　例えば、iPodなどの組み込み製品の製造番号。
　つまり、これは「バージョン」「マイルストーン」のことだ。
　製造番号とは、組み込み系テストを念頭に置いたものみたいだ。
　
　TestLinkのマイルストーンはビルドの日付ラベル。
　ビルドのような管理対象ではない。
　
　更に、ビルドで注意すべき点は、ビルドをCloseしたらテストケースを修正できない。
　TestLinkでは、ビルド(バージョン)単位にテストケースをアサインする。
　過去のバージョンのテストをしないように、過去のビルドはCloseして閲覧専用にする仕組みがある。
　理由は、常に最新モジュールをテストするようデグレを防ぐ仕組み。
　これによって、テスト担当者は必ず、最新ビルドのテストケースをテストするようになる。

3-3.テストスイート

　テストケースをカテゴリ化したもの。
　機能単位。

3-4.テストケース

　概要、ステップ、期待結果を書く。

　一番不満な所でもある。
　理由は、ユースケース記述書みたいに書けないから。
　テストの目的、テストの事前条件、テスト手順、事後条件を書きたい。
　しかし、目的、事前条件の欄がない。
　
　事前条件が欲しい理由は、システムテストのテストケースでは、テストの前準備が大変だからだ。
　例えば、ネット注文のテストの場合、指定の会員が指定の商品を購入してカート画面まで遷移しておく必要がある。
　その前提条件が崩れると、いくらテストしても無意味だから。
　
　カスタムフィールドで代用できるが、一旦ビルドをCloseすると表示されない。
　おそらく、概要の欄に事前条件を書き、テストの目的はテストスイートで代用する方法がベターだと思っている。
　もう少し調査してみる。

3-5.テストケースへアサイン
　テストケースへテスト担当者をアサインする。

3-6.テスト結果
　「失敗」「成功」「ブロック」の3種類がある。

　バグが出れば「失敗」になる。
　この時、他BTSのチケットとリンクする機能が付いている。
　つまり、バグ報告票はBTSで管理し、BTSチケットと1対1に紐づけることが可能。
　BTSは、Bugzila、Mantis、Trac、Redmineが対応している。
　RedmineのようなBTSはガントチャート、バーンダーンチャートなどのプロジェクト管理機能が強い。
　だから、テスト管理はTestLink、リソース管理はRedmineと区別すればよい。

　「ブロック」とは、他のテストケースが失敗しているため、テストできない状態のこと。
　例えば、ネット注文システムの場合、カート画面が動作できなければ、注文のテストはできないので、注文のテストケースは全て「ブロック」になる。
　これは、未着手の状態だが、依存するテストケースのバグが直れば、すぐにテスト可能の状態を指す。

3-7.テスト結果
　テスト結果は履歴に全て残る。
　【2】と同じ。

【4】要件とテストケースを紐づけできる

TestLinkには要件管理という機能がある。
ver1.7.4では使いづらいが、発想としては、要件とテストケースを紐づけること。
これによって、要件からテストケースをトレースできる。

使い道としては、バグが出たテストケースから、影響を受ける要件を洗い出すことが可能。
つまり、バグ修正の影響を受ける機能、要件がはっきりするため、再テストの工数を見積もることが簡単になる。

あるいは、1次開発でたくさんバグが出て修正した機能に手を加える時、影響を受けるテストケースを洗い出し、再テストする方策も明確に出せる。

今年の夏に出るver1.8.0では、要件管理が使いやすくなっているらしい。

【5】直交表からテストケース作成
　
直交表からテストケースを作成すると、ケース数が爆発して、全てのテストケースを実施するのは現実的に無理な時が多い。
この時に、AllPair法を使う。
AllPair法は、直交表のパターンを網羅するようにテストケースを間引きする方法。
実際の現場では、AllPair法を使って、最小のテストケースでもってテストして、できるだけバグ出しさせる。

このツールは、gyaroさんが公開しているRubyスクリプトで、TestLinkに読み込むのが可能。

AllPair法で作成したテストケースをTestLinkにテストケースとして読み込むツールallpairs2testcase.rb

他にも、下記ツールがあるので、試してみようと思う。

5-1.特定のJavaDocタグからTestLink用テストケースを出力する。
5-2.FreeMindで作ったテストケースをTestLink用テストケースを出力する。
5-3.インポート用Excelマクロ

TestLinkはテストケース作成に特化していて、マネジメント機能が弱い。
だが、マネジメント機能は、Redmineで代用すればよいと考える。

TestLinkを使う主な目的は、作成したテストケースをDBにどんどん放り込んで貯めていくことだ。
運用保守フェーズでは、最新の仕様が反映されていないドキュメントよりも、バグ修正でテスト済みのテストケースがある方がありがたい。

2次開発や運用保守が長く続くプロジェクトでは、テスト仕様書が他のドキュメントよりも一番価値があるからだ。

TestLinkがどこまで使えるか試してみよう。

TestLinkでテストプロセスをマネージする

TestLinkはWebベースのテスト管理ツール。
TestLink日本語化プロジェクトのコミュニティが頑張っていて、使い勝手がいい。

【TestLinkを使う動機】

単体テストはJUnitで十分。
JDK5以降なら、テストメソッドに日本語が使えるので、テストケース名にできる。

しかし、ユースケースと対応するシナリオベースのテスト、つまりシステムテストのテストケースを作るのはいつも面倒。

理想は、想定される全ての業務フローに対して、テストでシステムを叩いて、業務のインターフェイスの矛盾をなくしたい。
でも、テストシナリオを作るには、業務の深い知識が必要。
更に、テストシナリオをMECEで漏れなく重複なく全て網羅するように作るのは、手間がかかる。

よくあるパターンは、直交表を使うケース。
例えば、ネット注文のテストシナリオを作るには、会員の種類(優待・ポイント有無)、注文した商品(化粧品、ギフト)の観点に従って、テストケースのマトリックスを作る。
すると、膨大なテストケース数になり、ちょっとした内容の修正の影響が大きくなる。

テスト仕様書はExcelで作る時が多いので、テストケースを書く時間よりも、罫線を直す時間の方が多かったりする。

2次開発や運用保守では、過去のテストケースを再利用したい時が多い。
特に、1次開発でたくさんバグが出て修正した機能に手を加える時、影響を受けるテストケースを回帰テストで実施したいものだ。

他方、テスト工程では、大人数のテスト担当者を投入してマンパワーでテストするのが普通。
すると、どこまでテストしたか、テストでNGとなったケースを修正して再テストするなどのテストプロセスをきちんと管理しなければいけない。

だが、大人数になるほどマネジメントは格段に難しくなる。
システムテストで、テスト結果やテスト作業の状態をリアルタイムに管理するのは非常に難しい。

そこでTestLinkを使ってみよう。

【TestLinkはインストールが超簡単】
　下記リンクにXAMP＋TestLinkが一体化されたパッケージがある。
　解凍して起動するだけ。
　しかもBTSのMantisまで付属している！

JaSST'08Kansaiチュートリアル「今日から始めるTestLink」

TestLinkがExcelのテスト仕様書よりも素晴らしい点は別記事で書く。

XPを実現するCaseツールは？→Redmineだ！

JaSST関西2008で出た質問。

アジャイル開発を現場で使っているが、イテレーションが短くて多いから管理しにくい。
イテレーションを管理できる良いCaseツールはありますか？

XPJUG関西代表の細谷さんは立場上曖昧に答えたけれど、僕の回答は、Redmineを使って下さい、だな。

RedmineこそXPを実現する開発インフラです。
Redmineでチケット駆動開発を実践すれば、XPの計画ゲームを実現できます。
と。

Redmineを2ヶ月使ってみて、プロジェクトリーダーの本来の仕事である、タスクの優先順位付けやリスク管理に時間を費やせるようになった。

【1】もう一度おさらい。
Redmineでプロジェクト作成後にまず設定するものは下記の通り。

1-1.バージョン
　マイルストーンと同値。
　XPのイテレーションに相当する。

1-2.カテゴリ
　システムの機能別の単位。
　XPのストーリーカードの分類単位。

1-3.トラッカー
　チケットの種類。
　バグ修正、仕様変更、仕様追加、新機能開発など。
　XPのタスクカードの分類単位。

1-4.リポジトリ
　SVNを指定する。
　リビジョン単位のコミットログが一覧表示されるように、チームでフォーマットを統一しておく。
　XPのソースコード共有そのもの。

カテゴリやトラッカーは、チケットの集計結果を多面的に見る時に使う。
だから、カテゴリやトラッカーにどんな項目を作って運用するか、は、プロジェクト管理の醍醐味。
ソフトウェア工学の知識をフルに使えばいいだろう。

【2】それからチケットを登録していく。
チケットは、プロジェクト内部で発生する作業全て。
チケットは、XPのタスクカードに相当する。

基本は1チケット1担当者。
チケットの工数は5人日以内に抑える方が管理しやすい。
チケットには予想工数の欄もあるので、開発者に見積もりしてもらえばいい。

Redmineのチケットには他チケットとリンクする機能があるので、階層化、カテゴリ化できる。
「関連する」「先行する」「ブロックする」の3種類の使い分けもようやく分かった。
リンク付けは、チケットの依存関係の意味を表す。

複数の作業を階層化したい場合、「関連する」でリンク付ける。
これは単純な相互リンク。

機能Bを作る前に共通機能Aを開発する必要があるなら、BのチケットへAのチケットを「先行する」リンクをはる。
これによって、ガントチャートのFS関係のようにできる。

チケットBはチケットAが終わらないと実行できない場合、チケットBへチケットAを「ブロックする」リンクを張る。
例えば、テストケースAでバグが出て、テストケースBの検証ができない場合が相当するだろう。
あるいは、バグAの検証が完了しないと、バグBの検証も終わらない場合。
TestLinkでも同様の概念がある。

【3】プロジェクトの進捗は下記でリアルタイムに誰でも確認できる。

3-1.活動
　チケット更新やSVNリビジョンを表示。
　バグ発生やバグ修正、検証作業が多いと、活動欄が一杯になる。
　少ない場合は、進捗がはかどっていない証拠。

3-2.ロードマップ
　バージョン単位のチケットの状態と進捗パーセンテージを表示。
　XPのイテレーションが終了するには、進捗を100％にしなければならない。

3-3.ガントチャート
　遅れていると赤字で表示されるので、MSProjectよりも分かりやすい。
　プロジェクトリーダーでなくとも、開発者もプロジェクトの進捗がすぐ分かる。
　「プロジェクトの見える化」で最も有効な箇所。

3-4.カレンダー
　チケットの開始終了日やマイルストーンを表示。
　マスタースケジュールみたいなもの。

3-5.レポート(サマリ)
　トラッカー(バグ・仕様変更・仕様追加)、優先度、担当者、バージョン(マイルストーン)、カテゴリ(機能別)ごとに、チケットの状態(未完了・完了)の集計結果を表示
　CSV出力ができるので、ここからバグ収束曲線、バーンダーンチャートを作ったりできる。
　ソフトウェア工学の知識をフルに使える。

3-6.経過時間
　 実績工数(単位：h)をトラッカー(バグ・仕様変更・仕様追加)、優先度、担当者、バージョン(マイルストーン)、カテゴリ(機能別)ごとに表示。
　このデータを蓄積すれば、2次開発以降に、見積もり工数の精度を上げることができる。

Redmineの強みは、ガントチャート自動生成と、多様な集計結果だ。
これによって、人、時間という貴重で有限な資源を、ぴったりのタイミングで的確に投入するのが可能になる。

Redmineでチケット駆動開発(TiDD)がXPを実現する仕掛けだ。

つまり、Redmineのチケットの状態管理でプロジェクト管理できる。
チケットの状態の集計結果から、ソフトウェア工学の知識が使えるようになる。

Redmineはリソース管理そのものだ。

プロジェクト管理＝ソフトウェア構成管理

最近思うのは、ソフトウェア開発のプロジェクト管理とは、ソフトウェア構成管理と表裏一体ではないか、ということ。

プロジェクトリーダーの仕事を見てみよう。
彼らの実際の仕事は、ガントチャートを作って、日々の進捗をガントチャートに反映するのに半日以上かける。
結合テスト以降は、業務シナリオ単位でテストケースを作成し、仕様変更や仕様漏れに対しテストケースを何度も保守する。
そして、テストで出てきたバグに対し、優先順位と期限を決めて、修正担当者・テスト担当者・検証担当者をアサインして回す。

それらのプロセス管理のために、進捗状況やバグ情報、バグが発生した要件を手作業で情報収集している。

プロジェクトリーダーの仕事は本来マネジメント業務なのに、マネジメントの判断材料をそろえる作業に1日の90％以上をかけていないだろうか？

日本人はプロセス改善が大好きだ。
製造業の影響を受ける組み込み系の人達は、プロセス改善、品質管理、テスト手法が大好き。
なのに、ソフトウェアの品質が悪い。

テストプロセスでは、たくさんのテスト担当者を投入してマンパワーでバグ潰ししようとする。
人手が多いから、マネージャはテストプロセスを管理するのが大変。
テストプロセスが最もIT化されていない。

理由は、構成管理ツールの概念やノウハウが少ないからだと思う。
つまり、バージョン管理、統合ビルドを自動化するとか、BTSでバグ管理、Testlinkでテスト管理というIT化の発想がない。

プロジェクト管理とソフトウェア構成管理が別々になっている。
プロジェクト管理は、結局はリソース管理。
つまり、誰が何をするか、いつまでに何をやるか、がプロジェクト管理だと思う。

ソフトウェア構成管理は、バージョン管理(SVN)、統合ビルド(Maven＋Continuum)、BTS(Redmine)の3つが必須だと思う。

プロジェクト管理とソフトウェア構成管理を一元管理できないから、マネージャは雑用がすごく多い。

ソフトウェア構成管理をIT化できれば、プロジェクト管理の引継ぎがすごく楽になる。
会社としては、優秀なプロジェクトリーダーほど、1次開発で頑張ってもらい、運用保守や2次開発は若手のリーダーに任せたいもの。

その時に、SVNやBTSなどの開発インフラが揃っていれば、使い方さえ覚えてもらえれば、誰でもやれる。
プロジェクト管理のノウハウが共通化されるから、若手も使い方に慣れるだけで、管理業務に自然に強くなる。

プロジェクト管理は属人性が強い。
誰でも管理できると管理者は不要になる。
だから故意に自分がいないと回らないようにするマネージャもいるらしい。
プロジェクトリーダー個人の能力に大きく依存するプロジェクトは、会社にとっても危険だ。

オープンソースのBTSを使う利点は、色んな会社、色んな開発者が使った要望を実現しているので、ソフトウェア開発のデファクトスタンダードになっているからだ。
最初は使い方に慣れないけれど、慣れた方がソフトウェア開発のベストプラクティスをマスターできる。

Testlinkは、テストプロセスに特化したWebのテスト管理ツール。
Testlinkを使うと、テストケースを一度DBに放り込めば、テストの進捗をリアルタイムに管理できる。
また、DBにあるから、テストケースを保守しやすいし、2次開発でテストケースの再利用が楽になる。

更に、Testlinkは要件管理機能もあるので、バグが出たテストケースから影響を受ける要件を洗い出し、それに対して対策を取る、というやり方もできる。

特に、2次開発以降、1次開発で苦労したテストにかかわる機能を仕様変更で修正する場合、あらかじめ関連する機能とテストケースを洗い出しておいて、回帰テストで何度もテストし直すこともできる。
これらはリスクを未然に防ぐというやり方。

プロジェクトリーダーの本来の仕事はリスク管理、リソース管理であるべき。
Redmineでリソース管理、Testlinkでテスト管理を実施して、開発リスクの対策を早期に実行できるインフラを作る。

プロジェクト管理は誰でも実行できるインフラであるべきで、その実装がソフトウェア構成管理ではなかろうか？

MapReduceメモ

MapReduceの説明で良い記事があったのでメモ。

下記2つは、丸山先生の解説。
短いけれど、本質を突いている。

[jjug-members] MapReduceのアルゴリズム

[jjug-members] MapReduceのアルゴリズム２

下記は、オープンソースのGoogleクローンHadoopの解説。
丁寧ですごく分かりやすい。

Hadoop、hBaseで構築する大規模分散データ処理システム ～[初級] Google基盤ソフトウェアのオープンソースクローンを使ってみる 1

MapReduceの計算モデルが威力を発揮する状況は、1テラバイトのテキストファイルの読み込みや膨大なバッチ処理など、コンピュータのメモリにロードできない場合。
Map→ソート→Reduceという単純なアルゴリズムで、DVD1枚のGrepを0.2秒で処理しきってしまう威力。

プログラミング設計の基本パターンは分割統治。
その代表例としてオブジェクト指向設計がずっと叫ばれてきたが、いい加減飽きた。

もう一つの分割統治のパターンは、関数型言語やUnixのPipeAndFilterのように、膨大な処理を小さなプロセスに分割して並列に走らせること。
今後のプログラミング言語は、並列計算を実現できるような仕組みが必要だろう。

並列処理が有効に効く状況は、マルチコアCPU、Webネットワーク、バッチ処理など。
つまり、組み込み系でも、業務系でも、今後、関数型言語の発想によって、アーキテクチャが今と根本的に変わる可能性がある。

【感想】Kansai.pm第9回ミーティング

Kansai.pm第9回ミーティングに行ってきた。
その感想を書く。

【1】Naoyaさんの話～Hadoop Streaming で MapReduce

はてなのNaoyaさんの話。
一番興味があったが、期待通りすごく面白かった。

MapReduceとは、GoogleLabの論文に書かれた分散処理の高速アルゴリズムの一つ。
並列計算アルゴリズムの一種で、Googleが使っている。
Googleはこのアルゴリズムを使って、大規模データを多数のサーバーで並列処理させている。
つまり、バッチ処理を高速化したものと言える。

MapReduceのアルゴリズムのイメージは下記のようにすごく簡単。

入力ファイル→map()→シャッフル→reduce()→出力ファイル

つまり、計算モデルは、関数型言語の特徴である「map：写像」「reduce：畳込み」の2個の関数を組み合わせただけ。
これは、UnixのPipe and Filterと同じ発想だ。

但し、並列処理させるために、分散ファイルシステムが必要。
Googleは、独自の分散ファイルシステム(GFS)を持ち、これが強力。
特に、冗長性に特徴がある。

例えば、1テラバイトのバッチ処理のために、1テラバイトのデータをネットワーク転送するのは、非常に不安定。
ネットワーク転送するだけで1日以上かかるだろう。
GFSというGoogleの分散ファイルシステムは、1 TBを64Mbにchunkして、その単位でワーカーに処理させている。
また、壊れたノードは、別のノードが引き継ぐなど、フォールトレランス機能もあるらしい。

詳細は下記を見よ。

http://www.radiumsoftware.com/0608.html

ここに興味深い一文がある。

関数型プログラミングを会得しない限り， Google に強大なスケーラビリティをもたらしたアルゴリズム ― MapReduce を発明することはできないだろう。 -- Joel Spolsky [Joel]

MapReuceの利点は、計算アルゴリズムがmap, reduceだけでいいという簡単さ。
つまり、巨大なデータを細かい処理に分割し、透過的に処理させる。
その実装プログラムは、ストリーム的な処理で解けるため、関数型言語でなくとも、大抵のプログラミング言語で実装しやすい。

MapReduceで解ける問題としては、検索エンジンのインデックス作成、ソート、検索結果のPageRankの計算、ドキュメント内のリンク参照回数の計算からWebページの有用度計算、など非常に応用範囲が広い。

つまり、Googleは、このアルゴリズムを使って、検索エンジンのインデックス作成を高速化しているのだ！

例えば、MapReuceを使うと、DVD1枚をGrepするのにわずか0.2秒で処理できるらしい！！！
(ただしタスク分散のオーバーヘッド有り)

Naoyaさんは、MapReduceという分散処理の高速アルゴリズムを使って、Perlで実現したらしい。
話した内容の詳細は下記と殆ど同じ。

http://d.hatena.ne.jp/naoya/20080511/1210506301

※講演資料が下記で公開されています。

http://d.hatena.ne.jp/naoya/20080531/1212245982

Naoyaさんは、Googleの論文を読んで、Perlで独自実装したらしい。
使い道としては、巨大なApacheログ解析や検索インデックス作成など。
膨大なテキストファイルを1日ぐらいかけて読み込んでバッチ処理するのを高速化するのに向いている。

後で聞いたら、MapReduceには結構バッドノウハウがあるそうで、分散ファイルシステムだけでなく、シャッフルやReduceなどの処理で色々アレンジするらしい。

【2】バッチ処理の高速化が意味するもの

バッチ処理は業務システムの基本アーキテクチャだ。
特に金融系システムでは、毎日数万～数十万のトランザクションデータをバッチで一括処理するのも稀ではない。
この処理の実装は簡単であろうとも、テストして品質を確保するのは非常に難しい。

何故なら、高負荷な環境でしか再現できないバグは結構あるのに再現させにくい。
また、バッチ処理が異常終了した時、全件ロールバックさせると更に負荷がかかる。
だから、100件おきにチェックポイントを区切り、途中までCommitを実行し、途中から再開できるような仕組みを作る必要がある。

つまり、バッチ処理は、高負荷な環境のシステムテストや異常処理の設計がかなり難しいのだ。
しかし、Googleが適用しているMapReduceモデルでは、GFSというGoogle独自の分散ファイルシステムを使って、壊れたノードは別のノードが引き継ぐという冗長性を確保している。
並列処理なので、プロセスが死んでも他プロセスが引き継げばいい。

Naoyaさんも言っていたが、バッチ処理は冗長性が非常に大事。
いわゆるフォールトレランスが大事なのだ。

【3】日本のSIerの現状

上記の話を聞いて、非常に驚いた。
関数型言語の計算モデルがバッチ処理を抜本的に変えたとも言える。

日本の大手SIerのプログラマ、プロジェクトリーダーは、マンパワーでシステム開発し、マンパワーで品質を確保しようと懸命になっている。
Googleは、システム開発の前提条件そのものをひっくり返して、画期的アーキテクチャで作り直している。
当然、品質確保のやり方も日本のSIerと全く違う。

はてなのNaoyaさんは、少なくとも、Googleの論文を読んでいる。
日本の大手SIerにいるプログラマ、プロジェクトリーダーで、Googleの論文を読んでいる人はいるだろうか？
皆、残業に追われて、デスマーチに追われているうちに、Googleが生み出した技術などに取り残されている。
自分の技術が古くなっている事実にも気づかずに。

はてなは日本のGoogleみたいだ。