Romanticismこの広告は、90日以上更新していないブログに表示しています。2011-10-31静と動の往還としてのモデリングDesignDCIを参照しつつ「業務分析」について考えるはじめに最近「アジャイル」という言葉をなるべく使わないようにしています。この言葉に込められた「桃源郷へのあこがれ」が、色々なものを見えなくしてしまうような気がするから*1。アジャイルの基本は、「タイムボクシングによるインクリメンタルかつイテレーティブな開発」であると言え、それを実現するために流派によって様々なテクニックが提示されます。Scrumを見てみましょう。確かにタイムボクシングによる軌道修正がある程度できるとは言え、「優先順位の低いところは粒度が粗くてもいいよ」で先々問題が起きないとは、私にはどうしても思えないのです。どんなにプロダクトオーナーが先を読んでいても、どれほどチームが優秀でも、プロダクトオーナーとチームとの間で最終的なアーキテクチャが共有されていない限り、コードが先々の変化に耐えられるかたちになっているとはどうしても思えない。逆に言えば、網羅性と整合性が保証されたかたちでプロダクトバックログなり機能一覧なりが整備されていて、それを実現するためのアーキテクチャが定まっているのであれば、「それは、もう真っ当にウォーターフォールをやってもうまくいくのでは?」という気もします。継続的デリバリーのようなテクニックをウォーターフォールでは使えないかというと、それはまた別の話。して見ると、アジャイルかウォーターフォールかという区別は「アップフロントでの作業云々」ではなく、「何を固定するか」という話と社内事情とを照らし合わせたときに出てくる解ととらえるとすっきりします(これもよく言われることではありますが)。自社メンバだけで開発するという前提ならリソース固定(アジャイル)にならざるを得ないし、「どうしてもこの日までにこの機能を」というのがお客様のビジネスにとって必要なら、リソースのスケールアウト戦略(ウォーターフォール)を考える必要が出てくるでしょうし。前置きが長くなりましたが、こうしたことを踏まえて、いずれにせよ必要になるであろう「アップフロントな分析・設計作業」が本エントリの主題です。ソフトウェアをデザインする業務を分析してソフトウェアを設計する作業は、抽象度をコントロールしながらシステムのモデルを作り上げていく作業です。いうものを書かなければいけないかは、教科書を見ればいくらでも出てきます。このとき重要なのは、こうした複数のモデルが、1つのシステムの別々の側面を記述しているものであること。モデル1つ1つが、明確につながっていなければならないということです。このつながりが見えているかどうかが、設計の整合性と網羅性に決定的な影響を与えます。このつながりを考える上で、大きなヒントを与えてくれるのがDCIアーキテクチャです。システムが「どのようなものか」/「何をするのか」DCIの根底にある考え方を簡単におさらいします。DCIでは、人間がシステムをとらえる際には「システムがどのようなものであるか」と「システムが何をするか」の2つから考えているとします。その上で、オブジェクト指向のことを、後者を表現することには長けているが、前者をうまく表現することはできないと批判します。「人間のメンタルモデルを表現する」というオブジェクト指向の理念に従い、この「システムが何をするか」と「システムがどのようなものであるか」という異なる位相で重なり合う2つの軸を表現するために、ロールという概念が導入され、実装のためにScalaのTraitが提示されます(詳しくはこちら)。これを実装の話としてだけとらえてしまうと、実務で使うにはちょっと怖い感覚があるのですが、システムを「どのようなものか」と「何をするか」という2つの軸でとらえるという発想は、システムをデザインする上で大きなヒントを与えてくれます。この軸は「構造とふるまい」であり、「静と動」であり、「空間と時間」でもあるのです。静的なモデルと動的なモデル業務分析の入り口は、ユーザーの動きです。システム以前に、ユーザーが何をするのかがまず問題になるということですね。これを表現するためのテンプレートとしては、業務フローやユースケース、あるいはユーザーストーリーなど、そのコンテキストに応じて適切なものを選択すればよいですが、表現したいのはユーザーがシステムで何をしたいのか、それを踏まえてシステムは何をしなければならないのか、という動的な側面です。動的なモデルは時間軸を含むため、単一のモデルで全体を表現することができません。したがって、ソフトウェア全体を俯瞰するためには、つまり「システムがどのようなものか」をとらえるためには、時間軸を無視して全体を一枚に表現する静的なモデルが必要となります(Copeであれば、空間的という表現を使うでしょうか)。それは、ユースケース図かもしれないし、機能構成図かもしれないし、ER図かもしれない。どのかたちに落とすのが適切かは、先行する動的モデルの性質と精度によるでしょう。静的なモデルを引くことにより、先行する動的なモデルの検証も行うことができます(「これがあるということは、こういうこともしないといけないですよね?」)。して出来上がった静的なモデルは、今度は動的なモデルによって検証されることになります。静的なモデルの構成要素が登場するインタラクションを時間軸を導入しつつより具体的なレベルで分析することで、必要な要素が抜けていないか(網羅性)、構成要素に矛盾がないか(整合性)といったことを検討できるのです(「これをやるためには、こういうものも必要ですよね?」)。このとき重要なのは、「動的」という言葉が時間軸を含んでいるということです。「メッセージング」のような概念はそれ自体が動的であるかのように思えますが、単純に2つの構成要素間でメッセージングが行われていることを示しているだけなら、それは静的なモデルです。コンテキストを限定し、時間の流れとともに何が起きるのかを追跡するのが動的なモデルだということです。して、全体像とその動き(静と動)をクロスチェックしながら、抽象的なところから具体的なところに落としていくことで、その作業の結果が設計成果物となっていくわけです。プログラムをデザインするこうした静と動の関係は要件定義フェーズだけに限定されるものではなく、成果物の抽象度が詳細レベルまで落ちてきても本質的には変わりません。ER図の妥当性は最終的にはSQLを設計する際に検証される、ということです。Pryceの提唱している「モックを使ったTDD」がうまく当てはまります(「モックを使ったTDD」について詳しくはこちら)。「この入力に対してはこの出力が返される」という仕様は静的なものです。モックを使ったTDDの場合、実装時にはユニットテストコードを書きながらオブジェクトとコラボレーターとのインタラクション(動的)を規定していきます。テストコードがグリーンになったら、今度はコードを静的な構造としてとらえ直し、コラボレーターとしてのインターフェイスを実装したクラスの配置をリファクタリングします。ここではTDDのサイクルが、静と動との往還と一致しているのです。まとめ「システムがやること」と「システムのあり方」あるいは「静/動」という概念を軸に、設計について考えてきました。最後に、ドメイン駆動設計について少し触れておきたいと思います。ソフトウェア開発の実践)』の中で登場するのは、ほとんどがエンティティ同士の関係を示す静的なモデルです。これらの静的なモデルを作り上げる過程では、シナリオの中でそうしたエンティティがどう動くのかという動的な側面が、顧客との対話の中で考察されていることが読み取れるでしょう。事実、DDDを行うプロセスとして現在エリックが整備している「モデルを探究するうずまき」*2では、動的な要素としてのシナリオと、静的な要素としてのモデルとの往還関係を繰り返しながらモデルが進化していくとされています。Copeが「アーキテクチャ」という言葉を使うときには、システムをとらえるためのこうした大きな枠組みが含まれています*3。したアーキテクチャに対する思考は、アジャイルであれ、ウォーターフォールであれ、ある程度はアップフロントに行うべきものだと思うのです。12:58静と動の往還としてのモデリングTweet広告を非表示にするもっと読むコメントを書く2011-09-27モックによるインターフェイスの発見TDD設計ツールとしてのモックの使い方について考える。Objects"の日本語版「ロールをモックせよ」を公開しました。Walnes氏という豪華メンバーです。Object"で語られている思想はGOOSのベースになっているとも言えます。Objects"(以下、MRnO)で語られているモックの基本的な考え方について、GOOSを意識しつつ掘り下げてみたいと思います。設計手法としてのモックまずは"MRnO"で紹介されているサンプルを元に具体的なコードを見ていきましょう(なお、このエントリで紹介するサンプルは"MRnO"を元にjMock2に移植したものです)。実装する仕様は以下の通りです:オブジェクトをロードするフレームワークに対してキーを元にした検索を行い、その結果をキャッシュするコンポーネントを考えてほしい。ロードされてから一定時間が経つと、そのインスタンスは使えなくなる。そこで、時々リロードをしなければならなくなる。Objects(p.7)最初はシンプルな正常ケースを書きます。is("VALUE1"));}「cache.lookup()のタイミングで、TimedCacheのコンストラクタに渡されているmockLoaderのloadが呼び出され、その際には"VALUE1"が返されるのでlookupの戻り値も"VALUE1"になる」というからくりです。重要なことですが、この時点ですでにObjectLoaderというコラボレーター(隣接オブジェクト)が発見されています。図示するとこんな感じ:1つ補足しておくと、ここでObjectLoaderをモック化しているのは、それが外部リソース(DBなど)にアクセスしているっぽかったり、サードパーティーライブラリを想定していたりするからではありません。テスト対象のオブジェクトが動作する上で必要なコラボレーターを、テストを書きながら発見することがモックを使ったTDDの中核です。この後、2回目に呼ばれたときにはObjectLoaderを呼び出さずにキャッシュを使うテストも当然書かなければいけないのですが、アサート文が2つになるだけですので省略します。}}さて、ここで時間の概念を導入しましょう。仕様書にあるこの一文ですね。「ロードされてから一定時間が経つと、そのインスタンスは使えなくなる。そこで、時々リロードをしなければならなくなる。is("NEW-VALUE"));}図に表すとこんな感じ:モックを使ったTDDのユニットテストが通常のTDDと大きく違う点が、実はここに現れています。通常のTDDの場合、こうしたコラボレーターが登場するのは「レッド・グリーン・リファクタリング」のうち、主に「リファクタリング」のプロセスになります。動くようにした上で、より適切な責務分割を目指すわけですね。それに対して、モックを使うとコラボレーターは、テストを書いている段階すなわちレッドの手前で登場します。実際に写経してみるとわかるのですが、登場するオブジェクトとそうしたオブジェクト間のインタラクションを相当はっきりイメージできていないと、テストを書くことができません。この意味で、モックを使ったテスト駆動開発ではテストを書くことが設計することに直結するわけです。ここで設計されるのはあくまでオブジェクト間のインタラクションであり、クラスではありません。「では、クラスはどうやって設計するのか?」という疑問が当然出てくるわけですが、GOOSを読むと、いったんはインターフェイスの匿名クラスとして実装し、あとから名前のついた適切なクラスを抽出するというスタイルがとられていることがわかります。して抽出されたクラスの内部で責務があいまいだと感じた場合には、再びユニットテストを書いてコラボレーターを発見するというプロセスを繰り返すことになります。受け入れテストを書くこれが、このアプローチが「外から内へ」と言われる理由です。外側(=システムへのエントリポイント)に近い場所からユニットテストを書き、インターフェイスを発見しながら内側へと入っていくわけです。すると当然、「最初のテストはどこから書き始めるのか」という疑問が生じると思いますが、それに対する答えは「まず受け入れテストを書く」ということになります。全体を図示するとこんな感じでしょうか:実際には、受け入れテストをグリーンにする過程で必要に応じてユニットテストを書きつつインターフェイスを発見し、グリーンになった後も責務があいまいなクラスに対してまたユニットテストを書き、という具合にループが2重になっています。受け入れテストの話とユニットテストの話は別々のものであるようにも見えます。モックを使ったユニットテストが、オブジェクト間のインタラクションという内側にフォーカスしている分、システムが全体として正しく動いているかという外側を明示的に意識する必要があると考えれば、両者をまとめて1つのプロセスとする考え方は筋が通っていると言えるでしょう。「受け入れテスト+モックを使ったユニットテスト」をセットで考えれば、ユニットテストを書くという行為自体が従来のリファクタリングフェーズに当たると考えることができるかもしれません。development)とも強い親和性があります。「システムが何をすべきかをテストで表現する」ことにより、どこから始めればよいか、どうすればそのフィーチャの実装が完了したと言えるのかという問いに同時に答えることができるのです。最後にプログラマにとって、コーディングをしながら構造を発見していくプロセスというのはかなりエキサイティングに感じられるものですが、現実問題として本当に何もないところからこれを始めるのはいつになったら終わるのか全然わからないという怖さがあります。したがって、ある程度は事前に分析/設計を行い、大まかな構成のメドを立てておく必要があるということになります。Front"を避けつつも、事前の分析/設計を適切に行うバランス感覚が重要だということですね(それが簡単にできれば苦労はしないという話ですが)。モックに興味を持たれた方は、ぜひ「ロールをモックせよ」を読んでみてください。ここで取り上げたこと以外にも重要な示唆が色々と書かれています。サンプルコードはこちらで公開しています。08:29モックによるインターフェイスの発見Tweet広告を非表示にするもっと読むコメントを書く2011-08-29SIを仕事にするということEssayパラダイムを学ぶことと、実際にデリバリーすることとのバランスについて。導入8月1日にグロースエクスパートナーズ株式会社に入社しました。人生で2回目の転職となります。入社してまもなく一ヶ月が経とうとしていますので、本日はその報告を。ブログ、翻訳、プレゼンに続く舞台裏記事の第4段ですね。私とは違う物事のとらえ方をする方々も多くいらっしゃることは重々承知しておりますし、それを批判するものではないこともあらかじめご了承ください。私が7月まで勤めていたのは、いわゆる「ITゼネコン」と呼ばれる元請けSIerでした。開発の実務は協力会社さんにお任せしつつ、自分はメールと打ち合わせに埋もれる日々を送っていたわけです。要件定義から保守まで一通り経験できたという意味で学ぶこともありましたし、アーキテクチャ策定やデータモデル設計のようなことも隙を見てやっていたことは事実ですが、ソフトウェアを作るということと自分との間に、どうしても超えられない壁が立ちはだかっているような感覚が拭えませんでした。これを読む多くの方がいろいろな立場で普段職場で目にしているであろう「アレ」と言えば、大体おわかり頂けるでしょう。それと平行して、DDDやDCIといったソフトウェアのパラダイムを学びつつ、それをアウトプットする作業もここ数年で実を結び始めていました。DDD日本語版の翻訳は自分にとっての1つの大きな成果ですし、DevLOVEをはじめとしたコミュニティでも話をする機会を頂けるようになりました。要するに「仕事は日々の糧を得るための手段として割り切り、空いた時間で勉強をしつつ、コミュニティに対してアウトプットしていく」という日々になっていたのですが、やはり自分の中にある矛盾が少しずつ大きくなっていきました。エリックとの約束4月にDDDの著者であるエリックが来日し、かなりいろいろなことを話すことができました*1。エリックと会うまでは、DDDを理論書としてとらえていたのですが、本人と会って話したことでずいぶんと考えが変わりました。野村さんとの会話その後、ジュンク堂様にてフューチャーセンターファシリテータの野村さんとトークセッションを開催する機会を頂きました。事前準備のときに、「ユーザとのコミュニケーションの中で業務のとらえ方を理解し、ソフトウェアを作っていく*2」ということを話した後で、野村さんから「そういう開発をしてほしいという人がいた場合、どこにいけばいいですか?」と訊かれました。すごく素朴な質問だったと思うのですが、それに対して「僕に紹介してください」と言えなかったことが、本当に恥ずかしかったことを覚えています。結局のところ、組織に守られながらその組織に対して文句を言い、自分という人間を認めてくれる人たちの中で夢を語るのは、ものすごく居心地がよく、楽なことでした*3。それは、中学生が小遣いをもらいながら自分の母親をけなし、仲間内でギターを弾いて悦に入っているのと変わらない。「じゃあそれ、路上で、知らない人の前で胸を張って弾けるの?それで金を稼げるの?」それをやろうと思ったときに目の前に立ちはだかるのは、「生々しい現実」です。要件定義はやったことがあるし、設計も保守もやったことがある。アジャイルや設計手法の本も割と読んでいる。「自分でリードしながら開発をやり切ることができるのか?」と問われたときに、胸を張ってできると言う自信はありませんでした。ユースケース記述のフォーマットを知っていることと、実際にユーザーさんとやり取りをしながら実装可能な設計に落とし込むこととの間には、「ボクシングジムに通うこととリングに立つこと」程度の開きがあります。私にはまだ、師が必要なんですね。前後するのですが、転職自体はDDDを翻訳する前から考えていました。いうより「DDD翻訳の仕事が入ってそれどころではなくなった」という表現が正しいですね。今のIT業界では「SIerからサービスを提供する企業へ」という人材の流れが(少なくとも私の周りでは)起きているように感じていますので、それについても少し触れておきます。私も「実装技術」のようなものにもっと焦点を当てて力を伸ばしたいと思った時期もあり、非SIerへの転職を目指そうと思ったこともありました。私には「専門的で特殊なアルゴリズムを実装するスキル」はありません。それを育てたいとも思ったのですが、あまりそこをゴリゴリやっている自分の姿をリアルにイメージできなかったのは事実です。私には「漠然とした物事を言語化する」「物事を抽象的にとらえて、論理的に切り分ける」という作業が似合っているのでしょう。いう経緯とDDDからの流れがシンクロして、「バリューストリームの中で自分の手を動かしつつ」「企業をお客様として業務に使うアプリケーションを作る」ためには何をしたらいいかを考えるようになりました。一時は自分で会社を作ることも考えたのですが、尊敬する友人*4から何冊か本をプレゼントして頂き、それを読んだ結果、踏みとどまることにしました。Tokyoをきっかけとしたゆうすけさんとの出会いがあったおかげで、「探す苦労」をせずにすみました。本当にいろいろな方に助けられて今の自分があると思います。GxPは「DDDでの開発」や「アジャイル開発」を必ずしも前面に押し出している企業ではありません。「ソフトウェアを作る」ということを、ものすごく真っ当にやっている会社です。手法としてのDDD、手法としてのアジャイルが強調されることはなくても、DDD的モデリングやチケット駆動型の開発がごく当たり前のものとして普通に行われています。これはとても健全で、正しいことだと思うのです。入社してからの4週間でやったことを挙げると、こんな感じです。Actionを読み返す見て頂いてわかるとおり、上流/下流という区別なく、割と何でもやっている感じです。「華々しいこと」は特にやっていません。スタンドアップミーティングもやってないし(朝会はそろそろやる)、顧客の前でドメインモデルを書いたりもしていない。壁にバーンダウンチャートが貼ってあるわけでもない。テストコードは必要に応じて書きますが、ペアプロやいわゆるTDDも特にやっていません(これは声をかければできるかも)。提案書はパワポで書いていますし、表を作るときにはExcelも使います。機能一覧とかテストケースもExcelで書いています。要するに「アジャイル」と「ウォーターフォール」という区別にこだわらず、必要なことを当たり前にやっているだけです。「アジャイル」という言葉にこだわるあまりにウォーターフォール的なものを忌避しすぎると、不幸なことになると思うんですよね。大きな変化は、仕事に関してグチや言い訳を言わなくなったことでしょうか。上司は話がわかるし、仕事ができる方々に囲まれている。ミスしていないわけではないし、見落としをリカバリーするために会社に泊まったりもしましたが、それも自分で勝手にやったことです。すべてに自分の手が届くこの状況下では、何かあれば完全に自分の責任ですよね。まとめソフトウェアをデリバリーすることには、多くの「泥臭い作業」が伴います。その「泥臭い作業」は本に書かれたり、語られたりすることがあまりない。それはたぶん、語るまでもなく当たり前のことであったり、語れるほどには言語化されていなかったり、語るほど面白くなかったりするせいでしょう。いって、「そういうこと」をしなくていいわけではない。このあたり、パラダイムと泥臭い作業をひっくるめた「デリバリー」の全体像が見えずに苦しんでいたわけですが、他にもそういう方はいるのではないかと思います。「バリューストリームの中で自分の手を動かしつつ」「企業をお客様として業務に使うアプリケーションを作る」ことができる場所があるんだということは、多くの方に伝えたいメッセージです。コミュニティで出会った人と働くことに、少し怖さはありました。プレゼンをするときにはそれなりの準備をしてデキるコっぽく装うわけですが、仕事となれば完全に生身での勝負ですからね。「がっかりされたらどうしよう」とかは当然思うわけです。あんたいつまでも...大人になってもひとりじゃなんにもできない方がもっとこわいとは思わないの?」ということですよ。あしたって今さ!あわせて読みたいhttp://www.arclamp.jp/blog/archives/ugoki_design.html*1:豆蔵の羽生田さんをはじめ、この機会を与えてくださった多くの方々に感謝します*2:当たり前のこと、というより他にどうやるのか、今となっては謎ですが*3:誤解が怖いので念のため強調しますが、コミュニティがそういう人の集まりだと言っているわけでは断じてありません。「自分がどう向き合うか」というきわめて個人的な問題です。*4:最近幸せそうなあの人です。Agileオーム社様と監訳者の方々より献本いただきました。厚くお礼申し上げます。見るはじめにまずは「読者の声」から:最初は、軽いノリの入門書だろうと高をくくっていた。「マスター・センセイ」だし、そもそも「サムライ」だし。軽い文体とは裏腹に、アジャイルな開発のありかたが、きわめてロジカルかつ網羅的に語られている。ありそうで、なかった本。手元に置いておけば、きっといいことがあるはずだ。私はこの本に査読者として関わらせていただきました*1。原文も含めてかなり丁寧に読み込んだという自負はあるのですが、「読者の声」として書かせていただいたのはそのときの率直な印象です。要約すればこの言葉に尽きるのですが、書評としましては、「アジャイルな開発のありかたが、きわめてロジカルかつ網羅的に語られている」この一文をもう少し展開することにします。アジャイルな開発のありかた「アジャイル」という言葉はずいぶんと色々な誤解に取り巻かれているように思います。端的に言えば「ウォーターフォールに対するアンチテーゼ」という側面に目が行きすぎて、ウォーターフォールのいやなところを解消してくれるもの、というイメージを持っている人が多いのではないでしょうか。「あの大量のドキュメントから解放される」と思っているエンジニア、「いつだって要件を変えていい」と思っている顧客・・・。確かにアジャイルならそういうこともできるかもしれませんが、そのためにやらなければいけないことがあるはずです。「アジャイルな開発のありかた」という表現をしたことには理由があります。この本の中心に据えられているのが、ペアプロやテストファーストといったプラクティスに留まらず、そもそものアジャイルの目的であるということを伝えたかったのです。第1章「ざっくりわかるアジャイル開発」を開くと、まず目に飛び込んでくる絵にはこう書かれています。「お客さんにとって価値ある成果を届ける・・・毎週ね!」―動くソフトウェアを顧客に届け、そこからフィードバックを受け取る。そのためにどうすればよいか、ということが語られている本なのです。ロジカル文体の軽さと論理的な厳格さは両立し得るものだということを、私はこの本で学びました。「ロジカル」という言葉で表現したかったのは、「構造がしっかりしている」ということです。どの話も、ベースとなっている理念から始まり、それを実現するためにはどうすればよいかが1つ1つ積み上げられて語られています。これは言い方を変えると、この本を読むことでそれぞれのプラクティスを「なぜやらなければならないのか」がわかるようになるということであり、同時に「実際にどう使えるか」がわかるようになるということです。本書のハイライトのひとつである「インセプションデッキ」の説明も、「プロジェクトがだめになってしまうのは、最初の認識が合っていないからだ」という話から始まっています。インセプションデッキをはじめ、リリースボードやバーンダウンチャートについても、実際にどう使うのかということが丁寧に(そして面白く)語られているのです。単純な「書き方」を示したハウツー本とは一線を画していると言っていいでしょう。「アジャイル開発が大切にしている価値とは何か」から始まり、チーム作り、認識合わせ、計画作り、要件定義、イテレーションの回し方、さらにはユニットテストやリファクタリングといったかなり具体的なプラクティスまで、アジャイル開発を実践する上で必要になるであろうことが一通りこの薄さに収まっています。その分表層を触っただけかというと、そんなことはありません。ユーザーストーリーとして書き留めておくべき要件の粒度やそれをどう使うかといった話にもきちんと触れられています。逆にアジャイル開発に関する本を何冊か読んだことがある人であれば、「いまさらこの薄さの本を読む必要はないだろう」と思うかもしれません。そんなこともありません。インセプションデッキの話は本邦初公開ですし、それ以前にチームメンバーに求められるロールや、運営の手法など、必ず新しい発見があるはずです。こんなことができるのか正直不思議なのですが、おそらくは「豊富な実践によって蓄積した知識を自分の言葉で語っているだけ」ということなのでしょう。「恐ろしく頭のいい人」それが私が著者に対して抱いているイメージです。最後に翻訳書として見たときに、本書の素晴らしいところをあとふたつ挙げておきましょう。1つは「訳質」、もう1つは「監訳者あとがき」です。訳質については実際に手にとってご覧いただきたいのですが、翻訳であることを意識させないレベルで完璧な日本語になっています。訳語の選択についても練られていて、「期待マネジメント」という少し耳慣れない言葉に対しては、日本語版だけのコラムが付いていたりもします。監訳者あとがきも必読です。本書の内容について整理しつつ、アジャイルの歴史の中にしっかりと本書が位置づけられています。アジャイル開発について学びたい人のための金字塔が打ち立てられたことを、心からお祝いします。「とにかく読んでみてください」が私からのメッセージです。「アジャイル」という言葉を見て、「自分には読む必要がない」と思ってしまう人がいるかもしれませんので、すこし蛇足を加えます(そういう方がこのエントリを読んでいるかどうかは甚だ疑問ですが)。ここで語られているのは、「顧客に価値を届けるための方法」です。職場がウォーターフォールであっても、Wordで要件定義書を書くのだとしても、この本で語られている内容は必ず役に立ちます。副題にある「達人開発者」とは、「コードを書く人」ではなく、「顧客の願望をかたちにして届けることのできる人」なのですから。※なお、冒頭にAmazonのリンクを貼りましたが、PDFが必要な方はこちらのオーム社さんのサイトからご購入することをお勧めします。Groovy著者の方々より献本頂きました。厚く御礼申し上げます。見るはじめにまずはじめに、これはGroovyを好きな方々、Groovyのことが気になっている方々にとっての必携書になると思います。素晴らしいお仕事をなさった著者のみなさまに感謝します。本の紹介をする前に、私のGroovyに対するポジションを明らかにしておきたいと思います。過去の記事を見て頂けばおわかり頂ける通り、私は時々Groovyを触っています。DSLを書いてみたいとき、DCIアーキテクチャで何か作ってみたいとき、モダンTDDを試したいとき・・・。意図が伝わりやすいGroovyのコードと、動くアプリが一瞬で作れるGrailsは、私にとって実に頼もしいツールです。「ちょっと待て、Scalaのエントリも書いているじゃないか」そうですね、先日のTDDBC仙台でもScala組だったように、私は時々Scalaも触っています。「どっちなんだ?」私自身はこの2つの使い分けをかなり意図的に行っています。一言で言えば、「ScalaはネクストJava、Groovyは軽量Java」です*1。Scalaを使うときには、Scalaの持つJavaにないパラダイム、特に関数型のパラダイムを学ぶためという明確な目的があることが多いです*2。逆に、とにかくさらっとコードを書きたいときにはGroovyを選択しています。いう意味で、動的言語的な破壊力を隅々まで知り尽くしているわけではありません。いう比較的中立的(?)なGroovyユーザの視点で書かれた紹介だと思って続きをお読みください。概要この本の対象読者について、「はじめに」に書かれている言葉を引用します。本書の対象読者としては、Groovyのことをまだあまりよく知らないJavaプログラマを想定しています。(p.vi)もうすこし補うと、Javaをそれなりに使い込んでいて、Javaの「面倒なところ」も含めて理解している方のツボにはまるのではないかと思います。1点、この本の読み方ですが、まずは適度に写経しながら全体をさらっと通読してみるのがいいと思います。細かいAPIは表形式でまとめられていますので、必要に応じて後で調べることができます。頭の中に、「あ、こんなことができるんだ」というインデックスを作ることが重要だと思います。以下、勝手に3部に分けてみました。「まだGroovyに触ったことがない」という方は、第1章「Groovyの世界へようこそ」をさらっと読んでみてください。「Javaを置き換えるとまでは言わないけれど、とりあえず使えるところから使ってみなよ、便利だからさ」というGroovyの声が聞こえてくると思います。第2章「Groovyの利用方法」は開発環境整備です。これから準備される方はここを見ながらどうぞ。IDEとしてIntelliJがイチオシされていますが、初めてGroovyに触るのであればエディタの方をお勧めします。整ったら、ぜひ第3章、第4章を写経してみてください。第3章「プログラミング言語Groovy」ではBeanやGString、クロージャ、コレクションなどGroovyの「軽量」度合いがよく伝わると思います。Beanであれば余計なものを一切書く必要がありません。JavaでもIDEを使えば自動生成できますが、リファクタリングでフィールドが移動する場合などを考えると結構メンテナンスが面倒であることや、そもそもの圧倒的な可読性のよさを考えると、やはりこうやって書けるのはうれしいものです。第4章「Groovyのライブラリ」ではGroovyに準備されているさまざまなライブラリが紹介されます。ここで紹介されているものは、笑いがこみ上げるくらい小気味よいものばかりです。こんなXMLを出力する処理を考えてみてください。