【DevOpsとは】今、原点に立ち返る。CTOが考えるDevOpsの本質とは？
※本記事は、2021年6月に公開された内容です。
2021年5月12日に開催されたCTO meetup。今回はアジャイルコーチの藤原さんをファシリテーターに迎え、Chatworkの春日さん、エンペイの田野さんに「本当に心地良いOps（Dev）とは？」というテーマについてディスカッションしていただきました。
それぞれ企業フェーズが異なる2社のDevOpsには、どのような違いがあるのか。そして、二人のCTOはDevOpsの本質をどのように捉えているのか？具体的事例とともに、ユーザーに迅速かつ柔軟な価値提供をしていくためのヒントをお伝えします。
目次
登壇者のご紹介
シリーズAのエンペイと、ミドルからメガベンチャーを目指すChatwork
アジャイルコーチ／テスト自動化コンサルティング 藤原 大 氏（以下、藤原）：本日はよろしくお願いします。早速ですがエンペイの田野さんから自己紹介していただけますでしょうか。
楽天株式会社、株式会社メルカリを経て現在はフリーランスのアジャイルコーチ、エンジニアリングマネージャとして活動。 「リーン開発の現場」の翻訳者でもありアジャイルな創造的、継続的、持続的なソフトウェア開発の実現に向けて奮闘中。 週末に娘と息子とお昼寝しながら世界のビーチや離島を旅する夢を見るのが安らぎ。
株式会社エンペイ／取締役CTO 田野 晴彦 氏（以下、田野）：株式会社エンペイの取締役CTO田野と申します。エンペイは創業から2年半ほどのスタートアップ企業で、僕とCEOが創業しました。2021年4月に資金調達を完了し、現在シリーズAラウンドのフェーズになっています。
ワークスアプリケーションズにて、会計システムのエンジニアを担当。その後、リクルートに入社し、キッズリー、スタディサプリ、その他新規事業にてエンジニア、プロダクトマネージャーとして従事。株式会社エンペイをCEOと共に共同創業し、会社創業時から現在までCTOとしてプロダクト開発、開発組織作りを行う。
田野：事業内容としては集金の業務をSaaS化した「enpay」を運営しています。保育園に利用いただくことが多く、従来であれば現金や口座振替で保護者の方から支払っていただいていた月謝を、LINEで通知、そのまま支払える仕組みになっています。ビジョンは社会の「お金の流れを円滑にし、幸せな社会を創造する」ことで、お金の流れがスムーズになった結果、空いた時間に生産的なことができるようになればいいなと考えています。また、お金の流れに関するインフラとなる責任も感じており、決済流通額の一定割合を子供の宅食や養子縁組事業に寄付するなど、助けが必要ところにお金が届く仕組みを広げていきたいと思っています。
藤原：ありがとうございます。続きましてChatworkの春日さんお願いします。
Chatwork株式会社／執行役員CTO兼プロダクト本部長 春日 重俊 氏（以下、春日）：Chatwork株式会社のCTOを務めている春日と申します。Chatworkは東京と大阪、ベトナム、台湾に拠点を持っており、2000年に創業したChatworkの前身であるEC studio時代を含めると、そこそこの老舗企業となっています。
明治大学経営学部を卒業後、電通国際情報サービスに入社、大手企業の基幹会計システム導入の経験を積む。その後リクルートに入社、新規事業の業務に従事し、組織マネジメント・サービス企画・BPRなどに携わり、2016年1月にChatworkに開発本部長として入社。2020年7月に執行役員CTO兼開発本部長に就任。
春日：従業員数は3月末時点で176名でしたが、4～5月にかけて人が増え、もうすぐ200名規模の組織になります。2019年9月に上場した当時は100名ほどだったので、コロナ禍という状況にありながらも成長を続けており、ミドルベンチャーからメガベンチャーを目指していくようなフェーズです。
僕が統括しているのはプロダクト本部という組織で、プロダクトマネージャーやエンジニア、デザイナーなど、プロダクトを開発する全ての職種を集約させています。現在は組織の変換期と考えており、組織をスケールさせるためにフロントエンドやSRE、サーバーサイドなどいわゆるエンジニアのスキル別で編成しているチームもあれば、GE（グロースエンジニアリング）や料金プランなど、ファンクション別のチームも作っています。
藤原：ありがとうございます。最後に僕の自己紹介も簡単にさせていただきます。僕はもともとJavaエンジニアで、楽天時代にアジャイルコーチやフロントエンドのエンジニアリングマネージャーを務めていました。その後メルカリでテスト自動化や次世代QAの立ち上げなどを経験し、現在は独立。スタートアップ企業の技術顧問やアジャイルコーチ、テスト自動化のお手伝いなどをさせていただいています。
サービスや開発をゼロから創るステージにおけるDevOps
非同期的開発から同期的開発にチェンジし開発スピードを速めたい
藤原：まず、「サービスや開発をゼロから作るステージにおけるDevOps」については田野さんに、「苦難を乗り越え上場し、組織規模も倍増したステージにおけるDevOps」については春日さんにお伺いしていこうと思います。
では田野さんからよろしくお願いします。エンペイはまさに０が1になるシリーズAラウンドというフェーズだということですが、改めて会社のステージについて詳しく教えていただけますか？
田野：当社は創業から2年半経ち、正社員数がようやく最近2桁になりました。エンジニアも最近までは僕1人で、副業や業務委託の方に手伝っていただいていました。先日資金調達を迎えて3名ほどのチームになったので、まさにここから密度の高いチームを作って加速させていこうとしています。
藤原：開発はどんな役割、流れで行っているのでしょうか？
田野：エンペイの開発は2年半から今までで3段階ほどに分かれています。最初は僕1人と開発会社がいて、プロトタイピングしたものを実際のお客様に使ってもらい、ひたすらMVPの検証を行うフェーズ。次に一定数顧客を獲得しPMFを目指していくフェーズに差し掛かり、僕を中心とした副業・業務委託のメンバー10名ほどが非同期に開発を進めました。そこからある程度のスピードで開発が可能になり、PMFも達したという壁を超えたのが、今の段階です。今後は本格的にスケールしていくタイミングなので、正社員採用のアクセルを踏み、開発スピードもさらに速めていこうとしています。
藤原：副業や業務委託の方を交えながら開発を進めていく上での注意点はありますか？
田野：普通の開発は大体10時～18時までの間に同期的コミュニケーションを取り、何かあればすぐに相談してプルリクレビューをするのが当たり前ですが、副業や業務委託の場合はそうではありません。うちに入っていただいている方は平均すると月40～50時間稼働されている方が多く、活動時間はバラバラです。副業の方であれば深夜や土日の空いた時間を使うケースもあるので、同期的な進め方は不可能です。そうなると最初から非同期での開発を念頭に置いたフローを設定する必要がありますね。
藤原：今は非同期から同期的開発手法に移行するタイミングなんですね。開発自体はスクラムですか？
田野：非同期でも同期でも、一貫してスクラムです。ただ、非同期でスクラムをやろうとするといろいろと難しい部分があったので、そこは最適化できるようにカスタマイズを加えていました。
Biz,Devともに成功も失敗も経験した「２周目」のメンバーが多く、新技術導入の障壁は低い
藤原：DevOpsにおいてはフローだけではなく技術面も大切だと思うのですが、現段階までどんなツールを使ってきたのでしょうか？
田野：創業からずっとサーバーサイドはRails、フロントエンドはVueです。全体的にRailsに寄せた構成になっていて、サーバーサイドエンジニアが開発しやすい環境になっています。インフラはAWS、監視系はNew Relicです。
環境についてはもともとプロダクションとステージングしかなかったのですが、プルリクのレビューごとに確認できるHerokuの環境を構築したほか、最近はBig Queryも導入しようとしています。
藤原：開発者がプルリクを作るたびに自動でHerokuでレビュー用の環境が立ち上がるということまでされているんですか？
田野：そうですね。
藤原：すごいですね。それなら開発が増えてもスケールしそうな印象があります。そこまでやろうと思ったきっかけはあるんですか？
田野：我々はスタートアップではありますが、事業においても開発においても、成功も失敗も一通りを経験している「２周目」という感じのメンバーが多いんです。
藤原：大人ですね（笑）。
田野：メンバーはみんな、開発で辛くなってしまった経験を踏んできているんですよね。「今回は備えておこう」というマインドがあるので、新しい技術を導入する障壁が低いですし、コミュニケーションも非常にスムーズです。ここは会社として大きなアドバンテージだと感じています。
急加速する事業の成長スピードに開発も併走するのが一番のチャレンジ
藤原：DevOpsという観点で、現在課題に感じていることは何かありますか？
田野：やはり副業、業務委託中心から同期的な正社員中心の開発スタイルに変える部分ですね。なかなか苦戦しています。
藤原：それは技術的にという意味ですか？
田野：チームフローの部分が大きいです。もともと非同期で開発しているときは上手くいっていたことが、同期的にフルで働くメンバーが入ったとたん、難しくなってきました。
藤原：エンペイさんはこれまで中長期的視点でプロダクトテクノロジーのロードマップをご用意されているそうですが、実際のフェーズとしてもそういったものがより必要になってきましたか？
田野：そうですね。ロードマップに関してはDevOpsに加えてプロダクトマネジメントの要素も絡みます。事業とプロダクトが同じ角度で成長をしていく分には問題ないのですが、多くの場合は乖離が起きます。すると、「事業的にこれがやりたい」と思っても、システム的に実現できないという事態が起きる。できない前提で事業計画を練り直すと、今度は事業的に上手くいかない。
我々はまだ規模が小さくメンバーも少ないため、事業の成長速度は抑えられており乖離の問題は起きていないのですが、ここからシリーズAを迎えて事業が急加速していきます。そのときプロダクトも同じ勢いでクイックに対応し続けるようにするのが、一番のチャレンジかもしれません。
藤原：では、現在DevOpsの観点から、意識して取り入れているプラクティスやツールはありますか？
田野：ペアプロやモブプロを取り入れ始めました。実はこれまで副業などの採用はリファラル100％だったので、スキルセットが合うことはもちろん、一緒に働いていて居心地が良いメンバーばかりだったんです。タスクを渡したら、それだけで完成度の高いアウトプットが出てくるような状態でした。
しかし今後はそれだけではなかなかスケールできません。チームとしてナレッジを共有し学んでいくためにも、ペアプロ・モブプロの工程は積極的に実施したいです。
藤原：スタートアップで加速が求められる中でも、そういった時間的な投資をしていく判断をされたわけですね。非常に大人なスタートアップで面白いと思いました。
Chatwork
100人の壁を前に、「2枚のピザルール」で組織を分割
藤原：ではここからは春日さんにお話しいただきます。改めまして、Chatworkの会社としてのステージや開発組織について教えていただけますでしょうか。
春日：Chatworkは2019年に東証マザーズに上場させていただいており、社員数は189名（2021年4月末日時点）のミドルベンチャーです。プロダクトメンバーは80名以上で、いわゆる100人の壁が見え始めている段階です。
春日：年始の中計では「中小企業のナンバーワンビジネスチャットプラットフォームになる」と発表しており、成長戦略的にはメガベンチャーへの挑戦中でもあります。IRではChatworkのスーパーアプリ化を目指すとしており、Chatworkを軸にしながらも中小企業のDXを加速させるためのさまざまなアプリを立ち上げていかなければいけないと考えています。
組織のケーパビリティが全く足りていない状況なので、今回話を聞いてちょっとでも興味を持ってくださった方がいれば、ぜひ一度カジュアルにお話しできればと思います。
藤原：ありがとうございます。開発組織の人数についても詳しく教えていただけますか？
春日：僕が各部署をマネジメントする上でポリシーにしているのが、「2枚のピザルール」です。1つのチームが数十人規模にならないような形で組織を分割しているということですね。ですから各部署は8名くらいで、10個に分かれているというような状況です。
モノリスなシステムを残しながらも最新技術を導入して改善を継続
藤原：現在実際に使われているツールや技術選定についても教えていただけますでしょうか？
春日：採用候補者さん向けにまとめたスライドを見ていただければなと思います。
春日：これでも全部載せきれていないほどで、構成図は非常に複雑です。ざっくり言うとフロントエンドがReactとReduxですが、それだけでもコードが10万行を超えます。アプリはネイティブでないとユーザー体験を損ねてしまうので、KotlinやSwiftを使っているのが特徴かなと思います。
サーバーサイドは創業当初にPHPで作っていたモノリスな部分があったりするのですが、新しい部分はScalaやakkaを用いて、分散で速度を出すといった取り組みをしています。
あとは分散システムにkafkaやHBASE、kubernetesなど、いわゆる最新技術のトレンドを使っているのですが、当社の場合はどちらかというとスケールの課題を解決するために選択せざるを得なかった感じです。
それからチャットは低レイテンシーで運用しなければいけないサービスなので、監視部分にはNew RelicとDATADOGを両刀で使っています。pagerdutyを採用しているのは、365日24時間何かしら問題があれば対応できるように投資しているという部分です。
藤原：モノリスな10年もののシステムがありながら、どんどん組織も技術も改良されている印象ですね。歴史を感じます。
もう一度開発をやり直せるなら、人事・採用面を早いタイミングで強化したい
藤原：今はどういった形で意思決定をされているのでしょうか？
春日：まず、今は組織開発だけを行うDevHRという部署があります。そこのメンバーと組織的な課題を探りながら、効果が高い部分について議論し、意思決定を行っています。
藤原：専用チームがあるんですね！なるほど。春日さんは10年という歴史をたどってきた有識者ということでぜひ伺いたいのですが、もしもう一度開発をやり直せるのであれば、どういった活動やコード、プラクティス、プロセス、ツールなどを導入したいですか？
春日：今言ったDevHRが抱える課題は、ほとんどが人にまつわることです。実は当社に選任の人事ができたのは2019年からで、上場の前年度までは各本部長が片手間に採用しているような状況でした。そうなるとやはり本業が忙しいために、組織づくりが後回しになりがちだったんですよね。
今でこそDevHRと人事が両輪で活動するというところにたどり着けているので結果的には良かったのですが、人事の部分はまだ弱さを感じますし、もっと早く対策しておくべきだったと感じます。
藤原：組織周りもDevOpsのような形になっているんですね。興味深いです。
エンペイが考えるDevOpsの本質とは？
事業の変化に対して弾力性を持って対応できることが最重要
藤原：ここからは少し本質的なお話をできればと思います。テーマは広くなってくると思いますが、まずエンペイが考えるDevOpsの本質についてお伺いできますでしょうか。
田野：一つ考えたい視点としてあるのが、会社にはシステムというものがありつつも、外部環境がすごい勢いで変わっていくということです。特にスタートアップにおいて事業の方向性が変わったときのために、システムに弾力性を持たせておくというか、外部環境に適用できるようにしておくのが非常に重要だと思います。
そして変化に適用し、事業の向きたい方向に同じスピードで成長していくという動きを支えてくれるのが、DevOpsだという捉え方をしています。
藤原：事業としシステムのバランスが変わった、あるいは変えざるを得ないときに柔軟的に対応するのがDevOpsだと感じますね。これらを実現するために田野さんご自身がCTOとして気を付けていることはありますか？
田野：自分が多くの失敗をしてきているので、同じ状況になりそうかどうかはしっかり見ています。積み木を組み立てているような感じですね。何か歪みが生まれていないか、きちんと真っ直ぐ積めているかを意識しています。
また、CTOというものは経営レイヤーの中では一番技術に詳しくなければいけないという側面があります。経営にせよ事業にせよ、自分で状況を咀嚼して判断につなげなければいけないので、「自分は技術者だからここまで」というラインは持たず、全体的に情報を仕入れて適切に反応するようにもしています。
藤原：田野さんのお話を伺っているとあまりテクノロジー一辺倒ではないんですよね。プロダクトやビジネスという言葉を織り交ぜながら開発をされている点が興味深いと思いました。
エンジニアにとって心地よい開発環境の構築を目指して
藤原：少し大きな話になりますが、田野さんが今後実現していきたいDevOpsは一言で言うとどのようなものなのでしょうか。
田野：一言より長くなってしまいますが（笑）、僕はチームメンバーにとって心地よい開発をしたいんです。もちろん綺麗なコードがありドキュメントがそろっているという状態も心地よいのですが、どちらかというと、コードを書いてユーザーにプロダクトを届け、フィードバックが返ってくるというところまでを心地よくできるようにしていきたいと思っています。
実現のためにはもちろんリリースサイクルを小さくしなければいけませんし、いきなり全ユーザーに届いて大きな障害が出ても怖いので、フィーチャーフラグなどを使って限定的にリリースする必要があると考えています。フィードバックは定性的なものでもいいのですが、すぐに数値で見られるような基盤も必要です。
こういったところを高速で回して、コードを書いている開発者自身が「自分たちがこのユーザーに価値を届けているんだ」という感覚を持って開発できるようにしたいです。
藤原：エンペイさんのような会社規模・ステージだと、1サイクルはどれくらいですか？
田野：リリースからフィードバックをもらうまでの期間は以外と長くて、2週間～1ヶ月ほどです。
藤原：スプリントは2週間ですか？
田野：そうです。より細かな変化が必要とされるときは1週間に縮めていますね。ちょうど4月頃はお客様が増えてバタバタしていたので、1週間で回していました。
藤原：1日最大何回ほどリリースするものですか？
田野：基本的に1スプリントに1回で、何か理由があれば分割します。
Chatworkが考えるDevOpsの本質とは？
プロダクトに誇りを持ち、エンジニアが主体的に意思決定する
藤原：では再び春日さんにお伺いします。Chatworkが考えるDevOpsの本質とは何でしょうか？
春日：僕たちのようなサービス維持運営者から見ると、エンジニアはサービスをデリバリーする立場の職種だと思うんですよね。そのときに重要なのは、やはり自分のプロダクトに誇りを持つという観点だと思います。
ただ言われたから作るのではなく、きちんと自分が主体となって考えて意思決定すると納得感も生まれます。ボトムアップとトップダウンを上手くブレンドしながら組織として心地よい関係を作るというのが大切なのではないでしょうか。
藤原：ありがとうございます。現在は開発だけではなく組織づくりそのものにも力を入れ、組織を小さく分けていくという取り組みをされているそうですが、実際に上手くいっている部分、あるいは上手くいっていない部分があれば教えていただけますでしょうか。
春日：自分たちが成功事例になっているかどうかは、もう少し時間をかけてから結果が出るのではないかと思います。少なくとも良かったのは、責務を分けることで責任範囲が明確になったことですね。何か開発でトラブルになったときに、お見合いになってしまうことは少ないです。
Chatworkのソフトウェア規模がフロントエンドだけで10万行というお話をしましたが、そういうソフトウェアをメンテナンスし続けるというのは、六法全書を見ながら開発するようなものです。人が増えていく中でいきなり「六法全書を全て覚えろ」というのは厳しいですから、サービスが膨れ上がったときは、組織を適切に分割するという考え方が必要なのではと思います。
藤原：分割する中で、自律的に動ける組織構造を考えていくのが今のフェーズということですね。
一人ひとりが創造的に働ける、スポーツチームのようなチーム設計が理想
藤原：では、Chatworkが実現したいDevOpsとはどのようなものなのでしょうか。
春日：当社のミッションにも紐付くのですが、一人ひとりがもっと創造的に働けるチームであってほしいです。今後定年がどんどん引き上がり、長く働くことになるだろうと予測したときに、いかに心地よく、気持ちよく働けるかが永遠のテーマになると思うんですよ。仕事で「気持ち良く働ける」のは、自分で意思決定している瞬間です。そういうプロセスを上手く設計して成長していきたいと考えたときに、良いモデルの一つだと思うのがスポーツチームです。その中でもラグビー日本代表チームは本当に理想的だなと思います。
藤原：Netflixも確か同じようなことを言っていますね。
春日：今実際にチャレンジしているのは、『マネーボール』という映画に登場したセイバーメトリクスの考え方です。さまざまな視点の指標からチームを見るものなのですが、どうすれば正しいソフトウェアチームのセイバーメトリクスを作れるかなと考えています。
質疑応答
※Youtube Liveでリアルタイムに寄せられた質問に答えていただきました。
DevOpsを始める前にまず課題の解像度を高める必要がある
質問者：DevOpsをやる上で最低限必要な準備はありますか？
田野：始めようと思えばいつでも始められるのですが、いざやるとなると難しいですね。結構魔法の言葉感があるなと思っていて。
藤原：おっしゃる通りです。
田野：機械学習やAIがブームになって、上司から「機械学習を使って何かやるぞ」と言われるようなニュアンスと同じようなことが、DevOpsにも言える気がします。DevOpsを入れるなら、まずは課題を解像度高く捉えなければいけません。DevOps自体が非常に広い概念ですから、課題を掘り下げていってやることを決めて進むというのが、遠回りのようで一番のポイントかなと思います。
藤原：春日さんはどう思われますか？
春日：田野さんがおっしゃっているのは非常に重要な観点ですね。新しいことをやるとなると、経営視点では「貴重なリソースを使うのか」ということになります。ですからまずは小さくスタートすると決め、「なぜDevOpsを始めるのか」「自分たちがどんな課題をどう定義しているのか」についてディスカッションし、共感してもらうことが大切だと思います。
改善活動は一度流れが途切れるとリスタートにパワーがかかる
質問者：DevOps文化を根付かせ、改善を続けると息切れしてしまうと思います。ここを上手く続けていくためのポイントはありますか？
田野：確かに息切れはしがちですね。DevOpsをやらなくなってしまうケースの一つが、事業上の大きな機能を作るためにリソースを全振りし、その間は改善活動を止めるという状況です。これは実際何度も体験してきました。 スポーツ選手でも練習を1日休んだら取り戻すに3日かかると言われますが、改善活動系も同じで、一度流れが途切れると戻すのに時間がかかるんです。そのため我々の場合は、きちんとテクノロジーのためのリソースを確保して、ロードマップとして取り組むという形にしています。このように活動を継続するためには仕組みづくりや経営としての合意が必要ですし、とにかく常に取り組み続けるというところにピンを止めるのが大事なのかなと思います。
藤原：継続するという部分について、経営レベルできちんとディスカッションするということですね。
田野：経営レベルで認識がズレてしまうと、現場ではなかなか修正が難しい領域ですからね。
藤原：春日さんはいかがでしょうか？
春日：やめないことは重要です。一度停止してリスタートしようとすると、本当に大きなパワーがかかるんですよ。細々とでもいいからやり続けるには、やはりトップの意思決定が必要ですね。
とはいえ、事業を進める上で、どうしても踏ん張って開発を詰め込まなければいけないことはあります。僕の場合はそれが終わったら、「今はメンバーに無理をさせているから、クールダウンしよう」と意識して話すようにしています。
最後にひとこと
先人たちの知見を活かしながら、とにかく継続することが大切
藤原：では最後に、お二人から一言ずついただきたいと思います。お二人はCTOとして全く違うステージに立っていると思いますので、田野さんから見て春日さんのお話に何か感じることがあったか、春日さんが将来の自分かもしれないという点も含めて、感想をお聞かせください。
田野：このイベントはGW前からミーティングをして話すテーマなどを決めていたのですが、僕にとってはその時間が非常に価値あるものでした。まさにChatworkは僕たちの7、8年後の姿だと思っていますし、一貫してCTOを務めている春日さんがどんなところに何を思ったのか、何ならこの後お話したいくらいです（笑）。とても勉強になりました。
藤原：ありがとうございます。逆に未来を生きている春日さんから、田野さんを見て一言あればお願いします。
春日：個人的には自分がたくさん沼にハマってしまったので、田野さんはそうならないようアシストしてあげたいですね。業界の文化的にも、ソフトウェア業界の先人たちが自分たちの知見をオープンにして、助け合いながら業界そのものの発展に寄与してきたのだと思います。
特にCTOをはじめとした技術責任者は孤独なんですよね。責任者になればなるほど叱ってくれる人もいなくなりますから、壮絶に滑ってしまったときに自分ごととして反省するのが重要な観点です。そういう意味では、今日1日をしっかり振り返る癖を身に付けていくのがいいのではないかなと感じました。
藤原：では視聴者のみなさんにも一言ずつお願いします。
田野：本日はありがとうございました。エンペイは全職種を絶賛採用中ですので、エンジニアに限らず営業や企画、開発、プロダクトマネージャー、デザイナーまで、ご興味がある方がいればお気軽にお声掛けください。リモートでカジュアル面談をいたします。
春日：今日は短い時間でしたが、参加させていただきありがとうございました。新しいことをカルチャーとして根付かせるときは心が折れそうな瞬間がたくさんあると思うのですが、そのなか中でもやめない、続けることが重要です。失敗は継続していけばいつか成功につながるので、ぜひそういうマインドを持ってDevOpsに取り組んでいただきたいなと思います。
藤原：本日は以上になります。ありがとうございました。
