外部委託から内製化アジャイルへの切替支援を通してわかったこと #augj

外部委託から内製化アジャイルへの切替支援
を通してわかったこと
グロースエクスパートナーズ株式会社
関満徳
2017/08/22
ハッシュタグ： #augj

撮影可録音可
Copyright© Growth xPartners, Inc. All rights reserved. 2
音には配慮
お願いいたします

グロースエクスパートナーズ株式会社
• 略称：GxP（Growth xPartners）
• 主戦場：SI
• 創業： 2008年
• 2008年よりアトラシアン製品を活用
– システム開発
– 社内情報共有
» 議事録
» 貸し出し機器一覧
» サービスデスクでのQ&A
» などなど
• 2010年よりアトラシアン社のパートナーへ
– 販売やサポートのほか、SIの現場で培ったノウハウを生かした
コンサルティングや環境構築等に対応

今日お話ししたいこと
• iOS/Androidアプリ開発を外部委託して
いたチームが、内製化アジャイルに切替
• 支援を通して実施したこと・わかったこと

アジェンダ
• 背景
• 現状分析
• 改善方針
• 実施した改善
• 軌道修正（イマココ）
• まとめ

アジェンダ
• 背景
• 現状分析
• 改善方針
• まとめ

背景

背景
• iOS/Androidアプリの継続改善を担当
–企画チームは x社内
–開発チームは外部委託
外部委託（切替前）内製化アジャイル（切替後）
企画
チーム
x社内
外部委託
開発
チーム
企画
チーム
x社内
x社内
開発
チーム
外部支援

背景
• 同業他社（先進的なアジャイルソフトウェア開発に取り組ん
でいるY社）からスカウトされた、新任部長が着任
–現状のプロダクトは、お客様に価値を届けてられて
いないと判断
• トップダウンで、以下の指示が降りてきた
–アプリの大幅リニューアル
–トラッキングすべきメトリクスの刷新
–アジャイルソフトウェア開発導入
–外部委託のままだと契約面で難しいなら、内製化へ

アジェンダ
• 背景
• 現状分析
• 改善方針
• まとめ

<1>現状プロセス
<2>課題は何か
現状分析

<2>課題は何か
現状分析

企画
チーム
x社内
x社内
開発
チーム
ヒアリング
を実施

• 決定したスコープの変更が、開発着手後に頻繁に発生
• 仕様書の差し替えが、開発着手後に随時発生
• 仕様書がFIXしたのは、開発完了後
長いもので8w
短いものは4w

<2>課題は何か
現状分析

<2>課題は何か
1. 開発チームが価値を生む作業に集中できない
A) さまざまなチケットが、分類されずに混在していた
B) 決定したスコープに対する変更が、頻繁に発生
C) スコープの変更に伴う、諸作業による無駄が発生
2. 企画チームと開発チームが分断されている
A) 開発対象の伝達は、従来型の「機能仕様書」
B) 開発中のプロセスが、ブラックボックス
C) 企画チームと開発チームが、一体となっていない

<2>課題は何か
1. 上流工程（他部門調整やビジネス価値精査）に時間が
かかるチケット
2. 企画部門内で仕様確定して、開発着手できるチケット
3. 臨時で発生する調査や、障害対応のチケット

<2>課題は何か
1. iOS/Androidのバージョンアップや、リリース後の不具合
に対する緊急対応により、スコープの変更が頻繁に発生
1. 緊急度の高い障害対応チケットが発生すると、開発チームに
差し込みを依頼
2. 代わりに、合意済チケットの先送り調整を実施
2. スコープ外だった要求を、後からねじ込んでいた
1. 開発着手後に重要なチケットの仕様が確定すると、差し込みを依頼
2. 代わりに、合意済チケットの先送り調整を実施

<2>課題は何か
1. 頻発するチケットの出し入れに対する諸対応
1. スケジュールの再調整
2. 作業担当者・作業内容の再調整
3. スコープ変更に応じて、受領した仕様書を更新

<2>課題は何か
1. 開発する機能がお客様にどのような「価値」を
もたらすのかが、開発チームに伝わらない
2. 開発に至った背景や目的が、開発チームに伝わらない

<2>課題は何か
1. 外部委託先が開発をどう進めているかについて、
企画チームは把握していない
2. 企画チームのマインドセットは
「我々は、要件を開発チームに伝えた。
開発チームは責任をもって、全部やってくれればよい」
（外部委託体制なので、これが当然）

<2>課題は何か
B) 開発中のプロセスがブラックボックス
1. 企画チームと開発チームが、自己学習する1つのチームに
なっていない
1. 開発の機動性・柔軟性の阻害要因となっている
2. 内製化に向けた障壁となっている

アジェンダ
• 背景
• 現状分析
• 改善方針
• まとめ

改善方針
• アジャイルソフトウェア開発導入を通して
1. タイムボックス型開発でリズムを作る
2. 自己学習するチームを作る
※前提と制約
» 外部委託だった開発チームは、内製化へ切替済
▸ 契約切替済、同一建物へ作業場所を変更済
» 既存のツールであるRedmineは、そのまま継続
▸ Redmineは複数部門共通資産
▸ 自分たちの要件だけが理由で、プラグインをあてたり、
チケット大分類（トラッカー）変更は、ハードルが高い

改善方針：目指したい姿
プロダクト
Log
仮説スプリント
計画
ふりかえり
スプリント
スプリント
バックログ
デイリー
スクラム
プロダクト
バックログ
評価用
成果物
仮説検討
価値検討仕様検討
オポチュニティ
バックログ
価値評価
リーン
キャンバス
.....
:::::
:::::
:::::
:::::
:::::
:::::
.....
:::::
:::::
:::::
:::::
:::::
:::::
.....
:::::
:::::
:::::
:::::
:::::
:::::
ペルソナ
カスタマー
ジャーニーマップ
インセプション
デッキ
サービス
ブループリント
アーキテクチャ
設計
アーキテクチャビジョン
& デザイン設計
テクニカル
ソリューション技術
検討
スプリント
レビュー
ToDo Ready In Progress Done Feedback
かんばん
価値計測出荷
プロダクト
利用

プロダクト
Log
計画
ふりかえり
スプリント
スプリント
バックログ
デイリー
スクラム
プロダクト
バックログ
評価用
成果物
仮説検討
バックログ
価値評価
リーン
キャンバス
.....
:::::
:::::
:::::
:::::
:::::
:::::
.....
:::::
:::::
:::::
:::::
:::::
:::::
.....
:::::
:::::
:::::
:::::
:::::
:::::
ペルソナ
カスタマー
デッキ
サービス
設計
テクニカル
検討
スプリント
レビュー
かんばん
価値計測出荷
プロダクト
利用
リーン
スクラム
アーキ
テクチャ
本番運用

プロダクト
Log
計画
ふりかえり
スプリント
スプリント
バックログ
デイリー
スクラム
プロダクト
バックログ
評価用
成果物
仮説検討
バックログ
価値評価
リーン
キャンバス
.....
:::::
:::::
:::::
:::::
:::::
:::::
.....
:::::
:::::
:::::
:::::
:::::
:::::
.....
:::::
:::::
:::::
:::::
:::::
:::::
ペルソナ
カスタマー
デッキ
サービス
設計
テクニカル
検討
スプリント
レビュー
かんばん
価値計測出荷
プロダクト
利用
リーン
スクラム
アーキ
テクチャ
本番運用
チケット管理は4分類
1
2 3
4
スプリント
バックログ
プロダクト
バックログ
バックログ
かんばん

プロダクト
Log
計画
ふりかえり
スプリント
スプリント
バックログ
デイリー
スクラム
プロダクト
バックログ
評価用
成果物
仮説検討
バックログ
価値評価
リーン
キャンバス
.....
:::::
:::::
:::::
:::::
:::::
:::::
.....
:::::
:::::
:::::
:::::
:::::
:::::
.....
:::::
:::::
:::::
:::::
:::::
:::::
ペルソナ
カスタマー
デッキ
サービス
設計
テクニカル
検討
スプリント
レビュー
かんばん
価値計測出荷
プロダクト
利用
リーン
スクラム
アーキ
テクチャ
本番運用
チケット管理は4分類
1
2 3
4
スプリント
バックログ
プロダクト
バックログ
バックログ
かんばん
• アイディア出し中
• 問題が本当にあるか確認中
• プロトタイプによる検証中
で、開発着手前のものは、
「オポテュニティバックログ」
で管理
現在、開発チームが
着手中のタスクは
「スプリントバックログ」
で管理
開発計画のサイクル
に入らないタスクは
「かんばん」
で管理
今後開発予定のものは、
「プロダクトバックログ」
で管理
次のスプリント計画前までに、
• バックログ見直し
• ユーザーストーリー見直し
• ストーリーテスト作成
• ストーリーポイント見直し
• 価値・リスク観点での優先順位見直し
を実施しておく

• 1週間の仕事量
使い続け
させる
作る計画を
立てて
作る計画を
まわす
作る
スクラム
～スプリントバックログ～
本番運用
～かんばん～
月火水木金計
午前 ○ ○ ○ ○ ○
午後1 ○ ○ ○ ○ ○
午後2 ○ ○ ○ ○ ○
1人 3 3 3 3 3 15
5人 15 15 15 15 15 75

• スプリントバックログとかんばんの比率を計画
1スプリント
=2週間
スプリント
X
スプリント
X+1
スプリント
X+2
スプリント
X+3
スプリント
X+4
スプリント
バックログ
100 60 80 100 85
かんばん 50 90 70 50 65
合計
75×2週間=
150 150 150 150 150
本番リリース後は、
障害対応や調査依頼が増えるので
かんばんの割合を増やす
本番リリースがない時は
スプリントバックログの
割合を増やす

• スプリントバックログとかんばんの比率を計画
–数スプリント先／数ヶ月後までの期間
–その結果、企画チームから見れば、
「いつまでに要件を伝えれば、リリースしたい時期
にリリース可能なのかがわかる」
スプリント
X
スプリント
X+1
スプリント
X+2
スプリント
X+3
スプリント
X+4
スプリント
X+5
スプリント
X+6
スプリント
X+7
スプリント
バックログ
100 35 80 100 85 55 80 40
かんばん 50 85 70 50 65 80 70 95
合計 150 120 150 150 150 135 150 135
祝日や予定休・突発休の分だけ
合計ポイントを減らして計画
プロダクトロードマップに
あわせてリリースしたい時期
リリースしたい時期に間に合わせる為に
開発をはじめる時期を、逆算して計画
少なくともこの時期までに企画側内で承認
を取り、Goを出せば良いことがわかる
リリース前の非機能要件等の確認結果への
対応工数を、かんばん側にあらかじめ計画
リリース後の対応工数を
かんばん側に計画

アジェンダ
• 背景
• 現状分析
• 改善方針
• まとめ

実施した改善

実施した改善
A) 既存チケットの整理
B) アジャイルソフトウェア開発導入準備
C) Redmine環境の整備
D) チケット起票・バックログ運用ルール整備
E) 開発チームの進捗状況可視化

実施した改善
A) 既存チケットの整理
–同一プロジェクト内に起票されたすべてのチケット
» 以下に分類して整理

実施した改善
B) アジャイルソフトウェア開発導入準備
–企画チーム・開発チームを対象に、基礎講座を実施
–プロダクトオーナーを対象に、2日間実践研修を実施
–スプリントスケジュールを作成し、Wikiに掲載
–スケジューラーへ、会議室予約と共に一斉入力

実施した改善
C) Redmine環境の整備
–プロジェクトを追加
» かんばん
» プロダクトバックログ
» オポチュニティ
–各種ルール改善に伴い、バージョンや必要になった
項目を設定

実施した改善
D) チケット起票・バックログ運用ルール整備
–バックログ起票時の入力内容、形式、タイミング、
内容について、起票ルールを整備し、Wikiに掲載

実施した改善
E) 開発チームの進捗状況可視化
–企画チームが、開発チームの進捗状況を正しく把握
出来るよう、メトリクスを設定
» バーンダウン／バーンアップチャートを作成し、毎朝共有
▸ Redmineアドオンなしのため、別途チャート作成アプリを開発
» チケット総数、各種工数、進捗率を、毎朝定点観測
▸ Redmineアドオンなしでは自動集計
できず、Excelで作りこんだ
（無駄な工数・・）
▸ 定点観測結果は、Redmineチケット
のコメントへ毎朝反映
▸ 現状、GxPが代わりに集計作業中

実施した改善
A) スプリントプランニングの導入
B) ふりかえりの導入
C) 朝会の改善
D) プロダクトバックログリファインメントの導入
E) 見積りプロセスの改善

実施した改善
A) スプリントプランニングの導入
※Redmineアドオンなしだと、優先順位による並び替えが微妙
※企画の意図を開発に伝えるため、別途Excelで優先順位を共有
No. タイトルプラクティス内容
1-2 要件提示
ミーティン
グの運用
ルール
• 参加者：企画チーム、開発チームを合わせた全員
• 実施タイミング：毎スプリントの開始直後（１H程度）
• 実施内容：
1. 企画チームが、2-2. のチケット起票ルールに従ってチケットを起票し、ミーティングに臨む。
2. 企画チームが、１スプリントで実施できるチケット数を考慮の上、実施対象候補を選定し、優先順位を記入しておく。
3. 企画チームが、選定したチケットについて、順次開発チームに説明を行う。
4. 開発チームは、見積りを行う上で不明な点があった場合、企画チームに質問を行う。
• MTG終了時の状態：
1. 必要なチケットが全て起票され、開発チームに説明が終わっている事。
2. 提示されたチケットに対して、持ち帰り確認事項が明らかになっている事。
3. 持ち帰り確認事項については、一両日中に確認を行いチケット更新する事。
2-3 要件合意
ミーティン
グの運用
ルール
• 参加者：企画チーム、開発チームを合わせた全員
• 実施タイミング：要件提示MTG終了後3～4日目（1H程度）
• 実施内容：
1. 優先順位順に開発の見積もった予定工数を一覧化し、次のスプリントで開発する範囲を合意する。
2. チームのトータル工数120pt（4人×3pt×10日）とし、このうち100をスプリントバックログに、
20をかんばんに振り分ける
（振り分けは前スプリントまでの実績を元に毎回見直す）。
3. 連休や予定休などがあるときは120ptから必要な工数を差し引いて計画する。
• MTG終了時の状態：
1. 会議終了時点で、当該スプリントで開発するスコープが確定している事（＝開発するチケットが決定している事）。
2. チケットの優先順位が明確になっている事。

※できればやりたかったこと
• かんばんとバックログのチケットを通した
優先順位を、企画チームと開発チームで共有
–JIRA Software だと、アドオンなしで実現可能
かんばんとバックログ
それぞれに起票された
チケットを通して、
優先順位順にソート

実施した改善
B) ふりかえりの導入
–個人ふりかえりとチームふりかえりの両方を実施
» 改善に対する意識の芽生え・定着

実施した改善
C) 朝会の改善
–朝会での報告内容を「スプリントゴールを意識した
内容」へ改善（最新のスクラムガイドより）
» 報告内容の改善に伴い、朝会のアジェンダを整備
・昨日やったことは？
・今日やる事は？
・何か困ってることは？
・開発チームがスプリントゴールを達成する
ために、昨日やったことは？
・開発チームがスプリントゴールを達成する
ために、今日やる事は？
・私や開発チームがスプリントゴールを達成
するときの障害物を目撃したか？
改善前改善後

実施した改善
D) プロダクトバックログリファインメントの
導入
–かんばんとバックログに起票されている内容および
実施時期について、チーム全員で見直しを実施

実施した改善
E) 見積プロセスの改善
–見積単位を再設定 - 1日3PTとし、1PTは2時間前後
–相対見積（プランニングポーカー）の導入
–レビュー／テストは実績を元に、見積工数を見直し
プランニングポーカーに使用しているカード

アジェンダ
• 背景
• 現状分析
• 改善方針
• まとめ

軌道修正（イマココ）

• 改善着手から3か月経過し、ふりかえりを実施
–企画チームの反応
» スプリントの延長が頻発し、そのたびにリスケを行った
▸ リリース後の障害が頻発し、品質向上に対する対応を差し込んだ
▸ リリース回数を増やさずに対応するため、リリース延期で対応した
–開発チームの反応
» 見積の精度は、かなり改善した
▸ 見積と実績の差が、以前と比べてかなり小さくなった
▸ 企画チームと開発チーム間、および開発チームメンバー間の認識の
ズレや相違を、スプリント前に検出できるようになった
» 企画チームとの連携がうまくとれるようになった
▸ 仕様確認や障害対応中のやりとりが劇的に改善した

• チケット数、チケット分類ごとの工数実績等な
どを集計しなおし、何が起きていたのかを調査
–実際には何が起きていたのか
» アプリリニューアルの結果、品質が不安定になっていた
▸ 既存仕様の把握が十分でなかった（隠された仕様など）
» 対応時の想定以上に、品質安定に時間がかかり、
リスケせざるを得なくなっていった
▸ 最初の3か月(実働12週)のうち、不具合対応でスプリントを中断して
いた期間は、結果的に3週もあった
※これでは、プロセス改善の評価はできない
▸ それ以前の問題

• 改善方針に対する中間評価
» 毎スプリント毎にスプリントの延期をしており、
まだまだ改善できたといえる状況ではない
▸ とはいえ、開発チームが抱えているタスクの内訳を詳細に分析した
ことで、どうしたらよさそうか道筋は見えてきた
▸ 引き続き、各施策を実施していく
» 成果は出てきており、手応えも感じられるようになった
▸ とはいえ、優先順位の共有については、Excelで頑張っているのが
現状で、果たしてこのままでよいのかどうか
▸ ツールでの改善をすべきかどうか、要検討

アジェンダ
• 背景
• 現状分析
• 改善方針
• まとめ

まとめ

今日お話ししたこと
• iOS/Androidアプリ開発を外部委託して
いたチームが、内製化アジャイルに切替
• 支援を通して実施したこと・わかったこと

まとめ
• 外部委託から内製化アジャイルへスムーズに
切り替えるために
–現状分析を行った上で、
改善方針を決めて一つ一つ実施していくとよい

まとめ
• とはいえ、品質が安定していないのに、
プロセス改善をするのは、とてもツライ
–品質安定させてからやったほうが、本来はよいはず
–現場で何が起きているかを把握するためには、
定点観測時のメトリクスを何に設定するかがカギ
• こんなツールがあると便利
–かんばんとバックログを通した優先順位付け
–バーンダウン・バーンアップの自動作成
–定点観測用の、各数値の自動集計

お知らせ

一緒に働く仲間を募集中です
http://gxp.co.jp/recruit/career.html

ご清聴ありがとうございました！
コンタクト先 URL
Blog http://fullvirtue.com/
Twitter https://twitter.com/fullvirtue
Facebook https://www.facebook.com/fullvirtue
Email fullvirtue@gmail.com
資料公開場所 http://slideshare.net/fullvirtue/
これまで登壇してきた資料はこちらで公開しています！
是非ご覧ください！
関満徳
せきみつのり
グロースエクスパートナーズ株式会社 ITアーキテクト
Microsoft MVP for Visual Studio and Development Technologies
ITサービス開発全般のコンサルティング、開発、運用を
一括して手掛けながら、「顧客価値の創造」と「持続可
能な仕組み創り」をテーマとしたアジャイル・プロダク
トマネジメントのワークショップデザインを数多く実施。
全国各地でファシリテーターとしても活躍。

CONFIDENTIAL
 本文書は、グロースエクスパートナーズ株式会社が著作権その他の権利を有する営業秘密（含サプライヤー等第三者が権利を有するもの）
です。
 当社の許可なく複製し利用すること、また漏洩することは「著作権法」「不正競争防止法」によって禁じられております。
 本資料内の社名・製品名は各社の登録商標です。

外部委託から内製化アジャイルへの切替支援を通してわかったこと #augj

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a 外部委託から内製化アジャイルへの切替支援を通してわかったこと #augj

Semelhante a 外部委託から内製化アジャイルへの切替支援を通してわかったこと #augj (20)

Mais de 満徳関

Mais de 満徳関 (20)