SAAJ近畿支部第156回定例研究会報告(ISACA大阪支部合同) (報告者: 植垣 雅則)

会員番号1380 植垣 雅則

1.テーマ   「DevOpsの基礎」 ビジネス駆動なムーブメントによる戦略的なIT
2.講師    アトラシアン株式会社
           シニアエバンジェリスト 長沢 智治(ながさわ ともはる)氏
3.開催日時  2015年12月19日(土) 15:00~17:00
4.開催場所  大阪大学中之島センター 3階 講義室304

5.講演概要

「 DevOpsの基礎」

saajk20151219ビジネス目標を達成するためには、ITのチカラが不可欠な分野が増えてきている。クラウドや、IoT などのテクノロジーの進化と開発プロセスの知見の集約により、今まで以上にビジネスに寄り添ったソフトウェア開発、運用が求められている。このような時代背景のもとに生まれたのがDevOps であり、その基礎となる事項について、講演いただいた。

<講演内容>

(ア) 用語の定義

DevOps :DevelopmentとOperationsを合わせた言葉である。言葉の明確な定義がない。DevOpsという単語は2009年のオライリー主催のイベント「Velocity 2009」において、Flickrのエンジニアにより初めて公の場で用いられた。似たような用語として「アジャイル」があり、こちらはマニフェストと原則が定義されている。

(イ) ビジネスと戦略的なITの必要性

DevOpsはビジネスとITの関係が変遷してきた中で生まれた用語・概念であり、その時代の流れ・特徴について説明する。
時代ごとのビジネスの特徴として10年単位で考えると、「199x:ITによる効率化、コスト削減」「200x:ウェブ化、Eコマースなどの新たなサービスの出現」「201x:ビジネスとITが融合」のように整理される。
これに合わせて、以下に示すようにビジネスとITの構成要素の特徴も変化してきている。
ビジネスモデルの特徴 :確立しやすい ⇒ 確立しづらい
意思決定者の特徴   :IT部門 ⇒ 経営者層 ⇒ マーケット/消費者
技術と配布の特徴    :クライアント/サーバー ⇒ WEB/アプリ ⇒ IOT/デバイスとクラウド
ビジネスとITの関係を示す特徴を3つにまとめると、「ITがビジネスに学習機会を提供」、「市場の変化と競争の激化」、「継続的なIT投資とデリバリー」となる。

(ウ) ビジネス駆動ムーブメント

次に、DevOpsの特徴である「ビジネス駆動ムーブメント」について説明する。
ビジネスとITの関係を考える上で、ビジネスチーム、開発チーム、運用チームの3チームを考える。
まず1段階目では、ビジネスチームが主となるビジネス目標がある(例:売り上げ/利益率、ユーザー数、生産性/稼働率)。一方、開発チームには継続的な価値提供、運用チームには安定稼動といった目標があるが、3つのチームの目標は独立しており、融合していない。
2段階目になると、開発チームと運用チームが一体となり、それぞれのチーム目標とともに、両チーム共通の目標としてサイクルタイムや平均復旧時間(MTTR))などのシステム目標が定められることになる。
3段階目になると、ビジネスチームも加わって3つのチームが一体となり、ビジネス目標を実現するために協調して活動する状態になる。これにより、以下のサイクルで示されるリーンスタートアップが可能になる。
アイデア→(BUILD:構築)→プロダクト→(MEASURE:測定)→データ→(LEARN:学習)→アイデア
リーンスタートアップはビジネス開発手法の一種であり、ビジネスのアイデアをもとに小さく繰り返すことによりビジネス目標を実現させるものである。ITを利用するビジネスではデプロイ(開発したソースコードを運用環境に展開すること)を繰り返すことになるなか、「1日に10回以上のデプロイを実現した」との事例発表があり、その実現手法が「DevOps」とされた。
DevOpsの事例で1日に数百回のデプロイを実施したなどの説明もあるが、決してデプロイの回数を増やすことが目的ではない。ITがビジネスの推進を阻害することになってはいけない訳で、ビジネス要求をシームレスにITに反映することが大事であり、そのためのITの開発と運用との協調がポイントである。ITの開発・運用が協調することによりビジネスのスピードに追いつくことが目標である。

(エ) DevOpsの特徴

次に、DevOpsの具体的な特徴について、3つのキーワード「定期的なリズム」「継続的○○」「共同所有」をもとに説明する。

【定期的なリズム】 反復的な開発とデプロイ(サイクルタイム・MTTR)

開発のプロセスは、定義済みのプロセス(ウォーターフォール)と経験則によるプロセス(アジャイル)に大別される。定義済みのプロセスでは、失敗が許されない、軌道修正がしづらいといった特徴、経験則によるプロセスでは、早めに失敗できる、軌道修正を前提とするといった特徴がある。
DevOpsとアジャイルは同義ではないが、「反復的な開発を行い、期間を固定(タイムボックス)し、定期的に計画とやり方を見直す」との経験則によるプロセスはDevOpsと相性がよい。

【継続的○○】 常時結合 常時デプロイ 常時検証 常時監査

開発と運用の協調としては、「バックログの精査」「テスト駆動開発」「常時結合」などの主に開発に関係する要素と、「常時デプロイ」「常時検証」「常時監査」などの開発・運用に共通する要素がある。これらの要素を効果的効率的に実現するには、早い段階からのアプローチ、ライフサイクルを通したアプローチが必要である。

【共同所有】 コード化と自動テスト 共同所有の包括的な拡大

開発と運用の協調を実現する上では、コードを共有することも効果的である。クラウドや仮想化などのITの進歩により、運用インフラをコードで記述することも可能になっている。開発チームがソースコード、テストコードを所有、運用チームがテストコードを所有するといった共同所有体制をとることにより、開発から運用までの効率化迅速化が実現可能となる。

(オ) DevOpsに関するその他の考察

DevOpsの実現にクラウドは有用であり、調達ボトルネックの解消などのメリットがある。一方で、「壊れることを前提とする」必要があるなど、特有の考慮点があることには注意が必要である。
DevOpsを生かせるかは、その組織の文化にも関係する。振る舞い、集合知、改善などDevOpsに関係する要素の程度によって影響を受けることになる。
監査の位置付けを考察すると、DevOpsは新しい概念であり、実際の現場においては、監査で客観的な立場からチェックしてもらい、課題解決に向けた提言をしてもらうことは有用と考える。

<Q&A>

Q:従来の考えでは、不正を想定し、その防止策として開発と運用の分離が要求されている。DevOpsでは開発と運用の関係をどのように考えればいいのか?

A:DevOpsとして公式な答えはないが、私見として、ビジネスの変化に合わせて、開発と運用の役割も変わると思われる。ITILでも開発と運用の分離が規定されているが、見直しの機運もある。

6.所感

開発と運用が協調することにより問題解決(ビジネスへの貢献)を図るとの考えは、ある意味新鮮に感じられた。
途中で約20分間、紙を使った簡単な個人型ワークショップを実施されたことも特徴的であった。実際に体験することで、確証バイアス(自分の都合のよい事実を重視、選択しがちになる心理傾向)が働き、過去の成功体験を捨てられないことが実感できた。また、講師が説明されたように、一人では気付かなくても、チームで協力することにより問題解決が可能になるとの建設的相互作用の有用性も実感できた。
古くからのウォーターフォール型開発の時代から推奨されてきた開発と運用の分離といった考えが不正防止・統制強化の側面では有効である半面、アジャイル開発やクラウド、仮想化技術などのITが進歩し、ビジネスのスピードがより求められる最近の時代には、開発と運用が協調してスピードを実現することの必要性が高まっているのも確かである。社会インフラに関連する基幹業務と顧客向けネットサービスでは求められる事項が大きく異なるように、DevOpsが適するビジネス、サービスとそうでないものがあると思われる。
最後に監査に関する考察もしていただいたが、監査だけでなく、品質管理・品質保証の側面でもDevOps特有の考慮事項があると思われた。これを機会に、開発と運用の役割を改めて考察してみようとの気付きの機会となった。
DevOpsという最新の情報を紹介いただくとともに、開発と運用の関係という監査人にとって重要なテーマに関する問題提起の機会をいただき、貴重な講演であったと感じました。

以上