DevOps実践の鍵と、情シスの新しい役割：特集：DevOpsで変わる情シスの未来（4）（1/3 ページ）

動き続けるビジネスに対応するために、開発と運用が連携してリリースサイクルを速めるDevOps。だが、その適用が組織の仕組み・ルールとして難しい場合、どのようにこの概念を受け止めればよいのだろうか？ アジャイル開発の国内第一人者、平鍋健児氏に聞いた。

[内野宏信，＠IT]

　「DevOps」という概念が注目されて久しい。各種メディア、イベントなどで取り上げられる機会も増え、「開発部門と運用部門が連携してITサービスのリリースサイクルを速める」という基本概念は着実に浸透しつつある。

　ただ、この言葉に共感する人も多い半面、半ば冷めた目で見る向きも少なくないようだ。例えば「システム開発を社外のSIerに託している」「ITガバナンス面での配慮から開発と運用の業務範囲を明確に切り分けている」など、両部門の連携が組織の仕組みとして難しいケースも多い。「市場変化のスピードに対応するために、開発部門と運用部門が連携する」と言えば聞こえはいいが、そうした事情が「理想」「先進企業のもの」などと、DevOpsが特別視される1つの要因になっているといえるだろう。

　だが、いくら実践が難しいといっても、市場環境変化のスピードが変わるわけではないし、DevOpsが示す開発・運用の在り方が、ビジネスで勝ち残るための1つのポイントとなっていることは間違いない。では、「Webサービス系の先進企業」ではない大方の企業では、この言葉をどのように受け止めればよいのだろうか？――アジャイル開発の国内第一人者である平鍋健児氏に話を聞いた。

DevOpsが難しい現実的な理由

編集部　平鍋さんは、昨今の市場環境変化のスピードが開発・運用現場に与える影響をどのように捉えていらっしゃいますか？

平鍋氏　システム開発では「要求を取りまとめる」「設計する」「作る」「テストする」「リリースする」といった一連のプロセスがあります。しかし近年は、こうしたプロセスを時間をかけて実行している間に状況が変化し、リリースしたころにはニーズと懸け離れたシステムになっている、といったことが起こりやすくなっています。換言すれば、「しっかりと要件を定めて、しっかりと作り、しっかりとテストすればいいものができる」という「しっかりドグマ」――と、私は呼んでいるのですが――つまり「システムには“正解”がある」といった考え方自体が、こうした時代においては一種の幻想になっている、ともいえると思います。

平鍋健児氏

　もちろん基幹システムのように、一連のプロセスを確実にこなすべき「正解があるシステム」もたくさんあります。ただ、そうした類のシステムを除いて、“市場変化に合わせて動き続けるビジネス”に応えるためのシステムについては、実際にリリースしてみなければ分からないケースの方が圧倒的に多くなっている。

　つまり「正解」は開発関係者の頭の中ではなく、エンドユーザーや市場の中にある。従って、システムを「使う人」との対話なしに正しいと思われるものを作ったところで、その効用を期待しにくい状況になっているといえます。

　周知の通り、これまでは数十〜数百ページにもわたる仕様書を書いて、皆でレビューして、順を追って作り、テストをするといった「一連のプロセスを確実に踏む」ことが「しっかり作る」ことでした。今はこの「しっかり作る」の意味が変容しているのではないでしょうか。つまり、市場環境変化の影響をさほど受けない「止まっている課題」を解くためのシステム開発にはウォーターフォールのアプローチが適していますが、「動いている課題」に対してはウォーターフォールのような結果を決め打ちした方法は適さない。アジャイル開発や、それを核とするDevOpsは、そうした「動き続けるビジネス」に追従するシステムを作る手段として、多くの企業にとって不可欠なものになりつつあるわけです。

編集部　ただ、「開発・運用部門が連携してITサービスのリリースサイクルを加速させる」といったDevOpsの基本概念は、適用しやすい業種が絞られるように思うのですが。

平鍋氏　そうですね。例えば、DevOpsの実践事例が目立つWebサービス分野の企業は、相対的に適用しやすい業種といえると思います。というのも、こうした各社はエンジニアを積極的に雇用しています。つまり、企画をする「ビジネスを考える人」と、開発を行う「システムを作る人」、運用をする「システムを提供する人」が全て同じ会社の中にいるケースが多い。この点でゴールを共有しやすいですし、物理的にも連携・協働しやすい環境にあります。

　しかしメーカー、金融、小売りといったWebサービス分野以外の企業の場合、社内に情報システム部門があっても、開発作業は社外のSIerに発注している例が多いですよね。一次受けのSIerが開発業務を分割して複数の開発会社に発注し、各社を束ねてプロジェクトを運用して最終納品責任を持つ、といったケースも一般的です。そして運用の部分は自社であったり、あるいはBPO（Business Process Outsourcing）として外部委託していたりするケースもあるようです。こうした環境では確かにアジャイルやDevOpsは適用が非常に難しくなると思います。

　最大の原因は、「ビジネスを考える人」「システムを作る人」の間に、「発注」という壁ができてしまうことです。つまり両者のゴールが一致しない。例えば発注元企業にとっては「収益向上」「業務効率化」などがゴールでも、SIerにとっては「発注仕様書を満たし、期日通りに納品すること」がゴールです。「発注」「契約」という壁で区切られているため、一体感の醸成が難しいのです。リリースした後、「システムを提供する」立場になる運用部門もそうです。DevOpsで問題としているのは、社内で別部門として機能している「開発」と「運用」の間の壁ですが、こうした事情があると一緒に考えて「いいゴールを探そう、目指そう」という形にはなかなかなりにくいわけです。