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.

エンタープライズアジャイル内製プロジェクトを立ち上げる前に考慮すべき3つのこと

4,413 views

Published on

企業システム開発のアジャイル内製化を推進していく中で、実は開発チームよりも既存の事業活動に障壁が現れます。本資料では、例えばPMOや品質管理部門といった予測型を前提とした管理統制スキームを適用している組織にアジャイル内製チームを立ち上げる際に考慮すべき3つの観点について事例を交えて解説します。
【2015/12/9に開催されたエンタープライズアジャイル勉強会での講演資料です】

※ 2015/12/12 関連スライドとして下記講演へのリンクを加筆
「俺の背中について来い」アジャイルチームを一気に立ち上げる方法
http://www.slideshare.net/hiromasaoka/ss-56106141

※ 講演時のタイトルは「事業計画に適応するアジャイル内製プロジェクトの運営」でしたが、配付資料では講演内容に即した名称に変更致しました。

Published in: Software
  • Be the first to comment

エンタープライズアジャイル内製プロジェクトを立ち上げる前に考慮すべき3つのこと

  1. 1. エンタープライズアジャイル内製プロジェクトを 立ち上げる前に考慮すべき3つのこと 2015/12/9 株式会社ゼンアーキテクツ 岡 大勝 Enterprise Agile in-house project to considerbefore launching "Three things". キャプラン株式会社様の事例に学ぶ
  2. 2. ⾃自⼰己紹介 • 第⼀一勧銀情報システム(現:みずほ情報総研) • VOS3  COBOL&MS-‑Cプログラマ • ⽇日本DEC • 主に⽣生保・損保・銀⾏行向けの • 資産運⽤用システムに携わる。 • ⽇日本HP • ⾦金融機関向けのシステムアーキテクチャ設計、 • 開発プロセス設計、運⽤用プロセス設計を⾏行う。 • ⽇日本ラショナルソフトウェア • 開発プロセス(RUP)および オブジェクト指向分析設計⼿手法 の導⼊入コンサルティング。 • ゼンアーキテクツ • 2003年よりIT設計事務所として活動。お客さまのIT投資の最適化を ⽬目指し、アーキテクチャ中⼼心のプロセス改善を推進。 岡 ⼤大勝 (おか ひろまさ) 株式会社ゼンアーキテクツ CEO/チーフアーキテクト プロフィール
  3. 3. 著作 /  翻訳
  4. 4. アジャイルへの取り組み アジャイル + アーキテクチャ 企業システムの アプリケーション開発“内製化”⽀支援
  5. 5. • ラッセルチーム(※)で内製⽂文化の垂直⽴立ち上げ • 実績:9社11システム (2013/6〜~) • 業種:⾦金融、製造、⼈人材サービス、医療 • 5社7システムで⽀支援継続中 Powered  by Team  with マイクロソフト株式会社 クロスプラットフォーム開発パートナー アトラシアンエキスパート(正規販売代理理店) https://www.microsoft.com/ja-­‐jp/server-­‐cloud/Solutions-­‐Cross-­‐Platform-­‐Apps-­‐Partners.aspx https://ja.atlassian.com/resources/experts/?tab=find-­‐an-­‐expert&expertName=ZEN (※)ラッセル=登⼭山で、深い雪をはらいのけ道を開きつつ進むこと。
  6. 6. アジャイルチームとプロジェクトライフサイクル
  7. 7. Client Side WebBrowser (Presentation) View   (HTML) JavaScript FrameWork User   Event View   Model WebSocket Driver Validation ViewModel Server  Side Server <PaaS> App Service ASP .NET ASP .NET Application MVC Controller WebAPI Controller (REST   API) Service Identity (Authn/Authz) Business Model View   Model View Model Redis Cache SQL  Database Application Insights Business Object  A Business Object  B Send  Grid Validation Create HTML  Docs API  call (HTTP) WebSock et JSON Entry WebJobs Web  Apps Send  Mail Logging   & Notification JSON response MVC Controller Web  API Controller (REST  API) 利利⽤用技術とリファレンスアーキテクチャ Azure  AD/AD
  8. 8. なぜ企業システムの内製化を ⽀支援するのか? ニッポンの競争⼒力を 取り戻したい アジャイルはその⼀一助となり得る、と私たちは考えている
  9. 9. エンタープライズ =“ややこしい環境” シンプルなアジャイル(Scrum)をそのまま受 け⼊入れることが難しい環境
  10. 10. 企業システムも基本はScrum • シンプルなScrumで回せればベスト Scrum
  11. 11. エンタープライズアジャイル =  Scaling  Agile そのまま適⽤用できない環境に適合させるために、 Scrumに何らかの拡張が必要
  12. 12. Scrum Scaleさせるべきパラメータは、組織や 環境によって異なる Scrum チームサイズ 品質 統制組織
  13. 13. ⽬目的別のScalingライブラリとして エンタープライズアジャイルフレームワークを活⽤用する 13 Disciplined Agile Delivery Large  Scale  Scrum Scrum  of  Scrums アジャイルの本質は不不変。良良い悪いではない。 ⾃自分の環境に適応させ進化させれるためのガイドラインに過ぎない。 ⽬目的別ライブラリとして、さらに多様化していくことを望む。
  14. 14. プログラムアセスメントでの 適合性確認項⽬目 1. 動機とコミットメント 2. 既存の管理統制スキーム 3. プロダクトビジョンと お客様の状況により、アジャイル導⼊入/内製化をお勧めしない場合があります アジャイル内製化プログラムを 適⽤用するに当たって、以下の状況を確認する。 スコープコントロール
  15. 15. 実現する業務を ストーリーとして切切り出して登録 受け⼊入れられた 実装済ストーリーを、To-­‐Beにフィードバック SP 実装実績から ⾒見見積基礎値を設定 2W 優先順位の⾼高いストーリーを タイムボックスで計画化 チームで 実装 実装された 機能 修正・追加要望をバックログに追加 イテレーションデモ レビュー ユーザ(業務カテゴリをエピックで 分類すると識識別しやすい) ソース 管理理 ビルド・デプロイ・テスト プロダクトバックログ イテレーション計画 ユーザ シンプルなアジャイルプロジェクト プロダクトオーナー リリース
  16. 16. To-­‐Be 業務フロー ユーザからの 要望/要求 ビジョン 技術 実装⽅方式 初期のアー キテクチャ アーキテク チャ ドキュメント 主要なストーリーを実装 (US、TS) 実現する業務を ストーリーとして切切り出して登録 受け⼊入れられた 実装済ストーリーを、To-­‐Beにフィードバック SP 実装実績から ⾒見見積基礎値を設定 ⽅方式、パターン サンプルコード 2W 優先順位の⾼高いストーリーを タイムボックスで計画化 チームで 実装 実装された 機能 修正・追加要望をバックログに追加 イテレーションデモ レビュー ユーザ(業務カテゴリをエピックで 分類すると識識別しやすい) ソース 管理理 ビルド・デプロイ・テスト プロダクトバックログ ⾒見見積基礎値の フィードバック ドキュメントの追記・更更新 Living Document イテレーション計画 ⾃自動回帰テスト 受⼊入テスト リリース判定 Ops リリース 本番運⽤用 インシデント管理理 修正依頼 ユーザ 運⽤用担当者 ユーザ オーナー 企業システムでのアジャイルプロジェクト プログラムマネージャ PMO事業部⻑⾧長 報告 品質管理理部⾨門 品質基準 プロダクトオーナー
  17. 17. To-­‐Be 業務フロー ユーザからの 要望/要求 ビジョン 技術 実装⽅方式 初期のアー キテクチャ アーキテク チャ ドキュメント 主要なストーリーを実装 (US、TS) 実現する業務を ストーリーとして切切り出して登録 受け⼊入れられた 実装済ストーリーを、To-­‐Beにフィードバック SP 実装実績から ⾒見見積基礎値を設定 ⽅方式、パターン サンプルコード 2W 優先順位の⾼高いストーリーを タイムボックスで計画化 チームで 実装 実装された 機能 修正・追加要望をバックログに追加 イテレーションデモ レビュー ユーザ(業務カテゴリをエピックで 分類すると識識別しやすい) ソース 管理理 ビルド・デプロイ・テスト プロダクトバックログ ⾒見見積基礎値の フィードバック ドキュメントの追記・更更新 Living Document イテレーション計画 ⾃自動回帰テスト 受⼊入テスト リリース判定 Ops リリース 本番運⽤用 インシデント管理理 修正依頼 ユーザ 運⽤用担当者 ユーザ オーナー アジャイルプロジェクトを取り巻く問題 プログラムマネージャ PMO事業部⻑⾧長 報告 品質管理理部⾨門 品質基準 プロダクトオーナー 要求の⼀一貫性 拡⼤大するスコープ システム構造の ⼀一貫性 割り込みタスク 外部からの声 (PMO、QA、有識識者)
  18. 18. To-­‐Be 業務フロー ユーザからの 要望/要求 ビジョン 技術 実装⽅方式 初期のアー キテクチャ アーキテク チャ ドキュメント 主要なストーリーを実装 (US、TS) 実現する業務を ストーリーとして切切り出して登録 受け⼊入れられた 実装済ストーリーを、To-­‐Beにフィードバック SP 実装実績から ⾒見見積基礎値を設定 ⽅方式、パターン サンプルコード 2W 優先順位の⾼高いストーリーを タイムボックスで計画化 チームで 実装 実装された 機能 修正・追加要望をバックログに追加 イテレーションデモ レビュー ユーザ(業務カテゴリをエピックで 分類すると識識別しやすい) ソース 管理理 ビルド・デプロイ・テスト プロダクトバックログ ⾒見見積基礎値の フィードバック ドキュメントの追記・更更新 Living Document イテレーション計画 ⾃自動回帰テスト 受⼊入テスト リリース判定 Ops リリース 本番運⽤用 インシデント管理理 修正依頼 ユーザ 運⽤用担当者 ユーザ オーナー アジャイルプロジェクトを取り巻く問題 プログラムマネージャ PMO事業部⻑⾧長 報告 品質管理理部⾨門 品質基準 プロダクトオーナー 要求の⼀一貫性 拡⼤大するスコープ システム構造の ⼀一貫性 割り込みタスク 外部からの声 (PMO、QA、有識識者) 開発チームは 問題なく⽴立立ち上がる 焦点は、「既存の組織環境」との共存〜~浸透
  19. 19. To-­‐Be 業務フロー ユーザからの 要望/要求 ビジョン 技術 実装⽅方式 初期のアー キテクチャ アーキテク チャ ドキュメント 主要なストーリーを実装 (US、TS) 実現する業務を ストーリーとして切切り出して登録 受け⼊入れられた 実装済ストーリーを、To-­‐Beにフィードバック SP 実装実績から ⾒見見積基礎値を設定 ⽅方式、パターン サンプルコード 2W 優先順位の⾼高いストーリーを タイムボックスで計画化 チームで 実装 実装された 機能 修正・追加要望をバックログに追加 イテレーションデモ レビュー ユーザ(業務カテゴリをエピックで 分類すると識識別しやすい) ソース 管理理 ビルド・デプロイ・テスト プロダクトバックログ ⾒見見積基礎値の フィードバック ドキュメントの追記・更更新 Living Document イテレーション計画 ⾃自動回帰テスト 受⼊入テスト リリース判定 Ops リリース 本番運⽤用 インシデント管理理 修正依頼 ユーザ 運⽤用担当者 ユーザ オーナー アジャイルプロジェクトを取り巻く問題 プログラムマネージャ PMO事業部⻑⾧長 報告 品質管理理部⾨門 品質基準 プロダクトオーナー 要求の⼀一貫性 拡⼤大するスコープ システム構造の ⼀一貫性 割り込みタスク 外部からの声 (PMO、QA、有識識者) 企業活動との融和 プロダクト生産活動 本資料の焦点は、 企業活動との融和
  20. 20. については、 下記資料で事例を紹介しています。プロダクト生産活動 もうひとつの焦点である http://www.slideshare.net/hiromasaoka/ss-­‐56106141
  21. 21. キャプラン株式会社のご紹介 貿易易と航空・旅⾏行行を強みとする、総合⼈人材サービス企業 ⺟母体は伊藤忠グループ+⽇日本航空グループ。現在はパソナグループの⼀一員。
  22. 22. プロジェクトの経緯 • 2014上 派遣事業の基幹パッケージシステム更改を計画 • 2014下 次期パッケージのカスタマイズ要件の取りまとめを開始 • 2015.1理想のシステムを⽬目指す中で、改修対象と規模が拡⼤大 • 2015.3  ゼンアーキテクツにお声がけいただく • 2015.4  基幹パッケージとフロントシステムを分離した アーキテクチャとしてプロジェクト再スタート • 2015.4  フロントシステムを内製化し、 継続的な開発が可能な体制を⽬目標設定し⼈人材調達・チーム編成 • 2015.5  プロジェクト開始 • 2015.9 派遣登録申込機能を外部向けに初リリース • 2015.1  教育事業システム開発プロジェクト⽴立ち上げ(予定) • 2015.4  派遣事業新基幹システム稼働開始(予定)
  23. 23. 1.  動機とコミットメント
  24. 24. プロジェクトライフサイクルの選択は、 不確実性への対処戦略である。
  25. 25. ”不確実性”のレベル • ほとんどの事象は想定可能な⼀一定の幅に収まる • ビジネスでは、Lv.1=50%、Lv.2+Lv.3=50%、Lv.4=まれに出現 Lv.1 確実な未来 Lv.2 選択的未来 Lv.3 一定の幅 Lv.4 予測不能 適応する未来を形成する 留保する スピード、アジリティ、柔軟性リーダーシップ、標準 早期のコミットを避ける 戦略 「不不確実時代の⾏行行動と戦略略」ヒュー・コートニー、他 ハーバードビジネスレビューブックス:不不確実性の経営戦略略(ダイヤモンド社)より 企業システムにアジャイルは必要か
  26. 26. 計画できることは、計画して実施する • 「正しい」ことが分かっている • よほど⼤大きな問題が発⽣生しない限り“うまくいく” • 事業者は「必要な時期」に「必要なもの」が⼿手に⼊入れば良い。 • 定型反復業務 • 確⽴立された⼿手順 予測型 (計画駆動) Lv.1 確実な未来 Lv.2 選択的未来 PMBOK 5th ウォーターフォール型 企業システムにアジャイルは必要か
  27. 27. 計画できないことは、確認しながら進む • 何が「正しい」のか判断できない • 正しいものが変化する • 機能・技術・ビジネス、マーケット • 変化への継続的な対応 • 「要求の変化」と「優先順位の変化」 • 要求の変化=反復型による継続的フィードバック • 優先順位の変化=バックログによる動的要求管理 反復型 Lv.3 一定の幅 適応型 (変化駆動/アジャイル) PMBOK 5th 企業システムにアジャイルは必要か
  28. 28. 最初の判断基準 両⽅方可能ならば、ウォーターフォール型を推奨 p 最初に詳細な仕様を確定できるか p 精度の⾼高い⾒見積と計画は可能か
  29. 29. システム企画 ビジネス企画 ⾼高精度度な⾒見見積りと計画が可能か 計画可能 パッケージ導⼊入 熟知した業務 使い慣れた技術 予測型/外部調達 精度度が低い DeadLine(納期)は 決まっているか 再設定可能 決まっている 精度度向上施策の実施 ⽬目指す製品は明確に仕様化可能か 仕様化可能 仕様化困難 他社との差別化/先⾏行行が必要か 類似プロダクトの調査 ソリューションの 仮説検証サイクル 発⾒見見 スコープを限定した 予測型/外部調達 存在せず ⾃自社開発の必要性 DeadLine(納期)は 決まっているか 再設定可能 決まっている (できるだけ早く) プロトタイピング 適合性調査 適応型 新しいUI・新しいデバイス 新技術・利利⽤用技術の転換 提供⽅方式の転換(PKG→Web) 必要ない 必要 あり なし 外部調達 この⼿手段を 探していた 既存システムあり 必要とする レイヤーも様々 適応型で 代替可能
  30. 30. 適応型(アジャイル)を選択すべき状況 •全てYes、つまり競争状態にあるビジネス領域で 選択されるべき p 不確実性が残っている p 他社との差別化が必要 p 時間に猶予がない
  31. 31. アジャイルは、 ビジネスの必要に迫られて 選択する⼿手段 提案して採⽤用してもらうものではない。 強い動機がないなら、今まで通りで⼗十分。
  32. 32. 最終的には 「費⽤用」対「効果」対「リスク」
  33. 33. • これまで抑制してきた分、システムに投資する。リスクは取る • ⼈人材サービスのAmazonを⽬目指す。 • 時間かけて検討するより、どんどん良くしていこうよ! • エンジニアもゼロから育成して市場価値を⾼高めたい。 キャプラン株式会社 代表取締役社⻑⾧長 森本 宏⼀一 株式会社パソナグループ 取締役 株式会社パソナテック 代表取締役会⻑⾧長 社⻑⾧長の強⼒力なコミットメント
  34. 34. Q.  なぜ、強い動機なしに、 企業がアジャイルに⼿手を出しては いけないのか?
  35. 35. 2.  既存の管理統制スキーム
  36. 36. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. エンタープライズアジャイルの成熟度度レベル 予測型 Level  0 予測型のみ 予 測 適 応 独⽴立した環境で アジャイル 予 測 適 応 独⽴立しているが 同じ統制下 Level  1 Level  2 予 測 適 応 同じ統制下で 予測型と連携 Level  3 統制 予測型と混在 Level  4 統制 統制 事業活動そのもの アジャイルから リーンへ Level  5 統制 継続的 事業活動 それぞれのLevelで規模のスケール 株式会社ゼンアーキテクツによる定義
  37. 37. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. 37 成熟度“Level  3”  への壁 「予測型」前提の管理スキーム
  38. 38. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. 38 アジャイルを特徴づける5つの要素 反復型 適応型要求管理 ジャストインタイム コードの共同所有 リソースと納期の 固定 Agile
  39. 39. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. 39 リソースと納期を固定する 固定された 要求 リソース 納期見積もられた 要求 リソース 納期 予測型プロジェクト アジャイル(適応型) • メンバーを固定=見積もり精度を最大化 • リリース日を固定=事業計画との整合 • 要求可変=見積もり誤差を要求スコープで調整 図:「アジャイルソフトウェア要求(翔泳社)」第1章より引用 リソースと納期の 固定
  40. 40. 無防備で踏み⼊入ると、、
  41. 41. アジャイルプロジェクトのレビューで 必ず指摘されること üリリース時点でどの機能が使えるのか ü全体の進捗が知りたい ü仕様書がないのに作れるはずがない ü計画はFIXできないのか üこんなに計画変更が多発するプロジェクト はおかしい。順調なはずがない。
  42. 42. アジャイルプロジェクトのレビューで 必ず指摘されること üリリース時点でどの機能が使えるのか ü全体の進捗が知りたい ü仕様書がないのに作れるはずがない ü計画はFIXできないのか üこんなに計画変更が多発するプロジェクト はおかしい。順調なはずがない。
  43. 43. 既存の組織管理体系とのギャップ 可視化できれば、解決策はある。 アジャイルが 対処すべき アジャイルの 理理解 本質的に⽭矛盾
  44. 44. エンタープライズにおける アジャイルプロジェクトに不可⽋欠なもの アジャイルが 対処すべき 「全体計画」の可視化 いつ、何ができるのか、⾒見通しを⽰示す。 これがあるだけで、全然違う。
  45. 45. ≪前提≫ アジャイルの⾒見積りと計画⼿手法は 想像以上にうまく設計されている。 現実性/精度/⾒見積もりコストのバランスが絶妙
  46. 46. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. スクラム 46
  47. 47. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. 47 アジャイルプロジェクトの⾒見見積もりは 「ボトムアップ(積算)」 要求 ストーリー1 ストーリー2 ストーリー3 ストーリー4 識別 ストーリーn 必要工数 必要工数 必要工数 必要工数 必要工数 積み上げ 工数 要求を「重なり合ったストーリー」として定義し、 個別ストーリーの実現工数を積算
  48. 48. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. 48 【参考】ボトムアップ⾒見見積もり 要求仕様 作業1 作業2 作業3 作業4 作業n 必要工数 必要工数 必要工数 必要工数 必要工数 積み上げ 工数 成果物 分割 「本当に使える見積もり技術(日経BP社)」より引用
  49. 49. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. ⾒見見積もりはどこで⾏行行われるか 49 ①規模見積もり ②期間見積もり ③工数見積もり ④見積もりの改善
  50. 50. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. 50 アジャイルの⾒見見積もりの流流れ ①規模⾒見見積もり ストーリー 要求識別 ストーリー ストーリーの 見積もり 作成 ストーリーポイントの設定 プランニング ポーカー ストーリー積算による 規模見積もり set 新たなストーリーが 識別されなくなるまで ストーリーポイントの合計が 要求の規模 見積もり時の不毛な議論(100か 101か)を避けるため、ストーリーポ イントにはフィボナッチ数列の利用 を推奨 プロダクト バックログ +ストーリーポイント合計 ストーリー +  ストーリーポイント
  51. 51. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. スプリントスプリント ストーリー 51 アジャイルの⾒見見積もりの流流れ ②期間⾒見見積もり ストーリー 次スプリントの 作成 ストーリーストーリー スプリント バックログの 割り当て 前スプリントの 実績よりベロシティ設定 プロダクト バックログ スプリント バックログ リリース計画による 期間見積もり スプリント +  期間 +  ベロシティ +  ストーリー ポイント合計 ストーリー 優先順位の高い ストーリーから取得 SPがベロシティを 超えないよう ストーリーを割り当て set setget 実現するストーリーが 全てスプリントに 割り当てられるまで 1 1..* 1 1 スプリントの期間合計が プロジェクト期間 チーム編成は基本固定 期間は「2週間」が標準 チーム/組織 +  ベロシティ
  52. 52. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. タスク ストーリー 52 アジャイルの⾒見見積もりの流流れ ③⼯工数⾒見見積もり ストーリーの タスク分解 タスクアサイン と作業時間見 積もり スプリント バックログ スプリント計画による 工数見積もり +  ストーリー ポイント合計 ストーリーget タスクの定義 実施スプリントのタスク・工数の見積もり確定 実施スプリントのバックログ タスク +  担当者 +予定作業時間 set スプリントで実現する ストーリー全て 全てのタスク 工数合計がスプリント期間を超える もしくは大きな乖離がある タスク見積もり の精査 ストーリーの 割り当て変更 このスプリントでの1ポイントあたりの作業 工数見積もりは算出は可能。 しかし見積もりの数字遊びを避けるためSP を意図的に精緻に見積もらないようにして いる(フィボナッチ)ので、見積もりのポイン トからの実時間算出は無意味 ストーリーポイントの 見積もりとのギャップ エピック 1 0..* 任意の分類軸 creates
  53. 53. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. タスク ストーリー 53 アジャイルの⾒見見積もりの流流れ ④⾒見見積もりの改善 タスクの実施 スプリントデモ スプリント バックログ スプリント実施とフィードバックによる 継続的見積もり改善 +  ストーリー ポイント合計 ストーリー 実施スプリントのバックログ タスク +  担当者 +予定作業時間 +ステータス 全てのタスク スプリントタスク完了 リリース計画へ のフィードバック 対象ストーリーは変えない ステータス更新 タスクボード 未着手 →着手中 →完了 タスクの追加、 変更、削除 仕様化、レビュー、実装、テ スト、不具合改修、データ作 成、環境構築、リリース、等 ストーリーストーリーストーリー プロダクト バックログ • ストーリーの追加・削除・修正 • 各ストーリーポイント見直し • 優先順位変更 任意の タイミング 追加変更 要求 次のスプリント計画へ ストーリー単位で完了/未完了を判断 未完了のストーリーは実績ストーリーポイントに含めない 実績ストーリー ポイント = ベロシティ
  54. 54. アジャイルな⾒見積もりの 4つの利点 1. 全体計画と実施計画の分離 2. プロジェクト内のフィードバックループ 3. 「相対値の積算⾒見積もり」という落としどころ 4. ⾒見積もりコストの低さ 54
  55. 55. 5.  計画を「導出」可能
  56. 56. アジャイルのリリース計画は 「⼿手作り」するものではない。
  57. 57. Continuous  Release  Planning 「継続的リリース計画」 Agile  Processes  in  Software  Engineering  and  Extreme  Programming 「Continuous  Release  Planning  in  a  Large-‑Scale  Scrum  Development  Organization  at  Ericsson」
  58. 58. 反復毎にリリース計画そのものを “リリース”する
  59. 59. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. イテレーション5 イテレーション6 イテレーション7 ・新たなストーリー ・優先順位の入替 ・利用技術の見直し ・ストーリーの分割 継続的リリース計画 常時「見通し」を可視化 影響を反映 影響を反映 ・・・
  60. 60. チーム活動の透明化によって 事業活動との連携が⽣生まれている • プロダクトオーナーがリリース計画を更新するようになった • 他の事業部の施策の考慮 • 外部プロジェクトとの依存関係調整 • 他の施策の状況に応じて、リリース優先順位の⼊入替を⾏行うよう になりつつある。 ブラックボックスの プロジェクト 「システムの調達」から「事業としての⽣生産活動」へ 要求 システム ブラックボックスの プロジェクト 事業活動と連携した⽣生産活動
  61. 61. 「こんなに計画変更が多発するプロジェクトは おかしい。順調なはずがない。」 =予測型管理スキームを前提とすると、 「“計画を変更すること”がリスク」という認識 本質的に⽭矛盾
  62. 62. これが最もやっかい。
  63. 63. 必要なのは、 意識改⾰革だけではない
  64. 64. 「予測できないことに予測型を適⽤用する」ことに、 組織は慣れすぎていないか 計画 予定外の事象 計画変更の検討 固定された要求 リソース・納期 の変更 再検討駆動ライフサイクル
  65. 65. 「予測できないことに予測型を適⽤用する」ことに、 組織は慣れすぎていないか 計画 予定外の事象 計画変更の検討 固定された要求 リソース・納期 の変更 ⾦金金・時間の 垂れ流流し 先送り 拡⼤大する 再検討駆動ライフサイクル 終わりの⾒見見えない 泥泥沼 PMの仕事は “限られた資源”の 最適配分ではないのか。
  66. 66. 再検討駆動ライフサイクルへの対策 初級 • 「プロジェクトはリソース(予算)と期間によって制約される」という 認識の徹底。リスケ・予算変更は許さない。 • つまり、「要求の縮⼩小」という⼿手法を積極的に活⽤用する⽂文化の醸成 中級 • 機械的に「プロジェクト中⽌止」を判断するルールの設定(決断できない) • 不確実性の⾼高いプロジェクトは全て外部調達(外部へのリスク移転) 上級 • 「最初の計画が正しい」という認識を捨てる • つまり、適応型(アジャイル)プロジェクトの適⽤用
  67. 67. 3.  プロダクトビジョンと スコープコントロール
  68. 68. アジャイルプロジェクトのレビューで 必ず指摘されること(プロダクト編) üユーザーが必要だと⾔言うので必須です ü今提供している機能はマスト。 機能ダウンするわけにはいかない üやはりこっちの⽅方がいいんじゃないかな üこの機能があったほうが便利だ
  69. 69. アジャイルは 「変更を許している」がゆえ、 要求を突っ込みやすい。 要求を出す側は、 「無理すれば追加できるだろう」と考えやすい。
  70. 70. スコープ拡⼤大は、⼈人間の本能。 「せっかくだから」「どうせやるなら」・・・
  71. 71. 「ユーザーの要望は、製品仕様ではない」 • テクノロジの進化をエンドユーザーは知らない。 ユーザー要望は、参考情報に過ぎないと捉えるべき。 • プロダクトマネージャの製品への意思が、 要望を製品の機能性に変換する。 要望 プロダクト ビジョン 製品の 機能・仕様 要望 要望 要望 要望 要望要望 要望
  72. 72. 「スコープコントロール」は プロジェクトの成功に不可⽋欠 üアジャイルは、先⾏行して仕様を⽂文書化しないため、 スコープが曖昧になる。 üリソース・納期のキャパシティを超えて要求が流⼊入しやすい。 üゆえに、プロダクトオーナーによる「スコープコントロール」が 特に重要(“いますぐに実装しない”判断) üアジャイルの2週間のタイムボックスは、 実現可能なスコープを測るための「現実的な器」である。 アジャイルはスコープにセンシティブであるべき
  73. 73. 要求のみに注⼒力することで、 スコープコントロールの⽂文化が 少しずつ根付いてきた • 基幹業務をまわすために必要な最低限の機能(基本ストーリー)< MMRとも⾔言う>と、あると便利な機能(拡張ストーリー)に分割し、 “業務を回すための⼀一式”が必ずリリースに含まれるよう分割して 扱うことを⼼心がけている。 • ゆえに、ストーリーの粒度は⼩小さく。 • タイムボックスに収めるためには、採⽤用技術も重要。 • ユーザー要望は、プロダクトバックログの「外部」で管理している。 バックログには製品化するストーリーのみ記載。 • とはいえ、MMRの識別とユーザー交渉は双⽅方に⼤大きな負担だが、成 功の鍵はここにあると認識している。 MMR:  Minimum  Marketable  Release
  74. 74. To-­‐Be 業務フロー ユーザからの 要望/要求 ビジョン 技術 実装⽅方式 初期のアー キテクチャ アーキテク チャ ドキュメント 主要なストーリーを実装 (US、TS) 実現する業務を ストーリーとして切切り出して登録 受け⼊入れられた 実装済ストーリーを、To-­‐Beにフィードバック SP 実装実績から ⾒見見積基礎値を設定 ⽅方式、パターン サンプルコード 2W 優先順位の⾼高いストーリーを タイムボックスで計画化 チームで 実装 実装された 機能 修正・追加要望をバックログに追加 イテレーションデモ レビュー ユーザ(業務カテゴリをエピックで 分類すると識識別しやすい) ソース 管理理 ビルド・デプロイ・テスト プロダクトバックログ ⾒見見積基礎値の フィードバック ドキュメントの追記・更更新 Living Document イテレーション計画 ⾃自動回帰テスト 受⼊入テスト リリース判定 Ops リリース 本番運⽤用 インシデント管理理 修正依頼 ユーザ 運⽤用担当者 ユーザ オーナー 企業におけるアジャイルプロジェクトのありかた プログラムマネージャ PMO事業部⻑⾧長 報告 品質管理理部⾨門 品質基準 プロダクトオーナー ビジョン 継続的リリース計画 ⽬目指すべきは、 ビジョンを軸としたプロダクト⽣生産サイクル アジャイルから ⽣生産活動へ スコープ コントロール
  75. 75. ビジョン 継続的 リリース計画 エンタープライズ アジャイル チーム スコープ コントロール 新しい アイディア 継続的な 製品化 新たな施策 ⽣生産活動の透明性 ⽬目的軸 フローコントロール 事業としてのプロダクト⽣生産活動 事業での 結果 エンタープライズアジャイルの ⽬目指すべき姿
  76. 76. 達成できたこと • 新規システムをプロジェクト開始から3ヶ⽉月でリリース • 社内エンジニアゼロからの調達・育成 • 継続的な内製開発運⽤用体制の確⽴立 • アジャイルプロジェクト活動の分散拠点開発 • リリース計画の⾃自動化・精緻化による事業戦略との連携
  77. 77. 認識している課題 • ウォーターフォール型プロジェクトとの連携強化 • より能動的なスコープコントロールが必要 • 将来の開発チームのスケール(⽣生産⼒力強化) • 教育事業との並⾏行開発に向けて
  78. 78. フロント開発チームリーダー 南 邦彦様(プロモーション企画Tリーダー)の視点 • 良かった点 • 現場の⼈人間がシステム開発に携わることができる。 思った以上にめっちゃ良い。 • 今までは、システム開発は⼀一部の⼈人だけで進めていた。 変えたくても変えられない「システムという制約」が ビジネスを阻害していたと考えていたが、それは⾔言い訳だった。 • 思ったより⼤大変だった点 • その分、メンバー同⼠士の結束⼒力が求められる。 2週間ごとに、が⼤大変。 そして何より、理解してもらうことが⼤大変。 • トップの強い意向がないと、難しかったんじゃないかと思う。 • 改善点・慣れない点 • 中の⼦子にも「次に何をやるのか」を⾒見せてあげることが⼤大切。 たとえ後で変わるとしても。 • ⼯工数の考え⽅方が難しい。⼈人依存でやってみなければ出せないところ。 • まとまったシステムを作るときに「全部でいくら」が出しづらい。 「それで収まるの?根拠は?」と聞かれると困る。 • 受託だったら、スケジュールに合わせて尻を叩ける。 アジャイルは、「どうしてもやる」を詰め込みにくい。 サラッと「収まらない」と⾔言われると、無理をいいにくい。
  79. 79. ゼンアーキテクツが、 企業システムへのアジャイル内製化⽀支援の 活動を通じて学んできこと Øエンジニアリング⾯面では、企業システムへのアジャイル内製化に 障壁はない。チームの⽴立ち上げに不安なし。 Ø積極的なスコープコントロールが必須のため、⼀一括受託型での適 ⽤用はやはり難しいという認識。適⽤用には⼯工夫が必要。 Øアジャイルは、予測型に硬直した組織⽂文化を変⾰革させるための触 媒となる。システム開発だけでなく⽇日本の産業の国際競争⼒力を⾼高 めるための有⼒力な⼿手段になりえる。 Our journey still continues...
  80. 80. 82 zenarchitects.co.jp facebook.com/zenarchitects

×