巨大な縦割り組織の中のほんの一部でアジャイルやってみた（導入編）

こんにちは。Agile Studioの岡島一樹です。

今回から新シリーズです。全3回ぐらいを予定しています。

「巨大な縦割り組織の中のほんの一部でアジャイルやってみた」

ということで今回は導入編です。

巨大なウォーターフォールプロジェクト

この話は私が先日まで携わっていたプロジェクトのお話になります。

このプロジェクトはとても巨大で、私自身も2年間在籍していたにも関わらず

全体像がよく分からないほどでした（笑）

ざっくりプロジェクト体制の絵を描いてみました。

こんな感じで縦割りのチームが何チームも存在しています。

チーム間のコミュニケーションはQA表を作ったり、Redmineのチケットを発行したり、

チャットを使用したり様々です。

プロジェクト全体の開発手法はいわゆるウォーターフォールです。

設計部隊と実装部隊が分かれていて、設計部隊が設計した内容で

実装部隊が実装&単体テストを実施するという流れになります。

各チームのリーダーがスケジュールを作成し、ガントチャートを引いて

スケジュールを管理していきます。

フロントエンド開発チーム

ところが私が所属していたフロントエンド開発チームの中で、

スケジュールを立てられないチームが出てきました。

フロントエンドチームは更に細分化されており、

画面チームA、画面チームB、画面チームC・・・

といった感じでチームが分かれているのですが、各画面チームに対して

画面の共通部品を提供するチーム（以下、共通部品チームと呼称）があります。

特殊な画面共通部品チーム

このチームは他チームとは異なり、各画面チームから報告されたバグや、

機能追加等のエンハンスを行っていくのですが、対応しなければならないIssueは

日々変動し、優先順位も刻々と変わっていきます。

各開発チームが必要とするためリリースも頻繁に行わなければならず、

スピード感が求められます。

都度やることが変わっていく中でガントチャートを引いてスケジュールをアップデートしていくのは現実的でしょうか？それをやろうとするとガントチャートを引く職人が専用で必要になりますね。絶対無理ですよね（笑）

アジャイル開発の導入

そこでフロントエンド開発チーム全体のチームリーダーはこの共通部品チームに限って

アジャイルでまわしていくことを決意しました。

チームリーダーから与えられたミッションはざっくりと以下の通りです。

・各画面開発チームとコミュニケーションを取りながらIssueの優先度を決定していく

・日々変わっていくIssueの優先度に対して柔軟に対応する

・リリースのスピードを上げ、各画面チームの生産性向上に貢献する

・朝会等のチームのイベントを自分たちでまわしていく

・毎週ふりかえりを行い、チームのプロセス改善につなげていく

まさにスクラムですね！

この巨大なプロジェクトの中では初の、そしてとても斬新な取り組みになります。

果たしてこの取り組みは成功するのでしょうか？

次回に続きます。