すばらしい製品というのは、単に良い習慣の副産物でしかありません。

『Ship It!』（⁠注1）

はじめに

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

前回紹介した習慣は、習慣を身につけるための習慣（メタ習慣⁠）⁠、「⁠フィードバックを重視する」でした。

第2回である今回は、最初の具体的な習慣として「仕組みを育てる」習慣を紹介します。そのために、アジャイル開発者にとっての「仕組み」とは何か、なぜ重要なのかを説明――する前に、先日体験した印象深い経験について語らせてください。

RubyKaigi2007のDave Thomasとアジャイル

6月9、10日に日本Ruby会議2007（RubyKaigi2007）が開催されました（と書くと他人事のようですが、私は実行委員でした⁠）⁠。会期の最後に行われたDave Thomas（編注）による基調講演は、氏のRubyへの愛と、爆発的拡大を始めたRubyコミュニティのこれからのあり方について真摯に語る、粋で素敵な深く心に響く講演でした（写真1[2]⁠）⁠。

いちRuby好きとして行動しつつもRubyプログラマとしてRubyコミュニティに貢献できていない私は、氏の講演に大いに勇気づけられ、当日は感極まって思わず泣いてしまいました。

Dave ThomasはRubyの海外での認知のきっかけをつくった立役者であるだけでなく、『⁠達人プログラマー』（⁠注3）の共著者であり、アジャイルソフトウェア開発宣言（アジャイルマニフェスト）の署名メンバーでもあります。

“Be flexible and agile”

Dave Thomasによる基調講演は、私の個人的な感慨とは別に、本連載としても興味深い内容がありました。それはほかならぬ氏による「アジャイル」という言葉の使い方についてです。

講演でDave Thomasは、新しくRubyにやってくる人々にRubyコミュニティが伝えるべき価値の一つとして「柔軟かつアジャイルに」ということを挙げました。また、講演後の質疑応答でも「Rubyコミュニティはアジャイルだ」という発言をしていました。

アジャイル＝適応性＋持続可能性

Rubyの開発コミュニティは、たとえば計画ゲームやテストファーストといったアジャイル開発のプラクティスを熱心に実践しているわけでもなければ、自分たちが「アジャイルである」と標榜しているわけでもありません[4]⁠。

にもかかわらず、Dave ThomasはRubyコミュニティを「アジャイル」だと言いました。氏がこのとき「アジャイル」という言葉に込めた意味は「状況の変化に迅速に適応しながら開発を持続させていくこと」だったと私は理解しています。

アジャイルは単純な納期の早さではない

私は最近、Ruby on Railsを採用するプロジェクトについての相談を受けることが多くなりました。その際、先方から「スケジュールが短期なのでアジャイルに開発したい」と言われることが少なからずあります。

残念ながら、アジャイル開発が実現するものは、開発するソフトウェアのライフサイクル全体を通じた変化への適応性と開発の持続可能性であって、単純な納期の早さではありません。

アジャイル開発の「俊敏さ」

よくあるアジャイル開発の説明は「アジャイルとは『俊敏な』という意味である」という記述から始まるものです。ここでの俊敏さとは、従来型の開発――事前に策定した包括的で綿密な計画を絶対視する開発――と比較しての、ソフトウェアのライフサイクル全体を通じての相対的な開発速度の速さです[5]⁠。

例えるなら、アジャイル開発の速さはマラソン走者の速さであって、短距離走者の速さではありません。「⁠10分でブログアプリケーションを構築できる」といった開発速度の速さも、短距離走の速さです。

編注）

Dave Thomasさんと小飼弾さんの対談が、連載コラム「小飼弾のAlpha Geekに逢いたい♥」に掲載されています。

注2）

講演の内容は、zundaさんによるRubyKaigi公式サイトの速報ログに詳しいです。

注3）

『達人プログラマー ― システム開発の職人から名匠への道』（⁠Andrew Hunt／David Thomas（著⁠）⁠、村上 雅章（訳⁠）⁠、ピアソン・エデュケーション）

注4）

念のため補足しておくと、Ruby開発コミュニティはテストケースを大事にしています。ただ、典型的なアジャイル開発プロジェクトのようにはテストをソフトウェア設計の中心に据えているわけではない、という意味です。

注5）

こうした補足説明が必要になるということは、「⁠アジャイル」という言葉は実はあまりよい名前ではないのかもしれません

アジャイルな状態を持続させる「仕組み」

アジャイル開発では、ソフトウェアがライフサイクル全体を通じて変化への迅速な適応を持続できるように開発を行います。

今回のポイントは「持続できること（持続可能性：Sustainability）」です。アジャイル開発に限らず、何かを持続させるためには仕組みが必要です。担当者の能力と頑張りだけに頼っていては、持続可能性の実現は非常に心もとなくなります[6]⁠。

ソフトウェア開発という活動の仕組み

ここでの「仕組み」とは広い意味でのシステムのことです。仕組みとは、何らかの入力をもとに処理を行い、結果を出力するものです。

これを「システム」と呼んでしまうと開発対象のソフトウェアシステムと区別しづらいので、本連載では「仕組み」と呼ぶことにします。

開発プロセスは仕組みである

「⁠ソフトウェアを開発する仕組み」とは、つまり「開発プロセス」のことです。

開発プロセスの「入力」はソフトウェアに対する要求です。開発チームはこの入力を「処理」します。チームの「出力」は開発対象のソフトウェアです。

そして少し複雑なシステムにはたいていの場合、フィードバック機構が備えられています。フィードバックとは、その仕組みの出力したものが、再び仕組みへと入力されることです。エアコンやカメの水槽の温度を管理する温度調節などがフィードバックの例です。アジャイル開発ではフィードバックが重要であることは前回説明しました。

アジャイルな開発プロセスは、「⁠出力」したソフトウェアから学習することで自分たちの開発プロセスを改善し、アジャイルな状態を保つ活動なのです。

開発対象のソフトウェアも仕組みである

もちろん、開発対象のソフトウェアシステムも「仕組み」です。ソフトウェアは「入力」されたデータを「処理」して結果を「出力」することでビジネス価値を生み出します。

開発対象ソフトウェアそのものに自律的なフィードバック機構が備わっているかどうかは、開発するアプリケーションの特性にもよりますが、利用者からの機能追加や使い勝手の改善の要望もフィードバックの一種だと考えることができます。ソフトウェアは利用者に使われて初めて価値を生みます。

ちなみに私自身は「利用者もソフトウェアの一部である」というよりはもっと積極的に、「⁠利用者とソフトウェアとの共同作業がソフトウェアの価値を生み出す」と考えています。

仕組みを開発する仕組み

まとめると、ソフトウェア開発という活動は、「⁠ソフトウェアという仕組み」（⁠＝開発対象のソフトウェアシステム）を開発すると同時に、「⁠ソフトウェアという仕組みを開発する仕組み」（⁠＝開発プロセス）を開発するものでもあるのです（図2)。

「人がつくる」からこそ仕組みは重要

ところで、アジャイル開発は「ソフトウェアは人がつくる」という考えを前提としているのでした。

ソフトウェアを開発する仕組み、つまり開発プロセスを重視するという姿勢は、一見すると「人がつくる」という考え方に反するものにも思えます。しかし、そうではありません。

特定の個人は取り替えのきかない、かけがえのない存在です。だからこそ、特定の個人にだけ頼るのは危険です。彼または彼女の身には、いつ何どき、何が起こるかわかりません。

アジャイル開発は「人がつくる」ことを重視しているからこそ、このような事態にも備えて仕組みを用意し、それを育てることを大事にします。

この考え方は、アジャイル開発者の間ではトラックナンバーやハネムーンナンバー[7]といった言い回しとともに広く受け入れられています。

仕組みを育てるスキル

そして「仕組みを大事にする」ということは、事前に用意された仕組みを絶対視するということを意味しません。

仕組みは大事です。大事なので、アジャイル開発チームは、自分たちがソフトウェアを開発する仕組み――開発プロセスを、仕組みの利用者である開発チームが自分たち自身の手でつくりあげるのです。

習慣 #1　仕組みを育てる

この習慣で「育てる」対象として意識する「仕組み」は、開発対象のソフトウェアとチームの開発プロセスの両方です。

仕組みを育てていくにあたってのマインドセット（心構え）とプラクティス（実践）をそれぞれ2つずつ紹介します。

マインドセット「最初から完璧を目指さない」

仕組みを「育てる」という言葉には、「⁠次第に大きくなる」「⁠成長していく」という意味合いを込めています。

アジャイル開発の説明でよく使われる「インクリメンタルかつイテレーティブ」という言葉がこれをよく説明しています。「⁠育てる」とはすなわち、反復を繰り返しながら（イテレーティブ⁠）⁠、少しずつ進んでいく（インクリメンタル）ということです。

アジャイル開発者は、開発プロセスにせよソフトウェアにせよ、最初の1回で、あらゆる事態への対処を考慮した完璧な仕組みを用意することはできないと考え、行動します。

問題が起こることは問題ではない

「最初から完璧にはできない」ということは、失敗する可能性を想定しておくということです。前回の「習慣#0　フィードバックを重視する」で紹介した「タイムボックス化」や「ふりかえり」といったプラクティスは、一定のリズムでの繰り返しと改善の機会を仕組みとして用意します。これは問題の発生に対するセーフティネット（安全網）として機能します。

セーフティネットがあることで、もしも問題が発生したとしても、その被害を一番近いチェックポイントまでの間に食い止められます。

つまり「問題が起こること」は問題ではありません。問題が起こったときに問題に対処できないことが問題なのです。

マインドセット「仕組みのせいにしない」

仕組みは、仕組みとして存在するようになった途端に、ある種の存在感のようなものが生まれます。開発プロセスにしても、開発したソフトウェアにしても、これらがうまく機能している場合には別段、気になることもありません。

ところが、いざ問題が起きたり、問題と呼ぶほどのことではなくても不便を感じたりするようになったときに、つい「⁠（⁠この仕組み）はこういうものだから」と考えてしまいがちです。仕組みが一人歩きしてしまうのです。

これは、仕組みが他人から押しつけられた場合はもちろんですが、自分たちで決めた場合にも陥ってしまうことがあります。

仕組みのせいにするとひとまず安心できます。しかし、問題は先送りされるだけで解決されません。「⁠この仕組みは本当に変えられないものなのか？」「⁠どうすれば仕組みを変えられるようになるのか？」を問う姿勢を忘れないことです。タイムボックスごとの「ふりかえり」はそのためのよい機会です。

プラクティス「スモールスタート」

スモールスタートは文字通り、小さなステップから始めることです。小さく始めて、うまくいくことを確認しながら段々適用範囲を広げていきます。まずは、小さな規模（個人や作業ペアなど）で仕組みそのものが「うまくいくこと」を体得します。次に、それをより大きな規模（チームや組織内、組織間）へ適用していきます。規模が大きくなるにつれて、関係者が増え、影響範囲も大きくなり、考慮すべき事項が増えます。規模の変化にどう適応していくかもアジャイル開発者としての腕のふるいどころです。

以下では、アジャイル開発者の4つのスキル（前回参照）の習得を例にとって、スモールスタートを簡単に紹介します。

テスト駆動開発（TDD）

4つのスキルの一つであるTDDの真髄は、その名前の印象とは異なリ、実際にはテストの技法というよりは設計の技法だということです。しかし、これを実感し体得するまでには相応の実践が必要です。どこから始めればよいでしょうか？

これはTDDをスモールスタートする一例でしかありませんが、テストコードの書き方を身につけてから、テストファースト（テストコードを製品コードよりも先に書くこと）を意識するようにするのは、経験的にも有効だと確信しています。

ストーリの作成

ストーリの作成も4つのスキルの一つです。ストーリは、システムの振る舞いを顧客の語彙で散文的に記述します。しかし、実践にあたって、経験なしに顧客を巻き込むのは危険過ぎます。では、どこから始めればよいでしょうか？

つまり、開発プロセスの改善にストーリの作成を適用するのです。自分たちの開発プロセスを利用する（＝顧客）のは自分たちなのですから。作成するストーリは、大げさなものでなくてかまいません。たとえば「チェックアウトからビルドまでを1つのコマンドで実行できるように自動化すること」「⁠1人で悩む時間をタイムボックス化すること。1回につき30分以内に」といった具合です。

自分たちが「顧客」である開発プロセスの改善ストーリすら書けない状態では、顧客を巻き込んだストーリの作成は難しいと思います。

ストーリの書き方は、書籍『User Stories Applied』（⁠注8）やDan Northによる「What's in a story?」が参考になります[9]⁠。

いきなりすべてを適用しない

逆説的な言い方ですが、誰もXP実践経験者がいないプロジェクトで、XPのプラクティスのすべてをいきなり適用しようとしても、うまくいかないでしょう。

私の場合は幸運にも、最初にアジャイル開発を体験したプロジェクトには経験者がいました[10]⁠。おかげで比較的スムースにXP的な仕組みをプロジェクトで育てていくことができました。

しかしそれでも、数々の試行錯誤が必要でした。プロジェクトがもしも、XP初体験者だけで構成されていたら、ずっと困難な道のりになっていたことは間違いありません。

ですから、みなさんもまずは自分たちにもできそうなこと、やってみたいことから少しずつ始めることをお勧めします。

プラクティス「継続的インテグレーション」

継続的インテグレーションは、自動化されたテストの実行を1日に何度も行うプラクティスです。Martin Fowlerの記事をきっかけに広く知られるようになりました。今ではサポートツールも数多く存在しています。

仕組みを育てていくうえでは、その仕組みが全体として機能しているか？を常に確認し続けることが重要です。

継続的インテグレーションは、問題を早期に検出するために、システム全体の結合を頻繁に実施します。ソフトウェアに対するこの考えは、そのまま開発プロセスにも応用できます。スタンドアップミーティングはその応用の一つです。

スタンドアップミーティング

スタンドアップミーティングは、起立して実施するミーティングです（写真2)。立ちっぱなしで行うので、1回あたりの所要時間はできれば10分、最長でも15分以内に収めるようにしましょう（1時間も立ったままミーティングすると疲れますよね⁠）⁠。ミーティングの目的は、作業の進捗やメンバーの状況を手短かに確認することです。実施のタイミングは、チームの一日の作業を始めるときです。実施頻度は毎日です。このことから「朝会」という呼び名でもよく知られています。

毎朝の短時間のミーティングは、メンバーの作業内容や、作業で感じた不便といったチームの情報をチーム内で頻繁に結合しているともいえます。スタンドアップミーティングは継続的インテグレーションをチームに応用したものだと説明した理由はここにあります。

スタンドアップミーティング（特に朝会）は私の周囲でも人気があり、よく実践されています。仕事を開始する合図としての効果が得られるのも利点です。

スタンドアップミーティングの進め方やコツについては『プロジェクトファシリテーション実践編 朝会ガイド』（⁠注11）や「朝会のパターン：立ってるだけじゃないよ」を参考にしてください。スタンドアップミーティングは「立ってるだけじゃない」のです。

夕会 ― もっと頻繁に結合する

私の周囲では、朝会を実施しているチームの多くが、夕方にもスタンドアップミーティングを実施しています（朝会に対して「夕会」と呼び慣わされています⁠）⁠。

夕会は、定時の直前に実施します。こちらも頻度は毎日です。所要時間は5分程度、長くても10分以内にします。その日一日の作業をふりかえって報告します。夕会を実施したチームからは「仕事をタイムボックスで区切るので、ダラダラした残業をしなくなった」という声を聞いています。これは、夕会には通常のスタンドアップミーティングの効果に加えて、次の2つの効果があるからです。

夕会のあとにも作業を続ける場合は、チームメンバーにその旨を伝えます。所用などで早退したいメンバーがいる場合は、朝会でその旨をあらかじめ伝えて、当日の夕会の開始時刻を調整するとよいでしょう。

今回のまとめ

今回の内容を、前回のまとめを拡張して図3にまとめました。

また次回お目にかかりましょう。読者のみなさんの仕組みがアジャイルに育ちますように。acts_as_agile!