アジャイルサムライの著者による、本に書いていないアジャイルリーダーシップのトレーニングがあるということで、会社の教育として受けさせてもらいました。

最初に、ジョナサンにとってのトレーニングのインセプションデッキとして、受講者にこのトレーニングで知りたいこと言ってもらい、それをリストアップしていました。

折角なので、実際に困っている「1〜3人の小規模チームでのリーダーシップについて知りたい」という事をお願いしてみたのですが、それについてのディスカッションは後述。

一番ぐっときたこと

発表資料を見直してみても載ってなかったのですが、

大切なのは、継続的に価値を届けること、そしてそれでハッピーになることだ

ということを言っていたような気がするんですよね。そう、みんながハッピーにならなきゃいけないんだよ！

全体として

すばらしいトレーニングでした。 なによりも、要所要所でジョナサンが話す彼が経験してきたプロジェクトの話は興味深く、とても刺激的なものでした。 最後のディスカッションでも、受講者の現場の問題に役立ちそうな彼のエピソードを話してくれて、すごく視野が広がった感覚があります。

また、翻訳、通訳をしていただいた和智さん、本当にありがとうございました。後半はもう頭が働かなくて翻訳に頼りっぱなしでした…(英語勉強します…)

leadershipのScienceについて

初めに、ジョナサンがトレーニングのアジェンダを紹介したのですが、最初が「leadershipのscienceについてだ」というのを聞いてこれはやばいと思いましたね。

ぐっと来たのは、

• 人は自分のやり方で仕事がしたい
• 報酬は、ある閾値を超えると効果がなくなる(むしろ悪影響がある)
• 目標、評価は多角的に、チートできないように設計する

上の2つはダニエルピンクの「モチベーション3.0」の研究成果からの紹介だったのですが、最後の目標と報酬の話は非常に面白かったです。

たとえば、販売部門とシステム部門の部長の評価は、評価の一部に「相手の業績を上げるようなことができたか」という項目を入れることで、足の引っ張り合いもなくなるし、自然と仲良くなるというような話でした。

自分自身をリードする

(アジャイルな)リーダーとは、3つ事をリードしなければならなくて

• チーム
• 自分自身
• 上司(組織)

というような話だったと思います。

そのなかでも、自分自身をリードするために、ドラッカー風エクササイズを実際にやってみるという内容でした。

10 tips for leading your agile team

これはほとんどアジャイルサムライの内容でしたね。 ぐっと来たところだと

• 「悪いニュース」は伝えるのではなく、誰の目からみても明らかになるようにする(見える化の話)
• 目標を高く設定し、それをキープする
• コントロールなんて諦める。ただ、崖から飛びおりようとしていたら止める

小規模チームの話

実際今も1〜3人くらいの小規模チームで仕事をしているのですが、私が感じていた問題は

• 次イテレーションの準備が十分にできない
• 一人が休むとプロジェクトが止まってしまう(これはちゃんと伝えられなかったけど、アドバイスは非常に参考になった)

というものでした。ジョナサンから貰ったアドバイスは次のようなものでした。

まず、小規模チームというのは素晴らしい。2人なんて最高だ。 顧客とも直接話ができるんだろう？ なら、次イテレーションの準備なんて言わずに、そのイテレーションの最初、もしくは途中でも、そのイテレーションでやることを決められるんじゃないか？

思わず「あぁ…」と声を漏らしそうになるくらい、今自分が出来ていないことがわかってしまう、とても的確なアドバイスでした。もっと精進します。

ディスカッションの他のテーマ

1時間くらいは受講者の知りたいことについてディスカッションする時間があったので、これの為に来たと思ってもお釣りがくるくらいいい内容でした。

メモ程度ですが気になったことを書いておきます。

• 組織にアジャイルを普及されるために、今アジャイルで上手くいっているチームをバラしてもいいのか
• トレードオフスライダーは「scopeを変えますよ」という宣言のために作るんだ
• 全てがfixされているプロジェクトでは、お金を出している人を探すところから
• チームが自発的にタスクを取ってくれない？リーダーが2週間いなくなればいいよ

おわりに

アジャイルサムライ大好きなのに、ジョナサンの話を聞いたのはこのトレーニングだけだし、記念写真とりわすれるし…

ただ、またいつか会える日がきて、そのときはジョナサンに私のサムライ戦記を伝えられるように、これからもがんばろうと思ったのでした。

前回から3ヶ月経ってたらしいですね。(散髪ログ便利)

家から徒歩3分の美容院がPM11時まで受けつけなのでいつもお世話になっていたんですが、来月からPM8時が最終になるらしくて困り気味。

聞くところによると、深夜に入れる若者がどんどん辞めていってしまっているらしく、どこの業界でも若者は3年でやめるのかーと思ったのでした。

バレンタインデーが1日遅れてた都合上、ホワイトデーが1週間遅れてやってきた。

ちょっと前から「LeTAOのドゥーブルフロマージュ食べたい」と言われていたのでお取り寄せしたのでした。

あとは、IIDX Lincleのサントラが到着。

3/31にあるGEEK DAY TOKYOというイベントで「ソーシャルコーディング時代の幕開け」というタイトルでお話させていただくことになりました。

タイトルからもわかる通りGitHubの話なんですが、**「受託開発の会社がお仕事のリポジトリとしてGitHubを採用してみたら何が起きたか」**という話をしようと思っています。

他の発表者の方を見ると、普段あまり接点がない感じなので、楽しみでもあり不安でもあるという複雑な感じです。

なにやら、Asakusa.rbの花見が同じ日にあるようですが、興味のある方は来てみてください。(ドリンク(アルコール有)、軽食無料だそうです！)(LTと展示も募集中だそうです！)

octopressのデフォルト設定では、記事のURLは/YYYY/MM/DD/#{title}/のようになるんですが、某ブックマークサービスでは末尾のスラッシュを名寄せしてくれなかったり、ブラウザによって末尾のスラッシュ無しの場合にリダイレクトされたURLがアレな感じになったりするので、.htmlで終わるように設定を変更しました。

これによって、過去の記事のURLも全て変更されていますので、ブックマークから見れなくなっていると思います。すみません。

ここ数日揉めていた件に対応しました。

行動情報を取得しないはてなブックマークボタン作成ページ

普通に作るボタンは「行動情報を収集する」パターンで、下に灰色の文字でオプトアウト版の作成ページへのリンクを作るというのは、なんというかそこまでいってしまったんだなぁという感が否めないですね。

WEB+DB PRESSのRubyわくわくナビでも紹介されたtappのテストについては社内でも定期的に上がる話題で、もう少し広い意味で考えると、標準出力を扱うアプリのテストをどうするかという話になったりするのですが、

• tappの単体テストってなんかしっくりこないよね
• 標準出力に出すだけだしね
• そういえば、vim-ruby-refactoringっていうVimプラグインのテストがCucumberで書いてあるんですよ
• そういえば、jnicklas先生の新作Turnipっていうのがあって…
• それ使ってみましょう

という感じでTurnipを使ってAcceptance Testを書いてみました。

Turnipの特徴はこんな感じです。

• 記法はCucumberと同じGherkin
• Stepの定義に正規表現を使わずに、ただの文字列と、その中にコロン(:)をプレフィックスとしたプレースホルダで変数を扱う
• Stepに名前空間ある
• Stepの名前空間に変数が持てる

日本語で書けるかどうかは試してないですが、なかなかよさそうじゃありませんか？

Turnipで書いたtappのテストを下に載せておきます。 ただ、名前空間とかは使ってないので、Cucumberとは殆ど変わりませんね。

Feature: Object#tapp

  Scenario: Call tapp within methods chain
    Given I have the following code:
    """
    require 'tapp'

    (1..5).tapp.select(&:odd?).tapp.inject(&:+)
    """

    When Ruby it

    Then I should see:
    """
    1..5
    [1, 3, 5]
    """

Step定義も合わせてどうぞ。 こっちは、よくある標準出力をテストする方法を使っています。

step "I have the following code:" do |code|
  @code = code
end

step "Ruby it" do
  stdout = StringIO.new
  $stdout = stdout
  begin
    eval @code
  ensure
    $stdout = STDOUT
  end
  @output = stdout.string.chop
end

step "I should see:" do |output|
  @output.should == output
end

結構読みやすいと思うんですがどうでしょう。標準入出力を扱う簡単なツールは、こんな感じで単体テストよりもエンドツーエンドのテストを書いておいた方が価値があると思います。

(これは3/1に書きました)

去年はなんとなく参加しなかったデブサミですが、今年は少しだけ参加しました。

• 1日目: 平鍋さん
• 2日目: 角谷さん、松田さん

私にとって、デブサミと平鍋さんの組み合わせは特別なものなので、今年はどうしても行きたかったのです。

あれは2005年、学生として潜り込んだデブサミで平鍋さんの見える化の話を聞いたのが、私と永和の出会いだったのです。 その7年後の2012年に、平鍋さんから聞くアジャイルの10年という話は、あの頃の衝撃を思いださせてくれる、平鍋さんにしかできない話で感動しました。

角谷さんの話は、だいたい会社で話してることや、耳に入ってくる話が中心ではあるんですが「自然なソフトウェアの作り方」と「オープンソースソフトウェア」という話は、なるほどなーと思いました。オープンソースソフトウェアはすごい。

最後の松田さんは、もうあれは聞かなかった人は、スライドだけでも見るべきですね。必修科目です。GitHubとはなんなのか、何故GitHubなのか、彼等は何をなしとげたのか、すごく綺麗にまとまっていました。 これを聞いてから、GitHubの事を他の人に話そうとしても、松田さんの言ってたことをそのまま言うしかなくなってしまって少し困っています。

1年振りに参加したデブサミはとても満足できたのですが、一方で技術的なセッションがソーシャル系というかビッグデータ系ばかりなのは、ちょっと寂しいというか、もう少し何か話題がないのかな〜と思いました。

(本当は、1日目の和智さんも聞きにいく予定だったのですが仕事で間に合わず。後日Twitterを眺めて雰囲気を楽しみました。)

生クリームを買ってこいとの指令があったので買って帰ったら作ってくれました。 ありがとう！おいしゅうございました。

新ナイズルのみで、しかもその仕組みもドロップもごにょごにょらしいのでちょっと様子見。 30分しばりのせいで野良でも行きにくいし、身内でたまに行くしかやりようがないですな。

とはいえ、VWも

• コルスカンティ
• トキ
• ルベウス頭、アトス頭(コンプしたいけど別にどうでもいい)

くらいしか欲しいのがないし困ったなぁ。