読者です 読者をやめる 読者になる 読者になる

アジャイルサムライ読書会 横浜道場 特別編 「アジャイルは組織を変えられるのか」に参加してきました。

7/19(水)にアジャイルサムライ読書会 横浜道場 特別編 「アジャイルは組織を変えられるのか」に参加してきました。
f:id:tenten0213:20120728160513p:plain

横浜道場は初参加でした。
Developers Summit 2012での楽天の藤原さんの発表を聞いて凄い感動したので、もう一度聞きたかったのが一番の動機です。
もうあれから半年近く経ったんですね。
Developers Summit 2012が初めて参加した社外の勉強会(というかイベントか)だったんだよなーと思うと感慨深いものがあります。

Developers Summit 2012に参加しての感想はコチラ↓
Developers Summit 2012 初参加しての感想 〜情熱を取り戻せ - Confront my ignorance


タイムボックス

19:00 開場
19:30-19:35 オープニング
19:35-20:20 「アジャイルリーダーシップと組織改革 ~楽天のアジャイル開発というリアル~」 @daipresents
20:20-20:50 (A)ディスカッション(ワールドカフェ + 発表)
21:50-20:55 休憩 & 席替え
20:55-21:25 「アジャイルペーペーシップとチーム改革 ~楽天のアジャイル開発というリアル another story~」 @TAKAKING22
21:25-22:55 (B)ディスカッション(ワールドカフェ + 発表)
21:55-22:00 クロージング
22:00-23:00 ビアバッシュ


アジャイルリーダーシップと組織改革 ~楽天のアジャイル開発というリアル~

今回の発表は、前回の発表の後のお話をエピローグという形で追加したバージョンでした。


約半年ぶりに発表を聞きましたが、当時とはまた異なる感じ方ができ、考えさせられる内容でした。
前回も思ったのですが、色々な数値を計測していて、それを見える化したり振り返りに使っているのはとても参考になります。
上司に説明(説得)するときや、チームでの振り返りの際などにも定量的に増えている、減っていることがわかるとモチベーションにも繋がりそうです。

XPの導入

閉塞感のあるチームに対してXPを導入するのは良さそうに感じました。
ペアプロやペア作業を行うことでコミュニケーションが自然と緊密になるし雰囲気の改善にも繋がりそうです。
テストファーストの考え方や、テストの量についてはSIでも課題になりがちに思っています。
現在のPJではカバレッジを重視してはいますが、必要なテストが足りていなかったり、通らないテストが作られていたりな感じです。(絶対テストファーストじゃない…)
ここらへんは、工数見合いになりがちですが、発表の内容のように、見える化を行い効果を説明することで、導入出来たり、メリットが伝わるのかな?自分自身の課題です。
機会があれば、自分だけ(もしくは一部で)コッソリTDDを行ない、メリットを伝え、導入まで持って行きたいですね。
発表の「裏切る コッソリ」ってところで笑ってしまったのですが、覚悟とか信念を感じて好きです。

CIについて

>アラームが止まらない。
胸が痛いです…
パートナーに開発を委託していると、ビルドの失敗を無視してでも開発を進めてしまう傾向があるように感じます。
(進捗率であったり、Step数で生産性を計られたりする為)
ここも、どうやってマインドを伝えるか、ビルドを綺麗に保つことが重要かを伝えるかが重要で、難しそうです。

新人研修の話

凄い共感しました。
自分自身も新人研修で開発演習を行ったのですが、カンバンを使った進捗管理や、定期的な振り返り、朝回、チームビルディングなど色々取り組んでいましたし、業務を含めても一番うまくいった開発だった気がします。
今思うと、あんな雰囲気でもう一度開発がしたいというのがアジャイルに強く惹かれたキッカケなのかもしれません。

あ、でも研修なのにバーサーカーと化していたタイミングがあったのは反省ですね。(土曜日も出社してました…)

技術的負債

金融系のPJにいるためか、古い技術を使う機会であったり、レガシーコードと出会う機会は多々あります。
2年前はメインフレームも少し触りましたし、Cobolも書いたりしました。
最近はCobolUnitなるものがあるので、レガシーコードから脱却しようと思えば出来るんですかね…

そんな中で、Seasar2ベースのFWや、Jenkins、Redmineのような割りと新しめな技術にチャレンジする機会にも恵まれたのは、幸運だったのかなと思います。
今は、PJで開発中のコードがレガシーコード化しないように奮闘中です。

アジャイル

私自身はアジャイルで開発をしたことはありませんが、デイリースタンドアップミーティング、プランニングポーカー、CI(うまくいってない)、チケットなどのプラクティスは導入しています。
ただ、プラクティスを導入すればそれでOKでは無く、背景にある意図や思いをしっかり伝えてチームが理解していないと運用がうまくいかないですね。

発表で、何度失敗しても諦めない姿勢には勇気づけられましたし、打開するヒントが随所にあったようにも思えます。

特に、以下の2つの言葉が印象的でした。
今後、意識していきたいと思います。

・俺、私を使わず、”我々”を使う
・同じ方向を見る


アジャイルペーペーシップとチーム改革

楽天さんは人材が豊富ですねぇ…
発表がうまくて面白かったです。

内容は、組織変革の話と、DevLoveで以前発表した「私がスクラムをやめた理由」の再演でした。
自分がアジャイル開発の経験が無い為、王道も、覇道も邪道も経験したことが無いのですが、継続的に改善を行なっていくことが重要だと改めて気付かされました。
自分が変わることで周りが変わっていき、ついには深刻な壁不足になるまでになったというエピソードがとても印象的でした。
きっと仁義なき壁争いが繰り広げられているのでしょう…楽しそうだなぁ(笑)


最後に

アジャイルサムライ読書回 横浜道場スタッフの皆様、発表してくださった、@daipresentsさん、@TAKAKING22さんありがとうございました!
また、初参加なのにもかかわらず、じゃんけんで勝利し「Gitポケットリファレンス」を頂きました!

「Gitポケットリファレンス」の書評はブログで近々書かせて頂きます。
ありがとうございました!

Gitポケットリファレンス

Gitポケットリファレンス