View
257
Download
2
Category
Preview:
Citation preview
アジャイル開発チームと共に歩む~発注側から観るアジャイル開発~
荒本、山田、川上
KDDI株式会社 サービス企画本部クラウドサービス企画開発部
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d2
はじめに
POってこんなに大変
開発マネージャーの苦労
アジャイル開発を成功させるために
変えたこと
はじめに
プロジェクトの概要など
グローバルクラウドと高品質なキャリアクラウドを一括提供
KDDIのクラウド戦略
Multi
Network
Multi
Use
Multi
Device
ベーシックパック
1) スケール Scale
2) クオリティ Quality
3) ワンストップ OneStop
・クラウドは先行投資型で、規模の経済が働くモデル・通信キャリアが従来やってきたビジネスモデルそのもの・コンシューマサービス基盤としても活用
・クラウドは電気、ガス、水道と同じユーティリティサービス・社会基盤を提供し続けてきたキャリアオペレーション・24時間365日サービスを提供し続ける万全の保守体制
・クラウドは安定したネットワークの確保が前提・データセンターから、クラウド、ネットワーク、デバイスまで提供
・障害の切り分け、管理者エンドユーザまで、幅広くサポート
なぜキャリアがクラウドなのか？
アイデンティティ管理は、これからの時代のパーソナルなFW
Trusted
FW
KDDI Business ID~IDaaSをスタート
クラウドサービスのご利用をより安全・安心・簡単にするために
社内
社外
場所 デバイス
許可済
未許可
認証
ワンタイムパスワード
着信認証
2763564
各種クラウドサービスI
D
KDDI Business ID ~ IDaaS をスタート~
直前の案件
Waterfall
KDDI Business ID
Agile(Scrum)
企画担当 PO
開発部マネージャー 開発マネージャー
プロジェクトリーダ PM/SCM
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d9
プロジェクトメンバー（今日のスピーカー）３人の紹介
ベンダが出来るって言ってるのに、なんで出来ないって言うの（A->K）
現場の事分かってないのに、適当な事言わないで下さい（K->A）
サービスの仕様として無いと駄目な事分かるでしょ（Y->K）
仕様書に書いてないこと作れるわけないじゃん（K->Y）
「山田と川上は相性最悪」
「荒本と川上は水と油だから合わない」
と某部長に言わせた関係。
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d10
3人の関係性-直前のプロジェクト-
一緒にセミナーに出て話をする関係
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d11
3人の関係性-現在-
1年前は最悪だった相性が、1年間で何故変化したのか？
そこにアジャイル開発で、POと開発Tの一体感を高めるポイントがあるのでは？
以降、荒本と山田から具体的な話をさせて頂きます。
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d12
今日の話題
POって大変
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d14
社内での役割
サービス企画
お客様（法人）
社内業務部門
社内開発部門
経営層
要求提示
予算取得
要求取り纏め
要求取り纏め
営業部門
提案/提供
市場、ステークホルダの動向から売れるサービスの企画/実行を行う役割
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d15
Agileのきっかけ
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d16
私のミッション（Enterprise向けクラウドサービス企画）
グローバルサービス 企業オンプレシステムKDDIサービス
１つのIDであらゆるサービス、システムへいつでもどこでも安全に繋がる世界へ
IDaaS
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d17
Moving Target
しかし、Cloud＆Mobileの市場は先読みが容易ではない
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d18
Agileの決断
グローバルサービス 企業オンプレシステムKDDIサービス
IDaaS
先読みが難しい⇒変化への抱擁、継続的デリバリー
Agile
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d19
舞台裏
「１年後の市場なんて誰にも
分かんないから、Agile型でよろしく！！」
「IDaaSの開発ですが、ベンダーさんに見積ってもらい、XX円の開発費を見込んでま
す。」
私
上長
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d20
余談：サービス企画の立場から
これまでのWF型
一度出した要件を変更することは、開発費も増え、スケジュールも遅延を招く「やってはいけない行為」
Agileへの期待
変化を抱擁しながらいいものが作れる、しかも早くて安いらしい。なんていい手法なんだ！
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d21
ポイント①
・環境変化への追従からAgileは必然だった・意思決定者の１人にAgile推進者がいたこと
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d22
社内決裁
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d23
社内決裁
当社の決裁フローは、ウォーターフォール型を前提としたもの
固定費
変動費×損益分岐点
売上予測
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d24
Small Start
３カ月おきに、サービス/機能追加を投入し、都度決裁をとるスタイルとした
固定費
変動費
決裁①
決裁②
決裁③
・・・
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d25
注力したこと
定期的に経営層にデモを行い、Agileアピールを続けた
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d26
ポイント②
・Agile型での決済に無理に拘らないこと・経営層にAgileアピールをし続けること
・環境変化への追従からAgileは必然だった・意思決定者の１人にAgile推進者がいたこと
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d27
要件定義＆開発の推進
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d28
プロジェクトはスタートしたものの、
メンバーはウォーターフォール型しか経験したことがない
要件定義
基本設計
詳細設計
開発
テスト
ここまでが企画の仕事
ここからは開発の仕事
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d29
始めに取り組んだこと
①Scrumによるチーム作り 企画チーム
開発チーム
開発チーム
②Agile
トレーニング
MVP
Team Building
Less Mass
TDD・・・
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d30
特に注力したこと 「Less Mass」
出来るだけ多くのストーリをリリースしたい
タイムボックス
PO
開発ﾁーﾑ
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d31
特に注力したこと 「Less Mass」
いかにして作りこまないかを追求しない限り、早くて安くていいものは作れない
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d32
特に注力したこと 「Less Mass」
頭では理解したつもりだが立ち上がりは
ストーリーイメージ：Aサービスへのログインが人毎に場所、デバイスによって、制御されること
大きなストーリー
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d33
特に注力したこと 「Less Mass」
初期は低空飛行のベロシティに
1ヶ月目
このベロシティだと、いつリリースで
きる？
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d34
特に注力したこと 「Less Mass」
ストーリー粒度を細かくし、ストーリー単位で実施有無/優先順位を判断
ストーリーイメージ：Aサービスへのログインが人毎に場所、デバイスによって、制御されること
①Aサービスへのログインができる②認めれた場所からのログイン可能③認められてない場所からのログインは、エラーを出力する④認められたデバイスからのログイン可能⑤認められていないデバイスからのログインはエラーを出力する
①
②
③
④
⑤
⑥
⑦
⑧
⑨
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d35
特に注力したこと 「Less Mass」
開発メンバーにもストーリー実施可否の権限を与えた
×：要件を定義されたから作る○：必要性を理解したから作る
※但し、最終決定権はPOが持つ
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d36
特に注力したこと 「Less Mass」
徐々にベロシティが上がってきた
1ヶ月目 2ヶ月目
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d37
特に注力したこと 「Team Building」
週に１回KPTを繰り返し、改善活動を全員に浸透
例：開発タスクの消化が見積時間を大幅に超過
例：超過することが分かった時点でチーム内でミーティング
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d38
特に注力したこと 「Team Building」
Scrumチームは崩さず
KPTを繰り返す
あとは、
communicate,
communicate,
communicate.
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d39
結果として、
変化も抱擁しながら、当初計画通りにリリース完遂
1ヶ月目 2ヶ月目
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d40
実際のストーリー消化
#1 #2 #3 #4 #5 #6 #7 #8 #9 #10 #11 #12 #13 #14 #15 #16 #17 #18 #19 #20 #21 #22 #23
ストーリー完了数（累計）
初期
中期
後期
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d41
ポイント③
・Agileは魔法の杖ではないことを理解する・要件定義のマインドチェンジを徹底すること・ﾒﾝﾊﾞｰ全員がジブンゴト化する風土を作ること
・Agile型での決済に無理に拘らないこと・DemoによるAgileアピールをし続けること
・環境変化への追従からAgileは必然だった・意思決定者の１人にAgile推進者がいたこと
開発マネージャーの苦労
アジャイル開発との出会い
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d44
W/F開発していた時
表面的には知ってはいたが・・・
アジャイル開発とは
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d45
W/F開発していた時
表面的には知ってはいたが・・・
アジャイル開発とは
「うちの会社では無理だな。」
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d46
なぜ「うちの会社では無理」と思っていたか
1 2 3
自社で開発できる人達の開発手法だよね
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d47
なぜ「うちの会社では無理」と思っていたか
1 2 3
自社で開発できる人達の開発手法だよね
当社では
社内にプログラマという職種の人はいない
仕様を書いて実装はSIerに委託するケースが多い
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d48
なぜ「うちの会社では無理」と思っていたか
1 2 3
開発することを走りながら決めるなんて、どうやって会社の承認を取るのだ？
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d49
なぜ「うちの会社では無理」と思っていたか
1 2 3
開発することを走りながら決めるなんて、どうやって会社の承認を取るのだ？
当社では• 開発内容• スケジュール• コストをコミットして開発承認される仕組み
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d50
なぜ「うちの会社では無理」と思っていたか
1 2 3
成果物を定義しない発注なんてできない！
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d51
なぜ「うちの会社では無理」と思っていたか
1 2 3
成果物を定義しない発注なんてできない！
当社では、• 開発部門が作成した仕様書に基き、発注先を調達部門が決定する仕組み
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d52
しかし、課題も抱えていた
2
3
1長いリリースサイクルによりサービス競争力の低下
ベンダ丸投げにより技術力の低下技術の目利きが出来ないための品質の低下
対ベンダ、対部門間の牽制により角が取れた丸いサービス
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d53
Let’s try anyway.
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d54
変えようとしたこと
開発チームの在り方
2
3
1
受発注の関係
社内部門との関係
変えたこと その１開発チームの在り方を変える
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d56
RFP作成と受入試験これまでの開発チーム
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d57
RFP作成と受入試験
設計・実装まで踏み込む• SIerだけにアジャイル開発してもらっても、抱えている課題解決にならない
• スプリントを回すために実装まで理解が必要
これまでの開発チーム
アジャイル開発を始めるには
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d58
自社でプログラミングする内製を開発方針とする
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d59
自社でプログラミングする内製を開発方針とする
しかし、時間が掛かる
協力パートナー
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d60
外部のパートナーを社内に置き、社員と共同開発することでスキルを吸収
開発チーム
協力パートナー
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d61
トレーニングより実践（ペアプロ）が圧倒的に速い
• アーキテクチャー設計・ミドルウェア製品選定を自らが決定
• プログラミング未経験者が、６ヶ月間のプロジェクト期間で商用コード実装
変えたこと その２受発注の関係を変える
受発注の壁
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d63
日本のソフトウェア開発の課題
KDDI(発注側）
SIer（受注側）
壁
受発注の壁
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d64
日本のソフトウェア開発の課題
イノベーションが起こりにくい
KDDI(発注側）
SIer（受注側）
壁牽制
コミュニケーション・ロス
リスクを取らないテクノロジー
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d65
変えたかったこと
ユーザ企業と
SIベンダを
縦の関係から
横の関係へ
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d66
縦の関係から
企画チーム
開発チーム
リリース
検収
SIベンダ
開発会社
決裁
企画
仕様確定
開発管理
契約
PM
開発
企画と開発者の距離が遠く、見通せない
時間
距離
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d67
横の関係へ
企画チーム
開発チームリリース
検収
パートナー
決裁
企画バックログ
契約スクラムマスタ
開発
企画部門と開発者が一つのチーム
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d68
そのためには契約形態を変える
契約時に成果物が定められない
請負契約は向かない
アジャイル開発では
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d69
契約を変える
準委任契約
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d70
契約を変える
準委任契約
発注側
受注側
成果物の責任を負う覚悟
言われた通り実装するだけでは無く、成功のために個人の技術スキルを発揮
変えたこと その３社内部門との関係を変える
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d72
調達部門との関係を変える
これまで
成果物に対する調達
• 開発部門は仕様書（RFP）を定義
• 調達部門は仕様を満たすものを如何に安価に購入するか
• 競争入札が原則
RFP作成 競争入札 技術評価選定発注
システム要求仕様 請負契約開発提案書
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d73
調達部門との関係を変える
アジャイルでは
パートナーのエンジニアスキルセットで競争入札して評価
エンジニアチームの工数を調達
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d74
開発に必要な技術スキルセットでRFP・選定
要求スキルセットを提示し、エンジニアチームの提案を依頼
スキルセット例：アジャイル開発の経験テスト駆動開発フロントエンドMVC
など
求める必須レベルとのマトリクスで提案依頼
提案内容をポイント化し定量評価2社を選定した混成のチーム
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d75
調達方法の従来との比較
RFP作成 競争入札 技術評価選定発注
システム要求仕様 請負契約開発提案書
RFP作成 競争入札 技術評価選定発注
求められるスキルセット
準委任契約エンジニアチーム
提案書
業務フローは変えない
通常
アジャイル
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d76
運用部門との関係を変える
電気通信事業者としてシステムの品質が最も大切
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d77
運用部門との関係を変える
重大障害を起こさないため開発・運用プロセスを細かに定めて品質を守っている
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d78
運用部門との関係を変える
ウォーターフォール型がベースの開発プロセスの中でアジャイルを行う場合の
差分を明確化
RFPの記載項目 運用要件
設計書レビュー 技術評価
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d79
運用部門との関係を変える
開発プロセスを逸脱しないことの理解を得る
運用部門からもスクラムイベントに参加
求められる運用要件をバックログ化
ユーザ企業がアジャイル開発を成功させるために欠かせないこと
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d81
最も大切なこと
SIerだけにアジャイルで
お願いしても大して変わらない
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d82
最も大切なこと
アジャイル開発とは開発部門に
おける開発手法の一つではない
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d83
最も大切なこと
発注側のユーザ企業が
変わらなければ
アジャイルで変化は起きない
次への取り組みイノベーションを生み出す開発チームへ
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d85
目指すサービス開発プロセス（３つのループ）
企画チーム
開発チーム
アイ
ディア
仮説
試作
テスト
分析
改善
商用サービス開発
リリースサービス化
決定
フィードバックループスモールスタートし
段階的に大きくしていく
アイディアをプロト開発、価値のあるものをサービス化
目に見えるものをユーザ（社内/社外）に見てもらい短いサイクルの中で軌道修正
KDDIと開発パートナーが家族になる関係づくり
期間で定額契約
施策の決裁に依存した契約
パートナー契約期間
施策
施策
契約
決裁
施策
決裁
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d86
施策
決裁
施策施策
契約
施策
決裁
契約
決裁
契約
決裁
契約契約 契約
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d87
KDDIと開発パートナーが家族になる関係づくり
チームの一員としてイノベーションを一緒に起こせる開発チームへ
キーパーソンとなる優秀なエンジニアが集う開発現場・契約制度へ
最後に
組織やプロセスの壁を突破するには、
実務者同士の相互理解と
組織的なサポート、
上位者の理解
が必要。
C o p y r i g h t © 2 0 1 5 K D D I C o r p o r a t i o n . A l l R i g h t s R e s e r v e d89
Quality Cloud
Recommended