アジャイルもどき手法の開発事例

事例の紹介

実際にアジャイルもどき手法で開発した例を紹介します、この開発はインターネットを利用した時刻表検索システムです。複数の会社の時刻表をインターネットで統合的に案内しようというものです。
この開発の最大の問題点は、時刻表の元データがどのような形で集められるかまったくわからないことでした、時刻表の元データを持った各会社に参加の勧誘をしながらの開発になり、しかも、開発期間は５ヶ月、かなり厳しい開発でした。
当初は、参加各社の参加の意思が決まってから、どのようなデータを持っているかをヒアリングし、それから開発に入る計画でした、ところが、事業計画の関係でそんな悠長なことは言っていられないとなり、トップの一声でいきなり立ち上げが前倒しになり、各社に参加の勧誘をする期間を含めて開発期間が５ヶ月となりました、つまり当初の計画では、各社のデータ構造が分かったころの予定だった時期に、立ち上げなければならないのです。

基本設計

私の課のメンバーは係員３名、係長１名、課長（私）1名です、この内プログラムが作れるのは私を含めて３名です。
まず基本設計を私がやります、集められるデータ構造がまったくわからないので、あらゆるケースに対応できなければなりません。
考えに考えて設計しました、しかし、実際の設計文書としては、ファイルやメモリーの構造を決める構造体が書かれたヘッターファイルを書きました（各部に細かく注釈を入れました）、基本設計の文書はこれだけです。
そのヘッターファイルを元に、あとの２人に説明します、裏紙にぐしゃぐしゃと説明を書きます。（確かに、よくこんなもので、この２人は何を作るのか分かったと感心します、ここはもう少し文書を書くべきかもしれません）
作るものの説明が終わったら、分担を決めます、分担した部分は担当した人が設計から開発まで全部やります。
次に開発環境を準備します、開発にはCVSを改良（改悪？）したものを使います、各人が自分固有の開発環境を持ち、マスターの開発環境と連携します。

開発

環境ができたら即開発スタートです、思いつくままに作っていく感じで作っていきます、（かなりひどいことになると思うでしょうがそれがうまくいきます） 開発はパーツを作ったら必ずテストします、目的のプログラムを作るのと平行してテスト用のプログラムも作ります、プログラムは作っている時も必ず動くようにしておきます、これは極めて大事です、開発の極めて初期の段階からシステムを動かしながら作っていくのです、設計のいい加減さをこれでカバーします。
プログラムが出来るとすぐにマスター環境にアップします、また誰かが新しいプログラムをアップしていればそれを自分の環境に取ってくればより進んだテストができます、（つまり結合テストをかなり初期の段階から行います）テストしてうまく動かない場合は原因を探しますが、その時、他人のプログラムも調べます、間違いがあれば間違いを教えて作り直してもらいますが、簡単なミスならこちらで修正してマスターにアップしておきます、つまり、他人が作ったプログラムにも目を通しながらの開発になります。これも極めて重要です、思わぬ思い違いを防ぐことができます。
開発が進むと早い人と遅い人がでます（有能、無能ではなく、思いのほか手こずって遅くなることがあります）そんな時 遅れている人の担当部分を早い人に担当変更します、だから他人の担当部分がいやでも分かるようになります。
仕様変更は頻繁にやります、作ってみないと分からない部分が沢山あるからです、作ってみてこれはまずいと思ったら即仕様変更です、特に各社のデータ構造は元々分からなかったのですから、分かった時点で仕様変更です、仕様変更は必ず全員でミーティングをし、仕様変更の必要性やどう変更するかを確認し合います。

各社への説明

まず、参加を予定している各社への説明会を実施します、説明会の資料も作ります、資料はこの時点でこちらが想定している元データのデータ構造を元に作ってあります。
しかし、説明会を開いてみると計画とは大違いである事が判明、結局各社のデータ構造に合わせて仕様を基本から変更です。

時刻表部分の開発

各社のデータ仕様がわからないまま、時刻表部分を先に作ります。
参加予定の各社にはともかくサンプルにデータを送ってもらうように頼みます、数社が送ってきました、送られてきたデータを元に電話でヒアリングをして、それから取り込みプログラムを作ります。
しかし、すぐに作れるものは作ってしまって開発はストップです。

平行して開発

ホームページのリニューアルが同時期の実施予定でした、こちらも平行して開発します、その他に年度始めの大きなダイヤ改正があり、またホームページの保守も私達の仕事です、これらも全部やりながらの開発です。

取り込みプログラム

各社のデータ構造が分かった時点で、取り込みプログラムを作っていきます、１社１社違います、予定外の事が起きればすぐに仕様を変更しどんどんプログラムを追加します。
これほど柔軟に仕様変更に対応できるのはエクストリームもどきプログラミングだから出来ると思います。
立ち上げの直前まで取り込みプログラムの変更に追われます。

完成

なんとか予定通りに立ち上げました、残業したのは立ち上げの直前の１週間程度、休日出勤も１日だけです。
結構いい反応が返ってきています。
なお この事例のサイトは九州のバス時刻表です。