DevOpsが浸透しない「本当の理由」：特集：DevOpsで変わる情シスの未来（9）（2/3 ページ）
欧米では業種を問わず、多くの企業に浸透しているのに対し、国内ではいまだバズワードと見られているDevOps。その真因とは何か？ アジャイル開発、DevOpsに深い知見を持つ、日本HPの藤井智弘氏が「DevOpsの誤解」の真因を喝破する。
なぜDevOpsが必要なのか？ 理由と手段を認識しているか？
編集部 確かにこれまでは「自社ビジネスの目的は何か」「スピーディに差別化を図るためにはどうすればよいのか」といった目的や方法論より、言葉や概念そのもの、またツールの話ばかりが先行する傾向が強かったですね。
藤井氏 そうですね。「なぜ自社はDevOpsが必要なのか、なぜ取り入れるのか」を突き詰めて考えなければ、実現にはつながりませんし、たとえマネジャー層が「DevOpsを取り入れよう」とだけ訴えたところで現場は変わりません。まずは「ITで自社ビジネスの競争力を高める」「どんどんサービスを出して先行者利益を狙う」など目的を明確化する。その上で、「ウオーターフォールではその目的を実現できないから、アジャイルが適している」「運用への成果物引き渡しのフローをもっと短期化できないか」「では具体的にどうすればいいか」といった具合に判断する。目的と手段をロジカルに考え、共有していかなければ現場には決して浸透しません。
またマネジャー層は、ビジネス部門も含めて目的を共有・調整する必要もあります。例えば「頻繁に開発成果物をチェックできるから手戻りが少ない」といっても、それは開発者側の論理で、ビジネス部門から見たら面倒くさいだけでしょう。しかし「短いスパンで開発成果物に触れることが、自分のビジネスにおいてどのような意義を持つのか」「自分の顧客の満足度向上に、どのようにつながるのか」といった“目的”を共有し、その意義が同意されていれば、面倒くさいとは思わないはずです。
編集部 つまり概念が先行してしまって、「自社の場合は、なぜ行うのか」「どのように行うのか」というリアリティある議論に踏み込めなかったということですね。
藤井氏 結局、DevOpsは「開発と運用が連携してビジネスに貢献しよう」といったスローガンに終わってきたと思うんです。しかし「ビジネスにITで貢献しよう」とはずっと以前から意識されてきましたし、開発も運用もコスト削減、安定稼働という目標をずっと持ち続けてきました。それがなぜ今、開発と運用を連携させる必要が出てきたのか？ その唯一の答えは「スピード」です。
そのスピードを出すための手段として、自動化があり、開発・運用ルールの見直しがあり、人のロールモデルの変化がある。これらを考え、実践することがDevOpsであり、「自動化ツールを使うこと」とか「開発と運用が協力してビジネスに寄与すること」という“そもそも論”は一要素でしかないんですね。
編集部 DevOpsの定義がいたずらに拡大してしまった原因も、そうしたスピードが必要という目的意識や、「DevOpsが必要な理由」に対する意識が希薄だった点にあるのかもしれませんね。目的に対してウオーターフォールではできないことがあるから、アジャイル＆DevOpsを選ぶのであって、「ウオーターフォールかアジャイルか」といった優劣の話でもないんですね。
藤井氏 そうですね。自分たちの置かれた文脈――ビジネス上の競争の度合いとか時間感覚とか――が、以前とは変わってきているという意識を持つことも重要です。例えばアジャイルにおける典型的な議論として、プロダクトの仕様を決めるプロダクトオーナーをSIer側が担うのか、エンドユーザー側が担うのか、という話がありますが、そうした議論が出てくるうちは実践は難しいと思います。プロダクトオーナーとは自分たちの予算の使い道を決める役割ですから、本来、エンドユーザー側が担うべき役割なんです。
運用部門の担当者も「安全第一」主義から「品質、安定、スピード」の3要素を実現するために何を変えるべきかという視点を持つべきです。「スピーディに差別化を図るためにどう開発・運用するか、そのために必要な人のロールは何か、自分たちの振る舞いがどう変わるのか」を、ユーザー側が主体的かつ具体的に考えられなければ、DevOpsは進みません。
開発スピードの向上で、あらためて問われる「品質」の意味
編集部 ではビジネス展開のスピードを担保するために、どのような取り組みがポイントになるのでしょう？
藤井氏 DevOpsの議論がご指摘のようにいたずらに拡大している理由の一つは、ITの活動の全体感とその中でのアジャイルやDevOpsの位置付けが、不明確なまま、個別にテーマを議論しているからだと感じます。ここで全体感というのは、ビジネス部門、開発部門、運用部門といった各部門が出すべきバリューを明確化した上で、それらがお互いにきちんとつながっていくことによって最終的なビジネス目的を達成するという、いわば“大きな地図”のことです。HPでは「ITバリューチェーン」という考え方を提唱していて、お客さま企業とともに標準モデルの検討を進めています。DevOpsがシステムライフサイクル全体であるかのような言われ方もしていますが、本来DevOpsという言葉で提起されていた領域は、そうしたバリューチェーンの一部であり、DevOpsの範囲は明確に決まっていたはずです。
編集部 具体的には、どのような取り組みがDevOpsなのでしょうか？
藤井氏 まずDevOpsで最も大切なのはスピードです。これにはよく言われるツールによる自動化と人的側面を含めたプロセスの最適化が必要です。短期間で作れば作るほど、品質にセンシティブにならないと、品質の悪いソフトウエアを短いスパンでリリースすることになり、ロイヤルティや収益向上どころか、マーケットでの信頼失墜を招くことになります。
そこでHPでは、特にDevOpsの文脈では「高品質を担保したリリースプロセスの実現」にフォーカスしています。このためには、デプロイ自動化ツールによってデプロイ方法を標準化・仕組み化し、スピーディにデプロイする一方で、「開発のどのステージで、どのようなテストを行うか」を定義するビルド検証という仕組みを取り入れて、ツールで双方の仕組みを自動化し確実に統制することが重要になります。
二つ目は人的側面を含めたプロセスです。DevOpsの自動化では、従来の開発と運用の境界が変わってきます。従って単純に自動化するだけではなく、双方の責任範囲の整理が必要になります。ですからある程度の規模でDevOpsを推進・展開していくためには、前述した“大きな地図”も意識しながら開発と運用各々のミッションとそれにひも付く活動を定常的に整理して、段階的に権限の委譲を行っていくような成熟度モデルアプローチも必要だと考えます。
加えて重要なのは監視です。運用中のサービスの監視は、DevOpsか否かにかかわらず重要な要素ですが、「リリースした開発成果物が期待する能力を出しているのか」という監視結果が開発側へのフィードバックになるわけですから、短期開発、短期リリースという観点に立つほど「品質をモニタリングする」ことが不可欠になります。
編集部 ここでいう「品質」とは、どのようなものを指すのでしょう？
藤井氏 少々乱暴にまとめると「良いモノがキチンと動くこと」となりますが、「“良いモノ”とは何か？」「“キチンと動く”とはどういう状態か？」の二つの観点があります。
従来の考え方だと「事前に規定された機能が、ある環境条件下で動いている」ことが重要でした。サービスが動いているかどうかは、前述した監視機能でウオッチし、何かあれば手を打つことができます。しかし、「良いモノ」という観点を考えると、「運用中に得られたユーザーからのフィードバックをいかに迅速に取り込めるか」という点がとても重要です。その意味で、運用における監視も「伝統的な意味での“監視”」と、「フィードバックへの対応率やそれによる満足度」という指標が加味されることが望ましいと考えています。
Copyright © ITmedia, Inc. All Rights Reserved.