DevOps導入＆実践の落とし穴 ディシプリンドDevOpsに見る 体 … · 2016-10-20 ·...
20
DevOps導入＆実践の落とし穴 -ディシプリンドDevOpsに見る 体系的アプローチ 日本ヒューレット・パッカード株式会社 ソフトウェア事業統括 藤井 智弘
Transcript of DevOps導入＆実践の落とし穴 ディシプリンドDevOpsに見る 体 … · 2016-10-20 ·...
DevOps導入＆実践の落とし穴-ディシプリンドDevOpsに見る
体系的アプローチ
日本ヒューレット・パッカード株式会社ソフトウェア事業統括
藤井 智弘
アジェンダ
❑なぜDevOpsが”腹落ちしない”のか
❑DevOps･･･の前に、DADの基礎
❑ディシプリンドDevOpsの導入アプローチ
専門化が進んだIT要員 専門性を高めることに注力俯瞰的に全体を見ている人はほとんどいない
アジャイリストは、継続的デリバリーにフォーカスする アジャイルやリーンからの延長として、継続的デリバリーの実現に注力
運用の専門家はフラストレーションを抱えている 多種多様な環境の管理に忙殺ヘビーな運用プロセス（ITIL、ITSM）
ツールベンダーのオファリングには制限がある ツールラインナップがDevOpsの定義を決める
サービスベンダーのオファリングには制限がある 提供出来るモノ＝DevOps
ツールベンダーはDevOpsをマーケティングのバズワードとして扱う
既存の寄せ集めマーケティングツール
”クラウドこそDevOps”というビジョン決めつけ 前提条件であるかのような決めつけ
http://www.disciplinedagiledelivery.jp/disciplineddevops/
「共通定義が難しい理由」
･･･そして日本では･･･
強いベンダー依存実は言うほど高くない専門性そもそもお互いの業務を知らない異なる体制外注主体持ち帰り開発etc）
”しきたり”駆動「いままで～だったから」コスト＜キャッシュアウト
アジェンダ
❑なぜDevOpsが”腹落ちしない”のか
❑DevOps･･･の前に、DADの基礎
❑ディシプリンドDevOpsの導入アプローチ
DADの歩み1ディシプリンド・アジャイル・デリバリー 0.x
本フレームワークの起源は、IBM Rationalで2009年の始めから2012年6月にかけて開発された。 IBMチームは、ビジネスパートナーと密に協力してきたが、その中にMark Linesが参加し、Scott Amblerがリードしてきた。IBM Rational Method Composer(RMC)は、DADフレームワークの早期バージョン（バージョン0.5）をサポートしている。
2ディシプリンド・アジャイル・デリバリー 1.x 2012年6月の最初のDAD本”ディシプリンド・アジャイル・デリバリー”出版を以て、DAD1.0のリリースとしている。DADフレームワークの進化と公開は今ご覧のサイト上で2012年の8月から始まっている。DADフレームワークの知的財産は、Disciplined Agile Consortiumへ2012年10月に引き渡され、2014年6月IBMにより法的に確認された。
3ディシプリンド・アジャイル・デリバリー 2.ｘ これが現在のバージョンである。最初のリリースは2015年8月に行われた。前述したように、フォーカスはITプロセスへの柔軟でコンテキストに応じたアプローチへと進化している。
Coming Soon！
“The Big Book”
DADの（乱暴な）基礎
多様な利害関係者との合意形成とガバナンスエンタープライズ対応(aware) ：既存のアセット、ルールの尊重と活用ゴール駆動
©ScottAmbler+Associates
ゴール駆動アプローチ
プロセスゴール課題
プロセスファクター
有利な点不利な点考慮すべき事項
* オプションオプション（デフォルト）
*
初期チームの編成
ソースチームサイズチーム構造チームメンバー地理的な配置チームへのサポート体制可用性
同一拠点一部のメンバーが別拠点完全に分散サブチーム単位で分散
※本来はイタリック
有効度合いでの優先順位
ゴール駆動アプローチ
ゴール駆動アプローチ
ディシプリンドDevOpsのプロセス領域
アジェンダ
❑なぜDevOpsが”腹落ちしない”のか
❑DevOps･･･の前に、DADの基礎
❑ディシプリンドDevOpsの導入アプローチ
DevOps導入におけるDAの位置付けソリューションデリバリーでの意思決定フレームワークとして
• 開発チームを主軸として
• DevOps化以前にアジャイル化
• DAD1.x相当のフレームワーク
DevOps導入自体における意思決定フレームワークとして
• IT組織全体での意思決定フレームワークとして
ゴール図は、各専門領域で検討すべき事柄のカタログと、 ある時点での対応状況（=カバレッジ）把握のベースとなる。
第2期
第3期
第1期
第1期
第2期
第3期
DAのライフサイクルは、ロードマップ検討とそれに基づく導入スコープのベースとなる。
ここから先は、配布無しで
まとめ
• ”開発と運用との文化の差”･･･以前の文化の差があるよね
• アリモノは、使い倒す。
• DADのアプローチは、2つの点で有効
• ゴール駆動は、部門共同のイニシアティブとして共通の俯瞰な視点を提供する。
• フェーズによるガバナンスは、フィードバックに基づく実践的な導入アプローチを採ることが出来る。
Links本家
http://www.disciplinedagiledelivery.com
コンソーシアムhttp://www.disciplinedagileconsortium.org
分家http://disciplinedagiledelivery.jp
（分家の中） Discipline Agile DevOps（連載）http://disciplinedagiledelivery.jp/tag/devops/・ディシプリンドDevOpsを定義する・概論・開発・チーム編成戦略・災害対策・運用・サポート・リリース管理その１・リリース管理その２・データ管理・エンタープライズ・アーキテクチャ
ありがとうございました
