Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

ユーザー企業へのアジャイル導入四苦八苦 - エンタープライズアジャイル勉強会2016年11月セミナー

15,449 views

Published on

2016年11月19日に行われたエンタープライズアジャイル勉強会2016年11月セミナーでの講演「ユーザー企業へのアジャイル導入四苦八苦」の資料です

Published in: Technology
  • Be the first to comment

ユーザー企業へのアジャイル導入四苦八苦 - エンタープライズアジャイル勉強会2016年11月セミナー

  1. 1. ユーザー企業へのアジャイル導入四苦八苦 2016/11/18 鈴木雄介 グロースエクスパートナーズ株式会社 執行役員 日本Javaユーザーグループ 会長 エンタープライズアジャイル勉強会 2016年11月セミナー https://easg.smartcore.jp/
  2. 2. 自己紹介 鈴木雄介 • グロースエクスパートナーズ(株) » 執行役員/アーキテクチャ事業本部長 » http://www.gxp.co.jp/ • 日本Javaユーザーグループ » 会長 » http://www.java-users.jp/ • SNS » http://arclamp.hatenablog.com/ » @yusuke_arclamp 1
  3. 3. 講演要旨 • 日本の企業システムでは部門間調整、基幹シス テム連携、法制度対応など、様々な"事情"があ り、アジャイルの導入においてもそれらとのバ ランスが重要になります。 • そういった日本的な事情を勘案したアジャイル を「エンタープライズ・アジャイル」と位置づ けた上で、ユーザー企業とも協力しながら、い かにウォーターフォール型開発をアジャイル型 に適応されていくのかについて実績や取組みに ついて紹介したいと思います。 2
  4. 4. アジェンダ • アジャイル“海外文化”問題 • 僕が思うエンタープライズアジャイル • 事例紹介 • フィードバックサイクルについて • プロダクトオーナーについて • アーキテクチャについて • まとめ 3
  5. 5. アジャイル“海外文化”問題 4
  6. 6. アジャイルについて アジャイルソフトウェア開発宣言 • 2001年に公開 • アジャイルにおける「価値」 »プロセスやツール よりも 個人と対話を、 »包括的なドキュメント よりも 動くソフトウェアを、 »契約交渉 よりも 顧客との協調を、 »計画に従うこと よりも 変化への対応を、 5http://www.agilemanifesto.org/iso/ja/ 大事 超大事
  7. 7. アジャイルについて アジャイル“海外文化”問題 • アジャイルを導入するのに海外の文化をインス トールする必要があるのか? • 日本の文化に適合させようとするとアジャイル やDevOpsは機能しなくなるのか? • アジャイルやDevOpsはSIer中心ではうまくい かず、内製中心でないとダメなのか? 6
  8. 8. アジャイルについて 僕は「No」 • 確かに欧米的な考え方はベースであろう • でも、アジャイルソフトウェア開発宣言に書か れていることは日本とか欧米とか関係ない • むしろ、日本文化の良さを肯定したい »確かに無駄は沢山あるけども »「文化が違うから」は言い訳になりやすい 7
  9. 9. 僕が思う エンタープライズアジャイル 8
  10. 10. 話の前に 前提 • あくまでも僕個人の考え方です • エンタープライズアジャイル勉強会の役員にお いても統一見解はありません • 僕はエンタープライズ向けのSIerです »医療、通信、流通、メディアなど »ただし、出身は1兆円グループのシステム子会社 9
  11. 11. 10https://www.flickr.com/photos/iansand/5920421391/https://www.flickr.com/photos/peaceful-jp-scenery/16346037831/
  12. 12. 今どきのエンタープライズ 企業システムの類型化 • SoR(System of Record) » 情報を正しく「記録」するためのシステム » ユーザーは従業員が中心。取引情報を長期間にわたって 保持し、ビジネスの基幹となるシステム » 変更頻度は低め、システム障害影響大 • SoE(System of Engagement) » 顧客や取引先との「絆」を作るためにシステム » 最新の状況を表示し、判断を行ってもらう。機能はユー ザーごとに最適化され、高頻度で改善されていく 11
  13. 13. 今どきのエンタープライズ 正しい仕様がない • SoE型には事前に「正しい仕様」が存在しない »社内に”本当のユーザー”がいないため、誰にも正解 が分からない »外部の”想定しない変化”に合わせていく必要がある • 仮説検証型の進め方にするしかない »「仮説としての仕様」からはじめる »あとは状況に応じて対応をしていく 12
  14. 14. 今どきのエンタープライズ 一方で、企業システムとしての制約 • SoEはSoRと必ず連携する »基幹システム側は期日ありきで計画主導プロセス • 社内部門/業務と必ず関わりがある »多くのビジネスはITだけで完結しない ▸事業計画、教育コスト、部門間調整、稟議… • ビジネスは簡単に止められない »社会インフラに近いほど「止まっては困る」 13
  15. 15. 今どきのエンタープライズ WFの限界とアジャイルの限界 • WFでは「調整していく」のは大変 »全体設計を行って最適化するので変更が少ないほど 効率的になる • アジャイルでも「調整していく」のは大変 »日本的組織ではアジャイルが求める判断スピードに ついていけなくなることがある 14
  16. 16. エンタープライズアジャイル エンタープライズアジャイルとは • 日本的エンタープライズの現実を前提にした、 SoEを最適に実現するための手法 »SoRに適用しようとは(僕は)思わない »ただし、SoRに引きずられることは許容する • アジャイルマインドを重視しつつ、現実的な開 発の進め方に配慮する 15
  17. 17. 事例紹介 16
  18. 18. 事例1 17
  19. 19. 概要 顧客とプロジェクト • 顧客:企業信用情報の販売を行う企業 »社歴は120年越え • プロジェクト:オンラインで企業情報を販売 »ログイン~検索~購入~ダウンロードを行うフロン トシステム »基幹システムから信用情報がファイル連携される »販売管理システムなどとはオンラインAPI連携する 18
  20. 20. 概要 顧客の要望 • 安定稼働できたので、売上貢献へ »新しい商品形態の提供、購買プロセスの改善など • 改善は商品企画部主管にしたい »商品企画部はシステム開発は初心者 • 関係部署(営業、業務など)との調整をしない といけない »商品変更に伴う顧客への事前通知や営業説明が必要 • できれば顧客からの要望にも対応したい 19
  21. 21. 提案 1/2 継続機能改善プロセスの導入 • 3つ目のプロセスとして提案 »企画+見積(2w)→設計+QA(2w)→実装(4w)→受入 (2w)→リリース準備(2w) 20 名前 契約 内容 保守 年間の月額定額保守契 約 問い合わせ対応、緊急対応など 継続機能改善 3ヶ月ごとに同額で請負 契約 3ヶ月おきに「企画→設計→開発」 を実施 新規機能開発 個別に見積もりを実施 する請負契約 個別案件ごとに要件定義、見積もり を行って開発を実施
  22. 22. 提案 2/2 継続機能改善プロセス • 3か月定期でリリースする »リリース日が決まるので、遡って企画、要件定義、 見積もり、設計、実装、受入も日付が決まる • 予算は事前確保しておき、見積もり完了後にス コープ調整を行って稟議をかける »コスト調整というより各部署への通達 »企画~要件定義が部署間調整期間になる 21
  23. 23. 結果 1/2 よかったこと • スケジュールが先に決まるのでリズムにのれる »予算は確保済みだから使わないとまずい »間に合わなければ「次のリリースに載せればいい」 • 3ヶ月で社内調整~顧客告知~営業連絡ができる • 営業からも評判がいい »既存顧客への新商品紹介営業のきっかけになる »顧客要望を取り込んでもらえると営業にいける 22
  24. 24. 結果 2/2 課題になったこと • あわただしい »部署間調整をしたら、すぐに顧客営業調整に入らな いといけない »「やっぱ変える」はゼロにはできない • 予算確保の名目が難しい »年間計画時点で「何を作るかはその時に決めるから 、とりあえず枠だけ抑える」という稟議は困難 ▸金額の妥当性はサービスの売上金額に連動するなどを考え ていきたい 23
  25. 25. 事例2 24
  26. 26. 概要 顧客とプロジェクト • メディア企業 »社歴は約50年 • プロジェクト:統合顧客情報分析 »数十のシステムから顧客属性、実績(売上、行動等 )を収集し、分析を行う »オンプレでデータを収集後、クラウドにアップロー ドしてマートを作成。分析はオンプレのBIサーバで 実施 »まずはメールマーケティングの対象顧客抽出に利用 25
  27. 27. 概要 顧客の要望 • 社内システムに顧客情報が散逸しており、これ を統合してマーケティング目的で分析できる仕 組みを作りたい »でも、どこにどんなデータあるのか、どう組み合わ せられるのかなどは「やってみないと分からない」 • ビジネス成果につながらないと意味がない »売上に貢献するシステムを作ってほしい 26
  28. 28. 提案 年間計画と3か月計画 • 3ヶ月単位でプロジェクトを推進する »3か月ごとに「稟議」と「役員向け成果報告」 • 顧客社内に専任部署を設置する »開発チームは部署内に常駐する »開発チームにはシステム開発だけではなく、現場へ の導入推進も担当するメンバーも配置する 27
  29. 29. 結果 1/2 やってみて • 成果をどう出すか、を顧客が一緒に考えてくれる » 当初は連携先が少なくても、その範囲で成果を出せる人 を捜す » 現場が「顧客が見える!」と楽しんでくれた • 開発よりも、導入を強く意識できた » 「使われないと意味がない」を徹底。操作性クレームは 毎週対応 • 役員からは好評 » コストと成果が見えるようになった 28
  30. 30. 結果 2/2 課題になったこと • あわただしい »3か月に1回も役員報告するのはしんどい »3か月に1回も契約更改するのはしんどい • そもそも企画が弱い商品はITでは売れない »「そらそうだ」 • 元システムのデータ品質が悪い »連携させてみようとして分かる課題が顕在化した »俯瞰してシステムを棚卸する良い機会になった 29
  31. 31. 事例3 30
  32. 32. 概要 顧客とプロジェクト • クレジットカード会社 »グループの社歴は数百年 • プロジェクト:マイページ »クレジットカードの実績閲覧や契約変更が行える »プロモーション登録や提携サービス連携ができる »新規のカード申し込みができる 31
  33. 33. 概要 顧客の要望 • マイページは構築済みだがリリースサイクルが 遅すぎるのでなんとかしたい »特にマーケティング、ユーザビリティ、外部サービ ス連携などが急務 • 既存ベンダーから切り替えても良いが、再構築 などは避けたい 32
  34. 34. 提案 アプリをぶったぎる • 基幹と同じ典型的なWF »企画検討→見積もり→稟議決裁→開発開始に数か月 かかることも • 基幹連携に影響がない機能部分を分離し、独自 のリリースサイクルを可能にする »アプリケーションモジュール分割 »CI/CD環境の整備や認証機構の改造など 33
  35. 35. 結果 やってみて • 基幹に影響がない機能を好きなタイミングでリ リースできるようになった »機能移植などで障害があっても多少は許容 • 溜まっていたバックログは解消 »企画側がボトルネックになってきた • 今後も段階的に分割を行っていく方針 »再構築ではなく順次リニューアル 34
  36. 36. 結果 今後の課題 • ただし、定期リリースができていない »複数部署にまたがる課題の優先順位付けができない »稟議がないと開発をスタートできない ▸金融基幹として定められたルールの遵守 ▸準委任ではなく請負開発しか認められない • まずは勉強会から »横断的な優先度決定者の必要性を理解してもらう 35
  37. 37. 事例への考察 36
  38. 38. 事例への考察 3つの論点 • フィードバックサイクル • プロダクトオーナー • アーキテクチャ 37
  39. 39. フィードバックサイクル について 38
  40. 40. フィードバックサイクル 定期的であることは重要 • 期間に関係なく定期であることが大事 • アジャイルの原則には合致している(と思う) »☑リソースと期間を固定し、小さな計画をチームで 考える »☑動くソフトウェアで確認を行う »☑利害関係者全員で棚卸をする • 締め切り駆動でスケジュールが決まる »判断をするタイミングが明確 39
  41. 41. フィードバックサイクル 「3ヶ月」の意味 • 「ビジネス成果を上げるリズム」として最適 »それ以上短いと経営層や現場を巻き込めない »会社の四半期目標にも合わせやすい • 3ヶ月だけである必要はない »小さな改善はどんどんやればいい(毎週でもいい) 40
  42. 42. フィードバックサイクル 「次のリリース」という安心感 • 「今やるか、次にやるか」を選べる »締切駆動で判断するときに判断しやすい »他に部署にも調整しやすい • 要件を無理に押し込まなくなる 41
  43. 43. フィードバックサイクル 評価者は経営層 • 経営層に評価してもらうことが大事 »やっぱり会社だし »顧客からの評価はリリースしてから • 「システムを作る」ではなく「成果を出す」と いう意識が生まれる »「より成果につながる機能はなんだ?」 42
  44. 44. フィードバックサイクル 長期の視点も短期の視点も大事 • 企業にとって長期計画はとても大事 »サービスを安定して提供するのは当然 ▸「1年でやめます」というわけにはいかない • 長期的な方針を短期で具体化する »短期で具体化することで長期の方針が明確になって いく 43
  45. 45. フィードバックサイクルについて 3つの開発サイクル 44
  46. 46. フィードバックサイクルについて 3つの開発サイクル • 新機能追加(個別の見積発注)=WF的 » 他システム連携やリリース日程の確定が必要な機能追加 » 個別の見積とスケジュールで実行 • 定期改善(数ヶ月ごとの定額)=アジャイル的 » 2~3ヶ月おきに機能改善を実施する » 2~3ヶ月おきに実施内容を確定する(工数は事前固定) • 保守(毎月定額) » 日々の問合せサポート、緊急のバグ対応 » 影響範囲の少ない軽微な修正(1週~2週毎リリース) 45
  47. 47. 1 2 3 4 5 6 7 8 9 10 11 12 フィードバックサイクルについて 3つの開発サイクル 46 基本設計 実装 テス ト 要件 定義 計 画 受 入新機能 開発 定期 改善 設 計 実装 テ ス ト 計 画 受 入 初回 リリース マーケティング活動 設 計 実 装 テ ス ト 緊急の修正は 保守枠で対応 初回のマーケの 結果で改善を計画 2回目 リリース マーケティング活動 設 計 実 装 テ ス ト 設 計 実装 計 画 保守
  48. 48. フィードバックサイクルについて 開発スタイルの考え方 • 大型の機能追加や他システム連携を行うものは 「個別機能追加」として計画する • 改善は「定期改善」で実施していく »3ヶ月ごとに実施内容を確定し、設計~実装~テスト • 小さな改修については「保守」で1~2週おきに リリースする »影響範囲が小さいことが条件となる 47
  49. 49. プロダクトオーナー について 48
  50. 50. プロダクト開発 プロジェクトからプロダクトへ • プロジェクト型システム開発 »開発期間を区切りシステムをリリースして完了 »必要なリソースを調達し、終われば開放する • プロダクト型システム開発 »継続的な維持改善を続ける »プロダクトがなくなるまで永遠に続く 49
  51. 51. プロダクトオーナー プロダクトオーナーとは • Scrumで定義されたスクラムチーム内のロール • 名ばかりのオーナーではなく実務者 »バックログの管理 »プロダクトの方向性の決定 ▸内容やリリース時期など »タスク優先順位の最終決定 »プロダクトの成果に責任を持つ 50
  52. 52. プロダクトオーナー 日本的なプロダクトオーナー 51 スクラム マスター 開発チーム 開発PO 経営層 情シス 営業 広報 コールセンター 現場 作業者 管理 部門 法務/財務 顧客 意思決定 促進 現場調整 Dev/Ops 視点 ビジネス 視点 意思決定プロセス 現場
  53. 53. プロダクトオーナー 日本的なプロダクトオーナー • POの仕事 »開発作業の優先順位決定 »顧客への価値提供 • 日本的POの追加の作業 »意思決定プロセスへの働きかけ »現場との調整 52
  54. 54. プロダクトオーナー 部門間調整は特に高難易度 • プロダクトが複数部門にまたがる場合 »部門別での稟議では優先順位が決められない »一度、取りまとめてから判断が必要になる 53 営 業 部 業 務 部 そ の 他 経 営 企 画 部 システム部 ベンダー各社 PJ PJ PJ PJ 営 業 部 業 務 部 そ の 他 経 営 企 画 部 システム部 ベンダー各社 定期改善PJ PO
  55. 55. プロダクトオーナー 日本的なPOに求められる能力 • 開発視点やビジネス視点だけではなく、組織調 整能力が非常に重要 »「この機能なら成果が出ると経営層が納得してくれ る」「あの役員には先に話しておくべき」 »「あっちの部門は協力してくれそうだ」「こっちの 部門にはこの機能があれば納得してくれる」 • 会社がPOとして振る舞う、という解釈 »意思決定は組織で行い、POはそのファシリテーター 54
  56. 56. プロダクトオーナー 日本的なPOの在り方 • そもそも一人のPOではやりきれない »開発もビジネスも実務能力があって、役員も現場も 抑えられる人はいない • 数名でPOとして機能する方が現実的 »チーム内のすり合わせ(あいつが言うなら) »各部門の意見を集める人+ビジネスセンスの人+根 回し力の人+開発への一定の信頼と叱責 55
  57. 57. プロダクトオーナー 最も重要なのは「想い」 • 「このプロダクトにはこれが必要」という想い がないと調整も促進もできない »想いがない人には調整ができない »合意形成の手前には落としどころが必要 »想いがあれば間違っていても修正できる »「誰かの意見」で決まったことには逃げが生じる • システム開発ではなくビジネス開発 56
  58. 58. プロダクトオーナー POは育成できるのか? • そもそも出身事業部は強く影響する »開発出身PO vs 企画出身PO • 育成は大変 »なによりも「想い」が重要 »ただ、何が足りないかを評価して、足らない部分を 補うことが可能(特に組織調整能力) »その過程で強く育つと信じることが大事 57
  59. 59. アーキテクチャについて 58
  60. 60. アーキテクチャ アジャイルしやすいアーキテクチャ • アジャイルを適用しやすいアーキテクチャとい うのは存在する »機能が独立しており、各チームごとに独自のリリー スサイクルを実現できる »独立=外部システムとの関係性が疎である • その進化系がマイクロサービスアーキテクチャ 59
  61. 61. MSA 概要 • サービスの組み合わせでシステムを実現する »(小さな)サービスで(大きな)サービスを動かす »サービス同士はAPI/メッセージで連携する • サービスの単位でチームが分割される »チームが複数のサービスを管理しても良い 60
  62. 62. MSA メリット • モノリシックだと変更が全体に影響する »影響調査とリグレッションテストで工数の大半 • サービス同士が疎結合なら変更の影響が全体に 及ばない »サービスごとに好きなリズムでリリースしてよい • サービスごとに構造と非機能要件を変えてよい »例:サービスによって性能特性を変えられる 61
  63. 63. MSA MSAはどこから来た? • 理想論ではなく現実解釈 »2011年ごろ:先端的なウェブサービス企業のアーキ テクチャスタイルが似ていることが話題に »2012年:33rd Degree 2012「Microservices - Java, the Unix Way」 »2014年:martinfowler.com「Microservceis」 • アジャイル→クラウド+DevOps→MSA • アプリケーションではなくシステム全体 62
  64. 64. MSA なぜMSAは生まれたのか • ウェブサービス企業でもレガシーが増える • レガシー(変化少)とフロント(変化多)を切 り離さないと変化が許容できない »機能要件だけではなく非機能要件の都合も強い »非同期処理を許容することが重要 »一貫性よりも結果整合性のほうが価値がある 63
  65. 65. MSA MSAの限界について • MSAがすべてのシステムで有効なわけではない »品質に対する考え方は大きく異なる »小さな障害を許容することで全体の障害を回避する »小さな障害を許容できるかはシステムによる • とはいえ、MSAを無視することもない »疎結合そのものは重要な考え方 64
  66. 66. プロセスとアーキテクチャ アーキテクチャは重要 • アーキテクチャの変化許容度が上がった »仮想化、自動化、非同期処理などの技術が重要 »昔はプロセスで耐えるしかなかった • アーキテクチャ設計時にプロセスを意識する »アジャイルにしたいなら、それを許容するアーキテ クチャ設計にしておかないと苦しい »逆に段階的に分割することでアジャイルに取り組ん でいける 65
  67. 67. まとめ 66
  68. 68. エンタープライズアジャイルとは 僕が思うエンタープライズアジャイル • SoRとSoE »SoEが重要ではあるが、SoRからは逃れられない »日本的企業の品質は大事 • SoEにはフィードバックと改善は必要 »社内に正解がない、というのは事実 »であれば、社外ユーザーからフィードバックを得よ 67
  69. 69. エンタープライズアジャイルとは やってみて思うこと • フィードバックサイクル »ともかく定期的であることが大事(3か月?) »WFや短期リリースとも組み合わせていく • プロダクトオーナー »「想い」があったうえで組織調整力が大事 »一人でやるよりチームでやってもらう • アーキテクチャ »アジャイルを許容するためのアーキテクチャ設計 68
  70. 70. お知らせ アーキテクチャ寄りの話は • Cloud First Architecture 設計ガイド » 第1章 クラウドファーストの意味 » 第2章 クラウド技術の構成 » 第3章 クラウドファーストに至るまでの歴史 » 第4章 エンタープライズとクラウドファースト » 第5章 アーキテクチャー設計ガイド » 第6章 クラウドファーストにおけるエンジニア https://www.amazon.co.jp/dp/4822237818 69

×