アジャイルジャパン2015 講演資料

1. アジャイル開発チームと共に歩む ~発注側から観るアジャイル開発~ 荒本、山田、川上 KDDI株式会社サービス企画本部クラウドサービス企画開発部

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 d2 はじめに POってこんなに大変開発マネージャーの苦労アジャイル開発を成功させるために変えたこと

3. はじめに

4. プロジェクトの概要など

5. グローバルクラウドと高品質なキャリアクラウドを一括提供 KDDIのクラウド戦略 Multi Network Multi Use Multi Device ベーシックパック

6. 1) スケール Scale 2) クオリティ Quality 3) ワンストップ OneStop ・クラウドは先行投資型で、規模の経済が働くモデル・通信キャリアが従来やってきたビジネスモデルそのもの・コンシューマサービス基盤としても活用・クラウドは電気、ガス、水道と同じユーティリティサービス・社会基盤を提供し続けてきたキャリアオペレーション・24時間365日サービスを提供し続ける万全の保守体制・クラウドは安定したネットワークの確保が前提・データセンターから、クラウド、ネットワーク、デバイスまで提供・障害の切り分け、管理者エンドユーザまで、幅広くサポートなぜキャリアがクラウドなのか？

7. アイデンティティ管理は、これからの時代のパーソナルなFW Trusted FW KDDI Business ID~IDaaSをスタート

8. クラウドサービスのご利用をより安全・安心・簡単にするために社内社外場所デバイス許可済未許可認証ワンタイムパスワード着信認証 27635 64 各種クラウドサービスI D KDDI Business ID ~ IDaaS をスタート~

9. 直前の案件 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 プロジェクトメンバー（今日のスピーカー）３人の紹介

10. ベンダが出来るって言ってるのに、なんで出来ないって言うの（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人の関係性-直前のプロジェクト-

11. 一緒にセミナーに出て話をする関係 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人の関係性-現在-

12. 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 今日の話題

13. POって大変

14. 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 社内での役割サービス企画お客様（法人）社内業務部門社内開発部門経営層要求提示予算取得要求取り纏め要求取り纏め営業部門提案/提供市場、ステークホルダの動向から売れるサービスの企画/実行を行う役割

15. 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のきっかけ

16. 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

17. 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の市場は先読みが容易ではない

18. 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

19. 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円の開発費を見込んでます。」私上長

20. 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への期待変化を抱擁しながらいいものが作れる、しかも早くて安いらしい。なんていい手法なんだ！

21. 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推進者がいたこと

22. 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 社内決裁

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 d23 社内決裁当社の決裁フローは、ウォーターフォール型を前提としたもの固定費変動費× 損益分岐点売上予測

24. 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 ３カ月おきに、サービス/機能追加を投入し、都度決裁をとるスタイルとした固定費変動費決裁① 決裁② 決裁③ ・・・

25. 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アピールを続けた

26. 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推進者がいたこと

27. 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 要件定義＆開発の推進

28. 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 プロジェクトはスタートしたものの、メンバーはウォーターフォール型しか経験したことがない要件定義基本設計詳細設計開発テストここまでが企画の仕事ここからは開発の仕事

29. 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 ・・・

30. 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 開発ﾁーﾑ

31. 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」いかにして作りこまないかを追求しない限り、早くて安くていいものは作れない

32. 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サービスへのログインが人毎に場所、デバイスによって、制御されること大きなストーリー

33. 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ヶ月目このベロシティだと、いつリリースできる？

34. 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サービスへのログインができる ②認めれた場所からのログイン可能 ③認められてない場所からのログインは、エラーを出力する ④認められたデバイスからのログイン可能 ⑤認められていないデバイスからのログインはエラーを出力する ① ② ③ ④ ⑤ ⑥ ⑦ ⑧ ⑨

35. 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が持つ

36. 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ヶ月目

37. 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を繰り返し、改善活動を全員に浸透例：開発タスクの消化が見積時間を大幅に超過例：超過することが分かった時点でチーム内でミーティング

38. 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.

39. 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ヶ月目

40. 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 ストーリー完了数（累計）初期中期後期

41. 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推進者がいたこと

42. 開発マネージャーの苦労

43. アジャイル開発との出会い

44. 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開発していた時表面的には知ってはいたが・・・アジャイル開発とは

45. 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開発していた時表面的には知ってはいたが・・・アジャイル開発とは「うちの会社では無理だな。」

46. 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 自社で開発できる人達の開発手法だよね

47. 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に委託するケースが多い

48. 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 開発することを走りながら決めるなんて、どうやって会社の承認を取るのだ？

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

50. 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 成果物を定義しない発注なんてできない！

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

52. 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 長いリリースサイクルによりサービス競争力の低下ベンダ丸投げにより技術力の低下技術の目利きが出来ないための品質の低下対ベンダ、対部門間の牽制により角が取れた丸いサービス

53. 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.

54. 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 受発注の関係社内部門との関係

55. 変えたことその１開発チームの在り方を変える

56. 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作成と受入試験これまでの開発チーム

57. 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だけにアジャイル開発してもらっても、抱えている課題解決にならない • スプリントを回すために実装まで理解が必要これまでの開発チームアジャイル開発を始めるには

58. 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 自社でプログラミングする内製を開発方針とする

59. 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 自社でプログラミングする内製を開発方針とするしかし、時間が掛かる

60. 協力パートナー 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 外部のパートナーを社内に置き、社員と共同開発することでスキルを吸収開発チーム協力パートナー

61. 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 トレーニングより実践（ペアプロ）が圧倒的に速い • アーキテクチャー設計・ミドルウェア製品選定を自らが決定 • プログラミング未経験者が、６ヶ月間のプロジェクト期間で商用コード実装

62. 変えたことその２受発注の関係を変える

63. 受発注の壁 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 （受注側）壁

64. 受発注の壁 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 （受注側）壁牽制コミュニケーション・ロスリスクを取らないテクノロジー

65. 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ベンダを縦の関係から横の関係へ

66. 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 開発企画と開発者の距離が遠く、見通せない時間距離

67. 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 横の関係へ企画チーム開発チームリリース検収パートナー決裁企画バックログ契約スクラムマスタ開発企画部門と開発者が一つのチーム

68. 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 そのためには契約形態を変える契約時に成果物が定められない請負契約は向かないアジャイル開発では

70. 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 契約を変える準委任契約発注側受注側成果物の責任を負う覚悟言われた通り実装するだけでは無く、成功のために個人の技術スキルを発揮

71. 変えたことその３社内部門との関係を変える

72. 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作成競争入札技術評価選定発注システム要求仕様請負契約開発提案書

73. 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 調達部門との関係を変えるアジャイルではパートナーのエンジニアスキルセットで競争入札して評価エンジニアチームの工数を調達

74. 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社を選定した混成のチーム

75. 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作成競争入札技術評価選定発注求められるスキルセット準委任契約エンジニアチーム提案書業務フローは変えない通常アジャイル

76. 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 運用部門との関係を変える電気通信事業者としてシステムの品質が最も大切

77. 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 運用部門との関係を変える重大障害を起こさないため開発・運用プロセスを細かに定めて品質を守っている

78. 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の記載項目運用要件設計書レビュー技術評価

79. 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 運用部門との関係を変える開発プロセスを逸脱しないことの理解を得る運用部門からもスクラムイベントに参加求められる運用要件をバックログ化

80. ユーザ企業がアジャイル開発を成功させるために欠かせないこと

81. 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だけにアジャイルでお願いしても大して変わらない

82. 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 最も大切なことアジャイル開発とは開発部門における開発手法の一つではない

83. 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 最も大切なこと発注側のユーザ企業が変わらなければアジャイルで変化は起きない

84. 次への取り組みイノベーションを生み出す開発チームへ

85. 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 目指すサービス開発プロセス（３つのループ）企画チーム開発チームアイディア仮説試作テスト分析改善商用サービス開発リリースサービス化決定フィードバックループスモールスタートし段階的に大きくしていくアイディアをプロト開発、価値のあるものをサービス化目に見えるものをユーザ（社内/社外）に見てもらい短いサイクルの中で軌道修正

86. 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 施策決裁施策施策契約施策決裁契約決裁契約決裁契約契約契約

87. 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と開発パートナーが家族になる関係づくりチームの一員としてイノベーションを一緒に起こせる開発チームへキーパーソンとなる優秀なエンジニアが集う開発現場・契約制度へ

88. 最後に

89. 組織やプロセスの壁を突破するには、実務者同士の相互理解と組織的なサポート、上位者の理解が必要。 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

90. Quality Cloud