« 日本のSIでは生産性を上げても、はかどっていないような仕事ぶりをする | トップページ | DevOps時代の必読本「チーム開発実践入門」 »

2014/06/05

スクラムを大規模組織へ導入した事例

アメーバ事業部が混乱から立ち直ってスクラム導入を成功させるまでという記事が素晴らしかったのでメモ。

【元ネタ】
アメーバ事業部が混乱から立ち直ってスクラム導入を成功させるまで(前編)。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のパターン』のように、大規模組織にどのようにアジャイル開発を取り入れると上手くいくのか、成果が出るのか、というノウハウもパターン化されて公開されている。
その意味では、アジャイル開発導入の敷居はすごく下がってきているような気がしている。

|

« 日本のSIでは生産性を上げても、はかどっていないような仕事ぶりをする | トップページ | DevOps時代の必読本「チーム開発実践入門」 »

コメント

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



« 日本のSIでは生産性を上げても、はかどっていないような仕事ぶりをする | トップページ | DevOps時代の必読本「チーム開発実践入門」 »