continuous-reease-planning-with-caplan-配付資料2

(1)

エンタープライズアジャイル内製プロジェクトを

立ち上げる前に考慮すべき３つのこと

2015/12/9

株式会社ゼンアーキテクツ

岡

大勝

Enterprise Agile in-house project to consider before launching "Three things".

(2)

⾃⼰紹介

• 第⼀勧銀情報システム（現：みずほ情報総研）

• VOS3 COBOL＆MS-Cプログラマ

• ⽇本DEC

• 主に⽣保・損保・銀⾏向けの

• 資産運⽤システムに携わる。

• ⽇本HP

• ⾦融機関向けのシステムアーキテクチャ設計、

• 開発プロセス設計、運⽤プロセス設計を⾏う。

• ⽇本ラショナルソフトウェア

• 開発プロセス（RUP）および

オブジェクト指向分析設計⼿法

の導⼊コンサルティング。

• ゼンアーキテクツ

• 2003年よりIT設計事務所として活動。お客さまのIT投資の最適化を

⽬指し、アーキテクチャ中⼼のプロセス改善を推進。

岡⼤勝

（おかひろまさ）

株式会社ゼンアーキテクツ

CEO/チーフアーキテクト

プロフィール

(3)

(4)

アジャイルへの取り組み

アジャイル＋アーキテクチャ

企業システムの

(5)

• Russellチームで内製⽂化の垂直⽴ち上げ

• 実績：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)

(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 WebAPIController (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)

利⽤技術とリファレンスアーキテクチャ

(8)

なぜ企業システムの内製化を

⽀援するのか？

ニッポンの競争⼒を

取り戻したい

(9)

エンタープライズ

＝“ややこしい環境”

シンプルなアジャイル（Scrum）をそのまま受

け⼊れることが難しい環境

(10)

企業システムも基本はScrum

• シンプルなScrumで回せればベスト

(11)

エンタープライズアジャイル

= Scaling Agile

そのまま適⽤できない環境に適合させるために、

Scrumに何らかの拡張が必要

(12)

Scrum

Scaleさせるべきパラメータは、組織や

環境によって異なる

Scrum

チームサイズ

品質

統制

組織

(13)

⽬的別のScalingライブラリとして

エンタープライズアジャイルフレームワークを活⽤する

13

Disciplined Agile Delivery

Large Scale Scrum

Scrum of Scrums

アジャイルの本質は不変。良い悪いではない。

⾃分の環境に適応させ進化させれるためのガイドラインに過ぎない。

⽬的別ライブラリとして、さらに多様化していくことを望む。

(14)

プログラムアセスメントでの

適合性確認項⽬

1. 動機とコミットメント

2. 既存の管理統制スキーム

3. プロダクトビジョンと

お客様の状況により、アジャイル導⼊/内製化をお勧めしない場合があります

アジャイル内製化プログラムを

適⽤するに当たって、以下の状況を確認する

。

スコープコントロール

(15)

実現する業務をストーリーとして切り出して登録受け⼊れられた実装済ストーリーを、To-Beにフィードバック SP 実装実績から⾒積基礎値を設定２W 優先順位の⾼いストーリーをタイムボックスで計画化チームで実装実装された機能修正・追加要望をバックログに追加イテレーションデモレビューユーザ（業務カテゴリをエピックで分類すると識別しやすい）ソース管理ビルド・デプロイ・テストプロダクトバックログイテレーション計画ユーザ

シンプルなアジャイルプロジェクト

プロダクトオーナーリリース

(16)

To-Be

業務フロー

ユーザからの要望/要求

ビジョン

技術

実装⽅式

初期のアー

キテクチャ

アーキテクチャドキュメント主要なストーリーを実装（US、TS）実現する業務をストーリーとして切り出して登録受け⼊れられた実装済ストーリーを、To-Beにフィードバック SP 実装実績から⾒積基礎値を設定⽅式、パターンサンプルコード２W 優先順位の⾼いストーリーをタイムボックスで計画化チームで実装実装された機能修正・追加要望をバックログに追加イテレーションデモレビューユーザ（業務カテゴリをエピックで分類すると識別しやすい）ソース管理ビルド・デプロイ・テストプロダクトバックログ⾒積基礎値のフィードバックドキュメントの追記・更新 Living Document イテレーション計画⾃動回帰テスト受⼊テストリリース判定

Ops

リリース本番運⽤インシデント管理修正依頼ユーザ運⽤担当者ユーザオーナー

企業システムでのアジャイルプロジェクト

プログラムマネージャ PMO 事業部⻑報告品質管理部⾨品質基準プロダクトオーナー

(17)

To-Be

業務フロー

ビジョン

技術

実装⽅式

初期のアー

キテクチャ

Ops

アジャイルプロジェクトを取り巻く問題

要求の⼀貫性

_{拡⼤するスコープ}

システム構造の

⼀貫性

割り込みタスク

外部からの声

（PMO、QA、有識者）

(18)

To-Be

業務フロー

ビジョン

技術

実装⽅式

初期のアー

キテクチャ

Ops

アジャイルプロジェクトを取り巻く問題

要求の⼀貫性

_{拡⼤するスコープ}

システム構造の

⼀貫性

割り込みタスク

外部からの声

（PMO、QA、有識者）

開発チームは

問題なく⽴ち上がる

焦点は、「既存の組織環境」との共存〜浸透

(19)

キャプラン株式会社のご紹介

貿易と航空・旅⾏を強みとする、総合⼈材サービス企業

(20)

プロジェクトの経緯

• 2014上派遣事業の基幹パッケージシステム更改を計画

• 2014下次期パッケージのカスタマイズ要件の取りまとめを開始

• 2015.1理想のシステムを⽬指す中で、改修対象と規模が拡⼤

• 2015.3 ゼンアーキテクツにお声がけいただく

• 2015.4 基幹パッケージとフロントシステムを分離した

アーキテクチャとしてプロジェクト再スタート

• 2015.4 フロントシステムを内製化し、

継続的な開発が可能な体制を⽬標設定し⼈材調達・チーム編成

• 2015.5 プロジェクト開始

• 2015.9 派遣登録申込機能を外部向けに初リリース

• 2015.1 教育事業システム開発プロジェクト⽴ち上げ（予定）

• 2015.4 派遣事業新基幹システム稼働開始（予定）

(21)

(22)

プロジェクトライフサイクルの選択は、

不確実性への対処戦略である。

(23)

”不確実性”のレベル

• ほとんどの事象は想定可能な⼀定の幅に収まる

• ビジネスでは、Lv.1=50%、Lv.2+Lv.3=50%、Lv.4=まれに出現

Lv.1

確実な未来

Lv.2

選択的未来

Lv.3

一定の幅

Lv.4

予測不能

適応する

未来を形成する

留保する

スピード、アジリティ、柔軟性

リーダーシップ、標準

早期のコミットを避ける

戦略

「不確実時代の⾏動と戦略」ヒュー・コートニー、他

ハーバードビジネスレビューブックス：不確実性の経営戦略（ダイヤモンド社）より

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

(24)

計画できることは、計画して実施する

• 「正しい」ことが分かっている

• よほど⼤きな問題が発⽣しない限り“うまくいく”

• 事業者は「必要な時期」に「必要なもの」が⼿に⼊れば良い。

• 定型反復業務

• 確⽴された⼿順

予測型

（計画駆動）

Lv.1

確実な未来

Lv.2

選択的未来

PMBOK 5th

ウォーターフォール型

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

(25)

計画できないことは、確認しながら進む

• 何が「正しい」のか判断できない

• 正しいものが変化する

• 機能・技術・ビジネス、マーケット

• 変化への継続的な対応

• 「要求の変化」と「優先順位の変化」

• 要求の変化＝反復型による継続的フィードバック

• 優先順位の変化＝バックログによる動的要求管理

反復型

Lv.3

一定の幅

適応型

（変化駆動/アジャイル）

PMBOK 5th

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

(26)

最初の判断基準

両⽅可能ならば、ウォーターフォール型を推奨

p 最初に詳細な仕様を確定できるか

p 精度の⾼い⾒積と計画は可能か

(27)

システム企画

ビジネス企画

⾼精度な⾒積りと計画が可能か

計画可能

パッケージ導⼊

熟知した業務

使い慣れた技術

予測型/外部調達

精度が低い

DeadLine

（納期）は

決まっているか

再設定可能

決まっている

精度向上施策の実施

⽬指す製品は明確に仕様化可能か

仕様化可能

_{仕様化困難}

他社との差別化/先⾏が必要か

類似プロダクトの調査

ソリューションの

_{仮説検証サイクル}

発⾒

スコープを限定した

予測型/外部調達

存在せず

⾃社開発の必要性

DeadLine

（納期）は

決まっているか

再設定可能

決まっている

（できるだけ早く）

プロトタイピング

適合性調査

_適応型

新しいUI・新しいデバイス

新技術・利⽤技術の転換

提供⽅式の転換（PKG→Web）

必要ない

必要

あり

なし

外部調達

この⼿段を探していた

既存システムあり

必要とするレイヤーも様々適応型で代替可能

(28)

適応型（アジャイル）を選択すべき状況

• 全てYes、つまり競争状態にあるビジネス領域で

選択されるべき

p 不確実性が残っている

p 他社との差別化が必要

p 時間に猶予がない

(29)

アジャイルは、

ビジネスの必要に迫られて

選択する⼿段

提案して採⽤してもらうものではない。

強い動機がないなら、今まで通りで⼗分。

(30)

最終的には

(31)

• これまで抑制してきた分、システムに投資する。リスクは取る

• 派遣業界のAmazonを⽬指す。

• 時間かけて検討するより、どんどん良くしていこうよ！

• エンジニアもゼロから育成して市場価値を⾼めたい。

キャプラン株式会社代表取締役社⻑

森本宏⼀

株式会社パソナグループ取締役

株式会社パソナテック代表取締役会⻑

社⻑の強⼒なコミットメント

(32)

Q. なぜ、強い動機なしに、

企業がアジャイルに⼿を出しては

いけないのか？

(33)

(34)

エンタープライズアジャイルの成熟度レベル

予測型

Level 0

予測型のみ

予

測

適

応

独⽴した環境で

アジャイル

予

測

適

応

独⽴しているが

同じ統制下

Level 1

Level 2

予

測

適

応

同じ統制下で

予測型と連携

Level 3

統制

予測型と混在

Level 4

統制

事業活動そのもの

アジャイルから

リーンへ

Level 5

統制

継続的

事業活動

それぞれの

_{Levelで規模のスケール}

株式会社ゼンアーキテクツによる定義

(35)

35

“Level 3” への壁

(36)

アジャイルを特徴づける5つの要素

反復型

適応型要求管理

ジャストインタイム

コードの共同所有

リソースと納期の

固定

Agile

(37)

リソースと納期を固定する

固定された

要求

リソース

納期

見積もられた

_要求

リソース

納期

予測型プロジェクト

アジャイル（適応型）

• メンバーを固定＝見積もり精度を最大化

• リリース日を固定＝事業計画との整合

• 要求可変＝見積もり誤差を要求スコープで調整

図：「アジャイルソフトウェア要求（翔泳社）」第

1章より引用

リソースと納期の

固定

(38)

(39)

アジャイルプロジェクトのレビューで

必ず指摘されること

üリリース時点でどの機能が使えるのか

ü全体の進捗が知りたい

ü仕様書がないのに作れるはずがない

ü計画はFIXできないのか

üこんなに計画変更が多発するプロジェクト

はおかしい。順調なはずがない。

(40)

アジャイルプロジェクトのレビューで

必ず指摘されること

üリリース時点でどの機能が使えるのか

ü全体の進捗が知りたい

ü仕様書がないのに作れるはずがない

ü計画はFIXできないのか

üこんなに計画変更が多発するプロジェクト

はおかしい。順調なはずがない。

(41)

既存の組織管理体系とのギャップ

可視化できれば、解決策はある。

アジャイルが

(42)

エンタープライズにおける

アジャイルプロジェクトに不可⽋なもの

アジャイルが

対処すべき

「全体計画」の可視化

いつ、何ができるのか、⾒通しを⽰す。

これがあるだけで、全然違う。

(43)

≪前提≫

アジャイルの⾒積りと計画⼿法は

想像以上にうまく設計されている。

(44)

スクラム

(45)

アジャイルプロジェクトの⾒積もりは

「ボトムアップ（積算）」

要求

ストーリー

₁

ストーリー

₂

ストーリー

₃

ストーリー

₄

識別

ストーリー

n

必要工数

積み上げ

工数

要求を「重なり合ったストーリー」として定義し、

個別ストーリーの実現工数を積算

(46)

【参考】ボトムアップ⾒積もり

要求仕様

作業

1 作業

2 作業

3 作業

4 作業

_n

必要工数

積み上げ

工数

成果物

分割

「本当に使える見積もり技術（日経

_{BP社）」より引用}

(47)

⾒積もりはどこで⾏われるか

47

①規模見積もり

②期間見積もり

③工数見積もり

④見積もりの改善

(48)

アジャイルの⾒積もりの流れ

①規模⾒積もり

ストーリー

要求識別

ストーリー

ストーリーの

見積もり

作成

ストーリーポイントの設定

プランニング

ポーカー

ストーリー積算による

規模見積もり

set

新たなストーリーが

識別されなくなるまで

ストーリーポイントの合計が

要求の規模

見積もり時の不毛な議論（

100か

101か）を避けるため、ストーリーポ

イントにはフィボナッチ数列の利用

を推奨

プロダクト

バックログ

+ストーリーポイント合計

ストーリー

+ ストーリーポイント

(49)

スプリント

ストーリー

49

アジャイルの⾒積もりの流れ

②期間⾒積もり

ストーリー

次スプリントの

作成

ストーリー

スプリント

バックログの

割り当て

前スプリントの

実績よりベロシティ設定

プロダクト

バックログ

スプリント

バックログ

リリース計画による

期間見積もり

スプリント

+ 期間

+ ベロシティ

+ ストーリー

ポイント合計

ストーリー

優先順位の高い

ストーリーから取得

SPがベロシティを

超えないよう

ストーリーを割り当て

set

get

実現するストーリーが

全てスプリントに

割り当てられるまで

1 1..*

1

1 スプリントの期間合計が

プロジェクト期間

チーム編成は基本固定

期間は「２週間」が標準

チーム

/組織

+ ベロシティ

(50)

タスク

ストーリー

50

アジャイルの⾒積もりの流れ

③⼯数⾒積もり

ストーリーの

タスク分解

タスクアサイン

と作業時間見

積もり

スプリント

バックログ

スプリント計画による

工数見積もり

_{+ ストーリー}

ポイント合計

ストーリー

get

タスクの定義

実施スプリントのタスク・工数の見積もり確定

実施スプリントのバックログ

タスク

+ 担当者

+予定作業時間

set

スプリントで実現する

ストーリー全て

全てのタスク

工数合計がスプリント期間を超える

もしくは大きな乖離がある

タスク見積もり

の精査

ストーリーの

割り当て変更

このスプリントでの

1ポイントあたりの作業

工数見積もりは算出は可能。

しかし見積もりの数字遊びを避けるため

SP

を意図的に精緻に見積もらないようにして

いる（フィボナッチ）ので、見積もりのポイン

トからの実時間算出は無意味

ストーリーポイントの

見積もりとのギャップ

エピック

1 0..*

_{任意の分類軸}

creates

(51)

タスク

ストーリー

51

アジャイルの⾒積もりの流れ

④⾒積もりの改善

タスクの実施

スプリントデモ

スプリント

バックログ

スプリント実施とフィードバックによる

継続的見積もり改善

_{+ ストーリー}

ポイント合計

ストーリー

実施スプリントのバックログ

タスク

+ 担当者

+予定作業時間

+ステータス

全てのタスク

スプリントタスク完了

リリース計画へ

のフィードバック

対象ストーリーは変えない

ステータス更新

タスクボード

未着手

→着手中

→完了

タスクの追加、

_{変更、削除}

仕様化、レビュー、実装、テ

スト、不具合改修、データ作

成、環境構築、リリース、等

ストーリー

プロダクト

バックログ

• ストーリーの追加・削除・修正

• 各ストーリーポイント見直し

• 優先順位変更

任意の

タイミング

追加変更

要求

次のスプリント計画へ

ストーリー単位で完了

/未完了を判断

未完了のストーリーは実績ストーリーポイントに含めない

実績ストーリー

ポイント

＝ベロシティ

(52)

アジャイルな⾒積もりの

4つの利点

1. 全体計画と実施計画の分離

2. プロジェクト内のフィードバックループ

3. 「相対値の積算⾒積もり」という落としどころ

4. ⾒積もりコストの低さ

52

(53)

(54)

(55)

(56)

アジャイルのリリース計画は

(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)

反復毎にリリース計画そのものを

“リリース”する

(59)

イテレーション

5 イテレーション

₆

イテレーション

7 ・新たなストーリー

・優先順位の入替

・利用技術の見直し

・ストーリーの分割

継続的リリース計画

常時「見通し」を可視化

影響を反映

・・・

(60)

チーム活動の透明化によって

事業活動との連携が⽣まれている

• プロダクトオーナーがリリース計画を更新するようになった

• 他の事業部の施策の考慮

• 外部プロジェクトとの依存関係調整

• 他の施策の状況に応じて、リリース優先順位の⼊替を⾏うよう

になりつつある。

ブラックボックスの

プロジェクト

「システムの調達」から「事業としての⽣産活動」へ

要求

システム

ブラックボックスの

プロジェクト

事業活動と連携した⽣産活動

(61)

「こんなに計画変更が多発するプロジェクトは

おかしい。順調なはずがない。」

＝予測型管理スキームを前提とすると、

「“計画を変更すること”がリスク」という認識

(62)

(63)

必要なのは、

(64)

「予測できないことに予測型を適⽤する」ことに、

組織は慣れすぎていないか

計画

予定外の事象

計画変更の検討

固定された要求

リソース・納期

の変更

再検討駆動ライフサイクル

(65)

「予測できないことに予測型を適⽤する」ことに、

組織は慣れすぎていないか

計画

予定外の事象

計画変更の検討

固定された要求

リソース・納期

の変更

⾦・時間の

垂れ流し

先送り

拡⼤する

再検討駆動ライフサイクル

終わりの⾒えない

泥沼

PMの仕事は

“限られた資源”の

最適配分ではないのか。

(66)

再検討駆動ライフサイクルへの対策

初級

• 「プロジェクトはリソース（予算）と期間によって制約される」という

認識の徹底。リスケ・予算変更は許さない。

• つまり、「要求の縮⼩」という⼿法を積極的に活⽤する⽂化の醸成

中級

• 機械的に「プロジェクト中⽌」を判断するルールの設定（決断できない）

• 不確実性の⾼いプロジェクトは全て外部調達（外部へのリスク移転）

上級

• 「最初の計画が正しい」という認識を捨てる

• つまり、適応型（アジャイル）プロジェクトの適⽤

(67)

3. プロダクトビジョンと

スコープコントロール

(68)

アジャイルプロジェクトのレビューで

必ず指摘されること（プロダクト編）

üユーザーが必要だと⾔うので必須です

ü今提供している機能はマスト。

機能ダウンするわけにはいかない

üやはりこっちの⽅がいいんじゃないかな

üこの機能があったほうが便利だ

(69)

アジャイルは

「変更を許している」がゆえ、

要求を突っ込みやすい。

要求を出す側は、

(70)

スコープ拡⼤は、⼈間の本能。

(71)

「ユーザーの要望は、製品仕様ではない」

• テクノロジの進化をエンドユーザーは知らない。

ユーザー要望は、参考情報に過ぎないと捉えるべき。

• プロダクトマネージャの製品への意思が、

要望を製品の機能性に変換する。

要望

プロダクト

ビジョン

製品の

機能・仕様

要望

(72)

「スコープコントロール」は

プロジェクトの成功に不可⽋

üアジャイルは、先⾏して仕様を⽂書化しないため、

スコープが曖昧になる。

üリソース・納期のキャパシティを超えて要求が流⼊しやすい。

üゆえに、プロダクトオーナーによる「スコープコントロール」が

特に重要（“いますぐに実装しない”判断）

üアジャイルの２週間のタイムボックスは、

実現可能なスコープを測るための「現実的な器」である。

アジャイルはスコープにセンシティブであるべき

(73)

要求のみに注⼒することで、

スコープコントロールの⽂化が

少しずつ根付いてきた

• 基幹業務をまわすために必要な最低限の機能（基本ストーリー）＜

MMRとも⾔う＞と、あると便利な機能（拡張ストーリー）に分割し、

“業務を回すための⼀式”が必ずリリースに含まれるよう分割して

扱うことを⼼がけている。

• ゆえに、ストーリーの粒度は⼩さく。

• タイムボックスに収めるためには、採⽤技術も重要。

• ユーザー要望は、プロダクトバックログの「外部」で管理している。

バックログには製品化するストーリーのみ記載。

• とはいえ、MMRの識別とユーザー交渉は双⽅に⼤きな負担だが、成

功の鍵はここにあると認識している。

MMR: Minimum Marketable Release

(74)

To-Be

業務フロー

ビジョン

技術

実装⽅式

初期のアー

キテクチャ

Ops

企業におけるアジャイルプロジェクトのありかた

ビジョン

継続的リリース計画

⽬指すべきは、

ビジョンを軸としたプロダクト⽣産サイクル

アジャイルから

⽣産活動へ

スコープ

コントロール

(75)

ビジョン

継続的

リリース計画

エンタープライズ

アジャイル

チーム

スコープ

コントロール

_{アイディア}

新しい

継続的な

製品化

新たな施策

⽣産活動の透明性

⽬的軸

フローコントロール

事業としてのプロダクト⽣産活動

事業での

結果

エンタープライズアジャイルの

⽬指すべき姿

(76)

達成できたこと

• 新規システムをプロジェクト開始から3ヶ⽉でリリース

• 社内エンジニアゼロからの調達・育成

• 継続的な内製開発運⽤体制の確⽴

• アジャイルプロジェクト活動の分散拠点開発

• リリース計画の⾃動化・精緻化による事業戦略との連携

(77)

認識している課題

• ウォーターフォール型プロジェクトとの連携強化

• より能動的なスコープコントロールが必要

• 将来の開発チームのスケール（⽣産⼒強化）

• 教育事業との並⾏開発に向けて

(78)

フロント開発チームリーダー

南邦彦様

（プロモーション企画Tリーダー）

の視点

• 良かった点

• 現場の⼈間がシステム開発に携わることができる。

思った以上にめっちゃ良い。

• 今までは、システム開発は⼀部の⼈だけで進めていた。

変えたくても変えられない「システムという制約」が

ビジネスを阻害していたと考えていたが、それは⾔い訳だった。

• 思ったより⼤変だった点

• その分、メンバー同⼠の結束⼒が求められる。

2週間ごとに、が⼤変。

そして何より、理解してもらうことが⼤変。

• トップの強い意向がないと、難しかったんじゃないかと思う。

• 改善点・慣れない点

• 中の⼦にも「次に何をやるのか」を⾒せてあげることが⼤切。

たとえ後で変わるとしても。

• ⼯数の考え⽅が難しい。⼈依存でやってみなければ出せないところ。

• まとまったシステムを作るときに「全部でいくら」が出しづらい。

「それで収まるの？根拠は？」と聞かれると困る。

• 受託だったら、スケジュールに合わせて尻を叩ける。

アジャイルは、「どうしてもやる」を詰め込みにくい。

サラッと「収まらない」と⾔われると、無理をいいにくい。

(79)

ゼンアーキテクツが、

企業システムへのアジャイル内製化⽀援の

活動を通じて学んできこと

Øエンジニアリング⾯では、企業システムへのアジャイル内製化に

障壁はない。チームの⽴ち上げに不安なし。

Ø積極的なスコープコントロールが必須のため、⼀括受託型での適

⽤はやはり難しいという認識。適⽤には⼯夫が必要。

Øアジャイルは、予測型に硬直した組織⽂化を変⾰させるための触

媒となる。システム開発だけでなく⽇本の産業の国際競争⼒を⾼

めるための有⼒な⼿段になりえる。

(80)

80

zenarchitects.co.jp

continuous-reease-planning-with-caplan-配付資料2

エンタープライズアジャイル内製プロジェクトを

立ち上げる前に考慮すべき３つのこと

2015/12/9

株式会社ゼンアーキテクツ

岡

大勝

Enterprise Agile in-house project to consider before launching "Three things".

⾃⼰紹介

• 第⼀勧銀情報システム（現：みずほ情報総研）

•

VOS3 COBOL＆MS-Cプログラマ

• ⽇本DEC

•

主に⽣保・損保・銀⾏向けの

•

資産運⽤システムに携わる。

• ⽇本HP

•

⾦融機関向けのシステムアーキテクチャ設計、

•

開発プロセス設計、運⽤プロセス設計を⾏う。

• ⽇本ラショナルソフトウェア

•

開発プロセス（RUP）および

オブジェクト指向分析設計⼿法

の導⼊コンサルティング。

• ゼンアーキテクツ

•

2003年よりIT設計事務所として活動。お客さまのIT投資の最適化を

⽬指し、アーキテクチャ中⼼のプロセス改善を推進。

岡 ⼤勝

（おか ひろまさ）

株式会社ゼンアーキテクツ

CEO/チーフアーキテクト

プロフィール

アジャイルへの取り組み

アジャイル ＋ アーキテクチャ

企業システムの

• Russellチームで内製⽂化の垂直⽴ち上げ

• 実績：9社11システム

(2013/6〜)

• 業種：⾦融、製造、⼈材派遣、医療

• 5社7システムで⽀援継続中

Powered by

Team with

マイクロソフト株式会社

クロスプラットフォーム開発パートナー

アトラシアンエキスパート（正規販売代理店）

Client Side

WebBrowser

(Presentation)

User

Event

Server Side

Server

Business

Model

Redis Cache

SQL Database

Application

Insights

Send Grid

利⽤技術とリファレンスアーキテクチャ

なぜ企業システムの内製化を

⽀援するのか？

ニッポンの競争⼒を

取り戻したい

エンタープライズ

＝“ややこしい環境”

シンプルなアジャイル（Scrum）をそのまま受

け⼊れることが難しい環境

企業システムも基本はScrum

• シンプルなScrumで回せればベスト

エンタープライズアジャイル

= Scaling Agile

そのまま適⽤できない環境に適合させるために、

Scrumに何らかの拡張が必要

Scrum

Scaleさせるべきパラメータは、組織や

岡⼤勝

（おかひろまさ）

アジャイル＋アーキテクチャ

_{拡⼤するスコープ}

_{拡⼤するスコープ}