ソフトウェア技術者のための英語（7: Nice）：An Agile Way：オルタナティブ・ブログ
日本語でも日常的にカタカナ使われる単語、というのは、時として外国人に通じにくいことがある。日本語の用法に慣れてしまっていて、それが英語の本来の意味からずれているからだ。 例えば、ナイス(nice)という言葉がある。おおむね、「素敵」、「いいね」、という日本語感覚で使ってよいが、nice の本当のコアは、ここではない。例えば、次の英語を日本語で訳せるだろうか。 "I like Fukui, because people are nice." 人々がナイスだから、福井（平鍋の故郷）が好きだ。ということなのだが、この文章が腑に落ちたときに、nice の意味が獲得できる。この nice は、人が「優しい」さらには、「気持ちよく人に接する」という意味で、nice の中核に触れている。最近の日本語だと、（人が）「感じいい」という言葉がぴったりくる。 この nice に最初触れたとき、日本語のナイス、と
年代による休日の時間の過ごし方の変化：An Agile Way：オルタナティブ・ブログ
最近、休日になると目一杯、仕事と離れて家族との時間を重視するようになった。昔は、仕事をしたりソフトウェアに関する自分の趣味をしたりする時間をできるだけ取りたいと思っていたのに。。。このへんの変化について。 20代の休日は、とにかく仕事をしたと思う。あまり平日とか休日とかかまわず、仕事（会社のなかでの仕事）の続きを家でも考えていた。また、恋愛で忙しかったり、会社の同期との活動などに時間を使っていたかも。結婚が25歳なので、結婚準備や引越しやらに追われた時期もあった。 30になって、東京の仕事を退職して、福井に帰ってきて、永和システムマネジメントに入社した。最初の子供が生まれたのも30歳。30代前半は、会社の仕事は会社で、それ以外のソフトウェアに関する活動を、土日を使ってやっていた。時にはプロジェクトが大変になり、土日も関係なく仕事に追われたときもあった。でも、「会社の仕事をやってる」というモ
devsumi2009 デブサミに参加しました：An Agile Way：オルタナティブ・ブログ
2/12, 13 と翔泳社主催の「デブサミ」こと、デベロパーズサミット2009に参加しました。 主に、開発プロセストラック（＝角谷トラック＝アジャイルトラック）を中心につまみ食いです。ここ数年、どのイベントに行っても、ぼくはセッションを基本的に「人」で選んでいます。なので、「この人のセッション」、といういい方で紹介したいと思います。順序にはあまり意味がありません。 ぼくのセッション（倉貫さん、千貫さん、橘さん、藤原さん、平鍋） 「使う」と「作る」がつながるシステム開発、という題名でパネルディスカッションをしました。作る側の人と使う側の人が現在のSIの中では遠く感じられませんか？この原因、今後のSIの構造を探るセッションです。藤原さんに、書画カメラをつかってセッションのメモをファシリテーショングラフィックスしてもらいました。 倉貫さんの１つの結論は「SIerはいらなくなる」というもの。でも、
Designing a framework in an "open" way (オープンなフレームワーク設計)：An Agile Way：オルタナティブ・ブログ
"Beautiful Code" を読んでいます。 いいですねー。カーニハンやベントレー（『プログラマの打ち明け話』、『珠玉のプログラミング』、『プログラミングの設計と着想』など、昔ファンでした）の文章をひさしぶりに読みました。まだまだ、プログラミングにもわくわくすることが一杯ありますね。 ぼくが最も感動したは、Michael Feather （"Working Effectively with Legacy Code"の著者）の "Framework for Integrated Test: Beauty Through Fragility"(英語GoogleBook全文) です。コーディング（プログラム設計）に関する Ward Cuninngham の逸話はいくつもあります。November メソッドの話、400行の Perl で書かれた初版 Wiki の話、などなど。 今回は、Web
RubyKaigi2007 での Dave Thomas 基調講演 - An Agile Way [ITmedia オルタナティブ・ブログ]
ぼくは、Rubyistではありませんが、このコミュニティにはたくさん知り合いがいます。1998年にDDJ記事のためにオブジェクト指向スクリプティング言語を調べているときに、前田修吾さんのdemi（RubyのJavaブリッジ）を見ましたし、256倍極道編の助田さんや、神戸の列車事故で亡くなられた石井勝さんとも、2000年くらいからXPを通して出会っており、長い Social なお付き合いがありました。 また、今回のRubyKaigi2007の基調講演のDaveはAgileとRubyをつなぐ役割を果たしており、1999年に彼は『達人プログラマー』(Pragmatic Programmers)を書き、その後すぐに、『プログラミングRuby 達人プログラマーガイド』(Programming Ruby : The Pragmatic Programmer's Guide)を書いています。（このあたり
残業のない開発現場、ビジネスとITのリスク共有：An Agile Way：オルタナティブ・ブログ
TRICHORDの開発は、完全にアジャイル開発です。タイムボックスを区切ったマネジメントスタイルで、基本的に残業はなしです。っていうか、一日３コマのペア・プログラミングをやったら、へとへとで残業できません。ということを言ったら、記事になっていました。 残業ゼロの開発現場 http://itpro.nikkeibp.co.jp/article/OPINION/20070523/271904/ なぜ残業をなくせるかというと、それは（当たり前のことなんですが）開発のビジネスオーナーが自社だからです。受託型の開発だと、それはなかなか難しいのだと思います。つまり、ミッションとリスクをビジネスとITの間で分割してしまうと、そこでWin-Win関係と良好なコミュニケーションを確立することが難しくなってしまいます。 市場を「調査」し、仕様をまとめ、それを「発注」する。そして、それを開発し、「納品」し、市場
永和システムマネジメントがネットワーク応用通信研究所(NaCl)さんとRuby + Agile で業務提携：An Agile Way：オルタナティブ・ブログ
ネットワーク応用通信研究所(NaCl)さんと、Ruby + Agile で業務提携」というニュースをリリースしました。 永和システムマネジメント：http://www.esm.co.jp/news/newsrelease20070516.html NaCl：http://www.netlab.jp/news/2007/05/16/20070516/ ビジネスの変化をすばやく捉えて開発するアジャイル手法と、柔軟で人にやさしい言語のRuby。ともに、「人を中心にすえて、人が使いやすいシステムを、人が開発する」という視点にたった、顧客と共同チームでの開発を提案します。 このリリース文ですが、かなり「思い」がこみ上げてくる文章が一部入っていて（ここはかくたにが書いているのですが）、「リリース文ぽく」なくて気に入っています。 ソフトウェアは、『育てるもの』と捉え、顧客と開発者がひとつのチームとなって
Ruby+Agile で誠実なソフトウェア開発を。：An Agile Way：オルタナティブ・ブログ
お客様に価値を継続的に提供できる、開発がやりたい。 価値を見て分かって触ってもらえる開発がやりたい。お客様の喜びが、開発者の喜びに直結する開発がやりたい。 こういうテーマで、永和システムマネジメントで技術者と管理者が議論しました。 誠実なソフトウェア開発を、 Agileに行うことで、顧客RoIと連動した開発を、 Ruby on Rails を使うことで初期コスト、変更コストを最小限に。 行いたいんです。このコンセプトを、ぜひ実装したい。一緒にやって頂けるユーザはいらっしゃいませんか。変化、にたいして、本当に敏感に反応できる開発ができる可能性があります。大きな投資を初期に決めてしまうのでなく、やりながら考えてくれるユーザ。 これが実現できるのは、変更を抱擁できる言語(Ruby)＋フレームワーク(Rails)＋開発プロセス(Agile)、そしてユーザと対話できる開発者側の会話力と共感力、そして
KPTを使ったプロセス改善(2)：An Agile Way：オルタナティブ・ブログ
Issue … Problem の本質化。問題を見つめ、本質的「課題」としたもの。「５回のなぜ」などで到達できるもの。「アンチパターン」や「AntiPractices」では、root causeと呼ばれている。 Knowledge … Keep の結晶化。Keepの中には、ナレッジとして抽象化できるものがある。ナレッジの表現形式としては、「名前付け」がまず必要。そして、それを表現する形式としては、Pattern、新しいPractice、AntiPractice、Tips、FAQ、注意書きとして、壁に貼るなどが考えられる。 これを、KPTIRK（ケプターク）と言う名前でKPTの拡張として、Alistairに提案したところ、「日本人はカイゼン慣れしてるな～」という感想をもらった。 hiro さんのご要望にお答えして、KPTIRKのフォーマット例。まだ決まったものはない。 Keep->Knowl
ユーザ要望の聞き取り方を学ぶー究極の目的とは？：An Agile Way：オルタナティブ・ブログ
ユーザ要望の聞き取りをする場合、利用者や利用場面を聞くことは重要だ。しかし、もっとも重要なことはなんだろう？それは、そのシステムを作る目的は何か、だ。要求開発でも言われているように、「正しくない要求を正しく実装しても意味がない」。そのシステムを作る目的をはっきりさせることが、要求を聞き取る場合に最も重要なことだと思う。 目的はいくつかある、というかもしれない。では、究極の目的はなんだろう。それを聞き出す、魔法の質問がある。 作ろうと思った動機はなんですか？ この質問は、ぼくが家をたてるときにミサワホーム福井支店の営業、大野尊言さんに聞かれて、感動したものだ。ぼくは家を建てるときに、自分でラフなRFPを書いて数社に提案をお願いしようとした。他のハウスメーカーや工務店が、予算、間取り、和洋、などを聞いてきたのに対して、大野さんは、この質問をした。「家を建てようと思った動機はなんですか？」 ぼく
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 なハックだ。」 なるほどー。（ちなみに上映会の後、角谷氏は自転車で３０分以内で通える通勤路を見つけることを、「通勤ハック」と呼んでいた。） この映画を見て、採用と
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
