エンタープライズアジャイル内製プロジェクトを立 …zenwpmedia.blob.core.windows.net › wpmedia › 2015 › 12 › ZEN...エンタープライズアジャイル内製プロジェクトを

エンタープライズアジャイル内製プロジェクトを立ち上げる前に考慮すべき３つのこと

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システムで⽀援継続中

Poweredby

Teamwith

マイクロソフト株式会社クロスプラットフォーム開発パートナー

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

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

アジャイルチームとプロジェクトライフサイクル

Client SideWebBrowser(Presentation)

View (HTML)

JavaScriptFrameWork

User Event

View Model

WebSocketDriver

Validation

ViewModel

ServerSide

Server

<PaaS>AppService ASP

.NETASP.NET

Application MVCController

WebAPIController(REST API)

Service

Identity(Authn/Authz)

Business Model

View Model

ViewModel

Redis Cache

SQLDatabase

ApplicationInsights

BusinessObject A

BusinessObject B

Send Grid

Validation

CreateHTML Docs

API call(HTTP)

WebSocket JSON

Entry

WebJobs

WebApps

Send Mail

Logging &Notif ication

JSON

response

MVCController WebAPI

Controller(REST API)

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

AzureAD/AD

なぜ企業システムの内製化を⽀援するのか？

ニッポンの競争⼒を取り戻したい

アジャイルはその⼀助となり得る、と私たちは考えている

エンタープライズ＝“ややこしい環境”

シンプルなアジャイル（Scrum）をそのまま受け⼊れることが難しい環境

企業システムも基本はScrum

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

Scrum

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

そのまま適⽤できない環境に適合させるために、Scrumに何らかの拡張が必要

Scrum

Scaleさせるべきパラメータは、組織や環境によって異なる

Scrum

チームサイズ

品質

統制組織

⽬的別のScalingライブラリとしてエンタープライズアジャイルフレームワークを活⽤する

13

Disciplined Agile Delivery

LargeScaleScrum

ScrumofScrums

アジャイルの本質は不変。良い悪いではない。⾃分の環境に適応させ進化させれるためのガイドラインに過ぎない。

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

プログラムアセスメントでの適合性確認項⽬

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

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

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

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

アジャイル内製化プログラムを適⽤するに当たって、以下の状況を確認する。

スコープコントロール

実現する業務をストーリーとして切り出して登録

受け⼊れられた実装済ストーリーを、To-Beにフィードバック

SP

実装実績から⾒積基礎値を設定

２W

優先順位の⾼いストーリーをタイムボックスで計画化

チームで実装

実装された機能

修正・追加要望をバックログに追加

イテレーションデモレビュー

ユーザ（業務カテゴリをエピックで分類すると識別しやすい）

ソース管理

ビルド・デプロイ・テストプロダクトバックログ

イテレーション計画

ユーザ

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

プロダクトオーナー

リリース

To-Be業務フロー

ユーザからの要望/要求

ビジョン

技術実装⽅式

初期のアーキテクチャ

アーキテクチャ

ドキュメント

主要なストーリーを実装（US、TS）



SP


⽅式、パターンサンプルコード

２W


チームで実装





ソース管理

ビルド・デプロイ・テストプロダクトバックログ⾒積基礎値のフィードバック

ドキュメントの追記・更新

Living Document


⾃動回帰テスト

受⼊テストリリース判定

Ops

リリース

本番運⽤インシデント管理

修正依頼

ユーザ

運⽤担当者

ユーザ

オーナー

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

プログラムマネージャPMO事業部⻑

報告

品質管理部⾨

品質基準




ビジョン

技術実装⽅式



ドキュメント




SP



２W


チームで実装





ソース管理



Living Document




Ops

リリース


修正依頼

ユーザ

運⽤担当者

ユーザ

オーナー

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


報告

品質管理部⾨

品質基準

プロダクトオーナー要求の⼀貫性拡⼤するスコープ

システム構造の⼀貫性

割り込みタスク

外部からの声（PMO、QA、有識者）



ビジョン

技術実装⽅式



ドキュメント




SP



２W


チームで実装





ソース管理



Living Document




Ops

リリース


修正依頼

ユーザ

運⽤担当者

ユーザ

オーナー

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


報告

品質管理部⾨

品質基準

プロダクトオーナー要求の⼀貫性拡⼤するスコープ

システム構造の⼀貫性

割り込みタスク

外部からの声（PMO、QA、有識者）

開発チームは問題なく⽴ち上がる

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

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

貿易と航空・旅⾏を強みとする、総合⼈材サービス企業⺟体は伊藤忠グループ＋⽇本航空グループ。現在はパソナグループの⼀員。

プロジェクトの経緯

• 2014上派遣事業の基幹パッケージシステム更改を計画• 2014下次期パッケージのカスタマイズ要件の取りまとめを開始• 2015.1理想のシステムを⽬指す中で、改修対象と規模が拡⼤• 2015.3 ゼンアーキテクツにお声がけいただく• 2015.4 基幹パッケージとフロントシステムを分離した

アーキテクチャとしてプロジェクト再スタート• 2015.4 フロントシステムを内製化し、

継続的な開発が可能な体制を⽬標設定し⼈材調達・チーム編成• 2015.5 プロジェクト開始• 2015.9 派遣登録申込機能を外部向けに初リリース• 2015.1 教育事業システム開発プロジェクト⽴ち上げ（予定）• 2015.4 派遣事業新基幹システム稼働開始（予定）

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

プロジェクトライフサイクルの選択は、不確実性への対処戦略である。

”不確実性”のレベル• ほとんどの事象は想定可能な⼀定の幅に収まる• ビジネスでは、Lv.1=50%、Lv.2+Lv.3=50%、Lv.4=まれに出現

Lv.1確実な未来

Lv.2選択的未来

Lv.3一定の幅

Lv.4予測不能

適応する未来を形成する留保する

スピード、アジリティ、柔軟性リーダーシップ、標準早期のコミットを避ける

戦略

「不確実時代の⾏動と戦略」ヒュー・コートニー、他ハーバードビジネスレビューブックス：不確実性の経営戦略（ダイヤモンド社）より

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

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

• 「正しい」ことが分かっている• よほど⼤きな問題が発⽣しない限り“うまくいく”• 事業者は「必要な時期」に「必要なもの」が⼿に⼊れば良い。

• 定型反復業務• 確⽴された⼿順

予測型（計画駆動）

Lv.1確実な未来

Lv.2選択的未来

PMBOK 5th

ウォーターフォール型


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

• 何が「正しい」のか判断できない• 正しいものが変化する• 機能・技術・ビジネス、マーケット

• 変化への継続的な対応• 「要求の変化」と「優先順位の変化」• 要求の変化＝反復型による継続的フィードバック• 優先順位の変化＝バックログによる動的要求管理反復型

Lv.3一定の幅適応型

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

PMBOK 5th


最初の判断基準

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

p 最初に詳細な仕様を確定できるかp 精度の⾼い⾒積と計画は可能か

システム企画

ビジネス企画

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

計画可能

パッケージ導⼊

熟知した業務

使い慣れた技術

予測型/外部調達

精度が低い

DeadLine（納期）は決まっているか

再設定可能決まっている

精度向上施策の実施

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

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

類似プロダクトの調査ソリューションの仮説検証サイクル

発⾒

スコープを限定した予測型/外部調達

存在せず

⾃社開発の必要性

DeadLine（納期）は決まっているか

再設定可能決まっている（できるだけ早く）

プロトタイピング適合性調査適応型

新しいUI・新しいデバイス新技術・利⽤技術の転換

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

必要ない必要

ありなし

外部調達

この⼿段を探していた

既存システムあり

必要とするレイヤーも様々

適応型で代替可能

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

•全てYes、つまり競争状態にあるビジネス領域で選択されるべき

p 不確実性が残っているp 他社との差別化が必要p 時間に猶予がない

アジャイルは、ビジネスの必要に迫られて選択する⼿段提案して採⽤してもらうものではない。強い動機がないなら、今まで通りで⼗分。

最終的には「費⽤」対「効果」対「リスク」

• これまで抑制してきた分、システムに投資する。リスクは取る• 派遣業界のAmazonを⽬指す。• 時間かけて検討するより、どんどん良くしていこうよ！• エンジニアもゼロから育成して市場価値を⾼めたい。

キャプラン株式会社代表取締役社⻑森本宏⼀

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

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

Q. なぜ、強い動機なしに、企業がアジャイルに⼿を出してはいけないのか？

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

©2015ZENARCHITECTSCo.,Ltd.

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

予測型

Level0

予測型のみ

予測

適応

独⽴した環境でアジャイル

予測

適応

独⽴しているが同じ統制下

Level1

Level2

予測

適応

同じ統制下で予測型と連携

Level3

統制

予測型と混在

Level4

統制

統制

事業活動そのものアジャイルからリーンへ

Level5統制

継続的事業活動

それぞれのLevelで規模のスケール

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


35

“Level 3” への壁

「予測型」前提の管理スキーム


36

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

反復型

適応型要求管理

ジャストインタイムコードの共同所有

リソースと納期の固定Agile


37

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

固定された要求

リソース納期見積もられた要求

リソース納期

予測型プロジェクトアジャイル（適応型）

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

• リリース日を固定＝事業計画との整合• 要求可変＝見積もり誤差を要求スコープで調整

図：「アジャイルソフトウェア要求（翔泳社）」第1章より引用

リソースと納期の固定

無防備で踏み⼊ると、、

アジャイルプロジェクトのレビューで必ず指摘されること

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

ü全体の進捗が知りたい

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

ü計画はFIXできないのか

üこんなに計画変更が多発するプロジェクトはおかしい。順調なはずがない。

アジャイルプロジェクトのレビューで必ず指摘されること

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

ü全体の進捗が知りたい

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

ü計画はFIXできないのか

üこんなに計画変更が多発するプロジェクトはおかしい。順調なはずがない。

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

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

アジャイルが対処すべき

アジャイルの理解本質的に⽭盾

エンタープライズにおけるアジャイルプロジェクトに不可⽋なもの

アジャイルが対処すべき

「全体計画」の可視化

いつ、何ができるのか、⾒通しを⽰す。これがあるだけで、全然違う。

≪前提≫ アジャイルの⾒積りと計画⼿法は想像以上にうまく設計されている。

現実性/精度/⾒積もりコストのバランスが絶妙


スクラム

44


45

アジャイルプロジェクトの⾒積もりは「ボトムアップ（積算）」

要求

ストーリー1

ストーリー2

ストーリー3

ストーリー4

識別

ストーリーn

必要工数

必要工数

必要工数

必要工数

必要工数

積み上げ

工数

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

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


46

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

要求仕様

作業1 作業2 作業3 作業4 作業n

必要工数必要工数必要工数必要工数必要工数

積み上げ

工数

成果物

分割

「本当に使える見積もり技術（日経BP社）」より引用


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

47

①規模見積もり②期間見積もり ③工数見積もり

④見積もりの改善


48

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

ストーリー

要求識別

ストーリー

ストーリーの見積もり

作成

ストーリーポイントの設定プランニングポーカー

ストーリー積算による規模見積もり

set

新たなストーリーが

識別されなくなるまで

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

要求の規模

見積もり時の不毛な議論（100か101か）を避けるため、ストーリーポイントにはフィボナッチ数列の利用

を推奨

プロダクトバックログ

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

ストーリー

+ストーリーポイント


スプリントスプリント

ストーリー

49

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

ストーリー

次スプリントの作成

ストーリーストーリー

スプリントバックログの割り当て

前スプリントの

実績よりベロシティ設定


スプリントバックログ

リリース計画による期間見積もり

スプリント

+期間+ベロシティ

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

ストーリー

優先順位の高いストーリーから取得

SPがベロシティを超えないようストーリーを割り当て

set

setget

実現するストーリーが

全てスプリントに割り当てられるまで

1

1..*

11

スプリントの期間合計が

プロジェクト期間

チーム編成は基本固定

期間は「２週間」が標準

チーム/組織

+ベロシティ


タスク

ストーリー

50

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

ストーリーの

タスク分解

タスクアサイン

と作業時間見積もり


スプリント計画による工数見積もり +ストーリー

ポイント合計

ストーリーget

タスクの定義

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

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

タスク

+担当者+予定作業時間

set

スプリントで実現する

ストーリー全て

全てのタスク

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

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

タスク見積もりの精査

ストーリーの割り当て変更

このスプリントでの1ポイントあたりの作業工数見積もりは算出は可能。

しかし見積もりの数字遊びを避けるためSPを意図的に精緻に見積もらないようにしている（フィボナッチ）ので、見積もりのポイン

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

ストーリーポイントの見積もりとのギャップ

エピック1

0..* 任意の分類軸

creates


タスク

ストーリー

51

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

タスクの実施

スプリントデモ


スプリント実施とフィードバックによる継続的見積もり改善 +ストーリー

ポイント合計

ストーリー

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

タスク

+担当者+予定作業時間+ステータス

全てのタスク

スプリントタスク完了

リリース計画へのフィードバック

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

ステータス更新

タスクボード

未着手

→着手中→完了

タスクの追加、

変更、削除

仕様化、レビュー、実装、テスト、不具合改修、データ作成、環境構築、リリース、等

ストーリーストーリーストーリー


• ストーリーの追加・削除・修正• 各ストーリーポイント見直し• 優先順位変更

任意の

タイミング

追加変更要求

次のスプリント計画へ

ストーリー単位で完了/未完了を判断未完了のストーリーは実績ストーリーポイントに含めない

実績ストーリーポイント

＝ベロシティ

アジャイルな⾒積もりの4つの利点

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

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

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

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

52

5. 計画を「導出」可能

アジャイルのリリース計画は「⼿作り」するものではない。

ContinuousReleasePlanning「継続的リリース計画」

Agile Processes in Software Engineering and Extreme Programming「Continuous Release Planning in a Large-Scale Scrum Development Organization at Ericsson」

反復毎にリリース計画そのものを“リリース”する


イテレーション5



・新たなストーリー

・優先順位の入替

・利用技術の見直し

・ストーリーの分割

継続的リリース計画

常時「見通し」を可視化

影響を反映

影響を反映

・・・

チーム活動の透明化によって事業活動との連携が⽣まれている

• プロダクトオーナーがリリース計画を更新するようになった• 他の事業部の施策の考慮• 外部プロジェクトとの依存関係調整• 他の施策の状況に応じて、リリース優先順位の⼊替を⾏うよう

になりつつある。

ブラックボックスのプロジェクト

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

要求システム

ブラックボックスのプロジェクト

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

「こんなに計画変更が多発するプロジェクトはおかしい。順調なはずがない。」

＝予測型管理スキームを前提とすると、「“計画を変更すること”がリスク」という認識

本質的に⽭盾

これが最もやっかい。

必要なのは、意識改⾰だけではない

「予測できないことに予測型を適⽤する」ことに、組織は慣れすぎていないか

計画

予定外の事象

計画変更の検討

固定された要求リソース・納期の変更

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

「予測できないことに予測型を適⽤する」ことに、組織は慣れすぎていないか

計画

予定外の事象

計画変更の検討

固定された要求リソース・納期の変更

⾦・時間の垂れ流し

先送り

拡⼤する

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

終わりの⾒えない泥沼

PMの仕事は“限られた資源”の

最適配分ではないのか。

再検討駆動ライフサイクルへの対策初級• 「プロジェクトはリソース（予算）と期間によって制約される」という

認識の徹底。リスケ・予算変更は許さない。• つまり、「要求の縮⼩」という⼿法を積極的に活⽤する⽂化の醸成

中級• 機械的に「プロジェクト中⽌」を判断するルールの設定（決断できない）• 不確実性の⾼いプロジェクトは全て外部調達（外部へのリスク移転）

上級• 「最初の計画が正しい」という認識を捨てる• つまり、適応型（アジャイル）プロジェクトの適⽤

3. プロダクトビジョンとスコープコントロール

アジャイルプロジェクトのレビューで必ず指摘されること（プロダクト編）

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

ü今提供している機能はマスト。機能ダウンするわけにはいかない

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

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

アジャイルは「変更を許している」がゆえ、要求を突っ込みやすい。

要求を出す側は、「無理すれば追加できるだろう」と考えやすい。

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

「せっかくだから」「どうせやるなら」・・・

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

•テクノロジの進化をエンドユーザーは知らない。ユーザー要望は、参考情報に過ぎないと捉えるべき。•プロダクトマネージャの製品への意思が、

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

要望

プロダクトビジョン

製品の機能・仕様

要望

要望

要望

要望

要望要望

要望

「スコープコントロール」はプロジェクトの成功に不可⽋

üアジャイルは、先⾏して仕様を⽂書化しないため、スコープが曖昧になる。

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

üゆえに、プロダクトオーナーによる「スコープコントロール」が特に重要（“いますぐに実装しない”判断）

üアジャイルの２週間のタイムボックスは、実現可能なスコープを測るための「現実的な器」である。

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

要求のみに注⼒することで、スコープコントロールの⽂化が少しずつ根付いてきた

• 基幹業務をまわすために必要な最低限の機能（基本ストーリー）＜MMRとも⾔う＞と、あると便利な機能（拡張ストーリー）に分割し、“業務を回すための⼀式”が必ずリリースに含まれるよう分割して扱うことを⼼がけている。• ゆえに、ストーリーの粒度は⼩さく。• タイムボックスに収めるためには、採⽤技術も重要。• ユーザー要望は、プロダクトバックログの「外部」で管理している。

バックログには製品化するストーリーのみ記載。• とはいえ、MMRの識別とユーザー交渉は双⽅に⼤きな負担だが、成

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

MMR:MinimumMarketableRelease



ビジョン

技術実装⽅式



ドキュメント




SP



２W


チームで実装





ソース管理



Living Document




Ops

リリース


修正依頼

ユーザ

運⽤担当者

ユーザ

オーナー

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


報告

品質管理部⾨

品質基準


ビジョン継続的リリース計画

⽬指すべきは、ビジョンを軸としたプロダクト⽣産サイクル

アジャイルから⽣産活動へ

スコープコントロール

ビジョン継続的リリース計画

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

チーム

スコープコントロール新しい

アイディア継続的な製品化

新たな施策

⽣産活動の透明性⽬的軸フローコントロール

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

事業での結果

エンタープライズアジャイルの⽬指すべき姿

達成できたこと

•新規システムをプロジェクト開始から3ヶ⽉でリリース•社内エンジニアゼロからの調達・育成•継続的な内製開発運⽤体制の確⽴•アジャイルプロジェクト活動の分散拠点開発•リリース計画の⾃動化・精緻化による事業戦略との連携

認識している課題

•ウォーターフォール型プロジェクトとの連携強化•より能動的なスコープコントロールが必要•将来の開発チームのスケール（⽣産⼒強化）•教育事業との並⾏開発に向けて

フロント開発チームリーダー南邦彦様（プロモーション企画Tリーダー）の視点• 良かった点

• 現場の⼈間がシステム開発に携わることができる。思った以上にめっちゃ良い。

• 今までは、システム開発は⼀部の⼈だけで進めていた。変えたくても変えられない「システムという制約」がビジネスを阻害していたと考えていたが、それは⾔い訳だった。

• 思ったより⼤変だった点• その分、メンバー同⼠の結束⼒が求められる。

2週間ごとに、が⼤変。そして何より、理解してもらうことが⼤変。

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

• 中の⼦にも「次に何をやるのか」を⾒せてあげることが⼤切。たとえ後で変わるとしても。

• ⼯数の考え⽅が難しい。⼈依存でやってみなければ出せないところ。• まとまったシステムを作るときに「全部でいくら」が出しづらい。

「それで収まるの？根拠は？」と聞かれると困る。• 受託だったら、スケジュールに合わせて尻を叩ける。

アジャイルは、「どうしてもやる」を詰め込みにくい。サラッと「収まらない」と⾔われると、無理をいいにくい。

ゼンアーキテクツが、企業システムへのアジャイル内製化⽀援の活動を通じて学んできこと

Øエンジニアリング⾯では、企業システムへのアジャイル内製化に障壁はない。チームの⽴ち上げに不安なし。

Ø積極的なスコープコントロールが必須のため、⼀括受託型での適⽤はやはり難しいという認識。適⽤には⼯夫が必要。

Øアジャイルは、予測型に硬直した組織⽂化を変⾰させるための触媒となる。システム開発だけでなく⽇本の産業の国際競争⼒を⾼めるための有⼒な⼿段になりえる。

Our journey still continues...

80

zenarchitects.co.jpfacebook.com/zenarchitects

Documents

エンタープライズアジャイル内製プロジェクトを 立 …zenwpmedia.blob.core.windows.net › wpmedia › 2015 › 12 › ZEN...エンタープライズアジャイル内製プロジェクトを

エンタープライズアジャイル内製プロジェクトを立 …zenwpmedia.blob.core.windows.net › wpmedia › 2015 › 12 › ZEN...エンタープライズアジャイル内製プロジェクトを