デブサミ2012で発表しなかったスライドです。これはAgile Conference 2010で聞いたネタなのですが、アジャイル開発を実践する企業文化をグラフに表したもの。

自己組織化されたチームで構成されるため、管理要素が少なく、協調と教育という2つの柱が目立ちます。今日は「自己組織化されたチームとマネージャとの関係」について、Ask the speakerで質問を頂いたのでちょっと考えてみます。

自己組織化されたチームにマネージャやリーダーは必要か？

これはデブサミ発表資料のスライドです。このプロジェクトで私はプロジェクトリーダーやプロダクトオーナーに近い役割を演じました。チームが目指した自己組織化されたチームって、チーム内で全てが解決しそうですね。そういうフラットなチームに、マネージャやリーダーは必要なのでしょうか？

去年担当したプロジェクトの経験では、マネージャは必要だと思っています。上の図のようにチームにそっと接する形でマネージャはチームを支え、組織活動に必要な管理業務（勤怠管理や連絡、評価や予算管理）をマネージすることによってチームを支えてくれます。

これは、管理業務からチームを守る（もしくは効率良くサポートする）スクラムマスターに近いイメージです。リーダーと兼務することは可能ですが、正直しんどいです。会社活動における業務がヘビーな場合は、こういった形の支援があってもいい気がします。

では、リーダーはどうでしょう？リーダの仕事がチームを引っ張っていくことだとすれば、自己組織化されたチームに必要なさそうな役割です。ただ、「自己組織化されるまで」の間、チームを牽引する力があると良いのではないかと思います。その時のリーダーの仕事は「自己組織化されたチームを育成する」に近いイメージです。

チームが自己組織化されれば、自然にリーダーシップを発揮する人も生まれる・・・というのが今の理想ですね。

こう考えると、マネージャは永続的に必要だけど、リーダーはずっといる必要はない気がしてきたので、ずっとリーダーやってる場合ではなくて、自分の価値を探し続けないとなぁと思うのです。Similar Posts:

• Agile 2010 Conferenceにいってきた Day1 PM
• アジャイル開発の本質とスケールアップ読了
• 明日のデブサミ2012で「アジャイルリーダーシップと組織改革」を発表します #devsumi
• Agile India 2012 が2/17から3日間開催！#agileindia2012
• アジャイルリーダーシップと組織改革 楽天のアジャイルを発表しました #devsumi
• 第18回すくすくスクラムに行ってきました
• アジャイルな見積りと計画づくりを読んだ
• ここが日本のアジャイルなのか！Agile Japan 2010レポート
• Agile2010 – Mapping the Agile Enablement Battlefield
• Doingだけじゃアジャイルにならない？アジャイルになるための継続的デリバリとリーダーシップとは？

Lakeworks via Wikipedia

デブサミでの発表の後、質疑応答のためにAsk the speakerという場所でいろんな方とお話することができました。フィードバックありがとうございます。

その最後に、@kawagutiと@kappa4が来てくださって、いろいろお話しさせていただいたのですが、そこで超生産的なチームの話題があがって、面白い考察を伺うことができたので、うる覚えですがちょっぴりまとめてみます。間違っていたらごめんなさい。

ある日、スクラムのスプリント（上の写真）を見ていて、スプリントをハイスピードでぐるぐるまわす超生産的なチームになったときに、「仕事がつまらなくなったりしないか？」と思いました。あまりに効率的な開発をしていると、「ソフトウェア工場」みたいになってしまって飽きるのではないかなーと不安になったのです。

お二人はスクラム有識者ですので、どんなこと考えてるのかなーと思って聞いてみました。

@kappa4のお話しでは、「プロダクトオーナーは、ワクワクするようなプロダクトのビジョンを開発チームに話す必要があり、そのワクワクが開発チームを刺激するんじゃないか？もし、空き時間ができたのであれば、Googleの20％ルールのように、空いた時間を学習や検証につかって、プロダクトに貢献すればいいのでは？」というもの。

たしかに、プロダクトビジョンの重要性については、@kohsukekawaのセッション「【17-C-1】Continuous DeliveryとJenkinsアブストラクト」でも強く感じ、エンジニア視点や考察から考え出されるプロダクトのビジョンにはワクワクしました。プロダクトを引っ張っていくプロダクトオーナーの重要性を感じますね。

そして、サービス開発をしていると、リリースはサービスCloseまで続くので、@kawagutiがおっしゃっていた「そもそもプロジェクトとかの単位ってよくないんじゃないか？」という言葉にも思うところがありました。

経験則ですが、ソフトウェア開発をプロジェクト単位でやると、最後の方には「プロジェクトを終わらせることが目的」という錯覚が生まれて、「期限内に無事リリースできたから成功」みたいな目的と手段のすりかわりが発生してしまうことが多かったです。デブサミで発表させていただいたプロジェクトも同じで、リリース後にいまいち成功の実感がなかったんですよね。

「プロジェクトを終わらせることが目的」だと、最高の結果が「無事リリース」なので、プロダクトビジョンを満たしたり、お客さんに価値あるソフトウェアをデリバリーすることを達成するのが難しいように感じます。入社することを目的とする若者と、入社してやりたい事を持っている若者の違いみたいな。

SIerで働いていた頃は、リリースが終わるとメンバーもばらばらになることが多く、プロダクトビジョンを満たしたという実感をあまり持てなかったのですが、永遠に続くサービス開発でそれをやっても、開発だけで盛り上がっちゃって、ビジネスサイドとの共感やビジネスとしての成功につながらないんじゃないか？

じゃ、どうやったらいいの？ってのを最近考えております。Similar Posts:

• アジャイル開発のバーンダウンチャートはもう古い？！2012年からは「にゃーんダウンチャート」へ
• Agile2010 – Enterprise Scrum: Creating an Agile Company
• Jeff Patton氏の “情熱プロダクトオーナーシップ” に参加しました #sgt2011 #CSPO
• ユーザーストーリーマッピングで地図を書き、ソフトウェア開発の旅に出よう！
• リーンソフトウェア開発を読了
• 「アジャイルソフトウェア開発スクラム」を読んだ
• Redmine0.9.0のスクラム化 – backlog pluginでスプリント計画！
• 1/16（月）にJim Coplien 氏のアジャイル実践者研修が開催されます
• Agile 2011のプログラムが公開！気になるセッションを調べてみよう！
• アジャイル実践者として持っておきたいアジャイルツールセット

デブサミ2012が終わりました。僕は去年初参加だったので、今年で2回目。スピーカーとして参加できるなんて夢にも思いませんでした。

1日目は発表のため、2日目は脱力のため、一部のセッションにしか参加できませんでしたが、デブサミ2012のアジャイルセッションはすばらしかったです。

OpenJamは大盛況！

@kawagutiと@m_sekiのOpenJamセッション。これにあわせて到着したのですが、参加者が多かったですねー。OpenJamを休憩所として使おうと企んでいましたが、そんなことできるわけもなく。

去年も思ったのですが、デブサミはAgile Conferenceの雰囲気ととても似ています。OpenJamも@kawagutiによって輸入され、今年は@kaorun55も参加していたライブコーディングもあって会場外でも楽しめました。

【16-B-4】アジャイル開発の10年と今後を語ろう。平鍋 健児 氏

アジャイルに関して、世界からも認められている@hiranabeが語る10年は恐ろしく重みがあります。Agile Conferenceで「日本人です」っていうといつも「じゃ、Kenjiを知ってるかい？」って言われるんですよね。「面白そうなことやらないでどうするんですか！」といってさっそうと去っていく平鍋さんの背中は大きかった。

そんな平鍋さんの語るこれまでの10年とこれからの10年。発表の中で紹介されたアリスターさんのEnd of Methodologyからの一言。

分厚い方法論を持っている会社は滅びてしまうのではないか

すごく考えさせられる言葉です。日本からの発信として「スクラム、そして、アジャイル。~日本が取り戻すソフトウェア開発手法はここにある」を書かれるそうですね。楽しみです。

【17-C-3】オフェンシブな開発～「納品しない受託開発」にみるソフトウェア受託開発の未来 倉貫 義人 氏

そして、平鍋さんと共にアジャイルの10年を語るにふさわしい@kuranuki。僕がアジャイルの勉強を始めたのは、2009年1月とあるイベントで倉貫さんにお会いしたのがきっかけでした。社内で講演していただいた後に

「制約が少ない環境なのになんでアジャイルじゃないんですか？」

と言われたときは悔しかったですw。その後、倉貫さんは独立されてソニックガーデンが立ち上がります。あのニュースは衝撃だった。

DevLOVEアンオフィシャルパーティーで少しお話させて頂いたのですが、倉貫さんの考え方はいつも新鮮です。なんというか、「いつも変わってる」んですよね。ずっと変化している。進化している。

【17-B-5】アジャイルマニフェスト ディケイド 角谷 信太郎 氏

角谷さんのセッション。感想をフィードバックとして書こうと思ったんですが書けませんね。Ask the Speakerが大行列だったので「ライダーとマニフェスト署名者を整理したところすごい！」と伝えることができなかったのが残念です。まさか本当に作るとは思いませんでした。

なんというか、角谷さんのフォースが会場を「セイヤー」と震わせた気がしています。ここまで迫力のあるプレゼンを聞いたのは初めてだった。言葉の力ってすごい。

デブサミ2012から感じたアジャイルの10年と未来

去年、Agile Conferenceで「The Big Park Bench」というイベントが開催されました。アジャイルマニフェスト署名者が集まり再開するという歴史的イベントです。10年という時を超えて、海外でのアジャイルが成熟した瞬間を感じました。

そして、こちらは日本ですが今年のAgile Japan東京サテライトの開催に向けての挨拶にはこうあります。

新しいことを始めようとする気持ち、新たな息吹を感じたい気持ち、未来につながる新しい変化を起こしたい気持ちを持っているなら、ぜひ参加してほしい。新しいアジャイルの1歩を踏み出そう。

ふりかえってばかりでは前に進みません。次の一歩へ。新しい変化へ。きっとそういったものがアジャイル実践者に求められているのでしょう。次の10年はもう始まっています。

Action is the only way to find where you really are.
アクションは自分がいる場所を確認する唯一の方法だ
　　　　　　　　　　　　Hi-STANDARD Gloryより

それでは、位置について。よーい。ドンッ！Similar Posts:

• 明日のデブサミ2012で「アジャイルリーダーシップと組織改革」を発表します #devsumi
• 1/16（月）にJim Coplien 氏のアジャイル実践者研修が開催されます
• アジャイル実践者として持っておきたいアジャイルツールセット
• 平鍋さんの”アジャイル開発の現在・過去・未来”から感じたこと
• アジャイル実践者研修のおみやげが届きました
• Agile India 2012 が2/17から3日間開催！#agileindia2012
• アジャイルサムライ著者ジョナサン・ラスマセン氏から #DevLOVE へのメッセージ動画
• アジャイルリーダーシップと組織改革 楽天のアジャイルを発表しました #devsumi
• #DevLOVE HangarFlight Snow Barrageで楽天のアジャイル導入を語ります
• Letter to an Agile Samurai – アジャイルサムライへの手紙 #agilesamurai

（撮影：よしおかさん）

開発者たちの祭典、Developers Summit 2012（デブサミ）で「アジャイルリーダーシップと組織改革 ～楽天のアジャイル開発というリアル〜」という発表をさせていただきました。資料はSlideShareとSpeaker Deckで公開しています。

機会をくださったDevLOVE@papandaさん、翔泳社@kohseiさん、ちゃんこを食べながらアドバイスを下さったマスター@kakutani、一緒に働いた会社の同僚や来てくださったみなさんに感謝いたします。

セッションについては、タイムテーブルの説明がベースになっています。

【16-B-5】アジャイルリーダーシップと組織改革 ～楽天のアジャイル開発というリアル～
レガシーコード、求められる開発生産性。開発現場の課題は、この10年で変化したのでしょうか？一方で、世界は日々変化しており、変化を抱擁しない限り、その変化と現実のギャップは徐々に広がっていきます。このセッションでは、楽天という大きな組織の中で始めたアジャイル開発についてお話させて頂きます。変化に対応できる開発のために導入した『アジャイル』が実際どうだったのか？その導入から他部署への展開で経験したリアルを共有させていただく予定です。

実際に導入から展開をしてみたアジャイル開発の中で、「リーダーと成長したチーム」の物語をまとめました。

発表前のこと

発表前の様子（撮影：よしおかさん）

控え室に行くと有名人ばかり！！デブサミ10周年でスペシャルな人が集まってるなーと実感しました。とりあえず怖いので慣れているよしおかさんの隣に移動。よしおかさんは最近、スマフォで撮影した写真をソーシャルにUpするのがマイブームです。

発表直前（会社の先輩の撮影）

スライドに登場した効果測定について補足

Ask the speakerで「効果の説明に使われていた数字の詳細を知りたい」というFBをいただいたので、以下に少しだけ補足させて頂きます。もしかしたら計算間違っているかもしれませんが、ご了承ください。。。

ライブラリの数というのは機能別の数と、クラス数で測定していました。グラフはクラス数（テスト含む）で、８月40クラスから１１月148クラスになったという意味になります。この時は確か、2名（たまに藤原参加）でプログラミングしていました。

Capistranoを使った手作業の自動化については、１０手順ぐらいあったマニュアル作業にかかる時間を計測し、自動化したときにかかる時間と比較しています。ざっくりですが、手作業で400分かかっていたものが、80分まで圧縮できたという結果です。

これはCapistrano利用ユーザ数のグラフ。単純にアカウント数を数えただけですが、８月36人、９月６１人、１０月６５人になってます。最近計測したところ、２６０人ぐらい（エンジニア全体の２６％ぐらい）が利用しているようです。

横槍作業により圧迫された開発時間の数値です。全体で126時間/月ぐらいだったのが、７６６時間/月になったというものです。一人が複数サービスを持っている場合があるので、時間資源の集中がとても難しかったのを記憶しています。

こちらは単純にタスク（ふせん）の数なのですが、２月３０、３月２０、４月３０、５月５０、６月１２０という数でした。

さいごに

今回の発表させていただいた内容は、楽天に入社して@yuchimiriや@iamapenたちと出会い、共に戦った記録でもあります。二人がいなかったら頑張れなかった気がする。ありがとう。

アジャイル開発の導入の道は長く険しく、思った以上に思うようにいきませんでした。しかし、そんな中でも、変化にチャレンジし続けるチームや、若きスクラムマスター@TAKAKING22、サポートしてくれる周囲の人間の力が、道を切り開いてくれたのだと思います。ありがとう。

今思い返せば、年末に@papandaと江ノ島を歩きながら、「開発ってなんだろうね」という話をしたのが懐かしい。寒かったねー。これまでのアジャイル開発をふりかえり、自分のエンジニア人生や、10年後も世界で通じるエンジニアであるためのことを考えるきっかけになりました。ありがとう。

皇国の興廃この一戦にあり、各員一層奮励努力せよ

@papandaから発表を依頼され、２ヶ月間ずーっと考えて作った資料なのですが、「チームを勇気づける」というアジャイルサムライの言葉が、たまたま観光してみつけた戦艦三笠のZ旗とだぶり、こんな資料ができたのだと思います。

あらためて、みんなに感謝いたします。ありがとう。

*

Similar Posts:

• 明日のデブサミ2012で「アジャイルリーダーシップと組織改革」を発表します #devsumi
• #DevLOVE HangarFlight Snow Barrageで楽天のアジャイル導入を語ります
• 1/16（月）にJim Coplien 氏のアジャイル実践者研修が開催されます
• アジャイル実践者研修のおみやげが届きました
• アジャイル実践者として持っておきたいアジャイルツールセット
• Agile India 2012 が2/17から3日間開催！#agileindia2012
• 初めてのアジャイル開発を読了
• アジャイルサムライ著者ジョナサン・ラスマセン氏から #DevLOVE へのメッセージ動画
• Doingだけじゃアジャイルにならない？アジャイルになるための継続的デリバリとリーダーシップとは？
• アジャイル開発のバーンダウンチャートはもう古い？！2012年からは「にゃーんダウンチャート」へ

明日はいよいよ「Developers Summit 2012 – 10年後も世界で通じるエンジニアであるために」です。

デブサミは去年初参加だったのですが、今年は機会に恵まれて発表させていただくことになりました。皆様のおかげで生きております。

【16-B-5】アジャイルリーダーシップと組織改革 ～楽天のアジャイル開発というリアル～

レガシーコード、求められる開発生産性。開発現場の課題は、この10年で変化したのでしょうか？一方で、世界は日々変化しており、変化を抱擁しない限り、その変化と現実のギャップは徐々に広がっていきます。このセッションでは、楽天という大きな組織の中で始めたアジャイル開発についてお話させて頂きます。変化に対応できる開発のために導入した『アジャイル』が実際どうだったのか？その導入から他部署への展開で経験したリアルを共有させていただく予定です。

自分にとって大きかった二つの疑問。「アジャイルは組織を変えるのか？」「アジャイルにおけるリーダーシップとは？」に対する今の答えと、そこに行き着くまでの経験をお話させていただきます。

当日、皆様にお会いできることを楽しみにしております！Similar Posts:

• アジャイルリーダーシップと組織改革 楽天のアジャイルを発表しました #devsumi
• Agile India 2012 が2/17から3日間開催！#agileindia2012
• #DevLOVE HangarFlight Snow Barrageで楽天のアジャイル導入を語ります
• Agile 2011にやってきた
• 1/16（月）にJim Coplien 氏のアジャイル実践者研修が開催されます
• デブサミ2012から感じたアジャイルの10年と未来 #devsumi
• XPは砕けない – SonicGarden倉貫さんのストーリー
• アジャイル実践者研修のおみやげが届きました
• Doingだけじゃアジャイルにならない？アジャイルになるための継続的デリバリとリーダーシップとは？
• アジャイル実践者として持っておきたいアジャイルツールセット

おかんの描いた育児日記を読むと、僕はとても胃腸が弱く、「おじや」が大好きで社交的な赤ちゃんだったらしい。すぐに風邪をひいたり、ぶつぶつができたりして、若いおかんは日記の終わりにいつも「がんばれー」「がんばれー」って書いていた。

がんばれ！がんばれ！Similar Posts:

• がんばれ
• いきなり風邪
• Googleストリートビューで実家に行ってみた
• ジェダイの騎士とパダワン
• 青い春
• 夢の大地 オリンピア
• 1年4組だった藤原さんの日記 in ジュニア・エポカ学習帳 二回目
• スイカとイコカ
• 北島選手の金メダル
• 一生後悔するぞ

via Digitalnative from frickr

最近、組織としての視点と、開発者としての視点を比較して考えることが多く、2つの視点で考えると、開発って難しいジャッジメントが多いなぁと感じます。恐らく、今の結論は未来に変わっているでしょうし、「正解です！」というようなものもなさそう。

これも前に書いた「エンジニアを確保しやすい」という理由でプログラム言語を選んでいいのか？と似た話題だと思いますが、ソフトウェアを内製する場合と、外注する場合のメリットデメリットをちょっと考えてみました。

考えたきっかけ

ITPRO中田さんの「無いから作った人たち」という記事でも紹介されているように、Facebookが開発したCassandraとか、mixiのTokyo Tyrantとか、自分が欲しい物を作って公開しているエンジニアってすごいなぁと思います。業界に貢献とか、企業の技術ブランドUPにもつながりますし、新しいプロダクトはエンジニアのモチベーションを高めます。

ただ、会社で働いていると、作らずベンダー製品を活用するほうがよかったりする場合もあります。例えば、経理システムのような提携作業をの業務パッケージ化したものや、オラクルのような信頼と実績のあるデータベースとか。サービス企画までして開発は外注したり、いろんな方法でシステムは作られます。

こういった「どういう風に作る？」という判断はとても難しく、たまに、こういう相談を受けることがあるので、そのときによく考えることを整理してみたいと思います。

OSS開発、内製、ベンダー採用、外注・・・といろいろなケースがありますが、今回は単純に「中でなんとかする場合」と「外だけや外も活用する場合」にわけています。

中で何とかする場合

このメリットとしては、以下が考えられます。

• 自分が欲しい物を実現しやすいため、オーダーメイド感覚で作ることができる
• 外部調整がないので調整コストが低い
• 作るのが楽しそう
• 自社の開発力が上がる

逆に、デメリットは以下が考えられます。

• ある程度の技術力が開発に必要なので、人の確保（採用、広報）が必要になる
• オープンソースのプロダクトのほうが優秀な場合があったりする
• いけてない社内ツールが量産されるリスクがある

デメリットについては、やっぱり人の問題があります。オープンソースを使い倒して作られたシステムがあり、キーマンが抜けて維持できなくなるケースも見たことがあります。このへんは、組織的に人を育てるなどの対策をしなければ、人に依存したシステムに苦しめられます。

外も活用して何とかする場合

では、外パターンを考えてみます。まずメリットとしてどういうものがあるでしょうか。

• 安心の製品サポートがあり、困ったときに助けてもらうことが可能
• 専門エンジニアをあつめて開発されているわけなので、高性能・高品質をゲットできる
• 企画などに会社の資源を集中することができる

デメリットは以下でしょうか。

• ベンダーロックインで方針変更が難しくなってしまう
• 外部に依存するリスクがある
• 外部との調整で時間をとられる
• お金がかかる

「お金がかかる」点に関しては、場合によっては安く手に入るケースもあると思います。ただ、友人エンジニア何人かに聞くと、「外注のほうが高い」と答えることが多かったので、とりあえず外パターンのデメリットに入れておきます。

で、結局どっちがいいの？

答えはコンテキストにより変わると思いますが、自分が質問されたときの答えは以下です。

1. どういう開発部隊にしたいかで決める組織視点
2. メンバーのモチベーションで決めるエンジニア視点

「どうなりたいか？」という理念次第である程度の方針が出る気がしています。

1については、開発力で業界を生き残る戦略であれば内製を重視し、そうでもないなら外注寄りを視野に入れることができそうです。また2のように、新技術や技術動向に明るい人がいたり、「チャレンジしたいぜ！」というエンジニアが多いなら、内製という判断をしても後悔しない気もします。そのときは、エンジニアの興味とこれからの運用のトレードオフが必要でしょう。

一つの方針で走り続けるのも大変なので、だめそうになったら切り替え、またできそうになったら切り替え・・・という形で「歴史は繰り返すパターン」でやるのも、効率は悪そうですがアリな気がしています。内製はわかるんだけど踏ん切りがつきにくい。。。という意見はよく聞きますし。ただ、「やる！」と決めて走りつづければ、時間がかかっちゃうかもしれませんが、GoogleやFacebookのような、突き抜けた開発文化も作れる気がします。

私はエンジニア採用で社会人になった人間なので、自社で作りたいという気持ちが強いほうです。ただ、やるなら「無いから作った人たち」のように、作ったものをWebに公開していけるような開発がいいなぁと思っています。

そういうエンジニアが喝采を浴びるような世の中って夢があって素敵じゃないですか。Similar Posts:

• Wikipediaの「プログラマ」を説明したページの内容が偏っている件について
• 半年間のアジャイル開発をタスクボードでふりかえる動画！XP祭り2011LT資料 #xpjug
• ヌーラボさんのBacklogにできてRedmineにできないこと
• 詳説！Redmineを使ったスマートな開発プロセス改善（画面キャプチャ付き）
• 偉大なるリーダーシップ – ハーバード・ビジネス・レビューにスクラムが登場
• いつものミーティングをアジャイル開発手法「スクラム」で再設計した感想
• プログラマの魅力
• もうすぐ彼女の誕生日だってのに
• さよならかっこいいエンジニア
• スーパーエンジニアになるために

Agile2012の発表者募集が始まっています。

ちょっと気になったので、募集要項を調べてみました。

スピーカーへの説明は、Agile2012 For Speakerから確認できます。以下、適当訳です。

WELCOME TO THE AGILE2012 CONFERENCE OFFICIAL PROGRAM!

Agile2012カンファレンスは、コミュニティによるコミュニティのためのカンファレンスです。そして、興味のあるトピックを提出（サブミッション）し、そのレビューや承認フローによって、発表の機会が設けられています。過去のデータを元にすると、1000以上の申請から200ぐらいのセッションが選出されています。

レビューチームは14のステージに分かれています。それぞれのステージは特別な領域にフォーカスしています。発表したいトピックは、自分が一番近いと感じるステージに対して行ってください。どのステージでもしっかりとレビューが行われ、阿多のサブミッションに対してもしっかり整理されます。もし、プログラムやレビューチームが、あなたのサブミッションがステージにマッチしないと判断した場合は、より適したステージへとアシストすることになります。

サブミッションがとおり、あなたに対して最高の機会が提供されるとなると、注意深く説得力のあるトピックを考えていく必要があり、準備や、あなたの考えに対して明確なサブミッションになるように準備をはじめ、セッションに対してアプローチしていきます。

サブミッションを書き始めるときに、自分をレビュアーの立場に置き換えてください。ステージプロデューサーやレビュアーは、あなたのサブミッションに対する顧客と同じです。高い品質のものをデリバリしましょう。レビューチームは、たくさんの提出物を読まなければならないことを覚えておいてください。彼らが理解できるように明確な、説得力のあるものに仕上げてください。混乱しやすかったり、不十分な説明だったり、過度に言葉が多いサブミッションは、レビュアーの仕事を大変なものにしてしまいます。信頼できるフィードバックをしてくれる誰かに相談するなどして、Submitボタンを押す前に、評価してもらうようにしてください。We hope you make the reviewers job difficult in another way, by making your submission impossible to pass by. Give them so many great proposals that choosing among them presents a huge challenge!

早期のサブミッションを推奨するために、2つの承認ラウンドがあります。ファーストラウンドは、1月15日まで、セカンドラウンドは、2月19日まで。詳細は以下のレビュープロセスタイムラインを確認してください。

SUBMISSIONS

個人は4つまでサブミッションを提出可能です。この制限はあまり気にせずによく、個人がプライマリやセカンダリ提出者として認識されるだけになります。そして、個人は、２つまでの承認されたサブミッションのみプログラムに反映され、２セッションのプライマリ、セカンダリ提出者となります。

サブミッションを書くときには、以下の項目を検討してください。

1. 興味深いタイトルを考えましょう。タイトルは、よい印象をもたれるための一番のチャンスです。もし、タイトルがレビュアーの興味を聞いた場合、参加者の興味も引く可能性があります。

2. 参加者がなぜこのセッションに参加するのか？参加者とコミュニケーションが取れるように、明確な紹介文を用意してください。行動や問題提起といった部分を含めて検討するといいでしょう

3. プロセスや方法により、時間の長さや、時間の使い方を含む、セッション中の時間構造を、どのようにあなたが組み立てるかということをコミュニケーションしてください。時間の使い方については、変更は可能です。しかし、完璧に仕上げることを前提に進めてください。これはとても重要なことであり、あなたのプレゼンテーションによるアプローチで明確にコミュニケーションをすべきです。そして、参加者との約束にもなります。このセクションに対して、以下の追加情報を含めたい場合もあると思います。

参加者： あなたにとってもっとも優先度が高い対象となる参加者は誰かを理解します。そして、コミュニケーションをとります。これらは、よいサブミッションのキーになる部分です。参加者は、なぜあなたのセッションに参加すべきなのかや、なぜセッションが彼らに価値があるか？という情報に対する理解を必要としています。セッションのレベルや、学ぶこと、プラクティスやサブミッションへのアドバイスをドロップダウンで選ぶと、レビュアーは、「このセッションでは、企業内で働く、XPやスクラムを紹介したいと思っているが、どうやって進めたらいいか迷っている中級マネージャをターゲットにしている」といった追加の詳細情報を理解することができます。

プレゼーンテーションフォーマット：レクチャーやドロップダウンオプションに加えて、よいサブミッションは、プレゼンフォーマットを活用します。一つの例を挙げると、昨年、審査を通った発表の中で「セッションでは、まず紹介やゲームの目的を話し、ルールを説明し、そして、どうゲームするかの例をあげます。参加者は1時間で完全にゲームを理解するはずです」というものもありました。

プレゼンテーション履歴：以前にあつかったトピックでしょうか？もし、以前に発表していたりするのであれば、発表日や場所、内容など、参考となるリンクなどを共有してください。

発表能力の参照：すべてのレビュアーがあなたの発表能力やスタイルを知っているわけではありません。あなたのプレゼンテーション能力を説明できる人の名前を伝えることが、レビューチームの支援につながります。

4. 学習成果や効果を考えましょう。参加者がセッションでこれまでと違った練習になることや、どういったものを持って帰ることを保証できるかといった、効果的な成果を一覧にしましょう。例えば、「このセッションの参加者は〜〜でしょう」と説明したり、「効果的で効率的なミーティングを調査することで、混合することなく、戦略的、戦術的、日に日に焦点があってきます」というような説明や「５つの方法をリストにすることによりベロシティに作用する」というふうに、「練習する」「ディスカッションする」「演じる」「監視する」「調査する」「解析する」「検討する」「相互作用する」「認める」「投票する」など、あなたがセッション中に参加者に求める行動を、動詞を頭にすることで、その効果を知ることができるようになります。小さい学習効果では、観察できるコンテキストを映し出さず、我々の知る由のない参加者の頭の中で何が起こっているか仮定するしかありません。例えば、コミュニケーションに対するアプローチについて考えるとか、新しいコーディングテクニックについて学ぶ”といった、ぼんやりした学習目的だと弱い発表になってしまいます。

Review Process

2011年、2012年は、早期のサブミッションを後押しするため、2サイクルレビュープロセスを使っており、イテレーティブに提出物を改善しています。提出物はそれぞれのステージに直接提出となります。ステージプロデューサーやレビュアーは、提出者と共に作業し、発表にもっともあったステージを見つけるでしょう。

TIMELINES

サブミッションシステムは2011/12/1にオープンし、2012/2/19にクローズします。早期サブミッションを促すために、2ラウンドにわたって審査します。

ここで力尽きました。。。

つづきは、http://agile2012.agilealliance.org/for-speakers/から。。。Similar Posts:

• Agile2012サイトがオープン！参加登録、発表募集も開始 #agile2012
• Agile2011の開催概要から登録方法まで – Attendee Conference Guideより
• アジャイルなレビューをサポートするツールを5つ
• Agile 2011のプログラムが公開！気になるセッションを調べてみよう！
• Letter to an Agile Samurai – アジャイルサムライへの手紙 #agilesamurai
• アジャイル実践者として持っておきたいアジャイルツールセット
• そうだ！Agile 2011 Conferenceに行こう！
• Agile 2010 Conferenceにいってきた Day1 AM
• さぁ、始まりの場所に帰ろう – Agile 2011 マニフェスト署名者たちのセッション
• 大きな変化を抱擁せよ！ 楽天テクノロジーカンファレンス2011明日開催

第3回RxTstudyで「Redmineをチームに適用せよ！」を発表させていただきました。機会をくださった@yohhatuさんをはじめ、大阪の皆さまありがとうございます。すごく楽しかったです。

ちょっと前に、shinagawa.redmineでシステムやプラグインの歴史を共有させていただいたのですが、RxTstudyでは、その歴史の中で、チームはどのようにRedmineを使っていったかというテーマでお話させていただきました。

資料の一部には、海外からのアクセス対応としてなれない英語を使っている部分があります。ご了承下さい。資料はSlideShareとSpeakerDeckで公開しています。

前職では、とあるプロジェクトでTrac導入したりしたりしていました。2008年に今の会社に転職しました。

私が入社してはじめての場所はメンバーが3名ぐらいで、社内のミドルウェア標準化などの作業を担当していました。とくにタスクが管理されていたわけではなく、MTGがたくさんあったりして、私にとってあまり気持ちよく働けるような場所ではなかったです。

現場改善として、Redmineを空いているサーバに入れ、チーム導入を試みたりしたのですが、全然受け入れられることはありませんでした。かといって、仕事の効率が上がることもなく、仕事がうまくいくこともなく、全体的に閉塞感があったように思います。

やっぱりそういう現場は会社で長く続きません。最終的には、チームは解散。私は、パートナーとして来ていただいている二人のエンジニアと組み、チームの立て直しを行うようになります。とっかかりとして、社内でよく使われる似たような処理をまとめた「Java社内ライブラリ」の開発を選びました。

開発手法はXPを選択。人数が少ないので、楽できる部分を増やすためにツールをがんがん試しました。結構な数のツールを試しながら、使うもの以外はCloseしていき、Redmine、ReviewBoard、Wiki、CI・・・ぐらいが生き残りました。

タスクのトラッキングをしたかったので、チームにお願いしてタスク管理はいきなりRedmineを使いました。はじめはメンバーも慣れていないので、週に1回1つの画面を見ながら、自分が中心にタスクを作り、作業を確認しながらCloseするペアRedmineをしました。

慣れてくると徐々にまかせるようにしていき、最終的には朝礼での状況共有、スプリントの終わりにCloseされてないものを個別に確認という形になってきました。

合わせてRedmineのプラグインを自分で作り、見える化することで「どういう状況なのか」をチームに共有しました。Mgrへの報告も楽になり、やることが明確になり、集中して開発する時間が増えました。

メンバーも徐々に増えていったのですが、朝礼によって、メンバー間の調整を促すことで、メンバー間コミュニケーションが蜜になってきます。週に1回のマンツーマンペアRedmineを通して、Redmineの利用方法を伝えたり私とメンバー間のコミュニケーションも増やしました。

仕事の成果は小さなものが多かったのですが、ちょっとずつ前に進んでいる感が生まれました。何よりもチームの雰囲気がよくなり、周りと比べても元気なチームになってきました。

2010年は社内のRedmineユーザが1000人を超えた年です。チームも安定してきた時期で、引き続きRedmineやプラグインを活用して改善を続けていました。マンツーマンペアRedmineは徐々に減り、朝礼で十分になってきました。

それなりに順調にタスク管理ができていたのですが、なかなか仕事が終わらなかったり、長期的な作業チケットどうどうするか迷ったりするようになりました。

パーキングロットチャートプラグイン DoneしたVersionを見える化

仕事が終わらない問題については、Redmineのバージョンを付箋のように並べ表示しただけのパーキングロットチャートプラグインが効果的でした。

「○○をやります！」のようにバージョンに「達成すること」を記入して、「やること」をより明確に見えるようにしました。長い時間のかかる作業についてはバージョンをわけて対応したり、1つめのバージョンでここまで。2つめのバージョンでここまで・・・とロードマップになるように分割しました。

「達成すること」は「リリースする何かしら」として、中途半端なものがリリースされないように注意しました。一つ一つのバージョンを完結する作業としてやっていくと、半年位で上の写真のようにたくさんのDoneした作業が積み上がって見えます。

そして、私のチームは問い合わせが多い部署でして、ものすごく開発を圧迫していました。もともとデジエというツールを使って管理していたのですが、トラッキングに強いRedmineに変更しました。対応時間を入力することで作業コストの分析ができるようにしました。

チームの指標としてはベロシティを使い、「Redmineでアジャイルチームのスピードやパワーを見える化する」のように安定性をチェックするようにしました。

その結果、チーム状況の見える化から、成果の見える化につながりました。コストがかかる部分を分析し、改善ポイントを見つけ対応することができるようになりました。

また、過去のよくあるやり取りをFAQや手順にまとめることで、問い合わせや対応コストを減らすことも出来ました。効果的にRedmineを使うことで、Redmineはさらにチームに浸透していきました。

チームに力がついてきたので、昨年は現場支援として現場のチームと組んでプロジェクトを担当しました。メンバーでタスクボードを使ってタスク管理を行ったため、Redmineは使わなくなりました。

Redmineを使うことも考えましたが、異なるチームが混合で働くこともあり「一緒にやってる感」をだすためにタスクボードにしました。「それぞれのPCでRedmineを見る」と「一つのタスクボードを見る」はやっぱり違うんですよね。

結果的にRedmineを使わなくてもうまくタスク管理できたのですが、ふりかえってみると、今回のプロジェクトに関してはRedmineを適用する部分が少なかった気がしています。

設計のディスカッションなどはホワイトボードに書いたものを写真にしたり、その写真やその他の情報はWikiに整理しました。ソースに関してはコミットログやコメントに情報を残しています。

タスクボードに貼ると「ログが残らない」と思ってしまいますが、残したいものを残すようにしていると、特に困ることがありませんでした。

当時、チームでよく話題になったのがタスクのサイズ問題でした。いろいろやってみたところ、スプリント（イテレーション）のサイズにあわせて考えるようになりました。

例えば、スプリントが1週間なら、付箋には1〜2日のサイズでタスクを書き、最大で1週間のサイズにするようにします。これによって、スプリントで誰もが1回はDoneすることになり「やっている感」「進んでいる感」がでます。1〜2日サイズとすることで毎日の朝礼で1人が1つのチケットをDone！する形にしたかったのです。

1日以下の小さいタスクは付箋を使わないようにしました。これを付箋にすると朝礼が長くなってしまいます。

最近では、改めてタスク管理を考えるようにしています。

上の図はJeff Patton氏のCSPO研修で出てきた絵なのですが、Feature単位でタスクを考え、それをリリース、イテレーション、開発タスクへと分割し、開発タスクがDoneすることで、有効なパーツ（ソフトウェア部品のようなもの？）ができあがり、パーツがあつまって最小サイズのソフトウェアができあがり、それを継続的にリリースしていきます。

この考え方が個人的にわかりやすく、チームの評判も良かったので、今では上の図をベースにスプリント計画でユーザーストーリーマッピングを使い、ストーリーをタスクに分割する作業をチームでやっています。チームでタスクの大きさや呼び方をそろえ（ストーリーとタスクの2つを使っている）、ミニマムサイズのリリースを意識したタスク管理を行うようにしています。

このやり方を気に入っている理由は、動くものを効率的に小さくリリースすることで、より価値のあるソフトウェアを作っていく…という点を体験したかったからです。いいところや難しいところを経験するにはちょうどいい開発だったので。

ソフトウェアの価値を意識すると、おのずとユーザの要件をタスクに落としこむ部分に注意するようになりました。過去に参加した勉強会やカンファレンス資料からヒントを得て、「要件」を「きっかけ」としてとらえ、ユーザーとの会話から要求を見つけていくやり方を探求しています。

最近、「ユーザーエクスペリエンスのためのストーリーテリング」という本を、UX TOKYOさんから献本いただいたのですが、その中に登場するスプリングボードストーリーがとても面白く、ストーリー作りのときに実験でこの技を使っています。

例えば、「リリースを自動化したい」という要求が私にはあったのですが、「1日10回リリースできるようにして欲しい」という言い方に変えてチームに伝えました。

小さなニュアンスの違いでしかありませんが、単純に作業を自動化するのではなく、1日10回のリリースに耐え切れるプロセスを考えたり、実現に向けてアーキテクチャやプログラムをリファクタリングしたり、思った以上にいろいろ考えて対応してくれたのです。

詳細は「ユーザーエクスペリエンスのためのストーリーテリング」をぜひ読んでいただきたいのですが、ストーリーの中にある隠れた部分を、想像力や技術的アイデアで解決していく印象があり、チームでのディスカッションを聞いているととても創造的なやりとりになるので、今後もいろいろ試してみようと思っています。

そろそろまとめです。

Redmineをチームに適用し、プラグイン開発やアジャイルプラクティスなどを試してきましたが、Redmineを自分色に染めるだけではなく、Redmineのようなツールに合わせてプロセスを考えるのもひとつの手です。カスタマイズしすぎると、いつのまにか便利が不便になってしまうかもしれません。

また、こういうツールはツールを「使うこと」が先行してしまい、「使う目的」を見失うことが多いので、使い方と考え方はセットで利用者に伝えていく必要があります。

そして、なによりも、「使わない」という選択を頭に入れておくべきです。コンテキストが変化したときに「従来のやり方」が最善であるとは限りません。思い切って違うやり方を導入することを考え、より柔軟に変化に対応していくほうが、私のチームにはマッチしていました。

今後は、私のコンテキストだと「大人数」があるため、JIRAやTFSのような開発プロセス全体をカバーする統合的なツールをベースに、自社のプロセスにマッチしたツール導入を考えていこうと思います。ただ、Redmineはなくなるわけではなく、私のチームのように問い合わせ管理、バグ管理といったRedmineを適用しやすい仕事で残っていくかもしれません。

私のチームはツールからプロセスを考えるようになり、アナログなツールや会話の活用へと変化してきました。これが成熟すると、またツール導入を考えるかもしれませんね。

どのツールがいいか？どう使えばいいか？という質問をよく頂くのですが、「そもそもなんのために使うのか？」を考える必要があります。そこがブレるとツールを最大限に生かせないからです。ツールはツールでしかありませんが、うまく使うことによってとても大きな恩恵を得ることができます。ツールの進化により、恩恵はより大きくなってきたので、うまく使うにこしたことはないはず。

どう使うかは人間の考える事です。そして、自分以外が使うツールの場合は、使う相手のことも考える必要があります。いくら道具であっても「相手に対する思いやり」って重要です。

*

長くなってしまいましたが、shinagawa.redmineでの発表と、RxTstudyでの発表で私のRedmineナレッジや経験全てだと思っています。現場改善に取り組まれている方のお役に立てれば幸いです。また、こういった事例発表がどんどん共有されればいいなぁなんて思っています。

ありがとうございました。

*

Similar Posts:

• 楽天のRedmine事例を勉強会で発表します #47redmine #RxTstudy
• Redmine Backlogsで簡単スクラム！スクラムマスターや開発チームとして使う編
• Redmineのロゴが決まったらしい
• Redmineでプラグイン作ってたら「undefined method `plugins’ for Rails:Module (NoMethodError)」
• Redmineでアジャイルチームのスピードやパワーを見える化する
• アジャイルなレビューをサポートするツールを5つ
• Redmineプラグイン開発 – 史上最高のチームプラグインリリース
• アジャイルに結婚式準備を行うために必要なただ1つの方法
• BacklogsプラグインをMac上のRedmineにインストール
• Redmineプラグイン開発 – パーキングロットチャートプラグインリリース

昨日、プログラム言語についてつぶやいたら、いろいろFBを頂きました。ありがとうございます。つぶやきのきっかけは、ちょうどエンジニアと言語の選択について話をしたからでした。

チームは今Rubyと戯れているけれど「なんでRuby」と聞かれたので「まつもとさんとFBで友だちになった」と答えている 「そんな理由で」っていうけど「初めて配属されたところがJava使ってた」とかいう理由でJava始めるのよりはよっぽどいい話だと思うけどなぁ

よく聞く選定の条件や理由として、「エンジニアを確保しやすいかどうか」というものがあります。これは言語だけでなくフレームワークでも言えることかもしれません。

組織的な視点で考えると、なるほど。気持ちはわかる気がします。ただ、「エンジニアを確保しやすい＝いいエンジニアがいるわけではない」ので、「確保できる＝プロジェクトが成功する」というわけでもないでしょう。ふと「マンパワーでなんとかしよう」とか「なんとかなる」という楽観的な考え方になってしまっているのではないかと不安になりました。発想が現状維持だから面白みにかけるのかな。

さらに、こういった選定が、若いエンジニアに影響を与えることもあります。例えば「現場がPHP」の場合、入ってきた新人は「PHPを勉強してね」といわれて、PHP人生が始まり、確保しやすいエンジニアに仲間入りします。

私も、はじめの現場がJavaだったからJavaエンジニアからスタートしました。違うのやりたいなぁと思っても、なかなか導入は難しい。かといってずっとJavaエンジニアでやっていこうというほどの気持ちもありません。

結局、言語の選択は何でもいいんじゃないでしょうか。

理想を言うと、作る速さならRuby！安定性ならJava！とか、作るものにマッチした言語を選べばいい気がしますが、そうすると選択肢が限られてくる気がします。選択肢がしぼられるとわくわく感やチャレンジする気持ちが萎えてしまう。

だったら、目的や情熱を持っている人が決めて、それをチームが共感できるのであれば、その言語を使えばいいんじゃないかなぁと思うのです。

ちなみに、「まつもとさんとFriendになったからこれからはRuby！」と僕が宣言したとき、チームはざわざわしましたが、1週間後に簡単なツールのデモを見ることができました。しかもよくできてた。そんなもんなのだと思います。

* 「速さ」は「作る速さ」でしたので追記Similar Posts:

• プログラマの魅力
• さよならかっこいいエンジニア
• なんとなく仙台について調べてみた
• PHPエンジニアとJavaエンジニア
• インド人と日本人である藤原
• メモリが安い
• レンジ台がきました
• 楽天テクノロジーカンファレンスの中の人
• 自分の生誕31周年記念日のスピーチ
• 明日というか今日というか

前回、僕が持っているプランニングポーカーを紹介させていただいたんですが、最近、近所にプランニングポーカーコレクターが引っ越してきたので、彼のコレクションを見せていただきました。

各社個性豊かなデザインですが、だいたい数字は同じですね。コーヒーマークのカードとかは新しい！

プランニングポーカーは、これまでKKDだった見積もりが、コミュニケーションの場として生まれ変わるということで、僕の周りでも人気のプラクティスです。

日本ではまだ売ってない？と思うのですが、アギレルゴさんが、Mountain Goat 社製プランニングポーカーカード を一個単位でお分けします。ということをされており、まだ在庫があるみたいなので、ご興味があればどうぞ。

 Similar Posts:

• アジャイル実践者に大人気のプランニングポーカーの紹介
• アジャイル実践者研修のおみやげが届きました
• アジャイル実践者として持っておきたいアジャイルツールセット
• さぁ、始まりの場所に帰ろう – Agile 2011 マニフェスト署名者たちのセッション
• アジャイルなレビューをサポートするツールを5つ
• アジャイルな見積りと計画づくりを読んだ
• アジャイル開発の本質とスケールアップ読了
• アジャイルに結婚式準備を行うために必要なただ1つの方法
• Redmineでアジャイルチームのスピードやパワーを見える化する
• アジャイルな自己組織化されたチームにマネージャは必要か？ #devsumi から考えたこと

結婚祝いで、同僚に頂いたBodum社とFrancfrancのコラボ商品であるダブルウォールグラスがとても使いやすいのです。

2重になっているため、保温・保冷にすぐれていて、水滴もつかないし、熱いお茶でも熱くない！2つで2500円ぐらいなのでちょっとお高いですが、長く使いたくなる一品です。

調べてみるとBodumの製品にも色いろあるみたいですね。

【土日・祝日も発送&問合せOK】【bodum】 ボダム パヴィーナ　ダブルウォールグラス 2個セット … 価格：1,617円（税込、送料別）

Similar Posts:

• ダブルクォーテーション削除VBA
• Python2.5の文字列リテラル
• 寝室完成
• スターウォーズのポスターがほしい
• 巻き取れるLanケーブル
• フォースと共にあらんことを
• 捻挫発生より三日目 一日一回15分外出
• はじめての機種変更
• 携帯をW61CAに買い換えました
• ファイル読み込みVBA

我が家の寝室は、夏湿気が多く、冬乾燥するという悩ましい部屋です。

毎年、濡らしたタオルをぶら下げたり、洗濯物を寝る前に干したりしていましたが、スマートじゃない！！というわけで、前から気になっていた超音波アロマディフューザーを購入しました。なんと、今なら限定デザインお買い得セットです。

ランプにもなり、タイマーも付いているためつけっぱなしの心配もありません。しかも、音が静かなので寝室にぴったりですね。限定デザインも素敵な感じ。

アロマテラピーなんて、表参道を歩いている人だけのものだと思ってましたが、我が家も表参道レベルにちょっとずつ近づいています。Similar Posts:

• ダイソンのエアマルチプライアータワーファンを速攻レビュー
• とろとろ桃のフルーニュはここ数年で一番うまいジュースだ
• クロマティさん
• プログラマの魅力
• ハイビスカスを植えてみました
• 布団乾燥機（日立ふとん乾燥機「アッとドライ」HFK-SD2-P）を使ってみました
• Wii Sports リゾートを買いました
• Lamy サファリ 2007年限定ブラック購入
• 開国博にいってきたけどー
• ホームアローン2のダンカンさん

PCを整理していたときに偶然見つけた一枚の写真。

これは、世界遺産にも登録された小笠原諸島父島の港の風景です。小笠原諸島へは船旅となり、行きだけで25時間かかります。360度海しか見えず、夜は満天の星空をみることができますが、父島が見えた時と、船を降りた時の開放感はとても大きかったと記憶しています。

写真の話。この写真は帰りの船の出発風景です。小笠原で過ごした1週間はとても深く、以前ブログにも書いたのですが、最後の最後に、とても印象深いドラマがありました。

当時、小笠原へは1〜2週間に1回ほどしか船は来ません。確か、行きも帰りも同じ船で、途中船は来なかったと思います。そうじゃないと泊まる所が困るんですよね。そんな貴重な時間だから、島の人はこの時間をとても大切にしています。当時、僕はその風景をブログに書いていました。

汽笛が10月の小笠原の空に鳴り響き、船は陸と少しのサヨナラをします。
その瞬間。
手を振る人々がいっせいに船に歩み寄ってきます。
人々の声が大きくなります。
誰かがハイビスカスの花を空に手放し、
赤い花が青い海へと舞い落ちます。
「ありがとう」という声が聞こえます。
涙が出そうになり下を向きます。
「ありがとう」と思います。
見送る人達が小さくなっていきます。
みんな手を振ります。
美しい風景。
なんて美しい風景なんだろうと思います。

そして、幻想的な生活から25時間の船旅が始まり、都心へと帰っていくのです。

余談ですが、帰ってきたときに彼女（現在は嫁）と会う約束をしていて、次の日にその日に告白した気がする。ドラマチックに感じますが、久しぶりに都会女子にあってテンションが上がったのかもしれません。それもまた思い出。

* 1/25 17:29 その日ではなく次の日だというご指摘をいただいたので修正いたしましたSimilar Posts:

• 藤原の出発前夜
• エアロビクスをはじめてしました
• あと少しで30才になる独身エンジニアってどうよ
• 5/10 今週のザク
• 5/23 今週のザク
• はるうらら
• 結局全然寝れなかったけど沖縄に行ってきますね
• 真のクリスマスは？
• 6/6 今週のザク
• Googleマップで実家付近を激走する

第二回 shinagawa.redmine勉強会で「数千人が利用する楽天Redmineの過去と未来」を発表させていただきました。

資料はSlideShare、SpeakerDeckで公開しております。QAの時間が取れなかったため、質問などがあればTwitterでもなんでもご連絡ください。

来月、第3回RxTstudyでもRedmine事例の発表させていただくのですが、品川Redmineはシステム視点、RxTstudyではタスクマネジメント視点で資料を作りました。

はじまりは、使われてないサーバ上に作った仮想VMを使っていました。ユーザ数も少なかったので、WEBRickを利用し、ポートを分けることで複数Redmineを構築していました。WEBRickが固まることがあったので、cronで一日一回夜間に再起動して運用していました。

自分のグループで使ってみようという提案もしましたが、なぜか当時のマネージャが嫌がり断念。その後、ユーザー数はゆっくり増えてユーザ数64人に。当時だとエンジニア全体の10％に満たない開発者数です。

そんな中、プラグインを作っていろいろいじるようになり、チームの進捗を見える化し、チームを応援するため、Roadmapsプラグイン、All Time Teamプラグインを作りました。

その結果、Redmineの活用に成功しました。状況が一目でわかるようになり、見る側も自分がどういった状況なのかを理解できるようになりました。「チームでRedmineを使う」という方針にもつながりました。これらの成果は、徐々に周りへと広がり、徐々にユーザが拡大していきます。

ユーザが300人ぐらいを超え、チームメンバーもRedmineに慣れてくると、問い合わせ業務をRedmineに完全移行しました。外部とのやり取りを整理したかったという理由からだったのですが、問い合わせの傾向などをRedmineのレポートで出し、時間がかかっている部分を洗い出したり、過去の問い合わせをトラッキング＆検索することで、業務改善に大きく役立ちました。

このころからアジャイルプラクティスを本格的にRedmineに適用するようになります。

Version Burndown Chartプラグインはその1つです。Redmineのプロジェクトに対するバーンダウンチャートプラグインは見つけたのですが、バージョン単位のものがなかったので作成しました。しかし、入力が多く、バーンダウンせず最後にどーんと下がるチャートばかりだったので利用しなくなりました。

次に生まれたのがパーキングロットチャートプラグインです。私が作ったプラグインの中でも、これがもっとも多く使われているように感じています。バージョンを工夫することで、ビジネスサイドとのやりとりに使うこともでき、完了したバージョンが積み上がっていくため、達成感を感じることができます。

アジャイル開発の要素を取り入れたプラグインを入れてから、様々な情報の見える化が進みました。プラグインに興味をもつユーザが現れ、Redmineが周囲へも浸透していきました。なによりもチームのタスク管理能力が上がったように思います。

当時はバージョンアップごとに機能が増え、それにあわせてバージョンをがんがん上げていました。その影響か、ユーザはやがて1000人を超えます。頻繁なバージョンアップのために環境を改善し、できるかぎり自動化して対応しました。

1000人を超えたため、リアルサーバ＋Passengerへと切り替えました。

一番大きな問題として、RedmineのSVN連携で、SVN側に負荷が集中してダウンしたことがありました。たしかRedmineのコードに書かれていたタイムアウトが長く（たしか3分）、コネクションが積み重なってしまい、負荷へとつながっていました。

SVNだけでなく、JenkinsやReviewBoardなどもSVNに連携するため、SVN側をマスタ・スレーブにするなどの対応が必要になります。SVNにはスケールするための仕組みがあるので、それらの機能をうまく活用して、連携するシステム全体の増強を考える必要があることを学びました。

また、重い検索処理がRedmine全体を止めることがあったため、全体の検索機能は使えなくなりました。私の作った「All Time Teamプラグイン」もユーザが増えるとそうなる現象が発生しました。

コーチングの仕事の影響で、チームはタスクボードを活用するようになり、現在は、問い合わせ作業のみRedmineで運用しています。タスクボードの手軽さはあなどれません。

上のタスクボードでは、Doingのスペースを付箋２枚分しかとらないようにして、作業が誰かに偏らないように並行作業を制限しています。あとは写真をとってふりかえりなどで活用し、消化したタスクの傾向だけトラッキングしています。

私のチームはRedmineからはじめたて使いこなせるようになってきたので、タスクボードの手軽さは魅力ですが、張り出せない制限があったりするケースもあるはずなので、どっちがいいかというより、チームはどちらが好きか？で選べばいいと思います。

また、私のチームが使わなくなった理由として、Redmineで取っておきたい情報（問い合わせの履歴や外部とのやり取り）はRedmineを使う。開発に関する情報は、Subversionのコミットログや、リリースノート、簡単なマニュアルを書いたWikiがあれば十分だったため、ログが残らなくてもタスクボードで十分だったのです。

そして、最初は数人で始まったRedmineの現在へと進みます。

2011年秋ごろのデータです。ユーザは4000人を超え、2500ものプロジェクトが作成されています。

誰でもすぐ使えるようになったためユーザは急増。ただ、使いこなせているかどうかまではわかりません。私の感覚では、30％ぐらいのひとしか使いこなせていない気がしています。ここまでくると、開発の基幹システムと言えます。

ここまで大規模になった楽天のRedmine。たどった道のりを振り返ると、私のコンテキストからはいろいろな問題点も見えるようになりました。

まずは、簡単に使えてしまうという問題。簡単に使えるがゆえに、必要以上に使おうとする人が出てくるため、目的と手段の勘違いが発生し、非効率になってしまうことがあります。

次に、ルールの程度の問題。厳しいルールを始めに決めてしまい、ルールを守れない人が悪・・・という状況がチームを苦しめる場合もあります。大量の更新メールが開発者を襲い、「メール見ろよ」とかの衝突も生まれてました。

最後に、ユーザが増えたことで最適化が難しくなる問題。先に述べたような「全体検索停止」「負荷予測ができないためREST API停止」といった制限が生まれ、もともとあった柔軟性は徐々になくなり、「それなら独自で環境をつくろう」といった動きにつながります。Pluginが大量にインストールされ、大量のタブができてしまうこともあります。

ただ、それでもいいところはいっぱいあるため、どういった使い方をしていきたいのか？というビジョンを運営者側で持つ重要性が高まります。利用開始時のサポートや使い方のレクチャーも考えていく必要があります。ビジョンを達成できないのであれば、「ツールを使わない」という選択も必要になってきます。

楽天のRedmineの未来については、恐らく、私のチームがやっているように、やりとりのログが重要になる問い合わせなどで使われることが主流になっていく気がします。

環境面では、オープンソースソフトウェアで構成することも十分可能ですが、運用に○人コストを掛けるのであれば、ホスティングサービスのほうが安い場合もありえます。もしくは、クラウドサービスを使うことで個別最適化が進み、各自で独立した環境を作るケースが増えてくるかもしれません。

大人数で使う場合は、柔軟性ももちろんですが、「問い合わせならこういう使い方」「開発ならこういう使い方」というプロジェクトごとのテンプレートを作り、OSイメージを配る形で運用したほうが、開発者のためになりそうです。

最後に、どんなツールよりも対話するほうがコミュニケーションを取ることができます。アジャイルマニフェストにも「個人との対話」と書かれていますが、最近ではツールの進化が激しいので、プロセスやツールも軽視できない時代になってきたのではないかと思うようになりました。

私のチームでは、Redmine以外にもいろいろなツールを導入し、使い、捨ててきました。しかし、根本となる「ツールの使い方」「ツールを使う理由」への理解を深める事で、どんなツールに変化しても、対応できる柔軟性がチームに生まれました。ツールではなくチームが柔軟性を持ったのです。

最適なツールを最適に使いこなすことができれば、開発はより楽しくなります。Redmineはとてもいいツールだと思いますが、Goodなツールではなく、Excellentなツールへと育てるのが、導入や運用する側の仕事になってくるのではないでしょうか。

もし、今のRedmineがExcellentではなかったり、そうならないのであれば、ツールを再考する時期かもしれません。なぜなら、ツールを使い続けることが目的ではないからです。

Similar Posts:

• 楽天のRedmine事例を勉強会で発表します #47redmine #RxTstudy
• Redmineでプラグイン作ってたら「undefined method `plugins’ for Rails:Module (NoMethodError)」
• Redmineのロゴが決まったらしい
• Shibuya.trac第10回勉強会で初LTを体験しました
• ヌーラボさんのBacklogにできてRedmineにできないこと
• アジャイルなレビューをサポートするツールを5つ
• Redmineプラグイン開発 – パーキングロットチャートプラグインリリース
• Redmineプラグイン開発 – まずはHello Worldでしょ
• Redmineプラグイン開発 – プラグインの土台を作成
• RedmineのREST APIを使ってみる

アジャイル実践者研修 : Scrum Fine-Tuning using Organizational Patternsに参加した後輩からおみやげが届きました。Mountain Goatのプランニングポーカーもゲット。また、欲しいところに配ろうと思います。

翻訳されたScrum Tuning Using Organization Patternsを読みはじめました。Similar Posts:

• アジャイルな見積りに使えるプランニングポーカーを5種類並べてみた
• アジャイル実践者に大人気のプランニングポーカーの紹介
• 1/16（月）にJim Coplien 氏のアジャイル実践者研修が開催されます
• アジャイル実践者として持っておきたいアジャイルツールセット
• スクラムでつながる実践アジャイル – Scrum Boot Camp 横浜 #scrumbc
• アジャイルリーダーシップと組織改革 楽天のアジャイルを発表しました #devsumi
• アジャイルで目指した坂の上の雲 #DevLOVE HangarFlight – Snow Barrage – で発表しました #4tate
• Letter to an Agile Samurai – アジャイルサムライへの手紙 #agilesamurai
• アジャイルに結婚式準備を行うために必要なただ1つの方法
• DevLove Energized Work!に行ってきました

1/21（土）東京、2/4（土）大阪で、楽天のRedmine事例を発表する予定です。これまで培ってきた経験をあらいざらい共有できればうれしいなぁと思っています。なかでも、大阪で勉強会に行くのは初めてなので、とても楽しみにしています。

発表資料はまだ作成中なのですが、どちらの発表も導入初期から現在までの歴史や出来事を中心にお話させていただく予定です。資料は後日公開予定です。

第二回 shinagawa.redmine勉強会（東京）

タイトル：数千人が利用する楽天Redmineの過去と未来

参加登録は、第二回 shinagawa.redmine勉強会 ATNDからどうぞ。1/5現在、キャンセル待ちみたいです。Redmine人気はすごいですね。

Redmineが1000人のエンジニアに使われるまでのことにも書かせていただいたのですが、はじめは数人で使われていたRedmineも、すでに1000人以上が利用しており、なくてはならないツールへと進化しました。大規模になってしまったRedmineについて、運用/利用していた経験と、今思うことを共有させていただく予定です。

第3回RxTstudy（大阪）

タイトル：大規模Redmineを適用せよ

参加登録は第3回RxTstudy ATNDから可能です（懇親会はこちら）。こちらは、上限100人に変更されたのでまだ登録可能です！

RxTstudyでは、Redmineを使ったタスクマネジメント、プラグインを使った見える化や効果測定を中心に、導入したRedmineの歴史を共有させていただこうと思っています。どちらかというと3年使ったRedmineの使い方について共有したい10のことの拡張版になるかとおもいます。

おわりに

この2回の勉強会で、自分の知ってる情報はすべてまとめようと思っています。質問などがあれば、勉強会でも、懇親会でも、Twitterでもなんでもいいので、お気軽にご連絡ください。

当日お会いできることを楽しみにしております。Similar Posts:

• Shibuya.trac第10回勉強会で初LTを体験しました
• Redmineのロゴが決まったらしい
• Redmineでプラグイン作ってたら「undefined method `plugins’ for Rails:Module (NoMethodError)」
• 数千人が利用する楽天Redmineの過去と未来 #47redmine
• BacklogsプラグインをMac上のRedmineにインストール
• RedmineのREST APIを使ってみる
• Redmine0.9.0でredmine_chartsプラグインを動かしてやるぜ
• Redmineプラグイン開発 – 大豆プラグインがとりあえずできた
• Redmineにプラグインを入れるときに気をつけたいこと
• チームにRedmineを適用せよ！試行錯誤したツールとタスクマネジメント4年間の歴史 #RxTstudy

今年の仕事のことを考えているうちに、改めて「ソフトウェア開発ってなんだろう？」と思うようになった。

そして、ソフトウェア開発をする上で、「理想の環境というのはなんだろう？」ということを考え、今年はそれを目指そうと調べている。改めてWikipediaなどを読んでみると、いろいろな気づきがあり、一部の表現内容がとても偏っていることもわかった。

まず、Wikipediaのソフトウェア開発についての説明。

ユーザーのニーズやマーケティング上の目標をソフトウェア製品に変換する作業である。〜中略〜 ソフトウェア製品のマーケティング活動そのものは、必ずしも新商品開発とは結びつかない。

これはとてもいいまとめのように感じる。開発という中にいて周りを見ていると、エンジニアからの視点が強い人が多い。例えば、「Appleにあこがれる」「新しい技術を導入したい」といった、エンジニアの欲求に対しての視点だ。マーケティングの用語で言うとプロダクトアウトになるのだろうか？エンジニアのアイデアによって、製品やサービスを作るという形だ。

しかしながら、それだけでお金を稼ぐことは難しく、Wikipediaにもあるようにマーケティングの要素や、ビジネスサイドの考え方も必要になってくる。新サービスを作り続けることは大切な要素だが、その資金や時間を作り出すために、ビジネス視点や日々の改善作業は必要不可欠になる。

顧客の期待を満足させるべく開発されたソフトウェア製品の成功/失敗の責任が工学的側面にあるのかマーケティング的側面にあるのかを判別するのは、多くの場合困難である。そのため、ソフトウェア開発全体として工学的側面とマーケティング的側面を共に理解し、それらの協調を促進することが重要である。

私は、サービスを作っている会社に転職したことで、工学的な要素である「作り方」にこだわりたいタイプの人間なのだが、マーケティング的側面の重要性を感じるようになってきた。そして、工学とマーケの両方を理解することはとても難しいことも分かった。Wikipediaだと「プロジェクトマネージャのような人がバランスを取る」と書いてあるが、請け負う範囲が個人の裁量を超えるぐらい広いため、誰かがバランスを取るのではなく、全体でバランスを取る形がいいのかなぁと思った。

そして、問題のプログラマのページである。

恐らくこれを書いた人は、個人の視点で書いたように思える。なぜなら、共感するところはあっても、時と場合による所が多いからだ。これだとWikipediaのページとしては「不十分」と書かれても仕方ないように思う。例えば、

また、ソフトウェアに不具合が発見された場合、深夜残業や休日返上での修正作業をせざるを得ないこともある。

２４時間体制の仕事は他にもあるはずなので、プログラマだけの苦労ではない。

偽装請負や多重派遣を指すスラングとして、単に人材を他社に送り込むことで中間マージンを搾取することから「人売り」（人売りIT、人売り企業）、面談場所にたどり着くまでの間に営業担当者から他社の営業担当者へと次々と引き渡され連れ回されることから「ドナドナ」（ドナドナされる）などが存在する。

私も面談を経験したことがあるが、悲観的には思っておらず、ビジネスモデルの問題だと思っている。顧客といい関係を築いているならば、こうならないことも経験したので、これも悪い面だけがアピールされているのが残念だ。そして、中間マージンビジネスはもう難しいビジネスなので、経営者は早く見直さないと、企業はゆるやかに死へと進んでいくだろう。

そして、「格差社会におけるプログラマ」について。

頭数として利用される立場である以上、プログラマ自身のアイデンティティに対する価値は最初から全く期待されておらず、肉体の能力や精神的な意欲の低下が顕著となる３０代後半以降の局面を以って職業を継続する事が困難な状況に陥る傾向がある。本来は知的労働者であるべきプログラマが、そのアイデンティティを無視されたままに、年齢や怪我による主に肉体的な能力の低下を理由として簡単に使い捨てられる日本の常識的な産業構造を揶揄する意味でIT土方という言葉や新3Kという言葉はあまりにも有名であり、・・・

たしかにそういう面はあると思う。が、悪い面のみを書いているので悪く見えてしまうのが悲しい。

改めて調べてみると、いろんな見方があることがよくわかる。「SIerはオワコン」という言葉がよくタイムラインを流れていた時期もあるが、SIであろうが、サービス開発であろうが、どこも似たような問題を持っている。一部の問題に対して、全部が悪であるような言い方は個人的に好きではないし、そんなことしていても世の中が良くなる気がしない。そんな暇があったらプログラムを書いたほうがいい。

Wikipediaの先頭に「プログラマはクリエイティブな仕事である」と書いておこうかなと思った。

これ以外にも、システムエンジニアのページや、デスマーチの定義が面白かった。

• システムエンジニア – Wikipedia
• デスマーチ – Wikipedia

Similar Posts:

• 偉大なるリーダーシップ – ハーバード・ビジネス・レビューにスクラムが登場
• ソフトウェアを完全内製で作るのと外注やベンダー製品を採用する判断はどこでする？
• いつものミーティングをアジャイル開発手法「スクラム」で再設計した感想
• 詳説！Redmineを使ったスマートな開発プロセス改善（画面キャプチャ付き）
• ヌーラボさんのBacklogにできてRedmineにできないこと
• 半年間のアジャイル開発をタスクボードでふりかえる動画！XP祭り2011LT資料 #xpjug
• 1/16（月）にJim Coplien 氏のアジャイル実践者研修が開催されます
• 富士登山で使ったものリスト（2009年8月21日登山）
• ソフトウェア開発プロジェクトはプロダクトビジョンを満たしているか？ #devsumiの宿題
• WebLogic9.2でオートデプロイ

1/16（月）にアジャイル実践者研修が開催されます。詳細は、アジャイル実践者研修 : Scrum Fine-Tuning using Organizational Patterns (東京)をご確認ください。10・11日には大阪でプロダクトオーナー研修。10日の夜はScrum Meetupという名の新年会も開催されます。年初からアジャイル尽くしです。

講師のJim Coplien氏については、Wikipediaにエントリがあり、こう書かれていました（適当訳）。

James O. “Jim” Coplien (Copeとして知られているかもしれない)は、コンピューターサイエンスというフィールドで活躍する本の著者、講演者、リサーチャです。彼は、豊富なリサーチ経験を元に、ソフトウェアデザイン、組織開発、ソフトウェアデバッグといった領域で、重要な貢献をしています。 via Wikipedia

Scrum FoundationにもBIOがあり、それをふまえると、アーキテクチャパターンや、ソフトウェア開発における組織開発（開発というところが面白い）の第一人者なんですね。

今回は研修に、西村直人さん、角谷信太郎さん、和智右桂さん、高橋亜紀子さんといった方々もサポートではいるようですので、より深い研修になる気がしています。

アジャイル実践者向けの研修はめずらしいので、ご興味があればぜひどうぞ。Similar Posts:

• アジャイル実践者研修のおみやげが届きました
• アジャイル開発のバーンダウンチャートはもう古い？！2012年からは「にゃーんダウンチャート」へ
• #DevLOVE HangarFlight Snow Barrageで楽天のアジャイル導入を語ります
• アジャイル実践者として持っておきたいアジャイルツールセット
• 明日のデブサミ2012で「アジャイルリーダーシップと組織改革」を発表します #devsumi
• Letter to an Agile Samurai – アジャイルサムライへの手紙 #agilesamurai
• Agile India 2012 が2/17から3日間開催！#agileindia2012
• 16人のアジャイル署名者がAgile2011で再会 – Attendee Conference Guideより
• デブサミ2012から感じたアジャイルの10年と未来 #devsumi
• [適当翻訳] 大規模Agileの形を表現したAgile Enterprise Big Picture

Agile India 2012が来月2月に開催されます。

Linkedinのグループに投稿されたメッセージを読むと、アジア最大規模のアジャイル系イベントになるようです。

プログラムを見ると、12のステージ・同時7トラックになっており、かなり大きなイベントのようです。ステージも最近の話題を取り込んでおり、以下のような魅力あるステージになっています。

• リーダーシップと組織変革
• エンタープライズアジャイル
• アジャイルとアウトソース
• アジャイル開発プラクティス
• DevOps
• 文化、個人とチーム
• リーンの原則とプラクティス
• アジャイルプロダクトマネジメント
• コーチとメンター
• リーンスタートアップ
• リサーチカフェ
• ライトニングトークス

Agile2012でも分散アジャイルがステージになっているように、インドでもアウトソースのステージがあります。海外はもうアウトソーシングまで考えたアジャイル開発が主流なんでしょうか。

また、DevOpsやリーンスタートアップといった最近のトレンドを取り入れたステージや、リーンに特化したステージと、世界のカンファレンスを見ていると、今年のトレンドも見えてくるように思います。

ライトニングトークスはもう世界に通じるステージなのかな？Similar Posts:

• 明日のデブサミ2012で「アジャイルリーダーシップと組織改革」を発表します #devsumi
• 1/16（月）にJim Coplien 氏のアジャイル実践者研修が開催されます
• Agile 2011にやってきた
• [適当翻訳] 大規模Agileの形を表現したAgile Enterprise Big Picture
• Agile2012サイトがオープン！参加登録、発表募集も開始 #agile2012
• Agile2011の開催概要から登録方法まで – Attendee Conference Guideより
• アジャイル実践者として持っておきたいアジャイルツールセット
• アジャイルサムライ著者ジョナサン・ラスマセン氏から #DevLOVE へのメッセージ動画
• さぁ、始まりの場所に帰ろう – Agile 2011 マニフェスト署名者たちのセッション
• アジャイル実践者研修のおみやげが届きました