野中郁次郎先生を一橋大学に訪問、アジャイル、スクラム、創造、マネジメントについてディスカッションする機会を得ました。 先生はもちろん、ナレッジマネジメント、知識創造経営、そして、Scrumという言葉を生んだ、「The New New Product Development Game」という1986年の論文の著者の一人。もう一人は現在ハーバードの竹内さん。一昨年の AgileJapan 2010の基調講演、昨年は、Jeff Sutherland との対談が Innovation Sprint で実現、ハーバードの竹内さんのクラスにJeff Sutherland が呼ばれたりするなど、アジャイル会との交流が進んでいます。 ぼくが持ち込んだ、顧客を巻き込んだ、見える化された職場のワークスタイルの写真なんかを見ながらお話ししていたら、 PDCAって日本人大好きなんだけど、これは本当に欲しいもの、い
ソフトウェア工学の祖の一人である、トム・デマルコが、最近IEEE Software 誌に、過去のソフトウェア・メトリクス賛美を悔い改める記事を書いている。 「ソフトウェア工学」というコンセプト－その時が来た、そして、その時は去った。http://www2.computer.org/portal/web/computingnow/0709/whatsnew/software-r 1982年に、デマルコは有名な「計測できないものは制御できない」という一文から始まる、『品質と生産性を重視したソフトウェア開発プロジェクト技法』という名著を書いている。このドグマは、ソフトウェア工学の考え方に強く根ざしている。むしろ、すべての「工学」という活動は、科学や経験から得た知見を使って自然現象をコントロールし、人間の役に立てることをその定義としており、そこでは測定を元にしたコントロールという概念はその中核にあ
【文法を腑に落とすこと】 ぼくらはネイティブのスピーカーではないから、理論的なバックアップなしに、無意識に英語を操れるようになるようにはなれない。この「理論的バックアップ」が、文法だ。ところが、学校で習う文法というのは論理性を重視するあまり、実用でない、というのがぼくの印象。もちろん、SV、SVC、SVO、SVOC、SVOOの５文型とか、時制のこと、などは「知っておいたほうがよい」。学校でならう文法はかなりうまく現実を説明している。 一番うまく説明できていないのは、a, the, 無冠詞を含む「冠詞」の問題、それから名詞の「単数・複数」。これらは、ほぼ、学校文法では納得できる説明がなく、さらに、ネイティブスピーカーに聞いても（彼らにとっては無意識なので）よい回答が得られないのだ。 これらを含め、ぼくがお勧めするのは、英会話ができる日本人の英語文法の本、および、日本語が書ける英語ネイティブの
明けましておめでとうございます。 去年は少し、アジャイル・アジャイル言い過ぎた気がしており、今年はもう少し大切なことの範囲をエンジニアリングに回帰して、再度言おうと思っています。 オブジェクト指向やテスト技法をはじめとするソフトウェア工学の知識とスキルは、ソフトウェア開発に携わる人には絶対必要なもので、その上で、プロジェクトマネジメント手法としてのアジャイルがある。 ということは、もういちどちゃんと言っておこう。そう思った動機は、James Shore の「Art of Agile Development」を訳したこと。そして、それはXPの本だったこと。ここ３年くらいXPという言葉はAgile界では下火になっていて、AgileといえばScrumという風潮だったのが、「エンジニアリングの無いScrumは所詮うまく行かない」、というJames Shoreの当然な一撃があった。InfoQの日本語
ぼやっと思っていることを、形にしてみます。 ぼくはずっとソフトウェア開発は「工学」だと思っていました。コンピュータサイエンスの部分はあるけれど、再現可能にしていくには工学的な要素が重要です。だから、オブジェクト指向や構造化設計といった設計技法、テスト技法はとても大事。しかし、いざ「現場」のソフトウェア開発となると、プロジェクトのスケジューリングや調達、納期やコスト、といったプロジェクト管理の側面が強くなります。ここは、ソフトウェア開発プロジェクトを成功させるためにはとっても大事。 さて、大事であることは大事なんだけど、この２つ（ソフトウェア工学とプロジェクト管理）をやっていれば成功する、というものではないのです。実は、プロジェクトに参加している人が「いいものを作りたい」と思っているかどうか。この１点が、50%以上のファクタでプロジェクトの成功に効いて来る、と気づいたのは2000年にアジャイ
「リーンソフトウエア開発第二版」からの気づきと引用シリーズです。 現在、日本でも多くの企業がTPS（トヨタ生産方式）を企業活動に取り入れようとしています。このムーブメントがアジャイル開発と結びつき、現場を活性化し、デスマーチをはじめとする現場の問題と、品質に関する社会問題を解決できるといい、と心から思っています。 ただし、ひとつ警鐘を鳴らしたいと思います。強いトップダウンオンリーでこの改革を現場に持ち込まないこと。そして、マネジメントは、本当に現場の人間の力を信じること。理想論ではなく。 以下、引用になりますが、 リーンを成功させるには、作業を行っているその人、本人が、その作業のやり方を最もよく知っているのだ、という基本信念を、あなた自身の人に関する考え方に取り込まなくてはならない。プロセスから人を排除したり、作業に必要なスキルレベルを下げたりする自動化には、注意が必要だ。現場での意思決定
RubyKaigi初参加。ちょっとやんちゃなこともやってみたいと思い、ライトニングトークスに参加しました。 ロガーの zunda さんありがとう。適切なログがあります。 http://jp.rubyist.net/RubyKaigi2007/Log0609-LT02.html おかげで懇親会でたくさんフィードバックもらいましたし、何名かのかたとちょっと深い話もできました。自分にとって新しいことを試すのは、いつでも勇気がいりますが、見返りも大きいものです。 また、ぼくだけのために書画カメラを準備してくれた、（最近彼女ができた）笹田さん、どうもありがとうございました(^_^)。愛ですよね、愛。 ※追記(6/19) AkiyahさんがYouTubeに動画をアップしてくれました。 個人的に感じたこと。 コミュニティは、内容でなく「人」で選ぶのがよいのではないか？（Rubyコミュニティすごい） 高橋
『ソフトウェア開発に役立つマインドマップ』という本を書きました。構想から1年以上もたってしまいましたが、ようやく形にすることができました。 http://www.amazon.co.jp/ASIN/dp/4822283143/xpjp-22 ぼくはマインドマップに始めて出会ったときに、そのインパクトと人間らしさ、自由さ、発想を広げる柔軟さに惹かれました。そして使ってみるうちに、こういう「楽しい」、「やわらかい」ものがもっとソフトウェア開発の中に使えないか、という思いにとりつかれるようになりました。 いろいろ試してみてうまく行くものを取捨選択し、この本の中に詰め込むことにしました。中にはちょっと実験的なものも含まれていますし、議事録テンプレートのように、すでに僕の中では定番になっているものもあります。これらを、使える形でみなさんに提供し、ソフトウェア開発現場をより明るく生産的な活動の場、とす
ちょっと長いが、今朝のKent BeckのXPメーリングリストへの投稿を引用、要約したい。このメールは、「XPは第二版になって、その過激さを失った」というスレッドへの回答になっている。 RE: [XP] Do it by the book Wed May 2, 2007 1:32 am XP2nd になってXPは「ダイヤルダウン」した、という意見をよく聞く。1stよりソフトに、柔軟になったといわれるのは嬉しいことだ。2ndが攻撃性を欠いているのは意図的だ。ぼくのゴールは、「価値」(value)を基礎にした「原則」(practice)を活用することで、できるだけアジャイルになること。「実践項目」(practice)のチェックリストを作ってしまっては柔軟性を失ってしまう。実践項目は外的要素との重ねあわせだ。価値と原則に沿って行動することで柔軟性が増すが、自身が意識を持つことが必要だ。よい考えを
My Job Went To India ～オフショア時代のソフトウェア開発者サバイバルガイド http://www.amazon.co.jp/exec/obidos/ASIN/4274066592/xpjp-22/ すごい、いい本です。一見、オフショア開発が多くなり、実装だけではもうプログラマは要らない！というメッセージかと見えますが、そういうことではありません。当然これを訳しているのが、でびあんぐる、だし、日本での出版社がオーム社だし、きっといい本だろう、と思っていました。 著者は「達人プログラマー」に触発されてこの本を書いたそうだ。そう、達人プログラマにも、常に自分の知らない新しいタイプの言語を触ってみなさい、とか書いてあった（この本にも書いてある）。 それから、もっといろんな人と話そうとか、自分の勉強に投資しようとか、とってもいいことが書いてある。 なんのために、ソフトウェア開発を
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
