アジャイル開発者の習慣-acts_as_agile

第5回 設計を進化させる

この記事を読むのに必要な時間:およそ 6 分

習慣 #4 設計を進化させる

言い回しはしゃれている進化的設計ですが,特徴を整理すると実践するのは難しそうです。

進化的設計の特徴
  • 事前に大規模な設計をすることなく,
  • 時間の経過とともに変化に適応しながら,
  • 設計を洗練させつつ,
  • ソフトウェアとしての価値を提供し続ける

実はというか予想通りというか,これは簡単ではありません。しかし,実現するために必要なマインドセット(心構え)とプラクティス(実践)を継続させれば不可能ではないことは強調しておきます。順番に紹介します。

マインドセット「予測できないものが変化である」

進化的設計を実践するためには,まずマインドセットを切り替える必要があります。もう一度書いておきます。「変化とは,事前に予測できないから変化である」

そして,問題となるのは変化が起きてしまうことではありません。起きた変化に適応できないことが問題なのです。

設計コストを「都度払い」にする

ソフトウェアの設計に関していえば,事前に変化を見通すことではなく,変化が起きたときに迅速に対応できるようにすることが重要なのです。設計コストを「都度払い」にするとはそういうことです。

ですが,一朝一夕に設計コストを都度払いにはできません。都度払いにするための「仕組み」を育てる必要があります注8⁠。今回紹介するプラクティスはそのためのものです。

注8)
連載第2回の習慣仕組みを育てるで紹介したマインドセット「最初から完璧を目指さない」⁠仕組みのせいにしない」参照してください。

マインドセット「それはユーザ価値を提供するか?」

後述する進化的設計のプラクティス,とりわけテスト駆動開発とリファクタリングについては「どこまでやれば適応できているのか?」を判断するのが難しかったり,議論になることがあります。究めようと思えばいくらでもやることはあり,熱中し過ぎるとビジネス価値を損うことにもなりかねません。

設計は完璧でなくてもよい

そんなときには行った設計や,取り組もうとする作業が「ユーザ価値を提供するか?」という視点から自分自身やチームに向けて問いを発してください。

書いたテストや施したリファクタリングが,その時点で常に完璧である必要はありません。現在の設計はいずれ変更されることになりますし,変更されるべきだからです。

視点を変えれば,ユーザ価値を提供できてさえいれば,設計は美しくなくても,完璧でなくてもかまわないのです。むしろ,あとで必要になったときに変更できるか――つまり,後述する3つのプラクティスをどれぐらい充実できているかを気にかけるべきです。

ユーザ価値の提供を判断する基準

また,ユーザストーリは,ユーザ価値を提供する基準となっているはずです。計画づくりは,提供するユーザ価値に優先順位をつける活動です。自分の作業を常にユーザストーリや計画と照らし合わせて,進路を間違えないように,間違えたときはすぐに軌道修正することを心がけましょう。

プラクティス「テスト駆動開発(TDD)」

ソフトウェアの設計を変更させる過程であっても価値を提供させ続けていくためには,現在のコードが壊れていないことを確認する手段としてのテストは欠かせません。

ですが,現在の設計がテストしづらい設計になっていると,テストすることもできません。TDDは進化的設計における最重要プラクティスです。

TDDは「都度払い」の設計

「どうすればテストを書けるコードにできるか?」を考えることは立派な設計作業です。

James ShoreとShane Wardenは『The Art of Agile Development』注9で,TDDのステップを従来の「レッド,グリーン,リファクタリング」から拡張し,最初のステップを「Think」すなわち「考えること」だと主張しています図2⁠。

図2 テスト駆動開発の4つのステップ

図2 テスト駆動開発の4つのステップ

これはTDDが単なるコーディングでなく設計作業であり,この設計がテストを書くたびに少しずつ行われていくということ,つまりTDDが都度払いの設計であるということです。

なお,テストのない既存コードをどうやってテストできるようにするかについては『Working Effectively with Legacy Code』注10がたいへん参考になります。

注9)
『The Art of Agile Development』⁠James Shore/Shane Warden(著⁠⁠,OユReilly Media, Inc.)
注10)
『Working Effectively with Legacy Code』⁠Michael C. Feathers(著⁠⁠,Prentice Hall)
リファクタリングの安全ネット

テストケースは,後述するリファクタリングの過程で既存コードを壊していないことを保証する安全ネットでもあります。

テストを用意せずに設計を変更していくのは進化的設計ではありません。それは「書いて直せ」アプローチです。

著者プロフィール

角谷信太郎(かくたにしんたろう)

(株)永和システムマネジメント,サービスプロバイディング事業部所属プログラマ。「『楽しさ』がシステム開発の生産性を左右する」と信じてRubyによるアジャイル開発を現場で実践するテスト駆動開発者。目標は達人プログラマ。好きな言語はRuby。好きなメソッドはextend。著書に『アジャイルな見積りと計画づくり』(共同翻訳),『JavaからRubyへ』(翻訳),『アジャイルプラクティス』(共同監訳),『インターフェイス指向設計』(監訳)。

URLhttp://kakutani.com/

著書