アジャイルリーダーシップトレーニングを受けてきました

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

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

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

一番ぐっときたこと

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

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

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

全体として

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

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

leadershipのScienceについて

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

ぐっと来たのは、

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

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

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

自分自身をリードする

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

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

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

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

10 tips for leading your agile team

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

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

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

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

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

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

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

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

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

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

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

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

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

Turnipを使ってtappのテストを書いた話

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を眺めて雰囲気を楽しみました。)