さくらインターネット入社から1年半が経ってクラウドサービスのプロダクト責任者になった

これ自体は実際のところは前からやってることと変わってないのだが、4月の組織変更で明示的にそうなったというのも含めてメモしておこうと思った。

TL;DR

• ガバクラ採択めでたいね
• 4月からクラウド事業戦略本部 副本部長になりました
• クラウドサービス全般のプロダクト責任者という役割です
• それはそれとして去年Rubyコミッタになりましたね
• 来週のRubyKaigi 2026でキーノートとして話します

3月末までの話

さくらインターネット入社後3ヶ月のいまの話からずっとプロダクト担当として仕事をしてきて、とりあえず最初に見えていたマイルストーンであるところの2025年度末をこえた。このタイミングでの大きな目標であったガバメントクラウドについては、以下ニュースなどに出たとおり。

www.sakura.ad.jp

これは開発チームをはじめとして全体で本当に頑張った結果で、達成できて本当に安心した。大きな成果だと思う。さくらインターネットという会社がクラウドサービス開発をきちんと行える会社であること、クラウドサービスを本気で今後も運用・発展させていく気があることを示せたんじゃないだろうか。

一方、ガバメントクラウドだけやっているわけでもなく、その他に今後数年間のクラウドサービス成長を考えてやっていることもあれこれある。ビジネスとしての話もだし、ガバメントクラウドに含まれていなくても、クラウドサービスを使うときにどうしても欲しいもの、みたいなものもある。クラウドサービスのアイコンセットはそのうちのひとつで、これも無事に公開できるところまできて良かった。

www.sakura.ad.jp

そんなこんなをやる中で、形としてはいち社員、いちPdMだったんだけど、実質的にはクラウドのプロダクト全体をリードする状況でここまで働いてきた。なおコードは1行も書いていない。

「ガバクラという目標」が無いこれからのクラウドサービス開発

これまでの2年間半、良くも悪くも「ガバクラ」という大きな目標があったのでそれに向かって開発を進めてきた、という面は否定できない。それがひと段落ついたこれから本腰を入れて考えないといけないのは、さくらインターネットのクラウドサービスはどうあるべきか、海外の超大手クラウドサービスと較べられる状況で我々は何を強みとして、誰に使われるサービスとなるべきか、ということだ。もちろんこれまで考えなかったわけではないが、開発チームに対して解像度高く届けなければならない。

そういった事情などもあり、この4月に内部で大きめの組織変更があった。結果、クラウド事業戦略本部というクラウドサービスの企画・運営面を担当する部署において、副本部長ということになった。プロダクトマネジメント、ドキュメンテーションおよびサービス運営をおこなうチームを統括しつつ、これまでの役割を明示する形で、クラウドサービスのプロダクト責任を負う。

クラウドサービスというのも人によって見えている形は本当にさまざまで、VMやコンテナでのアプリケーションホスティングだと思う人もいれば、ストレージサービスが中心だったり、ネットワークをまず考えたりする人もいる。セキュリティや監査が本当に重要な業種業界もあるし、もちろん最近はGPUやAIを最優先に検討するケースも多い。

一方、さくらインターネットがクラウドサービスをやるとき、その強みは何かということを考えると、国内で持っているデータセンターによるハウジングあるいは物理サーバのサービスを考えることもある。それはクラウドなのかと言われるとアレだが、コンピューティングの中心がクラウド(オンデマンドなコンピューティングサービス)に移動しつつも、どうしても外せない存在としてオンプレミスや物理サーバを運用しつづける人達もいる。この組合せを最適な形で提供できるのは、海外超大手クラウドサービスには無い差別化要因として、我々の強みになるかもしれない。

そんなことを日々考えたり文書にしたりしつつ、今は組織変更の余波でひたすらばたばたしている。

プログラマーとしての自分

仕事では1行もコードを書いてないんだけど、趣味の面ではここ3年やっているRubyの開発がある。このBlogにきちんとした形で書いてなかったが、去年のRubyKaigi後に自分がつくった機能がRubyに入ることになって、そのときにコミッタにもなった。12月にはRuby 4.0が出るのも見届けた。

これはこれでひとつの区切りでもあったんだけど、実際には自分がつくったRuby Boxという機能は実験的機能で、あちこちが思ったように動いてない状態でもある。正式なリリースに機能として入らないと多くの人が使ってくれないという面はあって、多くの人がさわってくれるようになったらあれこれバグレポートが届いたりもしている。

やることは多いんだけど、年初からこっちはちょっと仕事が忙しすぎて手が動いていないのが悩みどころ。もうちょっとどうにかして時間を確保したい……。

RubyKaigi 2026でお会いしましょう

ところで来週 4/22-24 には函館でRubyKaigi 2026がありますね。もう学生向けチケットしか残ってないですが。

rubykaigi.org

今回はオープニングキーノートを担当させてもらうことになった。わお。RubyKaigiのキーノートをやることがあると人生わからんなあという気もしますね。カンファレンスのキーノートをやるのは初めてではないにせよ、RubyKaigiとなるとちょっと緊張するものがあったりなかったり。これはこれで楽しませてもらおうと思って準備している*1。

ということで

函館で、あるいはあちこちのクラウドや技術の現場でお会いしましょう。今後ともよろしくお願いします!

*1:なおこのエントリは発表準備からの現実逃避の一環として書かれております

"開発者体験が良い" とはどういうことか、あるいは例のランキングの使いかた

TL;DR

「例のランキング」と言われるようになってしまったエンジニアが選ぶ"開発者体験が良い"イメージのある企業ランキングですが、これをどう解釈すればいいか、企業側、採用側としてどう考えればいいかについて、自分なりの意見があるけどXの話とかであまり見ないので書いてみようと思った。

• 開発者体験とは、本質として「開発者個人の期待と現実のギャップ」である
• しかし開発者個人の期待というものは人によって千差万別だから、 "開発者体験が良い" は人によって求めるものが違いすぎているし、外部の人が評価できるものでもない
• ただし 「"開発者体験が良さそう"というイメージ」については、期待と現実のギャップをコントロールできているように外部に見えている、という指標として有用かもしれない

Disclosure

• 筆者はさくらインターネット株式会社で勤務しており、かつ、採用関連の活動にはこの1年弱のあいだ、それなり以上に関係しています。とはいえ何かを代表するような立場にいるわけではありません。
• さくらインターネットは前述企業ランキングにおいて、2024年まではランキング外でしたが、2025年に7位にランクインしました。
• 筆者本人はランキング作成の主体である日本CTO協会には関係していません。日本CTO協会の中の人に知り合いは多くいますが、誰がこのランキングの企画に関係しているかなどは全く知りません。

開発者体験とは何か

開発者体験とは何か、について、該当ランキングでも何をどのように計測しているかは割と詳細に記載がある*1。いっぽうで、そうはいっても開発者(ソフトウェアエンジニア)の人達にはそれぞれかなり強いイメージのある言葉でもある。

多くの人の最大公約数をとれば、おそらく「整って綺麗でモダンな設計のコードの上に、自分のロジックをストレスなく書けて、デプロイに苦労がない」みたいな内容になると思う。しかしこれを万人が求めているかというとそんなことはなくて、以下それぞれみたいな意見をもっている人だっていっぱいいるはずだという確信がある。

• 自分はデプロイに苦労はないとはいっても他人が人力でデプロイしてる、みたいなのは絶対にイヤだ、自動化されてなきゃ絶対にイヤだ
• デプロイは自動化されているがこの仕組みが気に入らない、自分が気に入る手法に直せないようでは体験が悪い
• そもそも開発プロセスの自動化とかは改善していけるなら大したことではない、きちんとしたビジネス課題とマトモな売上と優秀な同僚こそが開発者体験にとって最重要だ

どれが良い悪いという話ではなくて、人はいろいろな意見を持っていますね、という話でしかない。千差万別。このあたりの開発者個人の期待と現実との間でのギャップが大きければ、かつ改善もできないようであれば開発者体験が悪いとなるし、ギャップが小さいなら開発者体験が良いとなるんじゃないの、と自分は思っている。

この話自体はもちろん多くの人がわかっている。この話をベースにすると「開発者体験が良いかどうか」は本人に聞かなきゃわからないのは明らかで、だから「例のランキング」が対象企業の従業員ではなく、外部の人にアンケートした結果を用いて作成されていることに拒否感をもつ人が多いんだろうなと思う。

「"開発者体験が良さそう"というイメージ」とは何か

ところで「"良さそう"というイメージ」は何かというと、これは*2外から見えたイメージがどうなっているか、外部に向けたアピールがどう行われてどうした結果になっているか、というものでしかない。それに意味はないんですか?

外から中途入社してくる人がそれなり以上にいる状況で、もし入社した人の期待と現実との間にギャップが大きいと、もちろん間違いなく良くない結果を引き起こす。優秀な人はどうせ引く手あまたなんだから、入社後にちょっと違うなとなってしまったらすぐ他の会社に移ることだってできる。優秀な人を狙って採用すればするほどこのリスクは大きい。うひー怖い。世間の人だって、そんなことが続くようなら「あの会社には何かあるんだな」みたいな印象を持つだろう。

自分の意見としては、結局のところこれが「"開発者体験が良さそう"というイメージ」なんじゃないの? と思っている。あの会社に入社したら、その後も満足して働けそう、というふわっとしたイメージ。それを効率的に発信できているかどうか。そういうイメージをどの企業から受け取ったか。

ただし前に書いたとおり、開発者体験とは結局のところ個人の期待がどうだったかに大きく左右されるもので、かつ個人の期待は千差万別だ。どんな人を採用してもすべての人が「開発者体験が良かった」と評価する企業なんてものは存在しないと思っている。 だからこの「イメージ」を維持する・高めるために重要なものは、以下のものだと思う。このふたつがきちんとできているかどうかが「"開発者体験が良さそう"というイメージ」の形成に重要なんじゃないだろうか。

• 候補者に社内の実情を丁寧に伝え、それでも面白そうという「期待」を持ってもらうこと
• 入社した人がどのような「期待」を持っていたか、それと入社後の現実とのギャップがどうだったかをきちんと外部に発信すること

ところで上記の2点、普通に見て、採用プロセスにおいてものすごく重要なものだと思いませんか? もしこの2点をきちんとできているかを計測する指標がまがりなりにもあるなら、それを用いて現実の施策にフィードバックをかけるのは悪くないかもしれませんね?

この一年間のさくらインターネットのソフトウェアエンジニア採用

自分は2024年8月にさくらインターネットに入社した。入社エントリ自体はそれなりに読まれたが、反応としては正直「さくらインターネットって選択あるんだ?」みたいな、行き先としては分からなくもないが意外、という声がほとんどだったと思う。

入社して最初の数ヶ月いろいろ見た結果、まず思ったのが「さくらインターネットがソフトウェアエンジニアの転職先候補として全く見られていない」ということだった。クラウドの開発ではソフトウェアエンジニアを採用しなきゃ話が進まない、そのために社内制度や待遇の見直しもしている、しかしそれでも世間のソフトウェアエンジニアはさくらインターネットという企業があることを、転職のときに全く脳内にも置いていなさそうだった。他の何を置いても、これをどうにかしないと話にならない。

ということでやったことのひとつが、まず知り合いに直接話して誘うこと。いったん話を聞いてもらうことができたら、そこで実情をできるだけストレートに話すこと。色々な困難はある、すごくある*3、けれどもビジネスとして面白いし、また技術的にはユニークなことができること、などなど。これを面白いと思って入社してくれる人は思った以上にいた。そしておそらく、入社してからも期待と現実のギャップみたいなものは大きくなくて、(いや「負債とか聞いてたけど、思ってたよりだいぶだな????」はあるかもしれない)、それはつまり開発者体験はそう悪くないって状況をつくれているんじゃないかな、と思う*4。

やったことのもうひとつは、入社してくれた人のことをできるだけありのまま、かつできるだけスピーディに外部に向けて紹介すること。どういう人がどういう期待を持って入社してくれたかを多くの人に見てもらうこと。ソフトウェアエンジニアにとってさくらインターネットという選択肢が存在することを意識してもらうこと。おそらく多くの人が目にしているWelcome Talk 「ようこそ、さくらへ!」のインタビュー記事シリーズは自分がやるべきだと企画して、初期の進行から最初のインタビュアー、記事執筆まで自分でやったりした*5。

このあたりをやっていったところ、自分が入社したときにはまた意外なところに……みたいな反応だったのに、半年ちょっと経過した今年の春くらいには「またさくらか」「転職する人を見るとさくらだと思うように」みたいにまで言われるように。わお。やったぜ。

というのは自慢話じゃなくて*6、とにかく転職先として認知してもらわないといけなくて、そのためにやったことがうまく進行しているかは確認して実際の施策にフィードバックをかける必要がある。そのために使える指標ならなんでも使いたい、そういう現実の話です。

ところでまだまだ、足りないものはある

いま出している記事は採用へのフィードバックループをできるだけ早くかけたくて、入社後すぐにインタビュー収録、入社月のうちに記事公開、ということにしている。これは会社の認知をできるだけ早く高めるという目的にはとてもうまく働いたんだけど、じゃあ入社から数ヶ月、あるいは一年経過したときに、本当に入社前の期待と入社後の現実はうまくマッチしているんですか? ということをもっと発信していくべきだと思っている。自分が入社して11ヶ月だから、もうそろそろ真面目にこのへんをやっていくべきかもしれない。

また会社名あるいはサービス名の認知を高めること自体はうまくいっているが、じゃあ中の人たちは普段どのように仕事をしているんですが、何をどのように使って何を作っているんですか、という個々人の話がまだぜんぜん出ていっていないと思っている。ここは誰かが主導して記事化するよりも、それぞれの開発者がそれぞれにあちこちのミートアップやカンファレンスに出ていって話してくれるようになればいいんだけど、現状あまりうまくプッシュできていない。どうやっていこうかなあ。

まとめ

「"開発者体験が良さそう" というイメージ」のランキング、たぶん思ったほど馬鹿にしたもんじゃないですよ、ということを思ったので書いてみたくなったのでした。

ところでさくらインターネットではソフトウェアエンジニアをはじめ多数の職種で中途採用の募集中です！！！！

www.sakura.ad.jp

*1:この類のランキングにおいては珍しいことで、良いことだと思う

*2:これも言っている人がいるが

*3:スケジュールはある、長期サービスゆえの歴史的しがらみや技術的負債はいっぱいある、開発チームとしてもまだまだこれから、etc、etc

*4:もちろん直接紹介での入社以外の採用ルートにおいても、各エンジニアリングマネージャがこの実情の共有にものすごく熱心で、すばらしい状態にある

*5:最近は協力してくれる人も多いし社内でルーティン化してきてほとんど自分の手を離れた、ありがたい

*6:いやちょっとは自慢したい

RubyKaigi 2025 行ってきた＆しゃべってきた、その後

RubyKaigi 2025

愛媛県松山市で4月16〜18日にあったRubyKaigi 2025にスピーカーとして参加してきた。勤務先のさくらインターネットでのお仕事扱いです。主催のDrinkupもあったしね。

直前まで仕事がめちゃくちゃ立て込んでたのもあって準備が本当にギリギリで、そのせいで寝不足のままRubyKaigi weekに突入してしまい初日は体調が最悪だった、というのが今回の最大の反省点。会期中は飲むのをほどほどにしつつ体力の回復をはかって、3日目がいちばん元気、みたいな状況になってた。反省。

それにしてもRubyKaigiはいつものRubyKaigiで、あれこれトーク聞いたり人と話したり飲み歩いたり、じつに楽しかった。運営のみなさまには本当にありがとうと伝えたい。

しゃべった

今年もトークを採択してもらっていたので、話してきた。内容は現在開発中のNamespaceについて、というかNamespaceのデバッグについて。

speakerdeck.com

2024年に沖縄で話したときと機能的にはなにひとつ変わっていないNamespaceについて、この1年でいかにえんえんデバッグをしつづけていたか、という話をした。Namespaceの機能の話をちゃんとすると去年と全く同じ話になってしまうので、大丈夫かいなと思いつつそこは思い切って省いたんだけど、聴いてくれた人の反応はかなり良くてほっとした*1。Namespaceの実装がいかに大変かが感じられた、という意見を多く聞けたのでトークで狙ったところができたのかなと思う。いやあ、一年間遊んでいたわけじゃなくて苦労してたんですよ。

Namespaceの話

で、そもそもNamespaceの話をすると、デバッグの苦労話はもちろん色々あるんだけど、自分の開発ブランチを1年半ものあいだメンテしつづけるということにそもそも無理があるんだよね、ということを今回のトークの準備をしていて明確に意識した気がする。 それが言葉になったのがDay 0の夜、Asakura.rbとANDPADのイベントでMatzと話してたとき。

MatzとNamespaceどうよ? の会話をするの図

「やっぱrebaseつらいですよ、Shopify勢がなんか最適化するとことごとくこちらの変更とConflictするし」 「もうデフォルトでは無効にして早く入れちゃおうよ、それだったらどのくらいでできる?」 「うーん、特に難しいところはないと思うんで、順調にいけば1〜2週間くらいでできるんじゃないですかねえ」

確かにこんなことを言いましたよ。明確に覚えてる。まさかこの会話があんなことになるとは思わないよね……。

ということでRubyKaigi期間中はdefault disabledでいったんmergeしてもらうのを最速で達成する方向に切り替えてあれこれ作業してた。もしかしたら即座に動くのでは、みたいな甘い考えもあったけどあちこち手当て漏れがあって直したりしつつ、思ってたより時間かかるかなーと考えながら最終日までゆるゆると過ごしてた。 Ruby Committers and the Worldのセッションでも言及されて、なんかプロレス的に出てこいや! って壇上から煽られたｗ けど、Matzが必要なことをぱーっと言ってて加えることもなかったので客席で座り込んでた。あとはMatzのClosing Keynoteでもしかしたらちょっとは言及されるかなあ、くらい。

Closing KeynoteはAIの話をずっとしてて、わかるわかるって部分といくらなんでもRubyに我田引水ではって部分があって面白く聞きつつ過ごしてたら、One more thingで「Namespaceが入る、たぶん」って話があって、うおお、と思ったときの反応がこちら。

Namespaceが入ると聞いての反応がこちら

ここまでは割と楽しく気楽に過ごしてたんだけど、そしたら壇上でMatzがとつぜん言いだしたのがこちら。

「ZJITはもうすぐマージできそうなんですよね。Namespaceも来週か再来週には入るんじゃないかってことで、それでいい?」

キーノートスピーカーの言語設計者が壇上から圧をかけてくるとか、そんなことある?????????????????????????????????

え、これ何か俺が言うの? 何を? え? でも何かは言うのを期待されてる??? って混乱しつつ、でも思ったより時間かかりそうだと思ってたところなので来週か再来週って確約しちゃうのは絶対にマズい、みたいなことをぐるぐる考えて「ダメ!」ってとりあえず言ってみた。でもあまりに混乱してたので「ダ、ダメ!」みたいな感じになってた気がする……。

そのあと話す人みんなにネタにされてたので、はい、いい話題が提供できてよかったです。しかしなあ、ZJITみたいなフルタイム開発者がチームとしてやってる作業と並んで話題にされるのはなかなか厳しいですよ。

その後のはなし

とはいえですよ、なんもできないまま時間が過ぎちゃうのは嫌なんですよ当人としても。ということで、GWにだいぶ頑張った。

#rubykaigi の @yukihiro_matz のキーノート「来週とか再来週でいい?」から2週間 - 1日、とりあえずNamespace disabledで手元でテストが全部通る＆Namespace有効でもまあまあ動くようにしたのでpull-req作ったぞ!https://t.co/8V5dktrHgW

— tagomoris (@tagomoris) 2025å¹´5月1æ—¥

はい、「来週か再来週」になんとかしたぞ!

まあ細かい問題やらあれこれあって、3週間ちょっと経過の現在時点でまだマージされてないんだけど*2、やることはやってます。KaigiEffectだ! だいぶ特殊な気がするけど。

参加してた

RubyKaigiの話に戻る。体調が最悪だったのもあってあまり積極的な活動もできず、開発が頭にあってそう多くのトークも聞けずって感じだったのは心残り。聞いたトークの感想は省略しちゃうけど @ima1zumi さんのキーノートは本当に良かった。TRICKは相変わらずすべてがおかしかった。

会場内でささださん運営の本屋さんがあって、そこで2回ばかりサイン会に参加したりもしてた。おかげでWEB+DB PRESS総集編もだが、Fluentd実践入門も入荷分がぜんぶ売れていって有り難い限り。旅先の本屋の力はすごいな。楽しかった。

温泉

3日目はさすがにいろいろ限界がきてたので、お昼にちょっと中座して道後温泉本館でひと風呂浴びたりしてた。来年の会場も温泉地が近いはずなので楽しみ。

さくらインターネット

ソフトウェアエンジニア界隈で最近の採用が話題になってるだろうというのは自覚があったけど、あらゆるところで話題にされた。あとは「まさか @repeatedly に働く気があったとは!!!!!」とか。 さくらインターネットに興味が、という声を何度もかけてもらえて、これは本当にありがたい限り。

RubyKaigi 2025 Uchiage! by SAKURA internet

3日目の夜にはさくら主催でDrinkupもやった。懇親会的なものについては、人が大勢集まって色々な人と会話をストレスなくできる、というのが最大のポイントだと思っていて、そのように設計したところたいへんご好評をいただいたように思う。よかったよかった。

来年

来年は函館だ、楽しみ! ということで、おつかれさまでした。

*1:自分に直接反応を言ってくれる人が層として偏っている可能性は高い

*2:なおこの記事を書いたあとの5月11日夜にマージしました

さくらインターネット入社後3ヶ月のいまの話

さくらに入って3ヶ月経過して、入社直後といま現在ではまた見えている状況も違うし、実際どうなのっていうのを今の段階で書いておくのも悪くないかなと思った。自分より後に入ってきた人達が1ヶ月でのエントリを書いている(link)(link)のに触発されたというのもある。

入社直後のエントリはこちら。 tagomoris.hatenablog.com

思っていたより会社の変化が激しい

入社してから1ヶ月は、社内でこれまでクラウド開発・運用やガバメントクラウドをリードしてきた人達とひたすら話してキャッチアップ、みたいな感じで過ごしていた。で、なんとなく分かってきたかなと思ったのに、翌月から切れ目なく色んな人の入社が続いていて、いま自分がいるクラウド事業本部という組織がすごい勢いで変わってる。特にシニア層というかエンジニアリングマネージャ系の人達の入社が続いていて、これからどうするべきか、あちこちで議論が始まってる(いくつかは自分も始めている)。

これはどちらかというと、組織運営をやりかたに変化がほしい、という動機が先にあって、そのための採用がうまくいった結果がいま表れている、というのが正確な理解だと思う。自分としてもやりたいこと・こうなったらいいと思うことのうち、マネジメント系のことについては頼りになる同僚がどんどん増えているという状況なので嬉しい限り。

思っていたより状況がワイルド

ワイルドってなんだ、というと、なんだろう、スタートアップにありがちな未整備状態があちこちにあるというか、どこもかしこも成長の余地だらけというか……。歴史あるユーザ数の多いサービスをいくつも持っている会社なんだけど、内部を見てみると思ったよりも落ち着いてないなこれ、というか。

これは自分にとっては特にマイナスというわけでもない。特にビジネスが成長していると内部の整備が追い付かないというのは普通だと思う、というか、ビジネス成長速度が速い会社はそうなっていて当然とまで思っているフシが自分にある。前にいたライブドアもトレジャーデータも、特に入った直後はそんなもんと言えばそんなもんだった。そういう状況だとやり甲斐しかないというか、自分のやれることの余地がすごく大きいので割と好きだし、自分以外でもそういう状況が好きな人はまあまあいるんじゃないかと思う。

思っていたより周囲から注目がある

みんな結構ガバメントクラウドとか、あるいは国産クラウドについて思うところがあったんだなー、という感じで、入社後に会った人に応援の言葉をもらうことが多くて嬉しい。行政のデジタル化みたいなものを応援したい、という気持ちの一環みたいなところに国産クラウド応援がくっついているという場合もあって、これは入社前の自分を振り返ってみてもよくわかる気がする。

とはいえ、現状の機能などだと、AWSやGoogle Cloudをあたりまえに使っている各位の期待にすぐには応えられないので、この注目と期待があるうちに状況を前に進めていくぞ、ということで内心ちょっとシリアスな気分になることもある。

クラウドプロバイダの初心者プロダクト担当

プロダクト担当として何をやるべきか、みたいなことを考えながら、全体に影響があって時間がかかるいくつかの話はさっさと始めたりしている。クラウドサービスプロバイダにおけるプロダクト担当となるとエンジニアとしてのバックグラウンドがある方が有利に働くに決まってる、と入社前から考えていたところは見事に的中してると思うんだけど、いっぽうで各種の認証や規制、省庁のガイドライン、各業界の動向など知らないことも多くて内心悲鳴を上げがち。人生常にキャッチアップだな。ただ、自分が不得意なところを得意にしている超優秀な同僚もいて、これは本当に良い。勝手にあれこれ勉強させてもらってます。

入社エントリに「さくらのクラウド全体、あるいは広くさくらインターネットグループの中でやれることは何でもやるつもり」と書いたけど、本当にあれこれやってる。入社動機の大きなひとつ「エンジニアリングとビジネス両面を相手に仕事を」できていて楽しい一方で、コード書くのとは違ってなかなか即座には結果がわからないことばかりなので、本当にこれでいいんだっけ……みたいな不安におそわれたりもする。いやはや。

採用! 採用! 採用!

プロダクトまわりであれもやりたい、これもやりたいということが多く、しかし当然メンバーのほとんどは現行の開発プロジェクトで手いっぱい、という状況を見ると「採用! 採用しないと!!!」みたいな強烈な気分におそわれるので、採用まわりにもけっこう時間を割いてる。自分の知り合いのシニアエンジニアはみんなさくらに来ればいいのに……くらいに言いたい気分。転職考えてもいいかなって気分の人はいますぐ自分に連絡してください。

一度シニアになっちゃうとなかなか開発に集中できない、みたいな話も無くはないと思うんだけど、その点さくらについてはどんどん開発に集中してほしくて、そのためのポジション作りと待遇面の優遇はどちらもなかなか良い状況だと思う。だってクラウドのマネージドサービスを設計して作れる人なんて超貴重だもんね。もちろんプロジェクトをリードできる人だけでもなくて、プロジェクトのデザインと計画をきちんとフォローして開発を進められる人も大募集中です。データセンタの建物や電源みたいな超低レイヤから、完全ソフトウェアで構成された高レイヤのマネージドサービスまで、やることを超絶幅広い中から選べるのが特徴です!

あと、プロダクトまわりでもやることがいくらでもあるので、プロダクト担当のチームを立ち上げないといけないかなあとか、マネージドサービスがどんどん出ていくとSDK作らないといけないからDevRel職を置かないといけないんじゃないかとか、そういうことも最近考えてる。

コード書いてないと腹がへるの話

仕事でコードを書かない毎日にようやく慣れてきた。驚くことに入社後マジで1行もコードを書いていない*1。ちょっとした実証コードを書かないとなとは思っていて、それはまだ手が回ってないのが問題なんだけど……。

それはともかく、コード書かずにドキュメント書いてスライド書いて人と話してとやってると、コードを書いているときと較べて腹がへる、という恐るべき事実が自分に起きていることに気付いた。コード書いてるときは飴玉舐めるとかラムネ食べるとかでいかに脳に糖分を届けるかを考えてたのに、なんか最近それだけだと足りなくて、空腹を強烈に自覚するようになったんだよね。なんなんだこれ。エネルギーの消費のしかたが違うのかなあ。

脈絡のないmorisnite vol.5の話

で、脈絡ないですが、そのさくらインターネット東京支社を会場に使えるので、目的もなく集まって飲食するというイベント morisnite vol.5 をやります! 11月22日。

connpass.com

クラウドの話をしたければしてもいいし、したくなければ最近あのコードどうなのよって感じであれこれ楽しく話したいですね。どなたでもご参加ください。

*1:さくらの仕事としては。OSSは普通にやってる。

さくらインターネットに就職しました

TL;DR

• さくらインターネット株式会社で8/1から働いています
• さくらのクラウドの一人目のプロダクト担当ということで、エンジニアリングとビジネス両面を相手に仕事をしていきます
• ソフトウェアエンジニア大募集中です、いっしょに働こうぜ!

経緯

Treasure Dataを辞めたのが2021年7月末*1でしたが、それから丸3年経過しましたね。早いなあ。その間は本を書いたり個人サービスを作ったりしつつ、個人事業主の技術顧問として数社をお手伝いしたりしていましたが、個人的な事情がいくつか落ち着いたりしたこともあって、今年初めくらいからそろそろフルタイムで働くことを考えはじめ、多くの会社さんとのやりとりを経て、さくらインターネット株式会社への入社を決め、今月から入社し働きはじめました。

どういうポジションで何がしたいのかについては当初だいぶふらふらしていたのですが、いくらかの会話を経て「ビジネスを作る／育てる、そのためのチームを作る／育てる」というあたりを目標として動けるポジションで働くことを重視するようになりました。直近2つのキャリアも自分の対外イメージも、ICとしてのソフトウェアエンジニアとしてかなり強いものがあったようで、声をかけていただいてもミスマッチですね、となることも多かったところ、それでも是非といってくださる会社さんもあったのは本当に自分にとっては嬉しかったですね。

他にもチャレンジしているビジネスが本当にすばらしい・有望そうなスタートアップのポジションなどでもだいぶ悩んだのですが、会社のビジネスの状況、オファーされたポジション、待遇、などぜんぶひっくるめて考えて、さくらインターネットで働くことにしました。各社との話の中で何をやりたいかが明確になっていったのは全く否定のしようもなく、声をかけていただいた方々、選考プロセスでお世話になった方々には本当にお世話になりました。この場でになりますが、報告とお礼に替えさせていただければと思います。

さくらインターネット、さくらのクラウド

さくらインターネットという会社は、パブリッククラウドをやるぞという強い意思と、直近でも旺盛な投資意欲があるという意味では国内随一のクラウドサービスプロバイダであると自分は見ています。もちろん現時点でAWS、Google Cloud、Azureといったハイパースケーラ各社には及ぶべくもありませんが、それでも国内では現時点である程度以上のポジションを持っています。その上で、これからガバメントクラウドの正式認定*2を目指す、GPUを大量導入して国内AI基盤としての地位を確立する、といった大きな動きも既に見えています。

このタイミングで一人目のプロダクト担当としてさくらのクラウド全体に関われるというのはタイミング的に非常においしいと思いますし、またクラウドサービスのプロダクトマネジメントという領域がエンジニアとして積んだ経験を存分に活かせそうだという考えもあります。プロダクトマネージャのチームを作るぞという流れになれば、その立ち上げにも関わるでしょう。いやあ、楽しみだなあ。

もうひとつ重要な点として、非常に良い待遇で迎えていただいたのも関係しますが、投資の増大とそれに繋がるソフトウェアエンジニアの採用拡大を強く志向しているのも大きいですね。これから数多くの良いエンジニアの人達と同僚になれる可能性があります。すばらしい。自分が傾向としてスタートアップが好きなのはこの点がかなり大きいのですが、上場企業でも状況によってはこの利点が得られるんだなと思っています。

プロダクト担当

エンジニアリングのみに集中するよりもビジネスとの関わりも求めたい、ということを考えている自分にとってすばらしいポジションですが、一方でさくらインターネットという会社にどういうプロダクトマネジメントが必要なのかは全く明らかではないので、それを模索するところからの始まりになっています。これはもう、本当にわからないので、あらゆる関係者と話しながらやっていくしかないという状況ですね。

一方でプロダクトマネジメントしかやらないぞというつもりも無いので、さくらのクラウド全体、あるいは広くさくらインターネットグループの中でやれることは何でもやるつもりです。どういうことができるでしょうね。ただし、プログラミングやるという機会は確実に少ないと思います。これはもう、そういうものだろうなと最初から思っています*3。

FAQ

技術顧問は辞めたの?

稼動時間数をかなり縮小していますが、まだ複数社と契約は継続しています。これを受け入れるさぶりこキャリアという枠組みがあります。これからも技術顧問業を拡大することはそう無いと思いますが、一方で技術顧問業をやって得られる知識・経験は本業にも大いに役立つので、完全に辞めることはないかなと思っています。

さくらインターネットって誰がいるの?

専門によって誰に目をつけるかは異なるでしょうが、自分にとっては特に、今回誘っていただいた当人でもある@kazeburoさんがいるのは大きいですね。しかも伊勢さんもいるので、ISUCONを始めたときの当事者4人のうち3人が揃いました。すごいぞ。*4

他にも前々からのコミュニティでの知り合いも多いですね。彼らと一緒に働けるのが超楽しみです。

どこで働くの?

完全リモートなので自宅です。続けて東京都内に住んでおります。

入ってみて何がいちばん印象に残った?

社用メールアドレスのドメインが .ad.jp だったことですかねー。すごいぞ。

まとめ

ということで、今後ともtagomorisをよろしくお願いします。あと新卒・経験者問わず絶賛採用中なので、興味のある方はぜひお願いします。採用窓口への応募(すばらしい!)でも、さくらってどうなの? みたいな連絡を自分個人にいただくのでも歓迎します。みんなでパブリッククラウド作ろうぜ!

www.sakura.ad.jp

*1:5月末にエントリを書きましたが、休暇の消化で書類上の在籍は7月末まででした

*2:現時点では2025年末までに技術要件を満たすことを前提とした条件付き認定

*3:それでいいの? と言われると、一方でプライベートでRubyへの巨大なパッチを書いていたりするので、個人としては何も不満はないという状況です

*4:もう一人の@941さんは最近カケハシさんに転職されましたね

RubyKaigi 2024に行ってきた＆しゃべってきた

沖縄、那覇で行われたRubyKaigi 2024に参加してきた。いやあ、もう、最高でしたね。

(Photo by @hsbt -san)

しゃべってきた

"Namespace, What and Why" というタイトルで話してきた。

speakerdeck.com

これはいまRubyに提案している"Namespace on read"というものについての紹介で、本当は実装面とかも細々ひたすら語りたかったんだけど、なにしろこれまでのRubyに全くなかったパラダイムと機能なので、デモやユースケースの紹介、これからどうなるか、みたいな解説を中心にせざるをえなかったかな、というのはある。けど、そうしただけあって、聞いてくれた人達にはかなりインパクトを与えられた、んじゃないかなあ、少なくともKaigi中にいろんな人から感想を聞く限りは……。

実装はまだ完成していなくて、自分のトークが15日(水曜)だったんだけど、直前の金曜にようやくデモ用のスクリプトが動くようになった始末。それでもGCの関係で1/10くらいの確率でSEGVする状態なんだけど、直そうとして動いてるビルドを壊したら悲惨だった*1ので、まあこの確率なら本番でSEGV引かないだろ、と思って強行したら見事にSEGV引いて拍手喝采をもらってしまった。マジウケる。リトライしたときはちゃんと動いたので2連発引かなくてよかった。

Namespaceについて、あるいは今後どうなるみたいな話についていろいろ質問ももらったので、それについてはFAQを作ってみた。疑問などがある方はまずこのFAQをどうぞ。

"Namespace on read" for Ruby, FAQ · GitHub

ところでその後のMatzのキーノート

こんな言葉が最後の最後に出てくる? マジで? って、もうなんかよくわからん感じになって一人で感極まってた。もうだめっていう。頑張るぞ!

Matzキーノート後に感極まって動けないところを激写されるの図

(Photo by @emorima -san)

参加してきた

今回はとにかく色んな人にNamespaceどう思った? って感想を聞いて回ってあれこれ話すのが目標で、他の人のトークも聞いて回ったけどとにかく自分のがな、っていうRubyKaigiだった。これはもうしょうがないじゃん?

しかし@tompng(ぺん)さんのキーノートが本当にもう、Self TRICKってなんだよとしか言いようがないことをやりながら他の人のトークのネタを織り込むとかどういうことだよって感じですね。やってることのバリエーションもすごすぎるし、本当にユニークとしか言いようがない、めちゃくちゃに凄い人だよなあって再確認してましたね。

他のトークについては、自分がCRubyの中身に手を入れるようになったから、やっぱり内部の改善について理解の解像度が高まったなと思うところはある。@tenderloveさんの赤黒木の話なんかも、Object Shapeについての理解が進んでたのでつっかえずに聞けてた気がするし。 あとパーサについては、自分はもう最初から宣言的文法定義最高! 派で、かつちょっと今パーサ軍団に加わる余力はない……って感じだったので本当に気になったところだけつまんだけど、何人ものチームでどんどん前に進めててすごいなあ、いいなあって感じ。Namespaceももうちょっと前に進めて、その状態に至りたいもんだと思う。あとLTのときの金子さんの悪そうな顔が本当に最高だった。あのLTの完成度はすごい。

懇親会などなど、あれこれ書きたいことも多いけど、今回は省略。

このあと

RubyKaigi 2024 事後勉強会というイベントでLTの機会をもらったので、RubyKaigi 2023から2024までの1年間についてざっと振り返る内容を話そうかなと思った。興味のある方はぜひどうぞ。これはもうね、エモいやつです。5月31日。

smarthr.connpass.com

またNamespace on readはRubyアソシエーションの開発助成事業というものの対象プロジェクトに選ばれていたんだけど、その結果報告イベントがあって、そこでプロジェクトの経緯や内容について話します。Namespace on readの設計や実装をどう進めたかなど、RubyKaigiよりもうちょっと詳細に触れられるんじゃないか*2と思っているので、こちらも興味のある方はぜひどうぞ。7月19日。

www.ruby.or.jp

*1:あとRubyKaigi直前は家族旅行にあてていて、スライドもできてなかったから時間もなかった

*2:逆にNamespaceそのものの話はこっち見て、でけっこう済ませちゃうつもり

AWS LambdaのRuby .zipパッケージでgitから取得したgemを使う

AWS LambdaでRubyランタイムを使っててzipアーカイブで関数コードをアップロードしてる人向け。

基本的にはGemfileに依存関係書いてbundle config set --local path 'vendor/bundle'してbundle installすればいい。以下のドキュメントを読もう。

docs.aws.amazon.com

んだけど、Gemfileにrubygems.org以外から取得したgem、特にgitを指定したものを使っている場合にこれだけだとうまくいかないので、原因と対処を書いておく。

そもそもLambdaは何をやってるか

上述ドキュメントを読むとわかるが、zipファイルにはGemfile.lockã‚‚Gemfileも入れない。それで動作する。これはどういうことかというと、AWS Lambdaのランタイム側ではBundlerを使わず(?)、vendor/bundle 以下にLambdaが想定しているパスで置かれているファイルを直接探索するように$LOAD_PATHが指定されてるんじゃないかと思う。*1

で、通常rubygems.orgから取得したgemについては vendor/bundle/ruby/3.2.0/gems/ 以下にmyclient-1.1.0みたいなディレクトリでコード等が展開される。またvendor/bundle/ruby/3.2.0/specifications/ ディレクトリにgemspecファイルがmyclient-1.1.0.gemspecとして置かれる。試してみていた範囲では、gemspecを検出したらそれに対応するgemのディレクトリを$LOAD_PATHに追加してるんじゃないかと思う。

gitから取得したgemの扱い

gitから取得したgemについてはBundlerはrubygems.orgからのものとは異なり、vendor/bundle/ruby/3.2.0/bundler/gems/以下にmyclient-xxxxxxxのようなディレクトリで展開される。xxxxxの部分はcommit hash。

これはLambdaランタイムが読み込むディレクトリと異なっているため、zipファイルに含まれていても実行時にロードパスが通らず、requireしてもエラーになる。なんということでしょう。

無理矢理パスを通す

しょうがないので、以下のようにしてzipアーカイブを作れば動くようになる。

1. ruby/3.2.0/gems以下にシンボリックリンクを作成する

bundle installしてgitから取得したgemが展開されたら、そのディレクトリに対して以下のようにシンボリックリンクを作る。

$ ln -s vendor/bundle/ruby/3.2.0/bundler/gems/myclient-xxxxxx vendor/bundle/ruby/3.2.0/gems/myclient-1.1.0

こうすれば手元で実行するときにも壊れない。zipアーカイブを作るときは*2シンボリックリンクだった部分はそこにコピーされたようになるはず。つまり、Lambda環境ではruby/3.2.0/gems以下に該当gemのコピーが展開される。

2. specifications以下にgemspecをコピーする

gemspecがないと動かないのでこれもオリジナルの場所からコピーする。コピー時にバージョン番号をつけたファイルにするのに注意。

$ cp vendor/bundle/ruby/3.2.0/bundler/gems/myclient-xxxxx/myclient.gemspec vendor/bundle/ruby/3.2.0/specifications/myclient-1.1.0.gemspec

(余談) pathで指定したgemはどうなる?

Gemfileではgitで指定する他にもpathでローカルパスにあるgemを使うよう指定できる。開発中のgemを直接使うときに便利。

が、この指定だとBundlerは該当パスを直接見に行ってライブラリをロードし、vendor/bundle以下にはコピーを作らない。このため、zipアーカイブにしようとしても入ってくれず、Lambdaランタイム上では使いようがないということになる。

ローカルストレージ上のものをコピーしてzipアーカイブに入れてもいいけど、何が起きるかちょっとわからないのが怖い気もするので、開発中とはいえgitリポジトリ経由で入れるようにしたほうがいいかなと思います。

*1:書きながら思ったけど実行環境にBundlerがロードされているかどうかはちょっとコード書けばするわかるな……やるのがめんどくさい

*2:おそらく大多数の環境では