DevOpsとは？有名企業CTOが語る、DevOps成功の秘訣
2018年10月17日、DevOpsをテーマにしたイベント「CTO meetup～あなたの会社のDevOps～」が開催されました。数名規模のスタートアップから数百名規模の企業まで、それぞれの組織がどのようにDevOpsを実現しているのか、文化やプラクティス、ツールの観点から議論。より効率的に、そして柔軟に開発（Development）と運用（Operation）を進めるために必要な要素について深掘りしていただきました。
目次
登壇者のご紹介
ファシリテーター
パネルディスカッション
あなたの会社のDevOps
各社によって異なるDevOpsの定義とビジネスにおける位置づけ
長沢：みなさん、本日はお集まりいただいてありがとうございます。ファシリテーターの長沢翼と申します。「あらゆるLIFEを、FULLに。」をコーポレートメッセージに掲げ、LIFULL HOME’S という全国の住まい探しができる不動産・住宅情報サイトを中心に、様々なサービスを提供しているLIFULLという会社でCTOを務めています。私はもともとアプリケーションのエンジニアで、LIFULL HOME’SのWebサイトやネイティブアプリを開発したあと、インフラ業務を担当するようになり、オンプレミスからAWSへの移行を担当しました。クラウドを導入する中でDevOpsに関しても試行錯誤を行ってきたので、今回のテーマも馴染み深いところですね。
では、登壇者のみなさまもそれぞれ自己紹介をお願いします。
森山：森山と申します。日本マイクロソフト株式会社パートナー事業部において、独立系ソフトウェアベンダーの方々向けに、Microsoft Azureを用いた製品のSaaS化支援などをしています。SaaS化にあたっては開発と運用をどのように組み合わせていけば良いのか、という悩みの解決にもあたっています。
マイクロソフトにおけるDevOpsについて先に簡単にご説明すると、アメリカのドノーヴァン・ブラウンという方がDevOpsの責任者で、DevOpsに必要な三大要素を「人とプロセス、製品・ツールである」と定義しています。また「DevOpsは人とプロセスと継続的デリバリーの価値をエンドユーザーへ提供するための製品の塊である」とも定義しています。
DevOpsはやはり概念で、文化であり、プロセスであり、ツールであると言えます。正しい方法論は存在しませんが、組織に応じてGrowth mindsetをもって、変化を恐れずにチャレンジしていく文化の醸造がないと、破綻してしまいます。
マイクロソフトが提唱するGrowth mindsetとは、正しくても間違っていても、新しいことにチャレンジしていくこと。マイクロソフトの社員は、Growth mindsetをもってビジネスに取り組んでいこうとしています。これがDevOpsに紐づくマイクロソフトの基本的なメッセージなので、先にご紹介しました。今日はよろしくお願いします。
弓山：弓山です。株式会社レヴィの共同創業者であり、株式会社スタディストの技術顧問も兼任しています。経歴としては、株式会社インターネットイニシアティブで開発を担った後、株式会社クラウドワークスで2年間CTOを務めました。
レヴィは、複数のシステムが複雑に絡み合う中でそれらにどう対処して立ち向かっていくか、という部分のサポートを行うサービス「Balus Mega」の開発を行っています。創業間もない小さなチームで、開発初期は他に本業がある中で週末や平日の夜といった限られた時間でプロジェクトを進めていました。今も少ない人数でプロダクト開発から営業・サポートまでこなしているので、チームメンバーも時間も足りない中でいかにプロダクト開発を効果的に進めるか、そしてスムーズな運用をどのように実現するかを試行錯誤しています。追って詳しくお話していきますが、レヴィにおける組織概要とDevOpsについては以下の図にまとめています。よろしくお願いします。
白井：株式会社サイバーエージェントの白井です。SGE(Smartphone Games & Entertainment)統括本部技術統括室室長をしています。SGEとは、サイバーエージェントにおいてゲーム事業に携わる子会社が所属している組織のことです。私はCTOという立場で、子会社３社を直接見ています。 ゲームづくりにあたって、私自身はずっとサーバーサイドやインフラに携わってきました。ゲーム事業はサイバーエージェントの３本の柱の１つを担う事業にまで成長しているので、今日のテーマであるDevOpsについても、その過程の文脈でお話ができると思います。他の会社さんとの働き方の違いも個人的に興味がある部分です。どうぞよろしくお願いします。
梶原：梶原と申します。株式会社エブリーの取締役CTO兼CHECKカンパニー長です。キャリアはエンジニアからスタートしていて、最初はヤフーに入社。その後グリーで執行役員や開発本部長などを務めました。去年の春にグリーを退職し、エンジェル投資家、技術顧問としてスタートアップ企業の支援を中心とした活動を経て現在に至ります。
エブリーは動画メディア事業をメインとしていて、現在４つの動画メディアを展開しています。有名所はDELISH KITCHENという料理のレシピ動画です。最近は新たにライブコマース事業も立ち上げました。
まだまだエンジニアの人数は少ないため、組織の継続的な改善と安定的な運用の両方が必要になっています。その中でも重要だと思っている３つの要素は、まず新技術を積極的に採用して、常にベストな選択を取り続けること。そして、開発における面倒な部分は積極的にクラウドやSaaS、マネージドサービスなどを使い、自分たちは本当にユーザーのために大切な開発に注力すること。それに関連して、自動化や効率化も重視していますね。
DevOpsについての取り組み内容
効率的により良いプロダクトを生み出すため、開発プロセスに密接に絡むDevOps
長沢：ありがとうございます。では、さっそくパネルディスカッション第一部を開始したいと思います。DevOpsというワードは巷で話題となりはじめてから、それなりの時間を経ていると思いますが、会社によってさまざま定義が異なるものだと思います。それぞれの組織で考えているDevOpsとその取り組みについて、エンジニア規模とシステム規模を交えながらお話しいただけますでしょうか。森山さんからお願いします。
森山：マイクロソフトはWindowsやOfficeなどの非常に大きなプロダクトを持っています。ディベロッパーも数万人規模で抱えていますが、機能ごとにチームがわかれているので、DevOpsの規模でいうと約15名以下のチーム構成ですね。 開発サイクルとしてはまず３～４週間で回すスプリントがあり、それを３ヶ月単位で区切って１つの機能をリリースする流れがあります。エンジニアはその中でずっと雇われているわけではなく、短い人で１年、長い人で２～２年半というスパンでどんどん入れ替わっていきます。そこには、ワールドワイド展開している製品を人の入れ替えによって新鮮な形で開発をしていこう、という意図があります。 入れ替えが激しい中でも破綻しないような開発プロセスが設計されていて、マイクロソフトのブランドであるAzure DevOpsの開発したツールを活用しています。一方でオープンソースのツールも積極的に使っていますね。自分にとって使いやすいツールをどんどん活用していくという動きが、今まさにマイクロソフト社内で起きている変革です。
弓山：私たちの会社は創業者全体で７名。エンジニアは業務委託の方も含めて５名程度です。開発・運用に携わっているメンバーはフルタイムに換算すると２名程でしょうか。機能を開発して、実際にリリースしてエラーが発生すれば、それらの対応もすべて５名のエンジニアで行っています。DevelopmentとOperationsを分けるどころの話ではない状況です。その中で、どうやってお客様に届けるべき価値を作り出す開発の時間を増やすか、という部分を日々工夫しています。 そのための取り組みの一つが、Google App EngineというPaaSを使うという技術選択です。インフラ構築においてはAWSやGCP、Azureなどさまざまなクラウドベンダーがありますが、IaaSにおいてインスタンスを持ってしまうと、どうしてもセキュリティアップデートなどに手間がかかって大変だということはみなさんご存知だと思います。私達の場合はゼロからプロダクトを新しく作り始めるタイミングで、限られたリソースをどこに配分するかを考えた結果、PaaSを使いこなす方向に舵を切りました。
白井：私が所属しているSGEという組織は、規模で言うと、職種を問わず携わっているメンバーは1200名程です。そのうちエンジニアは350名前後。それぞれの会社の規模は、小さくて10名規模、大きくて200名規模になります。 ゲーム事業自体は今年で10年目に突入して、開発プロセスは落ち着いています。DevOpsは世の中の流れに合わせて社内に定着してきたイメージがありますね。ただ、気を付けないと昔の名残で少しでも早く開発を行うために目の前のことしかやらない、といったことにもなりかねないので、そのあたりを見直すためにDevOpsへの意識は改めて強くなっています。今は、どうしたらもっと時間をうまく生み出せるのか、という部分の統一化を図っています。
梶原：エブリーの組織規模は、エンジニアが30名前後。チームはDELISH KITCHENの料理動画アプリ製作と、ライブコマースアプリ製作の２チームで構成されています。組織がそこまで重くないので、みんなでDevOpsをやっているエンジニアリングチーム、という感じです。特にバックエンドの人材については開発やオペレーション、分析基盤までさまざまこなしていますね。エンジニアにシニアレベルの人が多いので、DevOpsを強く意識せずとも、開発をしながらオペレーションの効率化もしなければならないという指向性が常に存在しているんです。
DevOpsの文化を浸透させるためにしていること
全社的にDevOpsの方針を打ち出すことが文化浸透の一番の近道
長沢：では次のテーマです。DevOpsは個々の取り組みを継続的に行うことが非常に大切だと思いますが、DevOpsの文化を浸透させるためにしていることをお伺いしていきたいと思います。白井さんはこのあたり、意識されていることはありますか？
白井：所属する子会社の中で、月に１回、仕事で効率化した内容を表彰する制度を作りました。すると、みんなどんどんツールをつくりはじめました。作業の無駄な要素を探して効率化するようになった。会社の方針として打ち出すのは、文化の浸透方法としては早いのかなと思います。これは一例ですが、事業部全体としても方針として打ち出すことは大切にしています。
長沢：機能やツールを作るとなると、DevOpsは自動化の仕組み構築のために余計に時間がかかってしまう部分もありますが、そのあたりについて経営層はどんな理解をしていたのでしょうか。
白井：どちらかというと、エンジニアが直接関わるところ以外からはじまりました。普通の社員がエクセルを作るのに１日かかるけれど、エンジニアがやったら30分でできるんじゃないか、と。そういった部分から、プロジェクト全体の無駄な部分は見直した方がいいよね、という全社的な動きになっていきました。
長沢：わかりやすいところから着手していき、効率化によるメリットへの理解を広げていった感じですね。梶原さんはいかがですか？DevOpsはメンバーが自然に実施しているとのお話でしたが。
梶原：社長も含めボードメンバーのうち３名がエンジニア出身ということもあって、非効率なことがあると「ツールを開発したらすぐにできるようになるんじゃないか」という意識があるんです。人事メンバーにも意外とエンジニアがいたりするので、さらっとスクリプトを書いて効率化することもあるほどです。会社としてエンジニアのマインドがすごく浸透している感じですね。
長沢：森山さんはいかがでしょうか？
森山：マイクロソフトは、実は５年以上前はオープンソースを排除していた会社なんです。そこからオープンソースをどんどん導入していく中で、言われたことしかやらない、自分で手を挙げない人たちがどんどん増えていきました。先程ご説明したGrowth mindsetの逆、Fixed mindsetを持った人たちです。そんな状況を改善するためにGrowth mindsetを掲げて、エンジニア側から「これは必要だ」もしくは「お客様がこれは必要としている」というものを、投票という形で募り、どんどん実装していこうという取り組みを開始しました。 人事的な観点から言えば、例えば私がマイクロソフトの本社でエンジニアをやりたいと思ったら、Web上にジョブサーチのページがあって、本社のエンジニアポジションを探して自ら手を挙げられるようになった。自分のやりたいことを自分のやりたいタイミングで積極的にやれる会社になっていったんです。上司はそれを邪魔せず、次の部署でもがんばってもらうための支援をします。そういった文化を醸造して根付かせることが、Growth mindsetをもってDevOpsに取り組む土壌に繋がったのかなと思いますね。
長沢：ありがとうございます。では、弓山さんいかがですか？
弓山：私たちの会社は数名規模で、コア開発者は私も含めてDevもOpsも経験があります。いまのプロダクトを将来に渡って機能追加を行い、活用し、ビジネスの中心に据えていくのであれば、目の前の機能実装だけではなく、先々に向けた投資を一定量しなければならない、ということを頻繁に話しています。文化の浸透には、それが一番いいんじゃないでしょうか。
長沢：それは、同じような経験や意識を持ったメンバーが集まっているということなのでしょうか？
弓山：いいえ、中にはインターンで入っている学生さんもいるので、必ずしもメンバー全員が同じ認識を持っているわけではありません。一方で、コア開発者の認識はかなり揃っているので、メンバーとの差異を埋めてすり合わせるための会話を定期的に持ちながら進めているという感じです。
過去の失敗事例とそこから学んだこと
自動化の仕組みを構築において、属人化を起こさない工夫が必須
長沢：今日会場にいらしている方も、実際にDevOpsに取り組んでもなかなかうまくいかなかったというケースもあるかと思います。そのあたりの失敗事例や、その失敗から学んだことについて、森山さんから伺っていきたいと思います。
森山：パートナー支援の分野からお話させていただきます。特に大企業で古くからWebサービスを提供している企業に多い失敗例は属人化ですね。例えばJenkinsというツールがあったら、Jenkinsを使える人が属人化されてしまって、「Jenkinsおじさん」ができあがる。その時点ではまだ失敗ではないのですが、将来的にその人がいなくなると失敗につながってしまいます。 それを回避するためには、例えばスクリプトをやめて、クラウドのSaaSを使ったりテストスイートを導入するなどの方法があります。これは実際に私がお勧めしたケースです。 オープンソースのフレームワークやテストスイートを活用すれば、凝縮された世の中のベストプラクティスをそのまま導入できます。古いものはきっぱり切り捨てて、そういったものを積極的に採用していくことが改善につながる、という部分が学びでしたね。
弓山：私の今の会社につながるプロジェクトは当初２人くらいの小さなチームでやっていたのですが、良さそうなプラクティスを見つけてきたら、まず手頃な実験場として自分たちのプロジェクトで試していました。それは本業だった会社ではうまくまわるような仕組みに育てていくことができたのですが、エンジニア２，３名のチームにはやや荷が重いツールやワークフローだったので、結局取り除くことにした事例があります。 世の中にはいろいろなベストプラクティスがありますが、やはりフェーズによって適切なものの見極めが必要ですね。見極めを誤ってしまったときにズレた状態をいつまで続けるのか、どこで引き返すのか、という意思決定は非常に大事だなと思いました。
長沢：規模感に合わせた取り組み方は重要ですね。白井さんはいかがですか？
白井：以前、開発中に負荷テスト環境をTerraformで作ったことがあるのですが、それはその１回きりということがありました。エンジニアにとってはスキルが１つ増えて後々に活きているのですが、負荷テスト環境自体は普通に作った方が圧倒的に早かったので、良かったのかどうか、なんとも言えない事例ですね。
長沢：１時間の作業のために３時間で自動化の仕組みを作って、１回しか活用しない…ということもあるので、そのバランス感は難しいですね。梶原さんは何か自動化に関する失敗事例はありますか？
梶原：あまり深い話ではありませんが、自動化は最新技術の取り入れでもあるので、スキルの高いエンジニアが構築してしまうと自動化に対して手を入れることにもスキルが必要になり、失敗事例になることがありますね。
長沢：さきほど森山さんが話された「ジェンキンスおじさん」のような属人化とも似ていますが、自動化のシステム構築において属人化が発生してしまったときは、どのように解消していくんでしょうか？
梶原：違う人にオペレーションをローテーションしてもらうしかないですね。
森山：なるべく属人化を防ぐために、ツール選定はどのように行っていますか？
梶原：ニッチすぎず、枯れなさそうなところを狙っていきます。コミュニティや会社が終わったらサービスも終了してしまいそうなところは選びません。そういった部分はトレンドを見ながら選定していくことにはなりますが、メンバーが選定したものなら確かだという考えを持ってメンバーに任せていますね。
DevOpsを支えるツール
ツール選定に加え、ツールを使いこなすノウハウの蓄積も重要
長沢：会場のみなさんからの事前質問も数多くいただいていたテーマですが、DevOpsを進めていく上でどのようなツールを選んでいるのか、また、その良かった点などを教えていただければと思います。梶原さんからお願いします。
梶原：CI/CDでいうと、CircleCIを使用しています。アプリはfastlaneに流して、そこからCircleCI上でテストをして、ワークフローを組み、その後、Terraformを使用しています。 あとは最近だとsparkで機械学習のクラスタを組んだりしていますが、クラウドのSaaSがあるので、それを使うことによって便利にクラスタを作れて、データを流し込めば計算もできる環境も作っています。
白井：全く違うレイヤーの話ですが、開発ツールとしてはスプレッドシートをよく使っています。プランナーからプログラムでつかうマスタデータの受け渡しをするときは大体スプレッドシートで入稿をしてもらい、Google App Scriptで作業することが多いですね。きれいなワークフローの話は重要ですが、みんなどこに一番時間を取られるかというと、やはり人間が関わる部分の話になります。ツールという意味ではGoogle App Scriptは役に立っている、というのが所感ですね。
弓山：私たちのサービスでは、Google App Engine、すなわちPaaSを選んだというのは、大きな選択だったと思っています。新しい機能を作ろうとしたときにPaaSを選ぶかどうかというのは重要な部分で、岐路に立ったときのために、PaaSを使いこなすノウハウやエコシステムをチーム内にどう貯めておけるのかも大事ですね。
森山：オープンソースであることとオンプレで運用できることから、パートナー様の中ではGitLabがよく使われていますね。経営層が未だにクラウドの使用を躊躇している、というケースがあるからです。今後もまだまだGitLabを使用する方は増えていくのではないでしょうか。古くからDevOpsに取り組んでいるお客様の中にはJenkinsを選んでいる方もまだまだいらっしゃいますね。
長沢：セキュリティを担保しながら、ソースコードをいかに管理していくのかというのもDevOpsの課題でもあるので、そのためにGitLabを使用しているという視点はあるかもしれませんね。
以上でパネルディスカッションは終了します。みなさんありがとうございました！
