以下の文章は、Peter Stevensによる「10 Contracts for your next Agile Software Project」の日本語訳である。 Creative Commons ― 表示-非営利 3.0 Unportedの条件下で、ここに掲載する。 次のアジャイルソフトウェアプロジェクトに使える10の契約 2009/4/29 by peterstev ソフトウェアサービスの顧客であれサプライヤであれ、ソフトウェア開発プロジェクトの最初の頃というのは、口約束だけでいろんな仕事をやらなくちゃいけない。 契約書というのは、言ってしまえば、競技のルールがだらだらと書かれてあるものに過ぎない。 ルールが正しければ、顧客にとってもサプライヤにとっても、成功する確率が高まる。 ルールが間違っていれば、お互いに協力することも難しいし、進捗だって妨げてしまう。 それでは、アジャイルプ

http://martinfowler.com/bliki/CheaperTalentHypothesis.html 2008/2/8 ソフトウェア業界では、才能あるプログラマのほうが生産性が高いとよく言われる。 生産性は計測不能なので証明はできないのだけど、おそらくそれは正しいだろう。 人間の活動のほとんど全てにおいて、他人よりも優れた人がいるのである。 そしてその違いは、著しいことがしばしばだ。 ソフトウェア業界においては、プログラマ自身がその違いに気づくことが多い。 ただ、その場合も常に自分を「才能ある方」に入れているみたいだけど。 当然ながら、優れたプログラマは、フルタイムで雇うにせよ契約するにせよ、その単価は高い。しかし、たとえ単価が高いとしても、高価なプログラマのほうが実際には安価なのではないだろうか？ バカげた質問に聞こえるかもしれない。 何をどうしたら高価な人材が安価になる

http://martinfowler.com/bliki/PreferDesignSkills.html 2008/1/18 雇用について考えてみよう。 応募者が2人。どちらも経験が数年間。 青コーナーの人には、あなたが好きな設計スタイルの広範な設計力が備わっている（私の場合だと、DRY、分別のあるパターンの使用、TDD、伝わるようなコード、なんかが挙げられるけど、自分の好きなやつでいいよ）。ただし、彼女には、あなたが使っているプラットフォーム技術についての知識がない。 赤コーナーの人には、そういった設計の知識は（それに興味も）ないが、プラットフォーム技術についての知識はめちゃくちゃある。言語には詳しいし、どのライブラリが使えるかはよく知ってるし、ツールも流暢に使いこなす。 これ以外のことについては（こうした思考実験以外については）、2人ともまったく一緒だとしよう。 また、あなたのチーム

http://martinfowler.com/bliki/ObjectMother.html オブジェクトマザーとは、テストで使用するクラスである。 これはテスト用のサンプルオブジェクトを作るのに役立つものだ。 それなりの規模のシステムでテストを書くとき、 膨大なサンプルデータを用意する必要があるだろう。 たとえば、従業員の疾病手当の計算をテストする場合だと、従業員が必要になる。 これは単なるオブジェクトではなく、配偶者の有無、扶養家族の人数、勤務履歴、給与履歴などのデータが必要である。 もしかすると、オブジェクトを大量に生成しなければならないかもしれない。 こうしたデータは一般に「テストフィクスチャ」と呼ばれる。 まず、フィクスチャをxUnitテストのsetUpメソッドで作成して、 複数のテストで再利用できるようにする。 ここでよく面倒となるのは、同じようなデータが複数のテストクラスで

http://martinfowler.com/bliki/RollerSkateImplementation.html 2007/9/9 アジャイル開発の重要な特性として、小さな機能サブセットに分割してシステムを稼動させる方法をあれこれ考える、というものがある。 我々は、ソフトウェアがもたらすビジネス価値のためにソフトウェアを構築するのである。 システムの稼動が早ければ、それだけそのビジネス価値（の少なくとも幾分か）を早く手に入れることができる。 同僚のDave Leigh-Fellowsがこの考えにまつわる話を教えてくれた。 私はこの話が大好きだ。 我々が株式仲買業者の仕事をしていたときのことだ。 彼らは新しい商品を市場に投入したいと思っていた。 このためにソフトウェアが行うべきことは、顧客がWebフォームに入力した情報を使って必要な処理を行い、裏のバックエンドシステムにデータを受け

http://martinfowler.com/bliki/CustomerLoyaltySoftware.html 2007/9/4 先週、カナダのカルガリーオフィスでJohn Kordybackと楽しい会話をすることができた。 彼は最も信頼できる技術リーダーの1人だ。 彼は、旅行関係のロイヤルティソフトウェアシステムに従事（というか、どっぷり漬かって）いる（たとえば、Frequent FlyerやSleeperなどだ）。 我々は、これらのシステムの本質について、 そして、 より実りある方法で考えるにはどのようにすればよいか、 といったことについて話し合った。 ロイヤルティシステムの肝は、ポイント（やマイル）の記録にある。 顧客は自分のポイントを参照できなければならないし、会社はまだ引き換えられていないポイントを管理できなければならない。 多くの人はそうは思わないかもしれないが、実はこれ

http://martinfowler.com/bliki/OneLanguage.html 開発努力において言語は１つだけにすべきか？ エンタープライズ・ソフトウェア界の流行はここ10年の間ずっと、ソフトウェア開発努力のための1つの標準言語に集中することだった。 多くの開発組織が、すべての作業をJava(とかC#/VB)でこなそうとしている。 これの理論的根拠は、開発者が1つより多くの言語に熟練するのは困難だということだ。単一の言語にこだわり続ければ学習の負荷は下がる。とりわけ新人を採用するときに効果がある。 まあ真実もちょっとはあるけど、大抵は大外しだ。プログラミング環境ってのは一部は言語だけれど、でも複数の言語やフレームワークについてでもある。大規模フレームワーク、HibernateやStrutsやADOなんかは、単一のホスト言語でプログラミングしていたとしたって、今や1つの言語を学

朝会（デイリー・スタンドアップ・ミーティング、デイリー・スクラム、デイリー・ハドル*1、朝のロールコール*2）を説明するのは簡単だ。チーム全員が毎日顔を合わせ、現在の状況を迅速に確認しあう。立ってやるのはミーティングの時間を短くするためだ。以上。 でもこれだけじゃあ、「良い朝会」と「悪い朝会」の微妙な違いは分からないだろう。 朝会の定義は非常に簡単なものなのに、 うまくいっていない朝会があって私はとても驚いた。 すぐに原因は分かったが、そのチームはそれが何なのか分かっていなかった。 朝会の基本原則と詳細を意識していなかったのだ。 そのために朝会の問題について診断や解決がなされていなかったわけだ。 良い朝会を経験した人たちは、 うまくいってないときに何をすればいいかを知っている。 朝会に慣れていない人たちは、 うまくいってないときに何をすればいいかに気づかない。 「暗黙知なんだから、とにかく

http://martinfowler.com/bliki/Transactionless.html 2007/3/18 (更新：Bill Caputoからも経験談をいただいた) 数年前にeBayで働く友人たちと話していたときのことだ。 大規模サイトで使われる技術の話を聞くのはいつも楽しいが、特に興味深かったのが、eBayでは滅多にデータベーストランザクションを使用しないという話だった。 トランザクションがない環境というのは驚くべきことではないだろうか。 データベースを扱うときにトランザクションを使うのはごくごく一般的なことだ。 多くの人にとって（私もそうだが）トランザクションはデータベースを使う利点のひとつだ。 eBayがトランザクションを使わないのは、あのような規模ではパフォーマンスに影響が出てしまうからだというものだった。 eBayではデータをいくつもの物理的データベースにパーテショ

http://martinfowler.com/bliki/LocalDTO.html （最後の部分を更新） ThoughtBloggersをよく見ているんでしたら、 fowlbotのひとりが怒っているのをご存じかもしれません。 オーストラリアの太陽がスウェーデンのモデルをジリジリと焦がしています。 JonはData Transfer Objects（邦訳）にムカついているようですが、 これはDTOが悪者ということではありません。 他のパターンと同様、ある文脈内でのみ有用というだけのことです。 パターンは常に2つの部分に分けられます。 「どのように使うか（How）」と「いつ使うか（When）」です。 実装の仕方を知るだけでなく、 いつ使う（使わない）べきかも知っておく必要があるのです。 彼はポイントを突いています。 私はリモートインターフェースという文脈でDTOを語っていますが、 パターン

http://martinfowler.com/bliki/InterfaceImplementationPair.html すべてのクラスをインタフェースとペアにする手法である。 たとえば、ICustomerとCustomer、CustomerとCustomerImpl?のようなペアができる。 この場合、インタフェースと実装の型が分かれてしまうが、 これは、各クラスにヘッダファイルを付けるというC/C++の慣習を踏襲しているためである。 この手法のメリットは、 インタフェースの実装を別のものにすることで、 いつでも丸ごと入れ替えることができる点である。 ただ、私はこの手法があまり好きではない。 複数の実装がないのにインタフェースを使ってしまうと、インタフェースと実装とを同時に変更しなければならない分、手間がかかるからだ（IDEが補完してくれるが、やはり面倒だ）。 また、これだと裏に複数の

以下の文章は、Kent Beck、Ward Cunninghamによる「Using Pattern Languages for Object-Oriented Programs」の日本語訳である。 Ward Cunningham氏の許可を得て、ここに掲載する。 Kent Beck, Apple Computer, Inc. Ward Cunningham, Tektronix, Inc. Technical Report No. CR-87-43 September 17, 1987 Submitted to the OOPSLA-87 workshop on the Specification and Design for Object-Oriented Programming. 概要 オブジェクト指向プログラミングへのパターン言語の適合について概説する。ウィンドウ・ベースの

http://martinfowler.com/bliki/FivePoundBag.html 10ポンドのクソを5ポンドの鞄に入れることはできない――実際にやってみた人 Kentと一緒に『XPエクストリーム・プログラミング実行計画』を書いたとき、計画がどんなものなのか端的に示すために、この一風変わった文章を引用をした。 ソフトウェア開発の大きな問題点は、限られた時間内にどれだけのことを成し遂げられるか、きちんと認識している人がほとんどいないという点である。 どれだけの量が入るか分からないまま、多くの機能を鞄に無理やり詰め込もうとしている。 すべての機能を入れたいのだろうが、たいていその鞄は小さすぎる。 Kentの計画手法が本当に素晴らしいのは、シンプルなメカニズムを使ってこのことにうまく対応している点だ。 その原則は極めてシンプルである。 プロジェクトを複数のイテレーションに区切る。 要

http://martinfowler.com/bliki/RefactoringMalapropism.html かつて、わずかな人しか知らなかった用語「リファクタリング」は、 今ではコンピュータ業界の中でフラフラ迷走している。 これは私にも責任がある。 私はプログラマたちの生活の向上と、ビジネスに利益をもたらせたいと願っている （重要なことだが、私はリファクタリングの父でもないし、発明者でもない。ただの執筆者である） …… ……のだが、リファクタリングは、適切に使われてはいない。 リファクタリング中に2,3日システムが動かなくなっちゃってーなどと言ってる奴がいたら、 んなもんリファクタリングじゃあなーいと言ってやれ。 ドキュメントをリファクタリングしちゃるとか言ってる奴、 それもリファクタリングじゃねーぞコラ。 そういうのは、リストラクチャリング（再構築）というのだッ。 「リファクタリ

http://martinfowler.com/bliki/AccessModifier.html オブジェクト指向言語ではプログラムはクラスと呼ばれるモジュール群に分かれます。 それぞれのクラスは機能(features)をもっており、データ（フィールド）とメソッドで構成されます（すべての言語がこの用語を使うわけではありませんが、役割は一緒です）。 言語には、どのクラスがあるクラスの機能にアクセスできるのかについてのルールがあり、たいていクラスに適応されるアクセス修飾子に基づいて決まっています。 C++ の選択 おそらく最も影響力のあるアクセス修飾子はC++の３つから始まりました。 public: どのクラスもアクセスできる protected: どのサブクラスもアクセスできる private: どのクラスもアクセスできない 他のクラスやメソッドに対して _friend_ を使ってアクセス

http://www.martinfowler.com/bliki/TechnicalDebt.html システムに新しい機能を追加するとしよう。2つのやり方があるはずだ。ひとつは、早いけれど、ぐちゃぐちゃになるやり方（将来、変更が困難になることは分かっているよね）。もうひとつは、キレイな設計だけど、導入に時間のかかるやり方。 「技術的負債」とは、Ward Cunningham が作ったメタファーである。上記の問題について考える際に、この言葉が役に立つ。このメタファーを使うと、早いけれど汚い解決方法は（ファイナンスの負債と同じく）技術的な負債が発生する、ということになる。 通常の負債と同じく、こちらの負債も利子を払う必要がでてくる。 早いけれど汚い設計を選んだせいで、将来の開発において余分な労力をさかねばならなくなる、というわけだ。 これからずっと利子を払いつづけていくことも可能だし、 リ

http://martinfowler.com/bliki/ServiceOrientedAmbiguity.html (David Ingによる素晴らしいサポート記事へのリンクを追加した。何があろうともblogを書きつづけてくれ！） ThoughtWorksが何も考えずに私を顧客に差し出すときは、 いつも「SOA（サービス指向アーキテクチャ）についてどう思いますか？」という質問を受ける運命にあるようだ。 SOAは立場によって意味が異なるため、回答不可能な質問なのだが。 SOAとは、Webサービスで公開されたソフトウェアである。これは更に、WS-なんとかという規格に従えと考える場合と、http経由であれば、どんなXMLのフォームを受け入れることができる（XMLである必要さえないないかも）と考える場合に分かれる。 SOAとは、アプリケーションが見えなくなるアーキテクチャである。アプリケーショ

以下の文章は、Martin Fowler による 「Language Workbenches: The Killer-App for Domain Specific Languages?」 の日本語訳である。 ソフトウェア開発における新しい考えの多くは、実は古い考えの新しい組み合わせ方です。この記事では、その新しい組み合わせ方のひとつ、私が「言語ワークベンチ(Language Workbenches)」と呼んでいるツールについて説明します。これは、現在広まりつつある考え方で、たとえば、Intentional Software、JetBrainsのMeta Programming System、MicrosoftのSoftware Factoriesなどが例として挙げられます。これらのツールは古い開発スタイルを採用しており、私はこれを「言語指向プログラミング(language oriente