エンタープライズアジャイル内製プロジェクトを立ち上げる前に考慮すべき3つのこと
•
37 recomendaciones•6,172 vistas
企業システム開発のアジャイル内製化を推進していく中で、実は開発チームよりも既存の事業活動に障壁が現れます。本資料では、例えばPMOや品質管理部門といった予測型を前提とした管理統制スキームを適用している組織にアジャイル内製チームを立ち上げる際に考慮すべき3つの観点について事例を交えて解説します。 【2015/12/9に開催されたエンタープライズアジャイル勉強会での講演資料です】 ※ 2015/12/12 関連スライドとして下記講演へのリンクを加筆 「俺の背中について来い」アジャイルチームを一気に立ち上げる方法 http://www.slideshare.net/hiromasaoka/ss-56106141 ※ 講演時のタイトルは「事業計画に適応するアジャイル内製プロジェクトの運営」でしたが、配付資料では講演内容に即した名称に変更致しました。
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (20)
Similar a エンタープライズアジャイル内製プロジェクトを立ち上げる前に考慮すべき3つのこと
Similar a エンタープライズアジャイル内製プロジェクトを立ち上げる前に考慮すべき3つのこと (20)
Más de Hiromasa Oka
Más de Hiromasa Oka (20)
エンタープライズアジャイル内製プロジェクトを立ち上げる前に考慮すべき3つのこと
- 1. エンタープライズアジャイル内製プロジェクトを 立ち上げる前に考慮すべき３つのこと 2015/12/9 株式会社ゼンアーキテクツ 岡 大勝 Enterprise Agile in-house project to considerbefore launching "Three things". キャプラン株式会社様の事例に学ぶ
- 2. ⾃自⼰己紹介 • 第⼀一勧銀情報システム（現：みずほ情報総研） • VOS3 COBOL＆MS-‑Cプログラマ • ⽇日本DEC • 主に⽣生保・損保・銀⾏行向けの • 資産運⽤用システムに携わる。 • ⽇日本HP • ⾦金融機関向けのシステムアーキテクチャ設計、 • 開発プロセス設計、運⽤用プロセス設計を⾏行う。 • ⽇日本ラショナルソフトウェア • 開発プロセス（RUP）および オブジェクト指向分析設計⼿手法 の導⼊入コンサルティング。 • ゼンアーキテクツ • 2003年よりIT設計事務所として活動。お客さまのIT投資の最適化を ⽬目指し、アーキテクチャ中⼼心のプロセス改善を推進。 岡 ⼤大勝 （おか ひろまさ） 株式会社ゼンアーキテクツ CEO/チーフアーキテクト プロフィール
- 3. 著作 / 翻訳
- 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 （※）ラッセル＝登⼭山で、深い雪をはらいのけ道を開きつつ進むこと。
- 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
- 13. ⽬目的別のScalingライブラリとして エンタープライズアジャイルフレームワークを活⽤用する 13 Disciplined Agile Delivery Large Scale Scrum Scrum of Scrums アジャイルの本質は不不変。良良い悪いではない。 ⾃自分の環境に適応させ進化させれるためのガイドラインに過ぎない。 ⽬目的別ライブラリとして、さらに多様化していくことを望む。
- 14. プログラムアセスメントでの 適合性確認項⽬目 1. 動機とコミットメント 2. 既存の管理統制スキーム 3. プロダクトビジョンと お客様の状況により、アジャイル導⼊入/内製化をお勧めしない場合があります アジャイル内製化プログラムを 適⽤用するに当たって、以下の状況を確認する。 スコープコントロール
- 18. To-‐Be 業務フロー ユーザからの 要望/要求 ビジョン 技術 実装⽅方式 初期のアー キテクチャ アーキテク チャ ドキュメント 主要なストーリーを実装 （US、TS） 実現する業務を ストーリーとして切切り出して登録 受け⼊入れられた 実装済ストーリーを、To-‐Beにフィードバック SP 実装実績から ⾒見見積基礎値を設定 ⽅方式、パターン サンプルコード ２W 優先順位の⾼高いストーリーを タイムボックスで計画化 チームで 実装 実装された 機能 修正・追加要望をバックログに追加 イテレーションデモ レビュー ユーザ（業務カテゴリをエピックで 分類すると識識別しやすい） ソース 管理理 ビルド・デプロイ・テスト プロダクトバックログ ⾒見見積基礎値の フィードバック ドキュメントの追記・更更新 Living Document イテレーション計画 ⾃自動回帰テスト 受⼊入テスト リリース判定 Ops リリース 本番運⽤用 インシデント管理理 修正依頼 ユーザ 運⽤用担当者 ユーザ オーナー アジャイルプロジェクトを取り巻く問題 プログラムマネージャ PMO事業部⻑⾧長 報告 品質管理理部⾨門 品質基準 プロダクトオーナー 要求の⼀一貫性 拡⼤大するスコープ システム構造の ⼀一貫性 割り込みタスク 外部からの声 （PMO、QA、有識識者） 開発チームは 問題なく⽴立立ち上がる 焦点は、「既存の組織環境」との共存〜～浸透
- 19. To-‐Be 業務フロー ユーザからの 要望/要求 ビジョン 技術 実装⽅方式 初期のアー キテクチャ アーキテク チャ ドキュメント 主要なストーリーを実装 （US、TS） 実現する業務を ストーリーとして切切り出して登録 受け⼊入れられた 実装済ストーリーを、To-‐Beにフィードバック SP 実装実績から ⾒見見積基礎値を設定 ⽅方式、パターン サンプルコード ２W 優先順位の⾼高いストーリーを タイムボックスで計画化 チームで 実装 実装された 機能 修正・追加要望をバックログに追加 イテレーションデモ レビュー ユーザ（業務カテゴリをエピックで 分類すると識識別しやすい） ソース 管理理 ビルド・デプロイ・テスト プロダクトバックログ ⾒見見積基礎値の フィードバック ドキュメントの追記・更更新 Living Document イテレーション計画 ⾃自動回帰テスト 受⼊入テスト リリース判定 Ops リリース 本番運⽤用 インシデント管理理 修正依頼 ユーザ 運⽤用担当者 ユーザ オーナー アジャイルプロジェクトを取り巻く問題 プログラムマネージャ PMO事業部⻑⾧長 報告 品質管理理部⾨門 品質基準 プロダクトオーナー 要求の⼀一貫性 拡⼤大するスコープ システム構造の ⼀一貫性 割り込みタスク 外部からの声 （PMO、QA、有識識者） 企業活動との融和 プロダクト生産活動 本資料の焦点は、 企業活動との融和
- 20. については、 下記資料で事例を紹介しています。プロダクト生産活動 もうひとつの焦点である http://www.slideshare.net/hiromasaoka/ss-‐56106141
- 22. プロジェクトの経緯 • 2014上 派遣事業の基幹パッケージシステム更改を計画 • 2014下 次期パッケージのカスタマイズ要件の取りまとめを開始 • 2015.1理想のシステムを⽬目指す中で、改修対象と規模が拡⼤大 • 2015.3 ゼンアーキテクツにお声がけいただく • 2015.4 基幹パッケージとフロントシステムを分離した アーキテクチャとしてプロジェクト再スタート • 2015.4 フロントシステムを内製化し、 継続的な開発が可能な体制を⽬目標設定し⼈人材調達・チーム編成 • 2015.5 プロジェクト開始 • 2015.9 派遣登録申込機能を外部向けに初リリース • 2015.1 教育事業システム開発プロジェクト⽴立ち上げ（予定） • 2015.4 派遣事業新基幹システム稼働開始（予定）
- 23. 1. 動機とコミットメント
- 25. ”不確実性”のレベル • ほとんどの事象は想定可能な⼀一定の幅に収まる • ビジネスでは、Lv.1=50%、Lv.2+Lv.3=50%、Lv.4=まれに出現 Lv.1 確実な未来 Lv.2 選択的未来 Lv.3 一定の幅 Lv.4 予測不能 適応する未来を形成する 留保する スピード、アジリティ、柔軟性リーダーシップ、標準 早期のコミットを避ける 戦略 「不不確実時代の⾏行行動と戦略略」ヒュー・コートニー、他 ハーバードビジネスレビューブックス：不不確実性の経営戦略略（ダイヤモンド社）より 企業システムにアジャイルは必要か
- 26. 計画できることは、計画して実施する • 「正しい」ことが分かっている • よほど⼤大きな問題が発⽣生しない限り“うまくいく” • 事業者は「必要な時期」に「必要なもの」が⼿手に⼊入れば良い。 • 定型反復業務 • 確⽴立された⼿手順 予測型 （計画駆動） Lv.1 確実な未来 Lv.2 選択的未来 PMBOK 5th ウォーターフォール型 企業システムにアジャイルは必要か
- 27. 計画できないことは、確認しながら進む • 何が「正しい」のか判断できない • 正しいものが変化する • 機能・技術・ビジネス、マーケット • 変化への継続的な対応 • 「要求の変化」と「優先順位の変化」 • 要求の変化＝反復型による継続的フィードバック • 優先順位の変化＝バックログによる動的要求管理 反復型 Lv.3 一定の幅 適応型 （変化駆動/アジャイル） PMBOK 5th 企業システムにアジャイルは必要か
- 29. システム企画 ビジネス企画 ⾼高精度度な⾒見見積りと計画が可能か 計画可能 パッケージ導⼊入 熟知した業務 使い慣れた技術 予測型/外部調達 精度度が低い DeadLine（納期）は 決まっているか 再設定可能 決まっている 精度度向上施策の実施 ⽬目指す製品は明確に仕様化可能か 仕様化可能 仕様化困難 他社との差別化/先⾏行行が必要か 類似プロダクトの調査 ソリューションの 仮説検証サイクル 発⾒見見 スコープを限定した 予測型/外部調達 存在せず ⾃自社開発の必要性 DeadLine（納期）は 決まっているか 再設定可能 決まっている （できるだけ早く） プロトタイピング 適合性調査 適応型 新しいUI・新しいデバイス 新技術・利利⽤用技術の転換 提供⽅方式の転換（PKG→Web） 必要ない 必要 あり なし 外部調達 この⼿手段を 探していた 既存システムあり 必要とする レイヤーも様々 適応型で 代替可能
- 33. • これまで抑制してきた分、システムに投資する。リスクは取る • ⼈人材サービスのAmazonを⽬目指す。 • 時間かけて検討するより、どんどん良くしていこうよ！ • エンジニアもゼロから育成して市場価値を⾼高めたい。 キャプラン株式会社 代表取締役社⻑⾧長 森本 宏⼀一 株式会社パソナグループ 取締役 株式会社パソナテック 代表取締役会⻑⾧長 社⻑⾧長の強⼒力なコミットメント
- 35. 2. 既存の管理統制スキーム
- 36. © 2015 ZEN ARCHITECTS Co.,Ltd. エンタープライズアジャイルの成熟度度レベル 予測型 Level 0 予測型のみ 予 測 適 応 独⽴立した環境で アジャイル 予 測 適 応 独⽴立しているが 同じ統制下 Level 1 Level 2 予 測 適 応 同じ統制下で 予測型と連携 Level 3 統制 予測型と混在 Level 4 統制 統制 事業活動そのもの アジャイルから リーンへ Level 5 統制 継続的 事業活動 それぞれのLevelで規模のスケール 株式会社ゼンアーキテクツによる定義
- 37. © 2015 ZEN ARCHITECTS Co.,Ltd. 37 成熟度“Level 3” への壁 「予測型」前提の管理スキーム
- 38. © 2015 ZEN ARCHITECTS Co.,Ltd. 38 アジャイルを特徴づける5つの要素 反復型 適応型要求管理 ジャストインタイム コードの共同所有 リソースと納期の 固定 Agile
- 39. © 2015 ZEN ARCHITECTS Co.,Ltd. 39 リソースと納期を固定する 固定された 要求 リソース 納期見積もられた 要求 リソース 納期 予測型プロジェクト アジャイル（適応型） • メンバーを固定＝見積もり精度を最大化 • リリース日を固定＝事業計画との整合 • 要求可変＝見積もり誤差を要求スコープで調整 図：「アジャイルソフトウェア要求（翔泳社）」第1章より引用 リソースと納期の 固定
- 40. 無防備で踏み⼊入ると、、
- 46. © 2015 ZEN ARCHITECTS Co.,Ltd. スクラム 46
- 47. © 2015 ZEN ARCHITECTS Co.,Ltd. 47 アジャイルプロジェクトの⾒見見積もりは 「ボトムアップ（積算）」 要求 ストーリー1 ストーリー2 ストーリー3 ストーリー4 識別 ストーリーn 必要工数 必要工数 必要工数 必要工数 必要工数 積み上げ 工数 要求を「重なり合ったストーリー」として定義し、 個別ストーリーの実現工数を積算
- 48. © 2015 ZEN ARCHITECTS Co.,Ltd. 48 【参考】ボトムアップ⾒見見積もり 要求仕様 作業1 作業2 作業3 作業4 作業n 必要工数 必要工数 必要工数 必要工数 必要工数 積み上げ 工数 成果物 分割 「本当に使える見積もり技術（日経BP社）」より引用
- 49. © 2015 ZEN ARCHITECTS Co.,Ltd. ⾒見見積もりはどこで⾏行行われるか 49 ①規模見積もり ②期間見積もり ③工数見積もり ④見積もりの改善
- 50. © 2015 ZEN ARCHITECTS Co.,Ltd. 50 アジャイルの⾒見見積もりの流流れ ①規模⾒見見積もり ストーリー 要求識別 ストーリー ストーリーの 見積もり 作成 ストーリーポイントの設定 プランニング ポーカー ストーリー積算による 規模見積もり set 新たなストーリーが 識別されなくなるまで ストーリーポイントの合計が 要求の規模 見積もり時の不毛な議論（100か 101か）を避けるため、ストーリーポ イントにはフィボナッチ数列の利用 を推奨 プロダクト バックログ +ストーリーポイント合計 ストーリー + ストーリーポイント
- 51. © 2015 ZEN ARCHITECTS Co.,Ltd. スプリントスプリント ストーリー 51 アジャイルの⾒見見積もりの流流れ ②期間⾒見見積もり ストーリー 次スプリントの 作成 ストーリーストーリー スプリント バックログの 割り当て 前スプリントの 実績よりベロシティ設定 プロダクト バックログ スプリント バックログ リリース計画による 期間見積もり スプリント + 期間 + ベロシティ + ストーリー ポイント合計 ストーリー 優先順位の高い ストーリーから取得 SPがベロシティを 超えないよう ストーリーを割り当て set setget 実現するストーリーが 全てスプリントに 割り当てられるまで 1 1..* 1 1 スプリントの期間合計が プロジェクト期間 チーム編成は基本固定 期間は「２週間」が標準 チーム/組織 + ベロシティ
- 52. © 2015 ZEN ARCHITECTS Co.,Ltd. タスク ストーリー 52 アジャイルの⾒見見積もりの流流れ ③⼯工数⾒見見積もり ストーリーの タスク分解 タスクアサイン と作業時間見 積もり スプリント バックログ スプリント計画による 工数見積もり + ストーリー ポイント合計 ストーリーget タスクの定義 実施スプリントのタスク・工数の見積もり確定 実施スプリントのバックログ タスク + 担当者 +予定作業時間 set スプリントで実現する ストーリー全て 全てのタスク 工数合計がスプリント期間を超える もしくは大きな乖離がある タスク見積もり の精査 ストーリーの 割り当て変更 このスプリントでの1ポイントあたりの作業 工数見積もりは算出は可能。 しかし見積もりの数字遊びを避けるためSP を意図的に精緻に見積もらないようにして いる（フィボナッチ）ので、見積もりのポイン トからの実時間算出は無意味 ストーリーポイントの 見積もりとのギャップ エピック 1 0..* 任意の分類軸 creates
- 53. © 2015 ZEN ARCHITECTS Co.,Ltd. タスク ストーリー 53 アジャイルの⾒見見積もりの流流れ ④⾒見見積もりの改善 タスクの実施 スプリントデモ スプリント バックログ スプリント実施とフィードバックによる 継続的見積もり改善 + ストーリー ポイント合計 ストーリー 実施スプリントのバックログ タスク + 担当者 +予定作業時間 +ステータス 全てのタスク スプリントタスク完了 リリース計画へ のフィードバック 対象ストーリーは変えない ステータス更新 タスクボード 未着手 →着手中 →完了 タスクの追加、 変更、削除 仕様化、レビュー、実装、テ スト、不具合改修、データ作 成、環境構築、リリース、等 ストーリーストーリーストーリー プロダクト バックログ • ストーリーの追加・削除・修正 • 各ストーリーポイント見直し • 優先順位変更 任意の タイミング 追加変更 要求 次のスプリント計画へ ストーリー単位で完了/未完了を判断 未完了のストーリーは実績ストーリーポイントに含めない 実績ストーリー ポイント ＝ ベロシティ
- 54. アジャイルな⾒見積もりの 4つの利点 1. 全体計画と実施計画の分離 2. プロジェクト内のフィードバックループ 3. 「相対値の積算⾒見積もり」という落としどころ 4. ⾒見積もりコストの低さ 54
- 55. 5. 計画を「導出」可能
- 59. Continuous Release Planning 「継続的リリース計画」 Agile Processes in Software Engineering and Extreme Programming 「Continuous Release Planning in a Large-‑Scale Scrum Development Organization at Ericsson」
- 61. © 2015 ZEN ARCHITECTS Co.,Ltd. イテレーション5 イテレーション6 イテレーション7 ・新たなストーリー ・優先順位の入替 ・利用技術の見直し ・ストーリーの分割 継続的リリース計画 常時「見通し」を可視化 影響を反映 影響を反映 ・・・
- 62. チーム活動の透明化によって 事業活動との連携が⽣生まれている • プロダクトオーナーがリリース計画を更新するようになった • 他の事業部の施策の考慮 • 外部プロジェクトとの依存関係調整 • 他の施策の状況に応じて、リリース優先順位の⼊入替を⾏行うよう になりつつある。 ブラックボックスの プロジェクト 「システムの調達」から「事業としての⽣生産活動」へ 要求 システム ブラックボックスの プロジェクト 事業活動と連携した⽣生産活動
- 64. これが最もやっかい。
- 68. 再検討駆動ライフサイクルへの対策 初級 • 「プロジェクトはリソース（予算）と期間によって制約される」という 認識の徹底。リスケ・予算変更は許さない。 • つまり、「要求の縮⼩小」という⼿手法を積極的に活⽤用する⽂文化の醸成 中級 • 機械的に「プロジェクト中⽌止」を判断するルールの設定（決断できない） • 不確実性の⾼高いプロジェクトは全て外部調達（外部へのリスク移転） 上級 • 「最初の計画が正しい」という認識を捨てる • つまり、適応型（アジャイル）プロジェクトの適⽤用
- 75. 要求のみに注⼒力することで、 スコープコントロールの⽂文化が 少しずつ根付いてきた • 基幹業務をまわすために必要な最低限の機能（基本ストーリー）＜ MMRとも⾔言う＞と、あると便利な機能（拡張ストーリー）に分割し、 “業務を回すための⼀一式”が必ずリリースに含まれるよう分割して 扱うことを⼼心がけている。 • ゆえに、ストーリーの粒度は⼩小さく。 • タイムボックスに収めるためには、採⽤用技術も重要。 • ユーザー要望は、プロダクトバックログの「外部」で管理している。 バックログには製品化するストーリーのみ記載。 • とはいえ、MMRの識別とユーザー交渉は双⽅方に⼤大きな負担だが、成 功の鍵はここにあると認識している。 MMR: Minimum Marketable Release
- 76. To-‐Be 業務フロー ユーザからの 要望/要求 ビジョン 技術 実装⽅方式 初期のアー キテクチャ アーキテク チャ ドキュメント 主要なストーリーを実装 （US、TS） 実現する業務を ストーリーとして切切り出して登録 受け⼊入れられた 実装済ストーリーを、To-‐Beにフィードバック SP 実装実績から ⾒見見積基礎値を設定 ⽅方式、パターン サンプルコード ２W 優先順位の⾼高いストーリーを タイムボックスで計画化 チームで 実装 実装された 機能 修正・追加要望をバックログに追加 イテレーションデモ レビュー ユーザ（業務カテゴリをエピックで 分類すると識識別しやすい） ソース 管理理 ビルド・デプロイ・テスト プロダクトバックログ ⾒見見積基礎値の フィードバック ドキュメントの追記・更更新 Living Document イテレーション計画 ⾃自動回帰テスト 受⼊入テスト リリース判定 Ops リリース 本番運⽤用 インシデント管理理 修正依頼 ユーザ 運⽤用担当者 ユーザ オーナー 企業におけるアジャイルプロジェクトのありかた プログラムマネージャ PMO事業部⻑⾧長 報告 品質管理理部⾨門 品質基準 プロダクトオーナー ビジョン 継続的リリース計画 ⽬目指すべきは、 ビジョンを軸としたプロダクト⽣生産サイクル アジャイルから ⽣生産活動へ スコープ コントロール
- 78. 達成できたこと • 新規システムをプロジェクト開始から3ヶ⽉月でリリース • 社内エンジニアゼロからの調達・育成 • 継続的な内製開発運⽤用体制の確⽴立 • アジャイルプロジェクト活動の分散拠点開発 • リリース計画の⾃自動化・精緻化による事業戦略との連携
- 79. 認識している課題 • ウォーターフォール型プロジェクトとの連携強化 • より能動的なスコープコントロールが必要 • 将来の開発チームのスケール（⽣生産⼒力強化） • 教育事業との並⾏行開発に向けて
- 80. フロント開発チームリーダー 南 邦彦様（プロモーション企画Tリーダー）の視点 • 良かった点 • 現場の⼈人間がシステム開発に携わることができる。 思った以上にめっちゃ良い。 • 今までは、システム開発は⼀一部の⼈人だけで進めていた。 変えたくても変えられない「システムという制約」が ビジネスを阻害していたと考えていたが、それは⾔言い訳だった。 • 思ったより⼤大変だった点 • その分、メンバー同⼠士の結束⼒力が求められる。 2週間ごとに、が⼤大変。 そして何より、理解してもらうことが⼤大変。 • トップの強い意向がないと、難しかったんじゃないかと思う。 • 改善点・慣れない点 • 中の⼦子にも「次に何をやるのか」を⾒見せてあげることが⼤大切。 たとえ後で変わるとしても。 • ⼯工数の考え⽅方が難しい。⼈人依存でやってみなければ出せないところ。 • まとまったシステムを作るときに「全部でいくら」が出しづらい。 「それで収まるの？根拠は？」と聞かれると困る。 • 受託だったら、スケジュールに合わせて尻を叩ける。 アジャイルは、「どうしてもやる」を詰め込みにくい。 サラッと「収まらない」と⾔言われると、無理をいいにくい。