デブサミからもらったものをデブサミに返してきました。 - The Dragon Scroll
2010年のデブサミが、自分にとってこれまでと違うデブサミになりそうだと最初に考えたのは、DevLOVEコミュニティで97本の読書会を開いた時だった。 読書会後の懇親会で、この本の監修者であるyusukeさんに、「デブサミで話してみないか」という誘いを受けた。私はその時、yusukeさんが冗談を言っているのだと思った。 そもそも、デブサミは私にとって特別なイベントであり、その特別な場所で私が壇上に立って、話すというのは、好きなプロ野球球団から、バッターボックスに立ってみないかと言われているのと同じことを意味した。 ところが、yusukeさんの次の一言が深く自分に突き刺さり、「デブサミで話す」ということがリアリティのある話として感じられるようになった。 「聞きに来る人が、たとえ10人でも1人でもいいではないか。何を考えているのか、少なくとも私は聞いてみたい。」 こんな嬉しい言葉を一体人生で何
「テストとは、自分のバカさ加減を知るためのもの」 - The Dragon Scroll
id:t_wadaさんとは、きちんとお話をしたことがなかったこともあり、DevLOVEのイベント打合せを 名目にして、アルコール片手にお話をお伺いした。 イベント打合せ以上の話が聞けて、興奮冷めやらぬ感じ。逆に、t_wadaさんにはDevLOVEコミュニティ とは、何を大切にしたいコミュニティなのかを知って頂いた。 以下、お話の中で特に印象に残ったことを書き残す。 - 今回のDevLOVEイベントで話すこと。 ・DeveloperTesting。 ・開発の現場で、たびたび遭遇するレガシーコード(テストコードがない)に、どう対処するか。 ・2004年7月1日、チームかくたに以前の話。 なお、この本の翻訳は今年の夏頃になるらしいです。 Working Effectively With Legacy Code 作者: Michael Feathers出版社/メーカー: Prentice Hall
コミュニティや職場で、ハンガーフライトしよう。 - The Dragon Scroll
飛行機乗りの世界では、ハンガーフライトという言葉があるそうだ。 天候が悪ければ、良くなるまで、ハンガー(格納庫)で待つ。その間、同じように天候の回復を 待つ他のパイロットと雑談をする。この雑談が、飛行に関する貴重な情報源となっていたらしいい。 というのは、一人の人間が経験できることは限られているからだ。 お互いの体験談を話すことによって、それぞれの経験を共有することができる。 さて、稲作60回の話。 「まだ６０回しか稲作したことがない」という含蓄ある言葉 - サンフランシスコ出羽守手記(masayangの日記 システム開発も同じ。一人が、経験できるプロジェクトの数など、知れている。 だから、システム開発なんて、いつまでたっても手に負えることはない。 とは思わない。 経験は、その人自身のもの(経験とは、行動を起こした人への唯一の褒美)。全く同じ経験を、他の人が 手に入れることはできない。 し
社内で企画物を開催するときの切り札 - The Dragon Scroll
MetaConのキックオフミーティングで、こんな問いかけがあった。 "社内勉強会を開催するためにはどうしたらいいか。上司の理解得られず、開催できない。" そういえば、社内で勉強会を開催するにあたり、今所属する組織で、"積極的な否定"というのは 受けたことがないなと思い起こした。 確かに、社内には、社内ならではのルールがいくつかあり、開催にあたっては、それらのルールを クリアしなければならない。なかなか面倒なことが多い。 3月に、社内外問わずのイベントを開催したときは、細かいところで、"ちょっと待て"ということは あったが、全般的に協力的で、非常に助かった。それもそのはずで、私が所属する組織は、積極的に 社内勉強会を奨励する制度がある。逆に、構成員の方がそれを十分に活かしきれていないくらいに思う。 ただ、突飛なこと(=前例のないこと全て)をやろうと思うと、ハードルはとたんに高くなる。 "やめ
顧客対応のベストプラクティスは存在するのか。 - The Dragon Scroll
お客様とのやりとりで、困ることが少なくない。 進捗報告の粒度や、仕様変更やリスクに対する考え方、 プロジェクトの舵取りについて、意見が異なることは 普通にある。 こちらの言い分を主張したところ、容易には事は進まない。 しかし、こちらも、正論を言っているつもりだから、 引き下がれない（引き下がりたくない）し、 他のことを考える頭には切り替わらない。 そうなると、問題は、一向に解決には至らない。 頭の切り替えはやはり必要で、顧客も自分と同じ 一個人であることに、立ち返らなければならない。 個人的な思考や思想を持ち、無意識にうちに、それに 則って行動をしている。 "顧客"という言葉で、人を人くくりになんてできない。 現場にある、顧客と開発との関係は、個人対個人で、 まさに目の前にいる相手のことをどうにかしないといけない。 そこにはベストプラクティスは存在しない。 相手にあわせた、態度と姿勢で、話
この業界が変わるわけがないと、言う人はまだいるだろうか。 - The Dragon Scroll
社内で、アジャイルプラクティスの読書会を開いている。 今日は、その第四回。 アジャイルプラクティスをみんなで読んでいて、感じるのは、 現場には現場のプラクティスが既にあるということ。 その知恵を共有することで、新たな気づきを生むことができる。 Aという現場で抱えている問題は、すでにBという現場で解決を している。でも、それをシェアするようなタイミングも場も 無いから、同じような問題をそれぞれが解決している。 もっと、もっと、組織の壁は越えていい。 さて、この視点を広げてみたらどうだろうと思った。 つまり、社内でやっただけでも、我々は、前進することが できた。 では、会社の壁を越えて、そんな場を作り出すことができたら、どうか。 AというSIerとBというSIerは同じ悩みを抱えているかもしれない。 しかし、CというSIerはそれを既に解決しているかもしれない。 会社という壁を乗り越えたとき、
モノには、意味と形が備わっている。 - The Dragon Scroll
モノには、意味と形が備わっている。 例えば、「商品マスタ」というモノには、「商品マスタ」という 名前が付いている。これが、そのモノを表す形。 一方、意味も持っている。 Aというシステムで扱う、「商品マスタ」と Bというシステムで扱う、「商品マスタ」とでは、 形は同じかもしれないが、意味が全く異なる場合がある。 この「意味」を顕すことは、実は単純にはいかない。 「意味」は、他のモノとの「関係」で、初めて顕すことできる。 単体で、自明の意味を持つと考えることができる モノがあってもおかしくはない。 だが、突き詰めて考えると、果たしてその「意味」は 誰にとっても同じ認識、ぶれることのない「意味」と言えるのだろうか、 と考え始めたときに、疑わしくなってくる。 この「顧客マスタ」は、顧客を管理するエンティティです。 では、この「顧客」とは何か、取引先か、得意先か、仕入先か。 どうやれば、その意味を確
いきなりエベレストの登頂を目標にするのはやめよう。 - The Dragon Scroll
要件定義フェーズで、お客様と会話をしていると、その要望が止まらなくなってくる、 ということはよくある話だ。 基幹システムリプレースともなれば、その積年の思いの対象も限りなく広くなる。 いかに、現行のシステムが使いにくいか、どうしたいかをとうとうと語り出し はじめる。いったい、その話は、今回の開発のスコープなのか、それとも単なる 愚痴なのか…。 とにもかくにもお客様の、現行のシステム・業務を改善しようという思いは 強い。 一方、そのような話を聞くと、同情にも似た気持ちがエンジニア側に沸く。 これはひどい。分かりにくい。混沌としてる。混乱している。 こんなシステムを使って良く業務が回る。これなら、現行よりももっと良いシステムを 作ることができる。 依頼主と、作り手の思いはある時点、ある意味では、一致している。 それが、なぜいつの日か、そう遠くもない、いつの日にかは プロジェクトは破綻し、デスマ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
残業しているとなんとなく偉いという都市伝説。 - The Dragon Scroll