Agile japan2010 事例大規模セッション_神部

受託開発におけるアジャイルへの取り組み事例
Agile Japan 2010 事例セッション３）大規模

富士通ソフトウェアテクノロジーズ
インターネット基盤サービス事業部
神部知明
Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITED

自己紹介
神部知明
ソフトウェアエンジニア（17年）

 製品開発
 グループウェア企業向けSNS
 SNS（知創空間）
 受託開発
 製品カスタマイズ
 企業内のコミュニケーション/ チームの大きさ
コラボレーション
を扱うシステム１５名程度が好み
 その他

▼入社製品開発 ▼ 受託開発 ▼ 製品 & 受託
93 94 95 96 97 98 99 00 01 02 03 04 05 06 07 08 09 10
1 Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITED

本発表について
 2003年を境に、

大きく環境が変化した受託開発の現場が、
アジャイルな考え方を取り入れる。

試行錯誤した結果、
10人
1つのチームで始めた取り組みが、

7年かかってようやく組織に浸透し始めた。 50人
という事例です。


ある受託開発チームの課題

• 某社の情報共有系社内システム受託
• 1999～関連する複数のシステムを開発


受託開発サイクルの変化
 受託開発のサイクルが短期化
▼リリース ▼
上期
1999～
2002年下期

▼ ▼ ▼ ▼
1Q
3Q
2003年以降～
4Q
2Q

 顧客：ビジネス状況で投資額を変える
 開発：短期・大規模化で開発リスク増大


受託開発サイクルの変化
 開発メンバーの確保が問題に
人数
1999～2002年
メンバーは固定
1年

2003年以降～
メンバーが交代…

新メンバー投入別のプロジェクトへ

 品質：新メンバーのスキル・モチベーションは低い
 生産性：メンバーをキープできず上がらない


100
105

70
80
85
90
95

75
2000/1
2000/4
2000/7
2000/10
2001/1
2001/4
2001/7
2001/10
2002/1
2002/4
2002/7
2002/10
 2003年急落した単価

2003/1
2003/4
2003/7
受託の現場 2003年～

2003/10
2004/1
2004/4

・オフショア拡大
・リスク管理強化
2004/7

6
2004/10
2005/1
2005/4
2005/7
2005/10
2006/1
2006/4
2006/7
2006/10
2007/1
2007/4
日銀企業向けサービス価格指数（2000年基準）

2007/7
2007/10
2008/1
2008/4
2008/7
2008/10
2009/1
品目/__受託開発ソフトウェア

品目/__パッケージソフトウェア

2009/4
2009/7
Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITED

何が起きる？
やりがいはあるが、
辛い…

リスク増大

大規模化
売上倍増
短期化
高い成果は○
スキルが低いモチベーション
品質低下低下

プロジェクトスピードが落ちる…
メンバー交代
教育負荷増


短期開発にどう対応するか

• 規模は変わらず納期は1/2
• 割り当てメンバーのスキルは低い


開発の早い段階でリスクをつぶす
 期限までに確実に動かすしくみ
 イテレーションで動作するモノを作り、確実に進捗させる
 性能検証を前倒しで実施

 問題点を早期に見つけるしくみ
 毎朝・夕ミーティング
 ストアボードで見える化
 短期間で集約し、いつでも実物で
評価可能に


自律的なチーム作りで管理の負荷を軽減
 プロセスの浸透・ノウハウ共有のしくみ
 ペア作業
 共同所有の徹底
 ふりかえりでプロセス浸透・改善

 メンバーが自ら動けるしくみ
 タスク化、見える化


ツールの徹底利用でスキル不足をカバー
 作業もれ、ルール無視を防止するしくみ
 トラッキングツール(BTS)徹底利用

 レベルダウンを防止するしくみ
 構成管理ツールの徹底利用
 自動化


War Room

机を撤去し
場所を確保

作業スペース、ミーティングスペース、ストアボードが
同じ場所にあることが重要

規律
作業中帰宅時


人と仕事の分離
ペア・担当決め

くじ引き


実例:知創空間(SNS)の開発
コミッター83人
コミット回数13,500


実例:知創空間（SNS）の開発
開発メンバー～30人


実例:知創空間（SNS）の開発
コードの共同所有
例: ArticleAddForm.inc
1,200行 100リビジョン

24人


しかし、

他のチームに広がらない

• 経験者は増えたが…


組織への浸透のきっかけ 2009～
組織的（複数Ｐｒｊに拡散） ○開発

□受託
◇◇
☆☆

草の根的（プロジェクト内）トラブルプロジェクトの
火消し

１０＋４０投入

CGMサイト
○○受託開発～３０
製品開発 □□受託開発
～２０（知創空間）～２０
※適用時期はイメージ
～１５（実際とは異なる）
2002年 2009年

チームから組織へ拡大
 アジャイルなチームは大きくならない
 メンバーを抜いても継続可能 → 適当な大きさに収束
Agile Agile
縮小
草の根の域
Water Fall を越えられない
移籍

 火消しプロジェクトをきっかけに浸透
 10人のプロジェクト → 3カ月間50人に増強
 今まで培った手法（徹底した見える化/タイムボックス）でデスマーチ回避 max:270チケット/週
 経験者（卒業生）が多数参加
 リーダークラスを厚く投入（部課長、リーダー）
Agile Ａｇｉｌｅ
集結解散
Ａｇｉｌｅ複数Ｐｒｊに
拡散/浸透
Ａｇｉｌｅ
３ヶ月間の
ハードトレーニング

まとめ
 なぜ、大規模でアジャイルか？
複数のチームに拡大することで組織全体が俊敏になる
チーム編成、解散、メンバーの増減に柔軟に対応できる

 上手くやるには何が必要か？
構成管理・IssueTrackingなどのツール整備が必須
単に導入ではなく徹底利用、プロセスをツールに合わせる

 その他
成功には高いモチベーションと規律が必要
規律があればチームは育つが、個々の専門性が失われがち
マネージャーはメンバーの成長のために、テーマや時間を与えて
あげてほしい


毎朝9時


BTS利用例
 Redmine
+付箋紙を併用
 最大、週２７０枚のチケット消化
※Redmine上では感覚的に扱う事が難しい

紙チケット

顧客調整機能実装細かい状況は
電子的にUpdate
チーム
試験・品質確保 SI・運用設計
故障修正チームチーム
チーム

Agile japan2010 事例大規模セッション_神部

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (16)

Recently uploaded

Recently uploaded (10)

Agile japan2010 事例大規模セッション_神部