DevOpsの本質は“どのツールを使うか”ではない
前佛：まずOpsのほうは「もっと元気出せよ！」という感じでしょうか。今はどちらかというと開発ツールやインフラの部分がフォーカスされていて、それらに加えてOpsがあるというような状況です。
吉羽隆太郎氏
吉羽：DevOpsがバズワード化していますよね。IoTやビッグデータと並んでDevOpsがある。IT業界の3大「金の儲かるキーワード」的な扱いです。
DevOpsの本質はどんなツールを使うかではなく“文化”です。DevOpsが文化になれば、組織変革にもつながる。企業の中の開発部隊や運用部隊にDevOpsのツールを売りつけるのではなく、経営層にDevOpsの文化を持っていかなければだめだと思います。「これからはDevOps的な考え方でやっていかないと会社が死ぬよ」という感じで。DevOpsで文化の話が抜けているのが、今の大きな問題だと思っています。
牛尾：「DevOpsを導入している」というお客様を訪問すると実態はバージョン管理ツールを入れてるだけというケースも良くあります。「では、アイデアを思いついてから、実際に本番環境にデプロイするリードタイムはどれぐらいですか？」と聞くと「8カ月くらいかかる」という話もあって、何がDevOpsなんだろうと思うこともあります。
吉羽：DevOpsは、明確な定義がないのがいけないのかもしれませんね。“どうすればDevOpsなのか”がはっきりしない。2009年にFlickrのエンジニアが発表した「10 deploys per day」を参照することが多いけど粒度の違うものがいろいろ混じっていて分かりにくい。ただ、その後、DevOpsの要素として「カルチャー」「リーン」「オートメーション」「メジャーメント」「共有」が示されて、この5つのキーワードが重要だという認識で落ち着いてはきました。
牛尾：私は最近は、Gene Kimの3waysが気に入っています（参考）。1 wayが「リードタイムの短縮」、2 wayが「本番環境やユーザーからの学び」、3 wayが「継続的な実験と検証」です。リードタイムをまずは短縮する、次の段階ではそれを使ってもらいフィードバックを受ける。3段階目ではフィードバックを受けどんどんサイクルを回すのです。
通常に言われる10 deploys per dayとかだと、リードタイムの短縮までの話なんですね。ただ、その先には2 way、3 wayがあります。私が個人的にMSの中で一番のDevOpsチームだと思っている、Visual Studio Team Servicesのチームは3 wayまで実践している素晴らしいチームです。こういったことも伝えていきたいですね。
高添修氏
高添：エンタープライズのユーザー企業によっては、運用はどこかにやってもらえばよいと考えていますよね。なので、あまり運用を革新することに興味がない。開発と運用の両方を別々のIT企業に任せるような状況に対しては、ITで両者をつなぎましょうって言ったりします。たとえばコンテナを使えばContainer commandで簡単にDev とOpsをつなぐことができますよね。現場のエンジニアにとって、このシンプルさも大事だと思います。
吉羽：企業のIT環境でも、いまはクラウド技術を使って簡単にインフラは手に入ります。新しい環境をプロビジョニングするのに、技術的には5分もかからない。それなのに実際は新しい環境が欲しいと申請して、それが承認されるとベンダーに頼んでプロビジョニングしてもらう。こんなことをしているので何カ月もかかってしまいます。エンタープライズの世界に入ってしまうと、システムを構築して利用できるようにする一連の流れがとてつもなく長い。開発はその一部に過ぎません。
だから開発をどんなに速くしても、全体にはほとんど影響しないのですよね。つまり、DevOpsは、Devのところを改善しようという話ではなく、それ以外のところにある問題に気付いて是正する取り組みです。その点をMSにはもっと強く主張してほしいです。
牛尾剛氏
牛尾：MSも、その点で同じ問題意識を持っています。
私のミッションは、日本で良い DevOpsの事例を作ることなのですが、その一環として、特にMSにとっていい事例になっていただけるお客様のところでバリューストリームマッピングというサービスを実施しています。これは、アイデアを思いついてから、実際に本番にリリースされるプロセスを見える化して、無駄がどこにあるか発見していきます。その発見した無駄をハックフェストというお客様の社内で実施するハッカソンを通じて、ビジネスルール含めた無駄取りを行い、自動化を支援するようなことをしています。
実際、先日いい事例がありました。バリューストリームマッピングを実施する際には、現場の開発担当者や運用担当者だけではなく、マネージャーや経営層も呼んで実施します。先日はCEO (最高経営責任者）まで出席していただけました。バリューストリームマッピングを実施すると、プロセスの無駄が明確に見えてきます。現場のメンバーからすると、「会社のルールだから変えられない」と思い込んでいることも、経営層からしたら「どうでもいい」と思うこともあります。そういうメンバーが一同に会してディスカッションすると、現行８か月以上かかっているプロセスが実は１週間に短縮できることに気づくことができました。
このように、DevOps の本質をとらえることで、企業がもっとバリューを生み出せるようになるといいですね。
開発の一括外出しはダメ
吉羽：エンタープライズの世界には、闇がいっぱいあるように思いますね。開発を全部外出ししていて、それでいいのかと。その会社にとってビジネスのコアではないところは、たしかに外出しでもいいでしょう。でも、ビジネスの源泉になるところはそうじゃない。外出しして作ると、ベンダーロックインになってしまう心配もあります。
ベンダーロックインの何が心配かというと、今はオープン化が進んでいるのでテクノロジ面はあまりロックされないのですが、それよりもノウハウをロックインされてしまうのが困ります。外に出すとしても、受託形式で一括に外に出すのはダメ。せめて同じ部屋で社内のエンジニアと一緒に開発するようにしないと。
高添：丸投げや、安いところに依頼するという発想になってしまうのは良くないですね。自分たちが一緒にやるべきところはどこなのか、依頼する側の発想から変えていかないと。
牛尾：私が以前関わった大手企業では、請負形式の発注をやめて準委任契約を採用し、自分のところでリスクを受け入れて、おなじみ先ではなく新たに選定した技術的に優れたエンジニアがいる会社さんと仕事をするように変えました。また、内製化を進めてプロパーの社員の方が、それらのエンジニアと一緒に開発をする体制に移行しました。このように開発することで、アジャイルや、DevOps の素晴らしい実践をすることができて、効果を上げておられます。このような会社さんの実践が広まるといいなと思います。
吉羽：一括で外に出すより、1カ月いくらで優秀なエンジニアに来てもらったほうがリスクも少ないですよ。一括だと高いお金を払って、いいものができるのを待つしかないですから。
高添：そういう意味ではクラウドの登場は、企業の開発に対する考え方を変えるきっかけになっています。時間をかけずに開発のプロセスを回すことが、クラウドを活用すると実現できる。
