開発・運用に欠かせない課題解決、たった4つのポイント：開発を迅速化できないのは「DevOps」のせい！？

DevOpsという言葉が“バズワード”となって久しい。その背景にあるのは「開発と運用を自社内に持つ企業のもの」「一部Webサービス系企業のもの」といった考え方だ。だが現在、市場環境が開発・運用にスピードを求めているのは事実。こうした中で、一番大切なのは「DevOps」という言葉を完全に忘れてしまうことだ。

[PR/＠IT]

「DevOps」に取り組もう――その考えこそが間違いの元!?

　2013年ごろから、国内でも「DevOpsをエンタープライズ領域にいかに適用するか」という意識が広がっている。開発と運用が連携して、ITシステムを素早くリリースすることで、市場あるいはエンドユーザーからのフィードバックを受け、継続的なシステム改善を狙う。こうした改善のフィードバックサイクルをスピーディに回すことが、変化が速いニーズに追従する上で大きなポイントとなる――「DevOps」という言葉とともに、そうした考え方と狙いは多くの企業に浸透した。

　だが実際に取り組みを進め、成果を出している国内企業はまだ多いとはいえない。それどころか、「開発と運用が同じ会社の中にいるWebサービス系企業のもの」「非現実的」といった見解に象徴されるように、「DevOps」という言葉に拒否反応を示してしまっている企業が少なくない。

日本IBM コンサルティングITスペシャリスト 今村智氏

　そうした現状に対して、「『DevOps』という言葉に引きずられ過ぎているのではないか。そのために“システム開発・運用の本質”から視線がそれてしまっている傾向が強いのではないか」と指摘するのが、日本IBM コンサルティングITスペシャリストの今村智氏（クラウド事業統括クラウド・ソフトウェア事業部第一テクニカル・ソフトウェア）だ。今村氏は、こう続ける。

　「システム開発の目的は、ITを使って市場ニーズやビジネス課題にスピーディに応えること。そのための取り組みが、ある切り口から見ればアジャイルとなり、別の切り口から見ればDevOpsと呼ばれている。しかし何より重要なのは、そうした言葉や概念ではありません。“自社が”市場に追従するためのベストプラクティスは何か、“自社にとって”、どのような開発・運用の在り方がフィットするのかを見定めることです」(今村氏)

　「DevOpsに取り組もう」ではなく、「ビジネス要請に対応できる、“自社に適したシステム開発のアプローチ”を見つけ出そう」と考える。そうすることが結果として「DevOpsという取り組み」につながっていく――言葉や考え方が先に立ち、そうした前提が見えにくくなってしまっているのではないか、というわけだ。

　では、スピーディかつ柔軟なビジネス展開を支える上で、開発・運用には具体的に、どのような「解決すべき課題」が存在するのだろうか。今村氏は、ここであらためて多くの企業が陥りがちな4つの課題と解決のアプローチを挙げる。

1.デプロイのプロセスを標準化せよ

　1つ目の課題は、デプロイのプロセス整備だ。開発成果物の迅速な展開を阻むボトルネックの一つは、開発、テスト、ステージング、本番という各環境で、デプロイの基本的な手順がそれぞれ異なる点にある。その都度、異なる手順で実行することになるため、効率が悪い他、人的ミスも誘発しやすくなる。

　ではどうすればよいのか？ 解決策は、「共通のデプロイプロセスを構築すること」だ。開発、テスト、ステージング、本番という各環境の基本的なデプロイプロセスを標準化することで効率性・確実性が高まる。

　「もちろん開発環境と本番環境では、周辺の諸条件が異なる。その場合は、各環境に個別の要素をより分け、例えば入力値や設定を変えるだけで対応できるようにする。こうすることで高速なデプロイを安定して実行できるようになります。さらに、こうしたプロセスを開発部門全体で標準化し、日々実践する。そうすることで、デプロイプロセスを企業として成熟させることができるのです」(今村氏)

2.より早い段階から品質を作り込め

　2つ目の課題はよくいわれる「品質」だ。開発規模が大きくなると、複数の開発パートナーによるモジュールごとの並行開発が行われる例が一般的だ。だがそうしたスタイルでは、単体テストでは動いていたものが、最後の結合テストでまったく動かなくなるといったことが起こりやすい。というのも、データガバナンスの観点から、連携先モジュールのデータを参照できない例も増えるなど、一つのシステムを開発するにもかかわらず、連携先の詳細が分からない状況で開発を進めなければならないケースが多いためだ。

「開発の早い段階から品質を作り込む仕組みを整備することが大切」

　これに対する解決策は、「開発の早い段階から本番と同じインターフェースを作り、最初から品質を作り込んでいくこと」だ。具体的には、設計情報を元に連携先モジュールのスタブを作り、連携先モジュールの振る舞いに対して正確・確実に対応できるか否かを、開発の速い段階からテストしつつ開発を進める。

　「これはサービス仮想化と呼ばれるソリューションによって実現できます。連携先サービスの振る舞いを仮想化して開発の初期段階から用意し、テストに生かすことで、開発の最終段階での問題噴出を防止できるのです。また、現在はインターフェース仕様が一般化し、弊社ソリューションも含め、その多くがXMLでインターフェースを定義できるようになっているなどテストスタブも容易に作ることができます。さらに、テストスタブを自動的に作ったり、一度使ったXMLを加工して別の似たようなモジュールのスタブとして再利用することもできるなど、サービス仮想化そのものも効率化されています。スピーディに開発する上では、本番同様の品質をより早い段階から作り込むアプローチが重要なカギになるのです」

3.限られた情報を確実にシェアせよ

　3つ目の課題は、開発部門と運用部門のコミュニケーションだ。特に大規模システムでは並行開発が一般的な中、各チーム／開発パートナーは、場合によっては物理的にも隔絶されており、コミュニケーションロスが生じやすい環境にある。これにより、各チーム／パートナー同士の情報共有が難しくなっている他、運用部門との理解の齟齬も生じやすい状況にある。ロスが増えれば調整する時間、手間がかかり、冒頭で述べた改善フィードバックサイクルに大きな影響を及ぼすことになる。

　今村氏は、こうしたコミュニケーションの問題については、「必要な情報の共有だけを考えることがポイントだ」とアドバイスする。

　「DevOpsでは、主に文化の側面において、情報共有の重要性が指摘されてきました。しかし、ここも概念にとらわれる必要はありません。そもそも活動サイクルが異なるチーム同士が密接に情報共有する必要はありません。2つの開発チーム間ですら、シェアすべき情報はかなり限定的な場合が多いのです。ましてや開発チームと運用チームが全ての情報を共有する必要はありません」

　では開発と運用が“共有すべき情報”とは何か？ それは言うまでもなくデプロイ／リリースするシステムに関わる情報だ。デプロイ／リリースの方法、障害が起きた際の切り戻しなどの対処方法などを共有しておけば、開発と運用のコミュニケーションは十分に成り立つ。一方で、開発チームの稼働状況やバグ発生率といったことまでは、運用チームが知る必要はない。情報を両者で絞り込んだ上で、必要なものだけを確実に共有できればいい。これによってそれぞれが自身の業務を滞りなく進めることができる。

4.ビジネスからのフィードバックを“正しく”得よ

　4つ目の課題は、ビジネスとの連携だ。冒頭で述べたITサービスを改善するためのフィードバック作業に当たるが、今村氏によると「ここはしばしば見落とされがち」だという。取り組みとしては、Webやモバイル向けの解析ツールを使って、市場／エンドユーザーの反響を分析し、「改善」の内容を判断する。

「改善要求に“常識”や“先入観”は禁物」

　「改善のポイントは、“実際のデータ”に基づいて判断することです。例えばあるアプリケーション開発において、『あるOSのサポートが切れたから、アプリ開発のターゲットOSから外そう』といった判断はしません。調査をした結果、『サポートが切れたOSでも利用者が多いなら、サポートを継続すべきだ』と判断すべきです。一般的な常識ではなく、あくまで市場の状況、エンドユーザーの声から採るべき施策を判断することが大切です」

　VoC（Voice of Customer）の分析技術など、Webマーケティングの世界で培われたテクノロジが浸透したことで、フィードバックを得る手段が格段に増えている。システムの稼働状況に関しても、「どのようなバージョンの、どのOSで、どのようなタイミングで、どのようなエラーが起きて、いつクラッシュしたか」といったデータまで取得できる。開発へのフィードバックは、こうした情報を適切に活用する必要があるのだ。

ビジネス視点での「仕組み化」が重要

　開発と運用の連携という点では、これら4つの課題以外にも、気を付けるべきポイントは多い。中でも目立つのは「ある特定の領域だけに注目してしまうこと」だという。例えばリリースやデプロイの自動化だけに注目してしまう。

　「開発視点で見ると、リリースとデプロイを自動化することで自分たちのプロセスが迅速化すると考えられます。ただ運用視点で見ると、これらはリリース管理、変更管理といった運用業務の一部にすぎず、その後の安定運用の方が大変だという声が多いはずです。ここで大切なのは、自分は開発だから、自分は運用だから、という視点で考えないこと。自動化は連携をスムーズに行うための手段にすぎません。あくまでビジネスという最終的なゴールを見据えて、そのためにやるべきことは何かと考えることが大切です」

　開発と運用がお互いに主張し続ければ、連携どころではなくなる。特に「DevOps」は開発側が運用領域に踏み込む趣が強いことから、運用部門の"人減らし策"に短絡化しやすい側面もある。実際に運用部門を外注化し、開発部門にリソースを集中することで成果を挙げている企業もある。だがそれは、開発と運用、それぞれの視点からではなく、あくまで「ビジネスにどう貢献するか、そのためにはどのようなどのような開発・運用スタンスが最適か」という観点からなされた決定であることが多い。少なくとも、「DevOps実現のために、という発想ではない」。

　「開発チーム、運用チームではなく、あくまでビジネスにどう貢献するかを考えることが重要。それに応じて、自社の目的、開発・運用体制に最適な、“一連のフィードバックサイクルを円滑に、手違いなく回すための仕組み”を構築する。各種自動化などはそのための一手段として取り入れる捉えることが大切です」(今村氏)

システム開発・運用は、ユーザー企業主導であるべき

　以上のような指摘に続けて、今村氏は「開発・運用の担い手はユーザー企業であるべき」と主張する。だがこれは、必ずしも「全てを自社内で行うべきだ」という意味ではない。

　一般に、米国企業の開発スピードに比べて、国内企業の動きが遅くなりがちな背景の一つとして、日本特有の受託開発がある。米国のユーザー企業は開発・運用部門を自社内に抱えるのに対し、国内企業の多くは開発をSIに依頼し、運用も異なる組織に依頼するケースが少なくない。そうした組織的事情も手伝い、米国企業では開発・運用の利害が一致しやすいが、国内企業の場合、開発・運用の利害が一致しないため、そもそも連携を図りにくいという問題もある。だが、今村氏は「だからこそ、ユーザー企業が取り組みをリードすべきだ」訴える。

「開発・運用の連携プロセスを自ら仕組み化し、そこにパートナーSI／ベンダーを組み込んでいく。これがベンダーロックインを回避しながら“自社が本当にやりたいこと”を実現することにつながる」

　「基本的に、ベンダーやパートナーは、ユーザー企業の決定を実現することに最大限の力を注ぎます。しかしこれは、ユーザー企業が自ら音頭を取ることで、ビジネス目標に役立つシステムを開発しやすくなるということでもあります。つまり、外部に任せきりにするのではなく、どうすれば役立つものを速く、確実にリリースできるのかを自ら考える。そのために開発・運用の連携プロセスを自ら仕組み化し、そこにパートナーSI／ベンダーを組み込んでいく――このように自ら主導権を握って、その実現方法を仕組み化することが、ベンダーロックインを回避しながら、本当にやりたいビジネスを実現することにつながるのです」

　この旗振り役となるべきは、CIO、CTOに代表されるITのトップマネジメントだ。開発・運用という現場レベルでの取り組みだけでは、ビジネス視点での仕組み化はあまりうまく進まない。“ビジネスも含めた一連のフィードバックサイクル”を俯瞰できるトップのエンドースメントを得ることで初めて、現場レベルでの改革が進みやすくなるという。

　仕組み化を支援するツールも出そろっている。IBMが提供するツールとしては、リリース／デプロイ自動化・管理ツール「IBM UrbanCode」、テスト／サービス仮想化ツール「IBM Test Workbench」「IBM Virtual Test Server」、コラボレーションブラットフォームの「IBM Team Concert」などがあるが、これらも必ずしも全て必要というわけではない。自社の状況に応じて選択的に採用すればよいのだ。

　「おおよそ全てのシステムは、収益・ブランド向上に役立てることが目的。そして現在、そうしたビジネスに役立つシステムをいち早くリリースし、改善していかなければなりません。そのために、現在の開発・運用体制で足りないものは何か？――“スピーディにビジネスを展開するための開発・運用の仕組み”を整備する上では、このようにシンプルに考え、課題を見つけて優先順位を付け、一つずつ解決に導いていくスタンスが重要なのです」

　今村氏はこのように述べ、最後にあらためて力説する。

　「このように、DevOpsという言葉にこだわる必要など、まったくないのです。概念をそのまま適用しようと考えるのではなく、自社の目的、組織体制、状況に応じて必要なツールを試しながら、徐々に取り込んでいけばいいと考えます。そして、これは従来から求められてきた開発・運用スタンスと何ら変わりません。一番大切なのはビジネスの推進――この認識を、開発、運用、またトップマネジメント層が、今あらためて持ち直すことが大切なのではないでしょうか」

　ではビジネスを推進するために、具体的には何から取り組むべきなのか？ 以下にはそのヒントがつかめる3本のホワイトペーパーを用意した。簡単なアンケートに応えて今すぐダウンロードし、今の“自社”の開発・運用体制に足りないこと、取り入れるべきことを、あらためて考えてみてはいかがだろうか。

DevOps実現のために必要なアプローチとは

“「DevOps」に対する先入観”を払しょくする
3つのホワイトペーパーをダウンロード

※ダウンロードの際に、簡単なアンケートのご協力をお願いしております。