デジタルトランスフォーメーションとDevOpsの役割

本記事の原文はコチラ。
Julie O’Brien, SVP of Corporate Marketing
Sachin Chheda, Senior Director of Global Accounts and Industry Marketing
デジタルトランスフォーメーション(DX)は組織が大規模なオーバーホールとして試験的ーかつー本当のビジネスモデルと日々のプロセスの運用を考え直すきっかけとなりました。これまでの製品は新たな情報とサービス駆動の提供物で置き換えられていきます。特にコモディティ化が大規模に進む市場において顕著です。例えば流通産業においては様々な企業が製品の再パッケージ化、革新的な購入方法を模索しており、買い手のためのインテリジェントな推薦機能を追加しています。先進的な分析機能や機械学習、IoT/先進的センサー、普遍的な接続性などのテクノロジーのおかげで流通企業は店頭以外でも顧客にターゲットを定めることができ、在庫状況と顧客の振る舞いをベースに自動的なオーダーを行えるようにまでなっています。
DXの新興とIoTやデータ処理、可視化などのそれを支えるテクノロジーによって、ソフトウェアの開発はどんどん重要になってきています。新しいアプリケションとサービスを迅速に提供するために、ITチームはDevOpsモデルへと移行し開発と運用の間のギャップを埋めようとしています。
一体DevOpsとは何なのでしょうか？WikipediaによるとDevOpsは「ソフトウェアの開発」と「ITの運用」を融合させるもので、この組み合わせによってITのカルチャーとテクノロジーを開発チームと運用チーム間の摩擦のない、新しい機能やサービスの提供を加速するためのものへと変化させることだとしています。正しく実行されれば特定の組織が責任を追うような状態ではなく、コラボレーションや自動化が実現されるとしています。
潜在的な効果は膨大です：

• アクセスの自由化とセルフサービス。開発と検証の環境が開発者、検証チーム、運用チームに必要に応じて作成され、アジャイルな開発手法の利用が進みます。
• 高速な繰り返しとリリース。ソースコードのチェックインからリリース、利用に至るまでの検証と製品のリリースが自動化されます。
• 展開からの早期の失敗/修正。自動的な展開(と後戻り)の戦略によってテンポを早めながらリスクを低減します。
• デザインと検証の密な連携。すべての変化は学びと実験の機会、すべてのギャップと間違いは検証、実装、自動化の改善の機会。自動化された運用で監視システムが修復を開始できる。

DevOpsモデルへの移行を成功裏に終わらせるための共通した要素はエグゼクティブクラスによる後押しとアジャイルフレームワークと正しいツール、そしてインフラストラクチャです。それぞれを少しつづ見てみましょう。初めはエグゼクティブクラスの後押しです。

異なる目的を持った様々なグループが介在するあらゆる複雑なプロジェクトの場合と同様に、適切なエグゼクティブと意思決定者のサポート、そして、チーム全体に対しての然るべき姿のビジョンについてのコミニュケーションが非常に重要です。DevOpsは文化のシフトであり、ビジネス部門とソフトウェア開発者、QAとしてIT運用チームの緊密なコラボレーションが必要とされます。アメリカ国家技術賞のLaureate W. Edward Demingsの研究によると、組織の環境が個人の成果に与える影響はその個人自身の環境よりも大きいと判明しています。信条や文化は粘着質なもので変えるのが難しいだけでなく、また一方でスポンサーから組織の階層の下の方に至るまでの一貫性を維持しながら、明確に、そして正確にビジョン、変化の必要性と現実、それを受け入れることの安全性についてのコミニュケーションをはかりながら組織をDevOpsに向けた準備をさせていくことは非常に長い道のりになります。
うまくいくDevOpsモデルの根幹は迅速なソフトウェア開発手法であり、それはプロダクトとソリューションを様々な多様性を持つチームの中で進化させていくという信条から成り立っています。手法にはいくつかのヴァリエーションがある一方で、その効果はいかのようにまとめることができます：

1. チームを自己組織型組織化、コミニュケーション、コラボレーションを活性化
2. 顧客との緊密なコラボレーション(例：機能と品質についてのフィードバックループ)
3. 変化し続けるニーズへの迅速な応対(例 : イノベーションの継続)
4. 頻繁なソフトウェア提供 (例 : 継続的な統合と継続的な提供 - CI/CD)
5. "動き続ける"ソフトウェアであるということが成功の真の証明
6. 開発のドキュメント化も並行して実施、軽量だが効率的なレベルで

DevOpsの思想はアジャイルソフトウェア開発フレームワークとして運用化されます。アジャイルスクラムはプロダクトオーナーが広範なチームと緊密に連携し合うためのプロセスであり、チームが動き続けるソフトウェアの提供のために「疾走」するために、新しい機能のペイロードやバックログ(機能開発リスト)の特定や、バグ修正、または他の要件などを提供します。役割の違うチームの交流 ー ソフトウェア開発者、IT運用者、他をふくむ ー はこのバックログを短期間に(大抵の場合30日未満で)実行します。このプロセスは何度も何度も繰り返され、プロダクトオーナーはバックログをチームや顧客のニーズに合わせて優先順位付けし直します。

一回の疾走は継続的な開発と継続的な統合、継続的な検証、継続的な展開と運用から成り立ちます。さらに開発、検証、ステージング、本稼働の全てにわたるライフサイクル継続的なフィードバックループを行ないます。こうした疾走から生まれてきた新しいソフトウェアを大規模に展開する前に小さめの「カナリー」セットへと展開し、機能やパフォーマンスの確認を行ないます。同様にチームは軽量なカナリーテストを走らせ、プロセスやコードの確認を詳細なテストを実施する前に行ないます。

スクラムフレームワークにはスクラムマスターという、チームのファシリテーター、教育者となるべき役割が必要とされます。ファシリテーターはプロダクトオーナーと同じである必要はありません。明確で、頻繁にかわされるチームメンバー間のコミニュケーションは開発とリリースのサイクルが早い事を考えると基盤とも呼べるものになります。これはしばしばちょっとした立ちながらのミーティングで日々の進捗や目標をスクラムマスターがファシリテートする事によって確認されていきます。こうした形でのコミニュケーションは様々な場所 ー 製造業（自動車）、研究グループ(NASA, USエネルギー省)、それ以外でも育まれてきました。DevOpsモデルでは更にソフトウェア開発者とIT運用者そして、プロダクトオーナーを含みます。彼らの緊密なコラボレーションは先に述べたような文化やプロセスによって成り立っているのです。

組織がDevOpsを成功裏に展開する最後の、そして重要な要素はツールとインフラストラクチャです。次のパート2のブログシリーズではDevOpsモデルへのシフトを手助けするツールとインフラストラクチャについて見ていきましょう。

© 2018 Nutanix, Inc. All rights reserved. Nutanix and the Nutanix logo are registered trademarks or trademarks of Nutanix, Inc. in the United States and other countries. All other brand names mentioned herein are for identification purposes only and may be the trademarks of their respective holder(s).