ユーザー企業へのアジャイル導入四苦八苦 - エンタープライズアジャイル勉強会2016年11月セミナー
•
13 likes•17,549 views
2016年11月19日に行われたエンタープライズアジャイル勉強会2016年11月セミナーでの講演「ユーザー企業へのアジャイル導入四苦八苦」の資料です
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to ユーザー企業へのアジャイル導入四苦八苦 - エンタープライズアジャイル勉強会2016年11月セミナー
Similar to ユーザー企業へのアジャイル導入四苦八苦 - エンタープライズアジャイル勉強会2016年11月セミナー (20)
More from Yusuke Suzuki
More from Yusuke Suzuki (10)
Recently uploaded
Recently uploaded (8)
ユーザー企業へのアジャイル導入四苦八苦 - エンタープライズアジャイル勉強会2016年11月セミナー
- 2. 自己紹介 鈴木雄介 • グロースエクスパートナーズ（株） » 執行役員/アーキテクチャ事業本部長 » http://www.gxp.co.jp/ • 日本Javaユーザーグループ » 会長 » http://www.java-users.jp/ • SNS » http://arclamp.hatenablog.com/ » @yusuke_arclamp 1
- 4. アジェンダ • アジャイル“海外文化”問題 • 僕が思うエンタープライズアジャイル • 事例紹介 • フィードバックサイクルについて • プロダクトオーナーについて • アーキテクチャについて • まとめ 3
- 6. アジャイルについて アジャイルソフトウェア開発宣言 • 2001年に公開 • アジャイルにおける「価値」 »プロセスやツール よりも 個人と対話を、 »包括的なドキュメント よりも 動くソフトウェアを、 »契約交渉 よりも 顧客との協調を、 »計画に従うこと よりも 変化への対応を、 5http://www.agilemanifesto.org/iso/ja/ 大事 超大事
- 7. アジャイルについて アジャイル“海外文化”問題 • アジャイルを導入するのに海外の文化をインス トールする必要があるのか？ • 日本の文化に適合させようとするとアジャイル やDevOpsは機能しなくなるのか？ • アジャイルやDevOpsはSIer中心ではうまくい かず、内製中心でないとダメなのか？ 6
- 8. アジャイルについて 僕は「No」 • 確かに欧米的な考え方はベースであろう • でも、アジャイルソフトウェア開発宣言に書か れていることは日本とか欧米とか関係ない • むしろ、日本文化の良さを肯定したい »確かに無駄は沢山あるけども »「文化が違うから」は言い訳になりやすい 7
- 10. 話の前に 前提 • あくまでも僕個人の考え方です • エンタープライズアジャイル勉強会の役員にお いても統一見解はありません • 僕はエンタープライズ向けのSIerです »医療、通信、流通、メディアなど »ただし、出身は1兆円グループのシステム子会社 9
- 12. 今どきのエンタープライズ 企業システムの類型化 • SoR（System of Record） » 情報を正しく「記録」するためのシステム » ユーザーは従業員が中心。取引情報を長期間にわたって 保持し、ビジネスの基幹となるシステム » 変更頻度は低め、システム障害影響大 • SoE（System of Engagement） » 顧客や取引先との「絆」を作るためにシステム » 最新の状況を表示し、判断を行ってもらう。機能はユー ザーごとに最適化され、高頻度で改善されていく 11
- 14. 今どきのエンタープライズ 一方で、企業システムとしての制約 • SoEはSoRと必ず連携する »基幹システム側は期日ありきで計画主導プロセス • 社内部門/業務と必ず関わりがある »多くのビジネスはITだけで完結しない ▸事業計画、教育コスト、部門間調整、稟議… • ビジネスは簡単に止められない »社会インフラに近いほど「止まっては困る」 13
- 17. 事例紹介 16
- 18. 事例１ 17
- 20. 概要 顧客の要望 • 安定稼働できたので、売上貢献へ »新しい商品形態の提供、購買プロセスの改善など • 改善は商品企画部主管にしたい »商品企画部はシステム開発は初心者 • 関係部署（営業、業務など）との調整をしない といけない »商品変更に伴う顧客への事前通知や営業説明が必要 • できれば顧客からの要望にも対応したい 19
- 21. 提案 1/2 継続機能改善プロセスの導入 • 3つ目のプロセスとして提案 »企画＋見積(2w)→設計+QA(2w)→実装(4w)→受入 (2w)→リリース準備(2w) 20 名前 契約 内容 保守 年間の月額定額保守契 約 問い合わせ対応、緊急対応など 継続機能改善 3ヶ月ごとに同額で請負 契約 3ヶ月おきに「企画→設計→開発」 を実施 新規機能開発 個別に見積もりを実施 する請負契約 個別案件ごとに要件定義、見積もり を行って開発を実施
- 22. 提案 2/2 継続機能改善プロセス • 3か月定期でリリースする »リリース日が決まるので、遡って企画、要件定義、 見積もり、設計、実装、受入も日付が決まる • 予算は事前確保しておき、見積もり完了後にス コープ調整を行って稟議をかける »コスト調整というより各部署への通達 »企画～要件定義が部署間調整期間になる 21
- 23. 結果 1/2 よかったこと • スケジュールが先に決まるのでリズムにのれる »予算は確保済みだから使わないとまずい »間に合わなければ「次のリリースに載せればいい」 • 3ヶ月で社内調整~顧客告知~営業連絡ができる • 営業からも評判がいい »既存顧客への新商品紹介営業のきっかけになる »顧客要望を取り込んでもらえると営業にいける 22
- 24. 結果 2/2 課題になったこと • あわただしい »部署間調整をしたら、すぐに顧客営業調整に入らな いといけない »「やっぱ変える」はゼロにはできない • 予算確保の名目が難しい »年間計画時点で「何を作るかはその時に決めるから 、とりあえず枠だけ抑える」という稟議は困難 ▸金額の妥当性はサービスの売上金額に連動するなどを考え ていきたい 23
- 25. 事例２ 24
- 29. 結果 1/2 やってみて • 成果をどう出すか、を顧客が一緒に考えてくれる » 当初は連携先が少なくても、その範囲で成果を出せる人 を捜す » 現場が「顧客が見える！」と楽しんでくれた • 開発よりも、導入を強く意識できた » 「使われないと意味がない」を徹底。操作性クレームは 毎週対応 • 役員からは好評 » コストと成果が見えるようになった 28
- 30. 結果 2/2 課題になったこと • あわただしい »３か月に１回も役員報告するのはしんどい »３か月に１回も契約更改するのはしんどい • そもそも企画が弱い商品はITでは売れない »「そらそうだ」 • 元システムのデータ品質が悪い »連携させてみようとして分かる課題が顕在化した »俯瞰してシステムを棚卸する良い機会になった 29
- 31. 事例３ 30
- 35. 結果 やってみて • 基幹に影響がない機能を好きなタイミングでリ リースできるようになった »機能移植などで障害があっても多少は許容 • 溜まっていたバックログは解消 »企画側がボトルネックになってきた • 今後も段階的に分割を行っていく方針 »再構築ではなく順次リニューアル 34
- 37. 事例への考察 36
- 38. 事例への考察 3つの論点 • フィードバックサイクル • プロダクトオーナー • アーキテクチャ 37
- 40. フィードバックサイクル 定期的であることは重要 • 期間に関係なく定期であることが大事 • アジャイルの原則には合致している（と思う） »☑リソースと期間を固定し、小さな計画をチームで 考える »☑動くソフトウェアで確認を行う »☑利害関係者全員で棚卸をする • 締め切り駆動でスケジュールが決まる »判断をするタイミングが明確 39
- 42. フィードバックサイクル 「次のリリース」という安心感 • 「今やるか、次にやるか」を選べる »締切駆動で判断するときに判断しやすい »他に部署にも調整しやすい • 要件を無理に押し込まなくなる 41
- 46. フィードバックサイクルについて 3つの開発サイクル • 新機能追加（個別の見積発注）＝WF的 » 他システム連携やリリース日程の確定が必要な機能追加 » 個別の見積とスケジュールで実行 • 定期改善（数ヶ月ごとの定額）＝アジャイル的 » ２～3ヶ月おきに機能改善を実施する » ２～3ヶ月おきに実施内容を確定する（工数は事前固定） • 保守（毎月定額） » 日々の問合せサポート、緊急のバグ対応 » 影響範囲の少ない軽微な修正（1週～2週毎リリース） 45
- 47. 1 2 3 4 5 6 7 8 9 10 11 12 フィードバックサイクルについて 3つの開発サイクル 46 基本設計 実装 テス ト 要件 定義 計 画 受 入新機能 開発 定期 改善 設 計 実装 ﾃ ｽ ﾄ 計 画 受 入 初回 リリース ﾏｰｹﾃｨﾝｸﾞ活動 設 計 実 装 ﾃ ｽ ﾄ 緊急の修正は 保守枠で対応 初回のﾏｰｹの 結果で改善を計画 ２回目 リリース ﾏｰｹﾃｨﾝｸﾞ活動 設 計 実 装 ﾃ ｽ ﾄ 設 計 実装 計 画 保守
- 48. フィードバックサイクルについて 開発スタイルの考え方 • 大型の機能追加や他システム連携を行うものは 「個別機能追加」として計画する • 改善は「定期改善」で実施していく »3ヶ月ごとに実施内容を確定し、設計～実装～テスト • 小さな改修については「保守」で1～2週おきに リリースする »影響範囲が小さいことが条件となる 47
- 54. プロダクトオーナー 部門間調整は特に高難易度 • プロダクトが複数部門にまたがる場合 »部門別での稟議では優先順位が決められない »一度、取りまとめてから判断が必要になる 53 営 業 部 業 務 部 そ の 他 経 営 企 画 部 システム部 ベンダー各社 PJ PJ PJ PJ 営 業 部 業 務 部 そ の 他 経 営 企 画 部 システム部 ベンダー各社 定期改善PJ PO
- 58. プロダクトオーナー POは育成できるのか？ • そもそも出身事業部は強く影響する »開発出身PO vs 企画出身PO • 育成は大変 »なによりも「想い」が重要 »ただ、何が足りないかを評価して、足らない部分を 補うことが可能（特に組織調整能力） »その過程で強く育つと信じることが大事 57
- 59. アーキテクチャについて 58
- 62. MSA メリット • モノリシックだと変更が全体に影響する »影響調査とリグレッションテストで工数の大半 • サービス同士が疎結合なら変更の影響が全体に 及ばない »サービスごとに好きなリズムでリリースしてよい • サービスごとに構造と非機能要件を変えてよい »例：サービスによって性能特性を変えられる 61
- 63. MSA MSAはどこから来た？ • 理想論ではなく現実解釈 »2011年ごろ：先端的なウェブサービス企業のアーキ テクチャスタイルが似ていることが話題に »2012年：33rd Degree 2012「Microservices - Java, the Unix Way」 »2014年：martinfowler.com「Microservceis」 • アジャイル→クラウド＋DevOps→MSA • アプリケーションではなくシステム全体 62
- 67. まとめ 66
- 69. エンタープライズアジャイルとは やってみて思うこと • フィードバックサイクル »ともかく定期的であることが大事（3か月？） »WFや短期リリースとも組み合わせていく • プロダクトオーナー »「想い」があったうえで組織調整力が大事 »一人でやるよりチームでやってもらう • アーキテクチャ »アジャイルを許容するためのアーキテクチャ設計 68
- 70. お知らせ アーキテクチャ寄りの話は • Cloud First Architecture 設計ガイド » 第1章 クラウドファーストの意味 » 第2章 クラウド技術の構成 » 第3章 クラウドファーストに至るまでの歴史 » 第4章 エンタープライズとクラウドファースト » 第5章 アーキテクチャー設計ガイド » 第6章 クラウドファーストにおけるエンジニア https://www.amazon.co.jp/dp/4822237818 69