最近、アジャイル開発を「繰り返し型」の形として採用するのはいいが、そこで実際に開発活動をする人たちのスキルに、再度焦点が当たっている。つまり、プロジェクト管理手法としてのみアジャイルを取り入れても、破綻する、ということだ。ソフトウェア開発技術は、匠の技であり、この技術は職人の技だ。この議論は、 James Shore の「アジャイルの衰退と凋落」 Brian Marick の「What's missing from the Agile Manifesto」 Uncle Bob Martin の「Craftmanship over Crap」 などからの流れなのだが、ついに、「ソフトウェア職人宣言」が出現した。以下に、訳文とそのURLを書いておくので、同意する人は、サインをしよう！ ソフトウェア職人宣言(原文： http://manifesto.softwarecraftsmanship.o

ついに対応の検討をはじめました！ delegate、event、property など、難題はいろいろあるのですが、これをどう、JUDEらしく実現するか、がデザインの肝だと思っています。 私は、UMLの言語プロファイルを使って実現する、という方向でない、もっと自然なやりかたがいいのではないかと思っています。クラス図を描いても、そこに<<C#Language>>ステレオタイプとかあまり見えて欲しくない。言語特化したくないデザインもある。しかし、言語特化したいデザインがあると思うし。。。 と悩みはつきないのでした。要望のある方、ぜひこちらまで。 http://jude-users.com/ja/modules/weblog/details.php?blog_id=183

ソフトウェア開発における、資産とはなんだろう？単純に考えると、「ソースコード」というソフトウェア設計図そのものを中心に、それを開発するためのドキュメント、テスト、ユーザマニュアルなどを考えがちだ。人は、これらのまわりで、これらを作り出し、メンテナンスしている。 しかし、実際は「人、一人ひとりの頭の中」も、資産だと考えないといけない。すなわち、ソースコードになっていない思考過程、ノウハウなど。。。ソフトウェア開発は、壮大な伝言ゲームであり、脳の中で情報を加工し、その情報を別の脳に伝え合って開発している。 例えば、ドキュメントがしっかり整っていれば人は交換可能だ、と考える人もいるが、ぼくはこれはナンセンスだと思う。暗黙知も含めて、頭の中にある「スティッキー」な情報はすべてをドキュメントに書き出すことはできない。聞かれれば答えられる情報すべてを、聞かれる前に紙には書けないし、「こういう場いいどう

ボストンにて開催中の、SDBP 2007 にきています。昨日の基調講演は、「ソフトウェア開発のダイナミズム」(原著Dynamics of Software Development)で有名な、Jim McCarthy です。いつか見てみたい人だったので、偶然この機会に出会えてとてもうれしい。 彼のポイントは、「製品作りはチーム作りと同義である」ということ。製品は良いチームから生まれるし、悪いるいチームからは悪い製品しか生まれない（それぞれ、逆も真）。ビジョンを共有したチーム、の強さ、人のパワーについて、アクションを交えた語り口のとてもおもしろい講演でした。 講演中、会場を交えてこんな実験を。 「ビジョンを共有し、情熱あふれるチームに参加した経験がある人は起立してください。」 ⇒約８割が起立。 次に、「そのチームにいるとき、ビジョンを共有ていしないチームにいるときよりも、２倍よかった、と思う人

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

思いやり駆動開発（ODD） ソフトウェア開発を成功させる、もっともシンプルな「こころがけベース」のアプローチである。オブジェクト倶楽部2007夏イベントで発表された。ここでは、ついカッとなって私なりにこのコンセプトを膨らませてみたい。 ソフトウェア開発はコミュニケーションでできている。ソフトウェアの欠陥が発生しやすいのは、人と人の境界、プロジェクトとプロジェクトの境界。そしてそこにはコミュニケーションが生まれている。コミュニケーションには相手があり、その相手を「思いやる」ことが、大切だ。読み手のことを思いやるコードを書こう。システムのユーザを思いやる仕様にしよう。そんなシンプルな「こころがけ」だ。 具体的には、こういうこと。 システムを実際に使う「ユーザー」を思いやろう。ストレスなく使え、「思った機能がそこにある」ようなシステムにしよう。そのユーザが普段使っている言葉のUIを提供しよう。製

TRICHORDの開発は、完全にアジャイル開発です。タイムボックスを区切ったマネジメントスタイルで、基本的に残業はなしです。っていうか、一日３コマのペア・プログラミングをやったら、へとへとで残業できません。ということを言ったら、記事になっていました。 残業ゼロの開発現場 http://itpro.nikkeibp.co.jp/article/OPINION/20070523/271904/ なぜ残業をなくせるかというと、それは（当たり前のことなんですが）開発のビジネスオーナーが自社だからです。受託型の開発だと、それはなかなか難しいのだと思います。つまり、ミッションとリスクをビジネスとITの間で分割してしまうと、そこでWin-Win関係と良好なコミュニケーションを確立することが難しくなってしまいます。 市場を「調査」し、仕様をまとめ、それを「発注」する。そして、それを開発し、「納品」し、市場

ネットワーク応用通信研究所(NaCl)さんと、Ruby + Agile で業務提携」というニュースをリリースしました。 永和システムマネジメント：http://www.esm.co.jp/news/newsrelease20070516.html NaCl：http://www.netlab.jp/news/2007/05/16/20070516/ ビジネスの変化をすばやく捉えて開発するアジャイル手法と、柔軟で人にやさしい言語のRuby。ともに、「人を中心にすえて、人が使いやすいシステムを、人が開発する」という視点にたった、顧客と共同チームでの開発を提案します。 このリリース文ですが、かなり「思い」がこみ上げてくる文章が一部入っていて（ここはかくたにが書いているのですが）、「リリース文ぽく」なくて気に入っています。 ソフトウェアは、『育てるもの』と捉え、顧客と開発者がひとつのチームとなって

先日、電話でインタビューを受けたものが、podcast されました。 Software Process and Measurements: http://spamcast.libsyn.com/ 一つの自慢は、このインタビューシリーズの中に、Capers Jonesがいることです。skype での録音なんで、ちょっと聞きにくいものもあるかも。 interview with Kenji Hiranabe on using mind mapping in agile projects.  Mind Mapping is a powerful technique to order information and concentrate communication.  The interview with Mr. Hiranabe includes a large number of practi

資料公開はじめました！ぼくの資料は、あの時、書画カメラに向かってフリーハンドで描いた絵の「下書き」も含めました。前のブログで書きましたが、 ソフトウェア開発は壮大な伝言ゲームであり、ソフトウェアはビットの塊ではなく、コミュニケーションの塊で出来ている。そして、このコミュニケーション場を広帯域に保つこと、そして、その場に流す情報を、できるだけ誤解が少ないもの（すなわち、見えるもの、触れるもの）にしていく必要がある。さらに、このコミュニケーションは鎖状になっていることから、TOC的には「最も弱い部分」（契約を跨ぐ部分、場所を跨ぐ部分）を厚くすることが必要で、厚くする方法は、そこにWin-Winを持ち込む、対面で話す環境を作る、などがあり、マズロー的なキラーソリューションとして、「一緒に食事をする」ということをお勧めしました。そして、もう１つの方法はこの鎖を「わっか」にして繋いでしまい、そこに要

継続可能なソフトウェア(sustainable software) というキーワードで、現在のソフトウェアを取り巻く技術や考え方を統合したいと思っています。以下に、メモ。 何がソフトウェアの品質の中心となるか。 ・保守性(EoM)＝テスト可能性(EoT)＋変更容易性(EoC) http://blogs.itmedia.co.jp/hiranabe/2005/08/post_353b.html このための技術がオブジェクト指向（部品再利用やコード再利用ではない）、という位置づけ。テストしやすい設計、リファクタリングしやすい設計にすること。そのために、言語要素として継承・カプセル化・ポリモフィズムを使う。さらに原則として、DMP(問題領域概念とのダイレクトマッピング）、SRP（問題領域の変更を閉じ込める）などを使う。また、シンプルで愚直な設計をよしとする。 また、プロセスとしてはアジャイルなも

プログラミングの問題（by C++設計者のStroustrup） http://www.techreview.com/InfoTech/17831/ をラフに訳してみる。（未完） どうして、ほとんどのプログラムは「よくない」のでしょううね？ いいソフトウェアもあります、火星探査ローバー、Google、人ゲノムプロジェクト、などなど、クオリティ・ソフトウェアです！でも、現実世界にある平均的なプログラムをみてみると、泣きたくなる。本当の問題は、ソフトウェアというものがまだまだ永遠につづく改良の繰り返しの創発段階にあること、動くソフトウェアをつくることに向けて、トライアル・エラーをしながら、ちっちゃな奇跡を起こしながら進んでいること。 ソフトウェア開発者は、「不安定な要素を組み合わせて、それなりに安定したシステムを作る」という困難なアートに熟達してきたい。ここで問題は、でも、それをどうやってやっ

ボーリングのスコアを計算するプログラムを設計、実装、テストせよ。 この問題は、Robert C. Martin の『アジャイルの奥義』の中でも、TDD（テスト駆動開発）的なアプローチがしばしば直感とは異なったクラス設計に行き着くことを示す例としても取り上げられている。 また、実はJUDEチームの定番の教育練習問題となっていて、新メンバーが来ると必ずこの問題を解き、良い設計とは何か、という議論をすることになっている。受け入れテストのみを示して、それを通るコードを書いてもらう。 ぼくは、この問題の回答として、かなり普通のクラス構造と名前（たとえば、FrameとかGameとか)が現れくるオブジェクト指向的な設計構造を含んだものを好む。特に第10フレームの扱い（他のFrameとの汎化関係）や、GameとFrameの集約関係に目が行く。もう１つのポイントは、ボーリングのスコア計算ルール（スペアやスト

開発者にアジャイルを強制するのは、危険信号だ（Imposing Agile Is A Very Red Flag）とマーチンファウラーが書いた。 http://martinfowler.com/bliki/AgileImposition.html 要約すると、 アジャイルを管理者が押し付けてはならない、それは、 「プロセスとツールよりも、個人と対話に価値を置く 」という価値にも反するし、その背後にある原則である、 「動機付けされた人たちを中心にプロジェクトを構成する。彼らに環境と支援を与え、彼らが仕事を成し遂げることを信じる」、そして、「最高のアーキテクチャ、要求、そして設計は、自己組織化されたチームから創発する」 にも反する。 というのだ。 チームは自発的にウォーターフォール型の方法を選ぶことだってできる。その場合、アジャイルではなくなるだろが、アジャイルはもともと万能ではないのだ。私は

UML と Mind Map の融合はなぜ必要か？ ずっと温めているアイディアだが、一回整理してみよう。 UMLは、ソフトウェア開発における分析・設計記述の標準ビジュアル言語だ。しかし、UMLを利用してユーザと会話ができるだろうか？ぼくは、実際に、ユースケース図やクラス図をユーザに提示したことともあるが、絵の意味を理解するのに時間がかかるし、彼らの本業はソフトウェア開発ではないから、それを勉強してもらう、というのはおかしな話だ。また、仮にUMLを理解していても、ユーザとあいまいな要求を探索している場面、アイディアを出し合って仕様をこねている場面、対話をしながら合意を作っている場面では、UMLは使えない。矢印や四角の意味（ここは点線？ここは、白抜きの矢印？）に迷ったりしていたのでは、思考や会話のスピードについていくことはできない（Kent Beck 提唱の、GML ならまだしも）。 つまり、

アジャイル開発の中の１つのプラクティスである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さんの「テス

結城さんの、「ソフトウェアは、私たちの想像よりもずっと複雑」を読んで。 http://www.hyuki.com/d/200606.html#i20060616093839 本を書く、という行為の中で結城さんが至った一つの結論は、執筆活動は章立てや理論的なブレークダウンで進んでいくのではなく、「具体的な本文を書き出す」ことが、必要だ、ということ。以下、引用。 本全体のテーマを決める。つぎに各章の内容を考える。全部の内容が決まったら、さらに詳細な内容を考え、節ごとにブレークダウンする。全体の節が出来たところで、いよいよ本文を書き始める。こんな風に、まっすぐな流れで詳細化が進み、その結果として最後に完成する――というふうには進まないのです。 本全体のテーマを決め、各章の内容を考える。まあここまではよい。その次の有効な一手は、「さらに詳細な内容を考える」ことではなく、「本文をいきなり書いてみる」

突然ですが、来週火曜、6/6(火)、「見える化セミナー」を豆蔵さんでやります。募集人数があまり多くないのですが、先着で受け付けますので、ぜひ、お申し込みください。 見所は、「ソフトウェア構造とアイディアの見える化」であるJUDEの「マインドマップとUML」の連携デモ、JUDEを使ったモデリングのコツなどをお話するのと同時に、 今回はじめて、「プロジェクト状況の見える化」として、TRICHORDのデモをやります。 タスクカード、バーンダウンチャート、にこにこカレンダーをお見せできます。無料ですので、ぜひ来てください。 日時：2006/6/6(火) 15:00-17:00(受付 14:30-15:00) 会場：株式会社豆蔵大会議室（新宿三井ビル34F） http://www.shinjukumitsui55info.jp/access/ 参加費：無料 内容： ・JUDEを利用したUMLマインド

昨日から、JavaOne で展示しています。JUDEとTRICHORDです。 TRICHORD は、An Agile Dashboard. Project Management not for the managers, but for the developers. というコンセプトを全面に。にこカレは好評！インターネットから直接TRICHORDチームのワークスペースにつないで、現状を見せています。 まず、タスクカードを、書いて、TODOに貼り、それにサインアップしてDOINGに動かす。そして、終了したらDONEへ。 タイムスタンプはシステムが付けるので、それを集計してバーンダウンにします。 バーンダウンは、見積、実績の見える化。実績は、「あと何日でできる？」を日々聞いていくのがポイントで、何パーセントできた？とは聞かない。（こういう聞き方だと80%, 90%, 95%, 98%になる）

JUDEの開発を、福井で手伝ってくれる、若い(?)エンジアを募集します。ぜひ、ご応募ください。 http://www.change-vision.com/ja/recruit.html 中心はJavaでのオブジェクト指向開発ですが、それ以外にも、JUDEのWeb2.0を考えたり、マインドマップの新しい利用法、LightWeightLanguageの新しい利用法、福井での開発のワークスタイル、東京のSI部隊との交流、上海の部隊の教育指導やプロマネ、ユーザコミュニケーションサイトの構築(XOOPS)、社内ネットワークの整備、などなど、いろいろ試行錯誤しながら進んでいます。なかなかリクルートする機会はないのですが、ここをかりて募集させてください。 あと、チェンジビジョンデザインのグッズを販売始めました（写真）。 よろしかったら、どうぞ。 http://www.upsold.com/imshop/