Sustainable Software Development -- 持続可能なソフトウェア開発（アジャイルとジャグリング！？） かねてから、「持続可能な」ソフトウェア作りについて考えたいと思っていました。工業モデル、サービス業モデル、などで語られることの多いソフトウェア開発を、むしろ、農業や水産業、「育てる」モデルで捕らえたい。そうすれば、きっとチーム作りの面が強調されたアジャイル開発が浮かび上がるはず…。こんな話を、2000年以降、何度も天野さんや懸田さんとした記憶があります。KentBeckも、「ソフトウェア開発をガーデニングのメタファで捕らえたい」といっていました。 とてもいい本が出ていたので、紹介します。 Kevin Tate のSustainable Software Development: An Agile Perspective (Agile Software Deve

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

牛尾さんの記事「モデリング・リファクタリングのススメ」です。 http://itpro.nikkeibp.co.jp/article/Watcher/20070612/274464/ これはすごい。プログラミングレベルの概念である「リファクタリング」を、業務フローの記述に援用し、しかも、「不吉なにおい」と「リファクタリングカタログ」までついているではないですか！ 要求開発では、ITシステムの要求を獲得する過程を「収集」（そこにすでにあるものを拾ってくる）のではなく、「開発」（ビジネス価値から作り出すもの）と捕らえることで、システム開発が培ってきた手法を延長しようとしています。そして、今回、システム開発の手法の１つであるリファクタリングを、今回要求開発に延長しています。（それ以外にも、モデリングやUMLもシステム開発から持ち込んでいます） でも、私は、この記事のすばらしいところは、ナレッジを

オブジェクト倶楽部の今夏のイベントが終了しました。ちょっと思いを書いておきます。 3K(きつい、きつい、きつい)といわれるこの業界を変えて行きたい。そのためには、「エンジニア」という職種の人の価値を上げていくことが自分のミッションの１つだと考えている。 最近強く思うことは、 エンジニアの価値は、実は、世界と無関係にその人についているわけではない、ということだ。AさんとBさんの間にある「関係」に価値がある場合がある。 「あの二人が組むと、プロジェクトがうまくいく」というのは、Aさん、Bさんの属性として価値があるのではなく、その「間」に価値がある例だ。また、どんな知識やスキルがあっても、世界と関わらなければ、それは無価値。そして、その価値は、人と人との「関係」についている。 この意味で、コミュニティは、エンジニアの価値に大きく貢献できると思っている。他のエンジニアと知り合い、共感し、お酒を飲ん

XPのメーリングリストより。Kent Beckが Burndown チャートについてコメントしている。 「報告」の原則は、 Honest - 正直であること。事実をまげないこと。 Effective - うまく伝わること。 Responsive - 反応的であること。プロジェクトのフィードバックループに組み込まれていること。 詳細で大量な報告、とか、全く報告がない、はダメの典型。バーンダウンチャートは、人のビジュアルな思考を引き寄せ、短時間で全体感があり、効果的に情報を伝える力があるから。決して、「都合の悪い詳細を隠す」ためではない。 XPメーリングリスト：http://groups.yahoo.com/group/extremeprogramming/message/120292?l=1

多くの方からコメントを頂いて、再考してみる。（emeitchさん、chris dingさん、ひがさん、takadsignさん、satoshi さんありがとうございました！） まず、 Meyer のIOPは、クラシックOOの意味で正しい。 モデルTというか、一次近似というか、設計とはなんぞや、の意味である理想化された問題状況において、クラシックに正しいのだ。ここでの理想とは、 ユーザは要求を把握している。 要求は設計活動が終わるまではとりあえず変更されない。（その後変更はあるが） ということだ。まずはこの前提に立って、あるべき設計方法とは、という解決原則を提示しているのが、IOPだといえる。 さて、１，２が疑わしいとなると、事態は「さらに」複雑になる。そうなった場合、２つのアイディアが現在世の中では提示されている。 Extreme Programming等のアジャイル開発（アプリケーションの

ずいぶん前にオブジェクト倶楽部のメルマガに書いた記事ですが、人気がある、ということなので、図を加えて再掲します。 ソフトウェア原則 [2] IOP(Inside-Out Principle) Inside-Out Principleは、「中から外へ向って設計せよ」というBertrand Meyer(*1)のソフトウェア設計原則で、「Model Before UI」とも言います。 ユーザとの界面を持つソフトウェアでは、まず「モデル」を設計し、後で界面を設計するという指針になります。モデルとは、このソフトウェアが扱う問題領域の「基本概念群」です。 例えばレンタルビデオ屋のシステムであれば「ビデオ」、「貸し出し」、「顧客」などなどの基本的な概念群がキャプチャできるでしょう。これらの概念群を分析し、概念間の関連や汎化構造を探索することで、「概念モデル」と呼ばれる分析成果物が得られます。 まずこのモ

THICHORD(トライコード)の version 0.1 を発表します。自由にダウンロードできますので、どうぞ、みなさん開発へのフィードバックにご参加ください。http://trichord.change-vision.com/ これは、カテゴリとしては、SDLC(Software Development Life Cycle)ツール、となるでしょうか、でも基本的には、もっとシンプルな「状況の見える化」ツールです。 これまで、ソフトウェア進捗管理のツールといえば、「管理」のツール、仕方ないが、使えといわれるので使わざるをいえないツール、という印象が強いのではないでしょうか。TRICHORDは、 仕方なく使うツール、から、使いたいから使うツール にしたい。つまり、エンジニアが、必要だと思うから、導入するツール。 例えば、JUnit というシンプルなテスティングツールがある。これは、プログラ

3月17日に行われた要求開発のパネルディスかションで、「ビジネス設計」（ユーザ側、発注側）と「システム設計」（ベンダー側、受注側）の間をどう埋めるか、という議論がおもしろかった。 日本総研の細川さんが、その２つの間に点線を引いていたのを、システム側からビジネス側に食い込む斜め線をひき、システム側からビジネス側に押し出すような三角形にし、このデルタ地帯を「黒い三角形」と呼んだ。 豆蔵の萩本さんは、「現にビジネスの設計においてITを抜きでは語れない」ことから、そもそも現在、この点線分割が出来ないことを主張した。動くものを見てみないと、話にならないことが多いのだ。これは、アジャイルの立場とも強く符合する。 ぼくが最もおもしろいと思ったのは、甲府市役所の土屋さんの意見。「システムの側からも、工夫してビジネスの要求を聞き出して欲しい」ということ。「射止めたい異性のためには、さまざまな工夫をしてコミュ

PF(プロジェクトファシリテーション）の１つのプラクティスである、「かんばん」。最近よく講演をするのですが、よく聞く悩みが、「うちのチームには壁がありません…」 そこで、紹介したいのが、これ。 Kanban-nano ... (モバイルかんばん!) 普通は壁に貼るのだが、これをポータブルにする。めちゃめちゃおもしろいです。昨年末のオブジェクト倶楽部クリスマスイベントのライトニングトークスで、CCSの佐藤竜一さんが発表した、「形から入る『見栄っぱり』アジャイル開発講座」に出てくる、アイテムです。 かんばんを安定させるための、「まな板立て」の利用法に注目。こういうちょとしたディテールへの実用的な工夫が泣かせます。(※協力　CCS佐藤竜一) どこにでもかんばんを持ち出そう スーツにも、ベストマッチ。オフィスを颯爽と駆けろ

前に紹介したニコニコカレンダーhttp://www.geocities.jp/nikonikocalendar/index_ja.html これをブログでやってしまおうという試みが、Akiyahさんによって実装された。 http://akiyah.bglb.jp/software/NikoNikoCalendarPortal/ ブログエントリの「題名」の最後に、自分のムードを示すフェイスマークを入れる。そして、このサイトに、そのブログを登録すると、日本全国、（全世界？）のブロガーのムードが、天気予報のようにカレンダーになって表示される！ さっそく米国のXPグループで紹介しよう。

最近富士通の方に「要のもの・こと」という言い方を聞き、そこから検索して中村善太郎さんの『シンプルな仕事の構想法』という本を読んでみた。 すごいなー、トヨタ生産方式に代表されるような「ムダどり」の発想を、抽象化して捉えている。これは、GTDやらアジャイルやら、リーン思考やらプロジェクトファシリテーションやら、ユースケースやらというものをインスタンスとして扱えるような思考の枠組みじゃないだろうか。 仕事とは、「行わねばならないこと」を「体や頭を使って行うこと」 であり、さらに、 「行わねばならないこと」とは、「もの」を「始めの状態」から「終わりの状態」に変える「こと」 である。そこには「要（かなめ）の変化」があり、あとはすべて贅肉だ。仕事を分析して「要のもの・こと」に焦点を合わせ、排除（Eliminate）、結合（Combine）、シンプル化（Simplify）を検討する。そもそも、仕事に要が

坂田さんやヤマモトさんがやっている「ニコニコカレンダー」という今日の自分のムードの見える化手法がある。 http://www.geocities.jp/nikonikocalendar/index_ja.html チームの壁にこれを貼って、今のチームムードを全員でフィードバックする。ちょっとうまくリーダーに報告できないような「こころもち」も、これなら気軽に伝えられる気がする。略して「ニコカレ」。命名者は、 “つらい気持ちの人も、体調の悪い人も、変化のない毎日の人も、シールを貼っていくうちにこのカレンダーがニコニコマークでいっぱいになればいいなぁ、という気持ちでニコニコカレンダーとつけました。” という。mixi にも、「ニコニコカレンダー愛好会」というコミュニティがある。 ところで、「ブログ」というメディアを使って、「世界ニコカレ」の実験をしてみたい。ブログエントリの「題名」の最後に、自分

Paul Graham in "Joel on Software" あるいは、新しい会社に就職するときの心得 今日は角谷さんの企画で、Aardvark'd のDVDを見た。Joel on Software で有名な会社にきた Intern たち（いわゆる nerd というか、geek）が、ソフトウェアの世界になじみ、巣立つまでの 12 weeks を描いた映画。 面白かった。生Paul Grahamを初めてみたが、かなり俳優バリの存在感。いわく、 「ハッカーと言う言葉には sneaky なにおいがある。そして、もともと”創造”と”ハック”には似たニュアンスがあるのだ。例えば、相対性理論というのは、ユークリッド空間の sneaky なハックだ。」 なるほどー。（ちなみに上映会の後、角谷氏は自転車で３０分以内で通える通勤路を見つけることを、「通勤ハック」と呼んでいた。） この映画を見て、採用と

恒例のクリスマスイベント、今年もなんとか盛況のうちに終えることができました。 2005クリスマスイベント～ プロジェクトを成功させる7つのカギ ～ http://www.objectclub.jp/event/2005christmas/ 中心コンセプトは、プロジェクトを成功させるカギは何かとし、カギを全員参加型で議論し、カギ束にして持ち帰ろうよ、ということにしました。望む姿勢は、 Participate and Share です。「参加と共有」。手段として、TheWorldCafe をやりました。テーマについてカフェ形式で話合い、テーブルクロスにどんどん思ったことを書いていきます。全員がどんどんテーブルを交代して、議論を「交配」させるわけです。 この試み、おおむね好評でしたが、「議論の時間が短い！」、「会場が狭い！」という問題が大きかったです。ちょっと自己紹介をすると、すぐ交代の時間が来

ぼくがオブジェクト指向言語を勉強しはじめた90年ころは、「継承」という概念がとても流行っていて、継承によって「差分プログラミング」ができることがオブジェクト指向設計の再利用性の典型例のように言われていた。もちろん、こういう誤解は95年くらいには、みんなウソだと分かってきていた。 しかし、それでもときどき、 すべてのクラスの頂点のような「神様クラス」を作ってしまうことがある。 例えば、90年代の多くのC++オブジェクト指向データベースは、Persistenceのようなクラスを継承することで永続オブジェクトとなるクラスをマーキングしたり、あるベンダーのコレションクラスは、Objectというクラスを継承したクラスのオブジェクトのみがコレクションの要素となることができたり、という具合に。また、EJBも最近まではEntityBeanを継承することでEntityBeanの資格が得られるし、Servel

XPの第２版の絵より（日本語版がもうすぐ出ます）。これを説明してみます。 XPは、「価値」、「原則」、「実践」という３つのレイヤーとしての体系化しています。 「価値」(value)は、３つのレイヤーの最上位であり、XPが大切にしていることを宣言したものです。価値をはっきりさせることで、この手法の目的を明示することができます。価値には、「普遍的」（universal）、「お互いに矛盾しない」（consistent）、「補完的」（complementary）、「目的を示す」（purposeful）という特徴があります。 「原則」（principle）は、第２の中間レイヤーであり、上位レイヤーである価値を達成するために従うべきガイド、および下位レイヤーである実践を導く考え方です。原則には、人間特性、経験から発見された法則などが含まれ、「広い領域に適用可能」（widely applicable）、

「ワールドカフェ」、というファシリテーション手法をご存知だろうか。実はぼくも最近知ったのですが、「カフェ」での会話というスタイルを使って、みんなで共通の課題について話合おう、という趣向です。 （↓のマインドマップは、クリックで大きくなります。詳細は、http://wiki.esm.co.jp/TheWorldCafe.pdf) 書籍 The World Cafe: Shaping Our Futures Through Conversations That Matter http://www.amazon.co.jp/exec/obidos/ASIN/1576752585/xpjp-22/ 背景には、現在の社会的、技術的な関心事と未来の方向性は、個人個人の頭の中そして、それらの「ソーシャルネットワーク」にある、という気づきがあります。これは、現在のインターネット上のblogやSNSを見てい

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

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