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

第5回 設計を進化させる

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

変化をシステムに反映させる

重要なので何度でも書きますが,アジャイル開発とはお客様に価値のあるソフトウェアを提供するために「状況の変化に迅速に適応しながら開発を持続させていくこと」です。

「変化に適応する」とは,ソフトウェア要求の変化から個人の変化まで,さまざまなレベルでのフィードバックや学習の結果,気づきといった変化をシステム(=仕組み)に反映させていくことです。

本連載では「仕組み」とは開発対象のシステムと,開発対象システムの開発プロセスのことでした。連載の第2回では,主に開発プロセスを育てることに重点を置いて説明しました。

今回は,開発対象システムを変化に適応させる方法,すなわちコードを変化に適応させていくためのマインドセット(心構え)とプラクティス(実践)を紹介します。そのためのキーワードが「進化的設計」です。

進化的設計

進化的設計(Evolutional Design)はMartin Fowlerが設計の終焉?という記事で提唱した考え方で,計画的設計(Planned Design)と対比されるものです。

計画的設計

計画的設計は,従来から広く行われている「ソフトウェアを作る際にまず設計を行い,それからコーディングする」という設計の進め方です。経験の豊富な開発者が設計を担当し,コーディングは別の開発者が担当するという作業分担がされることもよく見られます。

計画的設計はアジャイル開発者の間ではあまり評判は良くありません。というのも,変化への適応をあらかじめ予測して,設計の柔軟性として盛り込んでおかねばならないからです。

計画的設計では,事前の予測が当たれば変化が起きたときに変更コストを低く抑えられます。しかし,予測が外れた場合には設計をやり直すか,それが無理なら「Work Around」と呼ばれる場当たり的な対処が必要になってしまいます。⁠柔軟な設計」が逆に足手まといになった苦い経験をみなさんはお持ちではありませんか? その意味では計画的設計には「うまくいくかもしれないし,うまくいかないかもしれない」という投機的な側面があります。

そして往々にして変化とは予測もしない方向からやってきます。アジャイル界には「予測できるような変化は変化ではない」という格言もあるぐらいです注5⁠。

計画的設計は「事前の大規模設計(Big Design Up Front:BDUF⁠⁠」や「前払いの設計」とも呼ばれます。

注5)
関将俊さんによる。

進化的設計

一方,進化的設計では「プログラミングを行いながらゆっくりと設計を進化させていきます。はじめから設計は存在しません。小さな機能をコーディングすることから始め,機能を追加していき,設計を洗練させていきます」注6⁠。

進化的設計は「はじめから設計は存在しない」という言葉から,いきなりコーディングを始める無統制で無秩序な「書いて直せ(Code and Fix⁠⁠」アプローチと混同されることも多いのですが,そうではありません。

進化的設計は「いま・ここ」で必要な分だけ設計することを繰り返します。計画的設計の設計コストを「前払い」するアプローチと対比させるならば,進化的設計は設計コストを「都度払い」するアプローチといえます。

また,進化的設計は「必要十分な設計(ENough design Up Front:ENUF⁠⁠」と呼ばれることもあります。

注6)
Martin Fowlerのblikiの記事進化的設計より。

進化のメタファが伝えたいこと

進化的設計は,生物の進化をソフトウェアの設計に適用したメタファです。⁠進化」とは生物の種が時間の経過とともにその形や機能が変化していくことです。

単に「変化する設計」と言わずに「進化的設計」と少し気どった言い回しをするのは理由があります。アジャイル開発における設計の考え方には,変化すること以外の意味も含まれているからです。その主なものを3つ紹介します。

変化への適応の「結果」である

計画的設計と異なる進化的設計の一番のポイントです。進化的設計とは,時間の経過とともに状況の変化に適応して洗練させていった結果として実現された設計のことです。生物のさまざまな姿や生態も環境の変化へ適応した結果であって,当初から意図を持って「設計」されたものではありません。

進化的設計では,当初は思いも及ばなかった設計が実現されることは日常茶飯事です。実現した設計は,当初想定していた構造よりもシンプルになっているこもあれば,その逆の場合もあります。

これはプロジェクトでの作業を通じて得られた学習や気づきといったフィードバックをソフトウェアに反映させることで達成できます。設計が変化していく過程自身から学ぶことも多くあります。

各段階で「機能」している

進化的設計では,設計は時間とともに変化していきますが,その変化の過程であってもソフトウェアとして機能していなければなりません。進化のメタファでいえば,機能しない(=その環境で子孫を残せない)生物種は絶滅してしまいます。

これはソフトウェアでも同じです。変化のために機能が損われてしまっては,ソフトウェアとしての価値を提供できません。

「進歩」ではない

進化的設計も進化と同じく,設計の変化は「進歩」を意味するわけではありません。時間の経過と共に追加されていく構造もあれば,取り除かれる構造もあります(人類は進化の過程で尻尾が退化しています⁠⁠。

アジャイル開発の言葉でいえば「シンプル設計」の考え方がこれに対応します。

カメの設計

たとえばカメの設計を考えてみましょう。甲羅を背負ったカメは少し変わった姿をしていますが,次のような特徴があります写真1⁠。

写真1 ヘルマンリクガメ

写真1 ヘルマンリクガメ

  • 生物種として2億年にわたって存続している
  • 生息域は南極を除く全大陸に分布
  • 個体の寿命も長い

「未来に子孫を残す」という生物の機能からすれば,設計としてはかなりの成功例ではないでしょうか。あくまで例え話ですが,事前にカメのような形態の設計がここまで成功することを見通すのは難しそうです。

「固い甲羅で外敵から身を守りますが,移動速度が落ちます。事故でひっくり返った際は,運が悪ければ死にます」……少なくとも私がカメを事前設計したとしたら,設計レビューに合格する自信はありません注7⁠。

注7)
生物進化はランダムな遺伝子変異の地質学的スケールでの自然選択の結果ですから,進化に意図はありません。

著者プロフィール

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

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

URLhttp://kakutani.com/

著書