無料ブログはココログ

« 2009年7月 | トップページ | 2009年9月 »

[TiDD] 小規模開発の難しさを考える

もう20年以上前になりますが、私がソフトウェア業界に就職したとき、最大10人程度の小規模プロジェクト(当時は間違いなくそういわれていました)に配属されました。

当時はいかに大規模開発を管理するかと言うことが注目されていて、各社で開発標準が決められつつあったころです。当時、小規模プロジェクトの管理はあまり注目されていませんでした。大規模プロジェクトが不採算になると会社がつぶれますが、小規模プロジェクトの不採算なら何とか耐えられたようです。

大規模プロジェクトが難しいのはだれもが認めるところでしたが、小規模プロジェクトにもそれなりの難しさがあり、当時、それはなぜか、どうすればよいか、と考えていたことを覚えています。

時代は移り、大規模プロジェクトではプロセス改善に費用をかけることで、比較的安定した開発が行われるようになりました。特にTSP/PSPでは階層的な管理が行われ、個人からチームへと積み上げによって高い精度で定量的な見積もりと管理ができるようになりました。プロセス改善を進める企業においては、その枠組みに入りきらないようなプロジェクトが企業の利益を圧迫するとまで言われています。

一方、小規模開発に関しては、アジャイル開発があるものの、高い能力を持つ技術者が必要とされていて、全ての小規模プロジェクトを救えるかどうか、難しいところです。

さて、ここで小規模プロジェクトはなぜ難しいかを考えて見ます。規模の大小にかかわらず、外部環境の変化による業務要件の変更、外部仕様の決定遅れ、ミドルウェアなどの開発基盤により生じる問題、は同じように発生します。

リスクは一般に問題の大きさとその発生確率で表現されます。大規模プロジェクトでは、それらを乗じた予算をあらかじめ用意しておくことで、問題が発生しても解決できます。これはリスクが統計的に扱えるほどに、プロジェクトの規模に比して小さいからです。

小規模プロジェクトあるいはプロジェクトの規模に比べて大きなリスクの場合は、問題が発生することで危機的な状況に陥ります。品質低下、予算超過やスケジュール遅れ、といういわゆるQCDが守れなくなるからです。

リスクが問題化したプロジェクトを健全な状態に戻すには、
(1)発生している問題をきちんと把握する
(2)優先順位を決めて作業手順を定める
(3)全ての問題を確実に解決(あるいは対処)する
ということが実施できなければなりません。

これは、まさにチケット駆動開発(TiDD)が支援することです。ソフトウェア開発集に生じた問題や予定していない作業をすべてチケット化し、優先順位を決めて、確実に作業する、TiDDのプロセスそのものです。

このように考えると、TiDDは小規模プロジェクト、特に、仕様変更の多いプロジェクト、細かな仕様が多いプロジェクト、予想外の問題や作業がが生じやすいプロジェクト、に向いていると言えるでしょう。

[TiDD] プラクティスから方法論へ

「チケット駆動開発」というキーワードで検索すると、名古屋で勉強会が開かれていたり、実際の仕事で試されている方がおられたり、色々なところで注目されていることがわかります。

そんな中で気になったのが、「チケット駆動開発の研究と実践」(livedoor 開発Blog)です。ここでは、チケットによる見える化や達成感というメリットのほか、こんなデメリットも書かれています。

「チケットを発行するときは楽しいのですが、クローズしたりステータスを変更するときはチケットが多いほど手間がかかります。」

そして、管理者をつけたほうが良いとのこと。確かに、たくさんの作業を見える化できることがTiDDの特長ですが、管理作業そのものは従来と同じですし、全体の状況となるとチケットを容易に増やせる分だけわかりにくくなるかもしれません。

実は関連する議論をしたことがあります。題して「TiDDは方法論か、プラクティスか」。アジャイル開発やテスト工程などでTiDDをプラクティスの一つとして用いるならば、大きな効果を挙げると思います。しかし、方法論として考えると、チケット駆動開発の基本である「チケットなしではコミットを許さない」というルールだけでは規模が大きくなると開発できません。

そのような現実から考えると、厳密にはTiDDはプラクティスと言えると思います。では、みなさんはどうされているかというと、あきぴーさんなどは上流はウォータフォール、製造はアジャイルをベースにTiDDを用いられているようです。

では、あきぴーさんの開発方法はTiDD開発方法論であるかというと、そうでもあるし、そうでもない。本人がそうだといえばそうなるのかもしれません。しかし、詳細が定まっていないものを方法論というのもおこがましいので、私とあきぴーさんで外部発表した際には「TiDDをアジャイル(あるいはXP)に適用した」という表現を使っています。

方法論とするには、いくつかの定義が必要だからです。具体的には

チケットの管理の方法:ワークフローの一般化。役割と作業の詳細な定義が必要です。また、チケットの統合や分割の定義も必要です。

作業の管理:チケットと紐づいた作業を日々どのように管理するか。作業が増えた際にどう管理するか。

要件あるいはストーリカードとチケットの関係:チケットをXPのタスクカードとするならば、ストーリーカードはどうなるのか。何らかの参照が必要なことはわかりますが、具体的な方法を示さなければなりません。

ほかにも色々あると思います。実際には、現実のプロジェクトが目の前にあるのですから、色々工夫をしながら具体的な事例積み重ねることだと思います。そしてそれらを元に、まとめていければと思っています。

(事例の提供者おられませんか?もし、論文を書きたいのなら、お手伝いならしますよ~)

« 2009年7月 | トップページ | 2009年9月 »