RubyKaigi2010で「本当のアジャイル」を学んã

Rubykaigi2010参加して本当に良かった。運営の皆様、スポンサーの皆様、参加してくださった皆様、Rubyを普段から支えてくださっている皆様。本当に有難う御座います。私もRubyに大変お世話になっていますので、少しでも私に出来ることはないかと思い、個人スポンサーとなって参加させて頂きました。そしてこのブログを残します。

本当のアジャイル

私がRubyKaigi2010に参加して一番痛感したことは、「今までの私はアジャイルをやっていなかったこと。むしろウォーターフォールに近いことをやっていた」と思い知らされたことです。

ウォーターフォールを御存知ですか？半年や１年の開発見積りを行い、それに従って開発を進めるが、見積りが合わなくなり（大抵は見積が足りない）、しかし見積は変えず、デスマーチと呼ばれる慢性的な長時間残業を行うようになり、自分への投資（技術の学習等）を行う時間を犠牲にする開発体制です。自分への投資がない（もしくは少ない）ものだから、技術力は一向に上がらない。いつまでたっても生産性は上がらないチームになり、成果も少ないままのチームになってしまいます。創造性を失い、ただただ「言われたタスクだけ」を毎日深夜までこなす。このような開発体制です。

そう。リーダー失格ですね。今、私のチームは上記に近い状態になっています。おそらくこのまま続ければ、どんどん悪化していくでしょう。食い止めないといけません。私のチームは「アジャイル」で開発を行っていると歌っています。しかし現実は「ウォーターフォール」になってしまっています。

なぜこのような現象が起こるのでしょう。答えは「RubyKaigi2010」にありました。永和システムマネジメントさんのセッション、COOKPADさんのセッション、Chad Fowlerさんのセッション・・・すべて詰まっていました。私は反省しました。変えなければいけません。そして、今から改革しようと決めました。

さて、どのように変えていけばよいのでしょう。答えは「お客様に”価値のある”成果を定期的に提供する」ということです。え？当たり前？そうですよね。でも、これが出来ていないのが今の開発体制です。毎日１０時間以上机の前にいるのに、成果が少ないのです。

まず、やめようと思ったことがあります。それは「長期的な見積りをやめること」です。

過去何ヶ月振り返っても、１ヶ月以上もの見積が当たったことは１度もありません。断言できます。それを「約束」していたのです。出来ないものを約束してしまうのは良くないことです。そして「まだできません」「まだできません」とお客様に繰り返し話します。これではお客様もうんざりです。ですから、「約束」はやめることにしました。

しかし、これでお客様（私たちの場合は社内にいますが）は納得するでしょうか。しないでしょう。私もそれだけではしません。

では、どうするか。Daily Hit を採用します。１日１つ「成果」を出していくのです。何を「成果」とするかは金曜日に決めようと思っています。例えば、午前中に月〜木の成果を「ふりかえり」ます（「ふりかえり」については別途記述します）。そして、お客様と開発チームで来週の月〜木の「成果」を決めます。お客様と開発チームが納得の行く成果ですのでOKです。月〜木ですので１人４つです。金曜日はふりかえりと来週の成果を決める、コードレビュー・リファクタリングを行ないます。飛び込みタスクがあるって？それも見積もるときの想像してください。あまりに飛び込みが多いようであれば、問題があります。本当にそれは飛び込みですか？今すぐやらないといけないのですか？ほかの日にまとめることはできないのですか？本当にその人がやらないといけないのですか？「ふりかえり」で工夫して、徐々に見積もれる状態に持って行きましょう。

Daily Hit というのは、「１日１つ"納得する成果”を出す」ということです。”納得”がポイントです。だれが納得すればよいのでしょう。もちろんお客様です。しかし、「テストを書く」という成果はお客様にとって納得できるものでしょうか？そうではないですね。しかし、重要なプロセスです。なので、チームリーダーの”納得”もOKにします。しかし１週間に１つ以上は”お客様が納得”する成果を出します。Viewを見せるでも、Viewに計算した数字を出すなど、目に見える成果を出していくのです。お客様に「見せる化」するのです。そうすることで、お客様に「安心感」と「進んでる感」を感じてもらいます。これは非常に重要です。Daily Hitの考え方は、Chad Fowlerさんから頂きました。書籍「情熱プログラマー」にも書いてあります。

”納得する成果”というのは、メンバーの技術力、アプリケーションについてどの程度精通しているかなどによりますので、基本的には１日８時間程度で終わるようなものがよいでしょう。８時間集中するのです。残業が当たり前になると、パーキンソンの法則が間違いなく働きます。８時間で終えるんだと自分で追い込むことが重要なのです。そして、家に帰りましょう。技術力を磨きましょう。生産性をどんどん高めましょう。家庭を大事にしましょう。技術者と交流しましょう。語り合い、本を読み、どんどん自分を成長させましょう。OSSに恩返ししましょう。Chad Fowlerも言っています。

１日で出せる成果を見積もるのは１ヶ月で出来る成果を見積もるより、はるかに楽です。見積もりの精度が自然と高くなり、お客様の”納得する成果”が出せるようになります。そう信じています。

１つの「ストーリー（お客様視点の要望）」を設定して、それに向かって開発します。ストーリーの単位は小さくします。１週間以上かかってしまうストーリーは分割を検討します。長い期間は見積が崩壊します。１日〜１週間が理想です。ストーリーを達成するためには、テスト、ロジック、Viewなどの開発工程があります。その工程は特にチケットを発行するようなことはしません。ホワイトボードに付箋を張る程度で良いと思います。ようするに永和さんが採用している”かんばん”を採用します。「ストーリー」は”お客様視点”でかかれたチケットと思っていただければ良いと思います。ストーリーに関してはこちらを御覧ください。

また、ペアプログラミングを推奨しようと思っています。以前、開発チームでもペアプログラミングをやっていたのですが、途中でやめてしまいました。しかし、今もたまーにやります。そして成果がでます。どういうときに成果がでるのでしょう。それは、「突発的ペアプログラミング」でした。以前は「計画的ペアプログラミング」でした。例えば、「火曜日の14時〜16時はペアプロ」などといった具体です。「計画的ペアプログラミング」の何がよくないかというと、「用意してしまう」ということです。「明日ペアプロだから、スムーズに進むように進行を考えよう」など考えてしまうのです。そうではなくて、「ここわかないのだけど、わかる？」「あぁ、たぶんこうじゃない？」「おお、そうだ。さすが！こやってこうだね。できた！」「こっちもこうやったほうがいいんじゃない？」「そうだね、こうやろう。いいね。」「ちょっとViewやってよ。コントローラにこのインスタンス変数を取得するコード書くから」「OK〜」・・まぁ、こんな感じが理想かなと想像しています。例のようにうまく行けば素晴らしいですね。あとは、「私はテスト書くから、実装お願い」「OK、あ、このパターンはテストしないとだね」「うんそうだね」といった具体に、他人の意見も入るので、バグも減るのではないかと期待しています。一日中やってると疲れそうなので、数十分〜数時間がいいなと思っています。

あと、"お客様ともっと積極的に交流しよう"と思いました。私の場合"お客様"は社内のメンバーです。要するに同じ会社の人です。営業さんだったり運用する人だったりします。その人達とお昼を食べに行ったり、夜飲みに行ったりします。同じ会社の人であれば簡単ですね。そこで「本当に欲しい機能」は何か？を引き出すのです。今は、開発側チームと営業側チームの架け橋をしてくださっている人が１名います。その方はプログラマではありませんので、システムについては分からない部分も多々あると思っています。営業側については非常に詳しく、営業よりの方です。私たち開発チームが寄り添って行き、システムの知識も踏まえた「本当に欲しくて、今すぐ取り掛かれる機能」を判断していく材料にするのです。"お客様の声を聞く"ことも非常に重要なことです。

環境を変えて語り合う

RubyKaigiは同じ会社のメンバー2人と行きました。みんなRubyプログラマです。私を合わせて3人です。RubyKaigiが終わった後、ホテルにお酒を買い込んで、語り合いました。上記に書いてある、アジャイルについてもそうです。意見は一致していました。永和システムマネジメントさんのストーリー開発に感動しました。昼休みに”皆の喜ぶ便利ツール”を作る文化にも感動しました。COOKPADさんの 200ms/request にも感動しました。RubyKaigiで得た知識、経験を元に、今の私達に足りないものを語り合いました。とっても充実していて、とっても成果が高く、そしてとっても楽しいのです。そして、「こんなの作ったら皆喜ぶよ！」って言ってその場でMacBookを取り出して開発してしまいます。そして１つできました。なんという生産性でしょう。このアプリケーションは月曜日から可動するのです。今回の”お客様”は”開発メンバーが喜ぶもの”そう”お客様”=="私たち"だったのでこれは”納得の成果”なのです。しかし、仕事では”お客様”は私たち以外でないといけないですね。

COOKPADさんは言っていました。「今のオフィスに行く前は、開発合宿とか頻繁にやっていました。しかし、今の環境の良いオフィスに来てからは合宿はやってない」

なぜでしょうか。開発するのに非常に優れた環境だからです。成果が出るからです。GoogleやCOOKPAD、はてなやLive Door・・・成果を出している環境をみていると私たちとは異なります。ただ、環境のせいばかりにしていては駄目ですし、環境というのは物や服だけではありません。人間関係や成果を出す開発システム、多くの無駄があるでしょう。そういったものを取り除いてから考えても全然遅くないのです。むしろ考える必要がなくなるかもしれません。

１つ来週から実践してみようと思うことがあります。まずは永和システムマネジメントさんが実践している「昼休みの開発」。お昼を食べながら、便利なツールや機能をわいわい作っていくのです。これには技術的な挑戦も含まれます。新しいRailsを使ってみたいけど、業務ではコストが高いから、昼休みに作るアプリケーションで使ってみようなどです。語り合う中で、「これがあったら便利」「これがあったら皆喜びそう」といったアイデアがたくさんでました。それを１つ１つやっていくことにしました。

あと、あまりに今回のRubykaigの後の語り合いがよかったものですから「また合宿やりたいね」という話がでました。数カ月にいっぺんなどのルーチンになるかもしれません。

「ふりかえり」とアジャイルの弱点

永和システムマネジメントさんのセッションは「永和さんが実際どのような流れで開発しているのか」を教えてくださいました。しかし、時間の関係上「ふりかえり」については飛ばされました。気になった私は、セッションの後、永和システムマネジメントさんの ursm さんに声をかけて質問させて頂きました。

• なぜ行うのか
  • 成果物をだそうとしているが、計画通りにでないときがある。なぜなのかを振り返る。
  • 短いイテレーションの繰り返しで、いろいろな機能を思いつくのは良いが「本当の目的」を忘れている場合がある。それを思い出す。

• いつ行うか
  • 開発している中で「ふりかえり」が必要と感じたとき
  • イテレーションやスプリントが終わりリリースしたとき
  • プロジェクトごとによって異なる

• だれとやるか
  • 基本的にお客様と開発チームを混ぜて行う
  • 開発チームの問題では、開発チームのみで行う場合がある

• どのように行うのか
  • ホワイトボードを使う。成果物をみながらとかはやっていない。
  • とくにフレームワークはないが、KPTなどを使うときもある。

• 議題はどのように出すのか
  • 開発中にメモしたことを議題にする
  • その場で思いついたことを議題にする

• ログはとるか？
  • 基本的にとらない。ホワイトボードの写真を取る程度

上記、間違っていたらごめんなさい。訂正しますので、ツッコミお願いしますm(_ _)m

もう一つ、興味深いお話を聞かせてくださいました。「アジャイルの欠点について」です。イテレーションを短くしていると成果を見せているときなどにお客様から「あれもほしい、これもほしい」と言ってきます。それはいいのだけど、「ほんとうに必要なもの」を見失いがちになります。「本当にやりたいこと」の確認が重要です。それを「ふりかえり」で行うことが多い。アジャイルは短くなって成果も見えるけど、短ければ良いものでもないということです。

この視点は非常に重要だと思いました。本当に有難う御座います。

写真集

iPhoneでRubyKaigi2010の様子を少しですが写真を撮りました。

大ホールです。感動的なkeynoteばかりでした。

私の名札です。個人スポンサーです。

好きなメソッドは？好きな言語は？私は好きなメソッドを each と書きました。好きな言語の方は書きませんでしたが、見てみるとさまざまな言語が書かれていました。

書道です。何を書いてもよいのです。

書道２です。楽しい内容ばかりですねｗ

喫茶自由です。ここで喉を潤しました。RubyKaigiのオアシスです。

私もですが、Macを持っている方が非常に多かったです。他の言語のカンファレンスでもそうなのですかね？？

松江ラーメン買いました。まだ食べていません。きっと美味しいですよね。

RubyKaigi2010参加して本当に良かった。運営の皆様、スポンサーの皆様、参加してくださった皆様、Rubyを普段から支えてくださっている皆様。本当に有難う御座います。このブログが少しでもRubyの為になればと願っています