シャノンの情報定理によると、50%の確率の未来を確定させることの価値は大きい。成功確率0%のプロジェクトをやるのは意味がなく、100%のプロジェクトをやることはまったく簡単だ。 ウォーターフォールとアジャイルがどんなときに有効か、と考えると、100%に近く安定して結果が出せそうな時、はウォーターフォールで、未来が予見しにくいときはアジャイルで、というのが筋が合いそうに思う。それを、「成功確率」、「再現可能性」という軸に乗せてみた。ウォーターフォールは、製造に近いモデルなんだな。計画通りやることが正解であり、情報が事前に十分集まっている状態(Prepare Before Doing)。アジャイルは、そもそもうまく行くかどうか分からないから、少しずつ進んで、情報を仕入れながらやっていこう(Learning By Doing)、というスタンス。 アジャイルのやり方がうまくようになったのは、リファ

Mary Poppendieckのリーダーシップについてのセッションは、立ち見（というか地べた座り）で満席。とくに、ＴＰＳとアジャイルの中から、「人」についての共通の考えを導き出しています。 「標準化」とはなにか。Mary は「現場の経営」（大野耐一の唯二の著書の１つで、最近英訳された）から、以下を引用し、いま、ソフウェア業界、多くの大企業で行われている間違った標準化について、指摘しました。 標準は、カイゼンの最初のベースラインというだけで、変えることが前提なんだ、そして、それはかならず現場で書く。 現在のソフトウェア業界で、いかに多くの「標準」というものが、現場から離れて書かれており、かつ、変えるのが困難か。作るのに１・２ヶ月もかかったら、それはもうダメだ。他人が机の上でつくった標準ではなく、「自分たちが作った標準」でなければ、カイゼンのモチベーションはうまれない。こういう、「あたりまえ

ChangeVision では、クレド(CREDO)を作って、みんなで会社の思いや行動指針を一つの方向にそろえ、力が合わさるようにしています。 以前のブログで、作成中のβバージョンをお見せしました。http://blogs.itmedia.co.jp/hiranabe/2006/08/changevision___fdaa.html 今回は、最新の1.0バージョンをお見せします。アジャイルのやり方に則って（？）、価値(values)、原則(principles)、実践(practices)で表現してみました。全部で、３価値、５原則、７実践、です。表裏があり、これを３つ折にして、名刺入れに入れて携帯します。 前文：　私たちは、「見える化」によって世界を革新します。 チェンジビジョンには、情熱をもった個人が集まっています。その力が合わさって、さらに強い力を生み出すために、また、迷ったときの意思

はじめて、トヨタ工場を見学しました。目的は、TPS（TOYOTA Production System)が機能している様子を見ることです。ちょうど来日していた Mary と Tom Poppendieck 夫妻（リーンソフトウェア開発の著者）と同行し、その他の方々と一緒に回りました。写真は、ツアー出発のトヨタ会館です。ここから、バスに乗って元町工場を見学に行きます。組み立てラインと溶接ラインを見せて頂きました。（写真撮影はできませんでしたので、映像をお見せできないのが残念です） いくつか気づいたことを… ８種のモデルを混合して同じラインに流しています。なので、流れてくる車種はばらばら。多品種少量生産です。 手持ちの在庫が本当に少ないです。例えば、ドアの取り付け工程では、５つくらいの手持ち在庫しかありません。ライン上を車がゆっくり流れてきます。別々の車種が次々に到着しますが、その車種がラインに

ユーザ要望の聞き取りをする場合、利用者や利用場面を聞くことは重要だ。しかし、もっとも重要なことはなんだろう？それは、そのシステムを作る目的は何か、だ。要求開発でも言われているように、「正しくない要求を正しく実装しても意味がない」。そのシステムを作る目的をはっきりさせることが、要求を聞き取る場合に最も重要なことだと思う。 目的はいくつかある、というかもしれない。では、究極の目的はなんだろう。それを聞き出す、魔法の質問がある。 作ろうと思った動機はなんですか？ この質問は、ぼくが家をたてるときにミサワホーム福井支店の営業、大野尊言さんに聞かれて、感動したものだ。ぼくは家を建てるときに、自分でラフなRFPを書いて数社に提案をお願いしようとした。他のハウスメーカーや工務店が、予算、間取り、和洋、などを聞いてきたのに対して、大野さんは、この質問をした。「家を建てようと思った動機はなんですか？」 ぼく

実際に、マインドマップを使って、顧客インタビューをやってみた。図書館の業務支援システムを題材に、本物の司書の方に、インタビュー。 最初に、聞きたいことの要点を、マインドマップで書いておき、その枝に聞いたことを追加していく。その枝（マインドマップ的には、BOI）は、 誰が使いますか？ どんな場面で使いますか？ 管理したいものは何ですか？ の３つである。そして、最後に宿題という枝を用意しておき、そのインタビューで出た宿題を追加する。この３つのBOIは、Who/When/What であると共に、 アクター ユースケース ドメインモデル になることを想定している。もちろん、完全にそうはならないが、ネタとして意識する。 マインドマップのコツとしては、最初から用意した質問の枝は、「下線」でなく「箱」をつかい、また「クリップ」アイコンで分かりやすくしている。宿題は、「おうち」アイコンである。このテンプレ

Issue … Problem の本質化。問題を見つめ、本質的「課題」としたもの。「５回のなぜ」などで到達できるもの。「アンチパターン」や「AntiPractices」では、root causeと呼ばれている。 Knowledge … Keep の結晶化。Keepの中には、ナレッジとして抽象化できるものがある。ナレッジの表現形式としては、「名前付け」がまず必要。そして、それを表現する形式としては、Pattern、新しいPractice、AntiPractice、Tips、FAQ、注意書きとして、壁に貼るなどが考えられる。 これを、KPTIRK（ケプターク）と言う名前でKPTの拡張として、Alistairに提案したところ、「日本人はカイゼン慣れしてるな～」という感想をもらった。 hiro　さんのご要望にお答えして、KPTIRKのフォーマット例。まだ決まったものはない。 Keep->Knowl

ユースケースは、やはり重要なのである。とはいっても、「ユースケース図」ではなく、「ユースケース記述」の方だ。 ユースケース図は、機能名を楕円で囲っただけだ！ と喝破したのは、「ユーザ中心設計(UCD)」のひがさんだが、ユースケースは、図ではなくて、シナリオにこそ、真価がある。図を書くと、ついつい構造化したくなり、include や extend を使ってどんどんどんどん深くなってしまう。そっちの方に行ってはいけない。 ユースケース記述を、充実すべきだ。その粒度、フォーマット、項目を最新の注意で設計しよう。細かな画面仕様やフィールド仕様でなく、まずは、「意図」が伝わるように。 最近のJUDEは、「ユースケース記述」をすっごい充実している。とくに、記述のフォーマットをカスタマイズできる。これで、独自の記述様式ができると共に、あらかじめフォーマットとして、RUP形式、アリスタコバーン形式が用意し

ソフトウェアパターンとXPをはじめとするアジャイルムーブメントは共通点が多い。より正確には、ソーシャルな形（人脈）で歴史的連続性を持っているために、思想的に共通するのは当然だといえる。 パターンが建築家Christopher Alexander（以下C.A.）の思想を、Kent Beckがソフトウェアの世界に持ち込んだ、ということは有名である。1987年、最初にソフトウェアにパターンを持ち込んだのは Kent Beck と Ward Cunningham によるGUI設計に関するものだ。KentとWardはパターンコミュニティHillside Groupを発足させる。そこでパターンを収集する活動がPLoPと呼ばれるもので、現在も続いている。 このコミュニティでJim Coplien（通称Cope）が重要な働きをしている（彼は2001年沖縄のMensorePLoPにも来日している）。Cope

アジャイル開発の中の１つのプラクティスであるTDD(Test Driven Development、テスト駆動開発)に使われるユニット・テスト、というものの役割について、よくテスト界の人との意見の相違がある。テストとしての完全性、や、品質保証についての考え方から見ると、テストとは呼べないのでは？ということ。 最近、アメリカテスト界の有名人であり、アジャイルコミュニティへの貢献も大きい、Brain Marick(www.testing.com/cgi-bin/blog) 氏とメールで話す機会があった。 アメリカでのコンセンサスは、TDDのテストはテストとしては二義的であり、一義的には、「設計ツール」だ これは、以前「テストの役割=進捗管理＋設計戦略」 blogs.itmedia.co.jp/hiranabe/2005/08/sd4__c05e.html で 紹介した、t-wadaさんの「テス

テスト駆動開発やTest Firstを表現するのに、よい日本語（和語）がないか、と思っていた。テストケースを書いて、「こうなっているハズ」という仕様を assert で書いていく。この先回りの感覚を表現する日本語を探している。 「まちぶせ」はどうだろう。 「ここに来るだろう」という場所で、来るべき相手を待っている。 ♪夕暮れの街角、覗いた喫茶店 微笑み見つめあう　見覚えある二人 （この歌にピンとくる人はどれくらい？）そう、『まちぶせ』だ。待っている。好きな人を。しかも、その人をこちらに振り向かせる自信はあるんだ。 ♪好きだったのよ～、assert 胸の奥でずっと もうすぐ、私きっと、あなたをグリーンにさせる ちなみに、石川ひとみの「まちぶせ」は荒井由実の作詞作曲。 そか、待ち伏せは、最終点だけおさえて、経路は問わない、といこともテストに似てますね。 http://d.hatena.ne.j

題名は、音楽の話に聞こえるかもしれませんが、ソフトウェア開発の話です。 以前、咳さんが体験談として >「お前のコードはナチュラルでエレガントだ」 >と言われた時は うれしかったなあ と語ってくださったことから、ちょっと思い起こしてみました。「ナチュラルなコード」とはなんだろうか、ということを考えてみたい。ぼくは、何かの本かインタビューで読んだ、Ward Cunningham の言葉がとても強く印象に残っています。 ...(要約するとこんな感じ)... そのコードは、すばらしいコードだった。ソースリストをプリンタに出力すると、 それは、「どこからでも読み始めることができ、意図が明確だった」 ............................ 「どこからでも読み始めることができる」（！）というのは、オブジェクト指向のよいコードの特徴じゃないだろうか。 （以前、oosquare-ml だっ

ここでのテストは、開発者テスト、の中の、ユニットテストの話。XPとTDDの文脈において、設計を駆動するテストについてです。（※最近、テスト、と言う言葉を慎重に使わないと、いろんな他の方面から誤解を招く、ということを知って、文脈を特定しておきます。^^;;） テスト容易性(EoT=Ease of Testing)が重要な設計品質である、ということを以前書いた。もう少し具体的な根拠を書きたい。 ユニットテストをたくさん作るということは、設計に対してどんな意味を持っているのだろう？物理的にいうと、「プログラムのエントリーポイントを増やしている」ということになる。 エントリーポイントとは、プログラムのスタート地点である。通常であれば、プログラムはmainという名前の決まったエントリーポイントから呼び出され、多くのモジュールを通過して終了する。しかし、ユニットテストを導入することによって、多くのテス

ソフトウェア開発を「問題解決」、と見ると、 問題→解という活動だと考えられる。左の「問題」は、問題空間にあり、右の「解」は解空間にある。設計とは、このマッピングを行なう活動だと考える。では、分析とは何か。 実際には、（ソフトウェアでは特に）問題が複雑だったり曖昧だったりすることから、このままではうまく解けない（悪構造 ill-structured problem）。そこで、一旦、この「問題→解」という現実世界の問題をモデル化しよう、ということになる。「問題空間」、「解空間」という空間と直行する空間軸として、上下に「モデル空間」と「現実空間」を導入する。そうすると、４つの象限が現れる。その４つの象限に、現実空間の「問題」と「解」、そして、モデル空間の「分析モデル」と「設計モデル」を置く。ここで、分析モデル＝モデル化された問題 、設計モデル＝モデル化された解である。そして、問題→解という直線的

今回は、トヨタ生産方式とアジャイル開発の共通点である、「プル生産」について書いてみたい。前回から継続している「テスト」の話に関連している。前回は、上流から下流へ向かって１個ずつ要求を流す、という話をしたが、今回は、生産指示（いつどれだけ作って後工程に流すか）について。 トヨタ生産方式では、工程間に溜まった仕掛を在庫（＝ムダ）と捕らえている。この在庫を「かんばん」で管理し、前工程への生産指示を出す。後工程が必要になって初めて、前工程が作る。前工程は、生産指示がない限り作らない。生産物は必要な分だけ前工程から後工程へと流れ、生産指示は逆に後工程から前工程へと流れるのだ（後工程引き取り）。 たくさん作ることは良いことだという作り手側の論理で生産を続けると、前工程から後工程へと生産物がプッシュされることになる。後工程で必要とする以上の生産物は、ムダとなり工程間に在庫として貯まる。これが、在庫のムダ

Alistair Cockburn は、ソフトウェア開発の「1個流し」(*1)と進捗管理について、おもしろい例を出している。次の問題を考えてみて欲しい。 ３０個の部屋がある豪邸を考える。この豪邸から、1ヵ月後に引越しをすることに決めた。全部屋を掃除し、捨てるものと運ぶものに分類し、ダンボール箱に詰めなければならない。どのように進捗を管理したら、１ヵ月というデッドラインを守れるか。 ウォーターフォール的計画： １．最初の1週間で全部屋の掃除を行なう ２．次の1週間で全部屋の捨てるものと運ぶものを分類し、ステッカーを家具や備品に貼る ３．次の1週間で全部屋のダンボール箱詰めを行なう ４．次の1週間で全部屋のチェックを行なう ５．４週間あるので、４週間後には全部屋のチェックまで終わる 1個流し的（アジャイル的）計画： １．日割りで、１日に１つの部屋を、掃除、分類、箱詰め、チェックまで終える ２．

「EoM=EoC+EoT」を鍵概念として、良い設計とは何か、よいプロセスとは何か、を再定義しようとしている。今回は、テストの役割について再考する。 テストは設計とプロセスの両方の基本単位だ。まず、テストと進捗管理の話をしたい（テストとドキュメントの話、テストとコミュニケーションの話、テストと開発リズムの話、などと続く予定）。 みなさんは、進捗指標として何を使っているだろうか？「工程ごとに違うが、成果物の完成に対する到達度だ」という答えが一般的だと思う。しかし、「設計書９０％完成という報告が２週間続いている」というような進捗会議に参加したことはない？　（きっとあるはずだ。） ぼくが考える進捗管理の基本は、 の3点だ。先に述べた「設計書のページ数」という単位は、３つの条件をどれも満たしていない。すべての設計書を否定するつもりはないが、設計書は内部の中間生産物であることが多いし、１００％終了とい

前回、「EoM(保守容易性)が良い設計の基準だ、そして、EoM＝EoT+EoCだ」という議論を書いた。ここまでの議論は、ソフトウェアの設計についてのものであり、開発の「プロセス」（あるいはプラクティス）とは無関係に進めてきた。ここで、１つの経験則を使って、プロセスの方（鏡の反対側）を見てみたい。その経験則とは、 コーンウェイの法則： ソフトウェアの構造は開発チームの構造に一致する。コンパイラを４チーム編成で作れば、４パスコンパイラになる である。（※この法則は、ソフトウェアとチームの「構造」（organization）について述べたものだが、ここでは、プロセスについて拡大解釈する） この法則を使うと、３つの設計品質についての方針は、そのまま、プロセスについての方針にミラーコピーできる。 EoTに関するプロセスの命題は、テストというより、「テスティング」という活動が、プロセスの中で最も重要な

前２回で、オブジェクト指向を「テスト容易性」と「変更容易性」を中心に再定義したい、という話をした。 従来オブジェクト指向の説明に使われている概念、およびそこから得られる（といわれている）再利用性という品質からではなく、 テスト容易性：　EoT = Ease of Testing 変更容易性：　EoC = Ease of Changing という２つの概念からが、（現代的な）オブジェクト指向設計の焦点であることを主張してきた。最後、なぜこの２つが必要なのか、というと、それは、メンテナンスのしやすさ（EoM=Ease of Maintenance）を高めるからだ。そして、このEoMこそが、2005年のソフトウェア開発の根本品質だ、と言い切ってまとめたい。 EoMの高い設計が、よいオブジェクト指向設計である。 ということである。今回は、前回書いた、EoT/EoCそして、このEoMについて、ソフト

良い設計とはなにか、と問われて、凝集度と結合度に関する議論を思いつく人も多いだろう。しかし、この定義によりもっと具体性がある設計方針として、テストを考える。テストの視点によってオブジェクト指向を再定義したい。キーワードは、Eon(Ease of Testing)、テスト容易性だ。 ぼくは、 EoT(*1)の高い設計が、よいオブジェクト指向設計である。 と主張する。設計品質の中で「テスト容易性(EoT)」を最上位と見るのだ。オブジェクト指向のさまざまな機構、用語、考え方は、すべて EoT のため、と捕らえられる。例えば、