• BPnet
  • ビジネス
  • IT
  • テクノロジー
  • 医療
  • 建設・不動産
  • TRENDY
  • WOMAN
  • ショッピング
  • 転職
  • ナショジオ
  • 日経電子版
  • PR

  • PR

  • PR

  • PR

  • PR

連載 Web 2.0時代のソフトウエア開発手法

第6回 アジャイル開発でタイム・ボックスを決める---TRICHORDの開発現場から

2006/04/12 ITpro

 前回までの平鍋からバトンタッチして,今回から懸田が本連載を担当する。筆者は平鍋が代表を務めるチェンジビジョンで,プロジェクトの見える化ツール「TRICHORD(トライコード)」の開発を担当している。以下では,TRICHORDの開発を例に,Web 2.0時代の軽量開発について具体的に考えていく。

 TRICHORDは,先の4月3日に最初の公開版であるバージョン0.1をリリースした(図1[拡大表示])。TRICHORDは本連載で提唱したコンセプト・アウト/デマンド・イン型の開発プロジェクトとなっている。まだ完成していない状態でプロダクトを世に送り,利用者にそのコンセプトを問うて,フィードバックをもらいながら,プロダクトを育てていこうとしている。


図1 TRICHORDの画面
2006年4月に最初の公開版であるバージョン0.1をリリースした。現時点ではごく基本的な機能しか実装していない。

[画像のクリックで拡大表示]

 Web 2.0時代のソフトウエア開発では,生産性の高い開発環境を使って,少人数のスキルの高いプログラマが短期間で動くソフトウエアを作ってしまう,というのが典型的な開発の進め方である。「少人数」という中には,「1人のハイレベルなプログラマが一気に作ってしまう」という意味も含まれると思うが,ここでは,あくまでもチーム開発として話を進めさせていただく。開発環境には依存しない,「小人数」「早期リリース」「変化に対応する」といった観点から見ていきたい。

アジャイル型の開発プロセスを採用

 前回,コンセプト・アウト/デマンド・イン型のプロジェクトの特徴として以下の7つを挙げたのを覚えているだろうか。

(1)要求がめまぐるしく変わる(3カ月前の要求が今も有効かどうか,疑わしい)。
(2)リリースごとのテーマと締め切りを守ることが最優先。スコープ(機能)は削ってもよい。
(3)開発は少数精鋭。チームは10名以下であることが多い。
(4)若い企業文化(モチベーションと成功意欲が高い)。
(5)継続的にバージョンアップを繰り返す(必然的なイテレーション型)。
(6)コミュニティからのフィードバックを得るとともに,開発の進ちょく状況などをトランスペアレントに外に発信。
(7)チームの生産性のためには,ソフトウエア資産の「再利用性」ではなく「保守性」が重要。

 TRICHORDは,これら7つの特徴を見事に備えている。そのため,前回説明したアジャイル型の開発スタイルを選択し,タイム・ボックスを区切ってフィーチャをイテレーティブかつインクリメンタルに開発している。

4つの変数の優先度を決める

 ソフトウエア開発プロジェクトには,4つの基本的な変数がある。「コスト」「時間」「フィーチャ(機能)」「品質」だ。プロジェクトの開始時には,これら4つの変数の優先度を決定しなければならない。

 コンセプト・アウト/デマンド・インでは,「コンセプトを動くソフトウエアに乗せて早くリリースする」ことが,何よりも重要になる。そのためには,「時間」が最も重要視される。言い換えれば,期限は固定されることになる。

 次に残りの変数の優先度を決める。大抵の場合は,「コスト」が2番目に重視されるだろう。つまり,リソースを固定して開発することになる。

 「品質」は最も基本的ではあるが,短い期間,例えば3カ月の期間の中で,どの程度の時間とコストをかけてテストするのかは難しいところだ。品質は,ほかの変数に依存することになる。そのため、品質を作り込んでいくことが重要になる。

 そして,最後に残るのが「フィーチャ」である。時間,コスト,品質に対する要求を決めたうえで,それに応じて(実装可能な)機能が決められる。結局のところ,タイム・ボックスという箱には,箱の容量を超えるフィーチャは入らないのだ。

タイム・ボックスを決める

 タイム・ボックスを決める際にはまず,リリースまでのタイム・ボックスを決める。TRICHORDでは,2005年末にタイム・ボックスを決めた。一番大きなタイム・ボックスは,2006年1月から2006年12月までの1年間の箱だ。その大タイム・ボックスを分割して,リリース単位のタイム・ボックスを決める。当初は四半期リリースとしたので,最初のタイム・ボックスは2006年1月初めから2006年4月初めまでの3カ月の箱になる。

 次に,一番小さなタイム・ボックス,つまりイテレーションのサイズを決定する。TRICHORDの場合は,1週間,つまり5日を最小のタイム・ボックスとした。1月から4月までの3カ月間には,イテレーションの箱が12個できた。

 タイム・ボックスを決めるということは,「時間は動かさない」と宣言することにほかならない。つまり「リリースを2日遅らせる」といったことはあり得ないし,あってはならないのだ。「リリースに間に合わない」のではなく,「あるフィーチャを次に回してリリースする」という姿勢が基本である。


懸田 剛

チェンジビジョンでプロジェクトの見える化ツール「TRICHORD(トライコード)」の開発を担当。デジタルなハックと,アナログなハックの両方を好む。新しいやり方やツールを考えるのが好きである。個人サイトは http://log.giantech.jp/

あなたにお薦め

連載新着

連載目次を見る

今のおすすめ記事

ITpro SPECIALPR

What’s New!

経営

アプリケーション/DB/ミドルウエア

クラウド

運用管理

設計/開発

サーバー/ストレージ

ネットワーク/通信サービス

セキュリティ

もっと見る