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

Hiromasa Oka
Hiromasa OkaSoftware Architect at ZOZO Technologies Inc.
企業システムにアジャイルは必要か
2015/6/22
株式会社ゼンアーキテクツ
岡 大勝
"Agile" is reallyneed to enterprise system?
⾃自⼰己紹介
• 第⼀一勧銀情報システム(現:みずほ情報総研)
• 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/チーフアーキテクト
プロフィール
©	
  2015	
  ZEN	
  ARCHITECTS	
  Co.,Ltd.
そもそも「アジャイル」は必要なのか?
• ウォーターフォールで何が悪い?
• いや、悪くない
• QCDを最初に厳密に規定し計画するのがウォーターフォール。
• 計画通りにプロジェクトが完了了するのであれば、むしろ望ましい
• なぜ、別の⼿手法が必要なのか
• プロジェクトが「最初に規定し計画した通り」に進まない。
• なぜ、計画通りに進まないのか
• システム開発には、不不確実性の⾼高い要素が多い= “リスク”
• 「要求リスク」「スキルリスク」「技術リスク」「政治リスク」
3
できるだけ早い時点でリスクをキャッチアップしながら
プロジェクトを進める手法が必要
©	
  2015	
  ZEN	
  ARCHITECTS	
  Co.,Ltd.
アジャイルの期待効果1
≪不不確実性への取り組み≫
不確実性 開発効率
©	
  2015	
  ZEN	
  ARCHITECTS	
  Co.,Ltd.
”不不確実性”のレベル
• ほとんどの事象は想定可能な⼀一定の幅に収まる
• ビジネスでは、Lv.1=50%、Lv.2+Lv.3=50%、Lv.4=まれに出現
Lv.1
確実な未来
Lv.2
選択的未来
Lv.3
一定の幅
Lv.4
予測不能
適応する未来を形成する 留保する
スピード、アジリティ、柔軟性リーダーシップ、標準 早期のコミットを避ける
戦略
「不不確実時代の⾏行行動と戦略略」ヒュー・コートニー、他
ハーバードビジネスレビューブックス:不不確実性の経営戦略略(ダイヤモンド社)より
©	
  2015	
  ZEN	
  ARCHITECTS	
  Co.,Ltd.
計画できることは、計画して実施する
• 「正しい」ことが分かっている
• よほど⼤大きな問題が発⽣生しない限り“うまくいく”
• 事業者は「必要な時期」に「必要なもの」が⼿手に⼊入れば良良い。
• 定型反復復業務
• 確⽴立立された⼿手順
予測型
(計画駆動)
Lv.1
確実な未来
Lv.2
選択的未来
PMBOK 5th
©	
  2015	
  ZEN	
  ARCHITECTS	
  Co.,Ltd.
計画できないことは、確認しながら進む
• 何が「正しい」のか判断できない
• 正しいものが変化する
• 機能
• 技術
• ビジネス、マーケット
• 変化への継続的な対応
• 「要求の変化」と「優先順位の変化」
• 要求の変化=反復復型による継続的フィードバック
• 優先順位の変化=バックログによる動的要求管理理
反復型
Lv.3
一定の幅 適応型
(変化駆動/アジャイル)
PMBOK 5th
©	
  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)
©	
  2015	
  ZEN	
  ARCHITECTS	
  Co.,Ltd.
”事業者”と”システム提供者”で「不不確実性」は異異なる
9
事業者 システム提供者
低 (Lv1,2)
適応 適応
高 (Lv3)
形成
反復型
適応型
低 (Lv1,2)
高 (Lv3)
市場・競合・法制 要求・技術・スキル
予測型
予測型
適応 適応
反復型
適応型
【IT業界構造】
・要求は変わる
・技術も変わる
・⼈人は外部調達
【リスク回避戦略略】
・仕様FIX
・慣れた(古い)技術
・実績あるメンバー
【リスク許容戦略略】
・要求変動を許容
・新技術を適⽤用
・過去実績の横展開
・パッケージ適用
システム開発リスクの転嫁
定められた期⽇日に、仕
様通りに利利⽤用開始でき
ればいい。
外部に委託するにはリスク・コス
トが⾼高すぎる場合、内製を検討。
・要求変動リスクを⾃自ら取る
・「技術」「⼈人」を固定
不
確
実
性
戦
略
降りる
仕様・期間/コスト・品質
アジャイル(Scrum)
不不確実性の⾼高い受託型を成功させるには、
反復復型・適応型の戦略略が前提。
・納期に何が必須か「価値・リスク駆動」
・幅を持った”約束”「スコープ、コスト」
エンタープライズ・アジャイル
「他組織からは予測型」
単一チームから
組織的活動に拡大する際、
社内でも同じ問題に直面。 他、反復型プロセス軽量反復型プロセス
【激しい競合】
迅速な対応が求
められる。
©	
  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
©	
  2015	
  ZEN	
  ARCHITECTS	
  Co.,Ltd.
アジャイルは何が違う?
• 進め⽅方が違う(だけ)
• 個々の作業は同じ
• プロセスフレームワークの組み合わせが違う
• “計画通りには進まない“ことに対処する。
• 動くシステムを使って(作って)みなければ、正しいかどうか分からない
• ⼿手直し(軌道修正)しながら進むために、作業⼯工程を⾝身軽にする
• ⼯工程別フェーズ → 反復復型フェーズ
• 成果物駆動 → ジャストインタイム
• 予測型(計画駆動) → 適応型(価値駆動・リスク駆動)
11
ウォーターフォール ”型” アジャイル ”型”
©	
  2015	
  ZEN	
  ARCHITECTS	
  Co.,Ltd.
プロセスフレームワークの組み合わせ
• 開発プロセスの違いは、
プロセスフレームワークの組み合わせの違い
• ⼯工程別フェーズ x  成果物駆動 x  予測型(計画駆動)
• ウォーターフォールモデル
• V字モデル
• 反復復フェーズ x  ジャストインタイム x  適応型(価値駆動)
• スクラム
• XP
• 反復復フェーズ(ゴール指向) x  成果物駆動 x  適応型(リスク駆動)
• ユニファイド・プロセス(UP)
• 反復復フェーズ(ゴール指向) x  ジャストインタイム x  適応型(価値・リスク駆動)
• ディシプリンド・アジャイル・デリバリー(DAD)
12
©	
  2015	
  ZEN	
  ARCHITECTS	
  Co.,Ltd.
「反復復型」フェーズ
• 要求の実装完了了が、フェーズの完了了基準
• 特徴
• 動作する機能が早期に利利⽤用できる
• 統合とテストの負担が⼤大きい
13
要求 分析 設計 実装 テスト
要求 分析 設計 実装 テスト
要求 分析 設計 実装 テスト
要求 分析 設計 実装 テスト
要求 分析 設計 実装 テスト
プロジェクト開始
リリース
技術リスク・要求リスクへの
対処
要求 分析 設計 実装
テス
ト
要求 分析 設計 実装
テス
ト
要求 分析 設計 実装
テス
ト
要求 分析 設計 実装
テス
ト
要求 分析 設計 実装
テス
ト
プロジェクト開始 リリース
反復型フェーズ工程別フェーズ
©	
  2015	
  ZEN	
  ARCHITECTS	
  Co.,Ltd.
アジャイルの期待効果2
≪開発効率率率の向上≫
不確実性 開発効率
©	
  2015	
  ZEN	
  ARCHITECTS	
  Co.,Ltd.
ジャストインタイム(JIT)
• 作業の管理理を、テスト結果によって⾏行行う
• 中間成果物は「それが必要な場合に」作成する
15
要求 分析 実装 テスト
要求 分析 実装 テスト
要求 分析 テスト
設計
実装設計
設計
チェック
ポイント
要求 分析 設計 実装 テスト
チェック
ポイント
チェック
ポイント
チェック
ポイント
チェック
ポイント
チェック
ポイント
タスクそのものを「必要に応じて」実施
チェック
ポイント
チェック
ポイント
成果物駆動
ジャストインタイム
データ
設計
テストデータ
作成
©	
  2015	
  ZEN	
  ARCHITECTS	
  Co.,Ltd.
ジャストインタイムを⽀支える活動
ジャストイン
タイム
Just-In-Time
コードの
共同所有
リファクタリング
安定した
アーキテクチャ
ペアプログラミング
実は「保守開発」の現場で見る光景
自己組織的チーム
©	
  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そのまま)
実装
コンパクトで要点に絞った
「⽣生きた」ドキュメント
©	
  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
個々の要件の概算見積もりの合計がベロシティに収まるよう、タイムボックスに割り当てる
©	
  2015	
  ZEN	
  ARCHITECTS	
  Co.,Ltd.
アジャイル”型”で何が得られる?
得られるもの
1. 不不必要な作業の削減
• JITの効果
• =⽣生産性向上=コスト最⼩小化(最適化)
2. リスクの減少
• 反復復型の効果
• リスクの早期識識別と早期(⼩小さいうちに)対処
• =再作業の削減 & 我慢(=ビジネス価値低下)の最⼩小化
• 再作業の原因(リスク)のほとんどは「要求」
• 「ほしいものはこれじゃない」
• 動くものを触ってもらう
• ITは、社会活動全体から⾒見見るとそこまで成熟していない
(モノを⾒見見るまで安⼼心できない)
19
©	
  2015	
  ZEN	
  ARCHITECTS	
  Co.,Ltd.
スクラム(Scrum)の特徴
20
§ プラクティス:
4プロダクト・バックログ
4価値駆動ライフサイクル
4⾃自⼰己組織化
4リリース・プランニング
4スプリント・プランニング
4⽇日次スクラムミーティング
4スプリント・デモ
4ふりかえり
§ ロール:
4スクラム・マスター
4プロダクト・オーナー
4チーム・メンバー
©	
  2015	
  ZEN	
  ARCHITECTS	
  Co.,Ltd.
スクラムの基本的な進め⽅方
21
©	
  2015	
  ZEN	
  ARCHITECTS	
  Co.,Ltd.
アジャイルの期待効果3
≪エンタープライズへの拡張≫
不確実性 開発効率
エンタープライズ
©	
  2015	
  ZEN	
  ARCHITECTS	
  Co.,Ltd.
「エンタープライズ」のコンテキスト
• エンタープライズ開発 ≒  業務システム開発
• 価値観の異異なる他の組織体と連携しながら進める開発
• 連携が避けられない、とも⾔言う
• 計画に基づく活動
• 事業から⾒見見るとマイルストーンが重要。⼈人、モノ、カネを動かすタイ
ミング。予算、期間、リソース制約も含む。
• 戦略略に則った選択
• 事業戦略略、技術戦略略、既存資産の利利⽤用(⼈人、設備、組織の経験)
• 利利害関係者との調整
• 複数のユーザー部⾨門、他のシステムの運⽤用・保守・開発チーム、シス
テムオーナー部⾨門⻑⾧長、役員
• コンプライアンスとガバナンス
• 業界の法律律・規制、組織の規則・ルール・標準
• 規模
• 個別システム、関連システム、企業全体
23
アジャイルであっても
避けられない
©	
  2015	
  ZEN	
  ARCHITECTS	
  Co.,Ltd.
エンタープライズアジャイル
エンタープライズのコンテキストで、アジャイル型を実践するための”拡張版“
• ディシプリンド・アジャイル・デリバリー(DAD)
《拡張点》
• 新規開発:ビジョンの合意、⽅方向付けフェーズ、初期のバックログ構築
• アーキテクチャ:アーキテクチャ、AO(アーキテクチャオーナー)、テクニカルストーリー
• コストとスケジュール:リリース計画、レンジド・バーンダウン
• ガバナンス:リスクリスト、リスク・価値駆動、マイルストーンレビュー
• スケールド・アジャイル・フレームワーク(SAFe)
《拡張点》
• プログラムマネジメント:プログラムバックログ、プロダクトマネジメント
• リリースの統制:リリース計画ミーティング、ART(アジャイルリリーストレイン)、リリースエンジニア、
IPスプリント
• アーキテクチャ:システムアーキテクト、アーキテクチャ滑滑⾛走路路、テクニカルストーリー
• 企業全体:ビジネスエピック、エピックオーナー、予算と投資判断、プログラムポートフォリオマネジメント、
エンタープライズアーキテクト
• Scrum  of  Scrums
• Enterprise  Scrum
24
©	
  2015	
  ZEN	
  ARCHITECTS	
  Co.,Ltd.
ディシプリンド・アジャイル・デリバリー(DAD)
25
引⽤用:ディシプリンド・アジャイル・デリバリー(2013/翔泳社)
Disciplined Agile Delivery
©	
  2015	
  ZEN	
  ARCHITECTS	
  Co.,Ltd.
スケールド・アジャイル・フレームワーク(SAFe)
26
©	
  2015	
  ZEN	
  ARCHITECTS	
  Co.,Ltd.
「エンタープライズ」の守備範囲
• 「エンタープライズ」で必要となる2つの軸
• プロジェクト環境の複雑さ
• 規模(開発者数)
プロジェクト環境の複雑さ
規模
(開発者数)
SAFe
DAD
新規性ガバナンス外部協調
10⼈人
50⼈人
1000⼈人
スクラム
戦略略適合
DADもSAFeも、
中⼼心はスクラム
©	
  2015	
  ZEN	
  ARCHITECTS	
  Co.,Ltd.
企業へのアジャイル導⼊入に必要な3つの要因
• 動機が適切切であれば、アジャイル型の導⼊入を検討する価値はある。
アジャイル型の導⼊入の成否に⼤大きく影響する3つの要因がある。
• 「⼈人を礎とする」
• 「⼈人は容易易に調達可能なリソース”ではない“」ことが前提。
• ⾃自ら考え⾏行行動できる⼈人(⾃自律律的に⾏行行動できる⼈人)だけで編成できるか。経験可否は問わない。
• PO、AO、TL + デベロッパ 3〜~5名。⾃自⼰己組織的チームが⽬目標。デベロッパは100%専任。
• 「環境とアーキテクチャを先⾏行行させる」
• バックログ、カンバンボード、ドキュメント共有、ソース管理理の「プロジェクト推進環境」とともに、
「アーキテクチャ」を先に⾛走らせる。(PO、AO、TLで先⾏行行)
• デベロッパー参画時には、プロジェクト推進環境とともに技術的基盤や実装⽅方式が「ある程度度」整ってい
る必要がある。
• 政治的調整が必要な場合は、準備するためのインセプション(⽅方向付け)を実施。
• クラウドや軽量量フレームワークなど、Just-‐‑‒In-‐‑‒Timeで調達可能かつ低負荷で利利⽤用可能な技術スタックが望
ましい。
• 「オーナーとチームの固い信頼関係」
• チームはベストを尽くし、オーナーはそれを信じる。オーナーとチームとの相互信頼関係が基盤。
• 当初は⾒見見積誤差が⼤大きい。パフォーマンスの測定と⾒見見積基礎値の蓄積、適切切なイテレーション計画に向け
て継続的改善。インセプションで基礎値を⾒見見出しておく。
• 安定したアーキテクチャの元でのコードの共同所有は、パフォーマンス底上げに効果⼤大。
©	
  2015	
  ZEN	
  ARCHITECTS	
  Co.,Ltd.
反復
Iterative
ジャストイン
タイム
Just-In-Time
適応型
Adaptive
Lifecycle
価値駆動
バックログ管理
コードの
共同所有
リファクタリング
自動回帰テスト
Living
Document
安定した
アーキテクチャ
継続的統合/
デリバリー
アーキテクチャ
スパイク
ペアプログラミング
BDD
カンバン
イテレーショ
ン計画
マルチファンクショナル
エンジニア(多能工)
リスク駆動
タイムボックス
ベロシティ
ふりかえり
Pull Request
インセプション
日次ミーティング
100%専任バーンダウン
チャート
自己組織的
チーム
リスクリスト
アジャイルは、意外にうまく設計されている
ビジョンドキュメント
イテレーション
デモ
※ゼンアーキテクツがお客さまの現場で実践している主要なプラクティスを表したものです
©	
  2015	
  ZEN	
  ARCHITECTS	
  Co.,Ltd.
To-­‐Be
業務フロー
ユーザからの
要望/要求
ビジョン
技術
実装方
式
初期のアーキ
テクチャ
アーキテクチャ
ドキュメント
初期のバックログビルディング
(IBB	
  :	
  Initial	
  Backlog	
  Building)
主要なストーリーを実装
(US、TS)
実現したい業務を
ストーリーとして切り出して登録
受け入れられた
実装済ストーリーを、To-­‐Beにフィードバック
SP
実装実績から
見積基礎値を設定
方式、パターン
サンプルコード
2W
優先順位の高いストーリーを
タイムボックスで計画化
チームで
実装
実装された
機能
修正・追加要望をバックログに追加
イテレーションデモ
レビュー
ユーザ(業務カテゴリをエピックで
分類すると識別しやすい)
ソース
管理
ビルド・デプロイ・テスト
プロダクトバックログ
見積基礎値の
フィードバック
ドキュメントの追記・更新
Living Document
イテレーション計画
企業システムとアジャイルの親和性
自動回帰テスト
受入テスト
リリース判定
Ops
リリース
本番運用
インシデント管理
修正依頼
ユーザ
運用担当者
©	
  2015	
  ZEN	
  ARCHITECTS	
  Co.,Ltd.
アジャイルは、予測型と「組み合わせて」使う
•フロント系システム + バック系システム
• 組織のシステム単位で組み合わせる
•フロントエンド(SPA) + バックエンド(MSA)
• 単一システムのレイヤー単位で組み合わせる
•インセプション(設計) + プロダクション(製品化)
• 単一システムの工程で組み合わせる
「全てをアジャイルで」という発想は捨てる。
31
©	
  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
©	
  2015	
  ZEN	
  ARCHITECTS	
  Co.,Ltd.
PO
(Product	
  Owner)
システム部 Web企画部
デザイナー
AO
(Architecture	
  Owner)
アーキテクチャ
担当デベロッパー
UI担当デベロッパー
プロダクト
バックログ
ドキュメント
スプリント/タスク
(計画・実績)
ソース
リポジトリ
お客様
テスト
環境
TL
(Team	
  Leader)
<Scrum	
  Master> プロジェクト
リリース
体制
©	
  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・サンプル作成
©	
  2015	
  ZEN	
  ARCHITECTS	
  Co.,Ltd.
アジャイルは不不確実性に⽴立立ち向かうための
「道具」である
1. 未来が想定できるかどうか。不不確実性を認識識する
• 想定できるなら「予測型」で計画駆動が前提。できない計画は⽴立立てない、そこに不不確実性がある
2. “事業者”と“システム提供者”の不不確実性は、特性が異異なる
• システム開発のリスクは「要求」「技術」「スキル」
3. アジャイルは、不不確実性と開発効率率率に対するソリューション
• 各施策やプラクティスは、ソフトウェアエンジニアリングの歴史の延⻑⾧長線上にある
4. エンタープライズアジャイルは、単にアジャイルの適⽤用範囲を広げたもの
• そのぶん、シンプルさは損なわれている
5. ”アジャイル適⽤用時の不不確実性”に⽴立立ち向かうためのソリューション
• システム提供者が直⾯面する「新規性」「⾒見見積り」「規模拡⼤大」をまとめて「エンタープライズ」
6. アジャイルは、思ったよりもうまく設計されている
• 単⼀一のプラクティス適⽤用よりも、まとめて適⽤用した⽅方がうまくいく
7. アジャイルは、組織が⼿手にすることのできる新たな「道具」に過ぎない
• 適切切な局⾯面で、適切切に組み合わせて利利⽤用できれば良良い。道具として使えるようになっておく
35
©	
  2015	
  ZEN	
  ARCHITECTS	
  Co.,Ltd.
36
zenarchitects.co.jp
facebook.com/zenarchitects
1 of 36

Recommended

アジャイル開発を支えるアーキテクチャ設計とは by
アジャイル開発を支えるアーキテクチャ設計とはアジャイル開発を支えるアーキテクチャ設計とは
アジャイル開発を支えるアーキテクチャ設計とはYusuke Suzuki
26.9K views56 slides
商流物流金流.pdf by
商流物流金流.pdf商流物流金流.pdf
商流物流金流.pdfZenji Kanzaki
783 views21 slides
大企業アジャイルの勘所 #devlovex #devlovexd by
大企業アジャイルの勘所 #devlovex #devlovexd大企業アジャイルの勘所 #devlovex #devlovexd
大企業アジャイルの勘所 #devlovex #devlovexdItsuki Kuroda
46.8K views109 slides
ウォーターフォールとアジャイルを考える #ita_ws by
ウォーターフォールとアジャイルを考える #ita_wsウォーターフォールとアジャイルを考える #ita_ws
ウォーターフォールとアジャイルを考える #ita_wsYusuke Suzuki
16.7K views47 slides
DeNAの品質を支えるQAの取り組み 〜標準化から実践まで〜 by
DeNAの品質を支えるQAの取り組み 〜標準化から実践まで〜DeNAの品質を支えるQAの取り組み 〜標準化から実践まで〜
DeNAの品質を支えるQAの取り組み 〜標準化から実践まで〜Tetsuya Kouno
7.2K views63 slides
エンジニアの個人ブランディングと技術組織 by
エンジニアの個人ブランディングと技術組織エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織Takafumi ONAKA
23.4K views40 slides

More Related Content

What's hot

開発速度が速い #とは(LayerX社内資料) by
開発速度が速い #とは(LayerX社内資料)開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)mosa siru
61.6K views18 slides
アジャイル開発のストーリーをGherkin記法で作成 by
アジャイル開発のストーリーをGherkin記法で作成アジャイル開発のストーリーをGherkin記法で作成
アジャイル開発のストーリーをGherkin記法で作成Shinya Nakajima
3.7K views9 slides
カネとAgile(大企業新規事業編) #rsgt2021 by
カネとAgile(大企業新規事業編) #rsgt2021カネとAgile(大企業新規事業編) #rsgt2021
カネとAgile(大企業新規事業編) #rsgt2021Itsuki Kuroda
11.9K views49 slides
リーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkan by
リーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkanリーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkan
リーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkanItsuki Kuroda
28.6K views104 slides
5分で分かるアジャイルムーブメントの歴史 拡大版 by
5分で分かるアジャイルムーブメントの歴史 拡大版5分で分かるアジャイルムーブメントの歴史 拡大版
5分で分かるアジャイルムーブメントの歴史 拡大版Fumihiko Kinoshita
29.3K views111 slides
PHPerだってMicroservicesしたい! by
PHPerだってMicroservicesしたい!PHPerだってMicroservicesしたい!
PHPerだってMicroservicesしたい!Shinichi Takahashi
12.7K views63 slides

What's hot(20)

開発速度が速い #とは(LayerX社内資料) by mosa siru
開発速度が速い #とは(LayerX社内資料)開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)
mosa siru61.6K views
アジャイル開発のストーリーをGherkin記法で作成 by Shinya Nakajima
アジャイル開発のストーリーをGherkin記法で作成アジャイル開発のストーリーをGherkin記法で作成
アジャイル開発のストーリーをGherkin記法で作成
Shinya Nakajima3.7K views
カネとAgile(大企業新規事業編) #rsgt2021 by Itsuki Kuroda
カネとAgile(大企業新規事業編) #rsgt2021カネとAgile(大企業新規事業編) #rsgt2021
カネとAgile(大企業新規事業編) #rsgt2021
Itsuki Kuroda11.9K views
リーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkan by Itsuki Kuroda
リーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkanリーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkan
リーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkan
Itsuki Kuroda28.6K views
5分で分かるアジャイルムーブメントの歴史 拡大版 by Fumihiko Kinoshita
5分で分かるアジャイルムーブメントの歴史 拡大版5分で分かるアジャイルムーブメントの歴史 拡大版
5分で分かるアジャイルムーブメントの歴史 拡大版
Fumihiko Kinoshita29.3K views
PHPerだってMicroservicesしたい! by Shinichi Takahashi
PHPerだってMicroservicesしたい!PHPerだってMicroservicesしたい!
PHPerだってMicroservicesしたい!
Shinichi Takahashi12.7K views
経営のアジリティを支えるDevOpsと組織 by Recruit Technologies
経営のアジリティを支えるDevOpsと組織経営のアジリティを支えるDevOpsと組織
経営のアジリティを支えるDevOpsと組織
ユーザーストーリーマッピングを使ってプロダクトバックログを作ろう by izumi ito
ユーザーストーリーマッピングを使ってプロダクトバックログを作ろうユーザーストーリーマッピングを使ってプロダクトバックログを作ろう
ユーザーストーリーマッピングを使ってプロダクトバックログを作ろう
izumi ito695 views
事業が対峙する現実からエンジニアリングを俯瞰する #devlove by Itsuki Kuroda
事業が対峙する現実からエンジニアリングを俯瞰する #devlove事業が対峙する現実からエンジニアリングを俯瞰する #devlove
事業が対峙する現実からエンジニアリングを俯瞰する #devlove
Itsuki Kuroda24.1K views
アジャイル開発におけるクラフトマンシップの重要性.pdf by Shigeru Tatsuta
アジャイル開発におけるクラフトマンシップの重要性.pdfアジャイル開発におけるクラフトマンシップの重要性.pdf
アジャイル開発におけるクラフトマンシップの重要性.pdf
Shigeru Tatsuta477 views
アジャイルコーチが現場で学んだプロダクトオーナーの実際と勘所 POの二番目に大事なことと by Yasui Tsutomu
アジャイルコーチが現場で学んだプロダクトオーナーの実際と勘所 POの二番目に大事なこととアジャイルコーチが現場で学んだプロダクトオーナーの実際と勘所 POの二番目に大事なことと
アジャイルコーチが現場で学んだプロダクトオーナーの実際と勘所 POの二番目に大事なことと
Yasui Tsutomu15K views
CloudNativeな決済サービスの開発と2年間の歩み #sf_A4 by Junya Suzuki
CloudNativeな決済サービスの開発と2年間の歩み #sf_A4CloudNativeな決済サービスの開発と2年間の歩み #sf_A4
CloudNativeな決済サービスの開発と2年間の歩み #sf_A4
Junya Suzuki4.4K views
Agile Quality アジャイル品質パターン (QA2AQ) by Hironori Washizaki
Agile Quality アジャイル品質パターン (QA2AQ)Agile Quality アジャイル品質パターン (QA2AQ)
Agile Quality アジャイル品質パターン (QA2AQ)
Hironori Washizaki6.5K views
あじゃいる時代の品質保証 ~DevSQAの提案~ by Hiroaki Matsunaga
あじゃいる時代の品質保証 ~DevSQAの提案~あじゃいる時代の品質保証 ~DevSQAの提案~
あじゃいる時代の品質保証 ~DevSQAの提案~
Hiroaki Matsunaga10.5K views
マイクロサービスにおけるテスト自動化 with Karate by Takanori Suzuki
マイクロサービスにおけるテスト自動化 with Karateマイクロサービスにおけるテスト自動化 with Karate
マイクロサービスにおけるテスト自動化 with Karate
Takanori Suzuki9.6K views
ユーザーインタビューするときは、どうやらゾンビのおでましさ by Yoshiki Hayama
ユーザーインタビューするときは、どうやらゾンビのおでましさユーザーインタビューするときは、どうやらゾンビのおでましさ
ユーザーインタビューするときは、どうやらゾンビのおでましさ
Yoshiki Hayama8.6K views
40歳過ぎてもエンジニアでいるためにやっていること by onozaty
40歳過ぎてもエンジニアでいるためにやっていること40歳過ぎてもエンジニアでいるためにやっていること
40歳過ぎてもエンジニアでいるためにやっていること
onozaty32.3K views
チケット駆動開発の解説~タスク管理からプロセス改善へ by akipii Oga
チケット駆動開発の解説~タスク管理からプロセス改善へチケット駆動開発の解説~タスク管理からプロセス改善へ
チケット駆動開発の解説~タスク管理からプロセス改善へ
akipii Oga4.4K views

Viewers also liked

Are you ready? ~これからアジャイル開発をスタートアップするために プラクティスの実践と実感~ by
Are you ready? ~これからアジャイル開発をスタートアップするために プラクティスの実践と実感~Are you ready? ~これからアジャイル開発をスタートアップするために プラクティスの実践と実感~
Are you ready? ~これからアジャイル開発をスタートアップするために プラクティスの実践と実感~Akira Ikeda
11.4K views70 slides
「アジャイル入門」(AgileJapan2013チュートリアルセッション資料) by
「アジャイル入門」(AgileJapan2013チュートリアルセッション資料)「アジャイル入門」(AgileJapan2013チュートリアルセッション資料)
「アジャイル入門」(AgileJapan2013チュートリアルセッション資料)Makoto Nishikawa
14.3K views42 slides
リクルート住まいカンパニーの新規事業でのスクラム導入奮闘記 by
リクルート住まいカンパニーの新規事業でのスクラム導入奮闘記リクルート住まいカンパニーの新規事業でのスクラム導入奮闘記
リクルート住まいカンパニーの新規事業でのスクラム導入奮闘記Tatsuya Yokoyama
12.1K views17 slides
スクラム開発について by
スクラム開発についてスクラム開発について
スクラム開発についてAkio Terayama
15.9K views31 slides
Yahoo! JAPAN の アジャイル開発の普及戦略 by
Yahoo! JAPAN の アジャイル開発の普及戦略Yahoo! JAPAN の アジャイル開発の普及戦略
Yahoo! JAPAN の アジャイル開発の普及戦略Yahoo!デベロッパーネットワーク
13.5K views54 slides
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove by
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove 社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove Itsuki Kuroda
63.2K views106 slides

Viewers also liked(8)

Are you ready? ~これからアジャイル開発をスタートアップするために プラクティスの実践と実感~ by Akira Ikeda
Are you ready? ~これからアジャイル開発をスタートアップするために プラクティスの実践と実感~Are you ready? ~これからアジャイル開発をスタートアップするために プラクティスの実践と実感~
Are you ready? ~これからアジャイル開発をスタートアップするために プラクティスの実践と実感~
Akira Ikeda11.4K views
「アジャイル入門」(AgileJapan2013チュートリアルセッション資料) by Makoto Nishikawa
「アジャイル入門」(AgileJapan2013チュートリアルセッション資料)「アジャイル入門」(AgileJapan2013チュートリアルセッション資料)
「アジャイル入門」(AgileJapan2013チュートリアルセッション資料)
Makoto Nishikawa14.3K views
リクルート住まいカンパニーの新規事業でのスクラム導入奮闘記 by Tatsuya Yokoyama
リクルート住まいカンパニーの新規事業でのスクラム導入奮闘記リクルート住まいカンパニーの新規事業でのスクラム導入奮闘記
リクルート住まいカンパニーの新規事業でのスクラム導入奮闘記
Tatsuya Yokoyama12.1K views
スクラム開発について by Akio Terayama
スクラム開発についてスクラム開発について
スクラム開発について
Akio Terayama15.9K views
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove by Itsuki Kuroda
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove 社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove
Itsuki Kuroda63.2K views
飛び道具ではないMetal #iOSDC by Shuichi Tsutsumi
飛び道具ではないMetal #iOSDC飛び道具ではないMetal #iOSDC
飛び道具ではないMetal #iOSDC
Shuichi Tsutsumi8.5K views
小さく始める大規模スクラム by Keisuke Tsukagoshi
小さく始める大規模スクラム小さく始める大規模スクラム
小さく始める大規模スクラム
Keisuke Tsukagoshi35.1K views

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

ソフトウェア工学2023 04 開発プロセスモデル by
ソフトウェア工学2023 04 開発プロセスモデルソフトウェア工学2023 04 開発プロセスモデル
ソフトウェア工学2023 04 開発プロセスモデルToru Tamaki
46 views54 slides
2014-10-27 #ssmjp 腹を割って話そう (運用xセキュリティ) by
2014-10-27 #ssmjp 腹を割って話そう (運用xセキュリティ)2014-10-27 #ssmjp 腹を割って話そう (運用xセキュリティ)
2014-10-27 #ssmjp 腹を割って話そう (運用xセキュリティ)Operation Lab, LLC.
5K views51 slides
OpenShift Ansbile 活用法 アプリケーションライフサイクルからみる導入効果 by
OpenShift Ansbile 活用法 アプリケーションライフサイクルからみる導入効果OpenShift Ansbile 活用法 アプリケーションライフサイクルからみる導入効果
OpenShift Ansbile 活用法 アプリケーションライフサイクルからみる導入効果Hideaki Tokida
1.6K views59 slides
Devlove2012 どうしたら良いシステムが作れるのか by
Devlove2012 どうしたら良いシステムが作れるのかDevlove2012 どうしたら良いシステムが作れるのか
Devlove2012 どうしたら良いシステムが作れるのかYusuke Suzuki
7.3K views43 slides
アジャイルにモデリングは必要か by
アジャイルにモデリングは必要かアジャイルにモデリングは必要か
アジャイルにモデリングは必要かHiromasa Oka
11.6K views58 slides
なぜソフトウェアアーキテクトが必要なのか - デブサミ2011 by
なぜソフトウェアアーキテクトが必要なのか - デブサミ2011なぜソフトウェアアーキテクトが必要なのか - デブサミ2011
なぜソフトウェアアーキテクトが必要なのか - デブサミ2011Yusuke Suzuki
6.1K views45 slides

Similar to 企業システムにアジャイルは必要か(20)

ソフトウェア工学2023 04 開発プロセスモデル by Toru Tamaki
ソフトウェア工学2023 04 開発プロセスモデルソフトウェア工学2023 04 開発プロセスモデル
ソフトウェア工学2023 04 開発プロセスモデル
Toru Tamaki46 views
2014-10-27 #ssmjp 腹を割って話そう (運用xセキュリティ) by Operation Lab, LLC.
2014-10-27 #ssmjp 腹を割って話そう (運用xセキュリティ)2014-10-27 #ssmjp 腹を割って話そう (運用xセキュリティ)
2014-10-27 #ssmjp 腹を割って話そう (運用xセキュリティ)
OpenShift Ansbile 活用法 アプリケーションライフサイクルからみる導入効果 by Hideaki Tokida
OpenShift Ansbile 活用法 アプリケーションライフサイクルからみる導入効果OpenShift Ansbile 活用法 アプリケーションライフサイクルからみる導入効果
OpenShift Ansbile 活用法 アプリケーションライフサイクルからみる導入効果
Hideaki Tokida1.6K views
Devlove2012 どうしたら良いシステムが作れるのか by Yusuke Suzuki
Devlove2012 どうしたら良いシステムが作れるのかDevlove2012 どうしたら良いシステムが作れるのか
Devlove2012 どうしたら良いシステムが作れるのか
Yusuke Suzuki7.3K views
アジャイルにモデリングは必要か by Hiromasa Oka
アジャイルにモデリングは必要かアジャイルにモデリングは必要か
アジャイルにモデリングは必要か
Hiromasa Oka11.6K views
なぜソフトウェアアーキテクトが必要なのか - デブサミ2011 by Yusuke Suzuki
なぜソフトウェアアーキテクトが必要なのか - デブサミ2011なぜソフトウェアアーキテクトが必要なのか - デブサミ2011
なぜソフトウェアアーキテクトが必要なのか - デブサミ2011
Yusuke Suzuki6.1K views
OSC2018 hiroshima session slide by OSSC by Daisuke Nishino
OSC2018 hiroshima session slide by OSSCOSC2018 hiroshima session slide by OSSC
OSC2018 hiroshima session slide by OSSC
Daisuke Nishino49.6K views
SIerにおくる、アジャイルプロセスの実践 by Takashi Makino
SIerにおくる、アジャイルプロセスの実践SIerにおくる、アジャイルプロセスの実践
SIerにおくる、アジャイルプロセスの実践
Takashi Makino1.1K views
Javaエンジニアのためのアーキテクト講座-JJUG CCC 2014 Fall by Yusuke Suzuki
Javaエンジニアのためのアーキテクト講座-JJUG CCC 2014 FallJavaエンジニアのためのアーキテクト講座-JJUG CCC 2014 Fall
Javaエンジニアのためのアーキテクト講座-JJUG CCC 2014 Fall
Yusuke Suzuki24.7K views
Monadic Programmingのススメ - Functional Reactive Programmingへのアプローチ by Tomoharu ASAMI
Monadic Programmingのススメ - Functional Reactive ProgrammingへのアプローチMonadic Programmingのススメ - Functional Reactive Programmingへのアプローチ
Monadic Programmingのススメ - Functional Reactive Programmingへのアプローチ
Tomoharu ASAMI16.2K views
オープンクラウド基盤の価値と導入へ向けた考慮点 〜IaaSからPaaSまで - EMC様セミナー 「あなたのビジネスを高速化!DevOpsとアジャイル開発... by Nobuyuki Tamaoki
オープンクラウド基盤の価値と導入へ向けた考慮点 〜IaaSからPaaSまで - EMC様セミナー 「あなたのビジネスを高速化!DevOpsとアジャイル開発...オープンクラウド基盤の価値と導入へ向けた考慮点 〜IaaSからPaaSまで - EMC様セミナー 「あなたのビジネスを高速化!DevOpsとアジャイル開発...
オープンクラウド基盤の価値と導入へ向けた考慮点 〜IaaSからPaaSまで - EMC様セミナー 「あなたのビジネスを高速化!DevOpsとアジャイル開発...
Nobuyuki Tamaoki804 views
オープンクラウド基盤の価値と導入へ向けた考慮点 〜IaaSからPaaSまで - EMC様セミナー 「あなたのビジネスを高速化!DevOpsとアジャイル開発... by VirtualTech Japan Inc.
オープンクラウド基盤の価値と導入へ向けた考慮点 〜IaaSからPaaSまで - EMC様セミナー 「あなたのビジネスを高速化!DevOpsとアジャイル開発...オープンクラウド基盤の価値と導入へ向けた考慮点 〜IaaSからPaaSまで - EMC様セミナー 「あなたのビジネスを高速化!DevOpsとアジャイル開発...
オープンクラウド基盤の価値と導入へ向けた考慮点 〜IaaSからPaaSまで - EMC様セミナー 「あなたのビジネスを高速化!DevOpsとアジャイル開発...
ソフトウェア開発の現場風景 by Koichi ITO
ソフトウェア開発の現場風景ソフトウェア開発の現場風景
ソフトウェア開発の現場風景
Koichi ITO4.2K views
20130320 agile pm by Takao Kimura
20130320 agile pm20130320 agile pm
20130320 agile pm
Takao Kimura2.2K views
Code for Japan 勉強会 Vol.1 CKAN入門 プロジェクトのFork、デプロイ、CIまで by Naoyuki Yamada
Code for Japan 勉強会 Vol.1 CKAN入門 プロジェクトのFork、デプロイ、CIまでCode for Japan 勉強会 Vol.1 CKAN入門 プロジェクトのFork、デプロイ、CIまで
Code for Japan 勉強会 Vol.1 CKAN入門 プロジェクトのFork、デプロイ、CIまで
Naoyuki Yamada5.3K views
Offshore Agile Development in XP by Kenji Hiranabe
Offshore Agile Development in XPOffshore Agile Development in XP
Offshore Agile Development in XP
Kenji Hiranabe1.9K views

More from Hiromasa Oka

ZOZOTOWNのアーキテクトという役割を紹介します by
ZOZOTOWNのアーキテクトという役割を紹介しますZOZOTOWNのアーキテクトという役割を紹介します
ZOZOTOWNのアーキテクトという役割を紹介しますHiromasa Oka
1.6K views23 slides
ZOZOTOWNのマルチクラウドへの挑戦と挫折、そして未来 by
ZOZOTOWNのマルチクラウドへの挑戦と挫折、そして未来ZOZOTOWNのマルチクラウドへの挑戦と挫折、そして未来
ZOZOTOWNのマルチクラウドへの挑戦と挫折、そして未来Hiromasa Oka
1.6K views44 slides
NoOps Meetup Tokyo #9 Opening by
NoOps Meetup Tokyo #9 OpeningNoOps Meetup Tokyo #9 Opening
NoOps Meetup Tokyo #9 OpeningHiromasa Oka
633 views39 slides
クラウドネイティブトランスフォーメーションのススメ by
クラウドネイティブトランスフォーメーションのススメクラウドネイティブトランスフォーメーションのススメ
クラウドネイティブトランスフォーメーションのススメHiromasa Oka
1.2K views57 slides
NoOps Meetup Tokyo #8 1st Anniversary - Opening by
NoOps Meetup Tokyo #8 1st Anniversary -  Opening NoOps Meetup Tokyo #8 1st Anniversary -  Opening
NoOps Meetup Tokyo #8 1st Anniversary - Opening Hiromasa Oka
1.3K views40 slides
NoOps Meetup Tokyo #7 Opening by
NoOps Meetup Tokyo #7 Opening NoOps Meetup Tokyo #7 Opening
NoOps Meetup Tokyo #7 Opening Hiromasa Oka
1.5K views36 slides

More from Hiromasa Oka(20)

ZOZOTOWNのアーキテクトという役割を紹介します by Hiromasa Oka
ZOZOTOWNのアーキテクトという役割を紹介しますZOZOTOWNのアーキテクトという役割を紹介します
ZOZOTOWNのアーキテクトという役割を紹介します
Hiromasa Oka1.6K views
ZOZOTOWNのマルチクラウドへの挑戦と挫折、そして未来 by Hiromasa Oka
ZOZOTOWNのマルチクラウドへの挑戦と挫折、そして未来ZOZOTOWNのマルチクラウドへの挑戦と挫折、そして未来
ZOZOTOWNのマルチクラウドへの挑戦と挫折、そして未来
Hiromasa Oka1.6K views
NoOps Meetup Tokyo #9 Opening by Hiromasa Oka
NoOps Meetup Tokyo #9 OpeningNoOps Meetup Tokyo #9 Opening
NoOps Meetup Tokyo #9 Opening
Hiromasa Oka633 views
クラウドネイティブトランスフォーメーションのススメ by Hiromasa Oka
クラウドネイティブトランスフォーメーションのススメクラウドネイティブトランスフォーメーションのススメ
クラウドネイティブトランスフォーメーションのススメ
Hiromasa Oka1.2K views
NoOps Meetup Tokyo #8 1st Anniversary - Opening by Hiromasa Oka
NoOps Meetup Tokyo #8 1st Anniversary -  Opening NoOps Meetup Tokyo #8 1st Anniversary -  Opening
NoOps Meetup Tokyo #8 1st Anniversary - Opening
Hiromasa Oka1.3K views
NoOps Meetup Tokyo #7 Opening by Hiromasa Oka
NoOps Meetup Tokyo #7 Opening NoOps Meetup Tokyo #7 Opening
NoOps Meetup Tokyo #7 Opening
Hiromasa Oka1.5K views
ZOZOTOWN の Cloud Native Journey by Hiromasa Oka
ZOZOTOWN の Cloud Native JourneyZOZOTOWN の Cloud Native Journey
ZOZOTOWN の Cloud Native Journey
Hiromasa Oka2.4K views
もう「効率化」なんてゴミ箱に捨ててしまおう by Hiromasa Oka
もう「効率化」なんてゴミ箱に捨ててしまおうもう「効率化」なんてゴミ箱に捨ててしまおう
もう「効率化」なんてゴミ箱に捨ててしまおう
Hiromasa Oka7.5K views
de:code 2019 SP07 実践NoOps by Hiromasa Oka
de:code 2019 SP07 実践NoOpsde:code 2019 SP07 実践NoOps
de:code 2019 SP07 実践NoOps
Hiromasa Oka1.9K views
NoOps Meetup Tokyo #6 Opening by Hiromasa Oka
NoOps Meetup Tokyo #6 Opening NoOps Meetup Tokyo #6 Opening
NoOps Meetup Tokyo #6 Opening
Hiromasa Oka2.4K views
NoOps Meetup Tokyo #5 Opening by Hiromasa Oka
NoOps Meetup Tokyo #5 Opening NoOps Meetup Tokyo #5 Opening
NoOps Meetup Tokyo #5 Opening
Hiromasa Oka1.5K views
NoOps Meetup Tokyo #4 Opening by Hiromasa Oka
NoOps Meetup Tokyo #4 OpeningNoOps Meetup Tokyo #4 Opening
NoOps Meetup Tokyo #4 Opening
Hiromasa Oka2K views
NoOps Meetup Tokyo #3 Opening by Hiromasa Oka
NoOps Meetup Tokyo #3 OpeningNoOps Meetup Tokyo #3 Opening
NoOps Meetup Tokyo #3 Opening
Hiromasa Oka1.3K views
NoOpsが目指す未来とコンテナ技術 by Hiromasa Oka
NoOpsが目指す未来とコンテナ技術NoOpsが目指す未来とコンテナ技術
NoOpsが目指す未来とコンテナ技術
Hiromasa Oka3.3K views
NoOps Meetup Tokyo #2 Opening by Hiromasa Oka
NoOps Meetup Tokyo #2 Opening NoOps Meetup Tokyo #2 Opening
NoOps Meetup Tokyo #2 Opening
Hiromasa Oka1.7K views
勝てる「開発プロセス」のつくり方 by Hiromasa Oka
勝てる「開発プロセス」のつくり方勝てる「開発プロセス」のつくり方
勝てる「開発プロセス」のつくり方
Hiromasa Oka4.1K views
15分で分かる NoOps by Hiromasa Oka
15分で分かる NoOps15分で分かる NoOps
15分で分かる NoOps
Hiromasa Oka30.6K views
NoOps Meetup Tokyo #1 Opening by Hiromasa Oka
NoOps Meetup Tokyo #1 OpeningNoOps Meetup Tokyo #1 Opening
NoOps Meetup Tokyo #1 Opening
Hiromasa Oka938 views
新世代の価値観へ越境せよ by Hiromasa Oka
新世代の価値観へ越境せよ新世代の価値観へ越境せよ
新世代の価値観へ越境せよ
Hiromasa Oka3.2K views
NoOps で変わる 人とシステムの関わりかた by Hiromasa Oka
NoOps で変わる 人とシステムの関わりかたNoOps で変わる 人とシステムの関わりかた
NoOps で変わる 人とシステムの関わりかた
Hiromasa Oka1.5K views

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

  • 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. アジャイルの期待効果1 ≪不不確実性への取り組み≫ 不確実性 開発効率
  • 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 • 顧客による継続的な変更更要求 • 技術リスク • 想定していた性能が出ない • 想定される動作をしない(接続できない、想定外のエラー) • ⽬目的に合致しない技術(拡張性、接続性) • スキルリスク • 利利⽤用技術の経験がない • 今回の開発プロセスの経験がない(初めての進め⽅方) • 政治リスク • 予測不不能。だが想定は⾃自由 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 要求 分析 設計 実装 テスト 要求 分析 設計 実装 テスト 要求 分析 設計 実装 テスト 要求 分析 設計 実装 テスト 要求 分析 設計 実装 テスト プロジェクト開始 リリース 技術リスク・要求リスクへの 対処 要求 分析 設計 実装 テス ト 要求 分析 設計 実装 テス ト 要求 分析 設計 実装 テス ト 要求 分析 設計 実装 テス ト 要求 分析 設計 実装 テス ト プロジェクト開始 リリース 反復型フェーズ工程別フェーズ
  • 14. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. アジャイルの期待効果2 ≪開発効率率率の向上≫ 不確実性 開発効率
  • 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. アジャイルの期待効果3 ≪エンタープライズへの拡張≫ 不確実性 開発効率 エンタープライズ
  • 23. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. 「エンタープライズ」のコンテキスト • エンタープライズ開発 ≒  業務システム開発 • 価値観の異異なる他の組織体と連携しながら進める開発 • 連携が避けられない、とも⾔言う • 計画に基づく活動 • 事業から⾒見見るとマイルストーンが重要。⼈人、モノ、カネを動かすタイ ミング。予算、期間、リソース制約も含む。 • 戦略略に則った選択 • 事業戦略略、技術戦略略、既存資産の利利⽤用(⼈人、設備、組織の経験) • 利利害関係者との調整 • 複数のユーザー部⾨門、他のシステムの運⽤用・保守・開発チーム、シス テムオーナー部⾨門⻑⾧長、役員 • コンプライアンスとガバナンス • 業界の法律律・規制、組織の規則・ルール・標準 • 規模 • 個別システム、関連システム、企業全体 23 アジャイルであっても 避けられない
  • 24. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. エンタープライズアジャイル エンタープライズのコンテキストで、アジャイル型を実践するための”拡張版“ • ディシプリンド・アジャイル・デリバリー(DAD) 《拡張点》 • 新規開発:ビジョンの合意、⽅方向付けフェーズ、初期のバックログ構築 • アーキテクチャ:アーキテクチャ、AO(アーキテクチャオーナー)、テクニカルストーリー • コストとスケジュール:リリース計画、レンジド・バーンダウン • ガバナンス:リスクリスト、リスク・価値駆動、マイルストーンレビュー • スケールド・アジャイル・フレームワーク(SAFe) 《拡張点》 • プログラムマネジメント:プログラムバックログ、プロダクトマネジメント • リリースの統制:リリース計画ミーティング、ART(アジャイルリリーストレイン)、リリースエンジニア、 IPスプリント • アーキテクチャ:システムアーキテクト、アーキテクチャ滑滑⾛走路路、テクニカルストーリー • 企業全体:ビジネスエピック、エピックオーナー、予算と投資判断、プログラムポートフォリオマネジメント、 エンタープライズアーキテクト • Scrum  of  Scrums • Enterprise  Scrum 24
  • 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つの軸 • プロジェクト環境の複雑さ • 規模(開発者数) プロジェクト環境の複雑さ 規模 (開発者数) SAFe DAD 新規性ガバナンス外部協調 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 適応型 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 実装実績から 見積基礎値を設定 方式、パターン サンプルコード 2W 優先順位の高いストーリーを タイムボックスで計画化 チームで 実装 実装された 機能 修正・追加要望をバックログに追加 イテレーションデモ レビュー ユーザ(業務カテゴリをエピックで 分類すると識別しやすい) ソース 管理 ビルド・デプロイ・テスト プロダクトバックログ 見積基礎値の フィードバック ドキュメントの追記・更新 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
  • 36. ©  2015  ZEN  ARCHITECTS  Co.,Ltd. 36 zenarchitects.co.jp facebook.com/zenarchitects