企業システムにアジャイルは必要か

1. 企業システムにアジャイルは必要か 2015/6/22 株式会社ゼンアーキテクツ岡大勝 "Agile" is reallyneed to enterprise system?

2. ⾃自⼰己紹介 • 第⼀一勧銀情報システム（現：みずほ情報総研） • VOS3 COBOL＆MS-‐Cプログラマ • ⽇日本ディジタルイクイップメント（⽇日本DEC） • 主に⽣生保・損保・銀⾏行行向けの資産運⽤用システムに携わる。 • Alpha NT, SQL Server, DECnet • ⽇日本ヒューレット・パッカード C&I-‐Financial • ⾦金金融機関向けのシステムアーキテクチャ設計、開発プロセス設計、運⽤用プロセス設計を⾏行行う。 • HP-‐UX, J2EE, WebLogic, Oracle Database, OO • ⽇日本ラショナルソフトウェア • 開発プロセス（RUP）およびオブジェクト指向分析設計⼿手法の導⼊入コンサルティング。 • RUP, Rose, ClearCase, Functional Tester • ゼンアーキテクツ • 2003年年よりIT設計事務所として活動。お客さまのIT投資の最適化を⽬目指し、アーキテクチャ中⼼心のプロセス改善を推進。著作/翻訳 • 「要求」の基本原則（技術評論論社）2009 • 本当に使える開発プロセス（⽇日経BP社）2012 • ディシプリンド・アジャイル・デリバリー（翔泳社）2013 岡⼤大勝（おかひろまさ）株式会社ゼンアーキテクツ CEO/チーフアーキテクトプロフィール

3. © 2015 ZEN ARCHITECTS Co.,Ltd. そもそも「アジャイル」は必要なのか？ • ウォーターフォールで何が悪い？ • いや、悪くない • QCDを最初に厳密に規定し計画するのがウォーターフォール。 • 計画通りにプロジェクトが完了了するのであれば、むしろ望ましい • なぜ、別の⼿手法が必要なのか • プロジェクトが「最初に規定し計画した通り」に進まない。 • なぜ、計画通りに進まないのか • システム開発には、不不確実性の⾼高い要素が多い＝ “リスク” • 「要求リスク」「スキルリスク」「技術リスク」「政治リスク」 3 できるだけ早い時点でリスクをキャッチアップしながらプロジェクトを進める手法が必要

5. © 2015 ZEN ARCHITECTS Co.,Ltd. ”不不確実性”のレベル • ほとんどの事象は想定可能な⼀一定の幅に収まる • ビジネスでは、Lv.1=50%、Lv.2+Lv.3=50%、Lv.4=まれに出現 Lv.1 確実な未来 Lv.2 選択的未来 Lv.3 一定の幅 Lv.4 予測不能適応する未来を形成する留保するスピード、アジリティ、柔軟性リーダーシップ、標準早期のコミットを避ける戦略「不不確実時代の⾏行行動と戦略略」ヒュー・コートニー、他ハーバードビジネスレビューブックス：不不確実性の経営戦略略（ダイヤモンド社）より

7. © 2015 ZEN ARCHITECTS Co.,Ltd. 計画できないことは、確認しながら進む • 何が「正しい」のか判断できない • 正しいものが変化する • 機能 • 技術 • ビジネス、マーケット • 変化への継続的な対応 • 「要求の変化」と「優先順位の変化」 • 要求の変化＝反復復型による継続的フィードバック • 優先順位の変化＝バックログによる動的要求管理理反復型 Lv.3 一定の幅適応型（変化駆動/アジャイル） PMBOK 5th

8. © 2015 ZEN ARCHITECTS Co.,Ltd. システム開発に潜む不不確実性（リスク） • 要求リスク • 当初想定からの機能の増加（スコープの拡⼤大） • 要件の認識識不不⾜足（⼿手戻り、再作業） • 仕様の決定が遅れる • 不不適切切なUI • 顧客による継続的な変更更要求 • 技術リスク • 想定していた性能が出ない • 想定される動作をしない（接続できない、想定外のエラー） • ⽬目的に合致しない技術（拡張性、接続性） • スキルリスク • 利利⽤用技術の経験がない • 今回の開発プロセスの経験がない（初めての進め⽅方） • 政治リスク • 予測不不能。だが想定は⾃自由 8 Barry Boehm introduced to us in 1981 and Steve McConnell re-‐introduced in 1997 in his book Software Project Survival Guide. https://msdn.microsoft.com/en-‐us/library/hh765979.aspx 不不確実性コーン(the Cone of Uncertainty)

9. © 2015 ZEN ARCHITECTS Co.,Ltd. ”事業者”と”システム提供者”で「不不確実性」は異異なる 9 事業者システム提供者低 (Lv1,2) 適応適応高 (Lv3) 形成反復型適応型低 (Lv1,2) 高 (Lv3) 市場・競合・法制要求・技術・スキル予測型予測型適応適応反復型適応型【IT業界構造】・要求は変わる・技術も変わる・⼈人は外部調達【リスク回避戦略略】・仕様FIX ・慣れた（古い）技術・実績あるメンバー【リスク許容戦略略】・要求変動を許容・新技術を適⽤用・過去実績の横展開・パッケージ適用システム開発リスクの転嫁定められた期⽇日に、仕様通りに利利⽤用開始できればいい。外部に委託するにはリスク・コストが⾼高すぎる場合、内製を検討。・要求変動リスクを⾃自ら取る・「技術」「⼈人」を固定不確実性戦略降りる仕様・期間/コスト・品質アジャイル（Scrum）不不確実性の⾼高い受託型を成功させるには、反復復型・適応型の戦略略が前提。・納期に何が必須か「価値・リスク駆動」・幅を持った”約束”「スコープ、コスト」エンタープライズ・アジャイル「他組織からは予測型」単一チームから組織的活動に拡大する際、社内でも同じ問題に直面。他、反復型プロセス軽量反復型プロセス【激しい競合】迅速な対応が求められる。

10. © 2015 ZEN ARCHITECTS Co.,Ltd. 開発プロセスの歴史 l 1960年年代：「Code & Go」 l 「聞いて、書いて、動かす」 l 1970年年：「ウォーターフォールモデル」Winston Royce l 「設計」の発明 l 要求を正しく扱うため「分析」の導⼊入など、その後も進化を続ける l 1988年年：「スパイラルモデル」Barry Bohem l 「⽬目標」「リスク分析」「実施」「計画」のサイクルで⼯工程が進む l 1991年年：「反復復型（イテレーティブ）開発」「漸進型（インクリメンタル）開発」 l ⼩小さな単位で開発することで、リスクを早期に識識別する。 l 1992年年：「Vモデル」German Ministry of Defense l ウォーターフォールモデルに品質保証の観点を追加。 l 1998年年：「ユニファイド・プロセス（UP）」Jacobson, Booch, Rambaugh l ユースケース・UMLに基づくオブジェクト指向開発プロセス。Rational社による商⽤用版が「RUP」 l 1999年年：「エクストリーム・プログラミング（XP）」Kent Beck l ドキュメントよりもコラボレーションに焦点を当てた軽量量開発プロセス。 l 2002年年：「スクラム（Scrum）」Ken Schwaber, Mike Beedle l 価値駆動の軽量量開発プロセス。原型は1986年年に⽵竹内弘⾼高⽒氏、野中郁次郎郎⽒氏が考案した製品開発⼿手法。 l 2009年年：「SEMAT」Jacobson他 l これまでの作業/成果物中⼼心のソフトウェアエンジニアリングモデルを活動/価値中⼼心に再構築。 l 2011年年：「スケールド・アジャイル・フレームワーク（SAFe）」Dean Leffingwell l アジャイルを単⼀一チームから企業規模にスケールするための⼿手法。 l 2012年年：「ディシプリンド・アジャイル・デリバリー」Scott W.Ambler, Mike Lines l アジャイルを企業活動に適合するよう拡張。 l 2013年年：「PMBOK 5th Edition」PMI l アジャイル（適応型ライフサイクル）がプロジェクトライフサイクル型として追加。 10

11. © 2015 ZEN ARCHITECTS Co.,Ltd. アジャイルは何が違う？ • 進め⽅方が違う（だけ） • 個々の作業は同じ • プロセスフレームワークの組み合わせが違う • “計画通りには進まない“ことに対処する。 • 動くシステムを使って（作って）みなければ、正しいかどうか分からない • ⼿手直し（軌道修正）しながら進むために、作業⼯工程を⾝身軽にする • ⼯工程別フェーズ → 反復復型フェーズ • 成果物駆動 → ジャストインタイム • 予測型（計画駆動） → 適応型（価値駆動・リスク駆動） 11 ウォーターフォール ”型” アジャイル ”型”

12. © 2015 ZEN ARCHITECTS Co.,Ltd. プロセスフレームワークの組み合わせ • 開発プロセスの違いは、プロセスフレームワークの組み合わせの違い • ⼯工程別フェーズ x 成果物駆動 x 予測型（計画駆動） • ウォーターフォールモデル • V字モデル • 反復復フェーズ x ジャストインタイム x 適応型（価値駆動） • スクラム • XP • 反復復フェーズ（ゴール指向） x 成果物駆動 x 適応型（リスク駆動） • ユニファイド・プロセス（UP） • 反復復フェーズ（ゴール指向） x ジャストインタイム x 適応型（価値・リスク駆動） • ディシプリンド・アジャイル・デリバリー（DAD） 12

13. © 2015 ZEN ARCHITECTS Co.,Ltd. 「反復復型」フェーズ • 要求の実装完了了が、フェーズの完了了基準 • 特徴 • 動作する機能が早期に利利⽤用できる • 統合とテストの負担が⼤大きい 13 要求分析設計実装テスト要求分析設計実装テスト要求分析設計実装テスト要求分析設計実装テスト要求分析設計実装テストプロジェクト開始リリース技術リスク・要求リスクへの対処要求分析設計実装テスト要求分析設計実装テスト要求分析設計実装テスト要求分析設計実装テスト要求分析設計実装テストプロジェクト開始リリース反復型フェーズ工程別フェーズ

15. © 2015 ZEN ARCHITECTS Co.,Ltd. ジャストインタイム（JIT） • 作業の管理理を、テスト結果によって⾏行行う • 中間成果物は「それが必要な場合に」作成する 15 要求分析実装テスト要求分析実装テスト要求分析テスト設計実装設計設計チェックポイント要求分析設計実装テストチェックポイントチェックポイントチェックポイントチェックポイントチェックポイントタスクそのものを「必要に応じて」実施チェックポイントチェックポイント成果物駆動ジャストインタイムデータ設計テストデータ作成

17. © 2015 ZEN ARCHITECTS Co.,Ltd. エンタープライズで「JIT」は有効か • テクノロジーの進化で、JITベース開発での保守引き継ぎが現実的になった 1. システムのあり⽅方（主にUI）にiOS等を規範とするコンセンサスが醸成されてきたこともあり、技術がシンプルに洗練されてきた。（J2EE→Rails→SPA+MSAの流流れ） 2. 利利⽤用技術が絞られ、標準的な利利⽤用⽅方法で作成できる割合が増加。カスタムコンポーネントの減少。（VB/Web/RIA → モダンWeb〜～フレームワーク適⽤用範囲拡⼤大〜～専⽤用設計の減少） 3. さらに、OSSで提供されるモジュール、ライブラリの適⽤用範囲拡⼤大に伴い、記述コード量量の⼤大幅な減少（同⼀一システムでコード量量が1/5程度度に） 4. コードベースが⼩小さくなることで、ドキュメントの主⽬目的である”引き継ぎ”をコードレベルで⾏行行う「コードの共同所有」。それに伴いドキュメントの⽬目的が、設計⽅方式や実装パターンの共有へ移⾏行行。実装後に清書する「ドキュメント・レイト」や、継続的修正が前提の「リビング・ドキュメント」で実⽤用的な保守が可能になった。 17 要求分析設計実装テスト要求分析設計実装テスト要求分析設計テスト ※本資料料は株式会社ゼンアーキテクツによる調査と考察によるものです。アーキテクチャ/ アーキテクチャドキュメント「標準的」な作り⽅方の機能は省省略略できるフレームワーク/ライブラリモジュールコーディングから「宣⾔言と記述」へ実装⽅方法が変化（ほぼUCそのまま）実装コンパクトで要点に絞った「⽣生きた」ドキュメント

18. © 2015 ZEN ARCHITECTS Co.,Ltd. 要件3要件2 要件1 適応型（価値駆動・リスク駆動） • 作業順序を決定するための要求管理理⽅方式 • プロジェクト開始時に、要件を価値/リスク基準で優先順位を設定。 • 期間 x リソースのタイムボックスに割り当てながら進める。 18 要求分析設計実装テスト要求実装テスト 10⽉月/1W〜～2Wタイムボックステスト 10⽉月/3W〜～4Wタイムボックス要件4 要件5 要件6 優先順位の高い要件（バックログ）から、タイムボックスに割り当て要件1 要件2 要件3 要件4 要件5 ⾼高優先順位低・価値/リスクの変動・新たな要件の追加＝優先順位の入れ替えタイムボックスの容量≒ベロシティ ≒イテレーション実装要件25 個々の要件の概算見積もりの合計がベロシティに収まるよう、タイムボックスに割り当てる

19. © 2015 ZEN ARCHITECTS Co.,Ltd. アジャイル”型”で何が得られる？得られるもの 1. 不不必要な作業の削減 • JITの効果 • ＝⽣生産性向上＝コスト最⼩小化（最適化） 2. リスクの減少 • 反復復型の効果 • リスクの早期識識別と早期（⼩小さいうちに）対処 • ＝再作業の削減＆我慢（＝ビジネス価値低下）の最⼩小化 • 再作業の原因（リスク）のほとんどは「要求」 • 「ほしいものはこれじゃない」 • 動くものを触ってもらう • ITは、社会活動全体から⾒見見るとそこまで成熟していない（モノを⾒見見るまで安⼼心できない） 19

20. © 2015 ZEN ARCHITECTS Co.,Ltd. スクラム(Scrum)の特徴 20 § プラクティス: 4プロダクト・バックログ 4価値駆動ライフサイクル 4⾃自⼰己組織化 4リリース・プランニング 4スプリント・プランニング 4⽇日次スクラムミーティング 4スプリント・デモ 4ふりかえり § ロール: 4スクラム・マスター 4プロダクト・オーナー 4チーム・メンバー

23. © 2015 ZEN ARCHITECTS Co.,Ltd. 「エンタープライズ」のコンテキスト • エンタープライズ開発 ≒ 業務システム開発 • 価値観の異異なる他の組織体と連携しながら進める開発 • 連携が避けられない、とも⾔言う • 計画に基づく活動 • 事業から⾒見見るとマイルストーンが重要。⼈人、モノ、カネを動かすタイミング。予算、期間、リソース制約も含む。 • 戦略略に則った選択 • 事業戦略略、技術戦略略、既存資産の利利⽤用（⼈人、設備、組織の経験） • 利利害関係者との調整 • 複数のユーザー部⾨門、他のシステムの運⽤用・保守・開発チーム、システムオーナー部⾨門⻑⾧長、役員 • コンプライアンスとガバナンス • 業界の法律律・規制、組織の規則・ルール・標準 • 規模 • 個別システム、関連システム、企業全体 23 アジャイルであっても避けられない

24. © 2015 ZEN ARCHITECTS Co.,Ltd. エンタープライズアジャイルエンタープライズのコンテキストで、アジャイル型を実践するための”拡張版“ • ディシプリンド・アジャイル・デリバリー（DAD）《拡張点》 • 新規開発：ビジョンの合意、⽅方向付けフェーズ、初期のバックログ構築 • アーキテクチャ：アーキテクチャ、AO（アーキテクチャオーナー）、テクニカルストーリー • コストとスケジュール：リリース計画、レンジド・バーンダウン • ガバナンス：リスクリスト、リスク・価値駆動、マイルストーンレビュー • スケールド・アジャイル・フレームワーク（SAFe）《拡張点》 • プログラムマネジメント：プログラムバックログ、プロダクトマネジメント • リリースの統制：リリース計画ミーティング、ART（アジャイルリリーストレイン）、リリースエンジニア、 IPスプリント • アーキテクチャ：システムアーキテクト、アーキテクチャ滑滑⾛走路路、テクニカルストーリー • 企業全体：ビジネスエピック、エピックオーナー、予算と投資判断、プログラムポートフォリオマネジメント、エンタープライズアーキテクト • Scrum of Scrums • Enterprise Scrum 24

28. © 2015 ZEN ARCHITECTS Co.,Ltd. 企業へのアジャイル導⼊入に必要な3つの要因 • 動機が適切切であれば、アジャイル型の導⼊入を検討する価値はある。アジャイル型の導⼊入の成否に⼤大きく影響する3つの要因がある。 • 「⼈人を礎とする」 • 「⼈人は容易易に調達可能なリソース”ではない“」ことが前提。 • ⾃自ら考え⾏行行動できる⼈人（⾃自律律的に⾏行行動できる⼈人）だけで編成できるか。経験可否は問わない。 • PO、AO、TL ＋デベロッパ 3〜～5名。⾃自⼰己組織的チームが⽬目標。デベロッパは100%専任。 • 「環境とアーキテクチャを先⾏行行させる」 • バックログ、カンバンボード、ドキュメント共有、ソース管理理の「プロジェクト推進環境」とともに、「アーキテクチャ」を先に⾛走らせる。（PO、AO、TLで先⾏行行） • デベロッパー参画時には、プロジェクト推進環境とともに技術的基盤や実装⽅方式が「ある程度度」整っている必要がある。 • 政治的調整が必要な場合は、準備するためのインセプション（⽅方向付け）を実施。 • クラウドや軽量量フレームワークなど、Just-‐‑‒In-‐‑‒Timeで調達可能かつ低負荷で利利⽤用可能な技術スタックが望ましい。 • 「オーナーとチームの固い信頼関係」 • チームはベストを尽くし、オーナーはそれを信じる。オーナーとチームとの相互信頼関係が基盤。 • 当初は⾒見見積誤差が⼤大きい。パフォーマンスの測定と⾒見見積基礎値の蓄積、適切切なイテレーション計画に向けて継続的改善。インセプションで基礎値を⾒見見出しておく。 • 安定したアーキテクチャの元でのコードの共同所有は、パフォーマンス底上げに効果⼤大。

29. © 2015 ZEN ARCHITECTS Co.,Ltd. 反復 Iterative ジャストインタイム Just-In-Time 適応型 Adaptive Lifecycle 価値駆動バックログ管理コードの共同所有リファクタリング自動回帰テスト Living Document 安定したアーキテクチャ継続的統合/ デリバリーアーキテクチャスパイクペアプログラミング BDD カンバンイテレーション計画マルチファンクショナルエンジニア（多能工）リスク駆動タイムボックスベロシティふりかえり Pull Request インセプション日次ミーティング 100%専任バーンダウンチャート自己組織的チームリスクリストアジャイルは、意外にうまく設計されているビジョンドキュメントイテレーションデモ ※ゼンアーキテクツがお客さまの現場で実践している主要なプラクティスを表したものです

30. © 2015 ZEN ARCHITECTS Co.,Ltd. To-‐Be 業務フローユーザからの要望/要求ビジョン技術実装方式初期のアーキテクチャアーキテクチャドキュメント初期のバックログビルディング (IBB : Initial Backlog Building) 主要なストーリーを実装（US、TS）実現したい業務をストーリーとして切り出して登録受け入れられた実装済ストーリーを、To-‐Beにフィードバック SP 実装実績から見積基礎値を設定方式、パターンサンプルコード２W 優先順位の高いストーリーをタイムボックスで計画化チームで実装実装された機能修正・追加要望をバックログに追加イテレーションデモレビューユーザ（業務カテゴリをエピックで分類すると識別しやすい）ソース管理ビルド・デプロイ・テストプロダクトバックログ見積基礎値のフィードバックドキュメントの追記・更新 Living Document イテレーション計画企業システムとアジャイルの親和性自動回帰テスト受入テストリリース判定 Ops リリース本番運用インシデント管理修正依頼ユーザ運用担当者

31. © 2015 ZEN ARCHITECTS Co.,Ltd. アジャイルは、予測型と「組み合わせて」使う •フロント系システム＋バック系システム • 組織のシステム単位で組み合わせる •フロントエンド(SPA) ＋バックエンド(MSA) • 単一システムのレイヤー単位で組み合わせる •インセプション(設計) + プロダクション(製品化) • 単一システムの工程で組み合わせる「全てをアジャイルで」という発想は捨てる。 31

32. © 2015 ZEN ARCHITECTS Co.,Ltd. ⾦金金融機関中規模チームでのDAD適⽤用例例 • ツール • JIRA • Confluence • Bitbucket • Jenkins • SWAT • アーキテクチャ • SPA/HTML5/knockout.js • MSA/PHP/Laravel/MySQL • RHEL • プロセス • Disciplined Agile Delivery 32 http://www.smartekworks.com/ http://www.atlassian.com/ ツール Tools プロセス Process アーキテクチャ Architecture

33. © 2015 ZEN ARCHITECTS Co.,Ltd. PO (Product Owner) システム部 Web企画部デザイナー AO (Architecture Owner) アーキテクチャ担当デベロッパー UI担当デベロッパープロダクトバックログドキュメントスプリント/タスク（計画・実績）ソースリポジトリお客様テスト環境 TL (Team Leader) <Scrum Master> プロジェクトリリース体制

34. © 2015 ZEN ARCHITECTS Co.,Ltd. PO プロダクトバックログ <JIRA> DADの開発保守サイクル課題要望制約追加/ステータス変更/ 属性変更スプリント 1 スプリント 2 スプリント 3 スプリント 4 スケジュール <JIRA> マイルストーン設定仕様優先度タスク化してスプリントに割り当て作業量見積もり将来像実装コスト適用技術実装方式・規約・ルール等 <Confluence> アーキテクチャドキュメントサンプルコードサンプルコード実装方式（パターン）の割り当て協働協働協働 AO メンバーの適性・熟練度の把握リポジトリ <Bitbucket> デザイナー TL 協働サンプルコードデザイン実装方式の調整デザイン案 HTML Web企画部デザイン案コミットアーキテクチャ担当Dev UI担当Dev コミット自動テスト作成参照把握 2W 2W 2W 2W ・バックログ作成、優先順位設定・マイルストーン設定・協働時の検討・判断・タスク設定、アサイン・実装方式の検討と定義・作業量見積もり・実装方式の習熟・成果物作成・テストの定義と実施・テクニカルバックログ・PoC・サンプル作成

35. © 2015 ZEN ARCHITECTS Co.,Ltd. アジャイルは不不確実性に⽴立立ち向かうための「道具」である 1. 未来が想定できるかどうか。不不確実性を認識識する • 想定できるなら「予測型」で計画駆動が前提。できない計画は⽴立立てない、そこに不不確実性がある 2. “事業者”と“システム提供者”の不不確実性は、特性が異異なる • システム開発のリスクは「要求」「技術」「スキル」 3. アジャイルは、不不確実性と開発効率率率に対するソリューション • 各施策やプラクティスは、ソフトウェアエンジニアリングの歴史の延⻑⾧長線上にある 4. エンタープライズアジャイルは、単にアジャイルの適⽤用範囲を広げたもの • そのぶん、シンプルさは損なわれている 5. ”アジャイル適⽤用時の不不確実性”に⽴立立ち向かうためのソリューション • システム提供者が直⾯面する「新規性」「⾒見見積り」「規模拡⼤大」をまとめて「エンタープライズ」 6. アジャイルは、思ったよりもうまく設計されている • 単⼀一のプラクティス適⽤用よりも、まとめて適⽤用した⽅方がうまくいく 7. アジャイルは、組織が⼿手にすることのできる新たな「道具」に過ぎない • 適切切な局⾯面で、適切切に組み合わせて利利⽤用できれば良良い。道具として使えるようになっておく 35

企業システムにアジャイルは必要か

Hiromasa Oka

Transcript