私がユーザー企業の経営者や技術者と話す中で分かったのは、彼らが抱く“期待”というのは、おおむねサービスのQCD(Quality:品質、Cost:費用、Delivery:納期)に依存しているということです。要するに「迅速性」を高めた新規サービス開発なのか、「品質改善」を求めた安定的なサービス運用なのか、または「コスト削減」を軸としたプロセス改善なのかの3つに大別できるのです。
もちろん、全てを一度に改善できることがベストではありますが、DevOpsの取り組み自体が、いきなり明日にでも結果を出せるような“銀の弾丸”ではありません。むしろ、一度試した結果をもとに、フィードバックのサイクルを細かく回すことによって投資対効果を図り、改善し続けることがDevOpsのベストプラクティスでもあります。
しかし、DevOpsの概念を理解しているにもかかわらず、このQCD改善の良い局面だけを上申の理由として取り上げ、はやりのITツールを導入したい、という企業が後を絶ちません。
例えば、打ち合わせの中で「インフラの運用コストを削減したいから、Ansible(構成管理自動化ツール)を利用した自動化を導入したい」といった要望や「迅速なアプリケーション開発のためにKubernetes(コンテナオーケストレーション基盤)を導入したい」といった話が、実際によく出てきます。
しかし、こうした抽象的な導入理由だけでは、QCDの本質的な改善には至らず、コンサルティング費用やツールのライセンスに多額のコストを掛けてしまうだけで終わる可能性も高いのです。
もちろん、スモールスタートで部分的に導入し、トライ・アンド・エラーを繰り返しながら、規模を拡大していく方法もありますが、導入規模にかかわらず、投資対効果を測る具体的なKPIを設定しなければ、改善するどころかムダな初期コストだけを費やしてしまう可能性は否めません。
「迅速性」を高めたければ、人手を介した承認プロセスの把握とデプロイプロセス時間の改善。「品質」を改善したければ、テストの自動化を主体とした手動オペレーション時間の排除とバグ改修率の推移。「コスト」を削減したければ、運用にかかる人件費の削減――といったように、自動化に関わる人的リソースやプロセスのKPIを可視化しなければ、投資判断がいつまでもたってもできないのです。
逆にこうしたKPIの共有を徹底し、自動化の恩恵として、これまでの運用工数を開発工数に配分するところまで考えられれば、リソースの有効活用とともにサービスの迅速性、品質向上までが同時に機能するようになります。ただし、このKPIの中には「従業員のモチベーション」も含まれるため、業界特性やチームの構成メンバーによっても、大きく進捗が異なることには注意してください。
DevOpsは、パッケージ製品のように、導入した次の日から改善に効くようなソリューションではありません。特にエンタープライズ企業では、外的要因による慎重な対応が求められるケースも多いことから、リスクを減らした方法にした結果、改善効果も薄くなってしまうことも多いです。
ただし、投資対効果の大小にかかわらず、DevOpsは各企業に適したKPIを策定し、可視化することで効果を高めていく改善プロセスです。そのため、ベンダー側に事例を求め、市場が飽和するのを待つのではなく、まずは自社の戦略と企業のKPIを見直すことがDevOpsの恩恵を受けるための“第一歩”となるでしょう。次回からは、その一歩を踏み出すための方法について解説していきます。お楽しみに。
楽天株式会社にて国際ECサービスのインフラ部門に入社。主にオープンソースを利用したインフラ基盤やプライベートクラウドの設計、構築、運用を担当。
その後、日本ヒューレット・パッカードにて、金融系システムのプロジェクトリードを経験。仕事に従事しながらグロービス経営大学院でMBAを取得し、現在はテクニカルアーキテクトとしてDevOpsやクラウド、Deep Learning分野をはじめとした、オープンソースソリューションの提案、コンサルティングおよび構築デリバリーを担当している。
また、これまでの業務経験を生かし、教育トレーニングの講師やオープンソース勉強会のリード、アーキテクト育成活動など幅広く活躍している。
著者の北山氏が10月20日、レッドハットのイベントで登壇することになりました。テーマは「Infrastructure as Code」。本物の北山氏を見てみたい!という方は、以下のリンクから内容をチェックしてみてください。
Copyright © ITmedia, Inc. All Rights Reserved.