Fujitsu Standard Toolスクラムマネジメント役割の明確化プロダクトオーナー、チーム、スクラムマスターを配置する。スプリント（または、イテレーション）

FUJITSU CONFIDENTIAL

株式会社富士通マーケティング GLOVIA事業本部サービスサポート統括部サービスビジネス部松浦豪一

富士通におけるアジャイル開発の取り組み

0

情報処理学会第79回全国大会

Copyright 2017 FUJITSU LIMITED & FUJITSU MARKETING LIMITED


会社紹介

名称：㈱富士通マーケティング

所在地：東京都港区港南2-15-3 品川インターシティ C棟

企業理念：富士通マーケティングは、常にお客様の視点に基づいて革新的で最適なソリューションを創出し、お客様のベストパートナーとして、ともに、創造性あふれる未来に貢献します。

スポーツCSR：

Copyright 2017 FUJITSU MARKETING LIMITED 1


自己紹介 2001年～ GLOVIA開発に従事

2007年～ GLOVIA SUMMIT MI プロジェクトリーダとして

2011年～富士通のアジャイル支援活動事例紹介、個別支援、教育を担当

2014年～ GLOVIA SUMMIT MIを使った顧客システムの開発を担当



富士通のアジャイルの取り組み

パッケージ開発での取り組み

富士通での展開

富士通での実践教育

エンタープライズアジャイルにおける富士通の役割

本日のアジェンダ

Copyright 2016 FUJITSU LIMITED 3


富士通の取り組み

アジャイル開発の手法

アジャイル開発における主なキーワード

富士通における実践事例

富士通のアジャイルの取り組み

Copyright 2017 FUJITSU LIMITED & FUJITSU MARKETING LIMITED 4


富士通の取り組み

Copyright 2014-2017 FUJITSU LIMITED

2000年 2005年 2010年 2015年

社内ｺﾐｭﾆﾃｨが設立され、活発な情報交換が開始

された。

2000年草の根活動開始

2005年小規模なSIでXPの適用が始まる

2006年ﾊﾟｯｹｰｼﾞｿﾌﾄ開発で自発的な適用が始まる

2012年本格的なSIの案件が始まる

2011年富士通ｸﾞﾙｰﾌﾟをサポートする組織ができる

2015年「アジャイル実践センター」発足

現場主導で活動

5


アジャイル開発の手法


アジャイル開発手法の中では、リーン、スクラム、ＸＰが主流です。

リーンをベースにして、スクラムとＸＰを現場に合わせてカスタマイズし適用します。

また、現場で継続した改善を行うことで、お客様の満足度向上を目指します。

リーンソフトウェア開発（考え方）

ＸＰ

スクラム

お客様の満足度向上

現場での改善・最新の技術・現場の探究・ﾉｳﾊｳの蓄積

・顧客との協調・会話や達成感・臨機応変

※リーンソフトウェア開発：トヨタ生産方式（TPS）等の優れた生産現場の手法をソフトウェア開発に応用したもの

6


参考：アジャイル開発主なキーワード


手法名観点主なキーワード内容

リーンソフトウェア開発

価値と原則７つの原則アジャイル開発を実践する際の思考や行動の基礎をまとめたもの。全員で共有する。

７つのムダトヨタ生産方式で有名な「７つのムダ」をソフトウェア開発の現場に置き換えたもの。

スクラムマネジメント役割の明確化プロダクトオーナー、チーム、スクラムマスターを配置する。

スプリント（または、イテレーション）

一定期間（1週～4週）の中で要件定義～設計～開発～テストを繰り返し、動くものをリリースする。

プロダクトバックログお客様の案件を必要とする順番に上から１列に並べる。状況の変化に応じて逐次並び替える。

エクストリームプログラミング（通称はXP）

技術ペアプログラミング不確実で困難な作業に対して２人の知恵を結集して克服する。その過程でお互いの知恵も共有する。

テスト駆動開発（TDD）

テストコードの作成と実行からフィードバックを繰り返し得ることで設計と開発を洗練する。

継続的インテグレーション（CI）

ビルドとテストを随時自動実行することにより早期に異常を検知して常に障害のない状態を維持する。

7


富士通における実践事例

種別業種開発人数

目的／方針特長

SI

※ 保険 40

やり方の抜本的改革

全社試行（モデル化）金融系基幹システム／大人数での挑戦

お客様と大部屋開発

SI 医薬品 10 営業支援ｼｽ基幹刷新

営業の満足度向上要求開発＋ｱｼﾞｬｲﾙ開発

Ruby on Rails で高頻度ﾘﾘｰｽ（1週間）

SI 官公庁 5 不明確な要求への対応

基盤を初期に安定基盤はUP=Unified Process、業務はScrum

お客様がプロダクトオーナーとなり牽引

SI 流通 10 基幹ｼｽﾃﾑ再構築

Salesforce.com(SFDC)使用当初はWaterfall型開発でｽﾀｰﾄ →

SFDCの特性に合わせてﾌﾟﾛｾｽ変更

SI ｿｰｼｬﾙ

ｸﾗｳﾄﾞ 40

現場の意見を直接製品に反映させる

最初の機能を1週間で提供。製品の価値が、ｶﾙﾃ管理から社会貢献に変化

SI 製造 7 開発期間の短縮、コスト削減こまめに作って結合することで、リスクを軽減

PKG 会計 15 品質向上

顧客要望の早期取込みﾘﾘｰｽｻｲｸﾙ6ヶ月→1.5ヶ月に短縮

SDEM開発標準ﾌﾟﾛｾｽを独自にｶｽﾀﾏｲｽﾞ

社内ｸﾗｳﾄﾞ運用

5 良いサービスを素早く提供したい。現状のやり方を変えたい。

1年近く試行錯誤し若手中心にﾌﾟﾛｾｽを確立。

今は運用側と組んでDevOps実現を目指す。


※：富士通プレスリリース 2014年2月10日

東京海上日動システムズ株式会社様アジャイル型開発で実現業界初のペーパーレス「らくらく手続き」を開発

http://jp.fujitsu.com/group/fwest/casestudies/2014-04.html

8


富士通の取り組みのまとめ

2000年頃から草の根活動として現場主体で実践されてきた。

2011年からサポートする組織が発足している。

リーン、スクラム、ＸＰを組み合わせて実践している。

富士通では、公開している実践例がある。

Copyright 2016 FUJITSU LIMITED

パッケージ開発での取り組みについて説明する

9


パッケージ開発での課題

機能追加と保守の両立

両立できた理由

パッケージ開発での取り組み



パッケージ開発での課題

新規分野の製品を開発

課題１：業務を持たない新規パッケージのため、ニーズやゴールがみえない。

課題２：早くビジネス化したい。

課題３：少人数で機能追加と保守対応を同時に実施しなくてはならない。

マーケットにはできるだけ早く投入要望対応や不具合修正はできるだけ早く開発者は少人数・・・拡販へシフト



機能追加と保守の両立

機能追加と保守を両立

短期間の繰り返し開発（５日×人数×４回）

５日ごとに優先順位の入れ替え

WIP（Work IN Progress)を制御

ニーズの吸収を６ヶ月から1.5ヶ月に短縮優先順位変更で早期に問題解決複数人を１つの開発集中し、１個ながしを実現



Work IN Progressを制御


割込D保守１人月が発生

WIPを１にして順位変更

割込D1からD4を最優先

開発Bに遅れ発生

結果として保守が押し出されただけで、予定どおりに戻る

助け合いがおこり、ノウハウや暗黙知が醸成される

13


両立できた理由

リグレッションテストによるレベルダウン防止

テストファーストによる開発品質向上

リファクタリングによる生産性の向上

リグレッションテストが開発項目と人の依存関係をなくし、優先順位の変更を可能にした。

テストファーストにより、問題発生が減少した。リファクタリングにより、機能追加が容易になり、

５日間の開発が実現できた。 Copyright 2017 FUJITSU MARKETING LIMITED 14


パッケージ開発事例のまとめ

パッケージソフトウェア開発にアジャイル（短いサイクルでの開発）を適用することで、品質及び生産性の向上をはかることができた。

リグレッションテストによるレベルダウン防止

テストファーストによる開発品質向上

リファクタリングによる生産性の向上


富士通でのノウハウの展開

について説明する

15


事例の横展開

なぜ失敗するのかその１

なぜ失敗するのかその２

アジャイル開発で目指すところ

どうやって実践・支援したの

富士通での展開



事例の横展開

社内で事例紹介

始められない、やろうとしてもできない理由をさがしてしまう。

事例展開ではない別のやり方が必要

理由１：改善後のプロセス展開はできない。改善理由が不明で継続できない

理由２：リーダシップ型ではスケールアウトできない。

チーム数を増やすのにリーダ育成が必要 Copyright 2017 FUJITSU MARKETING LIMITED 17


なぜ失敗するのかその１

ウォーターフォール開発でいいよね

アジャイル開発がよく分からない？「安い、早い、旨い」「軽量プロセス」

メリットを理解しても踏み切れない。「良いものがあれば」「全部は無理だよね」

「品質が悪い」などの悪評を聞く。「やらなきゃいけないことをやめている」

アジャイル開発を誤解している。



なぜ失敗するのかその２今までの目でみてしまう

ウォータフォール開発が常識

計画重視、プロセス管理、トップダウンリーダー

作り手視点が当たり前

生産性はどれだけプログラムを書けるか。

予定どおりが良い。内容、スピードは関係ない。

変えたくないし、変えない。 Copyright 2017 FUJITSU MARKETING LIMITED 19


アジャイル開発で目指すところ期待するマネジメント

メンバの成長を期待する。目的は学習なので、開発メンバが成長する。

チームとしてプロセスの成長を期待する。問題を明らかにして新しいプロセスを創造する。

プロダクトの成長を期待する。リリースとフィードバックを繰り返すことでプロダクトを成長させる。

Copyright 2017 FUJITSU MARKETING LIMITED

全員で計画し、全員で開発

タイムボックスで異常を検知

異常検知→ふりかえり→計画

20


どうやって実践・支援したの

KAIZEN活動のノウハウを活用

１）教育で基本を教える

２）支援者（伝道師）がチーム

を支援して成果を出させる。

３）実践者に成果を発表させることで定着させる。

完成形を渡すのではなく、

自分達なりのプロセスを構築させる。



富士通での展開のまとめ

事例紹介では上手くいかなかった

アジャイル開発に対する誤解が多い

従来プロセスにもどしてしまう

期待するマネジメントを展開したい

教育と支援を組み合わせて展開


富士通での実践教育について説明する

22


富士通のアジャイル教育体系

ワークショップ型教育

スクラム研修

問題対私たちの構図

「対話」しながら考えてみましょう。

アジャイル開発のプロジェクトマネジメント

富士通での実践教育



富士通のアジャイル教育体系


アジャイル開発の基礎 (UIT04D)

富士通ラーニングメディアより提供

アジャイル開発はじめの一歩 (UBS77L)

スクラム研修～アジャイル開発のチームマネジメント～

(UBS80L)

事例から学ぶアジャイル開発の

プロジェクトマネジメント (UBS79L)

アジャイル開発手法によるシステム開発

(UBS99L)

24


ワークショップ型教育

失敗をして、改善を体験する。ウォーターフォールのままだった。顧客視点で開発していない。

不安な気持ちを知る。プラクティスはメリットでやるのではなく、やらなかった時のデメリットで実践される。

対話を繰り返すことでチームの自己組織化を促す。

Copyright 2017 FUJITSU MARKETING LIMITED

スクラム研修

25


スクラム研修

目的

スクラム手法のプロセスフレームワークを、模擬プロジェクトを通じて理解し、実プロジェクトでの適用方法を学ぶ

内容

庭のジオラマ作り(ガーデニング)をソフトウェア開発に見立て、チームとして模擬プロジェクトを体験する

•スクラムのプロセスを理解する

Copyright 2012-2017 FUJITSU LIMITED 26


スクラム研修

実際に起こる問題を体験することで、アジャイル開発に対する理解を深める。

アジャイル開発で利用するツールを理解する。

対話を繰り返すことで、チームで考えチームで実践することを体験する。

以下の内容を体験する。（詳細は参考に記載）

優先順位で開発する

繰返開発でデグレードをさせない対策を考える。

利用者視点で開発する。

計画を変更する。

体験することでプラクティスを体験することで理解度を深める。



問題対私たちの構図

VMﾎﾞｰﾄﾞ

Ｆ

理想的な形

VMﾎﾞｰﾄﾞ

Ｆ

ラインから外れる

傍観している人は輪から外れる

腕組みをやめてもっと近づいて

参考資料：「対話」を加えたKPTふりかえりによる、チームの活性化これだけ!KPT



「対話」しながら考えてみましょう。

「対話」の進め方

①話し合わないで一人ひとり黙々と自分の意見を書く

・キーワードを書く

・付箋紙１枚にひとつ

・３つくらい

② ひとり一枚ずつ出して説明する

付箋紙を貼って説明する

終わったら次の人が出す

心構え・グラウンドルール１．積極的に話すこと２．当事者意識を持つこと３．議題に集中すること４．一人で話しすぎないこと（人の発言をさえぎることは禁止）話していない人にも想いあり５．問題に向かってはなすこと



アジャイル開発のプロジェクトマネジメント

作る

ﾘﾘｰｽ評価

作る

ﾘﾘｰｽ評価

作る

ﾘﾘｰｽ評価

作る

ﾘﾘｰｽ評価

作る

ﾘﾘｰｽ評価

体制作りｲﾝｾﾌﾟｼｮﾝ・デッキ開発環境作り

プロダクトバックログ作成リリース計画

：

これまでアジャイル開発で語られてきた部分

スプリント1 スプリント2 スプリント3 スプリント4 スプリント5

準備フェーズ

プロジェクトマネジメント

・体制、スケジュール、進捗管理、リスク管理、ステークホルダー対応など

開発フェーズ

アジャイル開発を前提のマネジメント →アジャイルチームの動向をみて、変動する計画への対応する。



富士通の実践教育のまとめ

富士通ではアジャイル実践するための教育を用意している。

教育はワークショップ型で、対話でチームを醸成する。

アジャイル開発周辺についても教育を実施している。


エンタープライズアジャイルにおける富士通の役割について説明する

31


ITベンダーに求められるのは

アジャイル開発の基本的な考え方

戦略的な開発順序とテスト

エンタープライズアジャイルにおける富士通の役割



ITベンダーに求められるのは

要求コントロールとステークフォルダ管理

戦略的な開発順序と戦略的なテスト

アジャイル開発の特性を活かしたマネジメント

富士通のアジャイル教育：「事例から学ぶアジャイル開発のプロジェクトマネジメント」

個別教育：「アジャイル開発における品質保証の進め方」



アジャイル開発の基本的な考え方１０００行のプログラムに１行追加する場合、追加した行と影響範囲のみをテストするのではなく、毎回すべてテストする。→決められたテストをすべて合格することが基準

ペアプログラミング・テストは、毎日行う。 →問題を検出するためではなく、問題が早く減少させるため

⑧ ⑤ ⑥

⑦ ①目標値どおり

②

⑨ ⑨ ④

バグ密度

レビュー密度テスト密度

レビュー密度・テスト密度は増加する →同じプログラムを何度も、レビュー・テストするためバグ密度は低下する →未完成の状態でレビュー・テストするため、カウントできない。

アジャイル開発は、従来手法での

品質保証ができない。

品質確保のための施策が測定を不可能にする。

参考資料：リーンソフトウェアと組織改革 Copyright 2017 FUJITSU LIMITED & FUJITSU MARKETING LIMITED 34


戦略的な開発順序とテスト

外部仕様

システム仕様

詳細仕様プログラムテスト

結合テスト

システムテスト

プログラミング

外部仕様

システム仕様


結合テスト



外部仕様

システム仕様


結合テスト



目標設定

すべてのテストを完了していること目標カバレッジをクリアしていること障害修正が完了していること検出障害に対して対策を実施していること定性的評価

機能検証

構造検証

ロジック

戦略的なテスト

クリティカルなテスト付加機能異常系機能

機能検証

構造検証

ロジック


機能検証

構造検証

ロジック




全体のまとめ

当たり前にアジャイル開発ができることが大前提。

エンタープライズ領域のアジャイル実践を踏まえた教育支援を実施している。

アジャイル開発の特徴を意識した、品質管理やテストが必要である。


教育や実践を進めながら

普及できるように進めていく

36


参考資料その他

【参考資料】

（1)これだけ! KPT,天野勝,ISBN978-4-7991-0275-6

(２)リーソフトウェア開発と組織改革,Mary and Tom Poppendieck, 訳:依田智夫,依田光江,ISBN978-4-04-868741-6

(3)チーム脳の作り方,清宮普美代, ISBN978-4-87290-405-5

(4)プロジェクトファシリテーション価値と原則編,㈱永和システムマネジメント平鍋健児,天野勝

(5)アジャイル開発プロジェクトマネジメントに対応する人材育成 ―改善によって成長を期待するマネジメント―,松浦豪一, 情報処理学会デジタルプラクティス Vol.7 No.3 (July 2016)

【注意事項】

GLOVIAは日本およびその他の国における富士通株式会社の登録商標または商標です。

本資料の著作権は富士通及び富士通マーケティングにあります。



参考：スクラム研修のポイント１

１．優先順位で開発する。すべての開発項目を終わらせるまでやるという習慣になっており、価値の高いもの早くリリースするという考えがない。失敗することでアジャイル開発になっていないことを体験する。

２．繰返開発でデグレードをさせない対策を考える。開発項目に関連性を持たせ、開発を進めるとデグレートが発生することを体験する。

３．利用者視点で開発する。ウォーターフォール開発では、設計書どおりであれば、ユーザの要求を満たしていなくても問題なかった。アジャイル開発は要求に書いてあるかではなく利用者視点で問題ないかで判断する。利用者視点で考えられていないことを体験する。



参考：スクラム研修のポイント２

４．計画を変更する。順序どおりに作成することが習慣になっている。当初の計画が２回目のスプリントでは変わってしまうことを体験する。

５．すべては予測できない。スプリントの最中に計画に作業が必要なことに気がつかせる。計画変更が簡単にいかないこと、状況にあわせて改善しなくてはならないことを体験する。

６．プラクティスを体験することで理解度を深める。

メリットを理解するのではなく、やらなかった時に発生する問題が体感することができ、実践に結びつける。・計画ミーティング（相対見積もり・プランニングポーカー）

・朝会（バーンダウンチャート）・開発（ペアプログラミング）・ふりかえり（KPT)


Documents

Fujitsu Standard Toolスクラム マネジメント 役割の明確化 プロダクトオーナー、チーム、スクラムマスターを配置す る。 スプリント （または、イテレーション）

Fujitsu Standard Toolスクラムマネジメント役割の明確化プロダクトオーナー、チーム、スクラムマスターを配置する。スプリント（または、イテレーション）