久々にプロジェクトに参画して「変更に対して柔軟」であることの意義を強く感じる。
それも、実装レベルの柔軟性が開発全体の柔軟性につながるということを強く感じるのだ。
例えば今回参画したプロジェクトで実装上で取り入れた柔軟性の１つとして、
ViewベースのDB設計がある。
全体に影響があると思われた仕様変更が
Viewの内側の変更に納めたことで
１人日程度の作業で済んだという例が毎日のようにあった。
柔軟な設計をするには、柔軟な実装を知っていなければならない。
進め方での柔軟性
私は、
要件定義→設計 →単体テスト→実装→仕様変更→単体テスト →結合テスト→システムテスト
の流れこそが、日本での現実的なアジャイルの姿だと思う。
「イテレーションのように、初めからやり直す」
というタイプの繰り返しではなく。だ。
そもそも、ウォーターフォールの問題点である
「変更を認めない」という流れになるのは実装工程からが顕著だ。
設計工程では、ほとんどの設計変更は受け入れることが多い。
実装工程の手戻りは非常に嫌われる。
最大の理由は「もう一度テストしなければならないから」だ。
エンジニアは、テスト済みのコードに手を入れるのをとても嫌う。
実際に効率も悪い。
ファウラー氏の意見を参考にすれば、
そこで活躍するのは常時メンテナンスされたテストコードだ。
テストコードを作ることの最大のメリットは
「手戻りを容易に行えるようにすること」だ。
テスト作業の軽減ではない。
しかし、テストコードの作成も、
その試みがどういった成功をもたらすのかを
実感として理解していなければ難しいのかもしれない。
そういったことを総合すると
アジャイルな開発を成功させる上で、
一番大事なことは、
「チームを常に固定のチームとし、
チームを成長させること」であると思う。
アジャイルなシステム開発では、
個人個人がチームの文化を理解して、
自律的に動作することが重要だからだ。
日本のシステム開発の現場では、
開発に当たっては協力会社の社員を集めて
開発チームを組むことが多い。
一度きりの開発メンバーを集めることが多すぎて
チームビルディングが成り立たない。
こういったチームは、自律的に動作するような開発には取りかかれない。
イテレーショナルな開発について
はっきり言って、要件定義と設計までは
順番に進めるほうが良いと思う。
物事には段取りというものがある。
準備も整わないうちに、ヨーイドン！と走り出してもコケる。
イテレーション的開発を導入するのは、
実装の準備がある程度はできてからでいい。
DBのスキーマも決まらない、
アーキテクチャ構成も決まらない段階では
実装が走り出すと言うのも無理な話だ。
UIのデザインや操作性、機能性を早い段階で顧客に見せ、
設計のブラッシュアップをするのは重要だが、
それをイテレーションの１つと呼ぶほどのものでもない。
コストについて
以前に「イテレーション開発の問題点はコスト見積ができないことだ」
と言ったが、
要件定義と設計さえ終わっていれば、
あとの仕様のぶれは交渉によって何とかなると思う。
根底の根底から覆るような仕様変更では、
コストが増加するのは当然だからだ。
エンジニアとして目指すべきは
仕様変更によって、スケジュールが守れない、
残業しまくらなくてはならなくなる
そういったことをなくすだけのことです。
