Sustainable Software Development -- 持続可能なソフトウェア開発（アジャイルとジャグリング！？）：An Agile Way：オルタナティブ・ブログ
Sustainable Software Development -- 持続可能なソフトウェア開発（アジャイルとジャグリング！？） かねてから、「持続可能な」ソフトウェア作りについて考えたいと思っていました。工業モデル、サービス業モデル、などで語られることの多いソフトウェア開発を、むしろ、農業や水産業、「育てる」モデルで捕らえたい。そうすれば、きっとチーム作りの面が強調されたアジャイル開発が浮かび上がるはず…。こんな話を、2000年以降、何度も天野さんや懸田さんとした記憶があります。KentBeckも、「ソフトウェア開発をガーデニングのメタファで捕らえたい」といっていました。 とてもいい本が出ていたので、紹介します。 Kevin Tate のSustainable Software Development: An Agile Perspective (Agile Software Deve
幸せの総量について -- 飛行機でキスされたこと：An Agile Way：オルタナティブ・ブログ
飛行機で隣の女性に「席を替わってくれませんか？」と言われた。替わる相手は彼女ではなく、席がばらばらになってしまった恋人である。二列後ろに彼は座っている。こころよく、「いいですよ」と言った。一瞬、めんどうくさいな、と思った自分を発見するが、人が喜ぶことをしてあげるのはいいことである、と言い聞かせた。 替わってあげるために、席を移動すると、黒人のボーイフレンドは、とてもうれしそうに、英語で感謝を述べ、ぼくをハグして頬のキスした。このリアクションにはぼくも少しびっくりしたが、その様子が本当に幸せそうだったので、ぼくもなんだかうれしくなってしまった。ぼくは、「My Pleasure」と返事をした。 その飛行気で、ぼくはちょうど手塚治の『ブッダ』を読んでいた。良く生きる、ということをつきつめると、人のために生きることになるという。他人の幸せについて考え、自分がそれをしてあげる、それが自分の喜びにつな
ものづくり、の本質：An Agile Way：オルタナティブ・ブログ
いくつかブログやらメールやらを見ていて、今年の思いを固めている。「つくる」ことの本質は何だろう、それは、「おもう」ことと関係しているのではないか、というのが今年のテーマです。 本日のGrady Booch のブログのクオートより； If you want to build a ship, don't drum up the men to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea. -- Saint-Exupery 船を作ろうと思ったら、人々に材料を集め、作業を分割し、指示を与えようとしてはならない。最初にすべきことは、果て無き広大な海への憧れを語ることだ。 -- サンテクジュペリ 昨日のAlistair Cockburn の
"Social change starts with you"(contd.)：An Agile Way：オルタナティブ・ブログ
以前、Kent Beck にサインをもらった角谷さんの話を書いた。そして、XP is about social change のなぞについても。http://blogs.itmedia.co.jp/hiranabe/2006/09/social_change_s.html 今日、XPの本家ＭＬにあった、Kent Beck 自身の投稿に、やはり同じような趣旨の発言を見つけた。文脈としては、「周囲を変えないと、アジャイルやＸＰをやるのは、難しいんだ。ぼくの周りには、現状をやっていればＯＫ、という人ばかりなんだから。」というメールへの返答を、Kent 自身がしている。 カールトン、ぼくは『周囲を変えたい』という状況になった場合、いつもこの言葉を忘れないように努力する--『自分が変えられるのは自分だけ』。でも、自分が変わるとすぐ、自分と周囲との関係が変化するんだ。そして、それで周囲の人が変化する、
ソフトウェアの設計とリズム：An Agile Way：オルタナティブ・ブログ
yachさんのブログより。 http://d.hatena.ne.jp/yach/20060927 ソフトウェアの変更は、そのソフトウェアに関わる人間の活動によって発生する。人間の活動には周期があり、その周期によって発生する変更の内容も変わってくる。変更は種類に応じて周波数を持つことになるので、その周波数をソフトウェアの設計で考慮することで、「変更を予測」せずとも、変更に強い設計が得られる。 そういえば、この「変更周波数」というアイディアは、ぼくも考えたことがあった。 http://blogs.itmedia.co.jp/hiranabe/2005/08/_eocease_of_cha_602c.html yachさんは、この周波数が「人間活動」に関連していることに気づいている。 また、これらをふまえた、ぁまんにょさんの「リズムについて」 http://d.hatena.ne.jp/ama
Paul Graham in "Joel on Software" あるいは、新しい会社に就職するときの心得：An Agile Way：オルタナティブ・ブログ
Paul Graham in "Joel on Software" あるいは、新しい会社に就職するときの心得 今日は角谷さんの企画で、Aardvark'd のDVDを見た。Joel on Software で有名な会社にきた Intern たち（いわゆる nerd というか、geek）が、ソフトウェアの世界になじみ、巣立つまでの 12 weeks を描いた映画。 面白かった。生Paul Grahamを初めてみたが、かなり俳優バリの存在感。いわく、 「ハッカーと言う言葉には sneaky なにおいがある。そして、もともと”創造”と”ハック”には似たニュアンスがあるのだ。例えば、相対性理論というのは、ユークリッド空間の sneaky なハックだ。」 なるほどー。（ちなみに上映会の後、角谷氏は自転車で３０分以内で通える通勤路を見つけることを、「通勤ハック」と呼んでいた。） この映画を見て、採用と
Without Practice, No Emergence - 永平寺にて：An Agile Way：オルタナティブ・ブログ
久しぶりに、永平寺を参拝。飾ってある道元禅師の言葉。 Without Practice, No Emergence 修さざれば、現れず この言葉は、アジャイルの感覚ととってもよく似ていて、いつもはっとさせられる。 Practiceは、禅宗の文脈では、座禅であったり日々の修行であったりする。禅宗は身体性を重視しており、頭ではなく身体でやってみることから、現れてくる（Emergence）ことを重要視している。 また、アジャイルの文脈では、理論ではなく実践してみてはじめて、それを掴むことができる、というアジャイルマインドを示している。また、それと同時に、すべてを先持って予見したようなアーキテクチャや設計というのはダメで、実践を通してしか、構造は現われないのだ。ということも言っていると思う。 ぼくは、この言葉がとても好きで、ここに来るたびにこの言葉をみて、考えを新たにします。
ユーザ要望の聞き取り方を学ぶー究極の目的とは？：An Agile Way：オルタナティブ・ブログ
ユーザ要望の聞き取りをする場合、利用者や利用場面を聞くことは重要だ。しかし、もっとも重要なことはなんだろう？それは、そのシステムを作る目的は何か、だ。要求開発でも言われているように、「正しくない要求を正しく実装しても意味がない」。そのシステムを作る目的をはっきりさせることが、要求を聞き取る場合に最も重要なことだと思う。 目的はいくつかある、というかもしれない。では、究極の目的はなんだろう。それを聞き出す、魔法の質問がある。 作ろうと思った動機はなんですか？ この質問は、ぼくが家をたてるときにミサワホーム福井支店の営業、大野尊言さんに聞かれて、感動したものだ。ぼくは家を建てるときに、自分でラフなRFPを書いて数社に提案をお願いしようとした。他のハウスメーカーや工務店が、予算、間取り、和洋、などを聞いてきたのに対して、大野さんは、この質問をした。「家を建てようと思った動機はなんですか？」 ぼく
マインドマップによる、ユーザ要望の聞き取り - An Agile Way
実際に、マインドマップを使って、顧客インタビューをやってみた。図書館の業務支援システムを題材に、本物の司書の方に、インタビュー。 最初に、聞きたいことの要点を、マインドマップで書いておき、その枝に聞いたことを追加していく。その枝（マインドマップ的には、BOI）は、 誰が使いますか？ どんな場面で使いますか？ 管理したいものは何ですか？ の３つである。そして、最後に宿題という枝を用意しておき、そのインタビューで出た宿題を追加する。この３つのBOIは、Who/When/What であると共に、 アクター ユースケース ドメインモデル になることを想定している。もちろん、完全にそうはならないが、ネタとして意識する。 マインドマップのコツとしては、最初から用意した質問の枝は、「下線」でなく「箱」をつかい、また「クリップ」アイコンで分かりやすくしている。宿題は、「おうち」アイコンである。このテンプレ
テスト駆動開発のテストは、テストか？―TDD から BDD へ - An Agile Way [ITmedia オルタナティブ・ブログ]
アジャイル開発の中の１つのプラクティスである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さんの「テス
プロジェクト・ファシリテーション－ファシリテータ型リーダの資質：An Agile Way：オルタナティブ・ブログ
プロジェクトの場作り（ファシリテーション）を行い、チームメンバーの能力を１００％以上発揮させ、１＋１を２以上にする、新しい形のリーダーシップが必要だ。そのたの人材像について、考えている。株式会社ITイノベーションに伺ったとき、Harvard Business Review をパラパラと見ていたら、こんな文章が！ 人々に学び 人々と一緒に計画し 人々が持っているもので始め 人々が知っていることの上に築きなさい。 リーダーが真に優れていれば、 終わってみると 人々は口々にこういう 「自分たちの力でやり遂げた」と。 －老子 うーん、まさに、これが理想だ。。。 ITイノベーションの林衛さんには、前回のオブジェクト倶楽部で主賓講演を頂きました。今回は、「ザ・プロジェクトマネジャーズ」のインタビューを私が受けました。 http://topic.promane.com/iti/dtdisp.asp?en
分析とは何か、設計とは何か？：An Agile Way：オルタナティブ・ブログ
ソフトウェア開発を「問題解決」、と見ると、 問題→解という活動だと考えられる。左の「問題」は、問題空間にあり、右の「解」は解空間にある。設計とは、このマッピングを行なう活動だと考える。では、分析とは何か。 実際には、（ソフトウェアでは特に）問題が複雑だったり曖昧だったりすることから、このままではうまく解けない（悪構造 ill-structured problem）。そこで、一旦、この「問題→解」という現実世界の問題をモデル化しよう、ということになる。「問題空間」、「解空間」という空間と直行する空間軸として、上下に「モデル空間」と「現実空間」を導入する。そうすると、４つの象限が現れる。その４つの象限に、現実空間の「問題」と「解」、そして、モデル空間の「分析モデル」と「設計モデル」を置く。ここで、分析モデル＝モデル化された問題 、設計モデル＝モデル化された解である。そして、問題→解という直線的
XP祭り2005 ～日本最大のアジャイルのお祭り～：An Agile Way：オルタナティブ・ブログ
「XP祭り2005」に参加してきました↓ http://www.xpjug.org/event/20050903matsuri/ この会は、2002年に始まり、これで４回目を迎えました。初めて土曜に開催したところ、参加者は２００を超え、懇親会は、なんと１20人。講師も含めて、すべてボランティアの運営です。 「EXP - Enterprise XP」 XPJUG代表倉貫さん 「プロジェクト・ファシリテーション」 平鍋 「ユーザ中心の設計(User Centered Design)」 ひがさん 「XP 体感ワークショップ - XPって何？」 天野さん 「要求開発」萩本さん 「スペシャルゲストによるパネル討論」萩本さん、ひがさん、萩原さん、関さん、平鍋、司会：倉貫さん 「劇団ペケぴー（世界初XP小劇団) vs アンプラーズ(2004 年ADCベストパフォーマンス賞受賞)」 「XPユーザ会恒例ライ
ソフトウェアのプル生産：An Agile Way：オルタナティブ・ブログ
今回は、トヨタ生産方式とアジャイル開発の共通点である、「プル生産」について書いてみたい。前回から継続している「テスト」の話に関連している。前回は、上流から下流へ向かって１個ずつ要求を流す、という話をしたが、今回は、生産指示（いつどれだけ作って後工程に流すか）について。 トヨタ生産方式では、工程間に溜まった仕掛を在庫（＝ムダ）と捕らえている。この在庫を「かんばん」で管理し、前工程への生産指示を出す。後工程が必要になって初めて、前工程が作る。前工程は、生産指示がない限り作らない。生産物は必要な分だけ前工程から後工程へと流れ、生産指示は逆に後工程から前工程へと流れるのだ（後工程引き取り）。 たくさん作ることは良いことだという作り手側の論理で生産を続けると、前工程から後工程へと生産物がプッシュされることになる。後工程で必要とする以上の生産物は、ムダとなり工程間に在庫として貯まる。これが、在庫のムダ
Ａｇｉｌｅに計画はいらないか？！：An Agile Way：オルタナティブ・ブログ
アジャイル、って「オヤジ語」に直すと、ＰＤＣＡなんです。Ｐｌａｎ－Ｄｏ－Ｃｈｅｃｋ－Ａｃｔｉｏｎ。上司に「アジャイルでやりましょう」というと煙たがられる（あるいは理解されない）場合は、「ＰＤＣＡをちゃんと回したいんです」と言ってみよう。「おお、君もようやく一人前になったな」と褒められること、請け合いです。 計画をつくるということ↓ http://d.hatena.ne.jp/kuranuki/20050728 そういう意味で、計画は大事。しかし、計画と言う言葉は、後で変更しづらい、あるいは、計画通りにやることが正しい、という「間違った」イメージを作ります。APMでは、構想とよび、計画作りのフェーズを構想フェーズ、としています（Vsion と Envision Phase です）。 構想⇒思索⇒探索⇒適応 ↑－－－－－↓ というループ。 実は、トヨタ生産方式では、「進捗管理」は、「計画と実績
セミナー受講心得 － 知っていることと実践することの隔たり：An Agile Way：オルタナティブ・ブログ
外部のセミナーに参加することがあります。その時は、「絶対何か一つ持って帰ろう」、という気持ちで出ることにしています。 逆に、セミナーの講師をすることもあります。その時は、「何かお土産を持って帰ってほしい」、と思います。「セミナー受講の心得」、というおもしろい考えを見つけました。 http://www.uesaka.ne.jp/keiei/cosmo-backno.html 「研修の５段階」には、 （１）参加した （２）理解した （３）やってみた （４）できた （５）効果がでた があるという。そうなんですよねー、まずは（２）と（３）に大きな隔たりがある。「アジャイル」である、ということは（１）－（４）が実践駆動であること」と言えるんじゃないかな。（５）を仮説型で設定し、とにかく反復でやってみること。 上記URLにも書かれているが、アジャイルでない人は、（２）の段階で、「あなたの言っていること
プロジェクトの「ふりかえり」 -- Retrospectives by Norm Kerth：An Agile Way：オルタナティブ・ブログ
Project Retrospectives、とはプロジェクトを全員でふりかえり、そこで何が起きていて、メンバーがどう感じたのか、をあぶりだすファシリテーション技術である。プロジェクトの途中で次のフェーズに有用なアウトプットを出すという使い方もあるし、プロジェクト終了時に、全員の健闘を称えあい、次のプロジェクトに生かす、という使い方もある。 私は「反省会」（ちょっとネガティブな感じ）と訳さずに、「ふりかえり」と訳すことにしている。 「ふりかえり」が、従来の「反省会」や「問題分析会議」と違うのは、それが全員参加で、かつ、参加者の「感情」部分の働きかえるものであり、建設的だ、ということ。誰かを非難したり、問題を抽出することが目的ではない。メンバーが、次のステージへ向かうための勇気を得ることが目的だ。だから、Norm が最初に書いているグランドルール、 「この会では、プロジェクトの全員が置かれた
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
