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

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

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

神部知明

自己紹介

神部知明

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

製品開発グループウェア

SNS（知創空間）

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

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

その他

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

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

企業向けSNS

チームの大きさ

１５名程度が好み

本発表について

2003年を境に、

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

試行錯誤した結果、

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

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

という事例です。

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

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

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

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

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

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

受託開発サイクルの変化

下期

▼リリース

2003年以降～

上期1999～

2002年

▼ ▼ ▼ ▼

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

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

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

受託開発サイクルの変化

1999～2002年

2003年以降～

メンバーは固定

メンバーが交代…

人数

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

受託の現場 2003年～

2003年急落した単価

2000/1

2000/4

2000/7

2000/1

2001/1

2001/4

2001/7

2001/1

2002/1

2002/4

2002/7

2002/1

2003/1

2003/4

2003/7

2003/1

2004/1

2004/4

2004/7

2004/1

2005/1

2005/4

2005/7

2005/1

2006/1

2006/4

2006/7

2006/1

2007/1

2007/4

2007/7

2007/1

2008/1

2008/4

2008/7

2008/1

2009/1

2009/4

2009/7

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

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

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

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

何が起きる？

短期化

大規模化

メンバー交代

スキルが低い品質低下

リスク増大

プロジェクト

モチベーション低下

教育負荷増

売上倍増高い成果は○

やりがいはあるが、

辛い…

スピードが落ちる…

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

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

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

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

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

性能検証を前倒しで実施

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

ストアボードで見える化

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

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

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

共同所有の徹底

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

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

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

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

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

自動化

War Room

机を撤去し

場所を確保

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

規律

作業中帰宅時

人と仕事の分離

くじ引き

ペア・担当決め

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

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

開発メンバー～30人

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

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

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

他のチームに広がらない

• 経験者は増えたが…

しかし、

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

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

CGMサイト

□□受託開発

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

2002年 2009年

～２０

～１５

～３０

～２０

１０＋４０投入

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

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

◇◇

☆☆

□受託

○開発

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

チームから組織へ拡大

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

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

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

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

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

max:270チケット/週

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

Agile Agile

Water Fall移籍

縮小

Agile Ａｇｉｌｅ

複数Ｐｒｊに拡散/浸透

Ａｇｉｌｅ

Ａｇｉｌｅ集結解散

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

まとめ

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

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

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

毎朝9時

Redmine +付箋紙を併用

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

機能実装チーム

故障修正チーム

SI・運用設計チーム

試験・品質確保チーム

顧客調整

紙チケット

細かい状況は電子的にUpdate

BTS利用例

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

Technology

小規模公園費用対効果分析手法マニュアル - MLIT · 2018-09-11 · 本マニュアルは、小規模公園の費用対効果を分析するものである。小規模公園は、大規模公園

S e 神召神學院 · 宗神學教育中肩負重要的角色。事實上，在華文五旬宗神學教育上，無論在語言、文字、規模、資源位置上，香港的神召神

導入活用事例：株式会社日本ビジネスエンジニアリング · -Salesforce.com、大規模ネットワーク、大規模ストレージ-スマートフォン関係技術

3 dプリンタの市場規模

超小規模環境のMySQL #mysqlcasual

大規模ネットワーク分析篠田

日本の森林利用の現状 - npobin.net · 大規模 (300.0kw 以上 ) 中規模 (75.0 ～300.0kw) 小規模 (75.0kw 未満 ) 大規模工場の素材消費量の割合（右軸）

小規模グループケア「パピヨン」小規模グループケア「パピヨン」保育士渡辺良枝今回は小規模グループケア「パピヨン」について紹介させていただきます。

第三章前馈型神经网络模型

第 8 章神经网络模式识别法

VPP（ﾊﾞｰﾁｬﾙﾊﾟﾜｰﾌﾟﾗﾝﾄ）の取り …...PCS 規模拡大・コスト低減が必要規模拡大・コスト低減が必要統合して規模拡大・VPP補助金活用を志向

SNP による大規模 LD マッピング

DDoS Prevention: Strategy & Experience Sharingicstwebstorage.blob.core.windows.net/attachfilearticles/5...DDoS攻擊規模 •2011年紀錄最規模的攻擊約達100 Gbps •2012年紀錄最規模約達60

(地球規模オペレーティングシステム外殻の開発と …地球規模オペレーティングシステムとは？Development and Application of Global Operating System

CyanoBase: 大規模更新とユーザコミュニティ連携

BP 神经网络模型与学习算法

大規模並列フレームワークHadoopのご紹介 · Hadoop のファイルシステム HDFS: Hadoop Distributed File System 大規模分散ストレージ大規模データを複数のサーバに分散して保存

大規模アジャイル Ibm

ビッグデータソリューション cloudera 導入も管理もシンプルな …€¦ · 数台規模の小規模から100台超の大規模クラスタまで、ラックマウントサーバ、ネットワークを一元管理"

小規模企業共済制度改正委託機関向け説明会資料−1− 小規模企業共済制度は、小規模事業者が、相互扶助の精神に基づき廃業、退職、転業等