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

Hiromasa Oka

More Related Content

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できるだけ早い時点でリスクをキャッチアップしながらプロジェクトを進める手法が必要
4.©  2015  ZEN  ARCHITECTS  Co.,Ltd.アジャイルの期待効果１≪不不確実性への取り組み≫不確実性 開発効率
5.©  2015  ZEN  ARCHITECTS  Co.,Ltd.”不不確実性”のレベル• ほとんどの事象は想定可能な⼀一定の幅に収まる• ビジネスでは、Lv.1=50%、Lv.2+Lv.3=50%、Lv.4=まれに出現Lv.1確実な未来Lv.2選択的未来Lv.3一定の幅Lv.4予測不能適応する未来を形成する 留保するスピード、アジリティ、柔軟性リーダーシップ、標準 早期のコミットを避ける戦略「不不確実時代の⾏行行動と戦略略」ヒュー・コートニー、他ハーバードビジネスレビューブックス：不不確実性の経営戦略略（ダイヤモンド社）より
6.©  2015  ZEN  ARCHITECTS  Co.,Ltd.計画できることは、計画して実施する• 「正しい」ことが分かっている• よほど⼤大きな問題が発⽣生しない限り“うまくいく”• 事業者は「必要な時期」に「必要なもの」が⼿手に⼊入れば良良い。• 定型反復復業務• 確⽴立立された⼿手順予測型（計画駆動）Lv.1確実な未来Lv.2選択的未来PMBOK 5th
7.©  2015  ZEN  ARCHITECTS  Co.,Ltd.計画できないことは、確認しながら進む• 何が「正しい」のか判断できない• 正しいものが変化する• 機能• 技術• ビジネス、マーケット• 変化への継続的な対応• 「要求の変化」と「優先順位の変化」• 要求の変化＝反復復型による継続的フィードバック• 優先順位の変化＝バックログによる動的要求管理理反復型Lv.3一定の幅 適応型（変化駆動/アジャイル）PMBOK 5th
8.©  2015  ZEN  ARCHITECTS  Co.,Ltd.システム開発に潜む不不確実性（リスク）• 要求リスク• 当初想定からの機能の増加（スコープの拡⼤大）• 要件の認識識不不⾜足（⼿手戻り、再作業）• 仕様の決定が遅れる• 不不適切切なUI• 顧客による継続的な変更更要求• 技術リスク• 想定していた性能が出ない• 想定される動作をしない（接続できない、想定外のエラー）• ⽬目的に合致しない技術（拡張性、接続性）• スキルリスク• 利利⽤用技術の経験がない• 今回の開発プロセスの経験がない（初めての進め⽅方）• 政治リスク• 予測不不能。だが想定は⾃自由8Barry  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   Roycel 「設計」の発明l 要求を正しく扱うため「分析」の導⼊入など、その後も進化を続けるl 1988年年：「スパイラルモデル」Barry   Boheml 「⽬目標」「リスク分析」「実施」「計画」のサイクルで⼯工程が進むl 1991年年：「反復復型（イテレーティブ）開発」「漸進型（インクリメンタル）開発」l ⼩小さな単位で開発することで、リスクを早期に識識別する。l 1992年年：「Vモデル」German   Ministry  of  Defensel ウォーターフォールモデルに品質保証の観点を追加。l 1998年年：「ユニファイド・プロセス（UP）」Jacobson,   Booch,  Rambaughl ユースケース・UMLに基づくオブジェクト指向開発プロセス。Rational社による商⽤用版が「RUP」l 1999年年：「エクストリーム・プログラミング（XP）」Kent   Beckl ドキュメントよりもコラボレーションに焦点を当てた軽量量開発プロセス。l 2002年年：「スクラム（Scrum）」Ken   Schwaber,  Mike  Beedlel 価値駆動の軽量量開発プロセス。原型は1986年年に⽵竹内弘⾼高⽒氏、野中郁次郎郎⽒氏が考案した製品開発⼿手法。l 2009年年：「SEMAT」Jacobson他l これまでの作業/成果物中⼼心のソフトウェアエンジニアリングモデルを活動/価値中⼼心に再構築。l 2011年年：「スケールド・アジャイル・フレームワーク（SAFe）」Dean   Leffingwelll アジャイルを単⼀一チームから企業規模にスケールするための⼿手法。l 2012年年：「ディシプリンド・アジャイル・デリバリー」Scott  W.Ambler,  Mike  Linesl アジャイルを企業活動に適合するよう拡張。l 2013年年：「PMBOK   5thEdition」PMIl アジャイル（適応型ライフサイクル）がプロジェクトライフサイクル型として追加。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要求 分析 設計 実装 テスト要求 分析 設計 実装 テスト要求 分析 設計 実装 テスト要求 分析 設計 実装 テスト要求 分析 設計 実装 テストプロジェクト開始リリース技術リスク・要求リスクへの対処要求 分析 設計 実装テスト要求 分析 設計 実装テスト要求 分析 設計 実装テスト要求 分析 設計 実装テスト要求 分析 設計 実装テストプロジェクト開始 リリース反復型フェーズ工程別フェーズ
14.©  2015  ZEN  ARCHITECTS  Co.,Ltd.アジャイルの期待効果２≪開発効率率率の向上≫不確実性 開発効率
15.©  2015  ZEN  ARCHITECTS  Co.,Ltd.ジャストインタイム（JIT）• 作業の管理理を、テスト結果によって⾏行行う• 中間成果物は「それが必要な場合に」作成する15要求 分析 実装 テスト要求 分析 実装 テスト要求 分析 テスト設計実装設計設計チェックポイント要求 分析 設計 実装 テストチェックポイントチェックポイントチェックポイントチェックポイントチェックポイントタスクそのものを「必要に応じて」実施チェックポイントチェックポイント成果物駆動ジャストインタイムデータ設計テストデータ作成
16.©  2015  ZEN  ARCHITECTS  Co.,Ltd.ジャストインタイムを⽀支える活動ジャストインタイムJust-In-Timeコードの共同所有リファクタリング安定したアーキテクチャペアプログラミング実は「保守開発」の現場で見る光景自己組織的チーム
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チーム・メンバー
21.©  2015  ZEN  ARCHITECTS  Co.,Ltd.スクラムの基本的な進め⽅方21
22.©  2015  ZEN  ARCHITECTS  Co.,Ltd.アジャイルの期待効果３≪エンタープライズへの拡張≫不確実性 開発効率エンタープライズ
23.©  2015  ZEN  ARCHITECTS  Co.,Ltd.「エンタープライズ」のコンテキスト• エンタープライズ開発 ≒  業務システム開発• 価値観の異異なる他の組織体と連携しながら進める開発• 連携が避けられない、とも⾔言う• 計画に基づく活動• 事業から⾒見見るとマイルストーンが重要。⼈人、モノ、カネを動かすタイミング。予算、期間、リソース制約も含む。• 戦略略に則った選択• 事業戦略略、技術戦略略、既存資産の利利⽤用（⼈人、設備、組織の経験）• 利利害関係者との調整• 複数のユーザー部⾨門、他のシステムの運⽤用・保守・開発チーム、システムオーナー部⾨門⻑⾧長、役員• コンプライアンスとガバナンス• 業界の法律律・規制、組織の規則・ルール・標準• 規模• 個別システム、関連システム、企業全体23アジャイルであっても避けられない
24.©  2015  ZEN  ARCHITECTS  Co.,Ltd.エンタープライズアジャイルエンタープライズのコンテキストで、アジャイル型を実践するための”拡張版“• ディシプリンド・アジャイル・デリバリー（DAD）《拡張点》• 新規開発：ビジョンの合意、⽅方向付けフェーズ、初期のバックログ構築• アーキテクチャ：アーキテクチャ、AO（アーキテクチャオーナー）、テクニカルストーリー• コストとスケジュール：リリース計画、レンジド・バーンダウン• ガバナンス：リスクリスト、リスク・価値駆動、マイルストーンレビュー• スケールド・アジャイル・フレームワーク（SAFe）《拡張点》• プログラムマネジメント：プログラムバックログ、プロダクトマネジメント• リリースの統制：リリース計画ミーティング、ART（アジャイルリリーストレイン）、リリースエンジニア、IPスプリント• アーキテクチャ：システムアーキテクト、アーキテクチャ滑滑⾛走路路、テクニカルストーリー• 企業全体：ビジネスエピック、エピックオーナー、予算と投資判断、プログラムポートフォリオマネジメント、エンタープライズアーキテクト• Scrum  of  Scrums• Enterprise  Scrum24
25.©  2015  ZEN  ARCHITECTS  Co.,Ltd.ディシプリンド・アジャイル・デリバリー（DAD）25引⽤用：ディシプリンド・アジャイル・デリバリー(2013/翔泳社)Disciplined Agile Delivery
26.©  2015  ZEN  ARCHITECTS  Co.,Ltd.スケールド・アジャイル・フレームワーク（SAFe）26
27.©  2015  ZEN  ARCHITECTS  Co.,Ltd.「エンタープライズ」の守備範囲• 「エンタープライズ」で必要となる2つの軸• プロジェクト環境の複雑さ• 規模（開発者数）プロジェクト環境の複雑さ規模（開発者数）SAFeDAD新規性ガバナンス外部協調10⼈人50⼈人1000⼈人スクラム戦略略適合DADもSAFeも、中⼼心はスクラム
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適応型AdaptiveLifecycle価値駆動バックログ管理コードの共同所有リファクタリング自動回帰テストLivingDocument安定したアーキテクチャ継続的統合/デリバリーアーキテクチャスパイクペアプログラミング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  Delivery32http://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協働サンプルコードデザイン実装方式の調整デザイン案HTMLWeb企画部デザイン案コミットアーキテクチャ担当DevUI担当Devコミット自動テスト作成 参照把握2W 2W 2W 2W・バックログ作成、優先順位設定・マイルストーン設定・協働時の検討・判断・タスク設定、アサイン・実装方式の検討と定義・作業量見積もり・実装方式の習熟・成果物作成・テストの定義と実施・テクニカルバックログ・PoC・サンプル作成
35.©  2015  ZEN  ARCHITECTS  Co.,Ltd.アジャイルは不不確実性に⽴立立ち向かうための「道具」である1. 未来が想定できるかどうか。不不確実性を認識識する• 想定できるなら「予測型」で計画駆動が前提。できない計画は⽴立立てない、そこに不不確実性がある2. “事業者”と“システム提供者”の不不確実性は、特性が異異なる• システム開発のリスクは「要求」「技術」「スキル」3. アジャイルは、不不確実性と開発効率率率に対するソリューション• 各施策やプラクティスは、ソフトウェアエンジニアリングの歴史の延⻑⾧長線上にある4. エンタープライズアジャイルは、単にアジャイルの適⽤用範囲を広げたもの• そのぶん、シンプルさは損なわれている5. ”アジャイル適⽤用時の不不確実性”に⽴立立ち向かうためのソリューション• システム提供者が直⾯面する「新規性」「⾒見見積り」「規模拡⼤大」をまとめて「エンタープライズ」6. アジャイルは、思ったよりもうまく設計されている• 単⼀一のプラクティス適⽤用よりも、まとめて適⽤用した⽅方がうまくいく7. アジャイルは、組織が⼿手にすることのできる新たな「道具」に過ぎない• 適切切な局⾯面で、適切切に組み合わせて利利⽤用できれば良良い。道具として使えるようになっておく35
36.©  2015  ZEN  ARCHITECTS  Co.,Ltd.36zenarchitects.co.jpfacebook.com/zenarchitects