#devsumi 2012 アジャイルリーダーシップと組織改革 ~楽天のアジャイル開発というリアル~ メモ
アジャイルリーダーシップと組織改革
- 楽天 藤原さん
- @daipresents
- 職業
- プログラマ、リーダー、コーチ
楽天の紹介
- 楽天にはたくさんサービスがある。カンパニーで、開発部は1つ
- 開発部隊を支援する部署に所属
- 標準化、PHPだったりJavaだったり
- ツール、subversion とか Redmine のようなツール
- アジャイル
- エンジニアは1000人以上、グループ数が70くらい、プロジェクトも1000以上
- 社内の開発プロセスはウォーターフォールがベース
- 厳守しなくてはいけない、というわけではない。言い換えれば楽天という会社には開発プロセスはない
アジャイルを導入してみたところ
- 最初は2009年、藤原さんを含めて3人
- チームのモチベーションがあまり高くない状況、閉塞感があってミーティングでもネガティブな話が多かった
- まずはじめにXPを導入してみた
- 「XP エクストリームプログラミング入門」本を買って、やってみた
- ペアプロを始めた
- 3人しかいないから、リスクヘッジも目的
- レガシーコード改善のため、CIを導入
- テストがなかったりするので。テストの無い文化にテストを導入するのは難しい
- テストすることでリリースが遅れることを懸念した上司に「どこまでやるの」と言われて「最低限やりましょう」で決着させたが、最後で裏切った
- 上司が正しいとは限らないじゃないですか
規律
- まかせる
- チェックはする
- チェックポイントは決める
- 週一回のマネージャーの報告とか、朝会とか
- 攻めの選択をする
- 一つの判断が、全部署について正しい判断とは限らない。とか言っているとなかなかよくならない。
- リスクありきでどこまで攻めるかを考えましょう
工夫したこと
- 「それはロックか?」
- もっとロックなことやっていきましょうよ!
- 時間
- 開発の時間を確保するため、ライブラリを作った。ライブラリ数が当初比3.5倍
- 月に100時間くらいは開発以外の作業をしていた
- Unit Test の割合
- 40%くらいがテストの時間に。初期のリリースまでの時間が長くなった気がする
- が、楽天のビジネスはリリースして終わりではない。サービスが続く限り作業が続く
- なので、リリースしてから「過去のテストがあってよかった」が生きてくる
- 運用が長く続けば続くほど、テストの価値が高くなる
アジャイル開発を展開してみたところ
- アジャイル、CI、自動化を社内に展開
CIのアラートメール数
- 成功したチーム
- 最初は下がるんだけど、コミットした瞬間に増える。それがまた下がる
- ビルドを安定させようとする意思が感じられる
- 失敗したチーム
- 質の悪いコミット文化が根付いている
- アラートメール数のグラフが下がらない、横ばいになる
自動化の効果
- Capistrano を使った。時間が75%削減できた
- 自動化の広がりは最初は早かったが、徐々に普及速度が遅くなった
- 始めてみたけど、難しかったとか
結果
- CIも自動化も全然浸透しなかった
- アジャイルも浸透しないんじゃないか?と思った
- 新人研修でがっつりやってみた
- 60+ 人の新人でやったら、できちゃった。もしかして、老害?
やり方を変えていった話
- 他部署と連携
- QAにCIを連携
- プロセス改善
- 育成協力
- 社内にスクラムマスターを増やしましょう
結果
- うまく行かなかった
- 一緒にやっている感がない
- 部署は隣同士なんだけど、レポートラインも目標設定も違う。連携がしにくかった
- 一緒に働くってのが難しい、というのを実感した
- 自分のやっていることを2010年くらいに整理してみた
やっていることを整理して考えなおした
- 工場 vs 創造
- 楽天のビジネスは工場的な要素が強かったので、ソフトウェア開発があるべき「創造」の方に引っ張っていく方が良いのではないか、と思った
- 乱立アジャイル
- 社内に色々あった
- 勘違いアジャイル、ひどいアジャイルもあった
- 軽い気持ちで導入した人が失敗して「アジャイル使えない」という評価がされてしまうのが嫌だった
- アジャイルが残念になる前に、成功事例を作ることにした。そのために、今までの普通を全否定することに
今までの普通を全否定
- その承認プロセスは本当に必要?効率的?
- 楽天主義
- コップに半分の水 → もう半分しかない、か、まだ半分残っている、か
- 新技術は積極的に導入していきましょう
- アジャイルは本気でやりましょう
- 積極的にチャレンジしてきましょう
- 現場にアプローチしても伝わらないので、現場でアプローチする。見えないなら見に行けばいいじゃない。
現場に行ってみた
- ほとんどが新人と若手、教育が行き届いていない
- レガシーコード山盛り
やってみたこと
- 朝礼。ちょっとでも遅れてきたら発言させない
- 自分に関係しそうな所に耳を傾けるようになったり、だんだん慣れてくる
- 見える化
- イベントに積極的に参加させる
- 外に出て行って、会社とのギャップをどんどんフィードバックさせた
良かったこと
- スピードが上がった
- 楽しかった
- 一体感があった。他部署との仕事で一体感がここまで感じられるとは思わなかった
定量評価
- 開発時間が6倍に
- つまり、それまでは優先順位付けができていなかった
- 横槍の作業が多かった。プロジェクトに集中することができた
- ちょっとくらいならいいよね、がものすごく邪魔
- カバレッジ 98%、バグ 0.02%
- 後でやればいいじゃん、がやらなくてよくなった
- 問題点
- 3ヶ月の準備期間
- ビジネスへの展開
止まった
- もともと問題があったから改善したが、元に戻ってしまった
- アジャイルでもウォーターフォールでもなんでもいいんだけど、改善しようということをやらなくなった
- 失敗から学んで、再度チャレンジした
- 現場改善の熱意は人を変えて人を育てる
リーダーシップと組織改革を考えた
アジャイルは組織を変えられるか?
- マネージャーが介入してこない形、が重要
- 介入してくるマネージャーだと失敗する
- チームでやっていることが、マネージャーによってひっくり返されてしまう
- 楽天に1000人エンジニアがいる。1年で20人どうにかするのは、組織改革じゃぁない。全部変えるのに半世紀かかる
- 今年は20人を支えて、ねずみ算式に増やして行けばいいんじゃん、という考え
- 自分はやるけど、相手には求めない
- ファシリテーションスキルが、アジャイルリーダーには必要なんじゃないか
- Agile leadership model という資料に色々まとまっている
- servant leadership
- self organize
- flat
- empowered
- self directed
- merit based
- チームを勇気づける (empowered) は共感できるところ
一番伝えたいこと
- チームを勇気づける、ってのが一番重要
- 表紙の写真は横須賀にある三笠のマスト
- Z旗
- 「客員一層奮励努力せよ」
- この号令が全員を奮起させた
- チームにがんばれ、頑張れと言い続ける仕事だった
- 最終的に相手を信じてまかせるのが一番いい
- アジャイルやってると社内にも仲間ができるが、社外にも、海外にも仲間ができる
コメント