Your SlideShare is downloading. ×
0
IT Architect Conference

2013

「攻めのIT」を実現する
アーキテクチャとDevOpsの関係
グロースエクスパートナーズ(株)
 ITアーキテクト 和智 右桂
Thursday, December 12, 13
JavaEE勉強会 所属

Yukei Wachi

グロースエクスパートナーズ株式会社 勤務
http://www.gxp.co.jp/index.html

和智 右桂
ネコ好き

IT アーキテクト
@digitalsoul0124
Di...
Thursday, December 12, 13
アジェンダ

•
•DevOpsのための継続的デリバリー
•幸せな運用のためのアーキテクチャ
まとめ
•
「攻めのIT」とは?

スライド中で使用されている画像について、
その著作権の全部または一部は、 クレジットに示した著者によって保留されて...
「攻めのIT」とは

Thursday, December 12, 13
攻めないIT
仕様

顧客

Thursday, December 12, 13

ソフトウェア

開発者
虎を追い出してくれたら
見事 捕まえてみせます!

Thursday, December 12, 13
スクラム

だから違う、

ということでもない
バックログを
ちゃんと作ってくれれば、
ちゃんと実装しますよ

マインドの問題
Thursday, December 12, 13
攻めのマインドとは

3D Character and Question Mark http://www.flickr.com/photos/crystaljingsr/3914729343/ by 姒儿喵喵
Thursday, December...
一緒に虎を追いかけましょう

Thursday, December 12, 13
虎は顧客の向こうに
•経営方針
•組織構造(運用、企画 etc)
•ビジネスモデル
•エンドユーザー
•競合他社
「業務」という言葉の重み
Thursday, December 12, 13
攻めのIT
企画

顧客

エンドユーザー

開発者

運用担当

競合他社

ステークホルダーの増加
Thursday, December 12, 13
...戦場が広がった
新しい戦略が必要だ

Thursday, December 12, 13
DevOpsのための
継続的デリバリー

Thursday, December 12, 13
ところでDevOpsって?

3D Character and Question Mark http://www.flickr.com/photos/crystaljingsr/3914729343/ by 姒儿喵喵
Thursday, Dece...
DevOpsとは

• 「開発(Development)の活動
と運用(Operations)の活動と
の間に壁がある」という問題意
識への反応
• 「変化を重んじる文化 / プロセ
スの統合 / ツールの統合」によ
る解決
Thursday,...
開発と運用との間の壁

• 志向 / プロセス / ツールの違いに
より生み出される
• 変化 vs 安定
• 開発から運用にソフトウェアが
投げ渡される
• 開発と運用でツールが異なる
http://dev2ops.org/2010/02/w...
DevOpsによる解決

• 計測と評価による変化を重んじる
文化の醸成
• 開発-運用のライフサイクルをエ
ンドツーエンドのプロセスに
• バージョンコントロールや自動化
のためのツール
http://dev2ops.org/2010/02/...
DevOpsの位置づけ
ビジネスプロセス

Biz

Dev

Agile
Thursday, December 12, 13

Ops

DevOps
具体的にどうしたら?

3D Character and Question Mark http://www.flickr.com/photos/crystaljingsr/3914729343/ by 姒儿喵喵
Thursday, Decembe...
開発-運用のプロセス作り
Thursday, December 12, 13
継続的デリバリー
1. 顧客からの依頼がソフトウェアに
なって戻っていくプロセス(バ
リューストリーム)のモデル化
2. 効率化 / 自動化

Thursday, December 12, 13
継続的デリバリーの概要

運用担当
リポジトリ
顧客
課題管理
開発者

テスト環境
CIサーバ

本番環境 エンドユーザー
Thursday, December 12, 13
実装のポイント

• 要件と実装との間のトレーサビリ
ティの確保
• メールは基本アンチパターン
• 開発-運用共通の構成管理基盤
• 統一的なリリースプロセスの確立
• 同じ場所から同じようにビルド
して同じようにリリースする
Thursda...
継続的デリバリーの意義

• 継続的インテグレーションまでは
開発のためのプラクティス
• デリバリーまで含めて初めて、
フィードバックループが回る

開発者
Thursday, December 12, 13

運用担当

エンドユーザー
幸せな運用のための
アーキテクチャ

Thursday, December 12, 13
アーキテクチャは後から現れる?

Jenga Nat http://www.flickr.com/photos/foolstopzanet/334203826 by Ian Willson
Thursday, December 12, 13
攻めのITのために

• 「イテレーティブ」と「インクリ
メンタル」
• 「イテレーティブ」はプロセス
• 「インクリメンタル」はアーキ
テクチャ
• アーキテクチャのないイテレー
ションは崩壊のプロセス
Thursday, December ...
アーキテクチャの役割

• 変化することを前提とした上で変
化の方向性を予め決定づける
• アーキテクチャの策定とは、変
わるものと変わらないものを事
前に決定する行為
• 要素技術よりも、ドメインや組織
への考慮が重要
Thursday, D...
具体的にどうしたら?

3D Character and Question Mark http://www.flickr.com/photos/crystaljingsr/3914729343/ by 姒儿喵喵
Thursday, Decembe...
アーキテクチャ策定の指針
どう境界を定め、どう構成するか
• コンウェイの法則
• 大局的構造
• モデル駆動設計

Thursday, December 12, 13
前提
相対的にアーキテクチャの重要度が
低いシステム
• 小規模
• 少人数
• スタンドアロン
小回りが利かないときにどうするか
Thursday, December 12, 13
コンウェイの法則とは
組織のアーキテクチャはプロダク
トのアーキテクチャと揃えておかな
ければならない

Thursday, December 12, 13
コンウェイの法則の適用例①
システムの境界が組織の境界となる

顧客管理

販売管理
在庫管理

パッケージ採用時には注意が必要
Thursday, December 12, 13
コンウェイの法則の適用例②
内部構造の境界がチームの境界に
汎用モジュール

個別モジュール

開発者
Thursday, December 12, 13

職人

個別モジュール

個別モジュール

開発者

開発者
大局的構造とは
システム間統合の方式設計は、
コミュニケーション形態に合わせる
•密結合して良いケース
•中間層を立てないと危険なケース

Thursday, December 12, 13
モデル駆動設計とは
ドメインモデルを反映してソフト
ウェアを作る
•変化に柔軟に適用できるが高コスト

Thursday, December 12, 13
ドメインモデルの損益分岐点
トランザクションスクリプト

機能追加の
コスト
ドメインモデル

ロジックの複雑度

-PoEAAより
Thursday, December 12, 13
業務に寄り添って進化する
ソフトウェアの形を見極める

Thursday, December 12, 13
まとめ

Thursday, December 12, 13
まとめ
• もはや「言われたものを作る」だ
けにはとどまれない。
• そのためにはエンドツーエンドの
プロセスと、
• 進化を許容するアーキテクチャが
必要である。
Thursday, December 12, 13
ありがとうございました!
Photo by @digitalsoul0124 All rights reserved.
Thursday, December 12, 13
Upcoming SlideShare
Loading in...5
×

「攻めのIt」を実現するアーキテクチャーとdev opsの関係

1,136

Published on

日経BP社様主催
IT アーキテクトカンファレンス2013 の講演原稿です
http://coin.nikkeibp.co.jp/coin/itpro-s/seminar/sys/131202/

Published in: Technology

Transcript of "「攻めのIt」を実現するアーキテクチャーとdev opsの関係"

  1. 1. IT Architect Conference 2013 「攻めのIT」を実現する アーキテクチャとDevOpsの関係 グロースエクスパートナーズ(株)  ITアーキテクト 和智 右桂 Thursday, December 12, 13
  2. 2. JavaEE勉強会 所属 Yukei Wachi グロースエクスパートナーズ株式会社 勤務 http://www.gxp.co.jp/index.html 和智 右桂 ネコ好き IT アーキテクト @digitalsoul0124 Digital Romanticism http://d.hatena.ne.jp/digitalsoul Photo by @digitalsoul0124 All rights reserved. Thursday, December 12, 13
  3. 3. Thursday, December 12, 13
  4. 4. アジェンダ • •DevOpsのための継続的デリバリー •幸せな運用のためのアーキテクチャ まとめ • 「攻めのIT」とは? スライド中で使用されている画像について、 その著作権の全部または一部は、 クレジットに示した著者によって保留されています。 Photo by @digitalsoul0124 All rights reserved. Thursday, December 12, 13
  5. 5. 「攻めのIT」とは Thursday, December 12, 13
  6. 6. 攻めないIT 仕様 顧客 Thursday, December 12, 13 ソフトウェア 開発者
  7. 7. 虎を追い出してくれたら 見事 捕まえてみせます! Thursday, December 12, 13
  8. 8. スクラム だから違う、 ということでもない バックログを ちゃんと作ってくれれば、 ちゃんと実装しますよ マインドの問題 Thursday, December 12, 13
  9. 9. 攻めのマインドとは 3D Character and Question Mark http://www.flickr.com/photos/crystaljingsr/3914729343/ by 姒儿喵喵 Thursday, December 12, 13
  10. 10. 一緒に虎を追いかけましょう Thursday, December 12, 13
  11. 11. 虎は顧客の向こうに •経営方針 •組織構造(運用、企画 etc) •ビジネスモデル •エンドユーザー •競合他社 「業務」という言葉の重み Thursday, December 12, 13
  12. 12. 攻めのIT 企画 顧客 エンドユーザー 開発者 運用担当 競合他社 ステークホルダーの増加 Thursday, December 12, 13
  13. 13. ...戦場が広がった 新しい戦略が必要だ Thursday, December 12, 13
  14. 14. DevOpsのための 継続的デリバリー Thursday, December 12, 13
  15. 15. ところでDevOpsって? 3D Character and Question Mark http://www.flickr.com/photos/crystaljingsr/3914729343/ by 姒儿喵喵 Thursday, December 12, 13
  16. 16. DevOpsとは • 「開発(Development)の活動 と運用(Operations)の活動と の間に壁がある」という問題意 識への反応 • 「変化を重んじる文化 / プロセ スの統合 / ツールの統合」によ る解決 Thursday, December 12, 13
  17. 17. 開発と運用との間の壁 • 志向 / プロセス / ツールの違いに より生み出される • 変化 vs 安定 • 開発から運用にソフトウェアが 投げ渡される • 開発と運用でツールが異なる http://dev2ops.org/2010/02/what-is-devops/ Thursday, December 12, 13
  18. 18. DevOpsによる解決 • 計測と評価による変化を重んじる 文化の醸成 • 開発-運用のライフサイクルをエ ンドツーエンドのプロセスに • バージョンコントロールや自動化 のためのツール http://dev2ops.org/2010/02/what-is-devops/ Thursday, December 12, 13
  19. 19. DevOpsの位置づけ ビジネスプロセス Biz Dev Agile Thursday, December 12, 13 Ops DevOps
  20. 20. 具体的にどうしたら? 3D Character and Question Mark http://www.flickr.com/photos/crystaljingsr/3914729343/ by 姒儿喵喵 Thursday, December 12, 13
  21. 21. 開発-運用のプロセス作り Thursday, December 12, 13
  22. 22. 継続的デリバリー 1. 顧客からの依頼がソフトウェアに なって戻っていくプロセス(バ リューストリーム)のモデル化 2. 効率化 / 自動化 Thursday, December 12, 13
  23. 23. 継続的デリバリーの概要 運用担当 リポジトリ 顧客 課題管理 開発者 テスト環境 CIサーバ 本番環境 エンドユーザー Thursday, December 12, 13
  24. 24. 実装のポイント • 要件と実装との間のトレーサビリ ティの確保 • メールは基本アンチパターン • 開発-運用共通の構成管理基盤 • 統一的なリリースプロセスの確立 • 同じ場所から同じようにビルド して同じようにリリースする Thursday, December 12, 13
  25. 25. 継続的デリバリーの意義 • 継続的インテグレーションまでは 開発のためのプラクティス • デリバリーまで含めて初めて、 フィードバックループが回る 開発者 Thursday, December 12, 13 運用担当 エンドユーザー
  26. 26. 幸せな運用のための アーキテクチャ Thursday, December 12, 13
  27. 27. アーキテクチャは後から現れる? Jenga Nat http://www.flickr.com/photos/foolstopzanet/334203826 by Ian Willson Thursday, December 12, 13
  28. 28. 攻めのITのために • 「イテレーティブ」と「インクリ メンタル」 • 「イテレーティブ」はプロセス • 「インクリメンタル」はアーキ テクチャ • アーキテクチャのないイテレー ションは崩壊のプロセス Thursday, December 12, 13
  29. 29. アーキテクチャの役割 • 変化することを前提とした上で変 化の方向性を予め決定づける • アーキテクチャの策定とは、変 わるものと変わらないものを事 前に決定する行為 • 要素技術よりも、ドメインや組織 への考慮が重要 Thursday, December 12, 13
  30. 30. 具体的にどうしたら? 3D Character and Question Mark http://www.flickr.com/photos/crystaljingsr/3914729343/ by 姒儿喵喵 Thursday, December 12, 13
  31. 31. アーキテクチャ策定の指針 どう境界を定め、どう構成するか • コンウェイの法則 • 大局的構造 • モデル駆動設計 Thursday, December 12, 13
  32. 32. 前提 相対的にアーキテクチャの重要度が 低いシステム • 小規模 • 少人数 • スタンドアロン 小回りが利かないときにどうするか Thursday, December 12, 13
  33. 33. コンウェイの法則とは 組織のアーキテクチャはプロダク トのアーキテクチャと揃えておかな ければならない Thursday, December 12, 13
  34. 34. コンウェイの法則の適用例① システムの境界が組織の境界となる 顧客管理 販売管理 在庫管理 パッケージ採用時には注意が必要 Thursday, December 12, 13
  35. 35. コンウェイの法則の適用例② 内部構造の境界がチームの境界に 汎用モジュール 個別モジュール 開発者 Thursday, December 12, 13 職人 個別モジュール 個別モジュール 開発者 開発者
  36. 36. 大局的構造とは システム間統合の方式設計は、 コミュニケーション形態に合わせる •密結合して良いケース •中間層を立てないと危険なケース Thursday, December 12, 13
  37. 37. モデル駆動設計とは ドメインモデルを反映してソフト ウェアを作る •変化に柔軟に適用できるが高コスト Thursday, December 12, 13
  38. 38. ドメインモデルの損益分岐点 トランザクションスクリプト 機能追加の コスト ドメインモデル ロジックの複雑度 -PoEAAより Thursday, December 12, 13
  39. 39. 業務に寄り添って進化する ソフトウェアの形を見極める Thursday, December 12, 13
  40. 40. まとめ Thursday, December 12, 13
  41. 41. まとめ • もはや「言われたものを作る」だ けにはとどまれない。 • そのためにはエンドツーエンドの プロセスと、 • 進化を許容するアーキテクチャが 必要である。 Thursday, December 12, 13
  42. 42. ありがとうございました! Photo by @digitalsoul0124 All rights reserved. Thursday, December 12, 13
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×