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

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

グロースエクスパートナーズ（株）　ITアーキテクト和智　右桂

IT Architect Conference2013

Thursday, December 12, 13

和智　右桂

JavaEE勉強会所属

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

Yukei Wachi

@digitalsoul0124Digital Romanticism

http://d.hatena.ne.jp/digitalsoul

ネコ好き

Photo by @digitalsoul0124 All rights reserved.

IT アーキテクト



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

アジェンダ

Photo by @digitalsoul0124 All rights reserved.

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


「攻めのIT」とは


攻めないIT

仕様

ソフトウェア顧客開発者


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


マインドの問題

スクラムだから違う、ということでもない

“バックログをちゃんと作ってくれれば、ちゃんと実装しますよ”


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

攻めのマインドとは


http://www.flickr.com/photos/turtlemom_nancy/1914397629/


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


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


攻めのIT

顧客開発者

運用担当エンドユーザー

企画

競合他社ステークホルダーの増加


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


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



ところでDevOpsって？




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

DevOpsとは


開発と運用との間の壁

http://dev2ops.org/2010/02/what-is-devops/

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




DevOpsによる解決•計測と評価による変化を重んじる文化の醸成•開発-運用のライフサイクルをエンドツーエンドのプロセスに•バージョンコントロールや自動化のためのツール

http://dev2ops.org/2010/02/what-is-devops/Thursday, December 12, 13



DevOpsの位置づけ

Biz Dev Ops

Agile DevOps

ビジネスプロセス



具体的にどうしたら？




開発-運用のプロセス作りThursday, December 12, 13

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

2. 効率化 / 自動化


継続的デリバリーの概要

顧客開発者

運用担当

リポジトリ課題管理

CIサーバ

テスト環境

本番環境エンドユーザーThursday, December 12, 13

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


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

開発者運用担当エンドユーザーThursday, December 12, 13

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


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

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


http://www.flickr.com/photos/foolstopzanet/334203826/in/photolist-vwT9W-y9q6S-y9q7N-ygp5N-yhZRA-NgoMf-NgoMh-38FiH8-3L4LSd-4aKZEG-4g5nf1-4mAVUP-4pYszd-4tdwDb-4A1PuB-4WrjBL-4ZMwqa-53pYsJ-53pYWj-57jDbB-5hMixn-5Cd16J-5MMc9V-5PfpUa-5PftP2-5PfwwR-5U5k8A-5U5kqA-62giEW-6aPfGt-6dZsxK-6e4BNU-6go3q5-6go4Hq-6oUuwC-6oUuWj-6oUv6J-6He8Yr-6M6bGv-6QGsb9-79W8DU-7s4A8L-7w1PQV-7w1Qrn-7w1Ra8-7whrVo-8UHR7a-8UHQMD-8ULTMA-8ULTSU-8C2gEe/

http://www.flickr.com/photos/foolstopzanet/334203826/in/photolist-vwT9W-y9q6S-y9q7N-ygp5N-yhZRA-NgoMf-NgoMh-38FiH8-3L4LSd-4aKZEG-4g5nf1-4mAVUP-4pYszd-4tdwDb-4A1PuB-4WrjBL-4ZMwqa-53pYsJ-53pYWj-57jDbB-5hMixn-5Cd16J-5MMc9V-5PfpUa-5PftP2-5PfwwR-5U5k8A-5U5kqA-62giEW-6aPfGt-6dZsxK-6e4BNU-6go3q5-6go4Hq-6oUuwC-6oUuWj-6oUv6J-6He8Yr-6M6bGv-6QGsb9-79W8DU-7s4A8L-7w1PQV-7w1Qrn-7w1Ra8-7whrVo-8UHR7a-8UHQMD-8ULTMA-8ULTSU-8C2gEe/

http://www.flickr.com/photos/foolstopzanet/334203826

http://www.flickr.com/photos/foolstopzanet/334203826

•「イテレーティブ」と「インクリメンタル」•「イテレーティブ」はプロセス•「インクリメンタル」はアーキテクチャ

•アーキテクチャのないイテレーションは崩壊のプロセス

攻めのITのために


アーキテクチャの役割•変化することを前提とした上で変化の方向性を予め決定づける•アーキテクチャの策定とは、変わるものと変わらないものを事前に決定する行為

•要素技術よりも、ドメインや組織への考慮が重要



具体的にどうしたら？




どう境界を定め、どう構成するか•コンウェイの法則•大局的構造•モデル駆動設計

アーキテクチャ策定の指針


前提相対的にアーキテクチャの重要度が低いシステム•小規模•少人数•スタンドアロン

小回りが利かないときにどうするかThursday, December 12, 13

コンウェイの法則とは

“組織のアーキテクチャはプロダクトのアーキテクチャと揃えておかなければならない”


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

顧客管理販売管理在庫管理

パッケージ採用時には注意が必要Thursday, December 12, 13

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

個別モジュール

個別モジュール個別モジュール

汎用モジュール

職人開発者

開発者開発者Thursday, December 12, 13

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


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


機能追加のコスト

ロジックの複雑度

トランザクションスクリプト

ドメインモデル

ドメインモデルの損益分岐点

-PoEAAよりThursday, December 12, 13

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


まとめ


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


ありがとうございました！Photo by @digitalsoul0124 All rights reserved.


Technology

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