仰々しいタイトルにしてしまった・・・
アジャイルな開発とウォーターフォールな開発
アジャイルな開発とウォーターフォールな開発を眺めてみます。
まずは、ウォーターフォールな開発です。
ウォーターフォールな開発では、設計→実装→テストをすべて一度にやっていきます。
このように、すべての設計を一度でやってしまう手法をここでは「ウォーターフォールな設計」と呼ぶことにします。
一方で、アジャイルな開発はこんな感じです。
ストーリーごとに設計→実装→テストをまわしていきます。
より正確にいうと、テスト→設計→実装だったりしますが1、本題とズレるので省略です。
このように、ストーリーごとに設計を行う手法をここでは「アジャイルな設計」と呼ぶことにします。
アジャイルな設計とウォーターフォールな設計
ウォーターフォールな設計と品質
ウォーターフォールな設計とアジャイルな設計を見ていきましょう。
まず、ウォーターフォールな設計から。
ウォーターフォールな設計では前述のとおり、いちどにすべての設計を行います。
言い換えるなら、全体を俯瞰して見ながら設計を行えるということです。
昨今の開発ではオブジェクト指向を用いて開発が行われることが多いです。
オブジェクト指向の核心は以下の4つとされています。2
- 構造
- 信頼性
- 認識論
- 分類
ここではオブジェクト指向についてあまり多く触れませんが、システムを構築する多くの情報をどのように構造化し、分類するかは非常に重要です。
システムの全体を俯瞰して見えるというウォーターフォールな設計の特徴は、構造化や分類をする際にとても役立ちます。
アジャイルな設計と品質
それでは、アジャイルな設計はどうでしょうか。
アジャイルな設計では、ストーリーごとに設計を行います。
ウォーターフォールな設計とは逆に、「木を見て森を見ず」な設計になりやすいということです。
都度設計するため、ただパッチを当てるような設計が横行し、ストーリーを作るたびに品質が落ちる可能性があります。
アジャイルでは「荒ぶる四天王」や「鉄の三角形」の話にあるように、「スコープ」「コスト」「時間」（「品質」）に優先順位をつけます。
この際、品質よりも速度を選択すると特に顕著に影響します。
ストーリーごとに最速でミニマムな変更を加えていけば、データベースは非正規化されたテーブルで溢れかえり、コードは手続き的で条件分岐だらけになることは容易に想像ができます。
また、アジャイルにおいてはスクラムフレームワークが有名ですが、スクラムでは技術的なプロセスの支援は一切ありません。
よって、スクラムだけを勉強して実践すると、簡単に品質の低いシステムになりやすいのです。
そして品質が低いがゆえに、システムに手を加えれば加えるほど、コードを読む時間が増え、修正コストがかさみ、バグが積み上がり、速度が低下していきます。
速度を優先していたはずなのに、速度が出せないという状況に陥るわけです。3
設計と変化
では、アジャイルな設計は良い点がまったくないのか、というと違います。
アジャイルな設計は、「変化」に強いという利点があります。
アジャイル開発では「計画は必ず変わる。計画が変わらないということは何も学んでいないということだ。」という考え方をします。
「計画が変わる」ということは見落としやすいポイントですが、ほぼすべてのプロジェクトで発生します。
変更の範囲に今まで設計したものがあれば、それは「やり直し」をしなければなりません。
これはアジャイルな設計でもウォーターフォールな設計でも同じです。
ただし、ウォーターフォールな設計では最初にすべての設計を行うので、設計後に発生した変更はすべて「やり直し」が発生します。
一方でアジャイルな設計では、すでに着手したものが変更された際には「やり直し」が発生しますが、まだ着手していないものについては「やり直し」が発生しません。
このように考えると、「やり直し」が発生する確率や範囲は、ウォーターフォールな設計よりもアジャイルな設計のほうが少ないわけです。
これをアジャイルでは「変化に強い」と呼んだりするわけです。
ここまでのまとめ
アジャイルな設計とウォーターフォールな設計を見てきましたが、まとめるとこんな感じなわけです。
| メリット | デメリット | |
|---|---|---|
| アジャイルな設計 | 変化に強い | 品質が低くなりがち |
| ウォーターフォールな設計 | 品質を高くしやすい | 変化に弱い |
どのような設計をしていくべきか
では、どのような設計をしていくべきなのでしょうか。
当然、「品質が高く」「変化に強い」両方をいいとこ取りをした設計をしていきたいものです。
どちらかの設計を基本とし、デメリットを補うような方法を採用できると良さそうです。
ウォーターフォールな設計の「変化に弱い」というものは、ウォーターフォールな設計の根本に紐付いているものなので、ここを補うのは大変そうです。
よって、ここではアジャイルな設計の「品質が低い」という問題を補う方法を考えていきます。
ここではXPのいくつかのプラクティスを紹介し、どのように品質が低くなる問題を補うかを考えていきます。
インクリメンタルな設計
設計の品質を補う主な戦略がこれです。
名前から推測されるとおり、「毎日設計をする」「常に設計をする」というものですが、それだけでは足りません。
これは「毎日最適な設計をする」「常に最適な設計をする」ということです。
『エクストリーム・プログラミング』では以下のように書かれています。
彼らは設計に時間をかけずに、できるだけ早くストーリーを積み上げようとしている。設計に毎日注意を払わなければ、変更コストは急増するだろう。その結果、設計が貧弱で脆弱な変更しにくいシステムになってしまう。
XPチームは、短期的な設計の労力を最小化するのではなく、現時点までのシステムのニーズに合わせて設計するべきである。
一番ミニマムな設計をしろという話ではない、ということです。
一見、簡単そうな変更に、ものすごく時間がかかるかもしれません。
例えば、カラムひとつ追加すればすぐに終わるが、最適な設計をしようとするとテーブル分割を行ったほうが良い場合もあるでしょう。
ですが、システム開発は今まで作ったものの上に積み立てていくものであり、しかも長い道のりになります。
目先のラクさにとらわれずに、良いものを作っていきましょう。
また、アジャイルな設計では、将来を見越した設計は行いません。
現在、いまあるシステムに対して最適な設計をするということです。
将来を見越した再利用性は不要ですが、今現在のシステムに対して価値のある再利用性は必要だということです。
なぜなら、その「将来を見越した何か」は「たぶん要らない」からです。(YAGNIですね)
DRY, KISS
DRYは「同じコードを書くな」、KISSは「シンプルにしろ」という意味です。
一般的なコーディングルールに則ってさえいれば、コード量は少ないほうが良いのです。
なぜなら、コード量が少なければ、読む量が減り、メンテナンスする量も減るからです。
同じコードが書いてある、というのは設計がまずそうな「におい」だと思っています。
同じコードがあるときは、自分の見落としている分類がある可能性が高いです。
いまいちどモデリングを行い、もっとシンプルにならないかを考えてみるとよいと思います。
自動テスト、継続的インテグレーション
自動テストによって品質を上げることはできませんが、品質の低下に気付くきっかけになります。
この品質の低下に気付くタイミングを、なるべく増やしましょう。
といっても、最近では継続的インテグレーションツールも進化してきており、みなさん当たり前にやってるような気がします。
まとめ
アジャイルな設計とウォーターフォールな設計は、どちらにもメリット・デメリットがあります。
どちらのメリットも教授できるような設計を実現するために、XPのいくつかのプラクティスを紹介しました。
「アジャイル＝最高！」みたいな風潮が最近強いですが、アジャイルな開発をすることによって何を失うのかについても注意を向けていきたいものですね。
