DevOpsというバズワードに流されないために：特集：DevOpsで変わる情シスの未来（5）（1/4 ページ）

実践事例や有識者へのインタビューを通じて国内のDevOpsトレンドを俯瞰してきた本特集。今回はSIer、ITアーキテクトの観点からDevOpsのあるべき姿を探る。

[内野宏信，＠IT]

DevOpsは理想論？ スローガン？ それともただのバズワード？

　2013年、「DevOps」という言葉の認知度は大幅に向上した。市場環境変化が速い現在、ビジネスニーズの変化をITサービスに反映させるためには、開発・運用のスピードが大きなカギを握る。その点、「開発部門と運用部門が連携してITサービスのリリースサイクルを加速させる」というDevOpsの基本概念は非常に合理的であり、大方にとって理解しやすいものだ。

　ただ、この言葉を半ばバズワードとして受け止める向きも少なくない。確かに「開発と運用が連携する」という概念は、納得しやすく理想的なものではある。だが実際には、多くの企業において「開発を外部に委託している」「ガバナンスやセキュリティ面で連携が難しい、好ましくない」といった現実がある。

　メディアで取り上げられるDevOpsの成功事例にしても、サイバーエージェントやDeNA、ヤフー、楽天といったWebサービス系の企業が目立つ。彼らは「開発部門と運用部門が同じ会社の中にいる」という共通点を持つ。無論、同じ会社の中にいても壁や制約は存在するわけだが、「外部に開発を委託している」ような例に比べれば、相対的に連携しやすい環境にあるのは事実だ。こうした点もDevOpsを他人ごとのように見せてしまう一因となっているのかもしれない。

　とはいえ、市場環境がITサービス開発にスピードと柔軟性を求めていることは間違いない。これに局所的な工夫・改善だけで対応することは難しい。例えば、プログラミングのスピードを速めたところで、リリースサイクルを加速させることは難しい。開発、運用、リリース、フィードバックといった一連のソフトウェアライフサイクルの円環を速く回せる“仕組み”がなければ、ビジネスを支える上で、必ずどこかがボトルネックになってしまうためだ。DevOpsがそうした“仕組み”の在り方を示すものである以上、バズワードと切り捨ててしまう前に、その本質をあらためて見直しておくべきなのではないだろうか。

　4回にわたってDevOpsトレンドをウォッチしてきた特集「DevOpsで変わる情シスの未来」。今回は、多数のシステム開発案件を手掛けるグロースエクスパートナーズ　ビジネスソリューション事業本部 本部長 執行役員でITアーキテクトの鈴木雄介氏にインタビュー。ITアーキテクトとSIerの視点から見た「現実的なDevOps」について話を聞くことで、DevOpsトレンドに対する現時点での1つの結論を出してみたい。

「アプリケーションではなく、サービスを生み出そう」という認識が重要

編集部　鈴木さんはDevOpsという概念をどのように捉えていらっしゃいますか？

グロースエクスパートナーズ　ビジネスソリューション事業本部 本部長 執行役員でITアーキテクトの鈴木雄介氏

鈴木氏　近年の市場環境を見ていると、ニーズに柔軟・迅速に対応するために開発と運用が連携しようといった流れが出てくるのは、ある意味、自然なことだと思います。この言葉をツールや自動化といった文脈で捉える解釈もありますが、基本的には開発部門と運用部門のカルチャーの違いをどう融合していくのか、開発と運用が一緒に物事を考え、業務を行う上ではどうすれば良いのかといったテーマだと理解しています。

　例えば、開発側は1つ1つのアプリケーションの独自性を大事にしますが、運用側は全てのシステムを並行に扱いたい。まずそうした独自性と汎用性という視点の違いがあります。また、開発側はアプリケーションをどんどんリリースしたいと考えますが、運用側は安定運用のために変化を避けたい。

　特にエンタープライズの分野では、セキュリティやガバナンス面でも課題が多いと思います。例えば、運用側はアプリケーションを止めてでもセキュリティ上の対応をしたいが、開発側からすればアプリケーションを止めるなどあり得ない。開発・運用を外部に委託していれば発注・契約という壁もある。こうした壁は流通、通信、金融、医療など、さまざまな業種の開発・運用現場に存在します。

編集部　Webサービス系の企業に成功事例が多いのは、開発部門と運用部門が1つの会社の中にいて、物理的にも文化的にも比較的融合しやすいという見方もありますが。

鈴木氏　そうですね。ただ注意したいのは、「連携しやすい環境にある」からというだけではなく、そうした新しいカルチャーの会社であればあるほど「ソフトウェアを作ろう」というより、「サービスを作って対価を生み出そう」という意識が強いことです。「サービス」にコミットし、そこにプライオリティを置こうと思えば、開発部門と運用部門の業務を明確に切り分けることにあまり意義がなくなってくる。この点で、開発と運用、両方のスキルを持つエンジニアが双方の調停をして、両部門のバランスを取りながら連携・協力させていく取り組みが、ごく自然な流れとして生じやすいのではないでしょうか。

　ただ、そうした企業に限らず、おおよそ全てのアプリケーションはサービスとして提供されない限り、価値が生まれないものです。この点で、ソフトウェア開発を担う全ての企業・組織は、おのずとDevOpsの考え方を取り入れていくようになるべきだと考えます。

編集部　しかし、Webサービス系以外の企業がDevOpsを取り入れるのは、先のような事情もありなかなか難しいですね。

鈴木氏　そうですね。例えば、実際には開発部門と運用部門の壁だけではなく、ビジネスの企画部門と開発部門、インフラ部門、運用部門のそれぞれの間に壁があります。この4部門を連携させるためには、まず「4部門が連携した成果指標」を矛盾なく設定できるか否かが、実現の大きな鍵を握ると思います。またそのためには、4部門を全て見渡せるITアーキテクトのような人材も必要です。各部門の知識を基に各ステークホルダーとコミュニケーションを取り、全体のバランスを調整できなければ、なかなか自社に適したDevOpsの在り方は見つけられないのではないでしょうか。

　ただ、ここで強調したいのは、バズワードに影響されて、DevOps自体が目的化している風潮もあるように感じることです。DevOpsは自社のゴールに照らして、必要に応じて使う方法論にすぎません。リリースとフィードバックループを加速させる必要がある場合にベタープラクティスとして取り入れればよいわけで、例えば1回リリースして完成といったシステムならDevOpsを取り入れる意義は薄いといえます。アーキテクトの観点を持つ人間が、プロジェクトのゴールに最適な方法論を選択することが大前提だと思います。