Always All Ways

Apologies, Glances and Messed Up Chances

Spotifyのエンジニアリング文化

Agile Management

動画

Spotify Engineering Culture - Part 1 という動画がとてもよかったので、貼り付けておきます。

Spotify Engineering Culture - part 1 from Spotify Training & Development on Vimeo.

関連する参考記事

藤原さんのこの翻訳もあわせて読みたい。同じテーマのHenrikのブログ記事の翻訳です。

組織に変化をもたらすための4冊+1 〜Fearless Change（翻訳版）の出版に寄せて〜

Agile Book Management

書籍"Fearless Change: Patterns for Introducing New Ideas"の日本語訳が出版され、ありがたいことに献本をいただきました。翻訳者にはアジャイル界隈で日頃お付き合いをいただいている方々の名前が並んでいます。

原著は Mary Lynn Manns, Ph.D. と Linda Rising, Ph.D.による名著で、2004年に出版されています。それが10年の月日を経て、待望の日本語版が出版されたということです。私自身もこの本は既に原書で読んでいましたが、日本語版についても改めて目を通しています。
そういえば、今の会社に入る時のインタビューで「何をやりたいのか？」と聞かれて、「組織のtransformationをやりたい」と答えたことを思い起こすとともに、今まさにこの本を読み返す必要が出てきたタイミングで日本語版が出版されたのも何かの縁と思っています。

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

組織に変化をもたらすための4冊

さて、この書籍自体については、いろんなところで既に書かれていると思いますので、ここではこの本を含めて、組織に変化をもたらすことを考える時に参考になる書籍を4冊ほど紹介しておこうと思います。

Leading Change

Leading Change

Influencer: The Power to Change Anything

Influencer: The Power to Change Anything

  • 作者: Kerry Patterson,Joseph Grenny,David Maxfield,Ron McMillan,Al Switzler
  • 出版社/メーカー: McGraw-Hill
  • 発売日: 2007/08/22
  • メディア: ハードカバー
  • クリック: 1回
  • この商品を含むブログを見る

Switch: How to Change Things When Change Is Hard

Switch: How to Change Things When Change Is Hard

Fearless Change: Patterns for Introducing New Ideas

Fearless Change: Patterns for Introducing New Ideas

そしてさらに1冊と言えば…

Jurgen Appelo氏が前述の4冊にインスパイアされて書いた小冊子が"How to Change the World"です。日本語版は達人出版会のページからどうぞ。

"The Healthy Programmer"を読み始めている

Agile Life Book

あまりにもBlogをサボっていて書き方を忘れてしまいそうだし、またいつも本は読み終わってから書評っぽいBlogを書こうとして読んでいるうちにその気がなくなってしまうということも続いているので、とりあえずこの本については読み始めの段階でなんか書いておこうと思います。

The Healthy Programmer: Get Fit, Feel Better, and Keep Coding (Pragmatic Programmers)

The Healthy Programmer: Get Fit, Feel Better, and Keep Coding (Pragmatic Programmers)

健康って大事だね、と思ってからどうするか？

読み始めたきっかけは、確かtwitterかなんかでたまたまこんな本が出ていることを知ったからなのですが、その前からいろんなことが自分の周りで起きていて、やっぱり仕事をするに当たって（当たり前だけど）健康って大事だね、と思っていたことも背景にあります。
で、誰もが「健康って大事だね」なんてことはわかっていると思うのですが、なかなか生活習慣を変えられなかったりしているのが現実です。そこでどうやって生活習慣を変えて「健康なプログラマー」を目指すかというのが本書のテーマです。

健康な生活に向けたアジャイルなアプローチ

この本は、意外にもちゃんとした学術的な根拠や理論に基づいて書かれているっぽいのですが、本文はあまり堅苦しくなく、参照文献などもいちいち示すのではなく巻末にまとめて挙げておくに留めるなど、読みやすくする工夫をしてあります。そのため、特に医学や脳科学やその他さまざまな前提知識というのはあまり必要とされません。
しかしながら、プログラム開発やシステム開発プロジェクト、特にアジャイル開発についての前提知識があると非常に理解しやすく、また楽しんで読めると思います。目次をざっと眺めてみるだけでも、それは容易に想像できると思います。

組織を変えるための個人レベルの変革にも通じる

…などと言ったらいいすぎでしょうか？でも、一人一人の習慣や行動を変えることは組織を変えていく上でも重要なことであり、その個人レベルの変革を促す科学的アプローチを知っておくことはとても役に立つと思います。
そうです、この本は"transformation"について書かれた本でもあるのです。

Let's refactor your health.

開催間近！ Agile Tour Osaka 2013

Agile

今年もAgile Tour Osaka 2013が開催されます。
開催日程が近づいてきましたので改めてご案内させていただきます。
毎回、開催日が近づくと申込みが集中する傾向にあります。ご興味をお持ちの方はお早めにお申し込みを。

開催概要

  • 日時：　2013年10月5日(土) 10:00-16:15
  • 場所：　伊丹商工プラザ
  • プログラム：
    • 基調講演　「アジャイルマーケティングがより良い製品を届ける」 Chris Kruppa氏
    • セッション１　「すぐそこにあるDevOps」 日本マイクロソフト　長沢 智治氏
    • セッション２　「プロジェクトを導くしなやかな背骨」 山本雄一郎氏

※詳細および申込みは以下のサイトをご参照ください。

ウォーターフォールの興亡２

Agile

３年前に旧ブログで「ウォーターフォールの興亡」というエントリを書きました。

昨日、そこにコメントいただき興味深い論文を紹介いただいたので、こちらでもご紹介しておきます。

The Rise and Fall of Waterfall

まずはその前に、旧ブログのエントリの方で貼り付けていたYouTubeの動画がブロックされて日本では観れなくなっているようですので、改めてvimeoにある動画を貼り付けておきます。

ウォーターフォールモデルの誤解を解く

そして、そこに昨日コメントいただいた小椋さんのブログエントリが

です。

Royceのモデルがどこかでウォーターフォールという名前のもとで誤解とともに広まってしまった悲劇は有名ですが、「では、いったい誰が最初にウォーターフォールという言葉を使ったのか？」というテーマで小椋さんが書かれた論文がダウンロードできるようになったそうです。

結論めいたものをブログ本文から引用すると

そこで、誰がウォーターフォールという言葉を最初に使ったのか、そして、誰がロイスがウォーターフォールの提唱者だと誤解を広めたのかを調べることにしました。
その結果、ウォーターフォールという言葉を最初に使ったのはベルとセイヤーの1976年の論文で初めて使われたこと、その誤解を広めたのはソフトウェア界の大御所であるベームが、その著書でロイスがウォーターフォールのオリジナルだといったことが原因であることを解明しました。

ということだそうです。

だからなんなんだ？という意見・感想もあろうかと思いますが、まずはRoyce論文についての復習と歴史のお勉強として。

ダウンロード

小椋さんの論文はこちらからダウンロードできます。

「ワークショップデザイン論」を読んで

Learning Book

私自身は、研修やセミナーなどで行われるワークショップが苦手です。もちろん、よく考えられて運営されたワークショップで多くの気づきを得る場合もあるにはあります。しかし、なんとなく「ワークショップ的な」ことで適当に時間を埋められたり、なんとなく「座学だけではなく体験型の研修を演出してみました」的なものに付き合わされている感があったり…そんなワークショップも少なくなく、そんな時は疲労感しか残りません。

というわけで、「ワークショップ」と聞くと「面倒くさいなー」「普通に座学させてくれないかなー」とか思ってしまうわけです。（それとは少し違いますが、「パネルディスカッション」という言葉にも似たような感覚を持ってしまうことも多いです。）

そんな私ですが、別にだからと言ってワークショップそのものが悪いとは思っておらず、それがちゃんと「デザイン」されていないというところが問題なのだろう…と思うくらいには大人になりました。

そして、

が出版されると聞いたときには早速予約して、今、手元に置いて読んでいるわけです。

で、この本は、良いです。

理論と実践のバランス

帯には「ワークショップ実践の必携書」というフレーズが踊っていますが、いわゆる実践面のみにフォーカスした「How-To本」ではありません。かと言って、研究者が理論面でのみ書いている本でもありません。理論的バックグラウンドをしっかり押さえつつ、実践の場での事例など含めて具体的なワークショップについても述べており、そのバランスがとてもよい感じです。

理論でときほぐし実践へ

この本を読んでいると、冒頭に述べたようないわゆる「ワークショップに対する漠然とした不満や違和感」の正体がなんとなく理論的に解きほぐされていくように感じます。まぁ、確かにそうだよね、と。その上で、じゃあどうしたらいいのか？自分がワークショップをデザインする時にこれから何をどう考えるべきなのか？そんなことを考えさせられるわけです。これは楽しみでもあり、プレッシャーでもあります。

これからワークショップのデザインや運営などに携わろうとしている人にはおすすめの一冊です。

ワークショップデザイン論―創ることで学ぶ

ワークショップデザイン論―創ることで学ぶ

見積りは必要？〜No Estimates Movementについて〜

Agile Management

今年に入ってからしばしばtwitter上で#NoEstimatesというハッシュタグを目にします。その議論は未だに続いているようですが、ここらでちょっと（後で自分で考えるためにも）簡単に整理しておきたいと思います。（全ての議論を追っているわけではないので、事実誤認などもあるかもしれません。お気づきの点などあればコメントいただけるとありがたいです。）

はじまりは、この辺？

おそらく、最初のきっかけとなっているのは、Woody Zuillが、No Estimatingのカテゴリーで書いているの一連のブログ記事ではないかと思います。

で、本人曰く、 #NoEstimates というハッシュタグを最初の使い始めたのがおそらく彼だろうということです。

もう一人、積極的にこのテーマについて発信しているのが、Neil Killickです。彼のブログには#NoEstimates３部作とも言える一連の記事があります。

Neilのプレゼンテーションもこちらにあります。

その後のいろんな議論

以降、 #NoEstimates のハッシュタグのもとでtwitter上でもいろんな意見が交わされてきています。また、そのトピックに関するブログ等の記事もいろんな人によって書かれているようです。
そしてついに4月末頃に大御所Ron Jeffriesが

という記事を書いています。
もっと最近のところでは、読んで面白かったのは、Michael Dubakovの

と、Glen B. Allemanの

です。
これからも引き続きtwitter上でもこの議論は続きそうですし、新しい記事も出てきそうなので要チェックです。

で、結局なんなの？

それがわかればとっくにこの議論は終わっているはずなのですが、…。
とりあえずざっくりと（あまりにも大雑把なまとめですが）自分なりに思うところをまとめてみたいと思います。

  • #NoEstimates というのは、単に「（ソフトウェア開発における）見積りなんてどうせ正確にできるわけないし無駄だからやめてしまえ！」という話ではなくて、「見積り」という手段よりもっとよい方法で必要なものが得られればその方がいいんじゃないの？という話。
  • じゃあ、「見積り」をする目的ってなんなの？ということになりますが、それはなんなのでしょうね？これもコンテキストに依存するのでしょうが、まるっと丸めて言えば「意思決定に使える材料を提供する」ということでしょうか。つまりは、どんな（なんの）意思決定をするかによって、必要とされるものもその精度も違ってくるということ。
  • 少なくとも、「見積りが必要だから見積りをする」ではなくて、ちゃんとその目的を明確にするのがまず第一歩でしょう。そういうことを何も考えずにただ必要だからということで見積りを機械的にこなしてしまっている現場って多くないですかね？