業務系アプリケーションでアジャイル開発を行っています。私はアジャイル開発というものは気に入っていて好んで利用しています。しかし最近、いくつかのプロジェクトでアジャイル開発に参加させて頂いているのですが、どうも疑問が多いので整理したいと思います。
ウォータフォールについて
業務アプリケーションはとにかく機能が多く、その流れを整理する必要があります。物事を細分化して適切なプログラムまで落とし込むのに必要なプロセスが存在します。それがウォータフォールです。
まず
- 全体像を把握する
- 機能分割をする
- 機能を詳細に落とし込む
- プログラムが書けるレベルに記述する
- プログラムを作成する
各プロセスでは次のことも考えます。
- それぞれについてテスト仕様を作成します
- 各工程で作成したドキュメントは次の行程への指示書と思え
プログラムの作成が終わったら4→3→2→1の順で作成したテストを行っていきます。これに加え
を工程の早いうちに行います。UI/UXである利用者とのインターフェース設計は感性要因がありますので、実際に画面を確認してもらい必要な情報を得ます。
アジャイルについて
アジャイルですが各工程の中で、それぞれやるべきことを列記します。つまり工程ごとに
- ストーリーの作成：ストーリーはシステム的に意味のあるものとして定義
- いくつかのストーリーをイテレーション/スクラムで仕上げる
- ストーリーに対しプランニングポーカーで工数を見積もる
- やらないものリストの作成：システムの流れに入らないものは除外
という形式で、それぞれの工程でやるべきことをひとつひとつ仕上げていくスタイルをとります。
ウォーターフォールとアジャイル
ウォーターフォールは開発プロセスであり、アジャイルは開発スタイルという位置づけで利用させて頂いています。ですので私にとってはウォーターフォールとアジャイルを比較する意味がありません。ウォーターフォールだけでシステム開発はできないしアジャイルだけでも開発ができません。元々アジャイルという言葉が出る前からカンバンは行っていました。ホワイトボードにやるべきことを書き、終わったら消す、新しい要素が出たらピックアップするということは日常でやっていたことです。
よろしくないと思われる例
開発プロセスのないまま、スタイルはアジャイルを採用します。その結果、全体像が見えず開発を進めることになり、ストーリーを消化するたびにリファクタリングが発生しています。つまり昔で言うところの「作り負け」です。
まだ問題があります。その場での最適なプログラムは次のストーリーでは必ずしも最適ではないということがあります。共通化すべきかそうでないのか。結果的に、スパゲティプログラムが完成されるという場合があります。リファクタリングは時間を要するため、とりあえずストーリーをこなそうという方針のためです。
「価値」の無いものはシステム化対象外
我々エンタープライズエンジニアにとって価値のないものは提供しません。システムは一連の流れで定義されています。点ではただのプログラムになりシステムとはなり得ません。プログラムは有機的に結びついてはじめてシステムになるためです。
アジャイルで価値のあるものを提供するという定義がありますが、すべての行為は価値のあるものなので力を入れて説明する程のものではないと思います。
スクラムマスター
アジャイルを行うときにスクラムという形でチームを組みますが、そのチームが健全であるかを第三者的に判断する人のことかと思います。ちょっと変な言い方をするとスタイリストでしょうか。
最後に
取り立ててこうでなければならないというのは持ち合わせていませんので「こだわり」はありません。しかし、動くシステムを納めるという命題はあります。
スタイルやプロセスにこだわり過ぎて、動くシステムが納められないとか開発工数が膨大になるというのは論外だと思います。利用者に喜んで使用されるシステムが出来上がれば、それでよしとしたいところです。
議論としてはだいぶ古い内容だと思います。ただ業務系アプリケーション開発の分野でもアジャイルを用いることが多くなってきています。やるべきことをやって「目的」を見失わないように良いシステムを構築していきたいと思います。
