DevOps再入門〜DevOpsが生きる領域、ITILが生きる領域〜：特集：国内DevOpsを再定義する（2）（2/4 ページ）

[編集部,＠IT]

DevOpsが真価を発揮する領域とは？

編集部　一方で、DevOpsが国内で注目され始めた当初、DevOpsがどのようなシステム開発・運用にも有効なメソッドであるかのような解釈もあったと思います。「DevOpsを適用すべきシステムの領域」は、どのように考えればよいのでしょうか？

長嶋氏　やはり基本的に、変化のスピードが速い、変化が多い領域のシステムの方がDevOpsに向いています。例えば半年に一回、数年に一回といった頻度でリリースするシステムなど、変化の遅い領域のシステムにわざわざDevOpsを適用する必要はないと思います。それよりモバイルアプリケーションやWebシステムなど、コンシューマー向けのフロントシステムなどの方が向いています。ただし、これも変化のスピード、変化の多さだけを基準に考えるのではなく、ビジネスゴールを基に判断することが大切です。

　ガートナーでは、要件に応じてシステムの特性を分けて考える「二つの流儀」という考え方を提唱しています。「モード1」は変化が少なく、確実性、正確性、高品質が求められる領域のシステム。ある程度、コストが高くなったり、サービスの価格が高くなったりすることを許容してでも、確実性や品質を重視するシステムです。象徴的な例としてはメインフレームなどが挙げられます。「モード2」は、品質はそこそこで良いとし、その分、開発・改善のスピードや、より低いコスト、価格競争力、何かあったらサポートなどがすぐに対応する「使いやすさ」などを重視するシステムです。

　モード1、2ともにユーザーの「満足度の高さ」を狙うことは同じですが、モード1が「安心・安全」を狙うのに対し、モード2は「すぐに分かる、できる、使っていて楽しい」といった要素を優先します。

　これを運用の観点で言うと、ITILはモード1、DevOpsはモード2です。優劣の問題ではなく、創出したいメリットとそのためのアプローチの違いであり、それぞれに合う方法を選ぼうということです。DevOpsの適用領域は、スピードが重視され、可用性は99.95％以下、つまり「ある程度、品質が許容できるもの」にDevOpsが向くサービスを見つけられるはずです。

図1　ITILとDevOpsの領域（提供：ガートナー）

　ちなみに、この考え方はDevOpsのような「アプローチ」だけではなく、システムやテクノロジの判断にも使えます。例えばメインフレームはモード1、クラウドはモード2といった具合です。これによって、アプローチや各種テクノロジについて、より目的にかなった適用を考えることができます。

　例えば昨今、「パブリッククラウドのIaaS上でERPを稼働させる」という話を耳にしますが、ERPはモード1、IaaSはモード2といえます。「ERPをクラウドに載せるメリットはどこにあるのか、変化の少ないシステムをIaaS上に載せてコスト削減以外にメリットがあるのか」などが議論になることがあると思います。もちろん、クラウドはさまざまな形態があるため、全てがモード2とは言えない側面があるのは事実ですが、例えば、「クラウドならではのメリットをより生かすことを考えるなら、モード2のアプローチで活用した方が“ユーザーにとっては”より大きなメリットが享受できる」という検討や判断は、なされるべきだと考えます。求める要件によっては例外もありますが、「二つの流儀」の考え方は基本的な判断基準として有効です。

スピードと品質の二軸で適用領域を考える

編集部　昨今は、変化が少なく、システムの安定性やデータ保全性などが強く求められるSystem of Record（以下、SoR）と、ユーザーニーズの変化に応じてスピーディに開発・改善することが重視されるSystem of Engagement（SoE）の二つに分ける考え方が浸透しつつあります。これに当てはめると、DevOpsは基本的にはSoE領域のシステムに向くということでしょうか？

長嶋氏　DevOpsの適用領域の判断について、より詳しく言うと、ガートナーが提唱している「ペース・レイヤ戦略」が役立つと思います。これはシステムの「使用目的」と「変更の頻度」で、アプリケーションのタイプを三つに分類して、それぞれに異なる管理プロセス、ガバナンスプロセスを定義する手法です。

　三つとは、「System of Record（SoR：記録システム）」「System of Differentiation（SoD：差別化システム）」「System of Innovation（SoI：革新システム）」です。「革新システム」の領域に近づくほど「変化のスピード」が求められ、「記録システム」の領域に近づくほど「変化のスピード」は遅くなる。競合他社へのスピーディな差別化を図るためのシステムならSoDあるいはSoI、一度作ったらほとんど変える必要のないシステムはSoRに分けることができます。

図2　DevOpsとITILの適用領域（提供：ガートナー）

　これに開発・運用プロセスを当てはめると、システムの目的がSoIに近づくほどDevOpsが向いており、SoRに近づくほどITILが向いていると判断できます。前述のように優劣の問題ではないですし、「必ずどちらかに絞るべき」といったゼロ百の問題でもありません。例えば、SoIでもITILが役に立たないわけではなく、SoRでもDevOpsが役に立たないわけではありません。しかしSoIでよりメリットが出やすい、成果を上げやすいのはDevOpsであり、SoRの場合はITILと言うことができます。まずは、これを基準にDevOpsの適用領域を探してみるのが有効だと思います。