スクラムを大規模組織へ導入した事例
アメーバ事業部が混乱から立ち直ってスクラム導入を成功させるまでという記事が素晴らしかったのでメモ。
【元ネタ】
アメーバ事業部が混乱から立ち直ってスクラム導入を成功させるまで（前編）。QCon Tokyo 2014 － Publickey
アメーバ事業部が混乱から立ち直ってスクラム導入を成功させるまで（後編）。QCon Tokyo 2014 － Publickey
『Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン』 - delirious thoughts
(引用開始)
組織の課題としては、増え続けるサービスの品質を担保したい、そして中央集権的な管理から自律的なチームにすることで改善スピードをどんどん上げていきたい、ということがありました。
そこで出てきたのが、「スクラム」という言葉です。
この頃には役員陣も興味を持ち始めてくれるようになり、ブログで「ハッカーと画家」とか「アジャイルサムライ」といった本を読んだことを書いたりしていて、アジャイル開発を議論できる空気になってきました。
(引用終了)
社長のような経営トップがアジャイル開発に興味を持ってくれるとすごく導入しやすい。
アジャイル開発とは何か、アジャイル開発を入れるとどんな利点があるか、を逐一説明する手間を省ける。
アジャイル開発を自社に入れる場合、ゴールをどこに置くか、どんな戦略で入れるか、という議論へすぐにたどり着ける。
『Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン
個人的に思うのは、経営トップほど最新の情報を知っているので、アジャイル開発も当然知っていること。
むしろ、管理職の方が最新の開発トレンドを全く知っておらず、10年前の技術や管理手法で対応しようとして、少しずつ現状とずれてきている。
上記資料で興味深い点は、組織へ導入するTipsだ。
【Tips1】組織を丸ごと変えてやるのは失敗する。真似てもらう。
アジャイル開発は、メンバーの自立化を前提にしている。
だから、強制するのはアジャイル開発と自己矛盾している。
しかし、そのままの状態で放置しても、アジャイル開発は導入されない。
そこで、一つの組織でScrumを導入して成功させ、その成功事例を口コミで広げて、他チームに真似てもらうようにしたこと。
そして、勉強会で広げたこと。
『Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン
【Tips2】また、組織の目標とアジャイル開発が競合するという課題もある。
組織には、売上目標や戦略的な目標があり、それによって成績評価される。
組織目標にアジャイル開発が役立つという説明理由を持っておかなくてはならない。
そのために、アジャイル開発を導入すると、開発の生産性も上がるし、社員の技術力向上やマネジメント能力向上にもなりますよ、とアピールするための準備が必要になる。
成功したと結果が出れば、風見鶏のように管理職も応援してくれる。
その準備の一つがパターンを用意すること。
自動化、チーム内での分割、タスクの粒度とWIP（Work in Progress：仕掛かり）の制限、ストーリーの直列化、ペアプログラミング、バックログ、バーンダウンチャートなど。
チーム内の分割は、『Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン
留意すべき点は、それらパターンが全てのチームに当てはまるわけではないこと。
自動化は開発環境の整備なので、全チームに当てはまるだろうが、チームの種類に応じて、パターンの適用を変えてみるわけだ。
チームには、営業マンもいれば、デザイナー、Webディレクター、インフラ担当者など、それぞれの作業内容は異なるし、チームのカラーも違う。
試行錯誤しながらパターンを試して、改善していく。
こんな事例を見ると、Webサービスなど最新のIT技術や開発プロセスを取り入れなければいけない危機感を持つ会社と、日本の製造業や農業のように古い装置産業の会社は全然違うのだろうと思ったりする。
そして、『Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン
その意味では、アジャイル開発導入の敷居はすごく下がってきているような気がしている。
| 固定リンク
コメント