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

Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITED

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

富士通ソフトウェアテクノロジーズインターネット基盤サービス事業部

神部知明

自己紹介

神部知明

ソフトウェアエンジニア（17年）

製品開発グループウェア

SNS（知創空間）

受託開発製品カスタマイズ

企業内のコミュニケーション/コラボレーションを扱うシステム

その他

1 Copyright 2010 FUJITSU SOFTWARE TECHNOLOGIES LIMITED

93 94 95 96 97 98 99 00 01 02 03 04 05 06 07 08 09 10

▼入社製品開発 ▼ 受託開発 ▼ 製品 & 受託

企業向けSNS

チームの大きさ

１５名程度が好み

本発表について

2003年を境に、

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

試行錯誤した結果、

1つのチームで始めた取り組みが、

7年かかってようやく組織に浸透し始めた。

という事例です。


10人

50人


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

• 某社の情報共有系社内システム受託

• 1999～関連する複数のシステムを開発

受託開発のサイクルが短期化

顧客：ビジネス状況で投資額を変える

開発：短期・大規模化で開発リスク増大

受託開発サイクルの変化


下期

2Q4Q

▼リリース

2003年以降～

1Q3Q

上期1999～

2002年

▼

▼ ▼ ▼ ▼

開発メンバーの確保が問題に

品質：新メンバーのスキル・モチベーションは低い

生産性：メンバーをキープできず上がらない

受託開発サイクルの変化


1999～2002年

2003年以降～

メンバーは固定

メンバーが交代…

人数

1年

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

受託の現場 2003年～

2003年急落した単価


70

75

80

85

90

95

100

105

2000/1

2000/4

2000/7

2000/1

0

2001/1

2001/4

2001/7

2001/1

0

2002/1

2002/4

2002/7

2002/1

0

2003/1

2003/4

2003/7

2003/1

0

2004/1

2004/4

2004/7

2004/1

0

2005/1

2005/4

2005/7

2005/1

0

2006/1

2006/4

2006/7

2006/1

0

2007/1

2007/4

2007/7

2007/1

0

2008/1

2008/4

2008/7

2008/1

0

2009/1

2009/4

2009/7

品目/__受託開発ソフトウェア

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

日銀企業向けサービス価格指数（2000年基準）

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

何が起きる？


短期化

大規模化

メンバー交代

スキルが低い品質低下

リスク増大

プロジェクト

モチベーション低下

教育負荷増

売上倍増高い成果は○

やりがいはあるが、

辛い…

スピードが落ちる…


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

• 規模は変わらず納期は1/2

• 割り当てメンバーのスキルは低い

開発の早い段階でリスクをつぶす

期限までに確実に動かすしくみイテレーションで動作するモノを作り、確実に進捗させる

性能検証を前倒しで実施

問題点を早期に見つけるしくみ毎朝・夕ミーティング

ストアボードで見える化

短期間で集約し、いつでも実物で評価可能に


自律的なチーム作りで管理の負荷を軽減

プロセスの浸透・ノウハウ共有のしくみペア作業

共同所有の徹底

ふりかえりでプロセス浸透・改善

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


ツールの徹底利用でスキル不足をカバー

作業もれ、ルール無視を防止するしくみトラッキングツール(BTS)徹底利用

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

自動化



War Room

机を撤去し

場所を確保

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


規律

作業中帰宅時


人と仕事の分離

くじ引き

ペア・担当決め


コミッター83人コミット回数13,500

実例:知創空間(SNS)の開発


開発メンバー～30人

実例:知創空間（SNS）の開発


コードの共同所有例: ArticleAddForm.inc1,200行 100リビジョン

24人

実例:知創空間（SNS）の開発


他のチームに広がらない

• 経験者は増えたが…

しかし、

組織への浸透のきっかけ 2009～


○○受託開発製品開発（知創空間）

CGMサイト

□□受託開発

トラブルプロジェクトの火消し

2002年 2009年

～２０

～１５

～３０

～２０

１０＋４０投入

草の根的（プロジェクト内）

組織的（複数Ｐｒｊに拡散）

◇◇

☆☆

□受託

○開発

※適用時期はイメージ（実際とは異なる）

チームから組織へ拡大

アジャイルなチームは大きくならないメンバーを抜いても継続可能 → 適当な大きさに収束

火消しプロジェクトをきっかけに浸透 10人のプロジェクト → 3カ月間50人に増強

今まで培った手法（徹底した見える化/タイムボックス）でデスマーチ回避

経験者（卒業生）が多数参加

リーダークラスを厚く投入（部課長、リーダー）


max:270チケット/週

草の根の域を越えられない

Agile Agile

Water Fall移籍

縮小

Agile Ａｇｉｌｅ

複数Ｐｒｊに拡散/浸透

Ａｇｉｌｅ

Ａｇｉｌｅ集結解散

３ヶ月間のハードトレーニング

まとめ

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

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

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


毎朝9時


毎朝9時


24 Copyright 2010 FUJITSU LIMITEDCopyright 2010 FUJITSU LIMITED24


Redmine +付箋紙を併用

最大、週２７０枚のチケット消化※Redmine上では感覚的に扱う事が難しい

機能実装チーム

故障修正チーム

SI・運用設計チーム

試験・品質確保チーム

顧客調整

紙チケット

細かい状況は電子的にUpdate

BTS利用例

Technology

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