僕は、偉大なプログラマなんかじゃない。偉大な習慣を身につけたプログラマなんだ。

Kent Beck （⁠注1）

自分の仕事を憎むには人生はあまりにも短い

私は、200名程度という微妙な規模のSIベンダーに勤務するプログラマです。主に企業で利用する業務アプリケーションの構築に携わっています。

私には夢があります。業務アプリケーションのプログラマとしての夢です。

• 自分だけではできないことをチームで成し遂げたい
• チームの成果が誰かの役に立ってほしい
• チームの成果に対して適切な報酬を受けたい

「自分の仕事を憎むには人生はあまりにも短い⁠」⁠。Joel Spolskyのこの言葉[2]と同じ思いを私自身が抱きはじめたきっかけは、2冊の書籍との出会いでした。1冊は『達人プログラマー』（⁠注3⁠）⁠。もう1冊は『XP エクストリーム・プログラミング入門』（⁠注4）です。

この2冊に出会ってから数年後、縁あって現在の勤務先に転職したのを契機に、日本のいわゆるアジャイル開発コミュニティに参加し始めました。すると、私のような夢を抱いている人は、どうやら私一人ではないことに気づきました。

この連載について

連載タイトルにある「アジャイル開発者」とは、アジャイルソフトウェア開発の実践者のことです。アジャイル開発者はソフトウェアをアジャイル（Agile）に――状況の変化へ迅速に適応しながら――開発します。アジャイル開発者のことを英語ではagilistと呼びます。

本連載では、アジャイル開発者としての私自身の実践経験と、私が出会ったアジャイル開発者との交流から気づいたことを、アジャイル開発者の「習慣」という切り口から紹介します。第1回である今回は、その準備としてまず、私なりにアジャイルなソフトウェア開発と、アジャイルな開発者について説明します。それから、今後の連載で紹介する習慣を身につけるための習慣（メタ習慣）として、「⁠フィードバックを重視する」習慣を紹介します。

アジャイルなソフトウェア開発

まず、連載の根幹に関わる「アジャイル」という（2007年現在では若干色褪（いろあ）せてしまった）バズワードを私なりに説明することから始めます。

アジャイルは形容詞

「アジャイル」という言葉は形容詞です。ですから、アジャイルソフトウェア開発とは「ソフトウェア開発がアジャイルである」という状態のことです。Chet HendricksonとRon Jeffriesは、この状態を「Early and Often（はやめに・こまめに⁠）⁠」という言葉で表現しています[5]⁠。

はやめに・こまめに

「はやめに・こまめに」が実現されている状態とは、ソフトウェア開発チームが次の条件をすべて満たしている場合です。

開発チームがこの「状態」を達成できるようになるための作戦を考えるのが本連載の目的です。次回以降の連載を通じて、項目のそれぞれに説明を加えていきます（ここで説明すると連載が終わってしまいます⁠）⁠。

ソフトウェアの時間的価値

なぜ「はやめに・こまめに」を実現させる――すなわちアジャイルに開発するのでしょうか。この背景にあるのは、ソフトウェアの価値に対する考え方です。ここでの価値とは、顧客にとってのソフトウェアの価値です。顧客にとってソフトウェアとは、実稼働してはじめて価値を生み出すものです。そこで、アジャイル開発ではソフトウェアの価値を次のように考えます。

アジャイルな開発が、ソフトウェア開発ライフサイクルの初期段階から（はやめに）リリース可能な状態を作りだすことで顧客価値の提供に備え、それを継続させる（こまめに）ことを重視するのは、ソフトウェアの価値の総量を最大化させるためです。

「達人プログラマー』の著者であるDave Thomasは、この考え方を「ソフトウェアの時間的価値」と表現しています[6]⁠。これは「明日の100円よりも今日の100円のほうが価値がある」という「貨幣の時間的価値」をソフトウェアに応用したものです。

ソフトウェアは人がつくる

ソフトウェアの時間的価値を最大化するために、開発チームがソフトウェアを「はやめに・こまめに」リリースできる状態を作りだし、それを維持する。この実現を目指す日々の活動がアジャイル開発です。そのためにアジャイル開発が前提にしている考え方があります。それは「ソフトウェアは人がつくる」という考え方です。考え方というよりも世界観と呼ぶべきかもしれません。

アジャイルに開発するからアジャイル開発

アジャイル開発の最小構成単位は、アジャイルに開発する個人です。アジャイル開発者たちの協働する自律的な場が、アジャイル開発チームです。

アジャイル開発では、開発プロセスはあくまでもチームが力を発揮できるよになるための手段です。必要に応じて（必ず必要になります）つくりあげ、改善されるものと考えます。つまりアジャイル開発とは、アジャイルに開発する人達が開発するからアジャイル開発なのです。

アジャイルな開発者

アジャイル開発では、チームの開発者がアジャイル開発者である――アジャイルに開発するスキルと心構えを備えている（または備えるようになる）ことに期待しています。

これは見方を変えれば、アジャイル開発はチームに参加する個人に依存しているともいえます。ですが、現代のソフトウェア開発は、事前に定義した開発プロセスに従いさえすれば、確実に成果を出せるほど単純なものではなくなっているのも事実です。

心構えとスキル

アジャイル開発者の心構えとは「はやめに・こまめに」の達成と持続を目指す態度のことです。

心構えなしに、アジャイル開発がうまくいくことはありえません。しかし、心構えだけでもうまくいきません。心構えだけで成功できるのであれば、いわゆる「デスマーチ」は絶滅しているはずです。

心構えと、心構えを実践できるスキルの両方が必要です。実践できるスキルに裏打ちされていない心構えは、絵に描いた餅です。

私は、アジャイル開発者としての心構えは、アジャイル開発者としてのスキルを磨いていく過程で内面化されていくと考えます。そのため、本連載ではスキルに焦点を当てて話を進めていきます。

スキルという言葉はさまざまな意味合いで使われます。本連載では、スキルを「開発者個人が身につけていて、開発チームのメンバーとしての日々の作業の中で実践できる技術」と考えます。

4つのスキル

先の「Early and Often」の講演資料によれば、アジャイル開発者に必要とされるスキルは次の4つです。

4つのスキルの詳細は連載を通じて紹介しますので、ここでは簡単な説明にとどめます。

ストーリの作成

「ストーリ」はシステムに要求される振る舞いを、顧客価値の観点から、顧客に理解できる語彙で散文的に記述したものです。ソフトウェアの価値とは顧客にとっての価値ですから、ストーリを作成できることは重要なスキルです。

計画づくり

アジャイル開発は計画を立てずにいきなりコーディングする――アジャイル開発に対するよくある誤解の一つです。確かにアジャイル開発では、作成された計画（Plan）を絶対視しません。その代わりに、状況に応じて計画づくり（Planning）を行います。アジャイル開発では計画づくりの実施頻度が高いので、1回あたりの計画づくりを効果的・効率的に行うスキルは重要です。

テスト駆動開発とリファクタリング

「テスト駆動開発」と「リファクタリング」は、アジャイル開発という文脈を越えて、開発者の重要なスキルであると認識されています。書籍も複数出版されています[7]⁠。本連載では、アジャイル開発の価値と目的に即した観点から改めて紹介する予定です。

アジャイル開発者になる

4つのスキルを身につけているだけでは、アジャイル開発者として十分ではありません。4つのスキルを磨く習慣を身につけている開発者、それがアジャイル開発者です。

習慣を身につける

本連載では、習慣を次の3つの要素から構成されているものと考えます。

習慣は、これら3つの要素が組み合わさり、内面化され、それを「当たり前」のこととして振る舞えるようになってはじめて「身につけられた」といえます。

私の経験と観察では、アジャイル開発者だと目されている人たちは、いくつかの共通する習慣を身につけています。連載を通じて、アジャイル開発者の習慣を身につけるために持つべきマインドセットと、実践可能なプラクティスを紹介します。心構えの内面化と実践を継続するのは、みなさん一人一人です。

まずは自分、それからチーム

習慣を身につけるにあたっての注意を一つ。紹介する習慣をいきなり開発チーム全体には導入しないでください。チームへの導入は、まず皆さん自身が試してみて、うまくいきそうなことを確かめてからです。実際にやってみせ、一緒にやることが重要です。私の経験では、自分でやっていないことを他人に強要してうまくいったことはありません。

習慣 #0　フィードバックを重視する

アジャイル開発者と目される人たちは、4つのスキルを磨くための習慣を身につけるための習慣、つまりメタ習慣やブートストラップ習慣とでも呼ぶべき習慣を身につけています。それが「フィードバックを重視する」という習慣です。今回はこのメタ習慣を紹介します。「⁠習慣を身につけるための習慣」なので、0番目の習慣としています。

マインドセット「実践から学習する」

実践すると、そのフィードバックとして経験が得られます。経験から学ぶことで、よりうまくなるための作戦を効果的に立てられます。ただし、いくらフィードバックを重視するからといって、ただ実践すればよいというわけではありません。実践と、そのフィードバックからの学習を「いつ・どうやるのか」を常に意識しなければなりません。

リズムをつくる

実践から学習するマインドセットを育てるためのプラクティスを2つ紹介します。「⁠タイムボックス化」と「ふりかえり」です。この2つを組み合わせて、実践と学習を繰り返すリズムをつくります。習慣は文字どおり「身につける」わけですから、リズムという身体感覚は重要です。リズムは、習慣として継続させるうえでも重要です。

プラクティス「タイムボックス化」

タイムボックス化は、時間と作業のマネジメント手法です。タイムボックス化では、プロジェクトや作業の期間を、一定間隔に固定された複数の「時間の箱」から構成されたものとみなし、期間中の作業を「時間の箱」に入るようにマネジメントします（図1⁠）⁠。

たとえば、作業期間が3ヵ月のプロジェクトに1週間単位のタイムボックスを適用すると、プロジェクト期間は、週レベルのタイムボックスが12個並んだものになります。

時間に対する意識

各タイムボックスに設定した期限は絶対です。延長はありません。「⁠週単位のスケジューリング」という言い方ではなく、あえて「タイムボックス」という新しい用語を導入しているのは、「⁠期限は絶対。延長なし」という考えを常に意識するためです。

もっと詳しく

タイムボックス化については「計画づくり」との関連で、今後の連載でさらに詳しく紹介します。まずはタイムボックス化では「箱」の大きさが固定されていることを理解してください。「⁠期限は絶対。延長なし」です。

プラクティス「ふりかえり」

ふりかえりは、レトロスペクティブ（Retrospective）やリフレクション（Reﾟection）とも呼ばれるプラクティスです。完了したタイムボックス期間中に行った作業をふりかえり、次のタイムボックスでの作業をより効率的にするための改善策を考えます。

実施するタイミング

ふりかえりは、タイムボックスが終了するごとに、定期的に繰り返し実施します。作業期間完了後に1回だけ実施される反省会とはこの点が異なります。1回のふりかえりのセッションに費す時間は30分から1時間の範囲内に収めます。ふりかえりに時間をかけ過ぎてしまって、実作業がおろそかになっては本末転倒です。

KPT法によるふりかえり

ここでは、私がよく行っているホワイトボードを使ったKPT法を簡単に紹介します。KPT法では、ホワイトボードの領域を三分割し、「⁠Keep」「⁠Problem」「⁠Try」と見出しを書き入れます（図2⁠）⁠。それぞれの意味は「よかったこと、次回も続けたいこと」「⁠よくなかったこと」「⁠次回以降に試したいこと」です。このホワイトボードを囲むようにして、ふりかえりを進めていきます。

KPT法の進行ステップ

KPT法によるふりかえりの進行ステップは、チェンジビションの製品であるTRICHORDの開発チームの手法が参考になります。ここでは進行のステップだけを紹介します。詳細は日経ITProのサイトに掲載されている記事を参照してください。

ふりかえりを効果的にするためには、特に（1）と（2）のステップが重要です。ふりかえりに慣れていない段階では、このステップに少し多めに時間を割くと効果的です。肝となるステップである（3）をスムースに進められます。

もっと詳しく

ふりかえりは、実践自体はとても簡単です。ただし、効果的に実践するにはコツが必要です。コラムに「ふりかえりの参考リソース」を紹介しておきます。実践の参考にしてください。

またTRICHORDの開発チームは、ふりかえり結果を開発者ブログでほぼ毎週、公開しています。ふりかえりをより効果的にするためのさまざまな試みも併せて紹介されており、参考になります。

acts_as_agile

連載の副題に掲げている「acts_as_agile」という言葉は、今回紹介した「フィードバックを重視する」というメタ習慣を踏まえたものです。人はアジャイル開発者であるかのように振る舞うことでアジャイル開発者になるのです。実践。フィードバック。学習。実践。フィードバック。この繰り返しによって、少しずつ、しかし確実にアジャイルな振る舞いを身につけていくのがアジャイル開発者への道です。

余談ですが、この副題はRuby on Railsの構成要素として有名なO/Rマッピングフレームワーク、Active Recordの振る舞いを拡張するメカニズムに由来しています[8]⁠。

今回のまとめ

今回の内容を図3にまとめました。

次回からは、アジャイル開発者の4つのスキルを磨いていくための習慣を支えるマインドセットとプラクティスを紹介していきます。またお目にかかりましょう。読者のみなさんにアジャイルな振る舞いが拡張されますように。acts_as_agile!