アジャイル開発チームと共に歩む~発注側から観るアジャイル開発~

KDDI株式会社 サービス企画本部
クラウドサービス企画開発部
荒本、山田、川上はじめにPOってこんなに大変

開発マネージャーの苦労

最後に

2

Copyright © 2015 KDDI Corporation. All Rights Reserved

はじめにプロジェクトの概要など

KDDIのクラウド戦略
グローバルクラウドと高品質なキャリアクラウドを一括提供

Multi
Use

Multi
NetworkMulti
Deviceベーシックパックなぜキャリアがクラウドなのか？

1) スケール Scale・クラウドは先行投資型で、規模の経済が働くモデル
・通信キャリアが従来やってきたビジネスモデルそのもの・コンシューマサービス基盤としても活用

2) クオリティ Quality
・クラウドは電気、ガス、水道と同じユーティリティサービス
・社会基盤を提供し続けてきたキャリアオペレーション・24時間365日サービスを提供し続ける万全の保守体制

3) ワンストップ

OneStop・クラウドは安定したネットワークの確保が前提
・データセンターから、クラウド、ネットワーク、デバイスまで提供
・障害の切り分け、管理者エンドユーザまで、幅広くサポート

KDDI Business ID~IDaaSをスタート

FWTrusted

アイデンティティ管理は、これからの時代のパーソナルなFW

KDDI Business ID ~ IDaaS をスタート~

27635
64社
内許可済

ワンタイム
パスワー
ド社
外未許
可

着信認証

デバイス

認証

I
D
場所

各種クラウドサービ
ス

クラウドサービスのご利用をより安全・安心・簡単にするためにプロジェクトメンバー（今日のスピーカー）３人の紹介
直前の案件
WaterfallKDDI Business ID
Agile(Scrum)

企画担当

PO

開発部マネージャー

開発マネージャープロジェクトリーダ

PM/SCM

9Copyright © 2015 KDDI Corporation. All Rights Reserved

3人の関係性-直前のプロジェクトベンダが出来るって言ってるのに、なんで出来ないって言うの（A->K）
現場の事分かってないのに、適当な事言わないで下さい（K->A）
サービスの仕様として無いと駄目な事分かるでしょ（Y->K）
仕様書に書いてないこと作れるわけないじゃん（K->Y）「山田と川上は相性最悪」「荒本と川上は水と油だから合わない」と某部長に言わせた関係。

10

Copyright © 2015 KDDI Corporation. All Rights Reserved

3人の関係性-現在-

一緒にセミナーに出て話をする関係

11

Copyright © 2015 KDDI Corporation. All Rights Reserved

今日の話題
1年前は最悪だった相性が、1年間で何故変化したのか？
そこにアジャイル開発で、POと開発Tの一体感を高めるポイントがあるのでは？

以降、荒本と山田から具体的な話をさせて頂きます。

12

Copyright © 2015 KDDI Corporation. All Rights Reserved

POって大変Agileのきっかけ

14

Copyright © 2015 KDDI Corporation. All Rights Reserved私のミッション（Enterprise向けクラウドサービス企画）

１つのIDであらゆるサービス、システムへ
いつでもどこでも安全に繋がる世界へ
KDDIサービス

グローバルサービス

企業オンプレシステム

IDaaS

15

Copyright © 2015 KDDI Corporation. All Rights Reserved

Moving Target
しかし、Cloud＆Mobileの市場は先読みが容易ではない

16Copyright © 2015 KDDI Corporation. All Rights Reserved

Agileの決断
先読みが難しい⇒変化への抱擁、継続的デリバリー
KDDIサービス

グローバルサービス

企業オンプレシステム

Agile
IDaaS

17

Copyright © 2015 KDDI Corporation. All Rights Reserved

舞台裏「IDaaSの開発ですが、ベンダーさんに見積ってもらい、XX円の開発費を見込んでます。」
私「１年後の市場なんて誰にも分かんないから、Agile型でよろしく！！」
上長18

Copyright © 2015 KDDI Corporation. All Rights Reserved余談：サービス企画の立場からこれまでのWF型Agileへの期待一度出した要件を変更する
ことは、開発費も増え、スケジュールも遅延を招く「やってはいけない行為」

変化を抱擁しながらいいものが作れる、しかも早くて安いらしい。なんていい手法なんだ！

19

Copyright © 2015 KDDI Corporation. All Rights Reservedポイント①
・環境変化への追従からAgileは必然だった
・意思決定者の１人にAgile推進者がいたこと

20

Copyright © 2015 KDDI Corporation. All Rights Reserved

社内決裁

21

Copyright © 2015 KDDI Corporation. All Rights Reserved

社内決裁
当社の決裁フローは、ウォーターフォール型を前提としたもの
売上予測

損益分岐点

×

変動費

固定費

22

Copyright © 2015 KDDI Corporation. All Rights ReservedSmall Start
３カ月おきに、サービス/機能追加を投入し、都度決裁をとるスタイルとした

・・・
決裁③

変動費

決裁②

決裁①

固定費

23

Copyright © 2015 KDDI Corporation. All Rights Reserved注力したこと定期的に経営層にデモを行い、Agileアピールを続けた

24

Copyright © 2015 KDDI Corporation. All Rights Reservedポイント②・環境変化への追従からAgileは必然だった
・意思決定者の１人にAgile推進者がいたこと・Agile型での決済に無理に拘らないこと・経営層にAgileアピールをし続けること25

Copyright © 2015 KDDI Corporation. All Rights Reserved要件定義＆開発の推進
26

Copyright © 2015 KDDI Corporation. All Rights Reservedプロジェクトはスタートしたものの、メンバーはウォーターフォール型しか経験したことがない
要件定義

基本設計
詳細設計
開発
テスト

ここまでが企画の仕事

ここからは開発の仕事
27

Copyright © 2015 KDDI Corporation. All Rights Reserved

始めに取り組んだこと①Scrumによるチーム作り

開発チーム
企画チーム
開発チーム

②AgileトレーニングMVPTeam Building
Less Mass
TDD
・・・
28

Copyright © 2015 KDDI Corporation. All Rights Reserved

特に注力したこと 「Less Mass」

出来るだけ多くのストーリをPOリリースしたい開発
タイムボックス
ﾁーﾑ
29

Copyright © 2015 KDDI Corporation. All Rights Reserved

特に注力したこと 「Less Mass」
いかにして作りこまないかを追求しない限り、早くて安くていいものは作れない

30

Copyright © 2015 KDDI Corporation. All Rights Reserved

特に注力したこと 「Less Mass」
頭では理解したつもりだが立ち上がりは大きなストーリー
ストーリーイメージ：
Aサービスへのログインが人毎に場所、デバイスによって、制御されること

31

Copyright © 2015 KDDI Corporation. All Rights Reserved

特に注力したこと 「Less Mass」
初期は低空飛行のベロシティにこのベロシティだと、いつリリースできる？

1ヶ月目
32

Copyright © 2015 KDDI Corporation. All Rights Reserved

特に注力したこと 「Less Mass」
ストーリー粒度を細かくし、ストーリー単位で実施有無/優先順位を判断
ストーリーイメージ：
Aサービスへのログインが人毎に場所、デバイスによって、制御されること

①

④

⑦

②

⑤⑧

③

⑥⑨

①Aサービスへのログインができる②認めれた場所からのログイン可能③認められてない場所からのログインは、エラーを出力する④認められたデバイスからのログイン可能⑤認められていないデバイスからのログインはエラーを出力する
33

Copyright © 2015 KDDI Corporation. All Rights Reserved

特に注力したこと 「Less Mass」
開発メンバーにもストーリー実施可否の権限を与えた

×：要件を定義されたから作る○：必要性を理解したから作る※但し、最終決定権はPOが持つ

34

Copyright © 2015 KDDI Corporation. All Rights Reserved

特に注力したこと 「Less Mass」
徐々にベロシティが上がってきた

1ヶ月目

2ヶ月目
35

Copyright © 2015 KDDI Corporation. All Rights Reserved

特に注力したこと 「Team Building」
週に１回KPTを繰り返し、改善活動を全員に浸透

例：
超過することが分かった時点でチーム内でミーティング

例：
開発タスクの消化が見積時間を大幅に超過
36

Copyright © 2015 KDDI Corporation. All Rights Reserved

特に注力したこと 「Team Building」

Scrumチームは崩さずKPTを繰り返すあとは、communicate,communicate,communicate.
37

Copyright © 2015 KDDI Corporation. All Rights Reserved

結果として、変化も抱擁しながら、当初計画通りにリリース完遂

1ヶ月目

2ヶ月目
38

Copyright © 2015 KDDI Corporation. All Rights Reserved実際のストーリー消化ストーリー完了数（累計）

後期

中期
初期
#1

#2

#3

#4

#5

#6

#7

#8

#9

#10

#11

#12

39

#13

#14

#15

#16

#17

#18

#19

#20

#21

#22

#23

Copyright © 2015 KDDI Corporation. All Rights Reservedポイント③・環境変化への追従からAgileは必然だった
・意思決定者の１人にAgile推進者がいたこと・Agile型での決済に無理に拘らないこと
・DemoによるAgileアピールをし続けること

・Agileは魔法の杖ではないことを理解する
・要件定義のマインドチェンジを徹底すること・ﾒﾝﾊﾞｰ全員がジブンゴト化する風土を作ること

40Copyright © 2015 KDDI Corporation. All Rights Reserved

開発マネージャーの苦労アジャイル開発との出会い

W/F開発していた時アジャイル開発とは表面的には知ってはいたが・・・

43

Copyright © 2015 KDDI Corporation. All Rights Reserved

W/F開発していた時アジャイル開発とは表面的には知ってはいたが・・・「うちの会社では無理だな。」

44

Copyright © 2015 KDDI Corporation. All Rights Reservedなぜ「うちの会社では無理」と思ったいたか

1

2

3

自社で開発できる人達の開発手法だよね

45

Copyright © 2015 KDDI Corporation. All Rights Reservedなぜ「うちの会社では無理」と思ったいたか

1

2

3

自社で開発できる人達の開発手法だよね
当社では 社内にプログラマという職種の人はいない 仕様を書いて実装はSIerに委託するケースが多い

46

Copyright © 2015 KDDI Corporation. All Rights Reservedなぜ「うちの会社では無理」と思ったいたか

1

23開発することを走りながら決めるなんて、どうやって会社の承認を取るのだ？

47

Copyright © 2015 KDDI Corporation. All Rights Reservedなぜ「うちの会社では無理」と思ったいたか

123

開発することを走りながら決めるなんて、どうやって会社の承認を取るのだ？
当社では• 開発内容• スケジュール
• コストをコミットして開発承認される仕組み
48

Copyright © 2015 KDDI Corporation. All Rights Reservedなぜ「うちの会社では無理」と思ったいたか

1

2

3

成果物を定義しない発注なんてできない！

49

Copyright © 2015 KDDI Corporation. All Rights Reservedなぜ「うちの会社では無理」と思ったいたか

1

2

3

成果物を定義しない発注なんてできない！
当社では、• 開発部門が作成した仕様書に基き、発注先を調達部門が決定する仕組み

50

Copyright © 2015 KDDI Corporation. All Rights Reservedしかし、課題も抱えていた1

長いリリースサイクルによりサービス競争力の低下

2

ベンダ丸投げにより技術力の低下
技術の目利きが出来ないための品質の低下

3

対ベンダ、対部門間の牽制により角が取れた丸いサービス
51

Copyright © 2015 KDDI Corporation. All Rights Reserved

Let’s try anyway.

52

Copyright © 2015 KDDI Corporation. All Rights Reserved変えようとしたこと

1

開発チームの在り方

2

受発注の関係3

社内部門との関係

53

Copyright © 2015 KDDI Corporation. All Rights Reserved変えたこと その１
開発チームの在り方を変えるこれまでの開発チーム

RFP作成と受入試験

55

Copyright © 2015 KDDI Corporation. All Rights Reservedこれまでの開発チーム

RFP作成と受入試験

アジャイル開発を始めるには設計・実装まで踏み込む• SIerだけにアジャイル開発してもらっても、抱えている課題解決にならない• スプリントを回すために実装まで理解が必要
56

Copyright © 2015 KDDI Corporation. All Rights Reserved

自社でプログラミングする内製を開発方針とする

57

Copyright © 2015 KDDI Corporation. All Rights Reserved

自社でプログラミングする内製を開発方針とする
しかし、時間が掛かる

58

Copyright © 2015 KDDI Corporation. All Rights Reserved外部のパートナーを社内に置き、社員と共同開発することでスキルを吸収
開発チーム

協力パートナー協力パートナー59

Copyright © 2015 KDDI Corporation. All Rights Reservedトレーニングより実践（ペアプロ）が圧倒的に速い••

アーキテクチャー設計・ミドルウェア製品選定を自らが決定
プログラミング未経験者が、６ヶ月間のプロジェクト期間で商用コード実装

60

Copyright © 2015 KDDI Corporation. All Rights Reserved変えたこと その２受発注の関係を変える日本のソフトウェア開発の課題

受発注の壁壁KDDISIer

（受注側）

(発注側）

62

Copyright © 2015 KDDI Corporation. All Rights Reserved日本のソフトウェア開発の課題

受発注の壁
壁KDDI
(発注側）

牽制

SIer（受注側）

コミュニケーション・ロス
リスクを取らない
テクノロジー

イノベーションが起こりにくい63

Copyright © 2015 KDDI Corporation. All Rights Reserved変えたかったこと

ユーザ企業とSIベンダを縦の関係から横の関係へ
64

Copyright © 2015 KDDI Corporation. All Rights Reserved

縦の関係から企画と開発者の距離が遠く、見通せない

時間
企画チーム

企画

リリース

決裁
開発チーム

距離仕様
確定

開発
管理

検収

契約

SIベンダ

PM

開発会社

開発
65

Copyright © 2015 KDDI Corporation. All Rights Reserved

横の関係へ

企画部門と開発者が一つのチーム

企画チーム

企画

バックログ

決裁
開発チーム

開発

パートナー

リリース

スクラムマスタ契約
検収66

Copyright © 2015 KDDI Corporation. All Rights Reservedそのためには契約形態を変える
アジャイル開発では契約時に成果物が定められない
請負契約は向かない
67

Copyright © 2015 KDDI Corporation. All Rights Reserved

契約を変える

準委任契約

68

Copyright © 2015 KDDI Corporation. All Rights Reserved

契約を変える

準委任契約
発注側 成果物の責任を負う覚悟言われた通り実装するだけ
受注側 では無く、成功のために個人の技術スキルを発揮
69

Copyright © 2015 KDDI Corporation. All Rights Reserved変えたこと その３
社内部門との関係を変える

調達部門との関係を変える
これまで成果物に対する調達• 開発部門は仕様書（RFP）を定義• 調達部門は仕様を満たすものを如何に安価に購入するか• 競争入札が原則
RFP作成

競争入札

技術評価

システム要求仕様

開発提案書
71

選定
発注

請負契約

Copyright © 2015 KDDI Corporation. All Rights Reserved

調達部門との関係を変える
アジャイルではエンジニアチームの工数を調達パートナーのエンジニアスキルセットで競争入札
して評価
72

Copyright © 2015 KDDI Corporation. All Rights Reserved

開発に必要な技術スキルセットでRFP・選定
要求スキルセットを提示し、エンジニアチームの提案を依頼

スキルセット例：
アジャイル開発の経験
テスト駆動開発
フロントエンドMVCなど
求める必須レベルとのマトリクスで提案依頼
提案内容をポイント化し定量評価2社を選定した混成のチーム
73

Copyright © 2015 KDDI Corporation. All Rights Reserved

調達方法の従来との比較

業務フローは変えない
通常
RFP作成

競争入札

技術評価

システム要求仕様

開発提案書

選定
発注
請負契約

アジャイル
RFP作成

求められる
スキルセット

競争入札

技術評価

エンジニアチーム
提案書
74

選定
発注

準委任契約

Copyright © 2015 KDDI Corporation. All Rights Reserved

運用部門との関係を変える

電気通信事業者としてシステムの品質が最も大切

75

Copyright © 2015 KDDI Corporation. All Rights Reserved

運用部門との関係を変える

重大障害を起こさないため開発・運用プロセスを細かに定めて品質を守っている76

Copyright © 2015 KDDI Corporation. All Rights Reserved

運用部門との関係を変えるウォーターフォール型がベースの開発プロセスの中でアジャイルを行う場合の差分を明確化
RFPの記載項目

運用要件

設計書レビュー

技術評価
77

Copyright © 2015 KDDI Corporation. All Rights Reserved

運用部門との関係を変える
開発プロセスを逸脱しないことの理解を得る

運用部門からもスクラムイベントに参加求められる運用要件をバックログ化
78

Copyright © 2015 KDDI Corporation. All Rights Reservedユーザ企業でアジャイル開発を成功させるために欠かせないこと

最も大切なこと

SIerだけにアジャイルでお願いしても大して変わらない

80

Copyright © 2015 KDDI Corporation. All Rights Reserved最も大切なこと

アジャイル開発とは開発部門における開発手法の一つではない81

Copyright © 2015 KDDI Corporation. All Rights Reserved最も大切なこと

発注側のユーザ企業が変わらなければアジャイルで変化は起きない

82

Copyright © 2015 KDDI Corporation. All Rights Reserved次への取り組み
イノベーションを生み出す開発チームへ

目指すサービス開発プロセス（３つのループ）

アイディアをプロト開発、価値のあるものをサービス化
目に見えるものをユーザ（社内/社外）に見てもらい短いサイクルの中で軌道修正
アイ
ディア

企画チーム

改善

仮説

開発チーム
分析

サービス化
決定

試作

商用サービス開発

リリース

テスト

フィードバックループ

スモールスタートし段階的に大きくしていく
84

Copyright © 2015 KDDI Corporation. All Rights Reserved

KDDIと開発パートナーが家族になる関係づくり
決裁

施策の決裁に依存した契約決裁

決裁

施策
契約

契約

施策

施策

契約

契約

契約

契約

契約

パートナー契約期間期間で定額契約決裁決裁

施策

決裁

施策

施策

施策
85

Copyright © 2015 KDDI Corporation. All Rights Reserved

KDDIと開発パートナーが家族になる関係づくりチームの一員としてイノベーションを一緒に起こせる開発チームへ

キーパーソンとなる優秀なエンジニアが集う開発現場・契約制度へ
86

Copyright © 2015 KDDI Corporation. All Rights Reserved

最後に組織やプロセスの壁を突破するには、実務者同士の相互理解と組織的なサポート、上位者の理解が必要。

88

Copyright © 2015 KDDI Corporation. All Rights ReservedQuality Cloud