プログラマ 福重 伸太朗 〜基本へ帰ろう〜 このページをアンテナに追加 RSSフィード

2010-08-29

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

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


本当のアジャイル

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


環境を変えて語り合う

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

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

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

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

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


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

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

  • なぜ行うのか
    • 成果物をだそうとしているが、計画通りにでないときがある。なぜなのかを振り返る。
    • 短いイテレーションの繰り返しで、いろいろな機能を思いつくのは良いが「本当の目的」を忘れている場合がある。それを思い出す。
  • いつ行うか
    • 開発している中で「ふりかえり」が必要と感じたとき
    • イテレーションスプリントが終わりリリースしたとき
    • プロジェクトごとによって異なる
  • だれとやるか
    • 基本的にお客様と開発チームを混ぜて行う
    • 開発チームの問題では、開発チームのみで行う場合がある
  • 議題はどのように出すのか
    • 開発中にメモしたことを議題にする
    • その場で思いついたことを議題にする

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

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

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


写真集

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

f:id:japanrock_pg:20100830021555j:image

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

f:id:japanrock_pg:20100830021554j:image

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

f:id:japanrock_pg:20100830021553j:image

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

f:id:japanrock_pg:20100830021552j:image

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

f:id:japanrock_pg:20100830021551j:image

書道2です。楽しい内容ばかりですねw

f:id:japanrock_pg:20100830021550j:image

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

f:id:japanrock_pg:20100830021549j:image

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

f:id:japanrock_pg:20100830032005j:image

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


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

norisuke3norisuke3 2010/08/31 19:43 参考になるお話、大変興味深く拝見しました。
一つ疑問に思ったのが、短期の見積の連続でプロジェクトを進めていくということは、プロジェクト全体の終了日程が決まらないままプロジェクトを始めるという事と解釈しましたが、工期 = 開発費 と仮定して、お客さんは予算のうちで開発を発注するので、開発費(= 工期)の見積が立たないと発注できないのではないかと思いましたが、如何でしょうか?

japanrock_pgjapanrock_pg 2010/09/01 02:46 id:norisuke3さん、コメント有難う御座います。

私の答えは「正確に長期見積もりを出さないと契約できないお客様とは契約しない」となります。

甘いと言われるかもしれません。

しかし、今の私が提供出来る最大の成果の出し方はブログに書いてあることだと信じています。

それを信じてやるのみです。

norisuke3norisuke3 2010/09/01 03:17 確かに、そういうお客さんがいればやり易いですね。
あと、スタートアップなどでの独自プロジェクトであれば、まさにアジャイルで行くのが最適な方法のように思われますね。

私のコメントは、単純な批判なのではなく、私もアジャイルで行きたいんだけど、最終的な開発費の見積りはどうするんだろう。というようなニュアンスでコメントしました。

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証