アジャイル開発におけるプロセスの洗練：アジャイル実践者インタビュー（2）（1/3 ページ）

[畑田成広, 塩田英二, 水越明哉，アジャイルプロセス協議会 ケーススタディWG]

　第1回（「発注者はアジャイル開発をこうみている」）に引き続き、アジャイルプロセス協議会「ケーススタディ ワーキンググループ」の活動として、実際にアジャイル開発手法を実践しているプロジェクトへインタビューした内容を紹介する。今回インタビューしたプロジェクトでは、XPやスクラムといった既存のプロセスから離れて、自らのアジャイルプロセスを組み立て洗練させながら開発を行っている。アジャイル開発が常にプロジェクトを改善し、進化していく様子を感じていただけるだろう。

メンバー紹介

　インタビューは以下の人々に行った。

TIS倉貫氏	プロジェクトリーダー。アジャイル開発経験者
TIS竹内氏	業務チームをまとめるサブリーダー。アジャイル開発は初めて
TIS吉尾氏	業務チームでスペックホルダ（後述）を行う
TIS中井氏	開発チームで開発を行う

プロジェクト概要

　このプロジェクトではWebを使った業務アプリケーションを開発した。期間は6カ月、初めは10人でスタートし、ピーク時の人数は17、8人だった。若手が中心で、アジャイル開発が初めてのメンバーがほとんどである。プラットフォームはJ2EE、OSはLinux、データベースはOracle、アプリケーション・サーバはTomcat。StrutsとHibernateとSpringフレームワークを使用している。HibernateとSpringに関しては社内で調査していたので、技術者はそろっていた状態だった。

実践したプラクティス

　このプロジェクトではXPやスクラムといった既存のプロセスを意識せず、自分たちなりにアジリティを持って開発していくにはどうすればいいかということを考え、プロジェクト前にプロセスの組み立てを行った。イテレーションは2週間で、以下のようなプラクティスを実践した。XPに含まれているプラクティスもあれば、まったく新しいプラクティスもある。また、プラクティスに問題があれば解決策を考えてより良いプラクティスに洗練していくという姿勢にも注目していただきたい。

スペックホルダ

図1 顧客プロキシ

　以前にプロジェクトリーダーが携わった開発では、顧客側の仕様をまとめるために顧客の業務に精通した顧客プロキシ（疑似顧客）を1人置いていた。しかし、開発後半になり機能が大きくなってくると顧客プロキシの負担が大きくなり、1人では難しくなっていた。

図2 スペックホルダ

　今回のプロジェクトでは仕様をまとめる負担を分散させるため、顧客プロキシを進化させたスペックホルダというプラクティスを考案し実践した。まずプロジェクトを業務チームと開発チームに分ける。業務チームはさらに2つ（Aチーム、Bチーム）に分かれ、Aチームが顧客のところに行って仕様確認をしている間、残りのBチームは顧客から握ってきた仕様を基に開発チームと開発を行う。AチームとBチームは1イテレーションごとに入れ替わり、仕様確認と開発を同時並行して進めていく。

　顧客プロキシに比べて、スペックホルダでは仕様確認が交互に行われるため負担は分散される。また、開発チームにとってはチーム内に顧客の仕様を持っている人が存在するため安心感がある。

　しかし、スペックホルダを実践しているうちに課題も見えてきた。