★テーマ
アジャイルリーダーシップと組織改革 ～楽天のアジャイル開発というリアル～
●スピーカー
楽天株式会社
藤原 大氏
●楽天という会社について
カンパニー制
開発部は一つ
エンジニア1000人
グループ70個
プロジェクト1000個／年
開発はウォーターフォールベースでやっている。
フェーズ必ず守らなければならないわけではなく、作業を進める参考程度にスケジュールが組まれている。
●アジャイルを導入し振り返って思った事
初めは２００９年くらいにアジャイルを３人で導入した
そもそも大企業でやっているウォーターフォールモデルを、
WebベンチャーのBtoCで真似するのが間違いだと思っている。
エクストリーム・プログラミング
ペア・プログラミングとCI
1つの作業を1人に任せてしまうと、誰か倒れて作業が止まってしまうと終わりなので、
ペアプロで内容を共有することにした
○当時の規律
・まかせる
・チェックはする
・攻めの選択をする
導入して３ヶ月くらいで成果が見えた
導入前は１００h／月くらいのボリュームで
バグ、調査、トラブルの対応をしていた。
導入後は調査、運用、開発で、開発の割合が上がってきた。
○朝礼
毎日朝礼を行う事によって、メンバー間での情報の共有を行った。
進捗の報告と、ホワイトボードに各人のタスクを貼り、作業の見える化をはかった。
○CI
CIを導入し、テストも自動化した。
これによりテストもしっかりとするようになり、開発全体に対するUTの割合が前は10%程度だったが、
40%くらいまで上がった。
テストをしっかりする分、リリーススピードは少し遅くなるが、
後の運用が安定するため、開発に力をそそげるようになった。
新規機能のリリース等も早く出来るようになり、長くやるほど元が取れる。
●アジャイル
CI
自動化
これによって時間を作り、その時間を開発にそそぐ。
単純作業はスクリプトを作って自動化していくと、時間を作れる。
現場では、テストが大事なことは分かっているが、忙しくてやってられないことがある。
自動化することによって、その問題も解決出来る。
○他部署との連携
他部署と連携が必要な作業に関しても、同じ手法を導入した
QAにCIを注入
プロセス改善
育成協力
と導入してみたが、結果的には失敗だった。
お互いに忙しかった事もあり、一緒にやってる感が全くなく、導入を徹底出来なかった。
○プロセスや標準化
同じ作業や選択
効率を上げる
同じ状況を想定
○技術的負債
レガシーコード
古い技術
ヘビーな運用
技術者が他所の勉強会等で、クラウドなど新しい技術を他社で使っている事を知って、
自分のところはこんなことをやっていてまずいという不安に陥ったりする。
開発が好きな人間ほど、他所とのギャップで不安になりやすい。
○様々なアジャイル、勘違いのアジャイル、クラジャイルが多い
今の普通を全否定する。
・テストのないプログラムがリリースされても「動いているから正しい」と考えている状況も多くあるが、
「動いているから正しい」という考え自体が間違っている。
・何をするにも上からの承認が必要なプロジェクトもあるが、無駄な承認に時間、労力を割く必要は無い。
●他の開発現場に行ってアジャイル開発を伝えた時の話
○現場の課題
エンジニア急増（若手を中心にやっている）
育成不足
レガシーコードの存在
○朝礼
朝礼を始めた（思っていることを発言させる場を作る）
少しでも時間に遅れたら発言させないという厳しさを持って、朝礼への参加を徹底させた。
○見える化
朝礼の際に張り出す事で、一緒にやっているメンバーに共有する
横やりの作業もどのくらいあるのかとか
積極的に勉強会等にも参加させ、モチベーションを上げさせた。
○良かった点
スピード感があった
楽しく作業出来ていた
みんなで解決ながらやっていて、チームに一体感が生まれた
それまで横やりの作業で時間を取られたりする事が多かったが、
横やりの作業に優先度付けをしっかりすることにより、それを解消した。
結果、開発に割く時間の割合が6倍に増えた。
それまではちょっとくらい、と思ってやっていた作業がすごく邪魔になることが分かった。
最終的には
カバレッジ98％
バグ0.02％
を実現した。
○いまいちだった点
導入まで3ヶ月の準備期間を取られた
ビジネスへの展開
プロジェクトを離れてしばらく経つと、元の状態に戻っていた
●リーダーシップと組織開発
○アジャイルで組織は変わるのか？
マネージャはチームに関与せず、マネージャとリーダーで連携しているだけ
マネージャーが介入してくると、チームで話し合って考えたことが
すべてマネージャの一言でひっくり返ってしまい、モチベーションも落ちて失敗する。
1年で２０人くらいはアジャイルに巻き込めていた。それだけでは組織改革とは言えない。
仲間にした２０人を後押しして、さらにその人たちが２０人を仲間にしていけば、
1年で４００人増やす事ができる。
そこまでいけば、組織開発したと言える。
○アジャイルのリーダーに必要なこと
1つのチームとして一体感を持って仕事をして、みんなで一つの目標に向かって行く。
全員で問題を共有したり、チームの問題としてとらえさせたりすることが大事。
従来のリーダー中心の考え方ではなく、チーム中心の考え方をする。
チームを勇気づけることも必要。
客員一層奮励努力せよ！
チームのメンバーへ応援を送ったりして、チームを奮い立たせる。
終わった後に「楽しかった」と言われることも多い。
●感想
ここ1年半くらいやっている開発が、アジャイルに近いものだったので興味深い内容が多かった。
残念ながらここでいう「勘違いのアジャイル」に含まれることも多い気がするので、一度分析してみたい。
そして一エンジニアの立場からでも、活かせる部分はどんどん取り入れるようにしてみたい。
また、今後自分がリーダーとしてアジャイル開発のプロジェクトを仕切る事になった時には、
是非思い出して実践してみたい内容だった。
アジャイルリーダーシップと組織改革 ～楽天のアジャイル開発というリアル～
●スピーカー
楽天株式会社
藤原 大氏
●楽天という会社について
カンパニー制
開発部は一つ
エンジニア1000人
グループ70個
プロジェクト1000個／年
開発はウォーターフォールベースでやっている。
フェーズ必ず守らなければならないわけではなく、作業を進める参考程度にスケジュールが組まれている。
●アジャイルを導入し振り返って思った事
初めは２００９年くらいにアジャイルを３人で導入した
そもそも大企業でやっているウォーターフォールモデルを、
WebベンチャーのBtoCで真似するのが間違いだと思っている。
エクストリーム・プログラミング
ペア・プログラミングとCI
1つの作業を1人に任せてしまうと、誰か倒れて作業が止まってしまうと終わりなので、
ペアプロで内容を共有することにした
○当時の規律
・まかせる
・チェックはする
・攻めの選択をする
導入して３ヶ月くらいで成果が見えた
導入前は１００h／月くらいのボリュームで
バグ、調査、トラブルの対応をしていた。
導入後は調査、運用、開発で、開発の割合が上がってきた。
○朝礼
毎日朝礼を行う事によって、メンバー間での情報の共有を行った。
進捗の報告と、ホワイトボードに各人のタスクを貼り、作業の見える化をはかった。
○CI
CIを導入し、テストも自動化した。
これによりテストもしっかりとするようになり、開発全体に対するUTの割合が前は10%程度だったが、
40%くらいまで上がった。
テストをしっかりする分、リリーススピードは少し遅くなるが、
後の運用が安定するため、開発に力をそそげるようになった。
新規機能のリリース等も早く出来るようになり、長くやるほど元が取れる。
●アジャイル
CI
自動化
これによって時間を作り、その時間を開発にそそぐ。
単純作業はスクリプトを作って自動化していくと、時間を作れる。
現場では、テストが大事なことは分かっているが、忙しくてやってられないことがある。
自動化することによって、その問題も解決出来る。
○他部署との連携
他部署と連携が必要な作業に関しても、同じ手法を導入した
QAにCIを注入
プロセス改善
育成協力
と導入してみたが、結果的には失敗だった。
お互いに忙しかった事もあり、一緒にやってる感が全くなく、導入を徹底出来なかった。
○プロセスや標準化
同じ作業や選択
効率を上げる
同じ状況を想定
○技術的負債
レガシーコード
古い技術
ヘビーな運用
技術者が他所の勉強会等で、クラウドなど新しい技術を他社で使っている事を知って、
自分のところはこんなことをやっていてまずいという不安に陥ったりする。
開発が好きな人間ほど、他所とのギャップで不安になりやすい。
○様々なアジャイル、勘違いのアジャイル、クラジャイルが多い
今の普通を全否定する。
・テストのないプログラムがリリースされても「動いているから正しい」と考えている状況も多くあるが、
「動いているから正しい」という考え自体が間違っている。
・何をするにも上からの承認が必要なプロジェクトもあるが、無駄な承認に時間、労力を割く必要は無い。
●他の開発現場に行ってアジャイル開発を伝えた時の話
○現場の課題
エンジニア急増（若手を中心にやっている）
育成不足
レガシーコードの存在
○朝礼
朝礼を始めた（思っていることを発言させる場を作る）
少しでも時間に遅れたら発言させないという厳しさを持って、朝礼への参加を徹底させた。
○見える化
朝礼の際に張り出す事で、一緒にやっているメンバーに共有する
横やりの作業もどのくらいあるのかとか
積極的に勉強会等にも参加させ、モチベーションを上げさせた。
○良かった点
スピード感があった
楽しく作業出来ていた
みんなで解決ながらやっていて、チームに一体感が生まれた
それまで横やりの作業で時間を取られたりする事が多かったが、
横やりの作業に優先度付けをしっかりすることにより、それを解消した。
結果、開発に割く時間の割合が6倍に増えた。
それまではちょっとくらい、と思ってやっていた作業がすごく邪魔になることが分かった。
最終的には
カバレッジ98％
バグ0.02％
を実現した。
○いまいちだった点
導入まで3ヶ月の準備期間を取られた
ビジネスへの展開
プロジェクトを離れてしばらく経つと、元の状態に戻っていた
●リーダーシップと組織開発
○アジャイルで組織は変わるのか？
マネージャはチームに関与せず、マネージャとリーダーで連携しているだけ
マネージャーが介入してくると、チームで話し合って考えたことが
すべてマネージャの一言でひっくり返ってしまい、モチベーションも落ちて失敗する。
1年で２０人くらいはアジャイルに巻き込めていた。それだけでは組織改革とは言えない。
仲間にした２０人を後押しして、さらにその人たちが２０人を仲間にしていけば、
1年で４００人増やす事ができる。
そこまでいけば、組織開発したと言える。
○アジャイルのリーダーに必要なこと
1つのチームとして一体感を持って仕事をして、みんなで一つの目標に向かって行く。
全員で問題を共有したり、チームの問題としてとらえさせたりすることが大事。
従来のリーダー中心の考え方ではなく、チーム中心の考え方をする。
チームを勇気づけることも必要。
客員一層奮励努力せよ！
チームのメンバーへ応援を送ったりして、チームを奮い立たせる。
終わった後に「楽しかった」と言われることも多い。
●感想
ここ1年半くらいやっている開発が、アジャイルに近いものだったので興味深い内容が多かった。
残念ながらここでいう「勘違いのアジャイル」に含まれることも多い気がするので、一度分析してみたい。
そして一エンジニアの立場からでも、活かせる部分はどんどん取り入れるようにしてみたい。
また、今後自分がリーダーとしてアジャイル開発のプロジェクトを仕切る事になった時には、
是非思い出して実践してみたい内容だった。