アジャイル初心者向けセミナー<2-2>①新人スクラムにおける議論の効率化②サービス開発初心者のSCRUMを用いた開発管理の改善と要因分析

富士通株式会社
SPF戦略企画室 インキュベーションセンター
0

Copyright 2015 FUJITSU LIMITED<2-2>① 新人スクラムにおける議論の効率化
富士通株式会社
SPF戦略企画室 インキュベーションセンター
杉本哲広

1

Copyright 2015 FUJITSU LIMITED

自己紹介

2

Copyright 2015 FUJITSU LIMITED自己紹介
名前：杉本 哲広（すぎもと あきひろ）
2015年4月入社の新人
3ヶ月の研修を経て、同年7月現在の部署

Incubation Centerに配属

性格：何か話し合いがあるとファシリテーション役をしたくなってしまう性格
3

Copyright 2015 FUJITSU LIMITED

実は
今回の<2-1><2-2>のセクションはIncubation Centerの新人が同時期に取り組んだ開発について発表

共通する項目についてご紹介
4

Copyright 2015 FUJITSU LIMITEDこのセッションの共通情報
新人スクラム結成までの道のり

5

Copyright 2015 FUJITSU LIMITEDIncubation Centerとは？
部署のコンセプト
新人が自律的にアジャイル開発を体得し世界で戦えるソフトウェアエンジニアに成長していく部署

部署名に込められた意味（Software Engineers） Incubation Center⇒ソフトウェアエンジニアを育てる部署
部署内で20人/24人が新人
6

Copyright 2015 FUJITSU LIMITED初めてのスクラム開発が始まるまで
5月

6月

7月

配属

8月

スクラム
開発開始
はじめてソフトウェア開発に触れる

新人ソフトウェア開発研修

7

社内サービス開発

Copyright 2015 FUJITSU LIMITED初めてのスクラム開発が始まるまで
5月

6月

7月

配属

8月

スクラム
開発開始
はじめてソフトウェア開発に触れる

新人ソフトウェア開発研修

8

社内サービス開発

Copyright 2015 FUJITSU LIMITED新人ソフトウェア開発研修
アジャイル要素を取り入れた開発
アジャイルで用いられるツールを利用

かんばん

バーンダウンチャート

振り返りから多くの知見を得て開発を終える
9

Copyright 2015 FUJITSU LIMITED初めてのスクラム開発が始まるまで
5月

6月

7月

配属

8月

スクラム開発開始
はじめてソフトウェア開発に触れる
社内のちょっとした問題
解決するアプリを作る
新人ソフトウェア開発研修

本日お話しするのはここ

社内サービス開発

４チームに分かれ本格的にスクラム開発に取り組むことに10

Copyright 2015 FUJITSU LIMITEDスクラム開発で学んだこと
ここから私の話

11

Copyright 2015 FUJITSU LIMITEDスクラム開発の始まり
目標：開発技術の向上
技術獲得のため、開発全体に関わることにデータベース

期待に胸を膨らませ、開発に臨んでいた！
12

Copyright 2015 FUJITSU LIMITED

メンバー
異動発令
13

Copyright 2015 FUJITSU LIMITEDメンバー異動
チームA

チームB

やっと慣れてきたチームを離れることに動揺・不安
14

Copyright 2015 FUJITSU LIMITED異動で得た気づき
新チーム：雰囲気が違う

発言が活発

議論が終わらない15

Copyright 2015 FUJITSU LIMITED異動で得た気づき
チームの雰囲気が違う

議論が終わらない

発言が活発

議論が終わらない
負のスパイラルを生む
16

Copyright 2015 FUJITSU LIMITED終わらない議論-例-

これって○○すべきだよね

話がかみ合わない

それは□□ってこと？
議論が終わらない

いやいや、そうじゃなくて…

一部が白熱

どういうこと？
△△したほうが良いんじゃない？
僕が言いたいのは…

17

Copyright 2015 FUJITSU LIMITED終わらない議論の-例-？ （なんの話をしているのか分からなくなってきたぞ）
話がかみ話がかみ合わない
合わない

ごめん、いまどういう話になってるの？
だから、いまは□□っていう話が出てて説明をする

一部が白熱

議論が終わらない

いやそうじゃなくて…

残りが置き去りに終わらない議論のスパイラル
18

Copyright 2015 FUJITSU LIMITED議論が終わりのないスパイラルに…
話がかみ合わない

説明をする

議論が終わらない

一部が白熱残りが置き去りに

19

Copyright 2015 FUJITSU LIMITED振り返りでの改善提案
原因をチーム全体で分析

1. 議論の属性が明確に分かれていない
2. 会話への割り込みが多い
3.

何故こんなに時間がかかっていたのだろう

議題が共有されていない振り返りの中で議論の問題が明らかに
20

Copyright 2015 FUJITSU LIMITED実施した対策(１/3)
1. 議論の属性が明確に分かれていない
議論の属性を宣言する“この議論は提案の場です”

提案の場か！
どんどんアイデアを出そう

提案と議論の場が明確に分かれるようになった議論が前に進むような発言をするようになった
21

Copyright 2015 FUJITSU LIMITED実施した対策(2/3)

2. 会話への割り込みが多い挙手制を導入“話がしたければ口を挟まず手を上げよう”
こういう意味かな？

発言する前に他人の意見や自分の意見を整理するタイミングができた

意見の整理をしてから発言するようになった
22Copyright 2015 FUJITSU LIMITED実施した対策(3/3)
3. 議題が共有されていない
ホワイトボードに議題を記載

議題○○○“いつでも目に入るように”議論の内容が横道に逸れたときに議題に戻すことができた
議題は「○○○」だったな

決めたいことをコンパクトに決められるようになった
23

Copyright 2015 FUJITSU LIMITED改善前の議論

Before

説明をする

話がかみ合わない

議論が終わらない

一部が白熱

残りが置き去りに24

Copyright 2015 FUJITSU LIMITED改善された議論

After

議題を共有

意見をまとめる
話が逸れる

効率的な
議論

アイデアを出す

疑問を解決
25

Copyright 2015 FUJITSU LIMITED最終的に…
効率の良い議論

情報や意識の共有
手戻りの少ない開発

理想とする成果物
議論を効率化すると、理想とする成果物ができる
26

Copyright 2015 FUJITSU LIMITED議論を効率化すると、理想とする成果物ができる
27

Copyright 2015 FUJITSU LIMITED<2-2>② サービス開発初心者のSCRUMを用いた開発管理の改善と要因分析
富士通株式会社
SPF戦略企画室 インキュベーションセンター
岩本華代子、江口由記、松井唯

28

Copyright 2015 FUJITSU LIMITED自己紹介2015年入社のソフトウェア開発者
配属直後に社内サービス開発
社内図書館横断検索システム ANKaor
開発期間： 1か月
開発者：新人5人
SCRUMを適用した開発

松井29

江口岩本

Copyright 2015 FUJITSU LIMITED新人ソフトウェア開発研修の反省 新人ソフトウェア開発研修の反省
 SCRUMの実践
 社内サービス開発の考察

30

Copyright 2015 FUJITSU LIMITED開発のあゆみ
5月

6月

7月

新人ソフトウェア開発研修

31

配属

8月

社内サービス開発

Copyright 2015 FUJITSU LIMITED開発のあゆみ
5月

6月

7月

新人ソフトウェア開発研修

32

配属

8月

社内サービス開発Copyright 2015 FUJITSU LIMITED新人ソフトウェア開発研修 一番できなかった班の事例
 新人研修としてWebサービスを開発したが…

素晴らしい開発計画を２週間かけて制作遅れの対策がない

実装が進むにつれスケジュールの遅れが積算
トップページは豪華
主要機能は未実装

納期にシステムが未完成
社会の厳しさ

発表会で評価をしてもらえない
33

Copyright 2015 FUJITSU LIMITED失敗の原因第3週(6/30～7/5)
失敗①：進捗管理はタスク数
タスク数
40
35

37

37

34
持越しは３タスクだが40時間分のタスク

企画から運用まで全体を通しての26
25
開発管理がされていない
20
30

30

31

16

15
10

失敗②：タスクの優先度
特に決めずにやれそうな部分から

3

5
0
6月30日

7月1日

7月2日

7月3日
34

7月4日

7月5日
Copyright 2015 FUJITSU LIMITED開発のあゆみ
5月

6月

7月

配属

8月

失敗①：進捗管理はタスク数
見かけと実態があっていない
失敗②：タスクの優先度
重要な機能が未実装

SCRUM

新人ソフトウェア開発研修

35

社内サービス開発

Copyright 2015 FUJITSU LIMITEDSCRUMの実践 新人ソフトウェア開発研修の反省
 SCRUMの実践
 社内サービス開発の考察

36

Copyright 2015 FUJITSU LIMITEDSCRUMの実践による課題解決 (1)失敗①：進捗管理はタスク数
失敗②：タスクの優先度
解決策としてプランニングポーカー(PP)を採用
チーム全員の知識を活用するため新人でも見積もりが比較的容易
新人の見積もり能力の向上

37

Copyright 2015 FUJITSU LIMITEDSCRUMの実践による課題解決 (2)失敗①：進捗管理はタスク数

失敗②：タスクの優先度
開発プロセスにおけるタスク優先度付け

計画
1. PPで見積もり
2. 優先度付け
3. ベロシティをもとに開発計画を作成
4. POに報告

作業
1. 優先度に従って開発
2. 作業時間を記録

38

振り返り
1. ベロシティの計算
2. PP等のやり方を改善

Copyright 2015 FUJITSU LIMITEDプランニングポーカーの改善（1/3）
第一週 参考書の通りコスト性で評価

見積もり
4ポイント
タスク

あるタスクを基準として相対コストを評価⇒実際の時間との対応が把握しにくい
39

Copyright 2015 FUJITSU LIMITEDプランニングポーカーの改善（2/3）
第二週 時間で見積もり

見積もり
4時間
タスク

タスクの作業量を絶対時間で評価⇒見積もりの誤差が把握できる⇒ペアプロ時の処理が未定義
40

Copyright 2015 FUJITSU LIMITEDプランニングポーカーの改善（3/3）
第三週 作業時間で見積もり

見積もり
８人時

ペアタスクであることを表す

タスク

P

タスクにペア・ソロ・全員を記述し、作業量を（人×時間）で評価⇒実作業時間と見積もりがリンク
41

Copyright 2015 FUJITSU LIMITED見積もり精度の向上
平均二乗誤差率 √Σ[N][k=1]（t1-t2）2 /N*100 [%]t1:見積もり時間 t2：作業時間 N:タスク数
週

見積もり方

タスク数

誤差率(％)

2週目

作業時間（時間）

8244.83週目

作業時間（人時）8108.84週目

作業時間（人時）1241.3

誤差率
1/6

自分たちに適した見積もり方法を習得

42

Copyright 2015 FUJITSU LIMITEDプランニングポーカーの更なる効果期待した効果
チーム全員の知識を活用するため新人でも見積もりが比較的容易
新人の見積もり能力の向上

更なる効果タスクに対する認識のずれが数値として現れる
タスクの情報を補間、共有目標達成に対する自主性が向上

43

Copyright 2015 FUJITSU LIMITED開発プロセスの改善
問題発生時にはPOと相談が必要

計画
1. PPで見積もり
2. 優先度付け
2b. POと相談しながら優先度付け
3. ベロシティをもとに開発計画を作成
4. POに報告

作業
1. 優先度に従って開発
2. 作業時間を記録
3. 問題があるときにはPOと相談

44

振り返り
1. ベロシティの計算
2. PP等のやり方を改善

Copyright 2015 FUJITSU LIMITED社内サービス開発の考察
 新人ソフトウェア開発研修の反省
 SCRUMの実践
 社内サービス開発の考察

45

Copyright 2015 FUJITSU LIMITED今回改善できたこと
 スプリント単位で完遂可能な計画を立案
 優先度付けにより障害への柔軟な対応
 時間を工面 優先度の高い機能から実装
 機能の方針変更はPOと適宜相談

開発システムへの評価
 ユーザの反応 ユーザや上司による審査の結果、全4チームの中で最も高い評価
 アンケートの結果、約7割が高評価
使いやすい
やや使いやすいふつうアンケート結果改善を続けることで納期までに満足度の高いシステムを提供
46

Copyright 2015 FUJITSU LIMITEDSCRUMが成功した要因
 我々のマインドセット
 POに提案ではなくチームの一員としてPOと協創
 SMがリーダーではない 自分の意見を押し付けない 相手を理解し、自分も理解されるように言動問題を発見する

実行する

 素早い改善サイクル

改善策を考える PPのように適宜改善がされ開発効率が向上

互いに信頼されるように行動することで素早い改善ができるチームを構築
47

Copyright 2015 FUJITSU LIMITEDまとめ 入社4か月の新人が社内サービスをリリース
 SCRUMを適用することで成功
 プランニングポーカーによる見積もりは開発管理に有効
 成功に必要なことは素早い改善 互いに信頼されるように行動することで素早い改善を可能に この経験を他の場でも活かしています 松井：社外研修会の組み込みソフト開発でスクラムマスターを担当
 岩本、江口：社外のＫＰＴを見学

 今後のインキュベーションセンターの活躍ご期待ください

48

Copyright 2015 FUJITSU LIMITEDCopyright 2015 FUJITSU LIMITED