CloudNative Days Spring 2021 ONLINEのDay1で発表した表題資料のスライドです https://event.cloudnativedays.jp/cndo2021/talks/231

1. エンタープライズ・インフラ構築・運用でも
DevOps を活用しよう
～チームを強くする DevOps ～
富岡 洋 ( @tomioka )
日本アイ・ビー・エム株式会社
グローバル・テクノロジー・サービス事業部
アドバイザリー・プロジェクト・マネージャー

2. 2 / 19
はじめに

3. このセッションについて
3 / 19
このセッションの
キーワード
• Enterprise IT
• IT Infrastructure
• DevOps
• Project Management
このセッションを
(特に)聴いて
もらいたい人
• エンタープライズのインフラ・システムに携わったことがある人／携わっている人
• DevOps という言葉を聞いたことがあるが、それが何かまでは知らない人
• DevOps という言葉を知っているが「自分には関係ない」と思っている人
難易度 • 入門レベル
必要な前提知識 • 特になし
セッション形式 • 資料投影プレゼンテーション ( 20~25 分程度 )

4. セッション概要
1. エンタープライズのインフラ構築・運用においても、ソースコードを中心にインフ
ラを管理することの重要性は日々高まっている
2. ソースコード中心の管理には、ベスト・プラクティスである DevOps の文化・プロ
セス・ツール群を活用することが重要である
3. DevOps は Dev（開発）と Ops（運用）の対立解消を目的に、情報共有を促進し、
相互理解・相互尊重に価値を置く概念である
4. エンタープライズのシステムでは、エンジニア系以外にも、非技術系のステークホ
ルダーが数多く存在する
5. DevOps はエンジニアだけでなく、非技術系のステークホルダーも巻き込んで活用
出来ると得られる価値がさらに増大し、チーム力の強化につながる
4 / 19

5. 氏名 : 富岡 洋 (TOMIOKA, Hiroshi)
所属 : 日本アイ・ビー・エム株式会社
グローバル・テクノロジー・サービス事業部
アドバイザリー・プロジェクト・マネージャー
仕事内容 : 下記プロジェクトの PM やアーキテクトを担当
• コールセンター向けの AI システム（主に音声認識技術）の導入
• 主に金融系のお客様向けのサーバー・システムの導入
SNS : Twitter :
LinkedIn :
Facebook :
Zenn :
@tomioka
@tomioka
@tomioka
@tomioka
セッション・スピーカー
5 / 19
このセッションの発表内容は私自身の見解であり、必ずしも IBM の立場、戦略、意見を代表するものではありません

6. 6 / 19
本編

7. DevOps とは何か
• DevOps に決まった定義はない
• 2009 年に写真共有サービス Flickr が行った『 10+ Deploys Per Day: Dev and Ops
Cooperation at Flickr 』という講演が DevOps という概念が生まれたきっかけ
• Dev (開発) と Ops (運用) は、「機能の追加」と「安定稼働」で利害対立
• しかし、会社として本当に大切なのは「ビジネスの成功」
• システムの安定稼働を維持しつつ、市場の変化に応じた機能追加を迅速に行うには？
• Flickr は「ツール」と「文化」の観点で対応
• 一般的に DevOps が語られる時は、「ツール」と「文化」、それらをつなぐ
「プロセス」のいずれか、もしくは全体について語られていることが多い
• DevOps の概念が普及するにつれて、多くのツールが登場し、利用されるように
なってきた
7 / 19

8. Flickr における DevOps
• 2009 年当時の Flickr は 6 つの「ツール」と 4 つの「文化」における対応を取った
• ツールによる対応
1. Automated infrastructure: Puppet など IaC ツールによるインフラ構築・構成の自動化
2. Shared version control: バージョン管理。みんなが「ここを見れば良い」と分かる
3. One step build and deploy: CI/CD 。「誰が、いつ、何を」変更したかが分かる
4. Feature flags: 機能フラグ。カナリア・リリースしやすく、問題があっても戻しやすい
5. Shared metrics: システム状態 ( CPU, Memory, Application ) をビジュアル化して共有
6. IRC and IM robots: チャットにログを集約し、Dev と Ops がログとデータを元に会話
• 文化による対応
1. Respect: 相手の知識・経験を尊重。何も聞かずに「 No 」と言わない
2. Trust: お互いが必要な存在と認め合う。権限を委ねることも
3. Healthy attitude about failure: 失敗は起こる前提で、普段から対応方法を訓練しておく
4. Avoiding blame: 相手を糾弾せず、常に建設的な態度を取る
• 同じ情報を Dev と Ops が共有して、相互理解・尊重することに価値を置いている
8 / 19

9. ペットから家畜へ
• 2012 年に CERN ( 欧州原子核研究機構 ) のエンジニアが『 CERN Data Center
Evolution 』という講演を実施
• 同じメンバー数で、複数データ・センターの 2 倍のサーバの管理が必要になった
• OpenStack によるプライベート IaaS と Puppet による構成管理で対応
• これからのシステムは、「ペット」ではなく「家畜」として扱うべきと主張
• 「ペット」と「家畜」とは？
• 「ペット」は、「はんぺん」や「オフィーリア」など名前が付けられ、手をかけて育
てられ、病気になれば必死に看病される
• 「家畜」は、識別番号が割り当てられ、大部分は機械で管理され、病気になったら処
分されて入れ替えられる
• 管理するサーバー数が増えるのであれば、手動管理ではなく、問題があるサーバー
を自動的に切り離して入れ替える、という家畜的管理手法が必要になる
9 / 19

10. コードによるインフラ管理の普及
• アプリ開発だけでなく、インフラ管理においても、コードを中心に管理を行うこと
が重要になっている
• Flickr と CERN の両方の事例に登場した Puppet を源流とする IaC ( Infrastructure as
Code ) は、利用範囲を広げてさらに普及 ( Miyashita. 2016 )
• AWS を始めとするパブリック・クラウドは API ( Application Program Interface ) に
よるリソース管理機能を初期から備えている
• YAML ファイルをベースにシステムの状態を宣言的に定義する Kubernetes は、
32.4% の企業が導入済みで、 25.6% が導入検討中 ( RedHat K.K.. 2020 )。
• コードを効率的に管理するには、ベスト・プラクティスである DevOps のツール、
プロセス、文化の活用が重要である
• 扱うインフラの性質が変わりつつある中で、 DevOps の活用はエンタープライズの
インフラ構築・運用においても不可避となった
10 / 19

11. DevOps プロセスとツールチェーン
• DevOps プロセスは、「要求管理・計画」→「開発・テスト」→「デプロイ」→
「運用」の流れで構成され、運用時のモニタリング & フィードバックのデータを
次の要求管理につなげて、継続的フィードバック・ループを回すことで成立する
• プロセスを支えるツールは相互に密接に結びつく「ツールチェーン」となり、要求
から本番システムまで一気通貫で管理することで本当の強みを発揮する
11 / 19
</>
要求管理 ソースコード管理 ビルド管理 継続的テスト 本番デプロイ モニタリングと
フィードバック
出典 : DevOps のための開発ツールチェーン (Doi, S & Yao, T. 2020. p.37) を元に筆者修正
DevOps プロセス

12. DevOps がもたらす価値
• DevOps のツールとプロセスが確立すると、変更作業によるオペレーション・
ミスの削減や変更履歴の正確な把握、効果的な作業割当などが実現できる
12 / 19
従来からある問題 DevOps が確立した場合
① 本番環境と設計
書の乖離
• 設計書が更新されておらず古いので、本番の構
成情報を確認し、本番を正として扱う
• 本番設定と設計書の差異の変更意図が不明（未
記録の理由があるのか、変更作業ミスか）
• ソース・コード管理システムのソースを常に正と
して扱う（自動デプロイで作業漏れを軽減）
• 要求管理システムで変更要求を管理し、ソース・
コードのコミット・ログと紐付けする
② 障害発生と変更
作業の追跡性
• 変更作業の実施日時・内容は担当者が個別に管
理しているので、担当者に聞かないと正確な変
更日時・内容が分からない
• 停止や性能低下と変更の時系列的な突き合わせ
調査が迅速に出来ない
• 自動デプロイ・ツールの実行履歴から、どの変更
がどの日時に実行されたかが即座に参照できる
• ソース・コード管理システムの変更差分から、機
能レベル、パラメータ・レベルで変更箇所を特定
出来、障害との原因切り分けが正確に実施できる
③ 作業割当、実施
状況の把握
• 週次の定例会などで作業を割り当てして、次週
の定例会で作業状況を確認する場合、次回の定
例会まで作業途中の進捗状況が見えにくく、作
業の負荷が偏ることも多い
• 対応履歴も Excel 管理表にまとめて残すが、記
録が不十分で読み返しても分からなくなる
• 要求管理システムに作業タスク（バックログ）が
一元管理され、実施中タスクは作業履歴を都度細
かく残して作業する
• 誰がどの作業を実施中・完了させたかが可視化で
き、手が空いている人は誰もやっていない作業を
自ら手を上げて実施できる

13. エンタープライズ環境における利害対立
• DevOps は、Dev (開発) と Ops (運用) の利害対立の解消のために生まれた概念
• 「文化」も「ツール」も両方が重要なのだが、実際は「文化」よりも「ツール」にば
かり人々の関心が集まってしまった ( Davis & Daniels, 2016 )
• エンタープライズの開発・運用の現場では、Dev と Ops などの技術者主体のロー
ル以外にも様々なステーク・ホルダーが登場する
• 例えば SIer のプロジェクト内外だけでも、別の利害対立が存在する
• 作業管理者 ( PM ) と作業実施者 : 進捗状況維持とワークライフ・バランスの確保
• 営業とプロジェクト・チーム : 新規提案や仕様変更の受入と実行責任の担保
• 情報を共有し、相互の置かれている立場や状況を理解・尊重し合う姿勢は「対立」
を「建設的な対話」に変化させられないか？
13 / 19

14. DevOps を技術者だけのものにしない
• DevOps ツールをコミュニケーション・ツールと見ると、「ネットワーク効果
（あるいはネットワーク外部性。ミクロ経済学用語）」に着目できる
• ネットワーク効果とは「『ユーザーにとって、他の多くの人が同じ製品・サービスを
使うほど、自身もそれを使う効用が高まる』特性」( Iriyama, 2020. p.5 )
• みんなが DevOps のプロセス・文化を理解し、ツールを使いこなせるようになると、
例えば「 JIRA のチケットに内容が書いてあるので見ておいてください」だけで話が
通じるようになる
• DevOps の話題では、CI/CD （継続的インテグレーション / 継続的デリバリー）の
導入事例発表が特に多く、分からない人にとっては「難しそうだし、DevOps は詳
しい技術者だけがやるものなんだな」という捉え方をされることもある
• 誤解されるとしたらもったいない。うまく使えるようになるとチーム力が強化できる
14 / 19

15. 何をやるべきか
• CI/CD ( ビルド→テスト→デプロイ ) の部分は実際に技術的で難しいが、システム環
境や扱うアプリの特性で組み合わせが変わることが多く、みんなが知るべき共通言
語にまでは至っていないように見える
• 要求管理システム ( JIRA ) やソースコード管理 ( GitHub ) のチケットやコミットロ
グは自然言語で書かれており、みんなが使い方を知るメリットは大きい
• 私も所属会社で DevOps の概念や Git, GitHub の使い方について一緒に勉強する会
を主催しています。DevOps に詳しい人は是非、周りの人に広めてみてください
15 / 19
</>
要求管理 ソースコード管理 ビルド管理 継続的テスト 本番デプロイ モニタリングと
フィードバック
出典 : DevOps のための開発ツールチェーン (Doi, S & Yao, T. 2020. p.37) を元に筆者修正

16. 16 / 19
まとめ

17. セッションのまとめ
1. エンタープライズのインフラ構築・運用においても、ソースコードを中心にインフ
ラを管理することの重要性は日々高まっている
2. ソースコード中心の管理には、ベスト・プラクティスである DevOps の文化・プロ
セス・ツール群を活用することが重要である
3. DevOps は Dev（開発）と Ops（運用）の対立解消を目的に、情報共有を促進し、
相互理解・相互尊重に価値を置く概念である
4. エンタープライズのシステムでは、エンジニア系以外にも、非技術系のステークホ
ルダーが数多く存在する
5. DevOps はエンジニアだけでなく、非技術系のステークホルダーも巻き込んで活用
出来ると得られる価値がさらに増大し、チーム力の強化につながる
17 / 19

18. 参考文献
• Allspaw, J & Hammond P. (2009). 10 Deploys Per Day: Dev and Ops Cooperation at Flickr. SlideShare. Retrieved
from https://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr
• McCance, G. (2012). CERN Data Centre Evolution. SlideShare. Retrieved from
https://www.slideshare.net/gmccance/cern-data-centre-evolution
• Davis, J & Daniels, R. (2016). Effective DevOps: Building a Culture of Collaboration, Affinity, and Tooling at Scale.
O’Reilly Media, Inc.
• Miyashita, G. (2016). Infrastructure as Code 再考. mizzy.org. Retrieved from
https://mizzy.org/blog/2016/04/22/1/
• Red Hat K.K.. (2020). 日本のコンテナ市場 2020 調査レポート. ITmedia White Paper Download Center.
Retrieved from https://wp.techtarget.itmedia.co.jp/contents/48880
• Doi, S & Yao, T. (2020). アプリケーションのライフサイクル全体を支えるOSSとその動向. ProVISION No.96.
Retrieved from https://www.ibm.com/blogs/pro-vision/no-96/
• Iriyama, A. (2020). 「ポーターの競争戦略」を理解すればフェイスブックの強さがわかる. ダイヤモンド・オンラ
イン. Retrieved from https://diamond.jp/articles/-/225823
18 / 19

19. 19 / 19
この後も引き続き
をお楽しみ下さい！