1 DevOps Perspectives 2 DevOpsリーダーが語るアイ ディア、 知見、 方向性 DEVOPS PERSPECTIVES 2 目次 はじめに エンタープライズの DevOps 変革について ビッグデータの時代の DevOps シャドー IT:DevOps にとってチャンスか脅威か ? ITIL – 推進役か障壁か ? 効果的な DevOps 実践者の 6 つの習慣 DevOps – ソフトウェアのテスト担当者のニーズに従うべきか ? DevOps 人材 – 新しく採用するか自社で育てるか ? 協力者 3 6 12 15 17 21 24 25 28 3 DEVOPS PERSPECTIVES 2 | はじめに DevOps は問題を抱えています。多くの点で DevOps はそれ自体の成功の被害者になっ ており、業界はクラウドのときと同じように DevOps を派手に宣伝しすぎたことの責めを 負うべきかもしれません。まるで、ソフトウェ ア・アプリケーションの開発と運用という一 対の業務にまたがる、何らかの新しい統合の 枠組みの登場が長年待たれていたかのよう です。それが登場した今、すぐに取り組まな ければならないにもかかわらず、私たちはい まだに革新の波に圧倒され、対処しきれてい ません。 現在は、実際の人間よりもソフトウェア・アプリケーションを通 じて顧客が企業のブランドを体験し企業とやり取りする可能性 が非常に高い、アプリケーション・エコノミーと呼ばれる時代 にあります。その只中にいることを私たちが受け入れるなら、 DevOps の機会をつかむことはすべての技術者にとって急を要 する責務です。アプリケーション・エコノミーと DevOps の役割 に関する最新の CA Technologies による調査 * の結果、IT 部門 と事業部門（LOB）の幹部 1,425 人のうち 88% が、DevOps をすでに導入済みまたは今後 5 年以内に導入予定であると答 えています。 4 DEVOPS PERSPECTIVES 2 | はじめに OpsDev と呼ぶべきだったか ? しかし議論すべき点はまだあります。OpsDev という呼び方にし ておくべきだったでしょうか ?DevOps の DNA のバランスは何ら かの点で不完全ですか ?DevOps はあらゆる環境に生産性の高 い実装を行えるよう、LoB と十分な関連をもって発展していま すか ?DevOps は、1990 年代なら DVD-ROM ボックスで送られ てきたようなパッケージ製品ではなく、職場の文化だということ を私たちは理解しているでしょうか ? DevOps はすでに初期の時代を過ぎ、この eBook で取り上げた ようなタイプの企業で展開され完全に実行されています。この 段階になると、DevOps が現在の作業環境で成果を上げられる ようにするための、もっと現実的な方法や細かい点が重要にな ります。現在の作業環境とは多くの点で継続的デリバリと継続 的インテグレーションに対する必要性によって動かされていま す。 88% このような議論はある意味健全なことでもあります。これは新 しいテクノロジが成熟していく過程で通らなければならない初 期の苦しみなのです。しかし長期の混乱は不健全で、混乱させ る力はマイナスになることは、CA のホワイトペーパー「DevOps: 「DevOps を適切に実現す The Worst-Kept Secret to Winning in the application economy ることは、社内の利害関 （DevOps: アプリケーション・エコノミーで成功を収めるために 知っておくべき秘密） 」にも記されています。DevOps の経験 係、経済、技術、人材に 者はすでに、アプリケーションの品質と性能、最終顧客エクス ペリエンスの強化、クロスプラットフォーム同時並行ソフトウェ 関わる問題です。 」 ア・デプロイメントにおいて測定可能な成果を上げています（15 ∼ 21% の向上） 。 88% の企業が DevOps を採用 予定 *CA の委託により 2014 年 7 ∼ 8 月に Vanson Bourne が実 施した調査、「DevOps: The Worst-Kept Secret to Winning in the application economy（DevOps: アプリケーション・エ コノミーで成功を収めるために知っておくべき秘密）」 5 DEVOPS PERSPECTIVES 2 | はじめに 環境に合わせる テクノロジ・エコシステムの範囲を DevOps 対応ワークフローに マッピングする際は、一歩下がってソフトウェアの開発とデリバ リへの個々のアプローチを分析する必要があります。DevOps はライフサイクル・プロセス管理やコラーボレーション・ツール と連携する必要があり、スムーズに事を進めるためには、すぐ にこうした環境に合わせなければなりません。 DevOps を適切に実現することは、社内の利害関係、経済、技 術、人材に関わる問題です。こうした多方面にわたる要因（同 時に成功への大きな可能性）を考えると、このことを適切に進 めるには、作業グループとディスカッション・フォーラムを形成 することが非常に重要です。CA の Vanson Bourne による調査 の回答者の半数が、アプリケーション・エコノミーの到来によっ て所属する業界は「かなり」あるいは「大いに」混乱してい ると回答しています。しかし、戦略的インサイトをもって機会 をとらえられれば、これは前向きな混乱になるかもしれません。 DevOps に何か問題があっても、これらの課題をグループと共 有し詰めることができれば、さらなる強化が期待できます。今 後の見通しは明るいといえます。 19% 品質とパフォーマンスが向上 6 エンタープライズ DevOps の変革 DevOps コンサルタント会社、Contino の共同創立者、Benjamin Wootton 氏はエンタープライズ文化における DevOps の位置を 評価しています。 DevOps は Facebook、 Spotify、 Google など Web 上で生まれた企業の間で始まったため、 従来型の大企業に合うのかという疑問が、DevOps コミュニティやその他で上がっていました。 大企業の多くはここ何年もテクノロジ・ベンダからの宣伝に煽られているため、エンタープライズ DevOps について話すプロバイダやコンサルタントが、すでに存在するものに別の目的を与えて 再び売り込もうとしているのではないかという、根本的な懸念を抱いたとしても当然のことでしょ う。 しかし DevOps をエンタープライズの設定の中でどのように適用すべきかを見てきた経験から私 は、エンタープライズ環境では DveOps はニッチの中のニッチという立場に値し、多くの点でよ り効果の高いツールであるという結論に達しています。 これは、大企業の CxO からエンタープライズにおける DevOps の変革と達成方法について質問 を受ける回数が増えていることにも反映されています。 エンタープライズでの DevOps 変革を行おうとするときは、人、プロセス、テクノロジという 3 つの点を考慮する必要があります。この 3 つが調和していなければ、その取り組みが最大限の 力を発揮することはできません。 7 DEVOPS PERSPECTIVES 2 | エンタープライズの DEVOPS 変革について 人 DevOps の実践者は文化についてよく口にしますが、文化の変 革は簡単なことではありません。文化はどのようにして評価で きるでしょうか、また、どうすれば私たちが変化して文化に影 響を与えることができるでしょうか ? DevOps 方式に向けてエン タープライズを変革するには、こうした問題よりももっと緻密な アプローチが必要です。 まず考慮しなければならないのは組織構成です。ここでは部門 の構造、職務、責務、指揮命令系統、社員の動機づけなどに ついて考えます。これは社内の職務、その役割、毎日の業務 割り当て、目標達成のために用意する報酬やインセンティブな どにも関連します。 「IT 業界は若手技術者の 育成が得意ではありませ ん。」 すべては皆が同じ方向を向くために必要なことです。このステッ プは重要です。これがうまくいくためには上級幹部の賛同を得 てトップダウン式に進める必要があるだけでなく、これを推進す るために組織内の責務が存在するところすべてに目を向けるこ とも必要であるからです。 次に、IT 組織内の人材について考える必要があります。特に、 必要な DevOps 人材が社内に揃っているか、揃っていない場合 はどこで見つけるか、新しく採用するのか社内で育成するのか、 などについて考えます。 8 DEVOPS PERSPECTIVES 2 | エンタープライズの DEVOPS 変革について 社内で育成するにはもちろん時間がかかりますが、新たに採用 する方が簡単とは限りません。実のところ、必要な能力を備え た人材を見つけることはたいへん困難です。産業界や教育は 縦割りの考えのもとに組織されています。 正直に言うと、IT 業界は若手技術者の育成が得意ではありま せん。私たちは育成方法について考え直す必要があります。 必要とする人材を採用しようとしても見つからないのは、企 業が直面する共通の課題です。知り合いのいくつもの企業が DevOps の人材を長い間探し続けています。 DevOps の採用はまさしく売り手市場で、この傾向はすぐには変 わらないでしょう。大学はいまだに考え方が古いため DevOps には対応しておらず、企業は若手の育成への投資に前向きで はないように見えます。その結果、以前からいる上級エンジニ アは給料がますます高くなり企業にとっての重要度が増す一方、 それに続く若手は育っていません。 人材を採用しようとするなら、インセンティブと文化の観点から 考える必要があります。適切な能力を持つ新入社員を引きつけ るだけでなく入社後に定着させるには、何を変える必要がある でしょうか、あるいは何を用意する必要があるでしょうか。もっ と自分に合う職場環境を提供する競合他社へと転職されるため に、社員を教育するわけではありません。 金銭的な報酬は明らかに重要な要因ではあるものの、DevOps 人材はデリバリによっても動機づけされる傾向があります。自分 のした仕事が市場に出て使用されるところを見たいと考えます。 柔軟な職場を求め、最新かつ最高のツールを使用して仕事をし たいと希望します。採用したい人材にオファーを出す前に、こう したことをすべて考慮にいれる必要があります。 9 DEVOPS PERSPECTIVES 2 | エンタープライズの DEVOPS 変革について プロセス ここでは、要件の把握と優先順位設定、ソフトウェア・リリース、 変更およびインシデント管理といった運用プロセスなど、組織 とそのビジネス・プロセスについて考慮する必要があります。 「コラボレーションと個人 の責任を重視する文化へ DevOps では、適切な人材が知識や責務を担えるよう、これら のプロセスを変更することが必要です。現在ほとんどの企業で と移行することが必要で IT へのアプローチはプロセス主導型です。ある業務の担当者、 別の業務の担当者というようにすべてがプロセス中心で動いて す。 」 います。 社員はロボットではありません。コラボレーションと個人の責任 を重視する文化へと移行することが必要です。社員は皆インテ リジェントで高度なスキルを有する人々です。これらの人々が 自分で判断し、協力し合うよう促すことが重要です。 文化はボトムアップからも変わっていきます。トップダウンとボト ムアップが真ん中で出会うのが理想的です。 もちろん大規模な実績ある企業の場合は特に、現在使用して 一般にこれが現場に適切な文化を導入するということです。トッ いるプロセスがあるはずです。長期にわたり特定の方法で物事 プダウンによる支援とその重要性について先に述べましたが、 が機能しビジネスを支えています。このような長く確立された 職場の慣習を変えるには何から始めればいいでしょうか。ここ でも人的要因が関係します。変化に抵抗の少ない人でも自分 のやり方に固執することがあります。 業界を問わず、組織のちょっとした変更でもうまくいかないこと はあります。しかも DevOps では人、プロセス、テクノロジが 複雑に関係します。プロセスの変革に関する課題を軽視しては いけません。 10 DEVOPS PERSPECTIVES 2 | エンタープライズの DEVOPS 変革について テクノロジ 第 3 の要素はテクノロジで、ここでは新興企業に比べて複雑で 込みいった、実績あるエンタープライズ組織のテクノロジ環境 について考えます。障害はいろいろあります。こうした企業は これまで CRM や ERP、SFA や HCM に投資してきました。ビジ ネスの基盤となるコア・システムの上には、長年にわたってい くつもの層が重ねられています。 「現在、本番のアプリケー ションの多くはモノリシッ クです。」 その結果、複雑に絡み合ったシステムの中に、多数の統合ポイ ントが存在する状態になっています。非常に多岐にわたるテク ノロジ、プラットフォーム、プロバイダが混在しています。何年 にもわたってこれらの要素が加えられてきたため、自動化は限 られ、更新や新規リリースへの対応に苦労し、おそらく支払う こともできない投資のバックログがあります。 易にし、インフラストラクチャの機敏性を向上させるには、クラ ウドや仮想化などの新しいデリバリ・モデルやテクノロジについ て検討する必要があります。 つまり組織とビジネス・プロセスの変革が必要であるように、テ クノロジ・プラットフォームにも変革が必要です。IT の管理を容 しかし残念ながらいまだに、たとえば仮想化などのポテンシャ ルを十分に生かせていない例はよくあります。こうした組織で はサーバ・プロビジョニングに数か月とはいわないまでも数週 間を費やし、環境は動的または一時的ではなく静的で、自動化 が不十分なため開発やテスト、本番に一貫した反復可能な環境 を用意できません。 現在、本番のアプリケーションはモノリシックであることが多く、 リリース、管理、保守、変更を容易にするにはこれを分割する 必要があります。 開発者はインフラストラクチャの層にもっと自分たちが関与すべ きときでも、縦割りのインフラストラクチャ・チームによって足 止めされ、サーバへの変更を待っていることがよくあります。 エンタープライズの DevOps 変革を成功させるには、こうした 状況をすべて変える必要があります。 DEVOPS PERSPECTIVES 2 | エンタープライズの DEVOPS 変革について まとめ 私たちが DevOps のエキスパートとして必ずしも困難を切り抜 けているとはいえません。私たちの一部にはエンタープライズ DevOps の考えに反対し、DevOps が単なる理想ではなく主流 となることを望まない人がいます。 「私たちは、DevOps は評 判が高まっているという事 実を受け入れる必要があ ります。」 私たちは、DevOps の評判が高まっているという事実を受け入 れ、エンタープライズ規模で DevOps を導入しようとする組織 に変革への詳細で緻密なロードマップを提供し支援する必要が あります。DevOps では本質的に文化と相手への共感が重要で あることは知られていますが、具体的なアクティビティとプロセ スの変更という点で、どのようにしてエンタープライズ組織を A 地点から B 地点へと動かせるか、もっと詳細に検討する必要 があります。 エンタープライズ DevOps はこれまであまり注目されていな いニッチであり、これに反対するのではなく取り組むことは、 DevOps の採用拡大の鍵となるでしょう。 11 12 DEVOPS PERSPECTIVES 2 | ビッグデータ時代の DEVOPS ビッグデータ時代の DevOps 現在はビッグデータ、Hadoop や Cassandra クラスタの時代で、かつてないほど DevOps のメトリクスを検索、収集できる機会があります。ただしそれがよいことかどうか、意見は 分かれています。 メトリクスは明らかに DevOps 戦略の重要な構成要素ですが、 単に大量の情報が利用できるだけでは、あまりにも多くのデー タ・ポイントを仕分けなければならないというリスクにつながる 可能性があり、データを見失うことになりかねません。 「 有 用なメトリクスとは、 情報の提供または検証の ために役立つものである べきです。」 Evolve Beyond 社 CTO の Robert Benefield 氏は「メトリクスは 多ければよいわけではありません」 とはっきり述べています。 「有 用かどうか明確でないメトリクスやデータはノイズを形成し、有 用なメトリクスやデータの供給を混乱させ速度を低下させます。 判別できない場合は、収集しない方が賢明です。いつか何か の役に立つかもしれないと考え明確な理由もなくデータを収集 することは無駄であるだけでなく、もっとすぐに役立つメトリク スを大量のノイズによって埋もれさせたり締め出してしまう可能 性があります。 「検証に役立つメトリクスの場合、仮定またはイベントに対する 証拠を提供します」と Benefield 氏は続けています。「これには 期待される使用パターンや動作の妥当性の証明や、課金のた めの計量などが含まれます。オーディエンスは通常、ビジネス・ バリューの検証、ユーザ・エクスペリエンスとエンゲージメント・ パターンの確認、技術やアーキテクチャの動作の検証を行ない たいと考えています。有用な情報提供メトリクスと同じく、検 証メトリクスもアクションの方向性を決定づけます。そのアクショ では、どのデータ・ポイントが有用でどれが有用ではないか、 ンは『現在の方向性のまま変えない』という場合もあります。」 どのように判断すればいいでしょうか ?Benefield 氏は最初の理 念に戻ることだと述べています。「有用なメトリクスとは、情報 「どのメトリクスを収集するかを決定するときは、何を、誰が、 提供または検証に役立つものであるべきです。情報提供に役 どういう理由で探しているかを把握する必要があります。これ 立つメトリクスの場合は、すぐに調査し解決する必要がある異 らの問いに答えられなかったり、その答えからはメトリクスの使 常や有害な傾向を知らせます。」これには相次ぐ予期しないア 用者が合理的に実行できるアクションが示されない場合、その プリケーションの再起動、セッションのドロップ、リソース使用 メトリクスには不備があるか、有用性が十分ではないということ 率の危険な急増などが含まれます。これらはすべて異常な現象 です。」 で、対応が必要です。 13 DEVOPS PERSPECTIVES 2 | ビッグデータ時代の DEVOPS 単なる大量のデータではない DevOps メトリクスから単なる大量のデータではなく、検証に 役立つデータと情報提供に役立つデータを得るには、Volume （量） 、Velocity（速度） 、Variety（多様性） 、Value（価値） 、 Veracity（正確性）というビッグデータの 5 つの「V」を適用 「メトリクスの中にはほとんど価値がないものもあります」と Matthews は述べています。「システムが正常なパラメータの 範囲内で動作していることを示すテラバイトものメトリクスは、 正常な動作がどういうものかわからない初期には必要かもしれ できるかどうかを考えると役に立ちます。 ません。システムが安定した後は、このようなメトリクスは維持 CA Technologies ラボの研究スタッフ、Peter Matthews による するべきでなく、廃棄するか無視する必要があります。どの測 と、この答えはある程度「できる」で、最初の 3 つの「V」は 定値にも、それ自体が何を示すか、そして他の測定値と結び付 DevOps のコンテキストで簡単に明らかになるということです。 メトリクスの Veracity （正確性） は馴染みのある問題です。「デー タの正確性は分析を行うときに常に懸念事項となります」と Matthews は述べ、ビッグデータに対する主な批判は、分析の 方法を知ってさえいればすべてのデータに価値があるという考 えだとしています。DevOps メトリクスはそのグループに該当す ると彼は指摘しています。 「DevOps メトリクスに関するデータ収集では価値をもたらす データを優先すべきで、膨大なデータの収集はノイズを発生さ せるという忠告があります」と Matthews は述べています。「こ れはデータの三角分割のような技法の出力を無視することと同 じです。データの三角分割は複数の関連の可能性があるデー タ・ソースを使用して、未知のデータ・ポイントを検証または作 成する手法です。」 「Volume （量） 、 Velocity（速 度） 、Variety（ 多 様 性 ） 、 Value（価値）、Veracity（正 確性）というビッグデータ 「これはナビゲーションの概念から応用したもので、社会科学で 「Volume（量）は規模と範囲によりますが、混雑した IT ショッ よく使用されますが、ビッグデータ戦略の一部として保持され プで大規模なデータが収集されていることは簡単に予測できま の 5 つの『V』を適用で たすべてのデータを活用して、破損したデータの修正を三角分 す。最後に、Velocity（速度）は追跡および管理対象の重要な 割法で行うことができます。分析と予測のために膨大なデータ きるかどうかを考えると役 を使用して DevOps メトリクスを改善できれば、そのデータの インシデントがある場合、疑問の余地はありません。」 価値はもっと簡単に確立できます。」 」 残りは 2 つのカテゴリ、Value（価値）と Veracity（正確性） に立ちます。 「Variety（多様性）はメトリクスのデータ収集範囲によって異な ります」と Matthews は述べています。「変更ログ、エラー率、 解決時間を見るだけなら多様性は大きくありません。しかし、 ソフトウェアの開発から廃棄までを測定している場合は、構成、 プロジェクト計画、ユーザ履歴など幅広いデータが存在する可 能性が高くなります。」 です。ここでの第一の原理として、収集するメトリクスにはどれ も Value（価値）がなければなりませんが、企業はすべてのメ トリクスが自動的に価値を持っていると決めてかかる罠に陥ら ないようにする必要があります。 いたときに何を推論できるかという価値を設定することが必要 です。」 「より多くのデータがあれば、DevOps システムの動作について 新しい事実を発見し、問題や逸脱が発生する前に予測できる機 会が得られます。 トレンドとパターンを一貫して確立するために、 「十分なデータ」というアプローチを「十分な」予測で補完 できることは注目に値します。」 DEVOPS PERSPECTIVES 2 | ビッグデータ時代の DEVOPS その他の考慮事項 オーディエンス タイミング サービス・エコシステムについての考慮も 必要 データがどれほど時間依存であるかは重要です。「サービス 考慮すべきもう 1 つの要因は、サービス・エコシステムの範 およびインフラストラクチャのヘルス・メトリクスは通常、戦 囲です。エコシステムの一部に入り込む不一致を確実に効果 略的ビジネス・インテリジェンス向けに取得された分析データ 的にキャプチャ、削除、防止できれば、メトリクスはもっと一 よりも一刻を争います。一部のデータはキャプチャして、適 貫して典型的で高度なものになります。 切なアクションをとれるように十分なコンテキストとともに適 切な場所に迅速に中継する必要がありますが、その他のデー 「メトリクスの効果に影響する最も重要だが見過ごされている タは分けてオフラインで処理することができます。」 要因は、サービス・エコシステムの安全性のレベルです」と 「同様に、コード品質、構築およびテスト・メトリクスは、監視 Benefield 氏は述べています。「構成や処理、その他の環境 すべきリスクの可能性が多い場所を運用が把握するために役 これには、どのデータがいつ重要かの特定に必要な選択を行 要因のちょっとした違いが、メトリクス・データのキャプチャ、 立ちます。使用率の情報と顧客エクスペリエンスの予測は、 うために必要なスキルを備えていることが必要です。「メトリ デリバリ、理解をわかりにくくし妨げます。」 ビジネスと技術グループの両方が設計、構成、保守について クスの目的と本当の意味を明確にする必要があります」と、 判断する際に役立ちます。」 Skelton 氏は述べています。「数学的相関と、どのようにデー タを適切に解釈できるかをきちんと理解できるスタッフが必 さらに Skelton Thatcher Consulting 社の主席コンサルタン 要です。」 ト、Matthew Skelton 氏は、DevOps メトリクスが最終的に どのように使用されるか注意する必要があると述べています。 一定のまま変わらないものはない 「DevOps コンテキストでメトリクスを収集するときは、メトリ クスを使用したことでチームにネガティブな行動を引き起こす ことがないよう注意する必要があります。たとえば、デプロ メトリクスの価値は一定ではありません。「メトリクスの有用 イの失敗数に基づいて製品チームを評価したり、ブルーグリー 性は時とともに高くなったり低くなったりするため、メトリクス ン切り替えの速度に基づき報酬を与えたりすると、逆効果を は定期的に価値を評価し、積極的に不要なものを取り除き管 招くことがあります。メトリクスは作業改善を目的としてチー 理することが必要です」 と Benefield 氏は述べています。 「デー ムを支援するために使用するべきで、チームの失敗を罰する タの選別に手間がかかると必要な作業量が大幅に増加するた ために使用するべきではありません。 め、組織がキャプチャし追跡する対象を、変化する状況に合 わせて変更しようとする応答性と意欲が低下します。」 収集したメトリクスからメリットを得るオーディエンスは複数い るという事実を認識することは重要だと、Benefield 氏は述べ ています。「欠陥、アプリケーションおよびインフラストラク チャのエラーと状態、リソース利用率など、従来は運用スタッ フが収集していたメトリクスは、開発とテストの作業を支援す る重要なインサイトを提供することができます。」 15 DEVOPS PERSPECTIVES 2 | シャドー IT シャドー IT:DevOps にとっ てチャンスか脅威か ? CIO Magazine の「2014 State of the CIO Survey」の結果では、IT リーダーの 5 人に 4 人が、IT 部門が関与せずに行われた IT プロジェクトは問題を引き起こすと感じていま した。 CA デジタル変革リーダーの Justin Vaughan Brown は、増大するシャドー IT の 懸念に DevOps がどう対処すべきかという問いを投げかけています。 この数年で、アプリケーション・デリバリ・サイクルの速度は大 幅に増加しました。これは、より迅速に高い応答性で実現する アジャイル・テクノロジへの要求に直面する開発、テスト、リリー ス、運用チームにプレッシャーを与えています。 言い換えると、従来の手順ではコストがかかりすぎ複雑で煩わ しすぎる上、何よりも時間がかかるという理由で、ビジネス上 の必要性に対応しようとした LoB が勝手な行動をとることを意 味します。 また、 新規製品 / サービスを導入し収益を上げる責任を直接担っ ている事業部門（LoB）の責任者にも影響を与えています。こ うした事業部門のユーザはたいてい、ビジネスに手段を与えサ ポートする「都合のよい」IT 部門がないことに不満を持ち、IT はむしろビジネスの邪魔をしていると非難をしがちです。 クラウド、SaaS、PaaS などはすべてオーダーと支払いが簡単 なオプションを提供し、しかも LoB が理解できる言葉が使用さ れています。こうした人々はクレジット・カードを使用して簡単 にブラウザベースのビジネスツーコンシューマ・アプリケーショ ン機能を手に入れることに慣れている世代です。職場では何が それほど違うのでしょうか ? このことがシャドー IT の懸念を増加させています。 シャドー IT とは、IT 部門に承認されていないインフラストラク チャや環境を使用してサービスを構築またはデプロイするチー ムのことです。 当然のことですがガバナンス、コンプライアンス、セキュリティ の点で大きく異なる上に、IT アーキテクチャ戦略に複数の路線 ができる危険があることは言うまでもありません。 DevOps はこうした今の時代の状況にどのように対応すべきで しょうか ?DevOps はこれを無視すべきか、歓迎すべきか、それ とも対抗すべきでしょうか ? これは白黒完全に割り切れる状況ではありません。次のページ では、なぜシャドー IT が DevOps にとって懸念を引き起こすか、 いくつかの理由を説明します。 DEVOPS PERSPECTIVES 2 | シャドー IT シャドー IT のメリット 行動計画 同様に、シャドー IT が DevOps にとって役に立ちうる理由もい くつかあります。 シャドー IT に直面したときに DevOps プログラムの従事者がと れる最善の対応策は、以下のようなものです。 継続的デリバリの透明性 チャンスの可能性 シャドー IT プロジェクトは他のアプリケーションにどのように マッピングしますか ? 関連するリリース段階についてどのくら い把握できますか ? シャドー IT の存在は現在 IT の実践内容がビジネスの希望する 速度を満たしていない場所を明らかにします。それは「DevOps について説明しましょう」という会話を始めるのに最適なタイミ ングであり、LoB の一部を味方に引き入れるチャンスとも考え られます。 » なぜ従来の IT が避けられるのか、そして LoB ユーザの懸 念 / 不満 / フラストレーションは何かを理解します。 シャドー IT の問題点 パラレル・ワールド DevOps が本番ラインを標準化しようとするとき、シャドー IT は並行して実行するアクティビティのサイロをもう1 つ作る別の 「工場」を構築します。どちらが優位に立つでしょうか ? セキュリティ API が脅威にさらされるリスクにはどのようなものがあります か ? サードパーティとの統合を確立するときに、見えない攻撃 に門戸を開く危険について LoB は理解しているでしょうか ?（答 え : 当然ほとんど理解していません。それは IT の仕事です。） ガバナンス 次の環境へのデプロイや、最も重要なことですが本番へのデ プロイをどのチームや個人が承認したかを実証するために、ど のようなレポートが作成されますか ? 金融サービスや医薬品な ど特定の業界には、承認または監査証跡の作成について非常 に厳格な規制があります。 再利用 LoB が望みどおりのものを手に入れ、アプリケーションをデリ バーしたら、その次は何が起こりますか ? シャドー IT はどのよ うにして次回のリリースに取り組むのでしょうか ?DevOps では、 アプリケーションの開発とデプロイはプロジェクトではなく反復 可能なプロセスであることが必要です。シャドー IT はこれを脅 かします。各要件を断片的、部門的な 1 回限りの視点で見る からです。 DevOps プロジェクトのアラート シャドー IT は初期の DevOps プロジェクトにとって、潜在的な 実験の場を示せる可能性もあります。ここでは、やむを得ない ニーズのために、従来とは異なるデリバリ方式を LoB が前向き に検討するような状況を見つける必要があります。そこで合格 しなければなりません。 クラウド 非常に多くのシャドー IT が低コストで簡単にアクセスできるクラ ウドベースのアプリケーションやプラットフォームを利用してい ますが、DevOps はパブリック、プライベート、ハイブリッド・ク ラウド環境で迅速なデリバリ / プロビジョニングを行う用意がで きていることを説明できる可能性があります。 » 現在または将来の DevOps 中心のプロジェクトに要件をどの ように適用できるか定めます（可能であれば）。 » 独自の方法をとることを検討した LoB のリーダーと話し合 い、コラボレーティブな DevOps のビジョンの概略を説明し ます。このコンテキストでは積極的に独自の行動をとろうと する社員はほとんどいないと考えます。 » シャドー IT の賛同者との接触を続け、DevOps が卓越した セキュリティと品質を確保しながら、どのように継続的デリ バリを達成できるか説明を続けます。 シャドー IT は時代の流れです。DevOps の擁護者がシャドー IT についてどう考えようと、あるいはどう反応しようと、これは重 大すぎて無視できない問題になっています。 17 ITIL – 推進役か障壁か ? ITIL 2011 フレームワークは、ビジネス目標に合わせた高品質な IT サービスを提供するた めに必要なプロセスおよび機能に関するガイドラインです。 ITIL はサービス管理フレームワークとして広く認められていますが、熱心な支持者が主張 するほど効果的な DevOps に適しているしょうか ? 18 DEVOPS PERSPECTIVES 2 | ITIL – 推進役か障壁か ? 基本情報 – 実際の ITIL とは 「ITIL は IT サービス管理のベストプラクティスをまとめたもの で、規範を示すフレームワークではありません」と、Skelton Thatcher Consulting 社 の 主 席コン サ ル タント、Matthew Skelton 氏は述べています。「また、ITIL は現行のサービス を継続的に改善していくことを重視しており、『完成していな い』プログラムです。 DevOps アプローチの主要な面は、作 業の引き継ぎをなくしてデリバリの速度と品質（および運用 の効果）を最大化することです。」 う側が妨げとして扱ったときのみ、妨げとなるのです。」 「ITIL はサービスの戦略と 「ITIL はアジャイル方式や DevOps に対する意見を述べたり支 DevOps に反 設計について列挙してい 援するようには意図されていません。同様に、 対する要素もほとんどありません。」 るものの、IT の『 構築 』 また、ITIL はサービスの戦略と設計について列挙しているも のの、IT の「構築」部分には触れておらず、 すぐに移行のトピッ 部分については扱ってお クに進んでいると、 Vazanias 氏は指摘しています。「構築プ 「アジャイル方式、ITIL、DevOps はどれも実用的なソフトウェ らず、すぐに移行のトピッ ロセスは扱っていません。開発の世界からどうにか生まれた アを重視し、反復による改善とコラボレーションを重視すると 動きである DevOps については触れられていません。実際に いう共通点があります。アジャイル方式で好まれるのは反復、 取り上げていないため、ITIL は DevOps を支持も否定もして クに進んでいます。 」 早期デリバリ、利害関係者とのコラボレーション、変化への いません。」 対応であり、詳細なマニュアルや計画よりも実用的なソフト ウェアです。」 したがって明らかに一定の共通した目的がありますが、期待し すぎるべきではないと、North Highland Company 社の社長、 Harry Vazanias 氏は述べています。「ITIL は DevOps を推進 するものか妨げるものかという疑問はよくきかれます。この 疑問は的を射たものとはいえず、的確な論点から注意をそら してしまいます。的確な論点とは『適切な DevOps 環境を推 進するにはどのようなガバナンスが必要か』ということです。 これには ITIL を重点的に活用する場合もあれば、そうでない 場合もあるでしょう。」 Vazanias 氏は、ITIL 自体は DevOps を妨げたり推進したり ITIL は現在の形態では、最新の技術の進歩についていけて いない恐れもあります。「ITIL 2011 は最新版ですが、実際 は 2006/7 年の V3 の小規模なアップデート版にすぎません」 と Vazanias 氏は述べています。「つまり、ITIL の中核を成す 考えは、スマートフォンのアプリケーション以前の時期のもの するように作られてはいないため、特にそのいずれでもな で、長い実績を持つ大企業がアジャイル方式を取り入れ始め いと主張しています。「ITIL はフレームワークであるため、 たばかりの頃です。」 DevOps にとってお役所仕事的だったり縦割りすぎる要素があ る場合は、無視できる柔軟性があります。つまり、ITIL は使 DEVOPS PERSPECTIVES 2 | ITIL – 推進役か障壁か ? 反対意見 Pearson 社の DevOps エンジニアリング・マネージャ、Patrick Hyland 氏は、ITIL V3 ライフサイクルに対応したサービス・プ Hyland 氏は例として、パフォーマンスが低下しているサービス ムの根幹を形成する継続的デリバリとの統合が可能です。」 についての問題管理を行っている運用部門が、設計のキャパシ ロバイダの、リーン生産方式を使用して管理される移行および ティが戦略要求に合うよう調節されていなかった戦略を検出で 「リーン生産方式を ITIL V3 に適用することでライフサイクルの 運用ステージでは、DevOps は非常に効果的に機能する可能性 きる場合を挙げています。 すべてのフェーズが相互接続され、開発と運用のコラボレーショ があると述べています。 ンに限らず、戦略から運用までの広い範囲のコラボレーション Hyland 氏は次のように説明しています。「このとき、サービス・ を可能にします。」 「かんばん方式を使用し、サービスを提供するライフサイクル・ プロバイダは制約理論を使用して、これが起きている原因を確 プロセスと相互接続することで、サービス・プロバイダはシス 認できます。たとえば、キャパシティ管理がボトルネックである しかし成果を得るには、これはすべて時間がかかり熟考を必 テム全体の可視性を確保でき、システムをより深く把握でき ため、もっと適切に活用する必要があるのかもしれません。あ 要とします。何にでも効く魔法の薬というわけではありませ ます。これは Gene Kim 氏が提唱する第一の方法「Systems るいは、キャパシティ管理が過剰なためにサービスの有効性確 ん。Vazanias 氏は最後に次のように語っています。「人々は Thinking」と似ていますが、開発と運用に ITIL V3 戦略と設計 認とテストの結果が影響を受けているのかもしれません。また、 DevOps を軌道に乗せるための特効薬を探し続けて、ITIL がこ を結び付けています。」 WIP インベントリの状況が影響している可能性もあります。」 れを簡単に実現できるのではないかと期待しています。そして 実現できないと、ITIL は目的にかなっていないと文句を言うの 「さらに、運用における問題管理からのフィードバック・ループは、 Hyland 氏は、このライフサイクルという観点で考えれば、ITIL です。」 ライフサイクルの典型的な DevOps にあたる部分である移行 は非常に効果的だと話しています。「ITIL V3 は包括的で迅速な フェーズだけでなく、ライフサイクルのすべての部分にまで拡 サービス・デリバリに完璧なマップを提供します。移行フェーズ 張して戻ることができます。つまりライフサイクルの初期フェー では、アプリケーション開発、サービスの有効性確認とテスト、 ズにまでフィードバックして戻ることが可能です。」 変更管理、リリースおよびデプロイ管理は直接関連性がある領 域で、自動化の準備が整っており、DevOps のバリュー・ストリー 19 DEVOPS PERSPECTIVES 2 | ITIL – 推進役か障壁か ? ITIL のガバナンスに関す る質問 アジャイルと ITIL をつなぐ実 用的なステップ Harry Vazanias Matthew Skelton » 開発から本番への承認はどのように機能しますか ? 特に責 任の説明が必要で、単一の DevOps の役割は実現可能で はない場合はどうなりますか ? 開発チームと運用チームをアジャイル方式と ITIL® のコンテキス トで連携させ、DevOps のコラボレーティブなアプローチを構 築する方法がいくつかあります。 » 変更を小規模に抑えます。 » デプロイを迅速に行うために、開発から本番へのプロセス をどのように合理化（リーン化）しますか ? » 開発チームがランブックのドラフトを作成し、詳細について 運用チームからの支援を求めるランブック・コラボレーショ ン » 開発チームと運用チームの間に適切な種類のコラボレー ションを確立し、効果的に共有ツールを使用して、継続的 サービス改善フィードバック・ループのタイミングを数週間 や数日間ではなく数時間あるいは数分間に短縮します。失 敗に対しては、どのように適切な見返りを与えますか ? » 1 日に複数のデプロイを行うために、変更プロセスをどの ように実行しますか ? » アジャイル方式を使用するときは、どのように移行計画を 実行しますか ? » 従来の縦割りの開発チームと運用チームと併用して、どこ でどのように DevOps チームを活用しますか ? » 失敗に対して、どのように適切な見返りを与えますか ? » コラボレーションを促進するツールを選択し、高額な本番 のみのツールを回避します。 » iTrinegy の NE-ONE のようなネットワーク・エミュレータ、 Saboteur のようなネットワーク・フォールト・インジェクタ、 Gauntlt のようなセキュリティ・テスト・フレームワークを使 用して、運用への移行に備えてテストを早期に実施します。 » 単一の製品バックログ、 「NFR」の回避、同じバックログにユー ザが見える運用機能 » 開発チームと運用チーム全体で人材を交代させます。 21 効果的な DevOps 実践者の 6 つの習 慣 非常に効果的な DevOps 実践者とは ? これは明らかに人によって、また、組織によって異なります。次に 示すリストは 3 人のエキスパート、Matthew Skelton 氏（DevOps Summit London 2013 の主宰者）、Dave Farley 氏（「Continuous Delivery」の著者）、Benjamin Wootton 氏（DevOps コンサルタ ント会社 Contino の共同創立者、主席コンサルタント）の考えをま とめ、要約したものです。 22 DEVOPS PERSPECTIVES 2 | 効果的な DEVOPS 実践者の 6 つの習慣 1 2 3 キーボードから目を上げる コラボレーションが重要 顧客と製品を重視し、すべての詳細レベル でフィードバックを活用し、改善して適応さ せます。 目の前のコンピュータ画面だけに注目するのではなく、もっと 広義のコンテキストで考えます。つまり、会社内にある多くの チームと継続的に対話してください。対話がスムーズでなくて もかまいません。 これは個人的なミッションではなくチームの取り組みであるた め、コラボレーションを行い、情報とベストプラクティスを共有 することが重要です。 顧客はあなたの会社と製品に何を求めていますか ? それらの製 品は顧客の希望と要求を反映していますか ? 顧客ニーズの理解 レベルを促進するフィードバック・プロセスは整っていますか ? Wootton 氏は次のように述べています。「ソフトウェア開発ライ Wootton 氏は次のように述べています。「効果的な DevOps 実 Wootton 氏は次のように述べています。 「開発者、 アーキテクト、 テスト担当者、運用チームなど、技術部門の他の同僚と話し合っ てください。優れたソフトウェア開発、優れた IT 運用、優れた テストとは何か、また、これらのアクティビティに固有の課題を 学んでください。」 フサイクル全体でアクティビティに関わるようにし、コラボレー ティブな方法で自分自身の観点を表現します。『縦割りの垣根 を取り払う』と言うのは簡単ですが、非常にお役所仕事的でプ ロセス主導の形式ばった組織にあっても、そのプロセスを開始 する力はたいてい個人の手に握られています。」 践者は以前よりも顧客や製品を重視するようになっています。 顧客がサポート対象のシステムから何を望んでいるかを理解し、 ユーザと良好な連携関係を築いています。事業部門が短期の サイクル・タイムで機能をデリバーできるようにして、ユーザの 要望を満足させたいと考えています。また、開発者やテスト担 当者、運用エンジニアとしての日常業務などよりも、ユーザ・ エクスペリエンスを最優先します。」 23 DEVOPS PERSPECTIVES 2 | 効果的な DEVOPS 実践者の 6 つの習慣 4 5 6 同僚が仕事の目的（目標）に集中し、ビジ コンピュータを使用するが、人間について 無駄を省き、プロセスの一部ではなく全体 ネスにとって最も重要なことに取り組めるよ も忘れない を最適化する うサポートする 先にも述べましたが、これはより広義のミッションです。あな たとあなたの同僚が取り組んでいるビジネス目標、あるいはサ ポートしようとしているビジネス目標は何ですか ? 全員が同じ道 を進めるように、これらの目標を他のスタッフが理解できるよう サポートできますか ? Wootton 氏は次のように述べています。「学んだことを自分 のチームの同僚と共有し、チームの仕事をしやすくする要件 が理解され作業に反映されるようにします。顧客エクスペリエ ンスや製品に関して技術者と事業部門の考えを一致させれば、 DevOps のような理念の多くは自然と浮かび上がってきます。」 これは、コンピュータにはコンピュータが得意なことをさせ、人 には人が得意なことをさせるということです。そして、あらゆる ことを自動化しますが、人が推測ではなく情報に基づいて決定 を行えるようにします。 Wootton 氏は次のように述べています。「DevOps 実践者はテ クノロジと同様に人についても変革が必要だということを知っ ています。しかし人的要因は日常的な職務と作業内容から始ま ることを認識することが必要です。」 リーンおよびアジャイル方式の組織構成およびプロセスを用意 することは、DevOps チームが最大のキャパシティでビジネスを 支援するためにきわめて重要です。これは、余分な負担をすべ て取り除き、DevOps 実践者が最も生産的な方法で作業を行う ために必要な重要な要素に集中することを意味します。 Wootton 氏は次のようにコメントしています。「DevOps 実践者 は製品機能がどのように使用されているかに関するデータを収 集し、次の反復のための情報を提供し、製品を改善するために そのデータを製品マネージャにフィードバックしたいと考えてい ます。」 DEVOPS PERSPECTIVES 2 | DEVOPS – アプリケーション・エコノミーへの対応 DevOps – ソフトウェアのテスト 担当者のニーズに従うべきか ? アプリケーション・エコノミーの進展の結果、継続的デリバリの 「このようなアプローチの効率性はすでにテストにおいてもよく 速度でのロールアウトを余儀なくされている Web/ クラウドベー 理解されています」と Janaway 氏は述べています。「ソフトウェ スのアプリケーションが推進するモバイル環境で、DevOps はソ アの設計、構築、デリバリに必要なすべてのスキルを、責任を フトウェアのテスト担当者のニーズにどのように従うべきかとい 持つ 1 つのチームに移すことは理にかなっています。1 つの信 う疑問が生まれています。 頼できるチームが品質とそれを理解するために必要なすべての ことに責任を持つのです。」 特にモバイル環境などの、ソフトウェアの開発とデリバリがます ます高速化するビジネス環境においては、プロジェクトの期間 DevOps への移行はチームが品質に責任を持つようになる は短くなり、ソリューションは大規模なユーザ・ベースに提供さ もう 1 つの機会としてとらえるべきだと、DevOps 支持者の れます。そしてこのユーザ・ベースはアプリケーション・ストア Janaway 氏は話しています。「テストをチームで行う作業として を使用してわかりやすいフィードバックを即座に行うことができ 考えるのと同じように、本番システムへのデプロイや保守のス ます。このような状況では、テストがデリバリ・プロセスにとっ キルについてもチームで行う作業としてとらえるべきです。顧 てボトルネックと見なされることがよくありますが、それは間違っ 客の要望を満たしていることを示す必要なメトリクスとともに本 ています。 番で一定期間実行されるまで、ユーザのストーリーは「完了し た」と考えるべきではありません。このフィードバックはテスト DevOps は必ずしもソフトウェアのテスト担当者のニーズに対 がチームにフィードバックできる内容を補完できます。」 応して従う必要があるわけではないと、Net-A-Porter Group の テスト担当コーチ兼トレーナーの Steven Janaway 氏は述べ、 また、本番と同様のテスト環境を取得し維持する際に、テスト DevOps の主なメリットの 1 つは、縦割りのバラバラなチームで 担当者が従来抱えていた問題を DevOps が解決できることは事 はなく、部門の枠を超えたデリバリ・チームが運用スキルを持 実です。「本番と同様の環境、または本番環境そのものでテス てることにあると主張しています。 トを行うことは、より迅速なリリース・サイクルをめざす中でま すます重要になっています」 と Janaway 氏は述べています。 「テ スト担当者は運用責任者から学ぶことができます。運用責任者 をチームに参加させたり、その役割の側面を既存の開発者に移 したりすれば、ソフトウェアのテスト担当者はより多くの機会が 得られます。本番環境を理解しているチームなら、デプロイの 前後を問わず、どこに重点を置いてテスト作業を行うべきか判 断することができます。 ただしこれはすべて、会社が新しい作業方法に適応できるよう になることが条件だと、 Janaway 氏は警告しています。「DevOps への移行に考え方の変革が必要であるように、1 つのチームに よるオーナシップと本番でのテスト作業にも考え方の転換が必 要です。テスト作業の一部をデプロイの後に移すには、リスク に対する認識を変えることが必要です。企業が最大の利益を得 られるようにするためには、会社のリスク選好をスタッフが理解 する必要があり、その変更が必要な場合もあります。 25 DEVOPS PERSPECTIVES 2 | DEVOPS 人材 – 新しく採用するか自社で育てるか ? DevOps 人材 – 新しく採 用するか自社で育てるか ? 大手 DevOps 人材採用会社である Speerhead 社の CEO、Paul 人材を見つけるための 5 つのヒントを提示しています。 優秀な DevOps 人材を採用することは、DevOps 文化の強力 な基盤となります。オープン・ソース・ツールの迅速な採用と、 Amazon Web Services（AWS）などのコンピューティング・プラッ トフォームが即座に（場合によっては）低コストでアクセスでき るようになったことで、個々のエンジニアが柔軟性の高い自動 化システムを構築できる権限は大幅に増大しました。 しかし権限には責任がともないます。この業界で、企業がこれ ほど少ない IT スタッフでこれほど多くの成果を上げていた時代 は、以前はありませんでした。優れたエンジニアのための質の 高い職場と環境を構築する上で、この権限にはこれまでにも増 して大きなアカウンタビリティがともないます。 現在、多くの IT 部門が DevOps 文化を導入しようとしています が、ビジネス目標に完全に合致して境界にとらわれず貢献する 高機能チームになるか、技術に関する駆け引きと個人的な利益 の追求ばかりの非効率なエンジニアをまとまりなく組み合わせ Speers 氏は、DevOps たチームになるか、その差は 1 人のエンジニアによって生み出 される可能性があります。 分野のスキルを伸ばし、DevOps の意味を十分に理解するエン ジニアを引きつけ採用するために熟慮して取り組めば、企業は 競争上の優位性を確保できるでしょう。 当社 Speerhead では、欧州各地のオフィス全体で数百人の DevOps エンジニアを採用してきました。私たちは過去 3 年間 の経験をもとに、独自の「成功への 5 つのヒント」を作成しま した。 26 DEVOPS PERSPECTIVES 2 | DEVOPS 人材 – 新しく採用するか自社で育てるか ? 会社を売り込む メンターの必要性 時間は限られている 現実には DevOps 人材は売り手市場で、トップクラスの人材は 見つけるのが難しく、一見すると誰もがすでに採用済みのよう です。十分に練られていない、つまらない職務明細書をいくつ も目にしてきましたが、これでは求める人材を引きつけること はできません。 採用側の企業は新しいエンジニアを引きつけ相談相手となるメ ンター役の担当者を置く必要があります。会社を魅力的に見せ、 採用プロセスが終わるまで最初の印象が続くようにすることが 重要です。社内にこれに適した人物はいますか ? すばやく動くことが大切です。たいていの DevOps エンジニア はあっという間に採用が決まってしまいます。面接の順番が後 の方だったためにトップクラスの人材を逃した企業は数多くあり ます。 個人の特性 採用手順は市場に合うものにする必要がありますが、ほとんど の企業はこれができていません。メンター役の担当者を決め、 職務と会社を売り込んで候補者を引きつけ、採用を完了するま での期間は約 2 週間です。 魅力ある資料を作成することが必要です。これは会社を売り込 むチャンスであり、優秀な IT チームと仕事に対する姿勢を売り 込むチャンスです。 会社がめざす技術的な変遷について明確に説明し、優れたプロ ジェクトとチームが使用する技術について宣伝します。DevOps への移行の進捗の概要、あるいは継続的デリバリへの道筋を 示すことも不可欠です。 インターネット上には DevOps のスキルに関連する多くのプロ ファイルが掲載されています。その半分はソフト・スキルとコミュ ニケーション・スキルで、これは技術スキルとともに不可欠な ものです。 Speerhead のオンライン技術者プロファイラを使用して、社内 のエンジニアの基準を評価します。これが完了したらエンジニ アの特性について正確なプロファイルを作成できます。この一 連の特性を応募してきた新しい採用希望者全員と比較します。 当社ではエンジニアを選択する際に、職務経歴書の一部として この比較情報を提供します。 27 DEVOPS PERSPECTIVES 2 | DEVOPS 人材 – 新しく採用するか自社で育てるか ? 社内の人材を育てる 開発の技術を備えた優秀な大学卒業生つまり人材を採用し、そ の人材をあなたの会社に 6 か月間配属するサービスがあるとし たらどうでしょうか。6 か月の間に Speerhead は、その若手エ ンジニアに御社の DevOps エンジニアになるために必要な関連 スキルのトレーニングを行い、6 か月後にはこのエンジニアは フルタイム社員として御社に移ります。 ソフト・スキル、プロセスのリエンジニアリング、IT 自動化、ツー ル作成、継続的デリバリの理念と実践事項についてトレーニン グを行います。6 か月後には、このエンジニアは御社の部門で 仕事をしながら、チームに必要なスキルを十分に身につけてい ます。 このアイディアのどこが優れているのでしょうか ?DevOps エン ジニアにとって給料が上がり契約も増えていますが、その結果、 DevOps を実現できる技術と実践の経験が豊富なエンジニアは 不足しています。 定義されたトレーニング・プログラムで新しい人材を教育し、御 社の分野について理解できるよう導き、その後しっかりした OJT まとめ を行うことで、忠実で信頼できるエンジニアを自社で育てるこ とができます。 その結果、新入エンジニアはエンジニアとしての職務の理念と 文化的特性を十分に理解し、同時にインフラストラクチャを変 革できる特定のツール構築やサービスについても研修を受けら れます。新入エンジニアは技術的な能力は高いですが、プレゼ ンテーション、会議、リーダーシップ、プランニング、組織化 などのソフト・スキルを中心に能力を伸ばすべき方向を示され ます。 優秀なエンジニアを引きつけ会社に定着させるには、IT チーム と HR チームが知恵を絞り、採用の実践内容とプロセスを大幅 に変える必要があります。 募集広告を掲載すれば応募が殺到した時代は過ぎ去りました。 こうしたエンジニアが企業に与える効果に関しても、通常の採 用 KPI ではなく、採用の評価方法を変える必要があります。 ソーシャル・メディアを通じてコミュニティとつながり働きかけ、 関連する集まりやオープン・ソース・ベンダのイベントやカンファ レンスに参加します。優秀な人材はいます。ただ、こちらから 探しに行かなければならないのです。 面接の順番が後の方だったためにトップクラスの人 材を逃した企業は数多くあります。 28 DEVOPS PERSPECTIVES 2 | 参加者 Benjamin Wootton Robert Benefield DevOps コンサルタント会社、Contino の Evolve Beyond 社、CTO Harry Vazanias North Highland Company、技術責任者 Benjamin Wootton 氏はコンサルタント会社 Contino の共同創 立者です。Contino は DevOps および継続的デリバリ向けツー Harry Vazanias 氏 は技 術 戦 略と変 革に関 する第 一 線 の エ キスパートで、次世代の IT およびデジタルに関する North Highland の考えを牽引しています。開発チームおよび運用チー ムで 15 年以上仕事をした経験があり、デリバリ・モデルと他部 共同創立者、主席コンサルタント ル、実践事項、アプローチを企業が採用するための支援を行っ ています。 Wootton 氏は現場のアジャイル・ソフトウェア開発者およびコン サルタントとして 10 年以上の経験を有しています。Goldman Sachs、UBS、Deutsche Bank、Oracle Consulting など大手企 業で、実践的なソフトウェア開発と IT 運用の職務からアジャイ ル変革、組織の変革などを幅広く手がけてきました。 LinkedIn:Benjamin Wootton Robert Benefield 氏は投資バンキング、防衛、電気通信、イン ターネット・サービス産業などの業界にわたる要求の厳しい高 アップタイム環境において、世界レベルのグローバルな無駄の ない高性能エンジニアリングおよび技術運用会社を設立し指揮 しており、経営幹部として 20 年を超える経験を有しています。 Benefield 氏はアジャイルおよびリーン生産方式を使用した変 革を主導した経験があり、トップレベルのクラウドおよびエラス ティック・コンピューティング技法を開発し、多様な複雑な環境 への実装を成功させてきました。企業やその市場にわたって複 雑な問題を解決したり、テクノロジと組織的手法をクリエイティ ブに使用して理解と活力を新しいレベルに進めたりすることを楽 しんで行っています。 LinkedIn:Robert Benefield 門への価値提案の再定義を支援しました。 Vazanias 氏は小売、メディア、電気通信など様々な業界の世 界的企業で IT とデジタル機能の再設計を主導してきました。 現在は、プロジェクトではなく製品開発に重点を置いたアジャイ ルおよび DevOps の作業方式に向けた企業の移行を支援してい ます。 North Highland Company 29 DEVOPS PERSPECTIVES 2 | 参加者 Matthew Skelton Patrick Hyland Skelton Thatcher Consulting Ltd、共同創 DevOps Associates 創立者 立者、主席コンサルタント Matthew Skelton 氏は 1998 年 以 来、 商 用ソフトウェア・シ ステムの構築、デプロイ、運用に携わっています。Skelton Thatcher Consulting の共同創立者であり主席コンサルタントと して、継続的デリバリ、DevOps、ITIL、ソフトウェアの信頼性 などソフトウェア・システムの構築と運用のための優れた実践事 項を、企業が採用し維持できるよう支援しています。 Patrick Hyland 氏はアプリケーション・エンジニアリング管理 Dave Farley 氏は Jolt 賞を受賞した『Continuous Delivery』の を中心とする、ロンドンを拠点とするコンサルタント会社、 共著者です。Farley 氏は 30 年以上にわたってコンピュータに DevOps Associates の創立者です。アジャイル方式、接続 ITIL 携わってきました。その間に、ほとんどの種類のソフトウェアを ライフサイクル・プロセス、DevOps コラボレーション / エンジ 扱ってきました。さまざまな規模のチームで複雑なソフトウェア ニアリングの実践事項を組み合わせて応用し、企業が卓越した アプリケーションサービスを設計、構築、デリバリ、運用でき るよう支援しています。 Skelton 氏 は 1000 人 の 会 員 を 擁 する「London Continuous Delivery」会合グループのリーダーで、欧州初の継続的デリバ Hyland 氏は 18 年間にわたり開発と運用に携わってきた ITIL エ リをテーマとしたカンファレンス、 「PIPELINE Conference」の開 キスパートです。Eli Goldratt の制約理論による管理に特に関心 催を後押ししました。また、人気の高い「Experience DevOps」 を持ち、IT サービス管理のコンテキストにリーン生産方式の考 ワークショップ・シリーズのまとめ役を共同で務め、継続的デ リバリと DevOps エクスペリエンスについてレポートした書籍 『Build Quality In』の共同編集者でもあります。 Skelton Thatcher Consulting Dave Farley 『 Continuous Delivery 』共著者、KCG Ltd、アーキテクト えを応用しています。 DevOps Associates の開発を指揮してきた幅広い経験を有しています。 Farley 氏は 1990 年代初めから商業プロジェクトに反復開発、 継続的統合、テストの大幅な自動化を取り入れ、アジャイル開 発手法を初期に採用しました。最近では、金融業界向け高性能 ソフトウェアを開発する低レイテンシ・コンピューティングの分 野に携わってきました。現在は KCG Ltd に勤めています。 LinkedIn:Dave Farley 30 DEVOPS PERSPECTIVES 2 | 参加者 Stephen Janaway Paul Speers Net-A-Porter Group、テスト・コーチ兼トレー Speerhead Group、CEO ナー Stephen Janaway 氏はモバイルと e コマースのテスト担当コー Paul Speers 氏は Speerhead 社の CEO です。5 年以上前に同 チ、ストラテジスト、マネージャです。15 年間にわたり Nokia、 社を創立し、長期的な成長に向けて Speerhead の指揮をとり、 Ericsson、Motorola、Net-a-Porter Group といった企業に勤め、 DevOps 市場での商業的成功を推進し、革新的な DevOps 人材 多数のモバイル・アプリケーション企業にテストおよびデリバリ 採用会社のフランチャイズを立ち上げ、DevOpsトレーニングと 戦略についての助言を行ってきました。モバイル・デバイスと 認証 IP の構築で指導的な役割を果たしました。 モバイル・アプリケーションを中心にテストに関しての記事執筆 やプレゼンテーションを頻繁に行っています。また、モバイル・ Speers 氏は DevOps 市場を牽引することに焦点を当てています ソフトウェアのテストやソフトウェアのテスト全般に焦点を当てた が、会社のグローバルな顧客ベースの成功を確立することと、 トレーニング・コースを提供し指導を行っています。 急激な成長に対応する採用ソリューションにも力を入れていま す。Speers 氏は Speerhead の顧客、 世界のフランチャイズ・パー Janaway 氏はソフトウェアのテスト、テスト手法、モバイル・デ トナー、DevOps 産業全体の間をつなぐ不可欠な存在です。 バイスやモバイル・アプリケーションについて意見を交わすこと を好んでいます。 Speers 氏は Marc Andreessen 氏が経営する IT 自動化のベンダ、 Opsware で管理職を務めたこともあり、IT 業界の販売とマー stephenjanaway.co.uk ケティングにおける 20 年の経験を Speerhead にもたらしまし た。Speers 氏は Global ITIL ベンダ、Fox IT の共同創立者でも あります。 LinkedIn:Paul Speers 31 DEVOPS PERSPECTIVES 2 | 参加者 Justin Vaughan-Brown CA、グローバル・デジタル Peter Matthews CA、VP 兼リサーチ・サイエンティスト Justin Vaughan-Brown は CA Technologies、製品マーケティ Peter Matthews は CA Technologies の副社長兼リサーチ・サ 変革責任者 ング担当部門のグローバル・デジタル変革責任者です。ホ ワ イト ペ ー パ ー「The Digital Transformation Journey: Key Technology Considerations（デジタル変革の道程 : 重要な技術 に関する考察） 」の著者で、 年 4 回の DevOps インフルエンサー・ ディナーを主催し、DevOps の主要理念を解説するインタラ クティブなオンライン・ワークショップ「DevOps Simulation Experience」の責任者を務めています。 イエンティストです。エンタープライズ規模のメインフレーム、 Unix、PC 環境を中心に 35 年間 IT に携わってきました。現在 はクラウド・コンピューティング、プライバシー、セキュリティ、 分析、IT サプライ・チェーンの合理化に関する研究を行ってい ます。Peter Matthews は『The Innovative CIO』の共著者です。 次のステップ DevOps の本格的な採用が始まりました。 DevOps のビジネス上のメリットとチャンスをすべてをつかめるよう体制は整ってい ますか ?CA Technologies は DevOps の専門技術に基づく製品とソリューションのポートフォリオを確立しています。 お客様が開発と運用のギャップを埋めアプリケーション・エコノミーで優位を保つために、 CA がお手伝いできる内容について は ca.com/jp/contact までお問い合わせください。 CA Technologies の DevOps ソリューションに関する詳細については ca.com/insights/devops をご覧ください。 #BusinessReWrittenBySoftware 2014 年 7 月に行われたディスカッションの後、およびその後の E メールによるインタビューで、寄稿とコメントの依頼を行いました。 Copyright © 2015 CA. All rights reserved. 本書に記載されているすべての商標、商号、サービス・マーク、ロゴは、該当する各社に帰属しています。
© Copyright 2024 ExpyDoc
