【DevOps後編】CTOが考えるDevOpsの本質とは?

2021年5月12日に開催されたCTO meetup「本当に心地良いOps(Dev)とは?」のイベントレポート後編です。

モデレータにアジャイルコーチの藤原さんを、パネラーにChatwork株式会社のCTO春日さんと株式会社エンペイのCTO田野さんをお迎えした本イベント、後半はさらに深くDevOpsの本質についても語りました。


【パネラー】
■Chatwork株式会社/執行役員CTO兼プロダクト本部長 春日 重俊 氏
■株式会社エンペイ/取締役CTO 田野 晴彦 氏

【モデレータ】
アジャイルコーチ/テスト自動化コンサルティング 藤原 大 氏

まだ読んでいない方は、ご登壇者の自己紹介や会社紹介から始まるイベントレポート前編中編もぜひご覧ください。

エンペイが考えるDevOpsの本質とは?

事業の変化に対して弾力性を持って対応できることが最重要

アジャイルコーチ/テスト自動化コンサルティング 藤原 大 氏(以下、藤原):ここからは少し本質的なお話をできればと思います。テーマは広くなってくると思いますが、まずエンペイが考えるDevOpsの本質についてお伺いできますでしょうか。

アジャイルコーチ/テスト自動化コンサルティング 藤原 大 氏
アジャイルコーチ/テスト自動化コンサルティング 藤原 大 氏

楽天株式会社、株式会社メルカリを経て現在はフリーランスのアジャイルコーチ、エンジニアリングマネージャとして活動。 「リーン開発の現場」の翻訳者でもありアジャイルな創造的、継続的、持続的なソフトウェア開発の実現に向けて奮闘中。 週末に娘と息子とお昼寝しながら世界のビーチや離島を旅する夢を見るのが安らぎ。


株式会社エンペイ/取締役CTO 田野 晴彦 氏(以下、田野):一つ考えたい視点としてあるのが、会社にはシステムというものがありつつも、外部環境がすごい勢いで変わっていくということです。特にスタートアップにおいて事業の方向性が変わったときのために、システムに弾力性を持たせておくというか、外部環境に適用できるようにしておくのが非常に重要だと思います。

そして変化に適用し、事業の向きたい方向に同じスピードで成長していくという動きを支えてくれるのが、DevOpsだという捉え方をしています。

株式会社エンペイ/取締役CTO 田野 晴彦 氏
株式会社エンペイ/取締役CTO 田野 晴彦 氏

ワークスアプリケーションズにて、会計システムのエンジニアを担当。その後、リクルートに入社し、キッズリー、スタディサプリ、その他新規事業にてエンジニア、プロダクトマネージャーとして従事。株式会社エンペイをCEOと共に共同創業し、会社創業時から現在までCTOとしてプロダクト開発、開発組織作りを行う。


藤原:事業としシステムのバランスが変わった、あるいは変えざるを得ないときに柔軟的に対応するのがDevOpsだと感じますね。これらを実現するために田野さんご自身がCTOとして気を付けていることはありますか?

田野:自分が多くの失敗をしてきているので、同じ状況になりそうかどうかはしっかり見ています。積み木を組み立てているような感じですね。何か歪みが生まれていないか、きちんと真っ直ぐ積めているかを意識しています。

また、CTOというものは経営レイヤーの中では一番技術に詳しくなければいけないという側面があります。経営にせよ事業にせよ、自分で状況を咀嚼して判断につなげなければいけないので、「自分は技術者だからここまで」というラインは持たず、全体的に情報を仕入れて適切に反応するようにもしています。

藤原:田野さんのお話を伺っているとあまりテクノロジー一辺倒ではないんですよね。プロダクトやビジネスという言葉を織り交ぜながら開発をされている点が興味深いと思いました。

エンジニアにとって心地よい開発環境の構築を目指して

藤原:少し大きな話になりますが、田野さんが今後実現していきたいDevOpsは一言で言うとどのようなものなのでしょうか。

田野:一言より長くなってしまいますが(笑)、僕はチームメンバーにとって心地よい開発をしたいんです。もちろん綺麗なコードがありドキュメントがそろっているという状態も心地よいのですが、どちらかというと、コードを書いてユーザーにプロダクトを届け、フィードバックが返ってくるというところまでを心地よくできるようにしていきたいと思っています。

実現のためにはもちろんリリースサイクルを小さくしなければいけませんし、いきなり全ユーザーに届いて大きな障害が出ても怖いので、フィーチャーフラグなどを使って限定的にリリースする必要があると考えています。フィードバックは定性的なものでもいいのですが、すぐに数値で見られるような基盤も必要です。

こういったところを高速で回して、コードを書いている開発者自身が「自分たちがこのユーザーに価値を届けているんだ」という感覚を持って開発できるようにしたいです。

藤原:エンペイさんのような会社規模・ステージだと、1サイクルはどれくらいですか?

田野:リリースからフィードバックをもらうまでの期間は以外と長くて、2週間~1ヶ月ほどです。

藤原:スプリントは2週間ですか?

田野:そうです。より細かな変化が必要とされるときは1週間に縮めていますね。ちょうど4月頃はお客様が増えてバタバタしていたので、1週間で回していました。

藤原:1日最大何回ほどリリースするものですか?

田野:基本的に1スプリントに1回で、何か理由があれば分割します。

Chatworkが考えるDevOpsの本質とは?

プロダクトに誇りを持ち、エンジニアが主体的に意思決定する

藤原:では再び春日さんにお伺いします。Chatworkが考えるDevOpsの本質とは何でしょうか?

Chatwork株式会社/執行役員CTO兼プロダクト本部長 春日 重俊 氏(以下、春日):僕たちのようなサービス維持運営者から見ると、エンジニアはサービスをデリバリーする立場の職種だと思うんですよね。そのときに重要なのは、やはり自分のプロダクトに誇りを持つという観点だと思います。

ただ言われたから作るのではなく、きちんと自分が主体となって考えて意思決定すると納得感も生まれます。ボトムアップとトップダウンを上手くブレンドしながら組織として心地よい関係を作るというのが大切なのではないでしょうか。

Chatwork株式会社/執行役員CTO兼開発本部長 春日 重俊 氏
Chatwork株式会社/執行役員CTO兼開発本部長 春日 重俊 氏

明治大学経営学部を卒業後、電通国際情報サービスに入社、大手企業の基幹会計システム導入の経験を積む。その後リクルートに入社、新規事業の業務に従事し、組織マネジメント・サービス企画・BPRなどに携わり、2016年1月にChatworkに開発本部長として入社。2020年7月に執行役員CTO兼開発本部長に就任。


藤原:ありがとうございます。現在は開発だけではなく組織づくりそのものにも力を入れ、組織を小さく分けていくという取り組みをされているそうですが、実際に上手くいっている部分、あるいは上手くいっていない部分があれば教えていただけますでしょうか。

春日:自分たちが成功事例になっているかどうかは、もう少し時間をかけてから結果が出るのではないかと思います。少なくとも良かったのは、責務を分けることで責任範囲が明確になったことですね。何か開発でトラブルになったときに、お見合いになってしまうことは少ないです。

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に取り組んでいただきたいなと思います。

藤原:本日は以上になります。ありがとうございました。

   
3/3 ページ

この記事を書いた人
FLEXY編集部
FLEXY編集部
ハイスキルIT人材への案件紹介サービス
FLEXYメディアは、テックメディアとしてテクノロジーの推進に役立つコンテンツを提供しています。FLEXYメディアを運営するのは、ITに関連するプロシェアリングサービスを提供するFLEXY。経営課題をITで解決するためのCTOや技術顧問、エンジニアやデザイナーと企業を繋いでいます。

週1日~/リモートの案件に興味はありませんか?

週1日~/リモートの関わり方で、「開発案件」や「企業のIT化や設計のアドバザリーなどの技術顧問案件」を受けてみませんか?副業をしたい、独立して個人で仕事を受けたエンジニア・デザイナー・PM・技術顧問の皆様のお仕事探し支援サービスがあります。

FLEXYでご案内できる業務委託案件

業務委託契約・開発案件

テーマ 案件はFLEXYに登録後、コンサルタントからご紹介します
勤務日数 2〜3日/週
報酬 4万円/日
必要スキル JavaScript・React
勤務地 東京都内 / フルリモート
リモート 週1日のオンラインMTG・リモート

外部CTO、技術顧問案件

テーマ 技術アドバイザリーとして知見と経験を生かす(FLEXY登録後に詳細のご紹介)
勤務日数 1日/週
報酬 5〜10万円/日
必要スキル エンジニア組織立ち上げや統括のご経験、コードレビュー経験、技術的なアドバイスが出来る方
勤務地 東京都内 / フルリモート
リモート フルリモート

インフラエンジニア(業務委託契約)

テーマ 案件はFLEXYに登録後、コンサルタントからご紹介します
勤務日数 2〜3日/週
報酬 5万円/日
必要スキル それぞれの案件により異なります
勤務地 東京
リモート 相談可

業務委託・フロントエンドエンジニア

テーマ 案件はFLEXYに登録後、コンサルタントからご紹介します
勤務日数 週2日〜
報酬 5万/日
必要スキル それぞれの案件により異なります
勤務地 東京
リモート リモートと常駐のMIXなど

技術アドバイザリー案件

テーマ CTO、技術顧問案件はFLEXYに登録後、案件をコンサルタントからご紹介します
勤務日数 週1日
報酬 5万以上/日
必要スキル CTOとして活躍可能な方、エンジニア組織のマネージメント経験
勤務地 東京
リモート 最初は業務委託契約で週3日などご要望に合わせます

業務委託契約・サーバサイドエンジニア

テーマ CTO、技術顧問案件はFLEXYに登録後、案件をコンサルタントからご紹介します
勤務日数 週2〜3日
報酬 案件により異なります
必要スキル 案件により異なります
勤務地 東京都内
リモート 相談可能
個人登録

お仕事をお探しの方(無料登録)
法人の方(IT課題の相談)