Contenu connexe Similaire à エンタープライズアジャイル内製プロジェクトを立ち上げる前に考慮すべき3つのこと (20) Plus de Hiromasa Oka (20) エンタープライズアジャイル内製プロジェクトを立ち上げる前に考慮すべき3つのこと2. ⾃自⼰己紹介
• 第⼀一勧銀情報システム(現:みずほ情報総研)
• VOS3 COBOL&MS-‑Cプログラマ
• ⽇日本DEC
• 主に⽣生保・損保・銀⾏行向けの
• 資産運⽤用システムに携わる。
• ⽇日本HP
• ⾦金融機関向けのシステムアーキテクチャ設計、
• 開発プロセス設計、運⽤用プロセス設計を⾏行う。
• ⽇日本ラショナルソフトウェア
• 開発プロセス(RUP)および
オブジェクト指向分析設計⼿手法
の導⼊入コンサルティング。
• ゼンアーキテクツ
• 2003年よりIT設計事務所として活動。お客さまのIT投資の最適化を
⽬目指し、アーキテクチャ中⼼心のプロセス改善を推進。
岡 ⼤大勝
(おか ひろまさ)
株式会社ゼンアーキテクツ
CEO/チーフアーキテクト
プロフィール
5. • ラッセルチーム(※)で内製⽂文化の垂直⽴立ち上げ
• 実績: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
(※)ラッセル=登⼭山で、深い雪をはらいのけ道を開きつつ進むこと。
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
WebAPI
Controller
(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)
利利⽤用技術とリファレンスアーキテクチャ
Azure
AD/AD
22. プロジェクトの経緯
• 2014上 派遣事業の基幹パッケージシステム更改を計画
• 2014下 次期パッケージのカスタマイズ要件の取りまとめを開始
• 2015.1理想のシステムを⽬目指す中で、改修対象と規模が拡⼤大
• 2015.3 ゼンアーキテクツにお声がけいただく
• 2015.4 基幹パッケージとフロントシステムを分離した
アーキテクチャとしてプロジェクト再スタート
• 2015.4 フロントシステムを内製化し、
継続的な開発が可能な体制を⽬目標設定し⼈人材調達・チーム編成
• 2015.5 プロジェクト開始
• 2015.9 派遣登録申込機能を外部向けに初リリース
• 2015.1 教育事業システム開発プロジェクト⽴立ち上げ(予定)
• 2015.4 派遣事業新基幹システム稼働開始(予定)
36. ©
2015
ZEN
ARCHITECTS
Co.,Ltd.
エンタープライズアジャイルの成熟度度レベル
予測型
Level
0
予測型のみ
予
測
適
応
独⽴立した環境で
アジャイル
予
測
適
応
独⽴立しているが
同じ統制下
Level
1
Level
2
予
測
適
応
同じ統制下で
予測型と連携
Level
3
統制
予測型と混在
Level
4
統制
統制
事業活動そのもの
アジャイルから
リーンへ
Level
5
統制
継続的
事業活動
それぞれのLevelで規模のスケール
株式会社ゼンアーキテクツによる定義
37. ©
2015
ZEN
ARCHITECTS
Co.,Ltd.
37
成熟度“Level 3” への壁
「予測型」前提の管理スキーム
38. ©
2015
ZEN
ARCHITECTS
Co.,Ltd.
38
アジャイルを特徴づける5つの要素
反復型
適応型要求管理
ジャストインタイム コードの共同所有
リソースと納期の
固定
Agile
39. ©
2015
ZEN
ARCHITECTS
Co.,Ltd.
39
リソースと納期を固定する
固定された 要求
リソース 納期見積もられた 要求
リソース 納期
予測型プロジェクト アジャイル(適応型)
• メンバーを固定=見積もり精度を最大化
• リリース日を固定=事業計画との整合
• 要求可変=見積もり誤差を要求スコープで調整
図:「アジャイルソフトウェア要求(翔泳社)」第1章より引用
リソースと納期の
固定
47. ©
2015
ZEN
ARCHITECTS
Co.,Ltd.
47
アジャイルプロジェクトの⾒見見積もりは
「ボトムアップ(積算)」
要求
ストーリー1
ストーリー2
ストーリー3
ストーリー4
識別
ストーリーn
必要工数
必要工数
必要工数
必要工数
必要工数
積み上げ
工数
要求を「重なり合ったストーリー」として定義し、
個別ストーリーの実現工数を積算
48. ©
2015
ZEN
ARCHITECTS
Co.,Ltd.
48
【参考】ボトムアップ⾒見見積もり
要求仕様
作業1 作業2 作業3 作業4 作業n
必要工数 必要工数 必要工数 必要工数 必要工数
積み上げ
工数
成果物
分割
「本当に使える見積もり技術(日経BP社)」より引用
49. ©
2015
ZEN
ARCHITECTS
Co.,Ltd.
⾒見見積もりはどこで⾏行行われるか
49
①規模見積もり
②期間見積もり
③工数見積もり
④見積もりの改善
50. ©
2015
ZEN
ARCHITECTS
Co.,Ltd.
50
アジャイルの⾒見見積もりの流流れ
①規模⾒見見積もり
ストーリー
要求識別
ストーリー
ストーリーの
見積もり
作成
ストーリーポイントの設定
プランニング
ポーカー
ストーリー積算による
規模見積もり
set
新たなストーリーが
識別されなくなるまで
ストーリーポイントの合計が
要求の規模
見積もり時の不毛な議論(100か
101か)を避けるため、ストーリーポ
イントにはフィボナッチ数列の利用
を推奨
プロダクト
バックログ
+ストーリーポイント合計
ストーリー
+
ストーリーポイント
51. ©
2015
ZEN
ARCHITECTS
Co.,Ltd.
スプリントスプリント
ストーリー
51
アジャイルの⾒見見積もりの流流れ
②期間⾒見見積もり
ストーリー
次スプリントの
作成
ストーリーストーリー
スプリント
バックログの
割り当て
前スプリントの
実績よりベロシティ設定
プロダクト
バックログ
スプリント
バックログ
リリース計画による
期間見積もり
スプリント
+
期間
+
ベロシティ
+
ストーリー
ポイント合計
ストーリー
優先順位の高い
ストーリーから取得
SPがベロシティを
超えないよう
ストーリーを割り当て
set
setget
実現するストーリーが
全てスプリントに
割り当てられるまで
1
1..*
1
1
スプリントの期間合計が
プロジェクト期間
チーム編成は基本固定
期間は「2週間」が標準
チーム/組織
+
ベロシティ
52. ©
2015
ZEN
ARCHITECTS
Co.,Ltd.
タスク
ストーリー
52
アジャイルの⾒見見積もりの流流れ
③⼯工数⾒見見積もり
ストーリーの
タスク分解
タスクアサイン
と作業時間見
積もり
スプリント
バックログ
スプリント計画による
工数見積もり +
ストーリー
ポイント合計
ストーリーget
タスクの定義
実施スプリントのタスク・工数の見積もり確定
実施スプリントのバックログ
タスク
+
担当者
+予定作業時間
set
スプリントで実現する
ストーリー全て
全てのタスク
工数合計がスプリント期間を超える
もしくは大きな乖離がある
タスク見積もり
の精査
ストーリーの
割り当て変更
このスプリントでの1ポイントあたりの作業
工数見積もりは算出は可能。
しかし見積もりの数字遊びを避けるためSP
を意図的に精緻に見積もらないようにして
いる(フィボナッチ)ので、見積もりのポイン
トからの実時間算出は無意味
ストーリーポイントの
見積もりとのギャップ
エピック
1
0..* 任意の分類軸
creates
53. ©
2015
ZEN
ARCHITECTS
Co.,Ltd.
タスク
ストーリー
53
アジャイルの⾒見見積もりの流流れ
④⾒見見積もりの改善
タスクの実施
スプリントデモ
スプリント
バックログ
スプリント実施とフィードバックによる
継続的見積もり改善 +
ストーリー
ポイント合計
ストーリー
実施スプリントのバックログ
タスク
+
担当者
+予定作業時間
+ステータス
全てのタスク
スプリントタスク完了
リリース計画へ
のフィードバック
対象ストーリーは変えない
ステータス更新
タスクボード
未着手
→着手中
→完了
タスクの追加、
変更、削除
仕様化、レビュー、実装、テ
スト、不具合改修、データ作
成、環境構築、リリース、等
ストーリーストーリーストーリー
プロダクト
バックログ
• ストーリーの追加・削除・修正
• 各ストーリーポイント見直し
• 優先順位変更
任意の
タイミング
追加変更
要求
次のスプリント計画へ
ストーリー単位で完了/未完了を判断
未完了のストーリーは実績ストーリーポイントに含めない
実績ストーリー
ポイント
= ベロシティ
61. ©
2015
ZEN
ARCHITECTS
Co.,Ltd.
イテレーション5
イテレーション6
イテレーション7
・新たなストーリー
・優先順位の入替
・利用技術の見直し
・ストーリーの分割
継続的リリース計画
常時「見通し」を可視化
影響を反映
影響を反映
・・・
80. フロント開発チームリーダー
南 邦彦様(プロモーション企画Tリーダー)の視点
• 良かった点
• 現場の⼈人間がシステム開発に携わることができる。
思った以上にめっちゃ良い。
• 今までは、システム開発は⼀一部の⼈人だけで進めていた。
変えたくても変えられない「システムという制約」が
ビジネスを阻害していたと考えていたが、それは⾔言い訳だった。
• 思ったより⼤大変だった点
• その分、メンバー同⼠士の結束⼒力が求められる。
2週間ごとに、が⼤大変。
そして何より、理解してもらうことが⼤大変。
• トップの強い意向がないと、難しかったんじゃないかと思う。
• 改善点・慣れない点
• 中の⼦子にも「次に何をやるのか」を⾒見せてあげることが⼤大切。
たとえ後で変わるとしても。
• ⼯工数の考え⽅方が難しい。⼈人依存でやってみなければ出せないところ。
• まとまったシステムを作るときに「全部でいくら」が出しづらい。
「それで収まるの?根拠は?」と聞かれると困る。
• 受託だったら、スケジュールに合わせて尻を叩ける。
アジャイルは、「どうしてもやる」を詰め込みにくい。
サラッと「収まらない」と⾔言われると、無理をいいにくい。