クラウドではソフトウェアの品質が課金の差として出てくる

はてなブックマーク - atsushifxのブックマーク - 2009年11月26日の文言「クラウドではソフトウェアの質は課金の差としてでてくる」が秀逸なのでメモ。

【元ネタ】
InfoQ: パフォーマンスを硬貨で測る

はてなブックマーク - atsushifxのブックマーク - 2009年11月26日

(前略)
クラウドプラットフォームでは、CPU使用量を10%削減すれば、そのままクラウドプロバイダからの1ヶ月の請求が10%削減されることになる。
例えば、 Windows Azureは1計算機による1時間の計算に12セントかかる。
このことを知った上でよいプロファイラを使えば、文字通り特定のコードブロックが会社に1ヶ月どれくらいコストを発生させているかを言うことができるだろう。
(後略)

クラウドでは下記の公式が成り立つ。

ソフトウェアの品質の差＝パフォーマンスの差＝課金の差＝コストの差＝利益率の差

データストアがRDBからkey-value storeへシフトする流れがある理由は、クラウドによって、ソフトウェアの品質、特にパフォーマンスの差が利益率に直結する事実が大衆の目の前に出てしまったからだろう。

クラウド上のSW開発は、関数型言語によってデータ処理をMapReduceアルゴリズムでいかに高速化するか、が鍵を握るのかもしれない。
「クラウドコンピューティングは開発者にとってゲームのやり方を変えてしまうものである。」という指摘はとてつもなく鋭い。

TiDDを実践して気づいたことpart4～TestLinkによるテスト戦略

チケット駆動開発にTestLinkを導入してテスト管理してみて、テスト戦略みたいなものをぼんやりと感じた。
以下メモ書き。

【元ネタ】
脱Excel！ TestLinkでアジャイルにテストをする 4頁目－ ＠IT自分戦略研究所

テスト手法の概念をTestLinkで説明する: プログラマの思索

TestLinkを運用して気付いたことpart8～みなしバグ、ブロッキングバグ、周辺テスト、そしてクリティカルパス: プログラマの思索

TestLinkを運用して気付いたことpart9～後追いテスト: プログラマの思索

TestLinkを運用して気付いたことpart4～TestLinkの概念を再考: プログラマの思索

TestLinkを運用して気付いたことpart5～TestLinkのテストケースの概念: プログラマの思索

TestLink・BTS・SVN・Hudsonの関連構造: プログラマの思索

【1】Redmineによるチケット駆動開発はとてもアジャイルに開発できるけれど、システムテストや受入テストの進捗管理はやりにくかった。
テスト工程の進捗管理は、テストケースの実施数・成功数・失敗数の予定・実績を比較することにあるけれど、Redmineチケットはテストケースと一致しないからだ。
だから、TestLinkを導入して一番良かったのは、テスト結果集計画面で、リアルタイムにテストの進捗を見れるようになった事であり、それから早期に是正対策を取るのが可能になった。

TestLinkがExcelなどの他のテスト管理ツールよりも良い点の一つは、Redmine・Trac・Mantisなどの既存のBTSと連携する機能がある事だ。
この機能によって、テストケースに失敗した場合、BTSチケットにバグの内容を書き込んで、バグ修正とバグ検証をペアプロのように作業できるようになる。

SW開発で最も難しい局面は、結合テスト(Integration Test)・システムテスト(System Test)・受入テスト(User Acceptance Test)などの各テスト工程で頻発するバグをいかに直していくか、にある。
バグ修正＆検証フローは実はとても複雑なワークフローであるからだ。

脱Excel！ TestLinkでアジャイルにテストをする 4頁目－ ＠IT自分戦略研究所の「図4－4－4　TestLinkのバグ検証とRedmineのバグ修正の連携フロー 」に書いたように、バグは修正して終わりではなく、バグ修正内容を検証して、更に失敗したテストケースが成功した所までの作業を含む。
そして、この作業は、バグを発見し検証するテスター、バグを修正する開発者、リリース作業を行うライブラリアン、そして全てのプロセスを監視するプロジェクトリーダーの4人が関わるので、そのやり取りだけで忙殺されやすい。

従来は、この作業内容をExcelの障害報告書に記載して、紙ベースで管理し、各担当者が判子欄にサインして承認するというフローをやっていた。
だから、バグが1日10件も出るととても煩雑になり、バグ管理だけでプロジェクトリーダーが忙殺される時も多かった。

TestLink＋Redmineの良い点は、この作業をチケット駆動開発と言うプロセス上で、バグ修正＆検証のワークフローを明示した点にある。
更に、脱Excel！ TestLinkでアジャイルにテストをする 4頁目－ ＠IT自分戦略研究所の「図4－4－5　バグ修正に対するRedmineチケットの状態遷移図 」に書いたように、Redmineのデフォルトのワークフローではバグ検証の作業管理がやりにくいので、更にカスタマイズした。

これが本来のバグ修正なのだ、と気付いた瞬間が、TestLinkによるテスト戦略を感じた時の一つ。

【2】TestLinkのテストケースのステータスには「成功」「失敗」「未実施」以外に「ブロック」がある。
「ブロック」は事前条件を満足できないためテスト不能な状態を表す。
このブロックを初めて使いこなせて、テストにはバグ検証の限界があるのだと気付いた時が、TestLinkによるテスト戦略を感じた2番目の瞬間。

実際にテストしてみると、1個のテストケースが失敗すると、1個のバグが出て、後続のテストケースは全てブロックになる。
更に、バグに依存する機能のテストケースは、全て「みなしバグ」になり「失敗」になる。
また、バグの原因を追求すると、類似バグが出てくる為、更にバグが増えてくる。

ブロックやみなしバグの発生源は、ブロッキングバグと言われる。
まさに、テストどころか開発そのものをブロックしてしまう危険バグを指す。
テスト工程では、ブロッキングバグをいかに早く的確に潰すか、が鍵を握る。

実際は、1個のテストケースの失敗の影響はとても大きく、最低10個のテストケースが「失敗」又は「ブロック」になる時が多い。
つまり、「みなしバグ」や「ブロック」のテストケースはテストしても無意味なのだ。
以前は、「みなしバグ」や「ブロック」の発想がなく、とにかくテストしまくるものの、バグが出た為に再テストするテストケースが多発して、うまく制御できなかった。
だから、無駄にテスト工数を浪費して、肝心のバグ修正がおろそかになる場合も多かった。

そんな経験を経て、イテレーション単位にTestLinkのテスト計画を実施しながら、常にテストの失敗率に注目するようになった。
理由は、テストケースの失敗率がある上限を超えると、殆どのテストケースがブロック又はみなしバグで失敗の状態になってしまい、もはやテストしても無意味になる状態があるからだ。
僕の経験では、失敗率が10％を超えるともはやテストしても無意味で、ブロッキングバグを修正するよりも、最初から単体テストをやり直す方が早いように感じてしまう。

【3】TestLinkのテスト結果はビルドという概念で管理される。
ビルドはビルド番号を指すと教えてもらった時、ビルドでイテレーションを管理すればいいのだ、と気付いた瞬間が、TestLinkによるテスト戦略を感じた3番目の瞬間。

ビルドの利点は、同じテストケースを回帰テストで管理しやすくなる事。
また、ビルドのテストケースが全て完了したら、ビルド番号を振り直せば、ビルドモジュールの履歴に書かれたチケットNoからバグチケットを探す事ができる。

アジャイル開発にTestLinkを組み込む場合は、TestLinkのテスト計画をイテレーションと見なして、反復型テストを行えばいい。
すると、テストケースを作ってテスト計画を立てた時点で、テスト期間が短すぎたり、テスターや開発者が少なすぎたり、テストケースがそもそも多すぎる場合、実は納期までにテストが終わらない事実が判明する時がある。
原因は、テストと言うスコープを制御できていないのだ。

2～4週間のイテレーションにテスト計画を押し込めるには、2種類の戦略がある。
一つは、イテレーション内で開発とテストの両方を行い、テスト完了後にリリースするインクリメンタル型開発。
もう一つは、開発のイテレーションが完了後、せいぜい数百の単位でテストケースを分割したイテレーションを順次テストしていく反復型テスト。

普通のシステム開発では数千～数万のテストケースに膨れ上がる為、おそらく反復型テストが基本戦略になるだろう。
イテレーションとテスト計画を同一視することで、テストのスコープを制御しやすくしているのだ。

更に、後追いテストや五月雨式テストというテスト戦略も出てくる。
後追いテストは、テスト完了後からリリース直前までに優先度が低いテストケースや未実施のテストケースを後を応用に実施する事。
五月雨式テストは、仕様追加が頻繁な場合、仕様が決まって開発が終了次第、すぐにテストして、五月雨式に開発＆テストしていく事。

後追いテストも五月雨式テストも、十分すぎる品質よりもスケジュールを重視する昨今のビジネスを反映していると言える。
ほどほどの品質をまずは確保した後で、リリースを優先し、品質を作りこむテスト戦略。

プロジェクトリーダーは、インクリメンタル型開発・反復型テスト・後追いテスト・五月雨式テスト等のテスト戦略を意識的に使い分ければ、SW開発で最も難しいテスト工程をコントロールしやすくなるだろう。

EclipseからRedmineへ接続するRedmine-Mylyn Connector

EclipseからRedmineへ接続するMylynプラグインの使い方が書かれている記事があったのでメモ。

【元ネタ】
Redmine-Mylyn Connector | shibomb

Redmine-Mylyn Connector | Get Redmine-Mylyn Connector at SourceForge.net

SourceForge.net: Installation - redmin-mylyncon

最初は、Redmine本家にあるRedmine - HowTo Mylynを参考にしたが、うまく動作しなかった。

Redmine-Mylyn Connector | Get Redmine-Mylyn Connector at SourceForge.netならば、サーバー側とクライアント側の両方に設定すればMylynを使えるようになる、とのこと。
Mylynの画面を見ると、使いやすそうなGUIみたい。

TiDDを実践して気付いたことpart3～繰り返し開発の戦略

Redmineでチケット駆動開発を実践して改めて、アジャイル開発は繰り返し開発であると認識した。
Redmine、Trac、Mantisでチケット駆動開発を経験してみて、繰り返し開発の戦略やコツがあるのがぼんやりと分かってきた。
ロジカルに言い尽くせないけれど、以下メモ書き。

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

Subversionコードラインのライフサイクル: プログラマの思索

チケット単位に並行開発する事例: プログラマの思索

裏プロセスは並行プロセス: プログラマの思索

チケット駆動開発のモチーフ: プログラマの思索

チケット駆動開発のFAQ: プログラマの思索

【再考】TiDDのプラクティス集: プログラマの思索

ツールが開発プロセスを改善する: プログラマの思索

TiDDを実践して気づいたことpart2～これがアジャイルだ！と気付いた瞬間: プログラマの思索

【1】チケット駆動開発では、タスクを全てチケットに書き起こし、それらチケットをリリース計画に基づいて各バージョンへアサインし、順次リリースしていく。
つまり、XPの小規模リリースとは、2～4週間という短期間でリリースを繰り返す繰り返し開発である。

繰り返し開発(スパイラルモデル)には、インクリメンタル型と反復型の2種類があるのは既に知られている。
インクリメンタル型は、各繰り返し(イテレーション)でどの機能を実現するかを決め、それを１回の繰り返しでリリースする。
反復型は、各繰り返し(イテレーション)でシステム全体の機能を少しずつ作っていき、何度も繰り返して完成させる。

RUPが反復型開発であるのに対し、XPやScrumのようなアジャイル開発は、基本はインクリメンタル型開発だ。
顧客価値を重視する開発スタイルだから、顧客へ早めにリリースすることを優先する。
つまり、XPの小規模リリースとは、小刻みに機能拡張しながらリリースしていくインクリメンタル型開発スタイルを指している。

インクリメンタル型開発の利点は、機能というスコープが小さいのでスコープを制御しやすい点にある。
リリースが最終ゴールだから、スコープが揺れていてはリリースできないからだ。

逆に反復型開発は、スコープを制御しづらい弱点があるように思う。
例えば、工程ごとの繰り返し開発の途中で、度重なる仕様変更を取り込んでしまい、スコープを制御できずに破綻してしまう時は多くないだろうか？

しかし、反復型開発では、システム全体の機能を何度も繰り返しながら作り上げるため、スコープさえ制御できていれば、品質を向上させるために使える。

【2】Redmineでチケット駆動開発を実践すると、自然にインクリメンタル型開発になったけれど、それだけでは品質には不安があった。
だから、TestLinkを導入して、システムテストや受入テストの工程を別のイテレーションで実施し、色んな観点のテストやバグ修正を行って、品質向上を図った。
すると、このイテレーションは、反復型開発に似ているのに気付いた。

つまり、リリースできる品質まで持ってきたが、更なる検証で品質を向上させたい場合、インクリメンタル型開発から反復型開発にチェンジして、複数回のイテレーションでテストを実施する手法だ。
これによって、TestLinkのテスト計画をRedmineのバージョンに見立てて順次テストしていく反復型開発がやりやすくなった。

【3】反復型開発を使う場面は他にもある。
特に、複数のサブチームによる大規模開発、ソフトウェア開発チームとハードウェアチームが連携する組み込み製品開発などが相当するだろう。

例えば、組み込み製品開発では、SWチームは、HWチームから提供されるハードウェアを元に、HWチームの開発サイクルよりも短いイテレーションで順次開発してみる。
理由は、早めにハードウェアとソフトウェアを結合して動作させながら確認したいからだ。

すると、この場合、HWチームの1イテレーションに対し、SWチームは複数のイテレーションをこなしていることになる。
つまり、イテレーションの入れ子構造で反復型開発を行っている。

反復型開発のもう一つの利点は、イテレーションの入れ子構造によって、開発のスケールアップがやりやすい点もあるだろう。

【4】インクリメンタル型開発が難しい理由は、並行開発になってしまう点にあると思う。

例えば、イテレーションで実装した機能をリリースしたら、そのシステムは顧客の前で動き続けるが、裏では開発チームが次のイテレーションの機能を実装し始める。
そして、次のイテレーションの機能をリリースしたら、前のイテレーションのシステムは廃止して、裏で次の次のイテレーションの開発を始める。
つまり、自然に、本番運用と新規開発の2種類のコードラインを常時保守せざるをえないのだ。

但し、並行開発に対する一つの回答は、メインラインモデルという構成管理手法で既に知られている。
つまり、trunkというメインラインからリリースする時は、ブランチを派生させ、常にtrunkが最新の安定した機能となるようにコードラインを保守する手法。

メインラインモデルの手法は、いくつかのバリエーションがある。
おそらく最もよく使われる手法はタスクブランチだ。
例えば、現在、Ver3.0へ向けて開発中で、その次のリリース予定のバージョンは4.0である時に、突然の仕様追加に対応しなくてはならなくなった場合、Ver3.1のタスクブランチを定めて、Ver3.0→Ver3.1→Ver4.0の順にリリースしていくという開発スタイル。
このタスクブランチの手法によって、品質を維持しながら、納期とスコープ、工数のバランスを取ることができる。

チケット駆動開発では分散バージョン管理を使って、更にトピックブランチという開発スタイルも選択できる。
つまり、チケットごとにトピックブランチをローカルに作って開発し、最後にtrunkへプッシュする開発スタイル。
これはタスクブランチを各チケットへ更に分化した場合に相当する。
GitやMercurialを使っていれば、おそらくスムーズに運用できるだろう。

チケット駆動開発による小規模リリースは、インクリメンタル型でも反復型でもどちらの繰り返し開発も運用可能だ。
繰り返し開発では、インクリメンタル型と反復型を故意に使い分ける戦略が重要ではないだろうか？
また、アジャイル開発が難しい理由は、インクリメンタル型と反復型を使い分けるノウハウがなかなか見当たらず、実践しにくい点にあるのではないだろうか？

クラウド時代のSW開発スタイル

「Twitterの衝撃 140文字がビジネスからメディアまで変える」を立ち読みした。
TwitterがRuby on Railsをフロントエンドで使っているのは知っていたが、メッセージの非同期処理(MQ)でScalaを使って性能改善したという説明があった。
気になったのでメモ。

【参考】
まだブロ: [Scala] Twitterの移行について

twitterがrubyからscalaへスイッチ - huixingの日記

第7回 関数脳のつくり方　First Season - 刺激を求める技術者に捧げるScala講座：ITpro

ScalaはJavaVM上で動く関数型言語。
TwitterがScalaをどこでどのように使っているのか、正直理解できていない。

しかし、大量のデータをさばく処理に対し、関数型言語を使ってMapReduceアルゴリズムで高速化を図っているのではないか、と推測している。
そのためにScalaを使ったのではないか、と。
上記の記事や本によれば、Scalaによるチューニングは大成功だったらしいから、そのノウハウが知りたい所。

Twitterは当初はRuby on Railsでアジャイルに実装しているという印象があった。
しかも、サーバーはクラウドのサービスを利用している。
#Twitter のホスティングは NTT Americaとのこと(コメントを受けて修正)

つまり、サーバー運用をアウトソーシングしているので、スケールアップしやすく、初期投資のリスクも低い。
クラウドというサービスは、ベンチャー企業にとってとても扱いやすいビジネス環境なのかもしれない。

今後のWebシステムの開発スタイルはこんな感じ。
フロントエンドはRailsやSeasarでサクサク作り、バックエンドやバッチ処理は関数型言語でMapReduceアルゴリズムをフルに使って高速化する。
そして、サーバー運用はクラウドのサービスを使ってアウトソーシングし、初期投資のリスクを抑えて、負荷が高まればスケールアップすればいい。

スクリプト言語、関数型言語、そしてクラウドが、今後のWebシステム開発のキーワードになるかもしれない。

プロジェクトマネジメントプリンシプル

「プロジェクトマネジメント プリンシプル - 変革の時代を生き抜くための人と組織の挑戦　[原書名：The Principles of Project Management]」を読み始めた。
今まで敬遠していたPMBOKの概念が支障なく理解できる。

プロジェクトマネージャがその権限を振るえる組織、チームビルディング、コンフリクトマネジメント、調達管理。
プロジェクトと言う形態が工学として知識体系化されたきっかけは、航空宇宙科学のプロジェクトから始まったのか、とか。
プロジェクトチーム形成や人的資源管理は、まさにプロジェクトファシリテーションそのものだな、とか。
「変化を抱擁する」をフレーズとしたXPは、まさにプロジェクトの特徴をおさえているな、とか。

内容は少し古いけど、エッセンスは詰まってます。

開発に30分、テストに10万年

センセーショナル（？）な記事があったのでメモ。

【元ネタ】
開発するのに30分、テストするのに10万年 － ＠IT MONOist

わずか30分以内に書けるプログラムでも、全パス網羅のテストは単純計算で10万年かかるという。
更に、仕様漏れ、要件漏れを検出しなくてはならないから、テスト工数はもっとかかる。

SW開発が難しい理由の一つは、実装したプログラムの信頼性を保証する工数が天文学的数字のため、不十分な品質と割り切るしかないこともあるのだろう。

C#からRedmineにアクセスする方法

C#からRedmineにアクセスする記事があったのでメモ。

【元ネタ】
.NETからRedmineへアクセスするライブラリを試してみた

Redmine Client

Redmine ClientはDLLであり、下記のAPIが使えるらしい。

Library:

* Using Redmine's web interface, thus not circumventing it's security
* Log-in to Redmine
* Get list of projects
* Get list of issues for selected project
* Get list of activities
* Get list of trackers
* Get list of users
* Get list of statuses
* Get list of priorities
* Get list of versions
* Get recent project activity
* Create new issues
* Report time spent on an issue

Client application:

* Measure time spent working
* Report time to Redmine
* Create new issues in Redmine

クライアントから、作業時間計測・実績時間報告・チケット登録ができるのは面白い。
RedmineのWebUIからRedmineを操作できるらしいから、RESTfulっぽい。
C#のRedmineクライアントを作る人は試してみてはどうだろうか？

チケット駆動開発でメトリクス採取コストを下げる

面白い記事を見つけたのでメモ。

【元ネタ】
データを見ないプロマネ

(前略)
ですが、トラブルになるプロジェクトは経験上、
* プロジェクトデータを継続的に収集できる仕掛けがない
* メトリクスの分析とフィードバックが不十分(集計して眺めているだけ…）
のいずれかが該当するはず。
こういうプロジェクトは個人的にPDDD(Plan-Do-Do-Death)プロジェクトと呼んでます(^^)
オープンソースのプロマネツールも数多く存在する現状を考えると「プロジェクトデータを継続的に収集できる仕掛けがない」プロジェクトは減ってくでしょうから、プロジェクトデータを分析して、早めに適切なアクションを打つことができるプロマネの価値はさらに高まっていくのではないでしょうか。

マネジメントの基本は予定と実績の比較・評価から是正対策を立てることだ。
しかし、計画を立ててその後は知らない、制御できない、というプロジェクトは数多い。

プロジェクトデータを採取しようにも、メンバーの入力工数が逆に増えて、プロジェクトの生産性が落ちる場合がある。
ある大手SIでは、メンバーに15分おきに作業内容を強制的に入力させていると聞いたが、開発者は奴隷ではないから、むしろモチベーションも低下しているのではないか？

チケット駆動開発では、SVNコミットする時にチケットと連携する機能があるし、チケットに作業履歴だけでなく進捗情報を記入することもできる。
つまり、開発者がToDo管理している感覚の背後で、BTSがチケットを自動集計して、進捗や品質に関するメトリクスを出力してくれる。

PMBOKなどのマネジメント手法も一般化しているから、メトリクスさえあれば好きなようにリスク分析できるはずだ。
今後のプロマネは、マネジメント手法だけでなくメトリクスを採取するツールや運用ルールも考慮する必要があるだろう。

チケット駆動開発のアンチパターン

チケット駆動開発のFAQ、プラクティス集以外にも、アンチパターンを考えてみた。
以下メモ書き。

【元ネタ】
チケット駆動開発のFAQ: プログラマの思索

【再考】TiDDのプラクティス集: プログラマの思索

【1】チケットのアンチパターン
【1-1】乱発されたチケット

よくある最悪なパターンは下記2ケースがあるだろう。

設計、開発、単体テストまでは穏便なものの、結合テストで火を噴き、たくさんのバグ報告があがる。
あるいは、リリース直後には、たくさんの障害報告や問合せが殺到する。

そのままチケットに登録すると、チケットが乱発される。
そして、それらのチケットを精査する工数が開発チームの許容量を超えると、チケットは放置される。

こういう状況はもはや、アジャイルだろうがTiDDだろうがCMMIだろうが、手に負える状況ではない。

【1-2】有効期限切れのチケット・放置されたチケット

終了予定日を過ぎて放置されたチケットを指す。
担当者がアサインされていないチケット、担当者も作業を忘れてしまったチケットが相当する。
こういうチケットが増えるたびに、チケットの精度も運用ルールも混乱していく。

対策としては2種類あると思う。
一つは、チケット管理の最終責任者は現場リーダーである事。
現場リーダーは、定期的に必ずチケットが最新の状態であるかチェックし、担当者へ逐一作業確認すべきだ。
担当者がアサインされていないチケット、リリース予定のバージョンがないチケットはすぐに保守すべきだ。
それが現場リーダーの本来の仕事であるからだ。

もう一つは、バックログのような特別なイテレーション、インシデント管理用プロジェクトのような特別なプロジェクトで管理すること。
顧客からの改善要望や問合せは、Scrumのプロダクトバックログのように、バックログのイテレーション又はインシデント管理用のプロジェクトで別管理する。
開発チームは、それらをチケットに登録しておくが、平時の開発作業とは別の作業であると認識し、リリース計画を立てる時に、顧客の要望や問合せを精査して、どのバージョンへリリースするか、取捨選択する。
つまり、XPの計画ゲーム、Scrumの計画プロセスに相当する作業を、バックログやインシデント管理プロジェクトで行う。

あるいは、ソースがコーディングルールに則っていない、とか、リファクタリングすべきだが優先度が低いなどの開発チーム内部の作業は、内部課題の特別のイテレーションで別管理する。
これらもチケットに登録しておくが、平時の開発で関係するチケットにリンクさせておく。
これらのチケットは、リスク管理に相当する。
工数見積もりが実績と大きく異なるのは、リファクタリング工数を見積もっていない場合がとても多いからだ。

【1-3】責任が重すぎるチケット

複雑で大変な作業、複雑な複数の成果物を作る作業を一人の担当者がアサインされた一つのチケットにしてしまう状況。
その担当者のプレッシャーは大きいし、担当者がもし新型インフルエンザにかかったら、誰もカバーできなくなる。

チケットは仕様書ではなく、作業指示書だ。
だからこそ、WBSのように成果物単位に細分化し、更に1個の成果物を一人の担当者が1週間以内に作業するまで細分化すべきだ。
実際の現場に合わせて、チケットの粒度はカスタマイズすればいい。

おそらくリリース後に集計したら、1人日以内のチケットへ細分化されているだろう。

【1-4】停滞したチケット

アサインされた担当者のチケットの進捗が進まない状況。
よくある状況は、進捗が90％のまま1週間経ってしまうこと。

対処としては2つある。
一つは、実績の進捗率は、0％・50％・100％の3種類と固定する方法のように、ルール化する。
つまり、チケットのステータスと進捗率を対応付けする。

もう一つは、チケットの中身を精査して、別作業を別チケットへ細分化すること。
チケットの進捗が悪い原因は、WBSの洗い出しが不十分だった時が多い。

例えば、1個の画面を実装するのに、実は複数の共通ライブラリ、モジュール、共通画面を作るために工数がかかっている、とか、新規の機能追加のはずなのに実はリファクタリングしていた、など、作業の予定と実績が大きく狂っている時が多い。
つまり、現場リーダーの作業割り振りが間違っているのが原因の大半だ。

【1-5】タスクがチケットに書かれない

開発チームでやるべき作業をチケットに登録していない状況。
例えば、ビルド作業、テストデータ作成作業、開発環境の構築作業などのように、顧客に無関係で開発チーム内部でやるべき作業を登録せずに、あうんの呼吸でやっている場合が多いだろう。

すると、やるべきタイミングで作業を忘れて、進捗が遅れたり、作業の品質そのものが落ちる。

この状況の根本原因は、WBSの洗い出しが不完全か、せっかく洗い出したWBSをチケットにすべて登録していないか、のどちらかだ。
つまり、現場リーダーがチケット駆動開発の運用ルールを徹底できていないのが根本原因だ。

【1-6】SCMと連携されてないチケット

SVNコミットする時に、チケットNoを書き込まず、チケットとSVNリビジョンが紐づかない状況。
まちゅさんは「No Ticket, No Commit!」と呼んで重視している運用ルール。
この状況では、せっかくのチケットが単なる作業履歴に過ぎない。

チケットとSCMが連携することによって、要件からソース、ビルドモジュールまでチケット経由で相互に追跡可能になる利点がある。
特に要件管理を実現したい場合に、とても強力な運用ルールだ。

【2】バージョンのアンチパターン
【2-1】ゴールの見えないバージョン

いつまで経ってもリリースできないバージョン。
よくある例は、顧客の改善要望の言いなりになって、バージョンへどんどんチケットを追加していくこと。
すると、いつまで経ってもリリースできないどころか、システムの品質がどんどん劣化していく。
機能追加すれば、必ずバグが紛れ込んでしまうからだ。

ScrumでもXPでも、スコープをあらかじめ制御しておくことを重視する。
イテレーション実施中に突然の仕様変更の要求が来たとしても、基本は次イテレーションに回して、すぐに対応しない方がいい。
機能追加よりも品質を重視する方が、手戻り作業が少なくなるからだ。

【2-2】優先度がごちゃ混ぜのバージョン

リリース計画、イテレーション計画がきちんと行われず、一つのバージョンに全てのチケットが放り込まれた状況。
例えば、顧客の問い合わせ・改善要望・障害報告、リファクタリングなどの作業が混じっていて、メンバーは、何から手をつければよいか、分からなくなっているだろう。

XPの計画ゲームでも、Scrumの計画プロセスでも、リリース計画をきちんと作る。
複数のバージョンを立てて、定期的に小刻みにリリースしていくという開発スタイルを取れば、チケットの優先度は自然に定まる。
顧客の要件の重要度と開発工数のバランスから、リリース計画が作られて、そのバージョンにチケットをアサインしていく。
上記の状況に陥った原因は、現場リーダーがプロジェクトのスコープをきちんと管理できていなかったことにあるだろう。

また、開発サイクルが異なるチケットは別管理にした方がいい。
例えば、顧客からの単なる質問やリファクタリングなどは、別のバージョンやプロジェクトで管理した方がいい。
本番運用のソースと新規開発中のソースをブランチで別管理するように、プロジェクトもブランチ単位で分けた方がいい。

【3】プロジェクトのアンチパターン
【3-1】大規模プロジェクトでごちゃ混ぜのプロジェクト

大規模プロジェクトでは、複数のサブチームのタスク管理が必要になるが、一つのプロジェクトに全てのサブチームのタスクが混在している状況。
TiDDを実践すると、経験的に5人以上のチームのタスク管理は非常に煩雑になる。
理由は、TiDDにおけるチケットの粒度は開発者視点なので、とても細かいからだ。

だから、複数プロジェクト機能を使って、サブチーム単位や工程単位などで分けた方が管理しやすいと思う。

また、チケット管理の専門担当者を配置し、随時チケットを保守させる。
更に、定期的に課題管理会議を開いて、チケットの棚卸を行った方が良い。
チケットに上がった問題が複数のサブチームが連携しなければ解決しない場合もあるので、調整作業が必要だからだ。
あるいは、どのチケットから手を付けた方が良いか、サブチームのリーダーの観点ではなく、もっと上層部のマネージャの観点で優先度を決めた方が良い場合も多々あるだろう。

他にも気付いたアンチパターンがあれば、随時追加していきたい。

TiDDを実践して気づいたことpart2～これがアジャイルだ！と気付いた瞬間

TiDD(チケット駆動開発)が何故、アジャイル開発と密接に関係するのか、経験を思い出して考えてみたことをメモ。
＃下記はロジカルでないので注意。

【元ネタ】
裏プロセスは並行プロセス: プログラマの思索

チケット駆動開発のモチーフ: プログラマの思索

チケット駆動開発のFAQ: プログラマの思索

【再考】TiDDのプラクティス集: プログラマの思索

ツールが開発プロセスを改善する: プログラマの思索

【1】Redmineでチケット駆動開発を実践して、これがアジャイルだ！と気付いた瞬間は、イテレーションと言うリズムに気付いた時だ。
Redmineのロードマップ画面で、バージョン毎にチケットをアサインした後、バージョンの進捗率が100％になり次第、随時リリースしていった。
すると、開発メンバーはリリース予定のバージョンを直近のゴールと見なして、自然に頑張るようになった。

そして、リリース後にKPTによるふりかえりMTを開いて、リリースしたバージョンについて、KPTの観点でヒアリングして議論したら、自然にプロセス改善になっていた。
僕は、チケットの運用ルール改善や作業の品質改善を狙っていたのだが、メンバーからは、設計書のこういう部分が分かりにくいからバグが出た、このワークフローはやりにくい、チケットでタスクの見通しがよくなった、など、色んな意見が出て、紛糾した。
そして、次のバージョンへの対策も決まり、ちょっとずつ、開発チームの作業効率も上がった。

SW開発で最も嫌なのは、ゴールが見えず、残業や休日出勤が延々と続く状況。
いわゆるデスマーチ。
リリース前のシステムテスト、リリース直後の膨大な問合せや障害報告で起きる。
特に、ウォーターフォール開発で、ドカンと一発リリースした直後が大変。
ウォーターフォール開発では、イテレーションと言うリズムが無いのが一番嫌だ。

【2】アジャイル開発では、スコープをコントロールしながら、小刻みに機能拡張しながらリリースしていく。
だから、リリース後の障害報告や問合せもそれほど多くないし、開発チームがコントロールできる範囲内に抑えられる。
何よりも、スコープをイテレーションに閉じ込めて、イテレーションというリズムが生まれるのが気持ちいい。
XPやScrumならば、必ず２～４週間後にリリースというゴールがあるので、作業が見えやすい。

チケット駆動開発では、ロードマップ画面でリリース計画やチケットの取捨選択を行う。
つまり、ロードマップ画面で、スコープを制御しながら計画ゲームを行っている感覚だ。

イテレーションは通常２～４週間という小さいタイムボックスのため、納期やコストが固定だから機能というスコープで調整するしかない。
つまり、リリース計画を立てて、複数のバージョンを随時リリースしながら機能拡張するという小規模リリースを自然に行っていた。

小規模リリースという繰り返し型開発に気付いた瞬間が、これがアジャイルだ！と思った2番目の瞬間。

このロードマップは、チケット駆動開発で最も重要な機能だと思う。
ロードマップは、平鍋さんが提唱するプロジェクトファシリテーションの「見える化」の例で出てくる野球のスコアボードと同じだ。
ロードマップには、「最新の正しい情報」がバージョンの進捗率とチケット一覧が表示されていいる。
Webなので、「メンバーも現場リーダーも(できれば顧客も)」ロードマップを見れる環境にある。
そして、ロードマップにあるバージョンの予定や進捗から、直近のゴールはこれだ、と「次の行動」が誘発される。

チケット駆動開発はプロジェクトファシリテーションともすごく相性がいいと思う。

【3】Redmineは1プロジェクト＝1リポジトリという設計思想で、Subversionと連携できる。
更に、Redmineには複数プロジェクト機能がある。
だから、ブランチを別プロジェクトで管理してみたら、自然に並行開発になっているのに気付いた瞬間が、これがアジャイルだ！と思った3番目の瞬間。

Subversionをまともに使いこなすまで、ずっとtrunk1本だけのコードラインだったから、並行開発を意識する事はなかった。
しかし、小規模リリースしていくと、本番環境のソースはブランチ、裏で機能拡張中のソースはtrunkというソース管理に自然になる。
すると、マージ作業という面倒な作業が発生するので、Redmine導入前はSVNのタグを乱発してコントロールしにくかった。

Redmineでは、本番運用と開発中のチケットは別々に作り、マージ作業のチケットは発生源の障害修正のチケットとリンクすることで、開発者はすごく作業しやすくなったみたい。
管理者としても、マージ作業のタイミングを忘れる事がなくなったので、ありがたい。

上記の経験を通じて、繰り返し開発が難しい理由は並行開発という開発プロセスが隠れているからだ、と思うようになった。
一度リリースしたソースはそれで終わりではなく、ブランチとして次のリリースまで生き続ける。
開発チームは、次の開発をやりながら、本番運用のソースも保守しなくてはならない。
そして、裏で開発中のソースをリリースしたら、本番運用のブランチを新たに作り、以前のブランチを廃止するという運用サイクルが生まれる。

つまり、小規模リリースというプラクティスは、単なる小刻みな機能拡張による繰り返し開発だけでなく、複数のコードラインを常時保守する並行開発という開発プロセスが本質なのだ。

アジャイル開発が難しい理由は、この並行開発を制御できない点にあると思う。
ウォーターフォール開発であろうとも、組込み製品やパッケージ製品の開発では、複数の製品ラインを保守しながら本番運用と開発中の2系統のソース管理をしているのだから、もっと大変なはずだ。

逆に言うと、並行開発を意識している開発プロセス、開発チームは、自然にアジャイルな開発を行っているだろうと推測している。

PFP関西WS#20でチケット駆動開発が紹介されました

PFP関西ワークショップ＃20で平鍋さんのPFの資料が下記に公開されました。

４３頁目に、「チケット駆動開発とPF」のスライドで、PFの事例の一つとして、チケット駆動開発(TiDD)が紹介されています。
平鍋さん、ありがとうございます！

Project Facilitation from Kenji Hiranabe

プロジェクトファシリテーション、Agile開発、Lean開発などの概要を知るには、上記だけで十分かも。

PFP関西WS#20の雰囲気は、2009-11-23 - mnishikawaの日記をどうぞ。

PFで最も重要な概念は「見える化」。
SW開発は営業や製造業と異なり、ただでさえ「見える化」しにくい。
だから、デスマーチプロジェクトに陥りやすく、プロセス改善しにくい弱点がある。

平鍋さんの資料のように、野球のスコアボードのように、「最新の正しい情報」を「選手」「審判」「観客」全員が見ていて、「次の行動」を誘発するのが重要。

TiDDでも特にRedmineでは、野球のスコアボードに相当する機能は、ロードマップ画面だと思う。
ロードマップを見れば、次のリリース時期はいつで、リリースまでにどんなタスクを消化しないといけないか、そして、進捗率は今どれくらいか、がすぐに分かる。
そして、リリースしたチケットは、ChangeLog(変更履歴)として残るので、プロセス改善の資料になりうる。

RedmineやMantisにはロードマップと変更履歴の機能があるのに、Tracはそれらの機能が不十分な為、見える化が不十分なように思う。
このロードマップ機能には、SW開発に関する重要な概念が隠れているので、色々考えてみる。

TiDDを実践して気付いたことpart1～解ける問題であれば人は自然に解決する方向へ動き出す

PFP関西ワークショップ＃20で平鍋さんのPFの話を聞いた。
もう何度も同じスライドで同じ内容を聞いているのに、いつも新鮮な感覚がある。

プロジェクトファシリテーションの話を聞きながら、チケット駆動開発(TiDD)でどうやって実現できるか、妄想をめぐらせてみた。

【元ネタ】
【Facilitation】解けない問題を解ける問題へ変換する: プログラマの思索

「ザ・ファシリテーター2―理屈じゃ、誰も動かない!」の本で「解けない問題を解ける問題へ変換する」という挿話がある。
この挿話では、解けない問題を解ける問題へ変換すると、人は自然に解決する方向へ動き出す、という教訓を提示している。

この教訓は、実際の開発現場でとても実感する現象だと思う。

SW開発では頻繁にデスマーチ・プロジェクトが起きる。
デスマーチ・プロジェクトでは、いくら目先の問題を解決しても、問題がとにかく多すぎて、現状がなかなか変わらない。
すると、メンバーもチームも無気力になり、一つの歯車で働いている感覚に陥る。
解けない問題はチームを無気力にするのだ。

過去、SW開発の諸問題を解決するために、色んな開発プロセスやプロセス改善の手法が提唱されてきた。
CMMI、PMBOK、RUP、Agileなど。
それらを勉強すると確かに概念は整理されるけれども、いずれも実践しにくい。

CMMIやRUPは、その膨大な量で圧倒されてしまう。
いくら勉強しても、あまりにも大きすぎて、開発現場へ応用しようとすると、畳の上の水泳練習みたいで、カスタマイズが難しい。
CMMIやRUPは勉強になるけど、運用するにはたくさんのノウハウを必要とする。

Agileも実践的プラクティスが多いけれど、良い方法と分かっていても、手が出せない部分が多い。
Agile開発の根本的な特徴は、頻繁なリリースを支える技術やプロジェクト管理手法が前提であるため、運用するには高度な作業やマネジメントが要求される。
手作業では到底無理であり、専用のツールは高価だったりする。

しかし、この数年で状況が少しずつ変わってきたように思う。
RedmineやTracなどのプロジェクト管理機能を持つBTS、SubversionやGit、Mercurialなど高機能なSCMのおかげで、タスク管理やソース管理をツールで補完できる範囲が広がってきた。

チケット駆動開発はTracのチケット管理から生まれたけれど、Redmineでチケット駆動開発を実践して初めてAgile開発をスムーズに運用できた経験をした。
すると、実際の現場の雰囲気も変わってきた。
つまり、ツールを使ってAgile開発について書かれた本の内容を運用できると、イテレーションを繰り返す度にチームは自然に改善されていった。

そして、Agile開発について書かれた本の内容を実践できただけでなく、それらの本に書かれていない新しい概念が出てきたように感じた。
その新しい概念は、当初はチーム特有のノウハウに過ぎないけれど、イテレーションを繰り返す度にノウハウが積み重なって、一つのプラクティスになる。

そのサイクルは、ツールを導入するとチームやメンバーの行動が変わり、行動が変われば考え方も変わっていく流れと同じ。
つまり、ツールが考え方を変えて、道具が新しい手法を生み出すサイクル。

ソフトウェアはとても柔軟で、しかもすごく威力がある。
それはビジネスだけでなく、SW開発自身についても同様だ。

ソフトウェア(ツール)で、SW開発の諸問題を解けない問題から解ける問題へ変換すると、チームもメンバーも自然に解決する方向へ動き出す。

SW開発の現状は、各種の概念や技法は出し尽くされた感があり、それをいかにツールで実現して、現場で運用できるようにするか、という問題へ変わりつつある気がする。

チケット駆動開発もその流れにあると思う。
実際、チケット駆動開発はBTSという従来のツールを使っているし、タスクをカードで管理する発想もXP等で既に提唱されているからだ。
しかし、チケット駆動開発というアイデアによって、アジャイル開発のインフラが整ってきたという現状がある。

今後、チケット駆動開発を実践して気付いたこと、考えたことを色々書いていく。

モデリングとプログラミングの観点の違い

要求開発の記事を読みながら思ったことをメモ。
＃あくまでもメモ書きであり、ロジカルでない。

モデリングとプログラミングは、根底から考え方が違うと思う。
モデリングできたからと言って、プログラムがすぐにできるわけではないし、モデルだけではシステムは動かない。
でも、モデリングで分析し尽さないと、思想のないプログラムが増殖し、それらのプログラムはすぐにスパゲティになる。
モデリングとプログラミングは相互に補完する関係にある。

モデリング技法には、OOAやDOA、他にも色々あるけど、基本は、エンティティを中心にその関係を考える。
一方、プログラミングは、基本はやはり手続きを考える。

構造化分析とは異なり、モデリングという概念が出てきたのは、DOAからだと思う。
DOAはモデルからデータと処理を区別して、データだけを取り出し、その関係をまとめる手法。
DOAはエンティティという入れ物が最初にありき。

DOAでもT字形ERでは、エンティティをリソースとイベントという2種類に分けて考える。
リソースは、マスタ系Tbl。例えば、顧客・商品など。
イベントは、トランザクション系Tbl。例えば、注文・在庫など。

リソースの関係からイベントが生じるという発想の元に、リソース間の関係にビジネスルールの制約を課す。
この手法によってER図が生まれる。
羽生さんの本(楽々ERDレッスン (CodeZine BOOKS))、渡辺さんの本(業務別データベース設計のためのデータモデリング入門, 業務システムモデリング練習帳 業務システムを効果的に設計するための精選45題)が詳しい。

OOAは、UMLという技法とセットで現れて数年前に流行した(ように思う)。
UMLにある各種のダイアグラムのうち、モデリングで最も重要な技法は、クラス図と状態遷移図だと思う。

ビジネス分析において、OOAもDOAと同じようにエンティティをまず洗い出すのが重要。
そのエンティティは概念モデルに現れて、その概念モデルはクラス図で表現する。

概念モデルはER図のように、クラス同士の関連に動詞を書き込んで、トランザクションを表現する。
つまり、DOAにおけるリソースとイベントが自然に現れる。
児玉さん(UMLモデリングの本質)は、リソースとイベントの関係を「もの-こと-もの」パターンと呼んでいた。

状態遷移図は、概念モデルで現れた一つのオブジェクトに注目し、そのオブジェクトの状態の動的な遷移を表現する。
仕様を理解できているかどうかは、状態遷移図を正確に書けているか、にかかっているように思う。

例えば、小売Webシステムならば、商品は販売中・カート・注文中・配送中・在庫無しなど色んな状態が各タイミングで変わる。
特に、排他制御が絡んだ在庫チェック、注文取消しの業務がとても難しい。

又、組込システムならば、缶ジュースの自動販売機の状態遷移の例が情報処理試験に良く出てくる。
自動販売機の状態も、販売中・販売完了など色々あるけれど、「缶ジュースが詰まってボタンが押せない」とか「在庫切れで販売できない」など色んなパターンも考えると、どんどん複雑になる。

モデリングが難しいのは、二つあると思う。
一つは、エンティティを洗い出すのが難しいこと。
例えば、概念モデルに現れたエンティティで漏れがない、という事を説明するのは難しい。

また、ビジネスルールを理解し切れていないと、エンティティを最初からすぐに導き出せない。
だから、羽生さんの本(楽々ERDレッスン (CodeZine BOOKS))では、最初はトランザクションに注目し、そこからエンティティを洗い出す手法を勧めている。
このやり方が最も自然なように思う。

更に、エンティティをクラスから型(Type)へ抽象化するのが難しい。
アナリシスパターン―再利用可能なオブジェクトモデルは、その構造を知識レベル・操作レベルと呼んでいるが、これを理解するのは至難の技。
児玉さんの本(UMLモデリングの本質)で僕はようやく理解できるようになった。

このやり方は、ビジネスモデリングで最も重要な手法の一つだと思う。
抽象化することによって、新たなビジネスパターンが得られるし、ビジネスで最も重要な概念が何か、が分かるからだ。
例えば、児玉さんの本(UMLモデリングの本質)では、会計システムにおける勘定パターンは物流システムの在庫パターンにも使える、と指摘している。

二つ目は、エンティティ同士の関連にどこまでビジネスルールを反映できているか、すぐに分かりづらいこと。
そこで、クラス図はあくまでも抽象的な図なので、実際に検証する時は、インスタンスの関係を書いたオブジェクト図を使えばよい。
児玉さん(UMLモデリングの本質)はクラス図の検証はオブジェクト図を使うことを推奨している。

また、児玉さん(UMLモデリングの本質)は「揺さぶり」という手法で概念モデルを洗練させる手法を提案している。
つまり、概念モデルに対し、ビジネスルールが反映されているかという観点で概念モデルを揺さぶってみる、ということ。
この辺りは児玉さんの本に詳しく、モデリングで最も面白い部分。

こう書いてきて、やっぱりOOAは児玉さんの本、DOAは渡辺さんの本が一番分かりやすいと思う。
平鍋さんは、渡辺さんの本(業務別データベース設計のためのデータモデリング入門など)を「日本人が書いたアナパタ」と呼んでいた。

オブジェクト納涼祭の感想: プログラマの思索

モデリングはプログラミングに比べると歴史も浅く、その手法も統一されてない。
モデリングの一番の弱点は、プログラミングと異なり、モデルだけではシステムが動かないこと。
だから、モデルの検証作業が難しい点が弱点であるように思う。

モデリング主義者が一番やりたいのは、モデル駆動開発(MDA)。
モデルを書いたら、そのモデルから動くプログラムを自動生成する手法。
でも、MDAは未だ完成していないし、そもそも本当にMDAが実現できるのか、誰も知らない。

ビジネスもSW開発プロセスも鈍重になっていく

最近のビジネス、SW開発プロセスで思うこと。
以前に比べて、どんどん鈍重になっている。

10年位前のSW開発の場合、「納期までに要求を満たすシステムを納品する」のが条件だった。
しかし、最近は更に、「納期までに要求を満たすシステムを納品し、開発プロセスが正しくマネジメントされている」ことを求められるようになった。
だから無駄なドキュメントが増えて、無駄なドキュメントを作る工数も増えてしまい、アジャイル開発しているのにその正当性を説明するのに手間がかかるようになった。

それはビジネスでも同じ。
最近よく言われるのは、コンプライアンス(法令順守)やJ-SOX対応。
確かにコンプライアンスは大事だけれども、本来の業務以外の間接業務の負荷が大きくなり、無駄なコストが増えている。
会社にシステムを導入する場合も、本来の業務を支援するシステムだけでなく、社員の労働状況やコンプライアンス状況を管理するためのシステム導入が増えている。

大前研一や木村剛は、このような最近のビジネス状況を官製不況と呼んでいたように思う。
こういう状況で最も得をする人たちは、取り締まる役割のお役所、総務人事部、あるいはSEPGやPMOなのかもしれない。

最近の企業を取り巻く情勢は、ビジネスのスピードを落とす方向に力を入れている。
SW開発も同様に、開発プロセスの正当性を説明するために、スピードを落とす方向に力を入れている。
正直、アジャイル開発への逆風が強まっている時期なのかもしれない。

要求開発はBABOKに対抗できるか？

先月、要求開発のセミナーを聞いて思った事をメモ。

【元ネタ】
Requirement Development Alliance : 要求開発アライアンス

ＮＤＳ要求開発|社長対談|「学ぶべき道・進むべき道」

ＮＤＳ要求開発|公開ワークショップ

The future is better than the past: 次はBABOK（ビジネス分析知識体系）？

PMBOKの次は「BABOK」が来る？ - 記者の眼：ITpro

要求開発はBABOKも、プロジェクトの立上げ、要件定義以前のRFP作成のプロセスを対象にしているようだ。
つまり、ステークホルダーのビジネス要件、又はシステム開発の要件へ落とす作業をターゲットにしている。

これら2つに必要なスキルはビジネス分析、いわゆるビジネスモデリングだと思う。

BABOKは、ビジネス分析の知識体系を目指す。
要求開発は日本独自の分析技法を提示しているみたい。

要求開発の話を聞いた限りでは、面白そうだけれども、何から手を付けて、どんな技法を使えばいいのか、分からなかった。
要求開発を受け入れている会社の人が一言、BSC(バランス・スコア・カード)を使うといいですよ、と言っていたのを聞いて、そういうレベルでやっているのか、これは難しいな、と思った。

正直、技法も知識も曖昧なので、実践するのは難しそう。
「ＮＤＳ要求開発|公開ワークショップ」のように、もっと実例が欲しいと思う。

でも、「ＮＤＳ要求開発|社長対談|「学ぶべき道・進むべき道」」を読むと、受託システム開発専門のSIerが現状に危機感を持っている理由がよく分かる。
単なる技術屋だけではなく、ITコンサルも兼ねたSIを目指したい、そうしなければ今後のITビジネスに未来がない、という思いは非常に分かる。
特に、クラウドの概念が現実になっている昨今、もはやシステムはスクラッチで開発するのではなく、システムのレンタル販売に移る傾向が大きくなるだろう。

色々探ってみたい。

Webシステム開発のトレンド

2002年頃、Strutsが出た時は興奮した。
それまでフリーでオープンソースのWebフレームワークは無かったから。

同じ頃、Eclipseが出てきた。
Javaの統合開発環境がフリーで、しかもプラグインを追加すれば、UMLやメトリクス出力、JUnitなど色んな機能を追加できる。
Eclipseでサーバー上のモジュールをリモートデバッグできた時は感動した。

Strutsが出る以前は、ベンダ製のWebフレームワークを覚えさせられて、正直嫌だった。
フレームワークのAPIを覚えても、他社プロジェクトで使えない。
フレームワークにバグがあっても、ソースが公開されてないので直せない。
結局、バッドノウハウが増えて、変なパッチが当てられて、どんどんソースが汚くなる。
そして、運用保守になると、誰もソースを触れなくなる。

日本のパッケージベンダーが駄目な理由: プログラマの思索
SIerの俺様フレームワークは最悪に激しく同意: プログラマの思索

Eclipseが出る前は、ベンダ製の統合開発環境を高値で購入せざるを得ず、誰もが気軽にプログラミングできる環境がなかった。
特にVisualStudioに慣れていると、ベンダ製のJavaの統合開発環境はUIも機能も洗練されておらず、開発効率も悪かった。

Tomcat＋Struts＋Eclipseがあれば、Webアプリをフリーな環境でフリーなフレームワークを使って開発できた。
デザインパターン、オブジェクト指向プログラミング、リファクタリング、JUnitによるテスト駆動開発を実際に試す事ができて、結構面白い時期だった。

それから、Railsが出てきた時も衝撃的だった。
わずか10分でインストール＋ログイン画面が作れるムービーが流れていて、Javaでガリガリ書いていた環境から見れば革新的だった。
同じ頃にSeasarも出てきて、JavaのWebアプリ開発の敷居も相当下がった。

そして、クラウドが出てきた。
ASPの看板を入れ替えただけと思っていたが、AmazonEC2やGoogleAppEngineに触れて、その思想は理解できてないけれど、革命的である事は直感した。

クラウドでも特にSaaSを実現できれば、もはやWebシステムは自作して運用せずにレンタルすればいい。

サーバーと言うハードウェアの納品とその運用で収益を上げて、Webシステムはその付属品という従来のWebシステムの受託開発ビジネスは、昨今の不況もあいまって、クラウドの出現によって収益率が急激に落ちている。

クラウドは非RDBを必要とする: プログラマの思索
クラウド時代のビジネスモデル: プログラマの思索

Webシステム開発ビジネスは今後どこに行くべきか？
フレームワーク、クラウド等で発展したWeb技術は、どこにイノベーションがあるのか？

今時の小学生はインターネットは当たり前らしい

下記の記事をメモ。

【元ネタ】
小学生のインターネット利用、6年生で約9割--gooリサーチ調査:ニュース - CNET Japan

Rubyを最大63％高速化した中学生は超多忙！ － ＠IT自分戦略研究所

Rubyを高速化した中学生は、小学1年生からコンピュータに触れていると言う。
コンピュータは大学に入ってから、というIT技術者の発想では、ありえないだろう。

今の労働者世代の経験と、今のキッズはおそらく全く違う。

我々の感性ではもはや、Webの新しい発想は出ないのではないか？
彼らの感性が今後のWebビジネスのあり方を変えるのではないか？

アドレナリンジャンキー

デマルコの新著「アドレナリンジャンキー プロジェクトの現在と未来を映す86パターン」が面白いのでメモ。

【元ネタ】
ビジネス書の杜: プロジェクトマネジメントのグル「トム・デマルコ」の集大成

デマルコはソフトウェアのプロジェクト管理に関して、優れた思索を本にしている。
思い出してみれば、「ゆとりの法則 － 誰も書かなかったプロジェクト管理の誤解」も「熊とワルツを - リスクを愉しむプロジェクト管理」も「ピープルウエア 第2版 － ヤル気こそプロジェクト成功の鍵」も彼が書いている。

もう一度読み直してみたい。

Redmineの集計プラグイン、statSVN諸々

Redmineの集計プラグイン、statSVNの機能についてメモ。

【元ネタ】
redmine_chartsプラグインでバーンダウンチャートは表示可能: プログラマの思索

Redmine - PluginCharts - Redmine

Redmineのプラグイン (3) ゴンペルたん: これ本番ですか？

redmine_chartsプラグインもゴンペルたんも、migrationが必要なく解凍して配置するだけ。
redmine_chartsプラグインは、予定・実績工数の右肩上がりのグラフを表示する。
つまりバーンダウンチャートの反対のグラフ。

このグラフが良い点は、PMBOKの言うSV(スケジュール差異)を目の前で表示してくれること。
これによって、コストさえ決まれば、PMBOKの言うEVMが可能になる。

また、ゴンペルたんはチケット集計の推移グラフ。
期間中のチケットの登録数・解決数などを表示してくれるので、Redmineの活動ログと合わせて見れば、開発チームの活発具合を見ることができる。

【statSVN】
StatSVN - jUCMNav Cloud Commit

statSVNにはcloud commitという機能があり、この機能は、SVNコミットログにある単語の出現頻度を出力する。
これは、SWリポジトリマイニングと同様の機能だ。
即ち、コミットログから、ソース修正の解決具合や関連情報を解析して、ナレッジを導き出す。

具体例を見ると、当然「refs」「fixes」が多いが、「fixes」が本当に解決されているのか、を調べることもできるだろう。

BTSやSCMは、SW工学の宝庫なのだ。

要件管理が必要な理由

要件管理が必要な理由についてメモ書き。
＃後でまとめる。

要件管理の機能で最も重要と思われる成果物は、要件と機能のトレーサビリティマトリクス(TM)だ。
イメージは、下記の記事の図3 トレーサビリティマトリクス（追跡可能性マトリクス）に相当する。

＠IT：みんなが悩む要求管理（8）要求管理ツールの賢い使い方

イメージとしては、上位要件を行、下位要件を列にしたマトリクスを作り、上位要件に紐づく下位要件がある場合、そのセルに印を付ける。
このマトリクスがトレーサビリティマトリクス(TM：追跡可能マトリクス)であり、このTMがあれば、要件に変更が生じた場合、下位要件、更にはそれに紐づくテストケースの影響範囲が一目瞭然になる。
上記の図にある「サスペクトリンク」は、そういう機能だ。

実際の開発では、要求仕様と基本仕様、基本仕様と機能仕様のように、隣り合う要件ドキュメント(フェースタイプテーブTblのフェーズ)でトレーサビリティマトリクスを作ればいいだろう。

清水吉男さんが提唱する派生開発プロセスXDDPでは、トレーサビリティマトリクス(TM)が成果物の一つであり、TMで変更要求と機能が交差した箇所で修正が必要な場合、変更設計書が作られる。
ここで、変更設計書は、実際のソースの修正手順まで含んだドキュメント。

XDDPでは、TMによって変更箇所を洗い出し、更に変更手順まで設計プロセスで作成するというプロセスを含んでいるのが秀逸。
つまり、派生開発という仕様変更を要件から開発・テストまできちんと追跡するプロセスがあるのだ。

要件管理では、要件漏れ・テスト漏れがないかという要件カバレッジ、つまりMECEの観点が一番大事だ。
要件カバレッジがあるからこそ、要件からソースコードやテストケースまでのトレーサビリティが実現される。
逆に、バグが発生した場合、バグの影響範囲を要件カバレッジによって即座に見極められるので、ブロッキングバグの修正・検証工数も最終的には計算できる。

つまり、両方向のトレーサビリティツリー機能によって、ブロッキングバグに影響する要件、更にはそれに紐づくテストケースや機能が分かり、最終的には、ブロッキングバグの修正・検証工数も計算でるはず。
この手法はブロッキングバグの影響調査だけでなく、仕様変更による影響調査にも使えるので、精度の高い変更管理が可能になる。

即ち、要件管理を仕様変更に伴う影響調査として使い、設計工程の品質Upやリスク管理に応用したいのだ。

そして、その機能は、手作業ではなく、ツールでサポートすべきであると思う。
何故なら、要件が数百、テストケースが数千もある場合、もはや手作業でカバーできないからだ。
これが、TestLinkの要件管理機能は現在は不十分でも、すごく潜在性を感じる理由でもある。

クラウドは非RDBを必要とする

最近流行するクラウドは、非RDBであるkey-valueストアを必要としている。
その理由を完全に理解できてないけれど、ネット上にある記事をメモしておく。

【元ネタ】
Web 時代の非リレーショナルデータベース: 第 3 回 Apache CouchDB で MapReduce フレームワークに基づく問いあわせを行う

「NoSQL」は「Not Only SQL」である、と定着するか？ － Publickey

クラウドが流行する背景には、Webサーバーのスケールアップは容易だが、RDBのスケールアップが難しいことがあるからだろう。
そして、ApacheのCouchDB(Erlangで作られている)、GoogleのBigTable等のkey-value storeをスケールアップしやすい理由は、MapReduceによる並行処理で高速化できるからだからだろう。

しかし、クラウドが分かりにくいのは、データストアをRDBではなく昔の汎用機の頃に戻しているからではないだろうか？
RDBに慣れているとkey-value storeを持つシステムは実装しにくく、正直分かりづらい。

色々探ってみたい。

ツールがサポートすれば考え方も変わる

日経コンピュータ(2009/11/11発売)の特集記事「幸せを呼ぶアジャイル開発　30年前の改善魂を取り戻せ」に、チケット駆動開発の内容が現場の事例の一つとして掲載されている。

その記事の中にある一文に惹かれた。

ツールがサポートすれば、メンバーの働き方が変わっていく。
行動が変われば考え方も変わっていく。

似たような言葉として、松井秀樹が恩師から言われた言葉がある。

心が変われば行動が変わる。
行動が変われば習慣が変わる。
習慣が変われば人格が変わる。
人格が変われば運命が変わる。

何か似ていると思いませんか？

後者の言葉はトップダウン。
心が変われば人生を変えられる。

前者の言葉はボトムアップ。
ツールで行動を変えれば、考え方が変わる。

ツールでプロセス改善する発想も、前者と同じ。
ツールでSW開発のあり方、考え方も変えるのだ。

NoSQL～RDBからkey-value storeへ

NoSQLという単語が最近流行しているらしい。

【元ネタ】
masuidrive on rails - NoSQL – SQLはもう古い?

NOSQL(Not Only SQL)ムーブメント - おおたに6号機blog

NoSQL - Wikipedia, the free encyclopedia

言わんとすることは、RDBからkey-value storeへの流れ。

普通のWebシステムならば、RDBで十分使える。
しかし、ユーザ数やトラフィックがとてつもなく膨大な場合、データベースのパフォーマンスに問題が出てくる。
Webサーバーのスケールアップは、サーバーの増設で対処できるが、RDBのスケールアップが難しいのだ。

ApacheのCouchDB(Erlangで作られている)、GoogleのBigTable等のkey-value storeはいずれも、データストアをいかにスケールアップしやすくするか、と言う観点で作られていると考えれば、その方向性も理解しやすくなるだろう。

【案内】PFP関西ワークショップ#20-AgileNight2009

2009/11/23に、PFP関西ワークショップ#20-AgileNight2009が開催されます。
CMをどうぞ。

※ブラウザのJavaScriptをONにして、Flash Player9以上をインストールしてください。

ソフトウェア開発チームはオーケストラに似ている

ソフトウェア開発の特徴で良い記事があったのでメモ。

【元ネタ1】
ソフトウェア開発組織はオーケストラ：柴田 芳樹 (Yoshiki Shibata)：So-net blog
ソフトウェア開発で伸びる人，伸びない人【第二版】：柴田 芳樹 (Yoshiki Shibata)：So-net blog

荒井さんの本「ソフトウェア開発で伸びる人、伸びない人 【第二版】 (技評SE選書)」が紹介されていたので立ち読みしてみた。
「特別付録　音楽とソフトウェア開発」という章が面白かった。

ソフトウェア開発組織はスポーツではなくオーケストラ。
個人のスキルは前提条件であり、協調するのが大事。
一人のスキルが低いと、演奏する音楽全体の品質が落ちる。

オーケストラでは、指揮者(プロジェクトマネージャ)以外に、副指揮者(プロジェクトリーダー)、コンサートマスター(アーキテクト)の役割が必須。
管理者の仕事が3人に分かれているのに注意。
SW開発の大規模プロジェクト(数十人以上)も同様に、管理者の役割が分化されるはず。
アジャイル開発のような小規模チームでは、管理者が役割を兼務する時が多い。

バッハやモーツァルトもその時代の音楽楽器の技術をフルに使うことで、優れた楽曲を残した。
IT技術も、その時代に合った技術をフルに使えば、ベターなシステムが作れるはず。
しかし、IT技術は陳腐化が激しいので、システムの寿命も本来は短いのかもしれない。

【元ネタ2】
「ソフトウェアは工業製品ではない」　まつもとゆきひろ氏：柴田 芳樹 (Yoshiki Shibata)：So-net blog
ソフトウェアエンジニア：柴田 芳樹 (Yoshiki Shibata)：So-net blog

日本のITベンダーのプロセス改善に何故、違和感を感じるのか？
彼らのプロセス改善の根底には、アートを作るのではなく、工業製品を作っているイメージがある。
ソフトウェア開発のプロセスが細分化されて、プログラミングではなくコーダになっている。

【元ネタ3】
ソフトウェアエンジニアの成長カーブ：柴田 芳樹 (Yoshiki Shibata)：So-net blog
開発チーム（組織）の成長：柴田 芳樹 (Yoshiki Shibata)：So-net blog

ソフトウェア開発において、成長できない組織や個人は、プロセス改善できない。
ソフトウェア開発においてプロセス改善するには、プログラミング技術が時代に乗り遅れないように、常に磨かなくてはいけない。

Redmineをホストごとに作る

Redmineをホストごとに作るためのシェルスクリプトが公開されていたのでメモ。

【元ネタ】
10分でredemineのホスティングサービスを作る | 半袖野郎 blog.hansode.org

社内の一つの部でRedmineを使う場合、問合せ管理だけなら一つのRedmineでよい。
Redmineの複数プロジェクト機能を目的ごとに使い分ければ更に管理しやすくなる。

しかし、開発と運用保守を兼ねる小プロジェクトが多いならば、ホストごとに作った方が管理しやすいだろう。

Redmineのチケット集計機能を強化するプラグイン

Redmineのチケット集計機能で良いプラグインがあったのでメモ。
いずれもマイグレーションが不要で、Redmine0.8.4で動作したから、ver0.8.xで大丈夫だと思う。

【元ネタ1】
Redmineプラグイン開発 - 大豆プラグインがとりあえずできた - フジハラボ -- 目指せ！スーパーエンジニア

このプラグインは、期間を指定後、下記を集計出力する。

1-1・担当者指定でチケット一覧を表示
1-2・トラッカーの時間コスト(実績工数)を出して、円グラフなどでグラフ化する
1-3・バグの種類を分析して、円グラフなどで表示する(チケットに「原因」というカスタムフィールドを追加し、バグという名前のトラッカーだけ入力)

1-2の機能は、実績工数の分布を集計してくれる。
この機能によって、テストやバグ修正に時間が取られているか、開発や設計などの上流工程で時間を取られているか、分析できるから、リスク分析に使える。

また、1-3の機能は、リリース後の障害分析で重要な機能だ。
この機能によって、バグの原因がリリース作業の不注意から生じたのか、コーディングミスなのか、設計漏れなのか、分析できるから、プロセス改善の資料の元ネタになる。

リリース後のふりかえりMTで各種の集計レポートがあれば、開発者の意識も変化させる事ができ、その後のチームの成長に役立つだろう。

【元ネタ2】
Redmineプラグイン開発 - Roadmapsプラグインリリース - フジハラボ -- 目指せ！スーパーエンジニア

このプラグインは、ロードマップの各バージョンの詳細情報(開始日・終了日・予定工数・実績工数)を一覧できるように改良している。

この機能は、Redmine標準のロードマップ機能を強化してくれる。
XPの計画ゲーム、あるいは、リリース計画やイテレーション計画は、ロードマップ画面で行うから、できるだけ機能強化されるべきだ。
RedmineがTracよりも優れている点の一つが、ロードマップ画面に各バージョンの情報を一目で一覧できることだと思う。
Tracのロードマップ画面は終了チケットの割合しか表示しないので、実際のプロジェクトの進捗情報を読み取りにくい。

Redmineのデフォルトのチケット集計機能はサマリと工数レポートだけしかないし、ロードマップ機能も進捗とチケット一覧しかないが、プラグインで機能強化すれば、リスクを早めに嗅ぎ取り、問題が起きる前に対策を早期に実施できるはず。
他のプラグインも試してみたい。

チケット駆動開発にPMBOKの概念を導入してみる

チケット駆動開発にPMBOKの概念を導入してみるアイデアをメモ。
＃あくまでもラフなメモ書き。

【元ネタ】
redmineの wikiマクロで graphviz その1 - あぁ そうだった

Graphviz - Wikipedia

簡単なサンプル

PMBOKツールと技法

結構ややこしいぞ！ アーンド・バリュー計算と分析－ ＠IT自分戦略研究所

Redmine - PluginBudget - Redmine

【1】PMBOKに限らず、進捗管理の基本はクリティカルパスをきちんとコントロールする点にある。
クリティカルパスを見るには、ガントチャートではなく、PERT図を描いて追跡しなくてはならない。
ガントチャートは、PERT図やクリティカルパスから導出される、顧客向けの進捗資料に過ぎない。

Redmineチケットの関連に「先行する」という機能がある。
これは、MSProjectでWBSを作る時のFS関係に相当する。
すると、この機能を上手に使って、Redmine上でPERT図、更にはクリティカルパスを表現できないか？

イメージはこんな感じだ。
まず、WBSの最小単位をチケットとし、FS関係をチケットの関連リンクの「先行する」機能で表現する。
チケットには、開始日・終了日・予定工数の属性が付与される。
つまり、PERT図で使われるマスタデータを全て、チケットとその関係で表現し、Excel上で作りこんでRedmineへ一括インポートする。

次に、Redmine上で、FS関係をGraphvizで表現して、PERT図へグラフ化する。
つまり、全チケットのFS関係を下記のようなGraphvizファイルへ変換し、GraphvizでPERT図へ自動変換する。

pert_diagram.dot

digraph pert_diagram {
ticket1 -> ticket2;
ticket1 -> ticket3;
ticket2 -> ticket4;
ticket3 -> ticket4;
}
↓
Graphvizで変換した図：pert_diagram.gif

クリティカルパスを計算するには、バックトラッキング機能を使えば、再帰的に計算できるはず(多分)。
Haskellならば、上記の関係を正しく表現できれば、クリティカルパスを自動計算できるだろう。

上記の生成したPERT図に、チケットへリンクする機能があれば、もっと良いだろう。

【2】PMBOKの優れた機能の一つに、EVMがある。
EVMで重要なのは、SV(スケジュール差異)とCV(コスト差異)だ。
プロジェクト期間中のある時点で進捗やコストを計算した時、スケジュールが遅れたり、コストがオーバーすると、SVやCVが負の値になる。
特に、ITプロジェクトに工事進行基準が導入される経緯を考えると、PVやSVを自動計算できる仕組みが欲しい。

Redmine上でEVMを表現できれば、進捗の遅延やコストの負荷をリアルタイムに追跡できるはず。

Redmineチケットで、CVやSVを表現するには、チケットの属性に「コスト」の情報が必要になる。
Redmine本家のプラグイン一覧にあるPluginBudget - Redmineが使えないだろうか？

つまり、チケットへコスト(金額)を入力できれば、予定工数・実績工数の差異から、SVだけでなく、CVも理論的には計算可能。

上記はあくまでも、Redmineでできたらいいな、というアイデア。
チケットという概念には、大きなポテンシャルがあると思う。

【再考】TiDDのプラクティス集

チケット駆動開発を運用する上で、あった方がよいと思う運用ノウハウをプラクティスとしてピックアップしてみる。
なお、下記には、他の人のアイデアも含まれているので、引用先をリンクしておく。

【元ネタ】
脱Excel！ Redmineでアジャイル開発を楽々管理 － ＠IT自分戦略研究所

チケット駆動開発のベストプラクティスを収集したい: プログラマの思索

チケット駆動開発のFAQ: プログラマの思索

チケット駆動開発 - Live a meaningful Life

チケット駆動開発とTestLinkによる開発プロセスの改善 (Shibuya.trac #4.5) - まちゅダイアリー(2009-09-11)

2009-09-17 gitだからこそできるチケット駆動開発のやり方- kunitの日記

チケット単位に並行開発する事例: プログラマの思索

[tech]チケット駆動開発 - Kazumi007の日記

１・チケット・ファースト(Ticket First)

プロジェクトの作業はチケットを受け取ってから始める。
作業が発生したら、まずチケットに起票してから始める。
このルールが徹底されて初めて、チケット駆動開発が始まる。

そして、チケットはXPのタスクカード(作業指示書)として扱う。
すると、チケットに作業履歴が残り、運用保守で検索しやすくなる。
進捗情報は全てチケットに書くから、BTSのチケット集計機能でリアルタイムに進捗情報を出力できる。

チケットを成果物の単位で作ると、作業しやすくなる。
例えば、「設計書を作る」「機能Aを作る」「バグを直す」「テスト仕様書を作る」など。
つまり、チケットはWBSから作り出すこともできる。
この手法はPMBOKにも流用可能のはず。

２・チケットはシンプルに

チケットの入力項目やワークフローは必要最低限にし、シンプルにしておく。
チケットに必須項目や入力項目が多いと、開発者がチケットの更新に億劫になり、チケットに最新の状態が反映されなくなってしまう。
特にワークフローが複雑な場合、メンバーが慣れるのに時間がかかり、TiDDの威力が半減する。

リリース後のKPTによるふりかえりMTが、チケットの運用を見直すタイミングになる。
リリースをこなしながらチケットを改善していけばいい。

３・分割統治(Divide and Conquer)

プログラミングと同様に、タスクは分割して統治する発想が大事。
複雑なタスクはWBSでツリー構造に階層化したり、分割する。
この時、分割統治の観点として、チケット・イテレーション・プロジェクトの3つがあると考える。

3-1.チケットで分割統治

僕の経験では「一つの成果物を一人の担当者が１～５人日以内で完成させる作業」まで細分化するのが良いと思う。

実際は、リリース後にチケットを集計してみると、チケット1個の工数は1人日以下になっている時が多いと思う。
理由は、新規開発後のテストでバグ修正や、顧客からの問合せ(障害修正・改善要望)など、開発チームが予想していたタスクの規模を超える時が多いから。
タスクが増えすぎた場合は、小規模リリースやチケットの関連付け、他の分割統治のプラクティスで対応する。

又、遅延したチケットは作業しやすいように分割した方がいい。
例えば、機能追加のタスクなのにリファクタリングに時間がかかっているチケットは、リファクタリングと機能追加のタスクに分ける。
開発者が作業しやすいように、コミュニケーションを取りながら、臨機応変に行えばいい。

他に、GitやMercurialのような分散バージョン管理を使っているならば、2009-09-17 gitだからこそできるチケット駆動開発のやり方- kunitの日記のように、チケット単位でトピックブランチを作る運用方法もあるだろう。

3-2.イテレーションで分割統治

細分化されたチケットは、リリース計画やイテレーション計画に基づいて、各イテレーションにアサインされる。
チケット駆動開発やRedmineでは、イテレーションをリリースバージョンと同一視するため、小規模リリースを実現でき、自然にアジャイル開発になる。
チケットをどのバージョンでリリースするか、という取捨選択や、イテレーション内部でのチケットの優先順位付けがプロジェクトマネジメントそのものになる。

アジャイル開発と同様に、チケット駆動開発でも、イテレーションを上手に使うのが重要だ。
僕がよく使う手法として、バージョンと対応されない特別なイテレーションとして、「バックログ」や「内部課題」を作っている。

「バックログ」は、顧客から寄せられた改善要望のチケットを貯めるイテレーション。
例えば、リリース直後に寄せられた膨大な改善要望は、バックログに溜め込んで保留とし、障害修正など、本番運用の安定に力を注ぐ。
そして、本番運用が落ち着いたら、バックログに溜まったチケットの難易度や優先度、予定工数などを洗い出し、リリース計画を立てて、チケットを各イテレーションへアサインしていく。

つまり、「バックログ」はScrumのプロダクトバックログのように、要望を一旦受け付けてフィルタリングし、リリース計画を立てる場とする。
即ち、XPの計画ゲームをバックログのイテレーションで行っているようなものだ。

又「内部課題」は開発者から寄せられたチケットのうち、優先順位が低い作業やいつやるか未定の作業を溜め込むイテレーション。
例えば、このソースはリファクタリングした方がいいが今手を付ける必要はない、とか、だいぶ先の予定作業などの備忘録。
そして、リファクタリングした方がいい機能を修正するタイミングで、進行中のイテレーションへチケットを移動して、リファクタリングも同時に行う。
あるいは、来るべき時が来たら、チケットをイテレーションへアサインしていく。

つまり、「内部課題」は開発チームのリスク管理を行うイテレーションだ。
「内部課題」のイテレーションを備忘録として使い、作業漏れをなくす。
特に、リファクタリングが必要な箇所はファウラーが言う技術的負債そのものだから、工数見積もりのリスクに直結する。
故に、システムのリスクに直結する情報は積極的にチケットへ登録する雰囲気作りが重要だと思う。

「バックログ」も「内部課題」も終了期限の無い特別なイテレーションとして扱うのに注意。

3-3.プロジェクトで分割統治

プロジェクト単位でチケット管理する状況は、顧客からの問合せと開発のタスクを分けたい時が多いだろう。
つまり、インシデント管理と実際の開発は、BTSの複数プロジェクト機能を使って、プロジェクト単位で管理する。
この方法によって、開発チームは、開発と無関係なインシデントのチケットを意識することなく作業すればいい。

他の例としては、大規模プロジェクトで、サブチームごとにタスク管理したい場合や、サブシステムやコンポーネント(jar, dllなど)の単位でタスク管理したい場合があげられるだろう。

４・No Commit, No Ticket

TiDD提唱者のまちゅさんが「チケット無しの成果物のコミットは不可」というルールをこのプラクティスで呼んでいたので、引用させてもらった。
チケットファーストのルールに従うと、必ずコミットする時にチケットNoは存在する。
つまり、修正意図の不明なコミットを排除する意味が込められている。

このルールのおかげで、運用保守時にリバースエンジニアリングしやすくなる利点がある。

５・チケットは常時最新に

八朔さんがTiDDで最も重要だと述べたプラクティス。
チケットに登録したとしても、進捗や情報が更新されないと、BTS上で最新の進捗情報を確認できなくなる。
特に、リリース直後に問合せや障害が大量に発生して、チケットが乱発されたり、放置されたりする時に起きやすい。

だから、チケット管理の責任者が常にチケットの状況を見ておく必要がある。普通はプロジェクトリーダーがその役割を担っているだろう。
大規模プロジェクトでは、専門のチケット管理者を配置して、進捗確認させるといいだろう。
また、チケット更新やSVNコミットのタイミングで関係者へメール送信する機能を使えば、気付きやすくなる。

他に、RedmineやTracでは、活動欄でSVNリポジトリ・チケット更新・Wiki更新などの履歴が表示されるので、最新情報を見る事ができる。
故に、活動ログの活発具合が開発チームの活発度に直結するので、注意した方がいい。

６・チケットは関連付ける

八朔さんの運用方法では、チケットは、要件-成果物-作業のツリー構造で関連付けられる。
このやり方ならば、チケットをタスクカードだけでなく、ストーリーカードとして扱う事もできる。

あるいは、複雑な機能を実装するチケットを分割した場合、関連するチケットをまとめるために、Redmineの関連リンク機能を使えばいいだろう。

僕がよく使う方法は、マージ作業が発生した場合、マージ作業のチケットに発生元のチケットを関連リンクさせておく。
これによって、マージ作業の意図を関連元のチケットから理解しやすくなる利点がある。

７・小規模リリース(Small Releases)

チケット駆動開発では、リリースバージョンをXPのイテレーション、Scrumのスプリントと同一視してアジャイルに開発していく。

RedmineやMantisでは、ロードマップ画面がイテレーション計画を行う機能になる。
そして、リリースされたイテレーションに紐づくチケットは、変更履歴画面でChangeLogとして残る。
この2つの機能おかげで、BTS上でリアルタイムに進捗情報や、リリース履歴を簡単に確認できる。

８・朝会

チケット駆動開発を実践すると、自然に朝会をするようになった。
朝会でロードマップ画面を見ながら、誰がどのチケットを担当していて、進捗が遅れているなら何が問題なのか、を議論する場になる。

朝会は、コミュニケーションが始まる場であり、リスク管理を行う場でもある。

９・ペア作業

Redmineの柔軟なワークフロー機能を使っていると、チケットは必ず2人の手を経て終了するようになった。
例えば、チケットを終了できる権限はプロジェクトリーダーのみとし、彼が承認したら終了できる。
あるいは、バグ修正のチケットは、開発者とテスターが交互にステータスを更新しながら検証していく。

XPのペアプロと異なるが、1枚のチケットを2人以上の手が加えられているので、ペア作業と呼んでいる。
ペア作業の利点は、自然な品質チェックと、自然なペアプロ。

１０・ふりかえり(Retrospect)

チケット駆動開発を実践して、イテレーションをリリース後、自然にふりかえりMTを行うようになった。
KPTで行ってみると、開発者も管理者も色んな思いが出てくる。
バグが多かった、無事に終わったけれどこうすればもっと良かった、このプロセスがやりにくかった、など。
チケット集計結果を見ながらKPTすると、チケットやワークフローの運用改善のアイデアが出てきて効果的。

他にも色々あると思うので、収集してみたい。

アジャイル開発と品質管理の関係

「アジャイル開発はMTTRを重視している」指摘を受けたのでメモ。

【元ネタ】
MSDN：可用性の概要

平均故障間隔 - Wikipedia

平均修復時間 - Wikipedia

ソフトウェアやハードウェアの信頼性や可用性に関する用語として、MTBF・MTBR・稼働率などがある。

MTBF＝稼働時間/稼動回数
MTBR＝修理時間/故障回数

稼働率＝MTBF/MTBF+MTBR
故障率＝1/MTBF

MTTRは可用性、MTBFは信頼性・障害密度に密接に関係するのは周知の通り。

MTBFが大きいほど信頼性は高いが、ソフトウェアのMTBFは格段に小さいように思う。
SRATS:Software Reliability Assessment Tool on Spreadsheet Softwareのサンプルでも、MTBFはわずか16時間に過ぎない。
つまり、16時間後には必ず障害(バグ)が出る。

しかし、MTTRが「0」に近ければ、信頼性が低くても稼働率は100％に近くなる。
つまり、バグ修正工数が少ないほど、ユーザ側から見るとシステムはずっと稼動しているように見える。

アジャイル開発で、「開発の一番重要なファクターは時間である。平均バグ修正時間をみれば品質がわかる」という話を聞いた。
つまり、アジャイル開発ではMTTRを重視している、と。
確かにそうだろうと思う。

リファクタリング、テスト自動化、継続的インテグレーション等のプラクティスは、保守性を高めてソースを修正しやすくすることにつながる。
つまり、バグ修正工数と言うMTTRを短くすることにも注力していると言っていい。

Googleでも、サーバーは故障するものであり冗長化することに力点を置いているという話もある。
極論な話だが、HDDが1時間に1回壊れたとしても、予備のHDDにすぐに取替えできるならば、問題ないという考え。
つまり、MTBFが小さくてもMTTRがほぼ0ならば、実際のシステムの利便性は問題ない。

システム開発でもそうだ。
度重なる機能改善やバグ修正があったとしても、修正工数を小さくできる余裕があるならば、自信を持ってプログラミングできる。
つまり、保守性が高く、可読性の高いシステムならば、どんどん機能改善できる余裕が出てくる。
すなわち、アジャイル開発と相性がいい。

プログラミングの保守性を高くする為のノウハウがGoFのデザインパターンでもある。
マネジメントのノウハウとしては、イテレーションという単位にシステム開発を分割して、スコープを制御する事によって、システムの安全性と継続性を重視する選択肢も取れる。

アジャイル開発と品質管理の関係についても色々考えてみたい。

TiDDにITILの概念を持ち込む

チケット駆動開発にITILの概念を持ち込めるか、考えた事をメモ。

【元ネタ】
サービスサポート - Wikipedia

ITILのプロセス関連図: プログラマの思索

ソフトウェア保守 - Wikipedia

XDDPの資料リンク: プログラマの思索

初心者歓迎！　ITIL連載講座：ITILの成り立ちと現状を知る (1/2) - ITmedia エンタープライズ

【1】ITILはIT運用プロセスのフレームワーク。
PMBOKと並んで、管理者がマスターすべきマネジメントツールだろう。

Itilプロセスフロー from akipii Oga

昨今のITの問題として、運用保守の作業負荷が増大している点が一番にある。
流行の早いWebシステムであろうとも、数年前に作ったシステムのアーキテクチャが時代に合わずに古くなっても運用せざるを得ない。
稼働中の古いシステムで、ユーザ企業は実際の業務をこなし、売上を上げているからだ。

そんな状況で、保守という名前でどんどん機能追加してシステムが不安定になったり、スケールアップが難しくなり、マンパワーでカバーするなどの問題点が噴出する現場が多くなっているだろう。

上記の問題に対し、ITILの利点は、運用保守や派生開発に応用可能で効果的な点だと思う。

運用保守の観点では、問題管理とインシデント管理を区別している点が重要だ。
つまり、障害の調査と根本対策を立てる問題管理と、ユーザから障害だけでなく改善要望や単なる使い方の質問までをサービスデスクで管理するインシデント管理はきちんと区別する。

例えば、「Webにログインするパスワードを忘れた」というユーザの質問に対しては「パスワードリマインダーを使って下さい」と回答すればいい。
この質問は障害ではなく、マニュアルを見れば、サポートデスクの女性がすぐに対応できる。

インシデント管理がしっかりすれば、開発部隊やサーバー保守部隊は、引っ切り無しにかかってくるユーザの電話から解放される。
インシデント管理で対応できなかったインシデントに対してだけ、エスカレーションして問題管理で対応すればいい。

派生開発の観点では、変更管理とリリース管理を区別している点が重要だ。
清水吉男さんが提唱する派生開発のプロセスXDDPでは、是正保守と改良保守(適応保守)を明確に区別する。
つまり、いわゆるバグ修正である是正保守と、ソフトウェア訂正ではないまったく新しい機能追加である改良保守は、開発プロセスがそもそも違うのだ。
例えば、携帯電話にカメラやお財布ケータイの機能を追加していくのは、どう考えても障害修正ではないのだ。
しかし、この例のような派生開発をきちんとした開発プロセスで行っている現場は少ない。

ITILでは、変更管理でRFC(変更要求書)を作り、RFCをCAB(変更諮問委員会)が精査して、設計・開発・リリースの計画をまず立てる。
そして、変更管理で作られた計画に従って、リリース管理のプロセスで実装してリリースしていく。

清水吉男さんが提唱する派生開発プロセスXDDPは、この変更管理のプロセスや成果物がしっかりしているので、特に組込み製品の企業がよく使っているのだろうと思う。

【2】改めて、ITILのプロセス群(特にサービスサポート)の目的をサービスサポート - Wikipediaから引用する。

１・インシデント管理･･･迅速なサービスの復旧を行い、企業が行う事業活動への影響を最小限に抑える
２・問題管理･･･インシデントや障害原因の追究と対策および再発防止策の策定を行う
３・構成管理･･･ITサービスの構成アイテム（CI）情報の精確な収集、認識と収集した情報の維持管理および確認・監査を行う
４・変更管理･･･CI情報の変更を安全確実かつ効率的に実施する
５・リリース管理･･･変更管理プロセスで承認された内容を本番環境（ITサービス提供媒体）に正しく反映させる為の作業（リリース作業）をコントロールする
６・サービスデスク･･･ITサービスを提供する組織とITサービスを利用する顧客の窓口的役割を担い、インシデント対応などのサポート業務を行う

チケット駆動開発のインフラであるBTSやSCMは、問題管理や構成管理を本来サポートしている。

ITILのプロセスをチケット駆動開発にのせられれば、BTSを問題管理以外のプロセスにも応用できる。
つまり、システムテストの障害管理だけでなく、日々の運用保守や新規開発、リリース作業の管理にもチケット駆動開発を応用できるだろう。

例えば、インシデント管理で、ユーザからの日々の問合せを、障害や改善要望などのカテゴリでフィルタリングし、システムを修正する必要のある要求はScrumのプロダクトバックログに詰め込む。
実際は、バグ修正のタスクと区別したいので、インシデント用のプロジェクトとワークフローを作って管理すればいいろう。
即ち、Redmineの複数プロジェクト機能、柔軟なワークフロー管理機能が必要になる。

例えば、変更管理では、変更要求をRFCとしてまとめて、CABは開発部隊だけでなくサーバー保守部隊やユーザの情報システム部門から構成して、RFCの精査やリリース時期の判断を下す。
そして、リリース管理では、RFCに従って、開発者がソース修正し、テスターが検証し、ライブラリアンがリリース作業を行う。

実際は、RFCにある要求をストーリーカード、RFCに基づく作業をタスクカードできちんと管理すればいいだろう。
そして、開発者・テスター・ライブラリアンの作業はチケットの属性によって使い分ければいい。
即ち、チケットの親子関係・柔軟な属性カスタマイズの機能が必要になる。
RedmineやTracにあるガントチャート・カレンダー・工数集計・バーンダウンチャートなどの多様なレポート機能があると、進捗管理が更にやりやすくなるだろう。

上記の思索を考えると、ITILのプロセスはチケット駆動開発と相性が良いと思う。
RedmineやTracをBTS(Bug Tracking System)だけでなく、ITS(Issue Tracking System)へ拡張する発想とITILがすごく相性がいいからだ。

同様に、PMBOKもチケット駆動開発に載せる事ができるか考えてみたい。
PMBOKはプロジェクト管理のフレームワークであり、その特徴は、リソース管理、コスト管理に優れている点にあると思う。
RedmineやTracの優れたレポート機能がPMBOKの概念の実装を補完してくれるはずだ。

redmine_chartsプラグインでバーンダウンチャートは表示可能

下記プラグインをインストールしてみたら、バーンダウンチャートの表示が可能だけでなく、機能が豊富でとても素晴らしかった。
以下メモ書き。

【redmine_charts】
Redmine - PluginCharts - Redmine

mszczytowski's redmine_charts at master - GitHub

pullmonkey's open_flash_chart at master - GitHub

ruby on railsでグラフを作成する。Open Flash Chart編←【2009/11/18 追記】

【インストール方法】
$redmine/vendor/plugins へredmine_charts、open_flash_chartのフォルダを解凍して配置する
※open_flash_chartフォルダがないと、redmine_chartsが動作しない。
↓
open_flash_chartプラグインに入っている/vendor/plugins/open_flash_chart/assets/swfobject.js ファイルを 　
RAILS_ROOT/public/javascriptsディレクトリにコピー　←【2009/11/18 追記】
↓
open_flash_chartプラグインに入っている/vendor/plugins/open_flash_chart/assets/open-flash-chart.swf ファイルをRAILS_ROOT/publicディレクトリにコピー　←【2009/11/18 追記】
↓
rake db:migrate_plugins RAILS_ENV=production
↓
ruby -Ku script/server -e production -d
で再起動
↓
プロジェクト設定画面で、「チャート」をチェックしたらOK

【redmine_chartsプラグイン感想】
redmine_chartsプラグインは日本語化されており、初期表示で下記の説明があるので、一目で機能が分かる。
但し、redmine_chartsプラグインをフルに使うには、チケットに開始日・終了日・予定工数・見積工数・作業分類がきちんと入力されているのが前提になるので注意。

１・バーンダウン
見積もり、経過および残りの時間を表しています
２・記録時間割合
時間はメンバ、チケット、活動、カテゴリごとに分類およびフィルタした記録時間の合計に比例しています
３・記録時間予定
メンバ、チケット、活動、カテゴリごとに分類およびフィルタして時間経過を表しています
４・記録時間分布
各チケットの見積時間と記録時間と残り時間の割合を表しています。この割合は100%以下になるべきです。見積時間のあるチケットのみ表示しています。左端に表示しているバーはこのプロジェクトの平均値を表しています。

redmine_chartsプラグインがあれば、Tracのレポート機能と同等か、それ以上の運用が可能になるだろう。
このプラグインもRedmine運用で必須のプラグインだろう。

【redmine_version_gantt_chart】
Downloads - version-gantt-chart - Project Hosting on Google Code

２つめブログ バージョンガントチャートPlugin 0.1 完成

【redmine_version_gantt_chartプラグインの概要】
(前略)
Redmineに登録したチケットとバージョンの情報から、
開発者ごとの作業負荷とタスクの進捗状況をざっくりと確認できるプラグインをつくってみました。
標準のガントチャート表示機能は綺麗に表示できるんだけど、開始日と期限日の入力と更新が面倒で使わなくなってしまった。
なので、できるだけ「少ない入力項目」で、「大雑把な進捗」を確認できるものを目標にしています。
(後略)

【redmine_version_gantt_chartプラグイン感想】
ガントチャートで開発者の負荷をざっくり見れるので、マネージャと言われる人達に最も受けそうなプラグイン。
プロジェクトの進捗をバーンダウンチャートだけでなく、ガントチャートなど色んな観点のメトリクスで出力できれば、リスクに対して早期に是正対策を採りやすくなる。

【Estimate timelogプラグイン】
r-labs - Estimate timelog - Redmine
Redmineで予定／実績レポートを表示するプラグイン【estimate_timelog】を作ってみた - へたれエンジニア日記 ver.2

工数集計画面で、予定工数と実績工数をユーザごとに集計表示してくれる。
予実比較はマネジメントの基本だから、とても貴重。

Redmineのレポート機能も、世界中の開発者のおかげでTracと同等か、それ以上まで機能改善されている。
短期間でRedmineが改善されている原因は、チケットという情報がDBで一元的に管理されていて、Railsという優れたフレームワークのおかげでプラグインで機能追加しやすいからだろうと思う。

それから注目すべきは、優れたRedmineプラグインの開発者に日本人がチラホラのっている事だ。
日本でもRedmineユーザが増えている証拠なのかもしれない。

Redmineのプラグインに関しては、今後も試したものについてはフィードバックしていきたい。

【公開】SQIP2009の論文資料

チケット駆動開発の情報を今後のリファレンスとして使いたいため、SQIP2009の論文資料を下記に公開する。
下記資料を引用する時は、必ず参考文献にリンク先を明示して下さい。

【SQIP2009】
日科技連 | ソフトウェア品質 | 第28回 ソフトウェア品質シンポジウム2009（SQiP(スキップ)シンポジウム）(2009/9/9-11)

「チケット駆動開発- BTSでExtreme Programmingを改善する-」(経験論文)

【注意】
チケット駆動開発は、まちゅさんの発表「チケット駆動開発 … ITpro Challenge のライトニングトーク (4)」が発端にある。

yet another TDD from Kohei MATSUOKA

これらの経験論文の元ネタは、TiDD：チケット駆動によるアジャイル開発法: ソフトウェアさかばの論文「TiDD：チケット駆動によるアジャイル開発法」(PDF)にある。
ソフトウェアさかば: チケット駆動開発も合わせて読むと、チケット駆動開発の全貌が分かるだろう。

パッチベースのワークフロー

オープンソースではパッチベースのワークフローがあるという記事をメモ。

【元ネタ】
gitster's journal - 入門Gitの目次はというと

入門Git - idesaku blog

2009-10-11 - 未来のいつか/hyoshiokの日記

gitster's journal - 入門Gitの目次はというとで、下記の文章が目を引いた。

第十章ではじめて、オープンソースの世界で多用されるパッチ・べースのワークフローを登場させた。
会社で仕事に使うだけ、というユーザには馴染みのないワークフローと考え方だと思うので、パッチ・べースのワークフローを使わない向きは飛ばして貰っても、本の他の部分を読むのには全く問題がない。
そのかわり、ボクがこれまでLinus君と一緒に仕事をしてきて学んだ、オープンソースコミュニティで生きてゆく際のコツ、といったものを「オープンな開発プロセス」という一節としてこの章に加えることにした。
ボクの経験が、少しでもオープンソースに関わる人たちに役に立ってくれると良いな、という考えからだ。

入門Gitは今予約中で読んでいないので、以下想像した事をメモする。
＃間違っていたら後で直す。

上記の言うパッチベースのワークフローは下記の意味だろう。
オープンソースコミュニティできちんと管理されているシステムのソースコードは、必ずコミッタが厳重に管理している。
ユーザが機能追加やバグ修正したソースを反映させたい時、パッチを作ってコミッタに送る。
コミッタはそのパッチをレビューして、フィードバックし、OKならコミットする。

このワークフローは実は、ReviewBoardやRietveldなどのコードレビューシステムと同じだ。
つまり、パッチベースのワークフローの目的は、コードレビューによる品質チェック、開発者同士の暗黙知の共有を指すと思われる。

普通のSIでは、上記のようなワークフローを持ったコードレビューは持っていないのではないか？
実は、オープンソースの方がはるかに高品質な開発プロセスを持っているのではないか？

また、パッチベースのワークフローをGitやMercuiralのような分散バージョン管理が補完している特徴も見逃せない。
マスタリポジトリはコミッタしか変更できないが、開発者は自分の好きな場所でリポジトリをコピーできてハックできる。しかも、マスタリポジトリから即座に最新ソースをマージして、常に最新バージョンにできる。
この分散バージョン管理におけるトピックブランチの仕組みが、パッチベースのワークフローを簡単にさせているのだろう。

GitもTortoiseGitがかなり機能改善されたので、TortoiseHgと比較しながら使ってみたい。

Redmineのプラグインが充実している

昨年に比べると、Redmineのプラグインがすごく充実している。
いろいろ試してみてメモ。

【コードレビュー】
r-labs - Code Review - Redmine

Redmineリポジトリ画面からコードレビューのチケットを発行できる。
UIも使いやすいし、チケットでレビュープロセスを管理できるから、ReviewBoardでわざわざコードレビューしなくても良い気がしてきた。
それぐらい素晴らしいプラグイン。

【Hudson】
r-labs - Hudson - Redmine

RedmineからHudsonと連携できる。
以前は、Redmine - PluginSimpleCI - RedmineでしかCIツールと連携できなかったが、このプラグインの方がはるかに高機能。
Hudsonを使っているなら、このプラグインは必須。

このプラグインのおかげで、ビルド管理をチケット駆動開発に含めることができるぐらい重要。

【工数集計】
WorkTime - kusu - A redmine plugin to view and update TimeEntry by each user. - Project Hosting on Google Code

ユーザ単位に月次で工数集計してくれる。
顧客へ工数レポートを毎月提出しているなら、このプラグインで十分。
UIもデザインも使い勝手が良い。

Redmineのレポート出力機能はTracに劣るけれど、下記のようなグラフ表示のプラグインも出ている。

Redmine - PluginCharts - Redmine

【Wiki拡張】
r-labs - Wiki Extensions - Redmine

RedmineのWikiはTextTileのため、Tracに比べると使いづらい。
上記のプラグインは、Wikiでサイドバーやタブを新規追加できる。
更に、コメント追記など、色々拡張できる。

他のプラグインもあるので、色々試したらいいと思う。

【史上最高のチームプラグイン】
他に面白いプラグインがある。

r-labs - 史上最高のチームプラグイン - Redmine

Redmineプラグイン開発 - 史上最高のチームプラグインリリース - フジハラボ -- 目指せ！スーパーエンジニア

これは、メンバー全員の現時点の進捗や工数から成績を表示するプラグイン。
コンセプトもデザインも面白い。

チケット駆動開発では、どうしても進捗管理などマネジメントに特化しているように思えるけれど、メンバーのやる気や感謝の気持ちを表現できれば更に良いと思う。
チケット駆動開発はアジャイル開発の一プロセスだから、プロジェクトファシリテーションのプラクティスとも相性がいいから。

【CSVインポート】
r-labs - Csv importer - Redmine
Redmine_Importer: Redmine CSV Import Plugin | Martin Liu - Martin's Crazy World

ExcelRedmineAddIn 1.0.0 リリース - かおるんダイアリー

Redmineにチケットを登録する時、WBSを作成したから大量のチケットを登録したい時がある。
そんな時にこれらのプラグインが役立つ。
このプラグインもチケット駆動開発を運用する上で必須だろう。

他のプラグインの開設は、r-labs - Redmineプラグイン集 - Redmineが日本語で、とても詳しく説明してくれているので参考にしよう。

【サブタスク】
Redmine - Feature #443: Subtasking - Redmine

Redmineでチケット駆動開発を運用する時、ストーリーカードを表現しづらい弱点があった。
僕は、Jiraのタスク(チケット)はサブタスクを持てるように、ストーリーカードはチケットの親子関係で対応する方法が最も簡単な解決手段だと思っている。

上記のプラグインを使うと、チケットに階層構造を入れることができる。
従って、第1階層をストーリーカード、第2階層以下をタスクカードで使い分ければいいのではなかろうか？

他にも、Scrumのアイデアを使ったプラグインがたくさんあるので、ストーリーカードやバックログをRedmine上で表現できるのではないか？

Redmine - Backlogs plugin 0.0.1 (scrum/agile) - Redmine

Redmine - Redmine Scrumdashboard plugin - Redmine

Redmineの本家のプラグインを見ると、Tracのプラグインに劣らないぐらい充実している。
本家に通知していないプラグインやgithubでハックしたものも含めれば、かなりの数に上るだろう。
世界中の開発者が、Redmineをアジャイル開発のプロジェクト管理で使えないか、日々フィードバックしているのだ。
色々追いかけてみたい。

Webシステムのリリース作業とフォールトトレランス

「Release It! 本番用ソフトウェア製品の設計とデプロイのために」を読んで、Webシステムのリリース作業の大変さ、非機能要件における性能・稼働率についてあれこれ考えた。
フォールトトレランスとリリース作業に関するメモ書き。

【元ネタ】
フォールトトレランス

フォールトアボイダンス

フォールトトレランスの定義と具体例が理解しやすい。

フォールトトレランス(耐障害性)とは、「失敗や障害が起きることを見越して、どんな事態に陥っても全体としての機能を失わないようにすること」です。
フォールトトレランスを実現する方法は下記の通り。

フェールソフト(周辺故障)とは、「システムが誤動作をしたり部品が故障したりしても、機能を完全に停止するのではなく、可能な範囲で稼動させること」
フェールソフトは継続性を重視しており、フェールオーバーを含むこともあります。

フェールセーフ(安全側故障)とは、「システムが誤動作をしたり部品が故障したりしても、安全側に制御すること」です。
フェールセーフは安全性を重視しています。

フェールオーバー(冗長性故障)とは、「設備を必要最小限よりも多く用意して、システムを冗長（リダンダント）化させて障害に備えることにより、フェールソフトを実現すること」。
フェールオーバーは継続性を重視しています。

フールプルーフ(誤操作対応)とは、「利用者が操作や手順を間違えても、危険を招かないように設計すること」です。
フールプルーフは安全性を重視しています。

フォールトアボイダンスとは、「失敗や障害の要素を完璧な精度にしたり十分に訓練したりして、失敗や障害を発生させないようにすること」です。
フォールトアボイダンスは古典的な手法ですが、「人間は間違いを犯す」という思想が広がり、フォールトアボイダンスだけでは不充分なため、現在はフォールトトレランスに重点を置くことが主流になっています。

リリース作業中、あるいは運用中でもシステムが障害を起こしてしまう時はある。
フォールトトレランス(耐障害性)を実現する4種類の方法は、障害が起きてもそのダメージを少なくする為のノウハウだ。

そして、特に組込み機器ではそれらの機能も実装する必要があるため、余分な開発工数をあらかじめ考えておく必要がある。

昨今のWebシステムでも、そのリリース作業は、10年前よりもはるかに高度になっている。
リリース中もシステムをダウンさせない手法が一般的になっている。

昨今の普通のWebシステムは、WebサーバーもDBサーバーも複数のサーバーへ物理的にも論理的にも冗長化されている。
その場合、ロードバランサによって、負荷に応じて各サーバーへ振り返られている。

昔のWebシステムのリリース作業は、手間が多かった。
まず、システムを停止し、アプリケーションを1個ずつデプロイし、Webサーバーを再起動する。
Javaならば、warやjarではなく、classファイルを1個ずつFTPでアップしていた。
更に、JSPは初回表示が遅いので、Webサーバー起動後、各画面を表示してJSPをリコンパイルさせていた。
だから、そのリリース作業中の数時間はWebサイトが使えません、とあらかじめユーザへ連絡する必要があった。
ユーザ企業としては、システムのダウン中はシステムから売上が出ないから、リリース作業と言えどもダウン時間が長いほどダメージは大きい。

それに対し、最近のWebシステムのリリース作業は下記が普通だ。
リリースする順番ごとに各サーバーをWebから切り離し、バックグラウンドでアプリケーションをデプロイして再起動していく。
リリースできたら、ネットワークにつなげて、次のサーバーへリリースしていく。
この手法ならば、ユーザ側からは、システムがずっと稼働中でダウンしているようには見えない。

情報処理試験にある信頼性の問題(午後1・問4)にもあるように、Webシステムの障害を検知する仕組みも以前に比べると洗練かつ複雑になっている。
Webサーバーの障害を検出する機能として、ヘルスチェックがある。
ヘルスチェック機能は、ping監視という最も基本的な方法から、ポート監視、プログラムやシェルによるアプリケーション監視がある。
例えば、ping監視やポート監視はWebアプリとは異なる外部サービスで行ったり、アプリケーション監視はログ出力やヘルスチェック用のJSPで実装したりする。

また、情報処理試験の問題にあるサーバー構成図のように、負荷分散と冗長化を兼ねたデュプレックスシステムのアーキテクチャで、WebサーバーとDBサーバーを冗長構成するのが普通になっている。
このやり方ならば、稼働率も安定する。

ネットの情報によれば、Googleは「サーバーやHDDは定期的に壊れる前提でサーバーを構成している」らしいから、おそらく冗長化の技術が普通のSIよりも優れているだろうと推測される。

システムはプログラミングだけでなく、稼働率の高いサーバーの構築というタフな作業もあるのだ。

MSMoneyのLinux版GnuCash

GnuCashは資産管理もできる家計簿アプリケーション。
MS MoneyのLinux版みたいなアプリ。

MS Moneyのファイルも読み込めるので、クレジットカードや銀行のWebページからMS MoneyファイルをダウンロードしてGnuCashに取り込めば、家計簿を簡単に付けれる。
複式簿記に対応できているので、ちょっとした財務管理に使えるかもしれない。

実際にインストールしてみたものの、操作やGUIは癖があるので、慣れないと使いづらい。
でも、オープンソースで公開されていて、随時バージョンアップされている。
日本語化されているので、試してみたい。

【元ネタ】
Free Accounting Software | GnuCash

GnuCash - Wikipedia

GnuCashを再び使ってみる | 我が心のあれこれ

Windows版のGnuCashを入れてみた - より良い環境を求めて

GnuCash チュートリアル・コンセプト ガイド

GnuCash - Linux on the Desktop

マネジメントのスピードが開発のスピードに直結する

倉貫さん(XPJUG代表)の記事を読んで、システム開発に関する洞察が優れている点についてメモ。

【元ネタ】
アジャイル開発のボトルネック - Social Change!

(中略)
つまり、発注側のかけるコスト（工数）の限界が、ソフトウェア開発における速度の限界点なのだ。プロジェクトが成功するかどうかの分水嶺と言える。
これは実はアジャイル開発に限らず、一般的なウォーターフォールのソフトウェア開発でも、まとめて要件定義や検収テストをしているだけで、結局、同じくらいの工数がかかっていたのではないだろうか。もちろん、要件定義の前のビジネスや業務検討のフェーズを含めれば、である。
アジャイル開発では発注側が行う作業へのコミットが細分化されて見えるので、開発と同程度の工数が必要だという傾向が顕著に見えるだけかもしれない。発注側と開発側にかかる工数比があるように思わせたのは、そうしないと儲からないSIerの罪であろう。
『ソフトウエア開発においては、開発側が必要とする工数と、発注側が必要する工数を同等にするべきである』こんな法則があるのではないだろうか。そして、『発注側は、自社がかけれる工数（コスト）以上の、発注をしてはいけない』というルールでもあれば、うまくいくのではないだろうか。
(後略)

上記の指摘は、昨今のシステム開発の現状において非常に的を得ていると考える。

僕は、Redmineによるチケット駆動開発を運用して初めて、アジャイル開発はこういう開発スタイルなんだ！と実感した。
即ち、チケット駆動開発では、ロードマップ画面でバージョンをイテレーションに見立てて、小刻みに機能拡張しながらリリースしていく開発スタイルになる。
つまり、XPの小規模リリースを自然に具体化した開発プロセスになる。

すると、チケット駆動開発を運用する開発チームの内部作業はスムーズに進むようになり、顧客と仕様やスケジュールを調整するプロセスがボトルネックになってしまう現象が頻繁に起こるようになった。
例えば、開発チームではこういう仕様で進めるし、無理ならば代替の仕様が選択肢としてありますよ、と顧客に提示するが、そこで決定に時間がかかってしまう。
実際に作ってリリースして、顧客に見せたら、ちょっと違うよと言われる機能があったり、本来の要件が間違っていた事実も判明するが、どんなスケジュールで直していくか、優先順位を顧客が付けれない。
リリーススケジュールを開発側が提示して、返事待ちという状況が多くなる場合がある。

この状況の原因は、開発の速度よりも仕様やリリーススケジュールを決める速度が遅い点にある。

従来ならば、システム開発そのものに工数もコストもかかっていたが、Railsなどの優れたフレームワーク等のおかげでプログラミングの速度が上がってきた。
そして、RedmineやTestLink、チケット駆動開発で開発チーム内部の作業も効率化し、品質も安定するようになってきた。
すると、開発チームで制御できないプロセスがボトルネックになって、開発の速度に制約がかかる。
特に、レビューと言うプロセスでこの症状が顕著に現れる。

XPにはオンサイト顧客というプラクティスがある。
顧客も開発チームに加わり、ストーリーカードの優先順位付け、受入テストなどを行う。
実際の開発では、顧客が開発チームに入るのは難しいので、要件定義を行うSEがその役割を担っている。
倉貫さんはこの手法を「顧客プロキシ」(オンサイト顧客の代理人)と呼んでいた。

ここで、オンサイト顧客(要件定義を行うSE)の重要な役割の一つに、開発チームが作ったシステム仕様をレビューして、品質チェック後、承認するという作業がある。
このレビュープロセス(デザインレビュー)はすぐに完了できるわけではないし、レビュー後にその仕様で実装していくから、レビュープロセスのキューにどんどんタスクが溜まって、開発速度が落ちる現象が頻繁に起きるようになった。
かと言って、レビュープロセスを簡略化したり、無視していいわけではない。
そして、SEの代わりに顧客を連れてきても、状況はおそらく変わらない。

今の僕の経験では、デザインレビューが開発のボトルネックになっている。
つまり、デザインレビューの速度が上がらなければ、開発の速度が現状以上に上がらない。

要求を洗い出す作業と、要件を仕様化する作業は別の能力だと思う。
要求開発やBaBOKのレベルでは、業務の全体最適化(つまりエンタープライズアーキテクチャ)の観点から、システムのあるべき姿を導き出す。
しかし、我々ITエンジニアは、要件をいかにシステムとして実装して稼動させるか、という作業に注力を注ぐ。
それらの作業は大きく異なる。

その作業をつなぐ部分にボトルネックがあるのかもしれない。