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

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

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

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

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

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

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

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

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

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

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

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