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

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

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

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

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

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

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

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

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

Let's refactor your health.

ブログ再開に向けてのふりかえり

３ヶ月ほどこのブログの更新が止まっていましたが、そろそろまた再開しようと思います。いくつか書きたいネタはあるのですが、まずはマーケットを知る（？）ということで、このブログへのアクセス状況をふりかえってみたいと思います。

2つの"Always All Ways"

このブログには、新旧２つが存在します。
2012年2月までぷららのブログ（Broach）を使って書いていたのが、

• Always All Ways

そして、その後Hatena Blogに引っ越して書いているのがこちら：

• Always All Ways

それぞれでちょっとアクセス状況を見てみましょう。

どういう検索キーワードでこのブログにたどり着いているか

まず、どんな検索キーワードでこのブログに来ているか見てみましょう。

Broach

今週一週間（4/15-21）で見てみると、検索文字列別集計で見ると

1. ボルダリング 動画
2. 徒弟制度　IT

検索語別集計でも

1. ボルダリング
2. 動画
3. IT
4. 徒弟制度

という結果になっています。いったい何のブログなんでしょうね（笑）
つまりは、こいつら（↓）ですね。

• Always All Ways: [Bouldering] 初心者向けボルダリング動画まとめ
• Always All Ways: [IT] 『アプレンティスシップ・パターン――徒弟制度に学ぶ熟練技術者の技と心得』

はてなブログ

こちらは、Yahoo検索とGoogle検索に分けて見てみましょう。Yahoo検索では、

1. リーンソフトウェア開発
2. リーン開発
3. 自己組織化 ビジネス
4. agile subwaymap

Google検索でも似たようなもので

1. リーンソフトウェア開発
2. リーン開発
3. scrum エンタープライズ
4. always all ways 意味
5. Management 3.0

です。

アクセス先ページ

次に、はてなブログの方だけですが、検索からどのページにアクセスされたかを見てみます。
Yahoo検索からのアクセス先ページだと、

1. リーンソフトウェア開発がいまだによくわからない - Always All Ways
2. 書籍「民俗のふるさと」（宮本常一） - Always All Ways
3. 仕事帰りにドラムサークルすると何が起きる？ - Always All Ways
4. Lulu.comで「世界を変える方法」を買ってみた - Always All Ways
5. But...Self-Organization Is Not Enough: 自己組織化チームに関する誤解とマネージャの役割 - Always All Ways

Google検索からのアクセス先ページでは、

1. リーンソフトウェア開発がいまだによくわからない - Always All Ways
2. Lulu.comで「世界を変える方法」を買ってみた - Always All Ways
3. エンタープライズでのScrum導入を支える仕組み - Always All Ways
4. プロジェクト向きのアジャイル開発手法：DSDM - Always All Ways
5. アジャイルなマネジメントについて考える必要性（書籍 "MANAGEMENT 3.0"） - Always All Ways

ふむふむ。そういうことですね。

まとめ

初心者向けのボルダリング動画という意味では、その後も大量に公開されていたりするのですが、基礎の基礎という意味では、F-STYLEさんのところのがいいかもしれませんね。

• フリークライミング総合情報サイトF-STYLE - YouTube

いや、そうではなくて…。とにかく、また何か書きます。

アジア諸国でのアジャイル開発普及と人材教育

ひきつづき、Agile Tour Osaka 2012 in Minohの告知ブログです。前回のエントリの時点では、まだ長瀬さんの講演タイトルと概要が公式に発表されていませんでしたが、数日前にようやく公表されました。

アジア諸国でのアジャイル開発普及と人材教育

これが、長瀬さんの講演タイトルです。そして概要は、こんな感じ↓

欧米諸国では、アジャイル開発はメインストリームとして当たり前になりましたが、日本での普及は１０％にもなりません。日本では、従来型にしがみつきアジャイル開発の普及が進みません。その裏では、日本のソフトウェア開発は、日本からアジアの新興国へシフトしだしています。
それでは、アジア諸国でのアジャイル開発の普及はどうなっているのでしょうか。とりわけ、中国、ベトナム、タイのアジャイル開発事情と人材教育の現場の話をいたします。

これを聴いて何を感じるか、何を考えるか

それはまさに参加者次第です。
オーガナイザーとして、長瀬さんに講演を依頼する立場として期待しているのは、これが単にアジア諸国のお話として捉えるのではなく、参加者ひとりひとりが今後の自分自身のエンジニアあるいはビジネスパーソンとしての生き方を考えるきっかけになればいいな、ということ。
その意味では、私自身が勝手にこのイベントの「裏テーマ」と考えている「会社に頼らない働き方、日本に縛られない生き方」を考える上での直接的ではないかもしれないけれどもさまざまなヒントを与えてくれるセッションになるのではないかと思っています。

申し込みはこちらからお早めに

• 11月3日 AgileTourOsaka2012 in Minoh　箕面の滝からこんにちは(大阪府)

XP祭り2012で感じたこと、考えたこと

9月15日に開催されたXP祭り2012に参加してきました。
今年は縁あって、「アジャイルコーチラウンドテーブル」というセッションにも（アジャイルコーチじゃないけど）登壇させていただきました。現在の立場的なものもあり、直接回答できるような内容があまりなかったですが、みなさんの悩みや現場での取り組みをいろいろ聴くことができました。

チームを育てるという視点は大事

ラウンドテーブルでの質問の中でも「アジャイルって、優秀なスーパープログラマーを集めないと無理なのか？」というようなお題があり、そこでの回答でも「アジャイル開発に取り組む中でメンバーのレベルを引き上げていく」という話がありました。それはまさにその通りだと思います。
優秀なメンバーがいるからアジャイル開発ができる、ではなくて、アジャイル開発に取り組む中で優秀なメンバーが育ち、すばらしいチームができるということだと思います。逆に言えば、このメンバー育成の視点やチームの成長の視点を持たなければアジャイルではないと言ってもいいくらいかと思います。
今は、直接アジャイル開発チームとは関わっていませんが、それでも、アジャイルの「育てる」という考え方はいつも忘れないようにしていることの一つです。
（参考） Always All Ways: [IT] 継続的改善フレームワークとしてのScrum

組織の壁は人の壁

もう一つは、アジャイル開発の導入・展開における「壁」の話。
この話は、いつも出てきますね。確かに、大きな組織になればなるほど「組織」という壁にぶつかったり、なんとも説明しがたいが抗うこともできない「空気」に流されることはよくあります。しかし、私自身はその実態の掴めない「組織」や「空気」と戦うのはあまり賢明ではないかな、と思っています。そうではなく、それを人との壁であったり、自分自身が勝手に作っている（思い込んでいる）壁として捉えて対処していきたいな、と。
そんなことを考えていたら、2年ちょっと前に書いたブログを思い出しました。

• Always All Ways: [IT] つぶやきの極私的補足（要求開発アライアンス５月定例会）

これは、要求開発アライアンスの定例会のUstream中継を観ながらつぶやいた内容について補足する形で自分の考えを綴ったものです。XPだろうがアジャイルだろうが要求開発だろうが、組織の中で何かやろうとした時の話には共通点があるなー、と改めて思いながら読み返した次第。

選択理論心理学もかじっておくといいよ

上で挙げたブログの最後にも書いていますが、組織の中での人との問題に対処するには、ウィリアム・グラッサー博士の「選択理論心理学」も少しかじっておくといいかもしれません。（少なくとも私はこれに少なからず影響を受けています。何年か前にDevLove関西の初回でこの話もした記憶がありますが、残念ながらスライドは公開していません。）
あとは、"How to Change the World"ですね。
これは、ナイスビアの人が今回のXP祭り2012のLTで紹介してくださっていますので、以下のスライドをご参照ください。

チェンジ・エージェントになる方法 @ XP祭り2012 from Miho Nagase

グラッサー博士の選択理論―幸せな人間関係を築くために

「How to Change the World〜チェンジ・マネジメント3.0〜」が出ました！

３月末頃からユルユルと翻訳作業を進めてきた"How to Change the World"(Jurgen Appelo著)の日本語版を、昨日（7/13）無事に出版することができました。

本書は電子書籍版（PDF/EPUB）のみで、達人出版会さんのサイトから購入できます。

• How to Change the World 〜チェンジ・マネジメント3.0〜 - 達人出版会

この本との出会い

過去の関連記事は、こちら

• Always All Ways: [IT] Change Management 3.0
• Lulu.comで「世界を変える方法」を買ってみた - Always All Ways

著者のJurgenは、このブログでも再三取り上げている書籍「Management 3.0」を書いた人で、私が最も影響を受けた人物500人のうちの一人です。ご興味があれば是非、ダウンロードして目を通してみてください。

AgileとChange

アジャイル開発の現場においては、変化を抱擁し変化に適応していくことが求められます。そして、アジャイル開発の導入・適用においては、組織レベルでの変化やトランスフォーメーションが欠かせません。
そこでは、チェンジ・エージェントとして適切に振る舞える人が必要であり、優秀なチェンジ・エージェントになるために必要なことが80ページ足らずのコンパクトな小冊子にまとめられたのが"How to Change the World"です。

Fearless ChangeとHow to Change the World

Changeやチェンジ・エージェントというキーワードから、Linda Risingの"Fearless Change"を思い出された方もいらっしゃるかもしれません。そんな方は是非、無料でダウンロード可能な

• "Questions for Change Management 3.0"(pdf)

を併せてお読みになることをおすすめします。
その中にはチェンジ・エージェントが考えるべき問いが、"Fearless Change"のパターンとのリファレンス付きでリストアップされています。

謝辞

今回の翻訳に際しては、原著がそもそもJurgenの自費出版のような形だったこともあり、翻訳の許諾を得るために著者本人に直接コンタクトを取るところから始まりました。日本語版の出版を快諾してくれたJurgenをはじめ、共訳者の川口さん・吉羽さん、レビューをしてくださった原田さん・ナイスビアの永瀬さん・高江洲さん、契約面でお手伝いいただいたアギレルゴコンサルティングの谷口さん、達人出版会の髙橋さん、その他本書の出版に関わってくださったすべての人々に感謝です。

"How"の質問に答えてはいけない

先週は、リーンソフトウェア開発のポッペンディーク夫妻（メアリーとトム）が来日していました。幸運なことに私も、

• 月曜日はリーダーシップ・ワークショップの一日目に出て〜とんかつ食べに行って〜
• 火曜日はリーダーシップ・ワークショップの二日目に出て〜しゃぶしゃぶ食べに行って〜
• 水曜日はSECセミナーでの午前中の講演を聴いて〜
• 金曜日は夫妻を囲む会でミニレクチャー聴いて懇親会で飲んで〜

という形でいろいろと直接お話をする機会を得ることができました。

本当は、「メアリーから学んだ５つのこと」みたいなタイトルでまとめてみたかったのですが、なかなかうまくまとまりそうにないので、以前のエントリとも絡めて一つだけ書いておきたいと思います。

Don't answer questions

これは、以前のエントリ（Scrumを教えるのに最適なフレームワークはScrum - Always All Ways）で紹介したTobiasのブログに出てくる５つの「やってはいけない」の４番目の項目です。
今からふりかえってみれば、メアリーのワークショップではまさにこの５箇条がしっかり守られていたように感じます。そしてその中でも、この４番目の「質問には答えてはいけない」というのは非常に強く意識されているように思いました。（意識されているというよりは、むしろ身体に染み付いて無意識の習慣になっているのかもしれません。）

Especially don't answer "How" questions

もちろん、彼女は質問も受け付けずに突き放していたというわけではないですよ。誤解を避けるために、Tobiasのブログから該当部分を抜粋しておきたいと思います。

Especially don't answer "How" questions [ref]. These are usually asked as challenges, and attempting to answer them will likely lead to positioning and entrenchment. Instead of offering answers, whether from intuition or experience, seek instead a better question—there is almost always one or more of those lurking below the surface. A classic example is the "How do we manage bugs in Scrum?" question. This is not a useful question, a better one being "Why do we have bugs?" [ref].
Top 5 Scrum Workshop Dont's

ここでのポイントは、

• 特に"How"を問う質問には答えるな。
• 代わりに、よりよい質問を探しなさい。

ということですね。
古典的な例として挙がっているのは、「Scrumではバグをどう管理するのか？」という問いに答えるのではなく「なぜバグが発生するのか？」と問いかけなさい、というやつです。

信念と自信に裏付けられた質問

こういう話をすると、たまに「質問をはぐらかしている」とか「問題をすりかえている」と思う人もいるかもしれませんが、今回のメアリーの話で少しもそういう印象にはならなかったのは、やはり彼女の言葉が信念と自信に裏付けられていて、彼女が質問を言い換えてくれることで我々自身が本当に考えて取り組むべき課題に目を向けさせてくれたからだと思います。
懇親会の席でとある参加者の質問を通訳してメアリーに投げかけたのですが、そこへのメアリーの回答を聞いたその方がtwitterで「涙が出てきた」「魂が震えた」と書かれていたのが印象的でした。

「信頼」が加速させるアジャイル

Peter Callies氏がLeadingAgileに書いていた記事が良かったので、簡単にご紹介しつついろいろ思うところをメモ書き。
Agile at the Speed of Trust – An Overview | LeadingAgile
この記事は、Stephen M.R. Coveyの"The Speed of Trust"（邦題：『スピード・オブ・トラスト―「信頼」がスピードを上げ、コストを下げ、組織の影響力を最大化する』）をベースに、アジャイルの文脈における「信頼」について論述したものです。今回はOverviewということで今後、続編が出てきそうな気配ですので楽しみです。

アジャイルと信頼/信用の話

アジャイル界隈の人は、「信頼」と聞くと、まずは「信頼貯金」とか「信用貯金」を思い浮かべるのではないでしょうか？
たとえば、角谷さんのこの記事（↓）にあるように。
アジャイル開発者の習慣－acts_as_agile：最終回　信頼貯金を増やす｜gihyo.jp … 技術評論社
そしてまた、渋川さんが翻訳された『アート・オブ・コミュニティ ―「貢献したい気持ち」を繋げて成果を導くには』の中でも、"social capital"を「信用貯金」と訳されていたかと思います。（渋川さんらしい訳ですね。）
これらは、何よりもアジャイルと信頼/信用が切っても切れない関係であることを示していると思います。

信頼の影響を示す２種類の数式

Coveyはその著書の中で、"trust"について次のように述べています。

trust is not some soft, illusive quality that you either have or you don't; rather, trust is a pragmatic, tangible, actionable asset that you can create

そしてさらに数式（っぽいもの）を使って、信頼というものが与える影響を示しています。
まず下に引用したものは見ての通り、Trustが上がったり下がったりすることがSpeedやCostにどう影響するかを示しています。

↑Trust = ↑Speed ↓Cost
↓Trust = ↓Speed ↑Cost

次に下に挙げるのは、これまでのResult（成果）は Strategy（戦略）とExecution（実行）の掛け算であるという数式にさらにTrust（信頼）との掛け算に展開したものです。つまり、Tが1より大きければSとEの掛け算以上に成果が上がるし、小さければ下がるということを示しています。

(S x E)T = R

信頼の波

続いて元記事で紹介されていたのは、Coveyが信頼の広がりを波紋のメタファーで説明しているものです。これについては図と詳細な説明が記事の中に書かれていますのでそちらを参照してください。
Self trust → Relationship trust → Organizational trust → Market trust → Social trust
この波の広がりの中で、Self trustというのがまず最初に来ています。それによって次の波が起き、最後にはSocial trustにつながっていくということです。そしてそれぞれのレベルでアジャイルなチームの振る舞いと密接に関係しています。

マネージャの立場から見た4つの信頼の形

上では5つのtrustの種類が示されていますが、Jurgen Appeloの"Management 3.0"（もう、このブログで散々紹介して食傷気味だと思いますのでリンクは省略しますね）の中でも別の切り口でマネージャの立場で考えるべき4つの信頼の種類が示されていました。（第７章 pp.138-141）

1. Trust Your Team （チームを信頼すること）
2. Earn Trust from Your People （チームメンバーからの信頼を獲得すること）
3. Help People Trust Each Other （チームメンバー同士の信頼関係構築を支援すること）
4. Trust Yourself （自分自身を信頼すること）

そして、ここでも最後のSelf trustがまず大切であると述べられています。

信頼こそがすべて

このエントリのタイトルは「信頼が加速させるアジャイル」としましたが、実は、元記事のタイトル（"Agile at the Speed of Trust"）を見て最初に思ったのは「アジャイルの導入・展開は、その組織における信頼関係構築のスピード以上には進まない」ということです。あなたの組織では、どうですか？

おまけ〜私にとっての「信頼」とは？〜

最後に、2009年の夏にブログに書いた記事のリンクを貼り付けておきたいと思います。
Always All Ways: [読書] 信頼すること
これも元は本の一節にインスパイアされただけですけれども。

追記

続編記事が出てきたら気づいた範囲でこちらに追記していきます。

• Agile at the Speed of Trust – Self Trust | LeadingAgile (2012.4.17追記）

スピード・オブ・トラスト―「信頼」がスピードを上げ、コストを下げ、組織の影響力を最大化する

アート・オブ・コミュニティ ―「貢献したい気持ち」を繋げて成果を導くには (Ｔｈｅｏｒｙ　ｉｎ　ｐｒａｃｔｉｃｅ)