念入りな画面設計などやめてしまおう
本日もAgile布教活動。
若手中心でAgileに挑戦しているチームを訪問。だが、状況を聞いているうちに「これはよろしくない」と思った。問題なのは画面の紙芝居で発注者と要件を調整していることだ。そして、きれいな画面設計書には「このボタンを押すとどんな処理が走る」「このリンクをクリックするとどこに飛ぶ」みたいな懇切丁寧な説明まで書かれている。
画面ベース開発の欠点
実際にプログラムを書かずに、利用者が使うことになるはずの画面見本を元に要件を固めていく。この方法が間違いとは言わないが、以下のような欠点を抱えている。
- 要件定義工程が膨らむ
- 画面に部品を描けば、必ずその部品が引き起こすイベントについて記述する必要がでてくる
- 結果、関連画面も芋づる式に記述していくことになり、検討する対象が増えてしまう
- 要件が硬直化してくる
- 検討対象が増えてくれば、検証にも時間がかかるようになる
- 運良く、漏れや間違いが発覚したとしても、関係画面全てに修正をいれるのはしんどい
- 知らず知らずのうちに、要件の追加修正を拒否するようになってしまう
- 厳密に要件が定義されていなくても、関係者が「わかった気分」になってしまう
- こうして、枚数が増えた画面要件定義書には細かい漏れや間違いが仕込まれる
- でも図解で説明されると、その場ではなんとなくわかった気分になってしまう
- 開発者視点にたった要件定義になりがち
- 「利用者が何をできるのか」ではなく「システムが何をするのか」に記述が偏る
- 受入テストの「より所」が存在しない
このような状態で開発を進めると...
以下のような問題に直面する可能性が高くなる。
- 開発作業量の増加
- 要件定義もれや間違いの発覚
- 総合テスト〜受入テスト段階でのドタバタ
厳密な画面紙芝居を作るのはとてもしんどいし、その紙芝居を検証するお客さんにも相当な負荷がかかる。なので、紙芝居はどこかで「手を抜いた」作品にならざるを得ない。「手抜き」をすることで、要件定義が曖昧なままでも顧客・開発双方が「わかった気分」になってしまいがちである。
Agileなら
要件はあくまでもフィーチャ定義でいくべきであろう。画面の大雑把な構造を図示するのは悪くないが、あくまでも参考資料としてとどめておくべきである。フィーチャ定義に関しては...今から水泳にいってくるので、帰ってから書く。
