属人化を排するということ～フラット化されたチームの構築～
富士通株式会社
共通ソフトウェア開発技術本部
ソフトウェア開発技術統括部
ソフトウェア技術センター
大脇 斉
0Copyright 2015 FUJITSU LIMITED自己紹介
 大脇 斉（おおわき ひとし）
 略歴
 1988年 富士通入社 Fortranコンパイラ開発
 2003年 共通部門に異動 ソフトウェア技術の実践と展開、プロセス改善
 2012年 社内向けクラウドサービス統合プロジェクト（ぬまくらシステム）
沼津ソフトウェア開発クラウドセンターシステムの略称
社内のソフウェア開発者向けに開発環境を提供する各種サービスの統合システム

 アジャイル歴 2013年 ぬまくらシステム開発にスクラムを導入（スクラムマスター）
 現在 別の社内システム開発のスクラムマスター

 現在の業務 社内 ソフトウェア開発部門へのアジャイル開発推進
1

Copyright 2015 FUJITSU LIMITEDぬまくらシステム構成と開発体制（2012年）
FY2012/2Q 3Q

 複雑、かつ短納期の難しいプロジェクト 予定 企画 設計・PG・テスト
ぬまくらシステム

大脇HN

サービス基盤4Q

VM自動貸出 VM手動貸出 SCM & ハウジング ストレージ貸出 &外部接続ID
TR

NK

OS
プロセス実行

HK

HI
サービス基盤

FY2013/1Q
公開・随時更新

実機貸出

STGM

SK
課金NE
利用状況集計

全社システム

認証基盤

人事情報

職制情報

課金基盤

 各システム/サブシステムごとに担当を割り当て
 全システムを並行して開発できる
FY2012/2Q 3Q
4Q
 担当に聞けば、各システムの状況がわかる 実績 企画
設計・PG・テスト
 担当者以外は誰も知らない
2

FY2013/1Q▲機能限定公開

Copyright 2015 FUJITSU LIMITED2013年3月の開発体制と発生した問題
 運用開始とともに、3名がチームを離脱
ぬまくらシステム大脇

HN

サービス基盤

ストレージ貸出
運用者

VM自動貸出 VM手動貸出 SCM & ハウジング ストレージ貸出 &外部接続ID
TR

OS
プロセス実行

NK

HK

HI
サービス基盤

実機貸出

ST

GM

SK
課金NE
利用状況集計ストレージ貸出の運用者画面で承認したら、『予期せぬエラーが発生しました』って出たんだけど?
え。。。
そんなエラーが出るってことをGMさんから引き継いでないので、予期してませんでした。
3

Copyright 2015 FUJITSU LIMITEDもし同じ体制で開発を続けていたら。。。
 2013年9月に、さらに3名離脱
ぬまくらシステム

大脇

VM自動貸出 VM手動貸出 SCM & ハウジング ストレージ貸出 &外部接続ID

HN

TR

サービス
基盤

OS
プロセス実行

HK

NK

HI
サービス基盤

実機貸出

ST

GM

SK
課金

NE
利用状況集計 2014年7月までに、の3名も離脱していた。。。

SRKH

KA

2014年1月～7月にかけて3名が加入

業務に『人』を結びつけてはいけない!!
4

Copyright 2015 FUJITSU LIMITED

目指すゴール = フラット化されたチーム
 誰が作業しても同じ結果を得られる
 誰かが抜けても（頭数以外は）困らない
 誰かが入ってもすぐに業務ができる

アドバイザー5

Copyright 2015 FUJITSU LIMITED

目指すゴール = フラット化されたチーム
 誰が作業しても同じ結果を得られる
 誰かが抜けても（頭数以外は）困らない
 誰かが入ってもすぐに業務ができる

アドバイザー6

Copyright 2015 FUJITSU LIMITED

誰が作業しても同じ結果を得られるようにする
 作業を細かく分割する 作業計画単位を2週間にする ＝ スプリント
 誰かに価値のある単位で分割 ＝ ストーリー• どういう状態がゴールか、全員で話し合って決める ストーリーを生産物のできる単位で分割 ＝ タスク• タスクのインプット／アウトプットの“モノ”を明確にする• アウトプットは次のタスクのインプットになる 何のためにこの作業をするか、明確な形で共有できる

 自動化する OSSツールを活用する• Jenkins：ビルド、配備、RT実行• Cobertura、checkstyle、FindBugs：ビルド時に同時実行し、見える化• sonarqube：プロジェクトの各種メトリクスを見える化（構築中） バッチファイル化・シェルスクリプト化する 手作業・手番を減らす
7

Copyright 2015 FUJITSU LIMITED

作業を細かく分割する
2560

コードホスティングサービスを利用中のプロジェクトは削除できないよ
うにしてほしい
2.0
受入条件
コードホスティングサービスを利用中のプロジェクトを削除しようとすると、削除できないことを通知（メッセージ）して削除できない。
ticket

タスク名

#2602

基盤の仕様確認#2597

STT項目表作成#2601

基盤側からの呼出し部実装+MT+スモテ

ストーリー名:何をしたいかがわかる
ように書く
ストーリーポイント:「1ペア日で終わる仕事」
を1.0とした相対値
受入条件:
全員で決めた、ゴールの状態

out：* スモテ実施可能に設定された基盤* operatorUIの設定手順メモ → OK
* 毎回削除できないと返すchs_ws.war* 配備手順書#2598

削除条件判定部分実装+MT+スモテ

#2599

STT実施

#2615

プロパティファイルを修正しコミット#2600

developマージ+RELEASE化+テスト
8

タスク名:
どんな作業を行うかがわかるように書く
アウトプット:
何を作るかを書く

Copyright 2015 FUJITSU LIMITEDスプリント計画の様子

Redmineでタスク作りながら、皆で共有

チケット番号

タスク名
見積時間

同時進行でこの辺の人が紙のタスクカードを作成
ストーリー識別シール
9

Copyright 2015 FUJITSU LIMITEDOSSツールを活用する ぬまくらシステムの開発環境

依存jarをダウンロード

修正資産をpush

開発マシン

資産サーバ

Cobertura

資産をpull

生産物格納庫ビルド結果を格納

FindBugs™

（構築中）
ビルド時に情報収集

10

Copyright 2015 FUJITSU LIMITED

目指すゴール = フラット化されたチーム
 誰が作業しても同じ結果を得られる
 誰かが抜けても（頭数以外は）困らない
 誰かが入ってもすぐに業務ができる

アドバイザー11

Copyright 2015 FUJITSU LIMITED誰かが抜けても困らないようにする
 チームで仕事をする
 外部に宣言＆徹底• 「チームで仕事します。担当者は割り当てません。」

 内部も徹底• フラット化、メンバーは平等• チーム内の係も持ち回り 作業優先順位の徹底• 優先順位の高いストーリーの優先順位の高いチケットから作業する

 情報を共有する
 朝会、昼会で直近の作業状況を共有
 チームを代表して出席した会議の後は、すぐに共有会
 定期的な全員レビューで技術、プロセス、設計思想を共有

12

Copyright 2015 FUJITSU LIMITEDチーム内の係を持ち回る ～司会～
 スプリント計画、レビューの司会（ローテーション）
 スプリント名を決められる リリースの最初では、そのリリースで使うスプリント名のテーマも決められる 名前を付けると愛着がわく
リリース名。POに命名権。
Aから順につける。
テーマは「キュンッ!」とくる？

スプリント名。司会者に命名権。
テーマに従ってAから順につける。
テーマの決定権はリリース最初の計画の司会者。
リリースEliteのテーマは「星座」、KHさんが付けました。

13

Copyright 2015 FUJITSU LIMITED

優先順位の高さを視覚的にアピール タスクボードのToDo域
ストーリーごとに、台紙を分けてタスクを貼る。
優先順位の高いストーリーが物理的に上になるように、台紙をタスクボードに貼る。
タスクは上から下へ、作業する順に貼っていく。
ストーリー。
色シールでどのストーリーのタスクかがわかるようにする。

14

Copyright 2015 FUJITSU LIMITED定期的な全員レビューの記録

15

Copyright 2015 FUJITSU LIMITED

目指すゴール = フラット化されたチーム
 誰が作業しても同じ結果を得られる
 誰かが抜けても（頭数以外は）困らない
 誰かが入ってもすぐに業務ができる

アドバイザー16

Copyright 2015 FUJITSU LIMITED誰かが入ってもすぐに業務ができるようにする
 ペアで仕事する すべてのタスクをペアで行う• 調査、設計、実装、テスト、運用作業、トラブル対応、休憩

 作業にあたるペアを固定しない• ランダム（じゃんけん⇒くじびき）• 毎日交代⇒半日交代（タスクの途中の作業は必ずどちらか1名が残る）

 役割の交代• 予定時間の半分⇒1時間⇒30分⇒1時間

 開発環境を共有する
 VMを借りて、皆で使う
 ビルド専用環境の構築
 資産管理、生産物管理の連携・自動化

 明文化する 作業内容の記録はタスクに残す
 作業手順やルールはWikiに書く（気軽に残せる、すぐ改版できる）
17

Copyright 2015 FUJITSU LIMITEDペアで仕事する
2560

コードホスティングサービスを利用中のプロジェクトは削除できないよ
うにしてほしい
2.0
ticketタスク名

担当者と作業時間#2602

基盤の仕様確認2/27 OS・KA 1.0H

#2597

STT項目表作成

3/2 KH・KA 1.5H

#2601

基盤側からの呼出し部実装+MT+
スモテ

3/2AM KA・KH 0.5H
3/2PM KH・KA 0.5H

ペアの組合せはランダム#2598

削除条件判定部分実装+MT+スモ
テ

3/3AM KA・SR 1.0H
3/3PM KA・KH 1.5H

#2599

STT実施

3/3 KA・KH 1.0H

午前と午後でペア交代、午前のペアの1人KAさんが、午後も残っている#2615

プロパティファイルを修正しコミット

3/4 SR・KH 0.5H

#2600

developマージ+RELEASE化+テス
ト

3/4 SR・KH 1.5H

18

すべての作業をペアで行う

Copyright 2015 FUJITSU LIMITEDペア作業の様子
共通開発環境にRDP接続。

Redmineのチケットは隣の画面で見ながら。

ペア決め用のくじ。
KAさん作。
これを作るための、タスクは作ってない。

ミニホワイトボードの手書きメモで意識合せ。
紙よりエコ。
19

Copyright 2015 FUJITSU LIMITED

作業内容の記録を残す
タスク #2601
機能 #2560: コードホスティングを利用中のプロジェクトは削除できないようにしてほしい

基盤側からの呼出し部実装+MT+スモテ
out：* スモテ実施可能に設定された基盤* operatorUIの設定手順メモ → OK
* 毎回削除できないと返すchs_ws.war* 配備手順書
chs_ws_warはWebserviceとして実装済み
毎回、削除できないと返す
OperatorUiで設定しスモテ実施すること
サービスをサービスグループに追加して、IsActiveProjectをチェック
削除不可のメッセージは正しく実装すること[soft-nmpo-dev:04367]
MEMO：
throw new NumacloServiceApiException(_VPDC.get(PropKeys.SERVICE_NAME), _VPDC_API.get(ApiPropKeys.USING_PROJECT)
これを投げれば、削除できないことになる
3/2
AM：KA-KH (0.5)
基盤側設定を行った。すでに手順書があったので、それを見ながらやった。
chs_commonのブランチを切った。POMを変更した。Propkeysを修正してコミット済み。
chs_wsのブランチを切った。POMを変更した。
chs_wsを実装したが、URL直叩きで見えない。たぶん、ServiceQueryImplにアノテーションを加えていないせいだろう。
http://xxxx,xxxxxx,xxxx,xxxx,xxxxxx,xxxx,xxx/chs_ws/ws/

見積の時に出た情報、条件などを、作業時に困らないように書いておく

午前と午後で作業者が変わる場合があるので、別々に記録する

PM:KH-KA (0.5)* ServiceQueryImpl見えるようにする(アノテーション追加)→bean.xmlに設定追加も必要* USEING_CHSに正しいメッセージを入れる→○○さんからのメッセージをCHS.propertiesに設定* スモテ （CHS使っているプロジェクトは常に返せないことになるはず）→削除時にエラーメッセージが正しく出力されることを確認
サービス設定画面でコードホスティングのチェックボックスが操作できないことを確認

20

Copyright 2015 FUJITSU LIMITED

作業手順を明文化する Wikiをはりつける

21

Copyright 2015 FUJITSU LIMITEDやり方を変えるのは大変である これまでのやり方
 一定期間内に出来ない事を、なんとかやってもらおうとする 新しいやり方
 一定期間内に出来ない事を、どうすれば出来るか全員で一緒に考える

 最初はぜんぜんまわらない 「今まで見たことないシステムだから。。。」
 「やったことない作業だったから。。。」
 モチベーションダウン（できなくてもいいや空気）

22

Copyright 2015 FUJITSU LIMITED抵抗勢力と戦う
 メンバーとの戦い

 外部との戦い

 担当者を決めない事への疑問

 「人」と仕事したがる人
だれに言えばいいの?

前の方がうまく行ってたと思う。

mlに投げてください。
だれかが対応します。

チームで仕事するんだから担当者は決めません!!

だれに割り振るつもり?

 ペア作業への抵抗

決まってません。
優先順位に沿って作業するので、そのチケットを誰がとるか、わからないです。

。。。1人で仕事したい。
ぜっっっっっっったい
ダメ!!

フラット化されたチーム作りのためには、ゆずれない!!
23

Copyright 2015 FUJITSU LIMITED上向きになるきっかけをもらう具体的な問題について、振返ってみたら?
アドバイザー

見積時間の2倍以上かかったタスクを振返ろう!

 「人」ではなく「やりかた」に着目する やることはわかっていたか?
 タスクを実行できる状態だったか?
 やりかたはまずくなかったか?

 具体的な改善案が出てきた 改善によって変わる事を実感できた おれたち、行けるんじゃね？

24

Copyright 2015 FUJITSU LIMITEDYaBaiタスク
 見積り時間の2倍以上かかったタスク = YB
Redmineのチケット番号

タスクの作業者、誰がやったか色でわかる共有開発環境の識別マーク。
日をまたいで引き継ぐ時に便利。
（後に数字に変更された）

タスクカードに『YB』マークをつける
見積時間と実績時間。
2.0Hの見積りで8.5Hはやばいでしょ!
25

Copyright 2015 FUJITSU LIMITED

目指すゴールを実現できるチームを作る フラットなチーム作り 自分もメンバーの1人として動く（特別扱いしない）
じゃんけんに負けて休日出勤しました 話しやすい雰囲気作り• チームメンバーに話しかける

L• 雑談にも積極的に乗る• 振返り会でアイディアを出しやすくするため、くだらない案を出してハードルを下げる

 新しく入った人の受入
 加入当初は意図的に全員とペアを組む
 可能な限り早く、メンバの1人として投入• チームのやっていることを即体感• 慣れる前に実践することで、気づきも多い暗黙知が発見され、共有できる状態に変更される

 もちろん、歓迎会も開催
26

Copyright 2015 FUJITSU LIMITED採用されたくだらない案
テンションが上がると『おねぇ』になる人がいたので、当番制が提案されました。

誰もやらないので、次のスプリントで固定制に戻されました。

運用作業で残業や休出する人のためにお菓子を買うための基金を作る提案がされました。

 注）上記全部を僕が出したわけではありません
27

Copyright 2015 FUJITSU LIMITED目指したゴールにたどり着けたか アクセス権設定（不定期な運用作業）の対応実績（最近10回）
担当HM
SRHM
SRHM
OS

SR
KH

SRKH

SRKH

OB
SR
KH

SRKH

OS
KH

KH
KA

作業時間
(H)

0.5

0.5

0.5

0.5

0.5

0.5

0.5

0.5

0.5

0.5

ticket #3537 #3428 #3406 #3330 #3329 #3264 #3152 #3150 #3145 #3092

 新しいメンバがペア作業に入るまでに要した期間
 SRさん：3日（システム説明） Java未経験者
 KHさん：1週間（システム説明+チーム説明+Javaのスキル習得）
 KAさん：0日（運用担当だったので、説明もしてない）
2015年度新入社員
 OBさん：4日（システム説明+チーム説明（+会社の事務手続き））
 SSさん：0日（隣のチームから移籍、同じ部署なので、概要は知っている）
 HMさん：2日（システム説明+チーム説明（+会社の事務手続き））
28

Copyright 2015 FUJITSU LIMITED人の増減による実績の変化
 1ストーリーポイントを完了するのに要した時間
 計算方法：実績作業時間÷実績ストーリーポイント≒（作業予定時間－割込み実績時間）÷実績ストーリーポイント
 6時間/1ストーリーポイント（赤線）が目標値

人の減よりも、新しく手掛けた他システムとの連携で滞ったのが主因

人の増減があってもなくても、見積もりに慣れてなかった期

ININ

IN

OUT
OUT

OUT

自分が抜けたOUT

1ヶ月だけチームに入ってアジャイル体験
29

IN

IN

OUT

Copyright 2015 FUJITSU LIMITED

まとめ 誰がやっても同じ結果を得られる○△○

 「次にほかの人がやる時に困らないようにしてあげる」、空気が定着 「僕にはできない」と拒否するメンバーはいない 結果を得るまでの時間の差は多少はある

 誰が抜けても、困らなくなってきた うまくいき始めてからも4人抜けてるが、そんなに困っていない 抜ける時に、引継を行っていない
 時々聞いているし、聞かれてもいる

 誰でもすぐに入れている 加入後、数日で戦力として活躍している
 チームのパフォーマンスも低下していない
 チームとして、人を受け入れる体制ができている30

Copyright 2015 FUJITSU LIMITED今後の展開 ～アジャイル開発推進者として～
 アジャイル開発導入ガイドラインを作る 自身の経験+実践者の知見を集める
 社内でアジャイルをやるための参考書を目指す
 アジャイル開発に取り組む人への、ハードルを下げる

 アジャイル体験場としてオープンチームとする
 情報は常にオープンにする 見学希望者、アジャイル開発体験希望者を積極的に受け入れる
 うまくいく体験をする事が、成功への近道である

 別のチームで、違うやり方を試してみる
 ベストなやり方はチームによって異なる もっと良いやり方があるかも知れない
 チーム状況に応じて、適切な支援ができる人になる31

Copyright 2015 FUJITSU LIMITED32

Copyright 2015 FUJITSU LIMITED