Manifesto for Software Craftmanship（ソフトウェア職人マニフェスト）にサインしよう：An Agile Way：オルタナティブ・ブログ
最近、アジャイル開発を「繰り返し型」の形として採用するのはいいが、そこで実際に開発活動をする人たちのスキルに、再度焦点が当たっている。つまり、プロジェクト管理手法としてのみアジャイルを取り入れても、破綻する、ということだ。ソフトウェア開発技術は、匠の技であり、この技術は職人の技だ。この議論は、 James Shore の「アジャイルの衰退と凋落」 Brian Marick の「What's missing from the Agile Manifesto」 Uncle Bob Martin の「Craftmanship over Crap」 などからの流れなのだが、ついに、「ソフトウェア職人宣言」が出現した。以下に、訳文とそのURLを書いておくので、同意する人は、サインをしよう！ ソフトウェア職人宣言(原文： http://manifesto.softwarecraftsmanship.o
「ふりかえり」が失敗する８つの理由：An Agile Way：オルタナティブ・ブログ
「アジャイルレトロスペクティブ」の著者、イースターダービーのStickymindsの短い記事です。 「ふりかえり」が失敗する８つの理由 Eight Reasons Retrospectives Fail ぼくは Retrospectives を「ふりかえり」、と訳している。オブジェクト倶楽部のプロジェクトファシリテーションのページに、天野さんが、日本語の「ふりかえりガイド」(PDF)もかいている。 簡単にまとめると、 「ふりかえり」が失敗する８つの理由 １．準備不足。 ⇒アジェンダをしっかり用意すること。 ２．焦点があいまい。 ⇒前回のイテレーションの改善に集中。 ３．データが集まっていない。 ⇒何かを変えようとするまえに、「実際に何が起きていたか」を話す。 ４．１人か２人が会議全体の会話を独占してしまう。 ⇒ペアにしたり、グループを作ったりして話あうアクティビティを持つ。 ５．自分たちで
x-dev で茂木さんと対談しました。：An Agile Way：オルタナティブ・ブログ
ぼくが株式会社チェンジビジョンを作ったときの夢は、「茂木さんのプロフェッショナルに呼ばれる」です。今日はその半分くらいが叶った気がした日でした。（写真は対談後、東京ドームホテル５F控え室にて） ぼくは、台風のお陰でタクシーにて10分遅れで会場に到着、なんと茂木さんをお待たせしてしまい、汗だくで走ってマラソン選手のように登場。そのまま、茂木さんのマシンガントークに押されながらも、応戦しました。普段の対談では、だいたいぼくはしゃべり負けないのですが、今回は７：３でしゃべり負けました！でも、茂木さんにWeb2.0的なものとはちがう、日本のソフトウェア開発業界もわかって頂けた気がしましたし、その上で、勇気をもらえる発言を引き出せたので、よかったと思います。 到着したとき、茂木さんは、「創造性＝体験×情熱意欲」という話をされていました。この部分はぼくは聞いていないのですが、「体験」の部分がさすが、茂
Java から Ruby へ：An Agile Way：オルタナティブ・ブログ
遅ればせながら、話題になっている、かくたにさんが訳している、Bruce Tate の本「JavaからRubyへ」を読んだ。 http://www.amazon.co.jp/JavaからRubyへ-―マネージャのための実践移行ガイド-Bruce-Tate/dp/4873113202 ぼく自身は、スクリプト言語好きなのだが、Rubyをほんの少ししか書いたことがない。でも、直感的にはかなり好きだと思う。closure みたいなものにびびっと来た時期もある。（後で気づいたのだが、ぼくは1998年にRubyのメーリングリストに短いプログラムを投稿していたりする。それに高橋さんがコメントをくれていたりもする。そしてその投稿は、matzが本を書くためにスクリプトを募集したものだったことが、今調べていて判明。このスクリプトは結局本には載らなかったのだろうと思うが。。。。 http://blade.naga
google video でオブジェクト倶楽部の動画公開：An Agile Way：オルタナティブ・ブログ
昨年１２月のオブジェクト倶楽部クリスマスイベントの動画をアップしました。 「ソーシャルチェンジ～世界の変化はあなたから」（平鍋健児） http://video.google.com/videoplay?docid=-7257264183783738026 今回、手元カメラ（書画カメラ）で絵を描きながら、「ソフトウェアは壮大な伝言ゲーム」ということを伝えてみました（※時間のない方は、１１分後くらいから見てください）。 他にも、 安井さん「ソフトウェア冶具」 http://video.google.com/videoplay?docid=-4683716686357753198 水越「マインドマップ」 http://video.google.com/videoplay?docid=7155483878277820392 などもあります。水越さんは、大きなホワイトボードにマインドマップを書きなが
今年の一言：An Agile Way：オルタナティブ・ブログ
今年の一言を書いてみた。今年は1/2に、ちゃんと弘法大師の掛け軸の前で書初めをした。「初心」である。しかし、書いていたら漢字が崩壊して分からなくなってしまい、「力」が「刀」を突き抜けてしまった。（これ、まじボケなんです ;_;） だんだん歳をとるにつれて、変化したり新しいことをトライしたりする「勇気」みたいなものが減ってきたように感じる。もともとやりたいことは、ソフトウェア開発にブレークスルーを起こすこと。このブレークスルーというやつは、一見勘違いか?、というあたりに潜んでいることが多く、たいがいは狙うと失敗する。セレンティピティに近く、たまたま、思っていたことと別の形で花開いたりする。 別の言い方をすると、「成功ポテンシャル」を空間上にプロットすると、現在の自分の位置というのは「小高い丘」になっており、少し進むと下に下降している。しかし、ブレークスルーは、「別のより高い丘」にあり、その下
Haskell で Bowling Score：An Agile Way：オルタナティブ・ブログ
ボーリングのスコアを計算するプログラムを設計、実装、テストせよ。 この問題は、Robert C. Martin の『アジャイルの奥義』の中でも、TDD（テスト駆動開発）的なアプローチがしばしば直感とは異なったクラス設計に行き着くことを示す例としても取り上げられている。 また、実はJUDEチームの定番の教育練習問題となっていて、新メンバーが来ると必ずこの問題を解き、良い設計とは何か、という議論をすることになっている。受け入れテストのみを示して、それを通るコードを書いてもらう。 ぼくは、この問題の回答として、かなり普通のクラス構造と名前（たとえば、FrameとかGameとか)が現れくるオブジェクト指向的な設計構造を含んだものを好む。特に第10フレームの扱い（他のFrameとの汎化関係）や、GameとFrameの集約関係に目が行く。もう１つのポイントは、ボーリングのスコア計算ルール（スペアやスト
My Job Went To India 読みました！：An Agile Way：オルタナティブ・ブログ
My Job Went To India ～オフショア時代のソフトウェア開発者サバイバルガイド http://www.amazon.co.jp/exec/obidos/ASIN/4274066592/xpjp-22/ すごい、いい本です。一見、オフショア開発が多くなり、実装だけではもうプログラマは要らない！というメッセージかと見えますが、そういうことではありません。当然これを訳しているのが、でびあんぐる、だし、日本での出版社がオーム社だし、きっといい本だろう、と思っていました。 著者は「達人プログラマー」に触発されてこの本を書いたそうだ。そう、達人プログラマにも、常に自分の知らない新しいタイプの言語を触ってみなさい、とか書いてあった（この本にも書いてある）。 それから、もっといろんな人と話そうとか、自分の勉強に投資しようとか、とってもいいことが書いてある。 なんのために、ソフトウェア開発を
開発の現場にてプロジェクトファシリテーションのワークショップ：An Agile Way：オルタナティブ・ブログ
永和システムマネジメントの川上さんが、プロジェクトファシリテーションの中でももっとも効果が高いとされるプラクティス、「ふりかえり」のワークショップを開催します。 http://www.shoeisha.com/mag/kaihatsu/workshop/ 有料セミナーですが、ぜひ、現場リーダー教育としてご活用ください。実際に参加してファシリテーション（司会のやり方）を体験してもらうことで、もちかえって自身の現場をカイゼンするきっかけを掴むことが、目標です。 ふりかえり、というのをご存知ない方のために、簡単に解説を。。。 ふりかえり、というのはチームが１つの開発単位（一週間とか一ヶ月とか）を終えたあとで、その期間をふりかえって、「次に活かせる何か」をチームで発見しよう、と言う試みです。うまくいったことは続ける。うまく行かない問題は、解決を考える。 KEEP = 続けて行きたいこと、PROBL
11年前に書いた awk スクリプト発掘（ギターコードを見る chordview）：An Agile Way：オルタナティブ・ブログ
ディスクを整理していたら、11年前に書いた awk スクリプトが出てきた。ギターのコード名を入力すると、そのコードフォームや構成音が表示される。コードブック代わりに使おうと思っていた。 当時、フォークギターからジャズギターへ転向しようと考えており、ローコードだけでなくハイポジションでの、6,5,4弦にルート音を持つ各ギターコードと、テンションの位置を勉強していた。 Jazzでは、例えば、メジャーコードは、1,3,5 度の音だけでなくM7と6と9、ドミナントコードは、1,3,5,b7 に加えて b9, 9, #9, #11, b13, 13 もテンションとして許される。それらを、キャラクタベースのCUIで表示するプログラムだ。通常のロックやフォークのコードではなく、自分のアドリブのインサイド音やテンション感を養成するために作った。例えば、Cの4弦ルートだと、こんなキャラクタを吐く。 D 型フ
Niko-Niko Calendar にこにこカレンダーのコミュニティ、blog で実験 (^_^)：An Agile Way：オルタナティブ・ブログ
坂田さんやヤマモトさんがやっている「ニコニコカレンダー」という今日の自分のムードの見える化手法がある。 http://www.geocities.jp/nikonikocalendar/index_ja.html チームの壁にこれを貼って、今のチームムードを全員でフィードバックする。ちょっとうまくリーダーに報告できないような「こころもち」も、これなら気軽に伝えられる気がする。略して「ニコカレ」。命名者は、 “つらい気持ちの人も、体調の悪い人も、変化のない毎日の人も、シールを貼っていくうちにこのカレンダーがニコニコマークでいっぱいになればいいなぁ、という気持ちでニコニコカレンダーとつけました。” という。mixi にも、「ニコニコカレンダー愛好会」というコミュニティがある。 ところで、「ブログ」というメディアを使って、「世界ニコカレ」の実験をしてみたい。ブログエントリの「題名」の最後に、自分
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 なハックだ。」 なるほどー。（ちなみに上映会の後、角谷氏は自転車で３０分以内で通える通勤路を見つけることを、「通勤ハック」と呼んでいた。） この映画を見て、採用と
Turbolinux Persoanal でのJUDE：An Agile Way：オルタナティブ・ブログ
bose さんの、Turbolinux PersonalでつくるJava環境というブログを発見。http://bose.techie.jp/?eid=193667 ここで、JUDE/Community(無償版UMLエディタ)のインストールについての体験をもとにした情報がある。 JUDEはPure Java アプリケーションであり、原理的にはOSを問わずJava環境で動作する。しかし、実際にインストールとなると、環境ごとで手間が違うし、癖もある。開発元としては全OSでサポートしたいのですが、やはり品質保証の問題で、その宣言がまだできないでいる。 そうしたときに、boseさんのようなユーザ情報は、とっても、とっても貴重になってくるし、みなさんのお役にも立つ。こういったすばらしいユーザに支えられているんだなー、とまた感涙なのです。
神様ルートクラスを嫌い、POJOを好む：An Agile Way：オルタナティブ・ブログ
ぼくがオブジェクト指向言語を勉強しはじめた90年ころは、「継承」という概念がとても流行っていて、継承によって「差分プログラミング」ができることがオブジェクト指向設計の再利用性の典型例のように言われていた。もちろん、こういう誤解は95年くらいには、みんなウソだと分かってきていた。 しかし、それでもときどき、 すべてのクラスの頂点のような「神様クラス」を作ってしまうことがある。 例えば、90年代の多くのC++オブジェクト指向データベースは、Persistenceのようなクラスを継承することで永続オブジェクトとなるクラスをマーキングしたり、あるベンダーのコレションクラスは、Objectというクラスを継承したクラスのオブジェクトのみがコレクションの要素となることができたり、という具合に。また、EJBも最近まではEntityBeanを継承することでEntityBeanの資格が得られるし、Servel
JUDEのAPI発表！：An Agile Way：オルタナティブ・ブログ
JUDE/Enterprise 2.4 がもうすぐ公開になります。今回の目玉は、API の公開です。要は、メタモデルアクセスの公開で、JUDEのモデルがプログラムから読めるようになります。 さて、メタモデルの仕様ですが、UML1.x にも、UML2.0 にも完全には合わせわせませんでした。というのは、OMGのメタモデルを理解するには、非常に時間がかかるからです。より、簡易で理解しやすいメタモデルをJUDEでは公開したいと思います。 これについては賛否両論あるかもしれません。もし、「ちゃんとOMGのメタモデルの仕様で公開すべきだ」という方はご意見歓迎です。ただし、一度、UML1.x と 2.0 のメタモデルを理解してから…（結構難しいのですよ）。 ←がその仕様です。今回は Read-OnlyAPIとして、クラス図、ユースケース図情報のみをアクセスできるようにします。今後、範囲を広げるとともに
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
JUDEのデモムービー公開：An Agile Way：オルタナティブ・ブログ