« 2008年3月 | トップページ | 2008年5月 »

2008年4月

2008/04/30

Subversionのブランチを有効活用してアジャイルに開発せよ

デブサミ2008講演資料の「SubversionとMaven 2 による構成管理」を読んで、改めてソフトウェア開発ではソース管理が最重要であると再認識した。
ソース管理について振り返ってみる。

【1】ソース管理の歴史

ソフトウェア開発では、ソース管理が必須だ。
ソース管理の本質は、履歴を辿って、いつでもソースをUndo、Redoできること。

昔のコンピュータ資源が希少な時、そもそもプログラムを履歴に残すことすらできなかっただろう。
今でもリリース時によくやるように、システム一式を複製して日付でリネームしていた。

僕は当初、ソース管理に、MSのVisualSourceSafeを使っていた。
CVSよりも直感的でGUIが使いやすい。

VSSを使い始めてから、下記の作業がルーチンになった。

朝、出社後、VSSから最新ソースを落として、VisualAgeForJavaのワークスペースにインポートする。

自分の担当のソースは、VSSからチェックアウトして、他人が修正できないように排他ロックする。

夜、退社間際に、VisualAgeForJavaのワークスペースからエクスポートして、VSSへチェックインする。

これによって、新規開発でも、結合テスト以降のバグ修正でも、VSSのソースを最新版として管理できるようになった。

しかし、VSSの弱点は一つは、チェックアウトされたソースは担当者以外は誰も修正できないこと。
CVSと違って、VSSのチェックアウトは排他ロックであるため、一つのソースを二人が平行作業することはできない。
だから、共通ライブラリを同時に修正する必要がある時等は、プロジェクトリーダーが慎重にアサインする必要があった。

VSSの弱点のもう一つは、ブランチを切った後のマージ作業が面倒なこと。
Ver1.0を本番リリース後、Ver1.0をバグ修正するチームと、Ver2.0に向けて新規開発するチームに普通分かれる。
その時、Ver2.0へVer1.0のバグ修正をマージする運用ノウハウがなかったので、マージ作業中は、Ver2.0のソースを凍結したりしていた。
理由は、一気にマージしようとするので、マージするソース量が膨大だったから。

だが、その期間は、Ver2.0の開発が遅れてしまう。
しかも、マージ後のソースは、新規開発中の機能と衝突したりする。
だから、開発者も単なるマージ作業のメンテナンスで疲労したものだ。

最近は、Subversionを使い始めた。
すると、SVNでは、

/trunk
/branches
/tags

の3つを意識的に使い分けて、下記のようにソースを管理するのが普通。

最新ソースは常にtrunkにチェックイン。

リリース直前にバージョンを付けて、tagへ入れる。

リリース後は、ブランチを切って、保守モードにする。
ブランチにコミットしたソースは後からtrunkへマージする。

この方法で飛躍的にアジャイルに開発できるようになった。

しかし、最近のWebシステムは、極端な時は、1週間に1度はリリースする。
だから、そのたびに、ブランチを切る羽目になり、しかもマージ作業が発生する。

また、ブランチを切るタイミングがすごく難しい。
ブランチを延命させると、マージ作業が大変になる。

今でも、頻繁なリリースとソース管理の連携に非常に苦労している。

【2】ブランチを切るタイミング

そこで「パターンによるソフトウェア構成管理」を読み直した。

「パターンによるソフトウェア構成管理」では、下記のパターンを述べている。

2-1.trunkを開発のメインラインとする。

2-1-1.最新ソースの開発はメインライン。
 メインラインは常にビルドが通るようにする。
 
2-1-2.ブランチはメインラインから行う。
 つまり、ブランチからブランチを切ることはしない。
 
2-1-3.ブランチしたら早めにメインラインにマージするようにする。
 マージ作業のコストを減らすため。

2-2.ブランチを切るタイミングは複数ある。

2-2-1.リリースブランチ
 大きいバージョンアップのリリース直前に、メインライン上でtag付け後、ブランチを切る。
 普通はこの場合が多いだろう。

 メインライン(trunk)が新規開発で、ブランチが運用保守。
 利点は、リリース期間中に、保守と新規開発の2つの開発を平行できることだ。

 「パターンによるソフトウェア構成管理」では、運用保守のブランチをリリースライン、又はリリースブランチを呼んでいる。
 理由は、既に安定しているリリースブランチにパッケージングや些細なUI修正などを施して、ブランチを延命する場合もあるからだ。

 つまり、もう一つの場合は、リリース用モジュールを早く作りたいために、リリースする前から早めにブランチを切る。
 そのような場合は、ブランチ上で、微小なUI修正など直近のリリース作業に専念する。
 新規機能の実装は、メインライン上で行うようにソースを分ける。
 
 メインラインへマージする作業はおそらく頻繁に発生する時もあるが、リリースブランチが安定すれば、マージする回数も減ってくるだろう。

 この手法の利点は、リリース作業に専念するリリースブランチがあるので、メインライン上で新規開発を凍結しなくてもいいことだ。

 この手法は、複数の顧客ごとにカスタマイズした機能を付けて順にリリースしなければならない時にも使えるだろう。

2-2-2.タスクブランチ
 メインラインへ大きな影響を及ぼす修正が必要な場合、ブランチを切って、ブランチ上で実験する。
 「パターンによるソフトウェア構成管理」ではタスクブランチと呼んでいる。

 この手法を使う場合は、共通ライブラリのバージョンアップや新規追加、ビッグ・リファクタリングをする時のように、メインラインのソースを大幅変更する場合に使う。
 
 この手法を使う回数は少ないだろうが、一人の開発者が大量のソースを修正しなければならない状況も、時にはある。
 その時、メインライン(trunk)に不完全なソースをコミットして欲しくない。
 
 だから、故意にブランチを切って、そのブランチ上で完成するまで作業してもらう。
 タスクブランチへメインライン上のバグ修正ソースをマージする時も多々あるだろう。


【3】RedmineのプロジェクトとSVNブランチを連携させる利点

 上記のようにtrunkとブランチを意識して使い分けた場合、「どんなバグ修正や仕様変更が反映されているのか?」を管理することが重要になってくる。
 ここで、Redmineの複数プロジェクト管理が有効に使える。
 
 つまり、Redmineの親プロジェクトには、SVNリポジトリのtrunkを紐づけておく。
 そして、Redmineの子プロジェクトごとに、SVNリポジトリの各ブランチを紐付けるのだ。
 
 これによって、新規開発のチケットと運用保守のチケットを別々に管理するのが簡単になる。
 チケットとSVNリビジョンが紐づいているので、どんなバグ修正や仕様変更がソースに反映されたのか、がチケットからすぐに分かる。

 特に、結合テスト以降リリース直前までの期間は、バグ修正と仕様変更が入り乱れる。
 だからこそ、デグレが起きないように、常にtrunkが最新ソースで最も安定するように保守していくのは最重要なのだ。

【4】Subversionのブランチ管理はアジャイル開発の配管作業

 VSSが駄目なのは、いつもメインライン上でしかソースを修正できないこと。
 でも、SVNでブランチを切りすぎると、マージ作業が大変になる。
 
 ここで、日次ビルドできる環境があれば、マージ作業後の検証も楽になる。
 素早く検証できるビルド環境とソース管理は密接に関連する。

 また、Linuxでは、GITのようなツールで、更にマージ作業が簡単になるようにブランチ管理しているようだ。
 GITは詳しく分からないけれども、その発想は頷けるものがある。

 ブランチを有効活用すれば、頻繁なリリースに耐えうる開発プロセスを作ることができる。


| | コメント (0) | トラックバック (0)

2008/04/29

受託開発プロセスはプロジェクトリーダーの手腕に100%依存している

「受託開発の極意」を読んだ感想を書いてみる。
#思いついたまま書くので、論理的整合性は後回し。

【1】受託開発プロセスはプロジェクトリーダーの手腕に100%依存している

SIerの受託開発プロセスは、プロジェクトリーダーに大きく依存していると思う。
プロジェクトリーダーごとに独自のプロジェクト管理技術を持っているのが実情だろう。

僕も過去に色んなプロジェクトリーダーを見てきた。
顧客調整が得意な人、進捗や運用の管理が上手な人、チームビルディングに力点を置いてメンバーをその気にさせるのが上手な人など。

「受託開発の極意」を読むと、顧客調整や要件定義プロセス、進捗管理、チームビルディングに彼独自の手法を編み出しているのが良く分かる。

それはそれでよいのだが、開発プロセスがプロジェクトリーダーに依存しすぎていたら、CMMのレベル3の段階ではないと思う。
つまり、組織として、標準化されたプロセスを持っているわけではない。
学習する組織まで成熟していないように思う。

本を出版しているから、そのノウハウは社内で公開され共有されているだろうが、普通のSIerでは、なかなかそこまでできないのが実情だろう。

【2】設計で品質を作りこむ

「受託開発の極意」を読むと、設計で品質を作りこむという思想が根底にあるように思える。

サービスは見積もりから始まっている。
だからこそ、工数見積に細心の注意を払う。

丸投げされた時は責任の所在を明確にしてから受ける。
丸投げドキュメントは、一覧を作って整合性を図り、シナリオを書きながら検証していく。
要件定義でも進捗を示して、前進していることをお客様にも見せ付けておく。

高レベル設計はドキュメント重視、低レベル設計はテスト駆動。
これは非常に役立つノウハウだと思う。

ソースコードに近い設計は、ユニットテストを書きながらプログラミングしていけばいい。
ユニットテストで大事なのは網羅性。
カバレッジが100%でないと、漏れたロジックからバグが出る。

でも、複数の機能を組み合わせて初めてシステムが出来上がるのに、機能の結合部分の調整でいつも労力がかかる時が多い。
その時は、プログラミングレベルではなく、システム全体を鳥瞰して、一連の業務フローというシナリオで理解する。
そうすれば、特に異常系の業務フローから派生するバグを発見できる。
このレベルは、ユースケース駆動と言っていいだろう。

ユースケース駆動で重要な成果物はドメインモデルだ。
つまり、お客様の業務の用語集がドメインモデルに相当する。
ドキュメントとは、業務の用語集であるべきなのだ。

特に運用保守では、保守されたドキュメントが威力を発揮する。
本番稼動後に、お客様から仕様を質問された時、的確に素早く返答せねばならない時が多い。
その時に手元に役立つドキュメントがあるかどうかの違いはすごく大きい。

業務フローからプログラムまできちんとトレースするためのミッシングリングの一つがドメインモデル。
つまり、仕様をプログラムにあるオブジェクトへ翻訳する。


【3】プロジェクトリーダーの本質的な役割は、人と組織を変化させること

「受託開発の極意」では、プロジェクトリーダーの大きな役割の一つに変化があると主張している。

プロジェクトリーダーの評価は、プロジェクトが納期通りに完了して黒字になることだけではない。
お客様と信頼関係を築いて、リピートオーダーがもらえることも含まれている。
更に、チームメンバーがプロジェクトを経験して成長していることも含まれている。

つまり、プロジェクトリーダーが関わる人達が、プロジェクト開始前と終了後に変化していなければ、成功したと評価されないのだ。

「受託開発の極意」では、自分を変えること、周囲の仲間を増やして組織を変えることのテクニックが書かれている。
普通のプロジェクトリーダーは、請け負ったプロジェクトのメンバーだけしか影響させられない。

でも、大規模プロジェクトでは、メンバーだけでなく、複数のチームを影響させねばならない。
だから、普通は、サブリーダーを通じて複数のチームをコントロールするようになる。
その時に、右腕となるサブリーダーとの信頼関係構築が最も重要になる。


受託開発はパッケージ製品開発と違って、デスマーチになりやすい傾向がある。
しかし、日本の大手SIerのパッケージ製品は、メインフレーム+Cobolで動く金融システムとか、ビジネスユース向けのWidows上で動くVBプログラムとか、技術がすごく古い。
最近になってようやく、Web2.0の技術を基盤としたビジネスが出ているけれど、それはまだごく少数。

受託Webシステム開発ならば、その時代のオープンソースのライブラリやサーバー環境を上手に使いこなせば、常に最新の技術を追いかけながら仕事できる。

受託開発のボトルネックであるプロジェクト管理さえ上手に制御できれば、受託開発はもっと面白い仕事になると思っている。

| | コメント (0) | トラックバック (0)

2008/04/23

Web2.0の特徴はCGM

CGM(Consumer Generated Media)という言葉が流行しているらしい。
CGMとは、下記の定義らしい。

インターネットなどを活用して消費者が内容を生成していくメディア。個人の情報発信をデータベース化、メディア化したWebサイトで、Web 2.0的なもののひとつとされる。商品・サービスに関する情報を交換するものから、単に日常の出来事をつづったものまでさまざまなものがあり、クチコミサイト、Q&Aコミュニティ、ソーシャルネットワーキングサービス(SNS)、ブログ、COI(Community Of Interest)サイトなどがこれにあたる。

 従来、インターネットメディアは雑誌や書籍などと同様にプロの書き手と編集者が内容を構成していく出版社型の事業モデルが多かったが、CGMでは一般の消費者が直接情報を投稿し掲載される。これにより実体験や生の声がリアルタイムにかつ膨大に提供・集積されるようになった。メーカーやマスメディアでは想定しえない特殊な事例や利害関係に束縛されない自由な意見が情報として集積されるため、消費者にとっては重要なサポート環境であり、メーカーにとっては商品の良し悪しがそのまま商品の人気に直結する場となっている。


マーケティングの観点では、情報を公開するだけでなく、ログインさせて囲い込むことが重要。
ログインというやや閉鎖的な空間の中で、ログインユーザ同士が、楽しくチャットしながら、情報共有する。
そういう場を提供すること。

今の時代、猫も杓子もSNSみたいだ。

技術的な観点では、Ajaxが鍵を握る。
デスクトップアプリと変わらないリッチUIをWeb上で実現する。
背後で非同期通信しながら、ネットワーク応答の遅さを感じさせない。

Web2.0の技術を見ると、メインフレームのCobolや、MSのWindowsAPIが古臭く見える。

Web2.0で作られたWebアプリは、共有やコミュニケーションがキーワードなのだ。


| | コメント (0) | トラックバック (0)

2008/04/22

アジャイル開発のインフラ

SIerはお客様の業務をIT化するのがお仕事なのに、自分たちの業務は意外とIT化しきれていない。
大量の印刷した紙、手作業の多い仕事に囲まれている。

ソフトウェア開発のインフラを考えると、最低3個の環境は必須だ。

一つは、ソースコード管理。
二つ目は、検証可能なビルド環境。
そしてBTS。

この3つについて考えてみる。

【1】ソース管理

プログラミングで仕事するならば、ソース管理(SCM)は必須だ。
ソース管理システムの本質は、前回のプログラムへUndoができること。
つまり、プログラムの履歴が残っているからこそ、前バージョンへUndo、Redoができる。

ソース管理は、MSならVSS、普通は、CVSかSubversionを使うのが普通だろう。

ソース管理で重要な作業はブランチやタグ付けができること。
ブランチは、枝分かれしたバージョンツリー。
タグは、ある時点でバージョン付けられたソース一式。ブックマークみたいなもの。

普通は、本番リリースや納品時にタグ付けして、バージョンをFixする。
そうすれば、同じモジュールを再リリースすることがいつでも可能になる。

ブランチを使うケースは、バグ修正と新規開発が並行して走っている場合。
特に運用保守フェーズでは、裏で仕様追加に伴う新規開発をしながら、緊急のバグ修正もこなさなければならない。
この時に本番モジュールと新規開発モジュールを区別するために、2系統のソース管理が必要になる。

普通のプログラマなら上記のことは行っているだろうが、実は、Webデザイナーの人たちにはソース管理と言う概念が無い。
だから、HTMLやCSSなどのViewソースは、実はソース管理がすごく難しい状況がある。

彼女たちにもSubversionをマスターさせればいいだけなのだが、彼女たちには難しいらしい。

【2】ビルド環境

ビルド環境の本質は、すぐにリリース可能なモジュールが作れること。
正しく動くプログラムを複製するソフトウェア工場のイメージに近い。

だめなプロジェクトは、すぐにビルドできない。
だから、バグ修正をすぐに反映できない。
結局、すぐに検証できないので、いつまで経ってもプロジェクトが収束しない。

最近のビルドは、単なるコンパイルだけでなく、ユニットテストも通すのが普通だろう。
つまり、回帰テストも通す。

これは、コンパイルの概念を拡張したものに相当する。
つまり、プログラミング言語体系に沿っているだけでなく、ユニットテストという仕様にプログラムが正しく合致しているか、Evaluateしているということ。

だから、最近のビルドは結構時間がかかる。

【3】BTS(バグ追跡システム)

BTSの本質は、アジャイル開発そのもの。
ドキュメント駆動ではなく、動くプログラムにどんどん手を加えて、多種多様な環境やフローにも耐えうるように品質を上げていくプロセスを補強する。

よくありがちなのは、BTSがないプロジェクト。

BTSがないプロジェクトは、結合テスト以降の開発がすごく弱い。
バグ報告からバグ修正、そして検証、リリースに至るまでのプロセスの状態と担当者をプロジェクトリーダーがきちんと把握できていない。

詰まる所、そのプロジェクトはおそらく殆どの場合、ウォーターフォール型開発。
だから、たくさんのバグ報告と修正に追われて、収束が付かなくなる。

Redmineには、バグ修正のステータスに特徴がある。
普通は、下記のバグ修正のフローだろう。

新規(Open):テスト担当者がバグ報告する

担当(Assigned):プロジェクトリーダーがPGをアサインする

解決(Resolved):PGがバグ修正する

検証(Verified):テスト担当者がバグ修正を検証する

終了(Closed):プロジェクトリーダーがバグ修正内容を確認する

Redmineでは、更に「却下」「フィードバック」というステータスがある。
「却下」とは、バグ報告を修正せずに終了すること。
例えば、「このバグは仕様なのです」みたいなケースだろう。

「フィードバック」とは「差し戻し」。
例えば、バグ修正して検証したら、実はバグが直っていなかった場合、PGへ差し戻しになる。

上記2項目がデフォルト設定されているRedmineは、実に良く考えられている。


最後に、おそらく上記の3つのうち一つでも欠けたら、多分そこからプロジェクトは炎上する。
ソース管理、ビルド環境、BTSはアジャイル開発のインフラ。

| | コメント (0) | トラックバック (0)

WebブラウザのJavaScriptエンジン高速化がもたらすもの

「SaaSに追い風、桁違いに速い次世代Webブラウザたち」の記事を読んだ感想。

Ver3のFireFox、Safariは性能がすごくいいのは知られていた。
その秘密は何か?

そもそもWebアプリの弱点は、一つはネットワーク遅延で応答性が悪いこと。もう一つはHTMLコンテンツを動的に扱うJavaScriptエンジンが遅いことだった。

しかし、前者は、Ajaxと総称される非同期通信のテクニックが進化したことでほぼ解消されつつある。
Googleが編み出すサービス群がその良い例。

後者は、次世代Webブラウザに搭載されるJavaScriptエンジンが高速化することで、今後解消されていくだろう。

そして、それは何をもたらすか?

近い将来、殆どのデスクトップアプリはWebアプリへ置き換わるだろう。

例えば、Google Docsの表計算アプリケーションは、Web上でExcelっぽく使える。

メールソフトも今やGMailを使う人が殆どではなかろうか?
GMailならば、外出先でも携帯からでも閲覧できる。

上記2点とも、Ajaxによる非同期通信のおかげで、ネットワーク越しの応答の遅延が気にならなくなったということ。
ユーザがブラウザで閲覧している裏で、Ajaxが必死になってDOMを生成して、HTMLをレンダリングしている。

利点は、ネットワーク上の人たちと情報共有がすごく簡単になることだ。
使いこなせれば、もっとコミュニケーションを活発化できる。

| | コメント (0) | トラックバック (0)

2008/04/18

オープンソースBTSはソフトウェア開発のベストプラクティス

ソフトウェア開発は3つのモードがあると思う。
最初は新規開発モード。
そしてソフトウェア開発の中で最も難しく、最もプロジェクトマネジメント能力を要求されるバグ管理モード。
最後は、運用保守モード。

BTS(バグ追跡システム)は、主にバグ管理モードで使われる。
つまり、各開発者のプログラムを繋ぎ合わせて正常に動かす結合テスト。
あるいは、色んなブラウザに対応しているか、とか、高負荷なアクセスに耐えれるか、などのようなシステムテスト。

BTSとは、そこで上がったバグを収集し、修正し、検証する一連の作業をフレームワーク化したもの。
主にWebシステムで作られている。

このBTSについて再考してみる。

【1】BTSに至るまでの歴史

一昔前。
結合テスト以降のバグ修正は、Excelベースだった。

バグを見つけた人が、Excelのバグ報告票に起票する。
そのExcelを修正担当者に渡し、修正してもらう。
修正後、修正担当者が、バグ報告票をテスト担当者に渡す。
テスト担当者は修正した機能を検証し、OKなら、プロジェクトリーダーへ報告して、報告票をCloseする。

業務プロセスをIT化するのがシステム屋の仕事なのに、自分たちのシステム開発は、余りにも手作業の部分が多かったし、今もそんな状況の開発チームは多くないだろうか?

このバグ修正のワークフローが、ソフトウェア開発で最も難しいのは何故か?
二つあると思う。

一つは、Excelベースなので、同時に複数人の書き込みができない。
バグ報告票は、作業状態によって、修正担当者・テスト担当者・プロジェクトリーダーなど複数人が触る。
システム開発で最も忙しい工程なので、Excelを握ったままの人がいると、はかどらなくなる。


もう一つは、プロジェクトリーダーが作業状態や優先順位を把握しづらいこと。
バグ報告票は複数人が触るので、今誰がバグ報告票を握っているのか、その作業状態を把握するのが最も大事。

でも、たくさんのバグが上がってきたら、どれが最優先に修正すべきか、そして、誰がバグを修正して検証すべきか、という素早い決断をいつもプロジェクトリーダーは迫られる。
その時にExcelベースだと、今どこまで進捗が進んで、後どれくらい残っているのか、そしていつ終えることができるのか、を見極めるのが難しい。

そこで、自社独自の開発プロセスを持つ大手SIerは、普通、独自のBTSを持っている。
ExcelベースをWeb化して、それなりに運用している。

しかし、この独自のBTSも良し悪しがある。
一つは、社外で利用する時に困ること。
最近は、請負開発で分散開発していたり、オフショア開発で海外で作っていたりすると、バグ情報を共有できない。

また、プログラマにとっては、独自のBTSの使い方に慣れないのも困る所。
大手SIer独自の開発プロセスに特化しすぎな部分があるからだ。


【2】BTSのワークフロー

ここでBTSのワークフローをおさらいしてみる。
このフェーズの作業フローは、Wikipediaで下記で明確に書かれている。


【Open】バグの報告:
テスト担当者はバグを発見するとバグ管理システムにアクセスしてバグの報告を行う。報告の完了時にはバグの状態は「Open」となり、すべての開発者にメールで通知される。

【Assigned】担当者を決定:
管理担当者はバグ情報を確認し、適切な修正担当者を割り当てる。修正担当者が割り当てられるとバグの状態は「Assigned」となり、修正担当者にメールで通知される。

【Resolved】バグの修正:
修正担当者は、バグを修正したら解決方法等を追記し、バグの状態を「Resolved」とする。修正の報告はテスト担当者にメールで通知される。

【Verified】修正の確認:
テスト担当者は再テストを行い、修正が完了していることを確認した上で、バグの状態を「Verified」とする。

【Closed】修正の完了:
管理担当者は「Verified」となっているバグに対して内容を確認し、状態を「Closed」に変更する。

ここで大事なのは、テスト担当者・修正担当者・管理担当者という3つの異なる担当者が関わり、5つの作業状態が変化すること。

RedmineやTracのチケットをバグ報告票と見なせば、BTS自体は非常に使いやすいToDo用のワークフローシステムだと言える。

そして、このワークフローは実は、ソフトウェア開発のフレームワークとして、一般化できる。

【3】BTSはソフトウェア開発のベストプラクティスを抽象化したフレームワーク

つまり、BTSは下記3パターンの作業フローに使える。

1・バグ管理ならBTS。
2・日々の運用保守や、開発時の様々な雑用のタスク管理なら、プロジェクト管理。
3・お客様から上がってきた仕様追加や仕様変更なら、要求管理。

だからこそ、オープンソースのBTSは数多いし、あちこちで使われている。
有名なBTSなら、Bugzilla、Mantis辺りだろうか?

Excelや独自のBTSよりも、オープンソースのBTSを使った方が効率が良いと思う。
理由は、多種多様なプログラマがBTSを使いこなし、カスタマイズして進化させてきたから、業界標準に従っている面があること、そして、ソフトウェア開発のベストプラクティスが含まれているからだ。

【4】Remineは単なるBTS以上のソフトウェア開発のインフラだ

ここで、Redmineを見ると、色んなパラメータをカスタマイズできる。
例えば、ステータスは上記5個のステータスそのものがデフォルト設定されていて、更に追加・修正もできる。
ユーザの権限も、増やすことができる。

更に、ワークフローと言う項目があり、そこでは、「バグ」「機能」「サポート」のチケットの種類に応じて、上記のステータスを一部だけ抜き出して選択することができる。

つまり、Redmineでは、担当者の権限と作業状態を作業フローの種類に従って選択・抽出できるのだ!
更に、Redmineでは、複数プロジェクトも管理できる。

だからこそ、新規開発モード・バグ修正モード・運用保守モードをそれぞれのプロジェクトで作っておき、それぞれの作業フローに従って、担当者の権限と作業状態をカスタマイズすればいい。

特に、運用保守フェーズでは、緊急のバグ修正時のソースと、工数をきちんと確保して仕様追加したソースを使い分けなければいけない。
この時に、リリース用モジュールがデグレしたり、新機能が混じったりしまいがちなので、細心の注意が必要になる。
普通は、Subversionでブランチを切って別管理するのが普通だろう。

ここで、Redmineで複数のプロジェクトに分けて、それぞれのSVNリポジトリを紐づけることができる。
そうすれば、運用保守モードのチケットと、新規開発モードのチケットを区別して、仕様からチケットを経由してソースコードまで、一貫してトレースできる。

Redmineで複数プロジェクトを管理できる利点が今まで良く分からなかったが、上記のことをやってようやく分かった。

ソフトウェア開発が難しい理由は、似たような3つのモードの作業フローを意識して切り替えながら、ソース管理もやっていく所にあるのだろう。

| | コメント (0) | トラックバック (0)

2008/04/16

チケット駆動開発でXPの計画ゲームを実施する

昔、XPlannerというXPのアイデアを実現したWebアプリがあった。
そのソフトは、XPのタスクカード単位で進捗管理できるのがウリだった。
でも、正直使い勝手は良くなかった。

そして、最近、Redmineを触って初めて、XPを実現できそうなプロジェクト管理ツールだと直感した。

Redmineによるチケット駆動開発のアイデアをまとめてみる。

【1】Redmineの特徴は、プロジェクトの進捗の可視化

Redmineの最大の特徴は、ガントチャート
チケットに作業内容と開始日、終了日を入れると、すぐにガントチャートが出来上がる。

これを初めて見た時は感動した。
プロジェクトリーダーは、ガントチャートを作って保守するために、殆どの時間を費やしている。
WBSさえ作って入力すれば、ガントチャートを自動生成してくれるのだ!

他に、カレンダーもある。
開発時だけでなく、運用保守時にリリースする日やDBメンテナンスする日が一覧で表示できるのがいい。

また、ロードマップは、マイルストーン単位の進捗率そのものを表示する。
バーンダーンチャートに近い。

プロジェクトリーダーは、ロードマップを見ながら、マイルストーンまでに後どれくらいのタスクが残っているか、をすぐに把握できる。

また、プロジェクトリーダーはロードマップを見ながら、遅れている開発があれば、開発者のアサインを変えたり、納期をずらすよう顧客を説得するなど、色んな手を考えるだろう。

ガントチャート・カレンダー・ロードマップは、プロジェクトの進捗を数字で可視化させてくれる、プロジェクトリーダーにとってありがたいツール。


【2】RedmineのチケットとSVNリポジトリを連携させる

【2-1】Redmineでは、リポジトリというViewがある。
リポジトリViewでSubversionを設定すると、Subversionにあるソースの一覧とコミットログが表示される。

更に、リビジョン単位でソースとコミットログも表示できる。
また、ソースの差分も色分け表示してくれる。

プロジェクトリーダーは、リポジトリを見ながら、いつでもソースインスペクションできる。

チケットとSVNリポジトリを連携させる時に最重要な点は、SVNコミットログをきちんと書くこと。
駄目なプロジェクトは、コミットログが空欄。
だから、何故ソースを改修したのか、すぐに理由を忘れて、デグレが発生しやすくなる。

チケットとの連携は、「refs チケットNo」というコメントをコミット時に入れるだけ。

$ svn commit -m '○○○機能を利用時の△△△な問題を修正。 refs 123'

これによって、チケットにリビジョンNoがリンクされる。
更に、リポジトリにあるソースのリビジョンにチケットNoリンクが逆に表示される。

この作業で、チケットとSVNリビジョンの行き来が簡単になる。


【2-2】TracやRedmineが、ExcelやMS Projectよりも優れている点は、ソースコードとチケット(作業タスク)を紐付けることができること。

つまり、チケットを経由して、ドキュメントとソースコードの紐づけができるので、上流工程から下流工程まで一貫して、要件をトレースできる。

要望書→設計書・テスト仕様書→【チケット】←ソースコード

このやり方は、結合テスト以降のバグ修正や、運用保守時の機能追加で大きな威力を発揮する。
なぜなら、結合テスト以降や運用保守の工程では、死んだドキュメントよりも、実際に稼動中のプログラムの方が重要だから。

チケットのおかげで、バグ修正や機能追加の作業で、誰がどのソースコードをどんな理由で触ったのか、すぐに分かる。

【2-3】これがチケット駆動開発のアイデアだ。

つまり、チケットNo無しのSVNコミットはご法度。
SVNにコミットできるソースは、チケットというちゃんとした理由があるものだけで、そうでない場合はコミット不可になる。

この運用ルールは、本番稼動後の運用保守フェーズで最重要だ。
何故なら、実際に稼動しているソースコードを理由無しに書き換えるのは危険だからだ。

【3】チケット管理の肝

実際にTracやRedmineでチケットを使って開発したことがあったが、上記のような理想的な開発とはならなかった。

その時は、各開発者が勝手にチケットを乱発し、そのチケットを誰が担当するのか、そしてチケットを解決してもデグレが発生したり、とか、うまくコントロールできなかった。

「第2回:なぜTracの導入に失敗するのか?」では、チケット管理の運用で主に問題点として下記をあげている。

1・チケットの優先度を決めるのが難しい
2・チケットのマイルストーンを決めるのが難しい
3・チケットに書き込む内容と工数はどれくらいの規模がいいのか?
4・チケットを閉じる時、どのようなタイミングで行うべきか?

1と2は、チケットの属性に関すること。
3はチケットの作業内容と工数に関わること。
4はチケットの作業状態に関すること。


結合テスト以前と、結合テスト以降、そして運用保守時の2つで使い分けるとよいと考える。

【3-1】結合テスト以前のチケットは、要望を詳細化した仕様そのもの。
開発者はチケットにある仕様を実現するために実装する。

チケットの優先度は全て同じでいい。
マイルストーンは、ガントチャートにあわせればよい。
理由は、動くプログラムをまず作ることに注力したいから。
チケットの属性にあまりこだわらなくていい。
プロジェクトリーダーがあらかじめ決めておけばいい。

このフェーズでは、チケットの粒度が重要。
1チケットで担当者1人にアサインし、1チケットが平均2.5人日程度になるように細分化する。
つまり、1週間でチケット2枚を開発者1人が担当する。

1人月=8チケットぐらいのサイズ。
20人月なら160枚のチケットの規模になるだろう。

理由は、チケットを実装する工数が大きいと、進捗管理が難しくなるから。
開発者にとっても、チケットをこなす速度が上がれば、楽しくなるし。
プロジェクトリーダーは毎日、ロードマップでチケットの進捗率を見張っておく。

【3-2】結合テスト以降、そして運用保守時では、チケットの状態管理が重要だ。

この工程では、チケットはバグ修正や機能追加、仕様変更などの作業になる。
緊急のバグ修正のチケットなら、優先度=緊急で、マイルストーンは本番リリース日になるだろう。

いわゆる課題管理は、チケットの優先順位、つまり、どのチケットから順に消化していくか、という作業になる。
このフェーズでは、プロジェクトリーダーが細心の注意を払って、優先度やマイルストーンという属性を決めることになる。

また、チケットを解決のステータスへ変更する時、2人の担当者を経由させるか、最後にプロジェクトリーダーが必ずチケットを確認するような運用にする。

理由は、チケットの品質管理を徹底させるためだ。

特に本番稼動後のバグ修正や仕様変更では、デグレが許されない。
だからこそ、チケットを実装した開発者とは別に、テスト担当者にそのチケットを検証させる。
最後は、プロジェクトリーダーが実際にチケットを検証する時もあるだろう。


【3-3】チケットの運用方法は、プロジェクトリーダーの采配に大きく依存する。

Redmineには、チケットに経過時間という項目があり、これが実績に当たる。
レポートでは、見積もり工数と実績の比較を一覧に出す機能もあるらしい。

Redmineは複数プロジェクトにも対応しているので、見積もり工数と実績の工数を収集して蓄積できる。
そうすれば、ソフトウェアメトリックスらしき測定値を収集することもできる。

チケットを上手に運用できれば、ソフトウェア工学で習った知識を実際に現場で生かせるのだ!


【4】チケット駆動開発はXPの計画ゲームそのものだ

チケット駆動開発は、アジャイル開発に最も適しているように思う。
つまり、チケットはXPのストーリーカードやタスクカードに見立てることができる。

XPの計画ゲームは、1イテレーションで実現する機能をストーリーカードやタスクカードへ落として、下記の4つでコントロールする。
(By たけぷ~さん)

 ・T:時間
 ・S:スコープ(いわゆるストーリの数)
 ・R:リソース(開発者数/コストに相当)
 ・Q:品質

チケットの工数、作業内容、優先度は、まさに上記4つのバランスで決まる。

チケットの状態は、Redmineのガントチャート・カレンダー・ロードマップで可視化できる。
チケットはSVNリポジトリと連携できているので、要件定義からソースコードまで一貫してトレースできる。

上手に運用できれば、プロジェクト管理を効率化できるはずと思う。

| | コメント (0) | トラックバック (0)

RedMineでチケット駆動開発!

一昔前。
プロジェクトリーダーが2人日以上かけてExcelでガントチャートを作り、開発者に報告書を毎晩提出させて、実績と進捗を管理していた。
プロジェクトリーダーの仕事の殆どが、進捗管理に費やされていた。

プロジェクト全体で何%まで完成して、後どれくらい開発が残っているのか、理解するのに手間がかかっていた。
最終的には、プロジェクトリーダーの勘と経験で、リスク管理されていた部分が多かったのではなかろうか?

最近のWebシステム開発は、3~8人の開発者で3~6ヶ月単位のプロジェクトが多い。
短い期間で約10万行近くのシステムを作り上げるのが普通だろう。

これだけスピーディに開発しないとビジネスにならない現状なのに、プログラミングのスピードにプロジェクト管理が追いついていない。

最近思うのは、プロジェクト管理、進捗管理をソースコードに近づけることができないのか?という疑問。


プロジェクトの見える化がプロジェクトファシリテーション等で叫ばれている中、最近注目を浴びているものが、TracやRedmineのようなBTS。

RedmineはRuby on Railsで作られているからインストールも簡単だし、Tracよりも使いやすいように思う。

これらのBTSの最大の特徴は、ソースコードとチケット(作業タスク)を紐づけていること。

例えば、Subversionにコミットする時に

$ svn commit -m '○○○機能を利用時の△△△な問題を修正。 refs 123'

を実行すれば、RedMineに登録したタスクNo(ここでは「123」)と紐付けることができる。

RedMineに登録したタスクは、 開始日と終了日を設定すれば、ガントチャートがデフォルト設定されている。
進捗が遅れているか、後何日しかバッファがないか、すぐに分かる。

最近思うのは、プロジェクト管理や設計工程がプログラミング工程よりも遅くて、質が悪い。

その理由は、ソースコードの変化の速さに付いていけてないからだと思う。

やりたいのは、

チケット駆動開発

略してTiDD なのだ!

RedMineによるチケット駆動開発について、色々考えてみたい。

| | コメント (0) | トラックバック (2)

Javaで型推論をプログラミング

Javaの型推論Utilsクラス」の記事から。
Javaでも型推論できるのか~。

でも、C言語のように、やたらとカッコ付きの型キャストが多い。
Scalaの方がいいのだろうか?

| | コメント (0) | トラックバック (0)

2008/04/13

【感想】第25回Ruby勉強会

大阪国際大学で開かれた第25回Ruby勉強会の感想を書く。

【1】JavaEEでRailsを動かす

紅月さんの講演
一番興味があった。

理由は、ファウラーの下記の記事「ファウラーがRubyに抱く感慨」が気になっていたから。


(前略)若いテクノロジーには新しくて重要な特筆すべき点がいくつもある。だが、私にとって最も重要なのは、JRubyだ。現在、JRubyは最終的なRCの段階だ。 Java VM上で動くスクリプティング言語を提供するだけでなく、 Rubyプラットフォームの完全な実装をJVM上で行おうとしている。 ThoughtWorksで我々が行っていること、そして、多くのRuby/Rails開発者たちにとって、(たとえ"include java"をしたことがなくても)これはかなり重要なことである。

我々のRubyチームが開発中に直面した最も大きな問題はデプロイだ。 Rubyのアプリケーションを実践投入するには、非常に多くの新しいテクノロジーが必要となる。それに、データセンターはこういったことに保守的だ。我々のRubyWorksもこの点をシンプルにしようと努力している。 JRubyはこの点について、Javaコンテナにデプロイすればよいので、 Railsアプリケーションもwarファイルとして簡単にデプロイできると主張している。これにより、Ruby on Railsが多くのエンタープライズ環境における選択肢となる得るのではないかと私は思っている。(後略)


Rubyはスクリプト言語なので、プログラムそのものがアプリケーション。

でも、本来、プログラムの目的は、実行可能なバイナリモジュールを作ることにある。
Cobol、C/C++からJava、C#へ至るプログラミングの歴史と同じぐらい、ビルドの歴史も長い。

例えば、Windowsアプリは、小さな実行モジュールであるexeファイルと、複雑な業務ロジックや共通ライブラリを分離した複数のDLLから構成されるのが普通。
その思想は、プログラムを論理的に分割するだけでなく、物理的にも分割し、複雑性を制御しようとする所にある。

同様に、JavaのWebアプリも、war/earファイルという一つのWebアプリをAnt/Mavenでビルドして作る。
warファイルの構成は、JSPなどのViewがrootの直下に配置される。
Controllerが含まれるWEB-INF。
そして、複雑な業務ロジック、共通ライブラリは複数のjarファイルへ分離する。

Windowsアプリと同じく、この設計思想も、複雑なプログラムを物理的にjarファイルへ分割するやり方に受け継がれている。

だから、RubyやRailsの弱点はビルド&デプロイにあるのではないか?というファウラーの指摘は的を得ている気がする。

紅月さんが紹介してくれたやり方の発想は、下記の仕組み。

Rails(warファイル)

JRuby

RailsServlet

Servlet Container(Tomcat等)

JVM

つまり、RailsServletがRailsをServletコンテナにラッパーして、Tomcat上で動かせるようにする。

RailsをTomcatで動かす利点は、JavaのWebアプリケーションサーバーは枯れた技術で性能もいいから。
Tomcat上でRailsが動けば、JBossを初めとして、WebSphere、WebLogicのような大規模なJavaのWebアプリケーションサーバーでも動作可能になるだろう。
そうなれば、より大規模で複雑なWebアプリをRailsで作ることが容易になるだろう。

紅月さんのデモはうまく動作しなくて残念だったけれど、この思想はファウラーの指摘以外にも、もう一つの重要な指摘を含む。

それは、JVMがインフラであること。
JDK6以降では、JRubyだけでなくJavaScriptのような殆どのスクリプト言語がJVMで動作可能になっている。
つまり、JVMさえあれば、RubyもPythonもJavaScriptも動いてしまうのだ。

最近は、Scalaのような関数型言語さえJVMがあれば動作する。
このScalaは、Liftという興味深いWebフレームワークもあるようだが。

実際はパフォーマンスもあろうが、特にWebシステムはスケールアップしやすいので、近い将来、JVM上でRailsを動かすのも実用的になるだろう。

まだ、Tomcatの上でRailsを動かすのは不安定だが、要注目の技術だと思う。

【2】角谷さんのRSpecライブコーディング

 角谷さんは本来、関西人だったそうで、ライブコーディングでは関西弁が随所に出て、聞いていて楽しかった。
 僕自身はJUnitに慣れているので、RSpecよりもRubyのTestUnitの方が理解しやすい。
 yu-yaさんに尋ねたら、TestUnitの方がassertEqualsだけで書けるので簡単ですから、と言っていたのが印象的だった。
 
 角谷さんが、ユニットテストのプログラミングの重要性を下記の図で説明した。
#縦軸:ソースの綺麗・汚い
#横軸:プログラムが動く・動かない

┌─────┬───┐
│       │     │
│ お花畑  │理想  │
│       │     │
├─────┼───┤
│       │     │
│ 終了   │現実  │
│       │     │
└─────┴───┘


 つまり、理想は、綺麗で動くプログラム。
 でも、現実は、動くけれど汚いプログラム。
 
 綺麗だけれど動かないプログラムは、お花畑。
 汚くて動かないプログラムは、既に終了している。

 角谷さんによると、リファクタリングとは、終了→現実→理想へのルート。
 
 池上さんは、終了→お花畑→理想 のルートもないだろうか?と質問していた。
 角谷さんによる明示的な回答はなかったけれど、数学者である池上さんらしい指摘。
 Haskellはまさに、コンパイルが通れば確実にバグなしで動く。
 Haskellは、終了→お花畑→理想 のルートなんだろうな。

 今日のRuby関西は、Flexユーザーグループ関西の夜桜と重なり、ちょっと人が少なかったのが残念。
 でも、懇親会、2次会も盛り上がって楽しかったです。

 ちなみに、角谷さんの本にサインしてもらいました。
 角谷さんの本は下記が有名かなぁ。


| | コメント (0) | トラックバック (0)

2008/04/11

ビルドのアンチパターン

ビルド環境について良い解説があったのでメモ。

万人のためのオートメーション: 継続的インテグレーションのアンチパターン、第 1 回
してはいけないことを学んで継続的インテグレーションを円滑に進める

万人のためのオートメーション: 継続的インテグレーションのアンチパターン、第 2 回
してはいけないことを学んで継続的インテグレーションを円滑に進める

ビルド環境で重要なことは、コンパイルを通すこと。
当たり前のことだが、複数人がシステムを触るから、ライブラリの依存関係などで、コンパイルエラーが発生しやすくなる。

注意点の一つは、ビルドを通すための頻繁なコミット。
1日の最後に一気にコミットしたら、ビルドエラーが頻発したという事象はありがちなケース。

もう一つは、ビルドを午前中のように、早めにビルドすること。
夕方にビルドして失敗した場合、皆で残業する羽目になる。

ビルド環境でいつも検証可能とするには、運用ルールが鍵を握る。
つまり、プロジェクトリーダーが力を発揮しやすい所。
そして、プロジェクトの進捗が前進するための最も重要なプロセスに当たる所。

ビルドのノウハウはもっと研究の余地がある。

| | コメント (0) | トラックバック (0)

2008/04/10

SIerの俺様フレームワークは最悪に激しく同意

下記の記事に激しく同意する。

SIerの俺様フレームワークは最悪だ

日本のパッケージ製品を作っているベンダーは、基本的に、自社のフレームワークで作りこんでいる。
そのフレームワークのルールを覚えるコストは、プロジェクトメンバーが増えるほど膨大になる。
コミュニケーションコストがすごく高い。

オープンソースのフレームワークならば、本で紹介されていたり、ネット上でノウハウが公開されていたりする。
少なくとも、RailsやStruts、Seasarなどのように有名なフレームワークほど、使いこなしている人も多い。
覚えれば、他の会社、他のプロジェクトでも応用できるので、コミュニケーションコストは低い。

だが、コミュニケーションコストよりも、保守性のコストの方がはるかに大きい。
下記の指摘はあまりにも的確だ。

フレームワーク自体に問題があった場合も最低だ。オープンソースならば自分で直すのも良し、バグ報告して直してもらうのも良し。しかしSIerフレームワークの場合、契約上の問題でフレームワーク自体を修正できなかったり、そもそもソースが無いので修正不能だったりする。バグ報告しても修正は期待できない。非常にダーティな手段でバグを回避するしかなくなり、ソースコードの保守性がどんどん下がっていく。

バグがあると分かっているのに、直せない。
その理由は契約上だったり、ソースそのものが公開されてないことだったりする。

結局、自前のライブラリを作ったり、無駄なラッパー機能を作ったりする。
最終的には、誰もその部分を触れなくなる。

製品よりもフレームワークという抽象化された設計思想に近いものほど、ソースを公開して欲しい。
設計思想こそ、全ての人の共有資産なのだ。

| | コメント (2) | トラックバック (0)

2008/04/09

プログラマにとって人生で一番悲しい言葉、そしてプログラマの権利

XPエクストリーム・プログラミング導入編 ― XP実践の手引き」の一節にこんな文章がある。
この文章に共感するプログラマは多いのではないか?

「がんばってみます」
We'll try
という言葉はプログラマにとって人生で一番悲しい言葉となる可能性がある。
私たちの殆どは、これまでにこの言葉を一度以上、口にしたことがあるだろう。


プログラマなら、下記の状況に陥ったことがあるだろう。

スケジュールを見ると、どうやっても無理っぽい。
技術的に難しくて無理っぽい。
あいまいな仕様で作るのは無理っぽい。

なのに、プログラマはプロジェクト後半でこの言葉を何回使うのだろう?
その言葉の責任を果たすために、残業し、休日出勤し、徹夜作業し、帳尻を合わせる。

そして、プログラマは心身ともに疲弊する。
何か間違っていないか?

XPエクストリーム・プログラミング導入編 ― XP実践の手引き」には、プログラマの権利という一節がある。
プログラマを勇気付けさせてくれる言葉なので、ここに書いておく。

プログラマの権利

【1】プログラマには、何が必要とされているのかを明確なプライオリティとあわせて知る権利がある。
【2】プログラマには、常に質の高い仕事をする権利がある。
【3】プログラマには、同僚や上司、顧客に助力を求め、それを受ける権利がある。
【4】プログラマには、自ら見積もりを行い、またそれを更新する権利がある。
【5】プログラマには、責任を割り当てられるのではなく、責任を自ら引き受ける権利がある。


デスマーチプロジェクトに陥った時、プログラマも当然巻き込まれる。
その時、プログラマは、その状況に対して異議申し立てする権利がある。
抗議するだけでなく、状況を改善し、プロジェクトを成功させる権利も含んでいる。

自らのタスクが多すぎて右往左往した時、同僚や上司、顧客に助力を求め、それを受ける権利がある。
自らのタスクの優先順位を明らかにする権利がある。
自らのタスクを見積もり、それを更新していく権利がある。

そして、自ら責任とリスクを引き受ける権利がある。

プロジェクトファシリテーションの究極の目標は、Quality of Engineer Lifeを高めること。
XPはその目標を実現するためのテクニックの一つとも言える。

XPには、プログラマを勇気付けてくれる言葉、テクニックが散りばめられている。

| | コメント (0) | トラックバック (0)

2008/04/07

ハムスターDBはSQLLiteの代わりになるか?

ハムスターDBが可愛い(^^♪
SQLLiteのように、お手軽なDBとして使えるだろうか?

| | コメント (0) | トラックバック (0)

プログラマはスロースターター

StatSVNは、Subversionにコミットしたソース情報から、各種統計を出力する。
その統計情報を見ていて、一つ気になったことがあった。

各開発者がコミットしたソース量を曜日別に並べたグラフ。
よく見ると2パターンある。

一人は水曜に山が来るパターン。
もう一人は金曜に山が来るパターン。

後者は、金曜の山の後、土曜も同じぐらいのコミット量がある。
つまり休日出勤でカバーした事実がそのまま現れている。

前者は当然、土曜はコミット量がゼロなので休日出勤していない。

実は、前者も後者も同じぐらいのコミット量なのだが、開発のスタイルが違う。

前者はエンジンがかかるのが早い。
月曜からしばらくは、落ちてきた仕様を理解したり、内部設計をしているのだろう。
そして週半ばに機能の実装とユニットテストの大半を通す。
週後半は、漏れていたテストケースを追加したり、仕様変更や細かなバグ修正をしたり。

IT業界にいて不思議なのは、殆どのプログラマはエンジンがかかるのが遅い。
何故か午後4時頃になって急激に活動し始める。
そして夜8時まで、活動のピークが続く。
同様に、木曜、金曜になるにつれてペースが上がってくる。
そして休日出勤する人が多い。

プログラマはスロースターターな人が多いのだろうか??

| | コメント (0) | トラックバック (0)

2008/04/05

最近はプログラマの影響力が大きくなっている

最近のWebシステムの開発の現場で気づいたこと。
システム開発の現場でプログラマの影響力が大きくなっている気がする。

現在は、入社1年目の新人プログラマでも、3ヶ月で軽く数万行のプログラムを書いている。
優秀な人であるのは分かっているが、数年前には信じられない状況だ。

数万行のプログラムの中身は、フレームワークが自動生成したソースやユニットテストが半分以上占める。
でも、それらのプログラムの整合性を取りながら、一つのWebシステムを曲がりなりにも動かしている事実がある。

以前よりも、大規模なシステム開発が少人数のチームで可能になったのは確かな事実だと思う。

その開発環境を支えているものは何か?
3つあると思う。

【1】フレームワークの威力が上がった

RubyならRails、JavaならS2Sruts/S2daoを使えば、DB層からWebのControler/Viewまで、CoCに従って簡単に書くことができる。
特にDB層は、ルールに従えば、自動生成してくれる。

フレームワークがプログラムの論理的整合性を大部分吸収している。
だから、ルールさえ覚えれば、業務ロジックに専念すればいい。

更に、ユニットテストもフレームワークが提供してくれている。
RailsもSeasarも、ユニットテスト用のディレクトリが既に確保されている。

特にDB層や共通ライブラリは、ユニットテストをプログラミングすれば、最低限の品質は確保できる。
仕様変更があっても、ユニットテストのプログラムがあるから、回帰テストで以前の機能が正しく動いていることも確認できる。

ユニットテストの重要性は、回帰テストでデグレを防止できることだけでなく、JDKやRuby、Tomcat、RDBのバージョンUpのような開発環境そのものが変わっても正しく動くことを保障できる所にあると思う。
システムのハード面のスケールアップにも、ユニットテストが大きな威力を持つ。

【2】無料で使いやすい開発環境の普及

JavaならEclipse、Rubyならemacsやvi、最近ならNetBeansで開発するのが普通だろう。

昔なら、MSのVisualStudio、IBMのVisualAge for Javaのような統合開発環境は高価で、誰もが自由に扱える存在ではなかった。
また、バージョン管理システムも、MSのVSSぐらいしか使い物にならなかった。

でも、JavaではEclipseが2002年以降急激に普及してから、山のようにオープンソースライブラリが増えて、より開発しやすくなった。

バージョン管理システムはSubversion、ビルドツールはAntやMaven、WebアプリケーションサーバーもTomcatやJBossのように、色んなツールが無料で、しかもかなり品質もいい。
ノウハウもネット上にいくらでも転がっている。

一度、開発環境を整えることができれば、新人のプログラマでも、環境の細かな使い勝手を考えずに、プログラミングだけに専念できる。


【3】アジャイルな開発プロセスの普及

Webシステム開発なら、常時ビルド環境はもはや当たり前。
だからこそ、いつでも検証できるし、頻繁なリリースも可能。

テスト駆動開発、リファクタリングというアジャイル開発の基本テクニックも、Eclipseを使ううちに自然に身に付く。
テストを通すようにプログラムを書く帽子、そして、テストが通ったプログラムをリファクタリングで綺麗にする帽子を切り替えることも、数万行近いプログラムを書くうちに、さすがに自然に分かってくる。

また、プロジェクト管理もTracやRedMineのようなWebベースのツールを使うプロジェクトが多くなった。
この部分はまだ洗練されていないと個人的に思うが、少なくとも、カレンダーで開発スケジュールを全員に周知させたり、BTSのようにバグ報告フローを管理するツールはすごく有効。
また、コミットしたソース量を毎晩レポートしてくれるツールがあるおかげで、誰がどれくらい頑張っているか分かる。

今回、数万行も書いている事実は、statSVNのおかげだ。

【今、問われる問題点とは?】

そんな開発スタイルで問われる問題点は、プログラマとしての基本的な技術力だと思う。
例えば、、

・可読性は高いか?
 クラスやメソッド、変数の名前が分かりやすいか?
 きちんとインデントしているか?
 無駄なコメントアウトしたソースがないか?
 JavaDocをきちんと書いているか?

・後から機能追加しやすいように保守性を気にしているか?
 きちんと論理的に分割できているか?
 無駄なフラグは多くないか?
 IF文が3個以上ネストしていないか?
 無駄なローカル変数が多くないか?

・きちんとユニットテストを書いているか?
 カバレッジは100%ですか?
 テストしやすいソースを書いてますか?

などなど。

つまり、保守性や可読性の高いプログラムを意識して書いているか?
一度、本番稼動いているプログラムは、たとえ可読性が悪くとも、たとえユニットテストやリファクタリングの技術があっても、修正するのはすごく難しい。

簡単にプログラムが書けてしまう時代だからこそ、プログラミングの基本スキルそのものが問われているのだと思う。

| | コメント (0) | トラックバック (0)

2008/04/02

システム開発から属人性を排除しようとして失敗する

ひがさんの記事「「誰が書いても同じコード」は大事なことなのか」を読んで思ったことを書いてみる。

大手SIerは独自の重量級の開発プロセスを持つ。
それは多分、メインフレーム+Cobol時代の開発プロセスを最近のオープン系に焼き直したものに過ぎない。

その現場のプロジェクトは大規模で人数も多いから、少数精鋭チームで自由に動くわけにはいかない。
その開発プロセスの意図は、誰が作業しても同じような品質を保つ所に重点を置く。
つまり、属人性を排除しようとする。

だから、できない人もルーチンのような作業までレベルアップするが、できる人は、無駄なドキュメント作成やマネジメント、そして古臭くなったコーディング規約などの運用ルールに縛られている。

彼らのプロジェクトはタンカーのように、一度動き出したら進路を変えるのは凄く難しい。

現在の特にWebシステム開発では、頻繁なリリースによるバージョンアップが多い。
その間隔は短ければ1週間単位。
開発者からすると、永遠のベータバージョンのシステムを作っている感覚だ。
丁度、mixiやGoogleが生み出すサービスに似ている。

そんなビジネスでは、開発のスピードが最重要。
だから、重厚長大なドキュメントや運用ルールで開発者を縛るよりも、ある程度の規律の下では開発者の自由に任せることが多いだろう。
現場でも、プログラマに要求されるスキルは高くなっていると感じる。

実際、昔のように、部品単位でモジュールを作るスタイルではない。
水平なレイヤー単位の開発スタイルではなく、機能単位に垂直に開発するスタイル。
システムは、機能単位に漸進的にリリースしていく。
つまり、細かな機能単位でバージョンアップしていく。

一機能を作るための全てのモジュールを、プログラマが責任を持ってプログラミングする。
だから、プログラマは、DB層からコントローラー、Viewまでのプログラミング、そしてAjaxなど、多様な技術力が要求される。

だからこそ、開発者が力を発揮しやすいように、アーキテクチャの部分は全ての開発者が設計思想を共有するがそれ以外の部分は、全て任せることが多い。
そして、設計者やプロジェクトマネージャは、顧客と開発者のインターフェイスに当たる作業に徹する事が多い。
彼らは、要求を収集し、論理的整合性を計り、開発者へ仕様を渡す所までに徹する。

それは、XPに似た開発スタイルと言える。
最低限のコーディング規約は守るが、スピード感のある開発スタイルを守る。
そのために、コードの共同所有、常時結合できるビルド環境、イテレーション単位の機能リリースなどを行っている。

そして、そんな開発プロセスは、プログラマの技術力に大きく依存する。
属人性を排除するのとは逆なやり方。
だからこそ、プログラマが生き生きと働ける環境にするのが大事。

大手SIerのやり方は多分、時代にマッチしなくなっている。

| | コメント (0) | トラックバック (1)

« 2008年3月 | トップページ | 2008年5月 »