#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旗
    • 「客員一層奮励努力せよ」
    • この号令が全員を奮起させた
  • チームにがんばれ、頑張れと言い続ける仕事だった
  • 最終的に相手を信じてまかせるのが一番いい
  • アジャイルやってると社内にも仲間ができるが、社外にも、海外にも仲間ができる