いまやもっとも美しい生き物はカメだろう。

――映画『エル・マリアッチ』

はじめに

本連載ではアジャイル開発を「アジャイルに開発する人たち（アジャイル開発者）が開発するからアジャイル開発」と考え，アジャイル開発者に必要なスキルを磨くための習慣を紹介しています。

今回は「変化」に対するアジャイル開発者の向き合い方を，「設計を進化させる」という習慣を通じて紹介します。これは「進化的設計」というキーワードで知られています。

連載の第1回で説明したように，アジャイル開発の目的は「ソフトウェアの価値の総量を最大化させる」ことです。変化に適応することは，このアジャイル開発の目的を達成するにあたって欠かせないものです。過去の連載で紹介してきた習慣のいずれもが「変化に適応する」ことと関係しています。

今回はまず，アジャイル開発者にとっての変化について簡単に説明します。それから，変化に適応することのソフトウェア設計への応用として「進化的設計」の考え方を紹介します。そして，この進化的設計を実践するために身につけるべき習慣を紹介します。

「変化ヲ抱擁セヨ」

変化はアジャイル開発者にとってとても強い関心事です。本連載の第2回でも，アジャイル開発とは「状況の変化に迅速に適応しながら開発を持続させていくこと」だと述べました。

アジャイル開発と変化

そもそものアジャイル開発のムーブメントの始まりである『XP エクストリーム・プログラミング入門』（注1）の原著の表紙には「Embrace Change（変化ヲ抱擁セヨ）」と謳われています（図1）。

これは「変化を嫌うのではなく変化が起こることを自然なこととして受け入れよう，というXPの基本姿勢」（注2）を表しています。

昨年末に刊行された『アジャイルプラクティス』（注3）にも「『アジャイルである』とはつまり変化に対応することだ」とあります。

Mike Cohnは『Agile Estimating and Planning』（注4）という，見積りと計画をアジャイルにすることを扱った書籍で次のように述べています。

計画に対するアジャイルな態度とは「変更されてもかまわない」ではない。むしろ「積極的に変更したい」と思うのがアジャイルな計画である。

――Mike Cohn

かなり大胆ですね。

このように，アジャイル開発がことさらに「変化」にこだわるのはある意味当然ともいえます。というのは，アジャイル開発はその出自が従来型の開発――事前に策定した包括的で綿密な計画を絶対視する開発（＝変化しないことを前提とする開発）に対するカウンターだからです。

変化の存在を認め，正面から向き合うというのがアジャイル開発者の基本的な態度です。

注1）

日本語訳第2版『XP エクストリーム・プログラミング入門 第2版 ― 変化を受け入れる』（Kent Beck（著），長瀬 嘉秀（監訳），株式会社テクノロジックアート（訳），ピアソン・エデュケーション）

注2）

平鍋 健児さんの記事「eXtreme Programmingの魅力を探る」より。

注3）

『アジャイルプラクティス　達人プログラマに学ぶ現場開発者の習慣』（Venkat Subramaniam／Andy Hunt（著），角谷 信太郎／木下史彦（監訳），オーム社）

注4）

『Agile Estimating and Planning』（Mike Cohn（著），Prentice Hall）

さまざまな変化

みなさんの中には（この連載も含めて）記事や書籍で語られる「変化」を，お客様から電話やメールで，あるいはマネージャから伝えられる「仕様変更」のことだととらえている方がいるかもしれません。

ソフトウェア開発の文脈でよく言及されるのは，上述したようなソフトウェアに対する要求の変化でしょう。確かに，仕様変更や要求の変化はプロジェクトへの影響も大きいですから，関心が高いのも当然です。

ですが，アジャイル開発で扱う変化は，こうした変化だけではありません。

ソフトウェア要求の変化

上で述べた「仕様変更」も，その背景にはさまざまな変化があります。たとえば法改正やビジネス環境の変化，お客様の組織改編，ベンダーの戦略転換などです。

アジャイル開発では，こうした変化に適応できることはもちろんですが，プロジェクトを進めていくなかでシステムに対して学んだことによる変化も取り入れていこうとします。

仕様の確認を進めていくなかで「そういうことだったんですね。じゃあ，ここはやっぱりこうしたいですね」といった意見が出てくる場面に遭遇したことはありませんか？

そのときに「それは変更できません」と答えるのではなく，実現させるための現実的な解決策を提示できるように努めるのがアジャイル開発者です。

組織やチームの変化

自分の所属する組織やチーム内でも変化は起こります。プロジェクトメンバーの増減や入れ替わりや，技術的な環境の動向，開発の進め方の改善も変化です。第1回で紹介した「ふりかえり」はこのレベルでの変化を促すためのプラクティスでもあります。

個人の変化

そして，個人のレベルでも変化は起きています。みなさんも経験があると思いますし，今現在も体験していると思います。

プロジェクトに対する理解は，チームで過ごしていく時間が経つにつれて，プロジェクトに参加した当初よりも深まっているはずです。プロジェクトで実現しようとしていること，採用している要素技術，一緒に働いているメンバーの振る舞い……（もちろん，程度の差はあります）。日々の作業の中での個人的な「気づき」も立派な変化の一つです。