AWS re:Invent 2022 に参加してきました

AWS イベント

SRE の @s4ichi です。年が明けてしまいましたが、昨年 11 月の終わりから 12 月の始めに開催された re:Invent 2022 へ現地参加してきたため、足を運んで得てきた体験をレポートとしてお届けします。今年もクックパッドから総勢5名の社員が参加してきました。

クックパッドと AWS re:Invent

クックパッドでは 2011 年ごろから AWS の各種サービスを利用しています。当時のサービスを AWS に移行するところから始め、かれこれ 10 年以上 AWS をコアに利用してきました。 re:Invent へは 2012 年から社員が参加しています。コアに利用するサービスのアップデートをキャッチアップするのはもちろんのこと、普段利用しないサービスの Workshop へ参加して知見を更新したり、AWS の開発者と直接議論やフィードバックをすることで、普段利用するだけでは見えてこない視点を養う機会になっています。

参加レポート

さて本題です。 re:Invent への参加は、参加した社員の知見更新だけでなく、帰国後に社内で実施する報告会や個々人の社内ブログ投稿を通して社内のエンジニアへ広められます。今回はそんな社内ブログに投稿されたレポートから取り上げた内容をいくつかピックアップして紹介します。

参加者それぞれ毛色の異なるセッションを聞いてきたので、それぞれの視点から書いたレポートをお届けします。今回レポートを書いたのは @s4ichi, id:sora_h, @hilinker, そして @naoki_shigehisa の4名です。

EBC (Enterprise Business Conference)

id:sora_h です。クックパッドは例年、AWS の担当アカウントチームに re:Invent を含めいろいろな機会で AWS のサービスチームとミーティング (EBC や Customer Meeting と呼ばれるもの) を組んでもらっています。re:Invent 2022 でも、複数のチームとディスカッションをすることができました。

詳細はここには書けませんが、基本的にやることは自分たちがどうサービスを使っていて、何に困っているかを持っていきます。現地ではそれに対して自分たちで workaround できる方法はあるか、サービスに機能を入れるとしたらどういう方向がいいのか、といった内容を議論することが多いです。内容は当然英語なので、基本的には事前にざっくりとした資料を作ったりして楽になるように、また限られた時間を有意義に活用できるようにしています。

担当者個人としては、re:Invent のような巨大カンファレンスはアーカイブに残らないコンテンツや機会を中心に時間を使うべきと考えていて、EBC は AWS との渉外を担当する自分にとっても、またマネージドサービスをしっかり利用している会社としても、重要なミッションです。今回も楽しく有意義な議論ができて満足しています (内容は書けないのですが)。

[NEW LAUNCH!] Using policies to manage permissions with Amazon Verified Permissions [Breakout Session]

@s4ichi です。このセッションは Amazon Verified Permissions という新機能に関するもので、その機能の説明からの技術の概要までを深堀りするセッションでした。Amazon Verified Permissions 自体も機能がかなり面白くて、簡単に言えば IAM Policy に似た記述を用いて任意のドメインに関する認証・認可を代替してくれるマネージドサービスになっています。 つまり、「ユーザーがレシピAを見るのに必要な権限があるか -> YES or NO」みたいなのを検証してくれる機能がサービスとして提供され、API を経由して利用できます。

そんな機能紹介はさておき、記述言語が独自言語であるため、その言語についての紹介が半分の時間を占めていました。プログラム言語に詳しい開発者の方が出てきて、作った言語の思想を紹介していく姿は、学会にでも来たのか？という状況が味わえる良いセッションでした。あとで調べたんですが、発表者の方はプログラム言語に関するエキスパートで、POPL や PLDI などでソフトウェアの Synthesis や Verification を専門とするアカデミアの方だそうです。そんな方が AWS の Scientist として登壇されていたので幅広い分野の方々が AWS を支えているのを実感しました。

記述言語は Cedar という名前です。Rust で実装されていて、公式サイトに Playground があります。

www.cedarpolicy.com

詳細には解説されていませんでしたが、この言語自体に対する仕様の検証や Policy の同値性証明などの話もありました。世紀の発明、というほどではないんですが、ニーズや要件を満たす最小限の言語がドンと出て機能の中核を担っているの、アツいものがありますよね。

セッションは動画も公開されています。

www.youtube.com

The evolution of chaos engineering at Netflix

@s4ichi です。Netflix はセッションの種別に NFX という Prefix があるくらい特別視されているらしく、このセッションはそんな NFX 系の Chaos Engineering についての発表です。

Chaos Monkey で一部のリソースを勝手に停止するような文字通り "Chaos" な取り組みから、今は FIT（Failure injection Technology）を構築している様子についての発表でした。 microservices 上の様々な要素を観測するための分散トレーシング基盤やサービスメッシュが Netflix のインフラに構築されており、その上で Failure injection を柔軟に扱う仕組みがあるそうです。Chaos Monkey のようなランダム性のある取り組みは方向性は良かったのですが、計算資源単位ではなくドメインやアーキテクチャを考慮した失敗、というのをシミュレートしたいというモチベーション。特定のサービス間で耐障害性が低くなる部分があったことが原因の障害があり、シナリオベースで障害を注入できる必要があると学んだ、とのことでした。

Netflix のサービスはソフトウェアエンジニアなら誰でも FIT を使った障害の注入が可能になっています（専用コンソールがありそうな雰囲気でした）。Injection Point や Scope、Treatment（回復手段）にその Scenario を定義することができて、それをリアルタイムに実行できます。

具体的には、リクエストヘッダに対して（例では x-ntfx-fit-fail でした）コンテキストを付与することができます。その内容は、各サービスやその横にある Envoy が解釈して Failure injection をシミュレートするためのコンテキストになるそうです。 例えば、「サービスAからBに通信するクライアント側で Failure する。Canary リリースされたユーザーのグループCのみに適用。障害時はリクエストを Delay して失敗させる」ぐらいの粒度で指定が可能です。シナリオを用意しつつ、それを Canary や Production 環境と組み合わせてシミュレートできるため、非常に機能的でした。

「Chaos is dead, Long live...」言っていたのが印象的です。可観測性を上げ、FIT によって特定の箇所を狙って障害をエミュレートできるようにし、リリースの戦略と合わせてテストをできるようにすることで、カオスはたった一つの道具にすぎないと話していました。例えば当時からある Chaos Monkey はそれ自体は良いけど、今は殆ど使われていないそうです。

セッションの動画も公開されています。

www.youtube.com

Deep dive into Amazon Aurora and its innovations [Breakout Session]

@hilinker です。このセッションは、前半で Amazon Aurora の仕組みを解説しつつ、後半では直近リリースされた機能の紹介をするものでした。クックパッドでは Amazon Aurora を非常に多くのアプリケーションで採用しています。Aurora の細かい利点については AWS の公式ドキュメントに譲りますが、かなり様々な恩恵を受けています。

さて、特にここでは直近で発表された Aurora の新規機能のうち、特に以下２つについて触れておきたいと思います。

１つ目は、Amazon Aurora zero-ETL integration with Amazon Redshift です。

aws.amazon.com

これは Aurora のデータをほとんどリアルタイムに Amazon Redshift 上に同期することができるというものです。 クックパッドではアプリケーションのデータベースとしては Aurora を利用し、分析などに用いる DWH として Amazon Redshift を採用しています。分析などの際には Aurora にあるアプリケーションのデータを Redshift 側にコピーして用いるのですが、このコピーは日次バッチなどを実行することで行っているケースがほとんどで、どうしてもデータの同期に時差が生じてしまいます。特に、最近は Redshift 上のデータを利用して組み上げたデータを元にして、リアルタイムにユーザーへコンテンツを表示したいという要求が社内で高まっていることもあり、Aurora、Redshift 間のデータの同期というのは悩みのタネでした。苦肉の策でバッチの実行間隔を狭めたりはしていましたが、あまりクールな解決とは言えませんでした。 そんな中で登場したこの新機能。いやぁ、待望と言わざるを得ないですね。これが入ると上述したような悩みのタネが一気に解決されます。 ただ、まだプレビュー版なのと、おそらく Aurora MySQL v3 からしか利用できないっぽいので、社内にある Aurora クラスタたちを v2 から v3 に上げていかなければならなそうなのはかなり大変かも。

２つ目は、Fully Managed Blue/Green Deployments です。

aws.amazon.com

これは、Aurora クラスタのバージョン更新作業などのメンテナンス時に、Blue/Green デプロイメントを AWS 側の用意してくれたスキームで実施できるというものです。これは re:Invent の keynote とかで発表されたわけではなく、初日ぐらいにさらっとニュースが出ただけなのですが、マジで待望の機能でした。

軽く説明すると、Aurora にはエンジンバージョンがあります。で、バージョンがあるということは当然 EOL もあり、EOL までにアップグレードをかけなければならないのですが、このアップグレードの際にどうしても DB にダウンタイムが発生してしまいます。in-place upgrade というボタンをポチッとするだけで上げられる方法を使うとアップグレード自体は簡単にできるんですが、read も write も平気で10分以上止まるので認証サーバーなどのクリティカルな DB では採用できません。

では、そいつらどうやってアップグレードするかというと、もう１個クラスタを用意してそっちにデータをレプリケーションしつつ、アプリケーションからアクセスする writer をえいやで切り替える方法を取ります。この方法だとアプリケーションから接続するエンドポイントを切り替えるだけなので、まず read のダウンタイムは発生せず、かつ write のダウンタイムも数分で済みます。

じゃあ全部レプリケーション方式でやればいいじゃん！と思うかもしれませんが、このレプリケーション方式、マジで準備が面倒くさいんですよね。いや、本当に作業と確認しなきゃいけない項目が多すぎて時間とメンタルが溶けます。

ということでここらへんの面倒な準備を AWS 側でいい感じにやってくれて、ぽちぽちすると切り替えができるようにしてくれる（らしい）のがこの Blue/Green Deployment 機能になります。早口でいっぱい喋っちゃうぐらいには嬉しい。

Build your first project with Amazon CodeCatalyst [Workshop]

@hilinker です。今回発表された新サービスの１つである Amazon CodeCatalyst を触ってきました。最初は、「CI/CD をいい感じにしてくれるぐらいかな〜」と思っていたらそれだけではなく、なんか開発に必要なサービス全部入ってますみたいな超巨大サービスでした。

まず、Git レポジトリの機能があります。そして、当然 issue/PR が作成できます。この時点で結構面白いんですが、さらにファイルを Cloud9 で開けて当然コードの編集ができます。レポジトリ内に manifest ファイルを定義するだけで PR の CI や CD の workflow を CodePipeline 上に作成できます。当然、実行や結果の確認、ログ出力なども CodeCatalyst 上でできます。さらに CloudFormation との連携も提供されているのでインフラ管理もお手のもの……

未だかつてなくオールインワンのサービスで、来るところまで来たなという感じがして笑っていました。難しいこと考えずにとりあえず AWS に乗っかれば大丈夫というのはだいぶ面白いですね。

ただ、こんだけオールインワンでやっていながら結構他からの移植性みたいなのは気にしていて、たとえば IDE で言えば Cloud9 だけでなく普通に VSCode や IntelliJ も使えたり、GitHub をレポジトリソースにできたり、Jenkins などと連携できたりと部分的に既存のものを使えるようにしているのは割と気を遣っているなという印象でした。

個人的にちょっと面白かったのは、CodeCatalyst のアカウントは AWS アカウント（やその中のユーザー）とは別のものということですかね。１人は１つの AWS Builder アカウントを持っており、それが複数の AWS アカウントと結びつくという関係らしいです。

[NEW LAUNCH!] Provision and scale OpenSearch resources with serverless [Breakout Session]

@naoki_shigehisa です。このセッションは新機能の OpenSearch Serverless についての Breakout session でした。名前の通りですが、 OpenSearch Service のServerless モードがプレビューとしてリリースされたという内容です。

クックパッドの検索では主にsolrが使われていますが、 OpenSearch Service もどこかで活用できないかなと思っていたところ keynote で Serverless モードが発表され、興味津々でセッションを聞きにいきました。

驚いたのは Serveless モードでサポートしている auto scaling の機能を実現するための構成が、クックパッドの solr を使った検索システムの構成とかなり似ていたことです。

techlife.cookpad.com

具体的には indexing 用の unit と search 用の unit が別に存在し、indexing 用の unit は index を作成して s3 に保存し、 search 用の unit は s3 に保存された index を使って起動するという構成です。時代がクックパッドに追いつきましたね。 現状ちょっと値段が高かったのですぐに活用するのは難しいかもしれませんが、せっかくなのでどこかで試しに使ってみたいなと思っています。

こちらのセッションは録画も公開されていたので、リンクを貼っておきます。

www.youtube.com

Improve search relevance with ML in Amazon OpenSearch Service [Workshop]

@naoki_shigehisa です。このセッションは SageMaker と OpenSearch Service を使って、単語の embedding を使ったテキスト検索を実現する workshop でした。

SageMaker 内で起動した notebook から OpenSearch へ embedding を含めたドキュメントを登録しておき、実際に検索する時にはSageMaker を使って作成したエンドポイントに対して検索クエリを投げて取得した embedding を使って OpenSearch に向けて検索リクエストを投げる形式で実装を行いました。これによって、単語の完全一致ではなくある程度意味を考慮してドキュメントの検索を行うことができます。

workshop用のコードの大半は予め用意されていてほとんど notebook 上でコードを実行するだけではありましたが、実装に必要な作業を大まかに把握できました。

機械学習の用途としては割とありがちなものだなと思いましたが、ほとんどの作業が SageMaker 内で起動した notebook 上で済むのはとても便利だなと感じました。モデルのデプロイやエンドポイントの作成まで notebook 上でコードを実行しているだけで完了するのは嬉しいですね。ぜひ活用してみたいです。

AWS GameDay: The New Frontier

id:sora_h です。先に述べたようなインタラクティブでアーカイブがないセッションとして、今年もGameDay に参加してきました (月曜午後の回)。当然、ランダムなチーム構成を希望して現地にいる他の知らない参加者とチームを組んで挑戦します。

最初に結果だけ書いておくと、2 度目の優勝を遂げて 2019年ぶりに Keynote の特等席を得たりしていました。

今年、というか近年の GameDay は他イベントでの再利用など横展開がしやすいようにするためか、初期の競技性があるもの — 全てをデプロイしてそれをちゃんと動かし続けてポイントを得る、ではなくクエストでポイントを稼いでいく形式、実質的に AWS コンソール操作 RTA レースみたいになっているのはちょっと残念と言えます。今回も多分に漏れずその傾向で、難易度が高いクエストから処理していけば上位にいけるので、悲しいところです。

いちおう Learning Opportunity の一環としてのゲームであるため、他のメンバーのサポートなどに回ったりしています。他の会社どころか他の国や出身の人達と同じ目的に対して頑張るという意味では貴重な機会なので、ここはたいへん楽しいところで、そしてたいへん運ゲーなところですね。

また頻繁に上位にいるせいで PM に顔を覚えられていて、またお前か…のような反応を得つつ公式からツイートもされる始末です。うかつな結果を残すわけにはいかないので、引き続き精進しようと思います。

思い出

参加メンバーで会期後にグランドキャニオン含むツアーに弾丸参加したときの写真です。（id:sora_h は Re:ステージ! のライブに行くために一足早く帰ったため、5人での集合写真が存在しませんでした）

さいごに

クックパッドでは AWS re:Invent の参加を通して、実際のサービス・基盤開発に活かせることを発見したり、より効率よく AWS を利用できないか研鑽する取り組みを続けています。こうしたブログでの発信に留まらない発見や知見更新のチャンスが社内に溢れているためです。

クックパッドには経験年数問わず、熱量のあるエンジニアがこうしたカンファレンスに参加できる環境があります。興味を持っていただけた方は下記のリンクより採用情報を参考にしてみてください。

cookpad.careers

【前編】企業所属のRubyコミッター対談！ 〜企業に所属するOSS開発者って何？〜

こんにちはCTO室の緑川です。今回はアンドバッドさんが主催しているPodcast「ANDPAD TECH TALK」第12回目のゲストに弊社の@mameが出演したので、対談内容を書き起こしました。Podcastとしてお聞きしたい方は下記のアンドパッドさんの記事からお聴きください。

tech.andpad.co.jp

トーク本編

櫻井：皆さま、こんにちは。アンドバッドの開発本部でエンジニアリングマネージャーをしている櫻井です。

櫻井：12回目のANDPAD TECH TALKです。ANDPAD TECH TALKはアンドパッドの中の人をゲストに招いてあれやこれやお話するカジュアルなテック系Podcastなのですが、今回スペシャル対談会として、社外ゲストをお招きして、アンドパッドの中の人の対談をお届けしたいと思います。今回は企業に所属するRubyコミッターであるお二人をお招きしております。

櫻井：アンドパッドからはRubyコミッターでありフェローの柴田さん、対談相手はクックパッド株式会社所属のRubyコミッターであるmameさんこと遠藤侑介さんをお呼びしております。柴田さんと遠藤さんの対談は前編・後編の２回に分けて配信します。前編では「企業に所属するOSS開発者ってなに？」と題して話を掘り下げていきたいと思います。

自己紹介

櫻井：本日はよろしくお願いいたします。早速ですが、遠藤さんの自己紹介をお願いできますでしょうか？

遠藤：こんにちは遠藤といいます。僕は大学院を修了したあと、企業の研究員として働いている時に、趣味でRuby開発に携わり始めました。それをしばらく続けていくうちにクックパッドに転職をして、今は笹田耕一さんというRubyのVMまわりを主に開発しているRubyコミッターと一緒にフルタイムでRubyの開発をするチームに所属して、日々活動しています。

遠藤：自分のRuby開発の担当範囲はいろいろな範囲にわたっていて、一番みんなが使っているところで言うと、キーワード引数周りの設計や実装を担当したのが大きいかなと思います。他には、コードカバレッジの測定をするためのバックエンドとなるライブラリの開発はクックパッドに入る前からやっています。クックパッドに入社したあとはRuby 3に型システムを入れるという話があったので、型システムまわりの議論をまとめ、TypeProfという型システムの試作を中心にやってきています。趣味はQuine（クワイン）と呼ばれる自分自身を出力するプログラムを書くということで、この趣味が高じて本を書いています。

櫻井：ありがとうございます。ちなみに、遠藤さんはmameさんというお名前で活動されていると思いますが、本日は遠藤さん、とお呼びさせていただこうかと思っていますがよろしいでしょうか？

遠藤：はい

櫻井：ありがとうございます。ちなみにですね、mameさんというハンドルネームの由来をお伺いしてもよろしいですか？

遠藤：子どもの頃のあだ名ですね。遠藤豆とよく呼ばれていたので、そこから取ってきたハンドルネームですね。日本チームにしか伝わらない。

櫻井：ありがとうございます。すごいシンプルな由来ですね。

一同：笑

櫻井：遠藤豆さん、と言うところからですかね？

遠藤：そうですね、単純に。

櫻井：ありがとうございます。皆さん、シンプルな理由でした。では、柴田さん、自己紹介をお願いいたします。

柴田：はい、よろしくお願いします。柴田 博志といいます。アンドパッドには、2022年の11月1日にフェローという肩書きで入社しました。前職では、執行役員（VPoE）だとか技術部長を兼務していて、マネジメントを主に担当していたのですけれども、現在は開発本部の直下に所属している一エンジニアみたいな肩書きになっていて、毎日部門で見かけた課題だとかエンジニアやマネージャーなどの幅広い人の相談にのったりと、前職の経験を活かしながら開発組織を支援する業務を担当しています。あとですね、フルタイムでRubyの開発をするのがメインの業務としていまして、僕は主にRubyで書かれている（Cで書かれているものもあるんですけど）、Rubyのライブラリであるとか、ライブラリを使うための RubyGems bundlerというソフトや仕組みがあるんですけど、そっちの開発を行っています。あとはですね、そのRubyというソフトウェアを開発するために必要なインフラであるとか、あとはSaaSのようないろいろなサービスを利用しているんですけど、そのメンテナンスとか管理も担当しています。趣味としてはいろいろと幅広く、アウトドアの趣味としては最近は美術館巡りで、アート・芸術・社会学関係の本を適当に買って読むということをやったり、あとは家の中ではゲーム・アニメ・漫画など家の中でできる遊ぶ系のものは大体プレイしたりいろいろやっています。最近は先週くらいにThe Witcher 3というPlayStation 4で出てたものすごい名作であるゲームが、PlayStation 5バージョンで出たのでずっとそれをやっています。　

櫻井：ありがとうございます。The Witcher 3の5バージョンが出たんですね。

柴田：はい、出たんですよ。

櫻井：今、アウトドアとインドアと幅広い趣味を紹介いただいて、どこを深く聞こうかな、と思ったのですが、思わずThe Witcher 3に食い付いてしまいました。

一同：笑

柴田：そうなんですよ。PlayStation 4の時は、ちょっと買って1時間くらいプレイして、まぁいいやって置いといたんですよね。PlayStation 5バージョンが出たのでやってみるか、と思って1時間ではなく4時間くらいプレイしたらめちゃくちゃ面白いじゃんとなって、今20時間くらいプレイしているんですけど、全然終わる気配がないので、もっともっと時間を投入してプレイしようかと思います。

櫻井：The Witcher 3、こう聞くと、私もやってみてみたくなるので意識しておきます。

Rubyコミッターってそもそも何？

櫻井：Rubyコミッターってそもそも何？ どういうことをする人なの？ という方も視聴者の中にはいらっしゃると思いますので、本日はそういったところもお二方に聞いていけたらなと思っております。遠藤さんと柴田さんは古くからお互いをよく知る間柄だとお聞きしましたが、どういったきっかけで知り合うことになったのでしょうか？

遠藤：はい、柴田さんと知り合ったのはRubyの開発がまさにきっかけですね。僕が2012年ごろにRuby2.0というバージョンのリリースマネージャーをやっていて、Rubyをリリースするためにいろいろな活動をしていたのですけど、その時に柴田さんが新しいRubyでRailsアプリケーションを走らせてみたり、結構テストしていてくれていて動かないところを報告するという活動を継続していてくれていたのを見ていて、その時にRubyの開発者であるまつもとゆきひろさんに「柴田さんへコミット権限を差し上げたらどうでしょう？」という話をして「いいね、いいね」という話になって、それがきっかけで柴田さんがRubyのコミッターになったという話があります。

櫻井：なるほど、その頃から柴田さんも遠藤さんのことはご存じだったのですか？

柴田：ちょっと覚えていなくてですね、たしかこの時ってRubyの20周年イベント前後ぐらいでしたよね？ 2012年の2月前後だったと思うんですけど、当時はSlackもなかったし、Twitterはあったけどどういう感じで使っていたかわからなかったので、おそらくメールとかRedmineという課題管理ソフトを使っているんですけど、その上で頻繁に見かける方だったなとか、Ruby2.0をリリースするためにいろいろチケットにコメントしたり、クローズしたり、オープンしたりしている方だなくらいの理解でしたね。

櫻井：なるほど。遠藤さんがRubyコミッターになったきっかけや馴れ初めはどうですか？

遠藤：大学時代からRubyに簡単なパッチを書いて送るといった貢献を少しずつしていたのですけども、会社に研究員として働き始めた後くらいからRuby 1.9.0のバージョンのリリースがあって、その頃から本格的に貢献を始めてコミッターになりました。1.9.0のRubyというのは野心的な新機能がたくさんあってバグが結構あったんですよね。なのでバグ出しやパッチ作成などの貢献の余地が非常に多くあったのと、Ruby 1.9.0のリリースをするのにいろんな人たちが寄ってたかってパッチを書いているのが学園祭というかお祭りみたいだったんですよね。それがすごく楽しかったと思ったので深く関わり出したきっかけです。

櫻井：なるほど。楽しそうな印象が伝わってきました。お二人が今の関係性になるまでどんな接点があったんでしょうか？

柴田：そうですね。いつの間にかRubyコミッター同士で知り合いというか仲がいいというか、大体みんなのことを知っているよね、と今はなっているのですけど、馴れ初めを思い出すとなかなか難しいな。僕の記憶だとRubyKaigiのいつだったかの開催の時に、mameさんがクックパッドに転職します、みたいな紹介の回があって、その時くらいから遠藤さんと話す機会が増えてきたと記憶しているんですよね。それまでは遠藤さんは別の会社で働かれていて、昼間であるとか、Rubyに関する活動以外の時間は何しているかは謎みたいな状況だったのですけど、そのクックパッドに転職されて以降はRubyもRuby以外の生活も最近の話だとかそういった部分でもいろいろと会話することがどんどん増えてきていて、実際にRubyの何かをする時だとか、例えばサーバーを何か引っ越したりだとかしますとか、開発に便利なものを何か作ります、というときも遠藤さんに結構手伝っていただいているので、二人でいろいろあーして、こーしてみたいなところを二人三脚でやるといった機会が増えてきて、今に至っているのかな、と思います。あと確か、間違っていたらひどい話なんですけど、同い年なんですよね？

遠藤：そうですね。

柴田：というのもあって、同年代エンジニアとして頑張るぞ、という感じで僕は捉えています。

櫻井：なるほど、それで今回、対談のお相手にぜひ遠藤さんと話したい、というお話が柴田さんからあったということですね。

柴田：はい、そうです。

遠藤：柴田さんとは、説明にあった通り、Rubyの開発をするインフラ管理なんかでだいぶお世話になっていますし、RubyKaigiとかRubyConfとかのRubyに関するイベント参加の時に一緒にうろうろするとか一緒にご飯食べるとかさせていただいています。なので、今回このアンドパッドにフルタイムのコミッターとして転職されて、どんな話をするのか非常に面白そうだと思って今回呼ばれました。

櫻井：今日のテーマが「企業に所属するOSS開発者ってなに？」なんですが、そもそもRubyコミッターってなに？という方も視聴者の中にはいらっしゃると思っています。なので、お二人から少し解説をいただけると嬉しいな、と思っていて、遠藤さんお願いいたします。

遠藤：はい、コミッターというのは、昔のバージョン管理システムの用語なんですけども、ソースコードの更新をする権限を持っている人のことです。gitだとコミットというのは履歴に変更を積むというだけの作業なんですけど、昔、gitよりも前のバージョン管理システムCVSだとかSVNだとかサーバー側に置いてあるソースコードを更新する行為のことを呼んでました。なのでgitの時代というとmergeだとかpushに相当するのですけど、その当時にコミットできる権限を持つ人をコミッターと、特に日本のRuby界隈ではソースコードを変更する権限を持っている人のことをコミッターというふうに呼ぶことが多いと思います。

櫻井：なるほど。そういう経緯からコミッターと呼ばれているんですね。僕も知らなかったですし、詳細までありがとうございます。

どうしてオープンソースで開発をしているのか？

櫻井：最近だと、オープンソースのソフトウェアを利用して、企業がサービスやプロダクトを開発するということが当たり前のようになってきているかな？ と思うんですが、若い方はOSSとはそもそもなんなのか？ あとどうしてオープンソースで開発をしているのか？ といったようなところも知らないエンジニアもいらっしゃるのかな？ と思っています。例えば、Googleなどの企業が母体となっているオープンソースプロジェクトなども増えてきている印象なんですが、その辺り柴田さんにお伺いしてみてもよろしいでしょうか？

柴田：はい、非常に難しい質問というか、解説になりそうな気がするのですけど、できる範囲でやろうかと思います。僕の理解としては、オープンソースは狭義のオープンソースと広義のオープンソースがあるかなと思っていて、狭義の意味としては「オープンソースデフィニション」という「これを満たしたソフトウェアはオープンソースであるよ」というものがあるんですね。それを満たしてたらなんでもオープンソースである、と言えます。それを開発している人はもちろんオープンソースの開発者になれる。なので、別にRubyみたいにプログラミング言語だけでなく、なんか自分で作った自分のカレンダーを管理するだけのソフトウェアであったとしてもそれがちゃんとオープンソースの定義に合致していればもちろんオープンソースですし、それを開発している方はみんなオープンソースの開発者であると、一旦狭い意味でのオープンソースです。で、もうちょっと定義ではないオープンソースソフトウェアというのは、経済とか社会とかとりまく環境の方で捉えてみるとオープンソースのソフトウェアは経済や社会みたいな部分だと今までにはない、不思議な存在となっていて、で、それが何かというとですね、会ったこともない人がなぜか自社の利益や売上を生むようなビジネスの中心にあるソフトウェアをメンテナンスしていて、なぜか何もお願いしていないのに不具合があったら直してもらえるし、欲しいなと思っている機能があったら開発をしてくれる、でそれを使ってそれぞれの所属している会社であるとか組織とかの利益や目標のためにそれを使うことができる。しかも無償で。というのがオープンソースソフトウェアの不思議な存在になっています。で、他の業界を見るとですね、たとえば、アンドパッドがメインとしているような建設業界だとか他の機械だとかいろいろな業界がありますけど、そういった業界ですと、こういうオープンソースのソフトウェアと似ているものはほとんどないな、と思っていて、ほとんどが特許、設計図だとかそういった規格は特許に守られていて、使うためには利用料金を払わなければなりません、とか、なんならもう使えない、みたいなものもいっぱいあるんですよね。ソフトウェア業界だと、オープンソースソフトウェアというものがあって、なぜか他の会社が開発したり、一個人が開発したものを無償で使って、それをビジネスの原動力に使える、というものになっています。でそれが今まで、現在進行形ですけど、オープンソースソフトウェアのざっくりとした説明になっていて、そのオープンソースソフトウェアのメンテナンスはいろんな人が何もお願いしなくてもずっと無限にやり続けてくれるのかというとそういうわけでもなくて、そのオープンソースソフトウェアというものがですね、ビジネスの中心になればなるほど、ビッグテックと呼ばれるようなGoogleだとかAppleだとかといった企業が主導してオープンソースのソフトウェアをメンテナンスしたり、会社によってはですね、社会全体の利益よりも自社が使いたい機能なので、といった形でそれを開発しているとか、いろいろ難しい問題も起きているというのが現状です。で、そのような中でですね、Rubyというプログラミング言語がありまして、私柴田であるとか、遠藤さんはそれぞれべつの企業に所属しながらも、それぞれの企業の事業の中心として使われているRubyのメンテナンスを業務として毎日行っているというのが現在になっています。

櫻井：Rubyの場合は母体となる企業があるわけではなくて、コミュニティが主体となって、活動してきているということですね。そういったコミュニティがメンテナンスや開発を進めていかないと、いけないというところで、本日のリスナーの皆さんが気になっている企業所属のOSS開発者とは何か？ というところで、なぜ企業は自社のサービス開発ではなくてOSSの開発を主体とするエンジニアを迎え入れるのか、という話につながってくるのかな？ と思います。と、いったところで、お二人が企業所属のRubyコミッターになった経緯をお伺いしたいと思います。まずは遠藤さんから、よろしいでしょうか？

遠藤：はい、前職の企業で研究者をやっていた時から趣味としてRubyの開発には参加していたのですが、自分も周囲も特に業務でRubyを使用しているわけではなかったので、いまいちRubyに実際にどうのような機能が求められているのか、といった現場感があまりなかったのがあります。そんな中でRuby2.0のリリースマネージャーを務めて、結構盛大なリリースパーティー、２０周年かつ2.0のリリースパーティーといったものが行われたんです。実際のリリースはその翌日にですね、自分が自宅から、確か冬だったのでコタツで細々とリリース作業をするという自分ではあまり使用していないRubyをリリースするということをやっていて、一抹の寂しさのようなものを感じたというのがあります。そんな経緯もあって、そこからしばらくRubyの開発から1、2年ほど離れるんですけど、世間はその間にですね、ちょうどRuby on Railsが非常に盛り上がり始める時期だったので、Rubyの需要がさらに盛り上がっていき、遠目に見ていて楽しそうだな、と思っているところがありました。で、その時にクックパッドに転職をしたばかりの笹田さんからクックパッドでRubyの開発をしませんか？ というお誘いをもらったので、転職をするきっかけになりました。その後はクックパッドの中で実際にRubyを開発に使っているという人たちからフィードバックをもらったり、会話したりしながらRubyの開発ができているので、とても毎日が楽しいです。

櫻井：柴田さんは11月にアンドパッドにジョインしたばかりで、当時、入社エントリーブログを読んだ方もいらっしゃるかもしれませんが、改めてお話を聞かせてください。

柴田：そうですね、私の場合はですね、Rubyを開発するのに必要なCIであるとか、インフラであるとか、周辺ライブラリのメンテナンスをすることをメインの担当領域としているのですけども、今まではですね、ぜんぜん前職ではRubyの開発はメインの仕事ではないので、いろいろとやる領域が広まれば広まるほどなかなか時間を作れなくって、Rubyのことをやるということが難しくなってきて、やりたいこととかやらなくちゃいけないことはいっぱいあるんですけど、時間をなかなか捻出できない、夜はもう疲れたので無理、みたいな形が続いてきて、そういった中で、たまたま話を聞いてみたアンドパッドのVPoEの下司さんにですね、最初の方はエンジニアリングマネージャーを採用したいといった形で僕に話をしてきたところに、僕がオープンソースの開発者として雇ってくれませんか？と逆にアピールをして「できるかもしれません」と下司さんにいろいろと動いていただいて、今に至って、今はRubyの開発をメインとしてやっています。で、遠藤さんも仰られた通り、会社の中でRubyを大規模に使って、プロダクトを作っているので、Rubyでこういうことに困っているだとか、こういう部分をよくしたいと思っている、みたいな部分ももちろんあるんですけど、最近はRubyの開発者の中でもフルタイムでRubyの開発を行う方が海外の会社も含めて増えてきていて、そういった中でこういう開発はどうかとか、こういうコードはどうかみたいな、そういう話であるとか、後は技術的な課題も含めて課題を議論したりだとか、そういったもので非常に毎日が刺激的なもので前職よりも1日の仕事をして疲れたというのが、11月からの現在の僕の状態です。

Rubyコミッターになるためのステップとは？

櫻井：このPodcastを聞いているリスナーの方々の中にもですね、Rubyコミッターになりたいという方もいらっしゃるかな？と思いますので、コミッターになるにはどうすればいいのか、どんなステップがあるのかを教えていただけたらと思います。

遠藤：はい、基本的にはRubyの重要なバグを修正していただけるとか、すごく重要ではないけれどたくさんのバグを修正していただけてくれるとか、他には大きな改善を提案してくれるとか、そういった貢献をしてくれた人には、そういう活動を続けてくださいとか、その改善をぜひメンテナンスしてくださいという意味でコミット権をお渡しして、その後勝手にやっていただくというのがよくあるパターンだと思います。

櫻井：ありがとうございます。他のオープンソースプロジェクトと同じようにコアコミッターでなくとも、Rubyに貢献することは誰でもできるということですね。貢献度の高い人はコアコミッターになれるという認識で大丈夫そうですかね？

柴田：そうですね。

櫻井：ありがとうございます。どうやって貢献していけばいいのか？ は、また後半のRuby開発の裏話と今後の取り組みの方で深堀っていきたいと思います。Rubyコミッターは普段どんなことをしているんだろう、と気になっている方も多いのかな？ と思います。アンドパッドのアドベントカレンダーで柴田さんがメールサーバーの移設の話を書かれていたと思いますが、そういったこともやられているというのは正直なところ驚きでした。

柴田：そうなんですよね、会社でプロダクトやサービスを開発する場合には、最近ですとSREというポジションの方がいたりだとか、社内のIT部門であるとかそういう専任で横断的な活動をする方がいらしゃって、そういった方達がプロダクトやサービスを作る人たちを支えるみたいな活動であるとか動きをしているものだと思うんですけど、Rubyの場合はですね、Ruby開発会社みたいなものがあるわけではなくて、言語としてのRubyを開発したいという人たちが10人、20人いますといった状態なんですね、なのでGitHubの設定だったりとか、GitHubのCIを誰がメンテナンスするのかだとか、後はもちろんお金がかかるものに関しては誰が請求書を切って、お金を払うのか？　みたいな部分とか、そういった部分が宙に浮いちゃうわけですね。なので、私柴田とNaClという会社にいらっしゃる前田さんという方の二人が主にメインの担当としてRubyの開発の社内IT担当みたいな形でいろいろ動いているような動きになっています。

櫻井：遠藤さんは普段、どんなことをやられているのでしょうか？

遠藤：はい、日常的にはですね、Rubyに送られてきたバグ報告とか機能提案だとか脆弱性の報告なんかも来るんですけど、そういうのを読んで、トリアージしたり、簡単であれば修正したり、というのが日々やっていることになります。あと、RubyのCIっていろんな環境でテストが走っているんですけど、それが変更によって落ちたりし始めるんですよね。そういったことが起きたら直す、ということもやっています。と、日常的な話としては、Rubyは月に一回開発者会議というのを行って、送られてきているバグ報告や機能提案について議論するということをやっているんですけど、その時のアジェンダを作成したり、最終的に書かれた議事録を公開したりだとか運営作業も行っています。より長期的な仕事としては最近はRubyに大きな改善を計画してくれる人たちと協力したり提案してくれる人を支援したりすることも結構増えてきています。Ruby3に入ったRubyの基盤となる型記述言語RBSというのがあり、Steepという型チェッカーを作っていたんですけど、それに対してはいろいろ口を出させていただいてRubyの本体に連動させるようにいろいろとアレンジさせていただいていましたし、去年はWebAssemblyに対応させるという結構大きな話があって、それをほぼ一人でやってくれたkateinoigakukunといろいろ話したり、支援させていただくこともやっていました。最近だとですね、ちょうど9月くらいからクックパッドにインターンに来てくれていたMakeNowJustっていう人がRubyのReDoS脆弱性と呼ばれる一種の脆弱性のリスクを大きく下げる改善というのをしてもらってそれも無事Rubyにmergeされたので、その成果でRubyのコミッターになってもらうということもあったりしました。今後は個人的に注目しているのはShopifyという会社の人たちがRubyのパーサーを大きく改善するという計画を立てているというレポートを注入してくれているので、それもいい感じにアレンジさせてもらったり、期待しているところになります。

櫻井：ありがとうございます。ちなみに、Rubyコミッターの方は何人くらいいるんでしょうか？

遠藤：前数えた時はおおよそ100人ちょっとだったと思います。ただ昔コミッターになったけれども、今はほとんど活動していないという人も多いので、この一年くらいでアクティブに活動している人というと15人くらいから20人ちょっとくらいかな？と思います。

櫻井：なるほど。そのアクティブな方々の担当みたいなものってあったりするんですか？

遠藤：漠然とあったりなかったりする感じですね。macOSに関するバグだったら、この人に一旦話を振るだとか、Rubyのこの機能に、たとえばカバレッジだったら、僕に振るだとか比較的はっきりしているところもあったりしますけど、誰もあまり興味がないところはみんなが見たりしたりしています。

櫻井：漠然とというところですね、OSS開発はチーム開発と比べて、どう違うんでしょう？

柴田：そうですね、まずRubyに関する話をするので、そのオープンソースソフトウェアが全部こうだという話ではないというのは事前にお伝えしておきますけども、Rubyの場合はですね、開発計画みたいなものはないんですよね。プロダクトやサービスの場合だと、いつ頃までにこういうものを作って、どういうユーザー向けにこういうものを出します、というまず開発計画があって、それに対して、じゃあ、いついつまでに作るにはこうしないといけないよね、という解像度を上げ下げして、ソフトウェアの開発を進めていくというのが、まずチーム開発というか会社でのソフトウェア開発だと思うんですけど、Rubyの場合はですね、毎年1バージョンはリリースするということだけが決まっていて、あとはRubyの開発者であるまつもとゆきひろさんが今後はこういうことをやっていきたいなー、といういわゆるプロダクトマネージャーみたいなすごい大方針的なものがすごくものすごく、フワッとしたものだけあるので、じゃあ、誰がいつまでに何をどう作るのか？みたいなものは誰も決めていないし、決めようとしてもいないという感じですね。とはいえ、そのそれぞれ15人から20人くらいの人が何か自分の好きなものだけをがーと開発していると、じゃあRubyどうなっとるんだ？ってなって、結果として誰にも使われなくなるということは、みんな知っているので、それぞれ自分がやりたいことは持ちつつも、お互いに話したり、作ったパッチだったり、これはこうではないか？みたいなことをディスカッションしたりしながらプログラミング言語Rubyとして違和感がないものをみんなで頑張って作っていこうという形になっていますね。で最近はmameさんも仰られたけど、毎月開発者会議という形で話す時間を設けたり、日本語で行っているんですけど、オフィスアワーという形で毎週ゆるく話す時間を用意したりしていて、この機能のことだよね、いやいやそういうことではない、みたいな部分を擦り合わせたり、その認識のギャップみたいなものを洗い出すということをやっています。でコミッターと呼ばれる人たちはですね、それぞれが一人でわりかしなんでもできる人が多くて、そのインフラ作って、コード書いて、サービスをリリースします、なんならマネージャも別にやります、みたいな人とかばっかりでそれぞれがですね、チーム開発ではないんですけど、チームプレイをしながら、Rubyの開発をしていると。マネージャーはいなくて誰かが時間の管理だとか次に何をするかといった管理はしていないんだけど、コミッター同士でうまく話を合わせ、こういうことかな？っていうニーズを掘り出して、実際に作って、リリースするというような形で開発を進めているのがRubyというオープンソースソフトウェアの開発体制となっています。

櫻井:ありがとうございます。だいぶ具体的なお話も出てきてですね、とても面白い話になってきて、続きが気になる方も多いと思いますが、今回のANDPAD TECH TALKは以上とさせて頂きまして、この続きは次回柴田さんと遠藤さんのスペシャル対談の後編として企業所属のRubyコミッター対談、Ruby開発の裏側と今後の取り組みでお届けしたいと思います。

柴田：そうですね。後半ではもうちょっと技術的、もしくはRubyの課題のような部分に踏み込んだ話ができればな、と思います。

櫻井：どんな踏み込んだお話が聞けるのかワクワクしております。次回はお二人の具体的な活動や裏話を盛り沢山でお届けする予定です。ぜひお聴きいただければと思います。それでは次回、またよろしくお願いいたします。ありがとうございました。

さいごに

前半はここまでです。後半は1月27日(金)ごろにアップをする予定です。 クックパッドではサーバーサイドやOSSに関わりたい仲間を募集しています。ご興味のある方はぜひご連絡ください。

cookpad.careers

エンジニアリングマニフェストを刷新しました: クックパッドの開発者文化をあらわす3つの言葉

CTO の成田（@mirakui）です。 クックパッドはいま、2017年からの10年間を投資フェーズとして位置づけていて、ミッションである「毎日の料理を楽しみにする」を実現するため、長期的に成長していけるための事業づくり、組織づくりに投資をしています。

クックパッドは価値のあるプロダクトをユーザに届け続けることが事業の中心にあり、そのためにはエンジニアの活躍が不可欠です。クックパッドにおけるエンジニアというのは、単なる「実装担当」ではなく、自発的に課題を発見し、一人ひとりの専門性や創意工夫をもって開発をしていくことが求められます。強い個人が集まって、それぞれの能力のうちの高い部分をお互いに引き立て合って、一人ひとりでは解決できないような大きな課題に取り組めるようになる。私は CTO として、クックパッドのエンジニア組織をそのように強化していきたいと考えてきました。

エンジニアリングにおいては、エンジニアの人数を増やしていくことが組織の生産性をあげるかというと、私はそうではありません。エンジニア10人の組織と100人の組織とでは、プロダクトの品質という意味では差が出てくるかとは思いますが、突破できる事業課題の大きさにはあまり人数は関係ないのではないかと考えています。それよりも一人ひとりが重要な課題に取り組めているかどうかが重要です。平均的な100人よりは精鋭の10人の組織でありたいですし、少数精鋭の10人が集まった100人の組織でありたいと考えています。そういったエンジニア組織を目指すため、チームワークによる生産性を目指すよりも先に、個々人の能力、リーダーシップを高めることを重要視しています。

私は今年、一人ひとりが自律的で卓越したエンジニアの集団を目指すために、クックパッドのエンジニアとしてのあるべき考え方・文化を言語化した「エンジニアリングマニフェスト」を制定しました。実はマニフェスト自体は以前から存在していたのですが、これからの成長を見据えて、新しい言葉で置き換えることにしました。それぞれ日本語と英語の表記を用意し、これを日本だけでなく海外のエンジニア組織も含めて統一しています。

クックパッドのエンジニアリングマニフェストは、次の3項目からなります。

  1. 境界を越える (Beyond boundaries): 私たちは一人ひとりが高いリーダーシップを持った個人になるために、自分の能力の限界や、責任範囲に対する思い込みを乗り越えて成長していくエンジニアを目指します。
  2. 技術を楽しむことに責任を持つ (Responsible for enjoying technology): 私たちは一人ひとりが技術を楽しむ集団であることを目指します。困難な状況であっても、常に技術的な挑戦の機会を諦めません。一人ひとりに技術を楽しんでいる自分を目指す責任があります。
  3. 作ったもので語る (Speak with what you make): 私たちは動くものをすばやく生み出せる存在として価値を発揮します。また、作ったものを実際に触れることで得られる気づきを尊重します。

以下、それぞれについて解説します。

1. 境界を越える (Beyond boundaries)

「境界を越える」は最もクックパッドのエンジニアらしさを表す言葉だと考えています。これは、知らず知らずのうちに自ら作り出している「境界」を見つけ出し、それを乗り越えていこう、ということを意味しています。境界は、例えば自分の能力の限界や、所属している部署の役割、自分の役職に与えられている裁量だったりします。

たとえばエンジニアが一人しかいないスタートアップであれば、その人はコーディングだけでなくさまざまな領域をカバーしなければなりません。しかし組織が大きくなると役割は細分化され、自分の限られた領域の仕事をしていれば済むようになります。その場合たとえ組織の人数が増えても、ただ役割を細分化していくのでは、本当の意味で課題に立ち向かう人数は増えていないということになりかねません。 自分の役割にとらわれずに、スタートアップの一人エンジニアのような責任感や柔軟さ、視座をもって立ち回れることは、クックパッドのエンジニアとしての大きな強みになると考えています。

2. 技術を楽しむことに責任を持つ (Responsible for enjoying technology)

二つ目として、私のエンジニアとしてのスタンスを最も表した言葉を選びました。

私たちの会社のミッションは「毎日の料理を楽しみにする」であり、「楽しみ」というものが生み出すエネルギーの大きさを信じています。世の中の技術は常に新しくなっていきます。新しい技術が登場してはコモディティ化し、エンジニアに求められる知識も日々変化しています。エンジニアの仕事というのは、そのような時代の流れのなかで常に技術の引き出しを新しくしながら磨いていく必要があります。どんなことでも、頼まれた仕事だから仕方なくやってる人は、楽しくて仕方が無いからやっている人には勝てません。

技術の学習についても同じで、これはどうやって動いてるんだろう、とか、この仕組みをもっと知りたい、とか。こんなことを出来る技術はあるのかな、とか。クックパッドのエンジニアには、こういった好奇心、技術的興味といったものを膨らませて、技術を楽しんで欲しい。

私はさらにこれを「楽しむことに責任を持つ」という強い言葉で結びました。これは、楽しんでいないのだとしたら、楽しんでる自分に持っていくことをそれぞれの責任でやってほしいという願いが込められています。誰かにそうしてもらうのではなく。

私はクックパッドで十年以上勤めてきたなかで、多くの卓越したエンジニアの方々と働く機会に恵まれました。卓越したエンジニアは、特にこの「技術を楽しむ」ということに長けています。忙しい業務のなかでも技術的なチャレンジをうまく入れ込んできます。日々の開発や技術の研鑽を「仕事だからやっている」から「楽しいからやっている」になれたとき、エンジニアとして次のレベルに成長できると考えています。

3. 作ったもので語る (Speak with what you make)

プロダクト開発では、初手から完成品を作るのではなく、まずは小さく価値を表現できる MVP を開発して検証する、というのはすでに世の中の当たり前になってきています。動くものを作り出せるというのは、エンジニアの強みどころか、存在理由でさえあると私は考えています。だからこそ、エンジニアがアイデアを表現する手段は、言葉よりもコードであってほしい。「こういうものがあったら良いよね」ではなく、「こういうものを作ってみたんだけどどうかな」という会話であるべきです。

私はクックパッドで働いてきて、サービス開発のプロセスは探索的であり、10個作って10個捨てることの繰り返しであると学びました。本当に優れたプロダクトを目指しているとき、比類無き一手を生み出せないくらいなら、一手も進めない方がマシだからです。打席に立つ回数や質を上げていくには、エンジニア一人ひとりが「作ったもので語る」ことが当たり前な文化があれば、より確度の高い一手に近づくことができるはずで、それによって未来を変えていけると私は信じています。

おわりに

クックパッドのエンジニア組織は、一人ひとりが卓越したエンジニアとなり、個人の能力の掛け合わせによって大きな事業課題を解決していくことを目指します。そのために重要と考える3つの要素を「エンジニアリングマニフェスト」として言語化し、これからのクックパッドのエンジニア文化としていきます。