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

IT Architect Conference

2013

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

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.


アジェンダ

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

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

「攻めのIT」とは


攻めないIT
仕様

顧客


ソフトウェア

開発者

虎を追い出してくれたら
見事捕まえてみせます！


スクラム

だから違う、

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

マインドの問題

攻めのマインドとは

3D Character and Question Mark http://www.ﬂickr.com/photos/crystaljingsr/3914729343/ by 姒儿喵喵

一緒に虎を追いかけましょう


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

攻めのIT
企画

顧客

エンドユーザー

開発者

運用担当

競合他社

ステークホルダーの増加

...戦場が広がった
新しい戦略が必要だ


DevOpsのための
継続的デリバリー


ところでDevOpsって？


DevOpsとは

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

開発と運用との間の壁

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

DevOpsによる解決

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

DevOpsの位置づけ
ビジネスプロセス

Biz

Dev

Agile

Ops

DevOps

具体的にどうしたら？


開発-運用のプロセス作り

継続的デリバリー
1. 顧客からの依頼がソフトウェアに
なって戻っていくプロセス（バ
リューストリーム）のモデル化
2. 効率化 / 自動化


継続的デリバリーの概要

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

テスト環境
CIサーバ

本番環境エンドユーザー

実装のポイント

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

継続的デリバリーの意義

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

開発者

運用担当

エンドユーザー

幸せな運用のための
アーキテクチャ


アーキテクチャは後から現れる？

Jenga Nat http://www.ﬂickr.com/photos/foolstopzanet/334203826 by Ian Willson

攻めのITのために

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

アーキテクチャの役割

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

アーキテクチャ策定の指針
どう境界を定め、どう構成するか
• コンウェイの法則
• 大局的構造
• モデル駆動設計


前提
相対的にアーキテクチャの重要度が
低いシステム
• 小規模
• 少人数
• スタンドアロン
小回りが利かないときにどうするか

コンウェイの法則とは
組織のアーキテクチャはプロダク
トのアーキテクチャと揃えておかな
ければならない


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

顧客管理

販売管理
在庫管理

パッケージ採用時には注意が必要

コンウェイの法則の適用例②
内部構造の境界がチームの境界に
汎用モジュール

個別モジュール

開発者

職人



開発者

開発者

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


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


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

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

ロジックの複雑度

-PoEAAより

業務に寄り添って進化する
ソフトウェアの形を見極める


まとめ


まとめ
• もはや「言われたものを作る」だ
けにはとどまれない。
• そのためにはエンドツーエンドの
プロセスと、
• 進化を許容するアーキテクチャが
必要である。

ありがとうございました！

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

Related slideshows

More Related Content

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