"開発者体験が良い" とはどういうことか、あるいは例のランキングの使いかた
TL;DR
「例のランキング」と言われるようになってしまったエンジニアが選ぶ"開発者体験が良い"イメージのある企業ランキングですが、これをどう解釈すればいいか、企業側、採用側としてどう考えればいいかについて、自分なりの意見があるけどXの話とかであまり見ないので書いてみようと思った。
- 開発者体験とは、本質として「開発者個人の期待と現実のギャップ」である
- しかし開発者個人の期待というものは人によって千差万別だから、 "開発者体験が良い" は人によって求めるものが違いすぎているし、外部の人が評価できるものでもない
- ただし 「"開発者体験が良さそう"というイメージ」については、期待と現実のギャップをコントロールできているように外部に見えている、という指標として有用かもしれない
Disclosure
- 筆者はさくらインターネット株式会社で勤務しており、かつ、採用関連の活動にはこの1年弱のあいだ、それなり以上に関係しています。とはいえ何かを代表するような立場にいるわけではありません。
- さくらインターネットは前述企業ランキングにおいて、2024年まではランキング外でしたが、2025年に7位にランクインしました。
- 筆者本人はランキング作成の主体である日本CTO協会には関係していません。日本CTO協会の中の人に知り合いは多くいますが、誰がこのランキングの企画に関係しているかなどは全く知りません。
開発者体験とは何か
開発者体験とは何か、について、該当ランキングでも何をどのように計測しているかは割と詳細に記載がある*1。いっぽうで、そうはいっても開発者(ソフトウェアエンジニア)の人達にはそれぞれかなり強いイメージのある言葉でもある。
多くの人の最大公約数をとれば、おそらく「整って綺麗でモダンな設計のコードの上に、自分のロジックをストレスなく書けて、デプロイに苦労がない」みたいな内容になると思う。しかしこれを万人が求めているかというとそんなことはなくて、以下それぞれみたいな意見をもっている人だっていっぱいいるはずだという確信がある。
- 自分はデプロイに苦労はないとはいっても他人が人力でデプロイしてる、みたいなのは絶対にイヤだ、自動化されてなきゃ絶対にイヤだ
- デプロイは自動化されているがこの仕組みが気に入らない、自分が気に入る手法に直せないようでは体験が悪い
- そもそも開発プロセスの自動化とかは改善していけるなら大したことではない、きちんとしたビジネス課題とマトモな売上と優秀な同僚こそが開発者体験にとって最重要だ
どれが良い悪いという話ではなくて、人はいろいろな意見を持っていますね、という話でしかない。千差万別。このあたりの開発者個人の期待と現実との間でのギャップが大きければ、かつ改善もできないようであれば開発者体験が悪いとなるし、ギャップが小さいなら開発者体験が良いとなるんじゃないの、と自分は思っている。
この話自体はもちろん多くの人がわかっている。この話をベースにすると「開発者体験が良いかどうか」は本人に聞かなきゃわからないのは明らかで、だから「例のランキング」が対象企業の従業員ではなく、外部の人にアンケートした結果を用いて作成されていることに拒否感をもつ人が多いんだろうなと思う。
「"開発者体験が良さそう"というイメージ」とは何か
ところで「"良さそう"というイメージ」は何かというと、これは*2外から見えたイメージがどうなっているか、外部に向けたアピールがどう行われてどうした結果になっているか、というものでしかない。それに意味はないんですか?
外から中途入社してくる人がそれなり以上にいる状況で、もし入社した人の期待と現実との間にギャップが大きいと、もちろん間違いなく良くない結果を引き起こす。優秀な人はどうせ引く手あまたなんだから、入社後にちょっと違うなとなってしまったらすぐ他の会社に移ることだってできる。優秀な人を狙って採用すればするほどこのリスクは大きい。うひー怖い。世間の人だって、そんなことが続くようなら「あの会社には何かあるんだな」みたいな印象を持つだろう。
自分の意見としては、結局のところこれが「"開発者体験が良さそう"というイメージ」なんじゃないの? と思っている。あの会社に入社したら、その後も満足して働けそう、というふわっとしたイメージ。それを効率的に発信できているかどうか。そういうイメージをどの企業から受け取ったか。
ただし前に書いたとおり、開発者体験とは結局のところ個人の期待がどうだったかに大きく左右されるもので、かつ個人の期待は千差万別だ。どんな人を採用してもすべての人が「開発者体験が良かった」と評価する企業なんてものは存在しないと思っている。 だからこの「イメージ」を維持する・高めるために重要なものは、以下のものだと思う。このふたつがきちんとできているかどうかが「"開発者体験が良さそう"というイメージ」の形成に重要なんじゃないだろうか。
- 候補者に社内の実情を丁寧に伝え、それでも面白そうという「期待」を持ってもらうこと
- 入社した人がどのような「期待」を持っていたか、それと入社後の現実とのギャップがどうだったかをきちんと外部に発信すること
ところで上記の2点、普通に見て、採用プロセスにおいてものすごく重要なものだと思いませんか? もしこの2点をきちんとできているかを計測する指標がまがりなりにもあるなら、それを用いて現実の施策にフィードバックをかけるのは悪くないかもしれませんね?
この一年間のさくらインターネットのソフトウェアエンジニア採用
自分は2024年8月にさくらインターネットに入社した。入社エントリ自体はそれなりに読まれたが、反応としては正直「さくらインターネットって選択あるんだ?」みたいな、行き先としては分からなくもないが意外、という声がほとんどだったと思う。
入社して最初の数ヶ月いろいろ見た結果、まず思ったのが「さくらインターネットがソフトウェアエンジニアの転職先候補として全く見られていない」ということだった。クラウドの開発ではソフトウェアエンジニアを採用しなきゃ話が進まない、そのために社内制度や待遇の見直しもしている、しかしそれでも世間のソフトウェアエンジニアはさくらインターネットという企業があることを、転職のときに全く脳内にも置いていなさそうだった。他の何を置いても、これをどうにかしないと話にならない。
ということでやったことのひとつが、まず知り合いに直接話して誘うこと。いったん話を聞いてもらうことができたら、そこで実情をできるだけストレートに話すこと。色々な困難はある、すごくある*3、けれどもビジネスとして面白いし、また技術的にはユニークなことができること、などなど。これを面白いと思って入社してくれる人は思った以上にいた。そしておそらく、入社してからも期待と現実のギャップみたいなものは大きくなくて、(いや「負債とか聞いてたけど、思ってたよりだいぶだな????」はあるかもしれない)、それはつまり開発者体験はそう悪くないって状況をつくれているんじゃないかな、と思う*4。
やったことのもうひとつは、入社してくれた人のことをできるだけありのまま、かつできるだけスピーディに外部に向けて紹介すること。どういう人がどういう期待を持って入社してくれたかを多くの人に見てもらうこと。ソフトウェアエンジニアにとってさくらインターネットという選択肢が存在することを意識してもらうこと。おそらく多くの人が目にしているWelcome Talk 「ようこそ、さくらへ!」のインタビュー記事シリーズは自分がやるべきだと企画して、初期の進行から最初のインタビュアー、記事執筆まで自分でやったりした*5。
このあたりをやっていったところ、自分が入社したときにはまた意外なところに……みたいな反応だったのに、半年ちょっと経過した今年の春くらいには「またさくらか」「転職する人を見るとさくらだと思うように」みたいにまで言われるように。わお。やったぜ。
というのは自慢話じゃなくて*6、とにかく転職先として認知してもらわないといけなくて、そのためにやったことがうまく進行しているかは確認して実際の施策にフィードバックをかける必要がある。そのために使える指標ならなんでも使いたい、そういう現実の話です。
ところでまだまだ、足りないものはある
いま出している記事は採用へのフィードバックループをできるだけ早くかけたくて、入社後すぐにインタビュー収録、入社月のうちに記事公開、ということにしている。これは会社の認知をできるだけ早く高めるという目的にはとてもうまく働いたんだけど、じゃあ入社から数ヶ月、あるいは一年経過したときに、本当に入社前の期待と入社後の現実はうまくマッチしているんですか? ということをもっと発信していくべきだと思っている。自分が入社して11ヶ月だから、もうそろそろ真面目にこのへんをやっていくべきかもしれない。
また会社名あるいはサービス名の認知を高めること自体はうまくいっているが、じゃあ中の人たちは普段どのように仕事をしているんですが、何をどのように使って何を作っているんですか、という個々人の話がまだぜんぜん出ていっていないと思っている。ここは誰かが主導して記事化するよりも、それぞれの開発者がそれぞれにあちこちのミートアップやカンファレンスに出ていって話してくれるようになればいいんだけど、現状あまりうまくプッシュできていない。どうやっていこうかなあ。
まとめ
「"開発者体験が良さそう" というイメージ」のランキング、たぶん思ったほど馬鹿にしたもんじゃないですよ、ということを思ったので書いてみたくなったのでした。
ところでさくらインターネットではソフトウェアエンジニアをはじめ多数の職種で中途採用の募集中です！！！！
RubyKaigi 2025 行ってきた＆しゃべってきた、その後
RubyKaigi 2025
愛媛県松山市で4月16〜18日にあったRubyKaigi 2025にスピーカーとして参加してきた。勤務先のさくらインターネットでのお仕事扱いです。主催のDrinkupもあったしね。
直前まで仕事がめちゃくちゃ立て込んでたのもあって準備が本当にギリギリで、そのせいで寝不足のままRubyKaigi weekに突入してしまい初日は体調が最悪だった、というのが今回の最大の反省点。会期中は飲むのをほどほどにしつつ体力の回復をはかって、3日目がいちばん元気、みたいな状況になってた。反省。
それにしてもRubyKaigiはいつものRubyKaigiで、あれこれトーク聞いたり人と話したり飲み歩いたり、じつに楽しかった。運営のみなさまには本当にありがとうと伝えたい。
しゃべった
今年もトークを採択してもらっていたので、話してきた。内容は現在開発中のNamespaceについて、というかNamespaceのデバッグについて。
2024年に沖縄で話したときと機能的にはなにひとつ変わっていないNamespaceについて、この1年でいかにえんえんデバッグをしつづけていたか、という話をした。Namespaceの機能の話をちゃんとすると去年と全く同じ話になってしまうので、大丈夫かいなと思いつつそこは思い切って省いたんだけど、聴いてくれた人の反応はかなり良くてほっとした*1。Namespaceの実装がいかに大変かが感じられた、という意見を多く聞けたのでトークで狙ったところができたのかなと思う。いやあ、一年間遊んでいたわけじゃなくて苦労してたんですよ。
Namespaceの話
で、そもそもNamespaceの話をすると、デバッグの苦労話はもちろん色々あるんだけど、自分の開発ブランチを1年半ものあいだメンテしつづけるということにそもそも無理があるんだよね、ということを今回のトークの準備をしていて明確に意識した気がする。 それが言葉になったのがDay 0の夜、Asakura.rbとANDPADのイベントでMatzと話してたとき。
「やっぱ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が入る、たぶん」って話があって、うおお、と思ったときの反応がこちら。
ここまでは割と楽しく気楽に過ごしてたんだけど、そしたら壇上で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 に働く気があったとは!!!!!」とか。 さくらインターネットに興味が、という声を何度もかけてもらえて、これは本当にありがたい限り。
3日目の夜にはさくら主催でDrinkupもやった。懇親会的なものについては、人が大勢集まって色々な人と会話をストレスなくできる、というのが最大のポイントだと思っていて、そのように設計したところたいへんご好評をいただいたように思う。よかったよかった。
来年
来年は函館だ、楽しみ! ということで、おつかれさまでした。
さくらインターネット入社後3ヶ月のいまの話
さくらに入って3ヶ月経過して、入社直後といま現在ではまた見えている状況も違うし、実際どうなのっていうのを今の段階で書いておくのも悪くないかなと思った。自分より後に入ってきた人達が1ヶ月でのエントリを書いている(link)(link)のに触発されたというのもある。
入社直後のエントリはこちら。 tagomoris.hatenablog.com
思っていたより会社の変化が激しい
入社してから1ヶ月は、社内でこれまでクラウド開発・運用やガバメントクラウドをリードしてきた人達とひたすら話してキャッチアップ、みたいな感じで過ごしていた。で、なんとなく分かってきたかなと思ったのに、翌月から切れ目なく色んな人の入社が続いていて、いま自分がいるクラウド事業本部という組織がすごい勢いで変わってる。特にシニア層というかエンジニアリングマネージャ系の人達の入社が続いていて、これからどうするべきか、あちこちで議論が始まってる(いくつかは自分も始めている)。
これはどちらかというと、組織運営をやりかたに変化がほしい、という動機が先にあって、そのための採用がうまくいった結果がいま表れている、というのが正確な理解だと思う。自分としてもやりたいこと・こうなったらいいと思うことのうち、マネジメント系のことについては頼りになる同僚がどんどん増えているという状況なので嬉しい限り。
思っていたより状況がワイルド
ワイルドってなんだ、というと、なんだろう、スタートアップにありがちな未整備状態があちこちにあるというか、どこもかしこも成長の余地だらけというか……。歴史あるユーザ数の多いサービスをいくつも持っている会社なんだけど、内部を見てみると思ったよりも落ち着いてないなこれ、というか。
これは自分にとっては特にマイナスというわけでもない。特にビジネスが成長していると内部の整備が追い付かないというのは普通だと思う、というか、ビジネス成長速度が速い会社はそうなっていて当然とまで思っているフシが自分にある。前にいたライブドアもトレジャーデータも、特に入った直後はそんなもんと言えばそんなもんだった。そういう状況だとやり甲斐しかないというか、自分のやれることの余地がすごく大きいので割と好きだし、自分以外でもそういう状況が好きな人はまあまあいるんじゃないかと思う。
思っていたより周囲から注目がある
みんな結構ガバメントクラウドとか、あるいは国産クラウドについて思うところがあったんだなー、という感じで、入社後に会った人に応援の言葉をもらうことが多くて嬉しい。行政のデジタル化みたいなものを応援したい、という気持ちの一環みたいなところに国産クラウド応援がくっついているという場合もあって、これは入社前の自分を振り返ってみてもよくわかる気がする。
とはいえ、現状の機能などだと、AWSやGoogle Cloudをあたりまえに使っている各位の期待にすぐには応えられないので、この注目と期待があるうちに状況を前に進めていくぞ、ということで内心ちょっとシリアスな気分になることもある。
クラウドプロバイダの初心者プロダクト担当
プロダクト担当として何をやるべきか、みたいなことを考えながら、全体に影響があって時間がかかるいくつかの話はさっさと始めたりしている。クラウドサービスプロバイダにおけるプロダクト担当となるとエンジニアとしてのバックグラウンドがある方が有利に働くに決まってる、と入社前から考えていたところは見事に的中してると思うんだけど、いっぽうで各種の認証や規制、省庁のガイドライン、各業界の動向など知らないことも多くて内心悲鳴を上げがち。人生常にキャッチアップだな。ただ、自分が不得意なところを得意にしている超優秀な同僚もいて、これは本当に良い。勝手にあれこれ勉強させてもらってます。
入社エントリに「さくらのクラウド全体、あるいは広くさくらインターネットグループの中でやれることは何でもやるつもり」と書いたけど、本当にあれこれやってる。入社動機の大きなひとつ「エンジニアリングとビジネス両面を相手に仕事を」できていて楽しい一方で、コード書くのとは違ってなかなか即座には結果がわからないことばかりなので、本当にこれでいいんだっけ……みたいな不安におそわれたりもする。いやはや。
採用! 採用! 採用!
プロダクトまわりであれもやりたい、これもやりたいということが多く、しかし当然メンバーのほとんどは現行の開発プロジェクトで手いっぱい、という状況を見ると「採用! 採用しないと!!!」みたいな強烈な気分におそわれるので、採用まわりにもけっこう時間を割いてる。自分の知り合いのシニアエンジニアはみんなさくらに来ればいいのに……くらいに言いたい気分。転職考えてもいいかなって気分の人はいますぐ自分に連絡してください。
一度シニアになっちゃうとなかなか開発に集中できない、みたいな話も無くはないと思うんだけど、その点さくらについてはどんどん開発に集中してほしくて、そのためのポジション作りと待遇面の優遇はどちらもなかなか良い状況だと思う。だってクラウドのマネージドサービスを設計して作れる人なんて超貴重だもんね。もちろんプロジェクトをリードできる人だけでもなくて、プロジェクトのデザインと計画をきちんとフォローして開発を進められる人も大募集中です。データセンタの建物や電源みたいな超低レイヤから、完全ソフトウェアで構成された高レイヤのマネージドサービスまで、やることを超絶幅広い中から選べるのが特徴です!
あと、プロダクトまわりでもやることがいくらでもあるので、プロダクト担当のチームを立ち上げないといけないかなあとか、マネージドサービスがどんどん出ていくとSDK作らないといけないからDevRel職を置かないといけないんじゃないかとか、そういうことも最近考えてる。
コード書いてないと腹がへるの話
仕事でコードを書かない毎日にようやく慣れてきた。驚くことに入社後マジで1行もコードを書いていない*1。ちょっとした実証コードを書かないとなとは思っていて、それはまだ手が回ってないのが問題なんだけど……。
それはともかく、コード書かずにドキュメント書いてスライド書いて人と話してとやってると、コードを書いているときと較べて腹がへる、という恐るべき事実が自分に起きていることに気付いた。コード書いてるときは飴玉舐めるとかラムネ食べるとかでいかに脳に糖分を届けるかを考えてたのに、なんか最近それだけだと足りなくて、空腹を強烈に自覚するようになったんだよね。なんなんだこれ。エネルギーの消費のしかたが違うのかなあ。
脈絡のないmorisnite vol.5の話
で、脈絡ないですが、そのさくらインターネット東京支社を会場に使えるので、目的もなく集まって飲食するというイベント morisnite vol.5 をやります! 11月22日。
クラウドの話をしたければしてもいいし、したくなければ最近あのコードどうなのよって感じであれこれ楽しく話したいですね。どなたでもご参加ください。
さくらインターネットに就職しました
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をよろしくお願いします。あと新卒・経験者問わず絶賛採用中なので、興味のある方はぜひお願いします。採用窓口への応募(すばらしい!)でも、さくらってどうなの? みたいな連絡を自分個人にいただくのでも歓迎します。みんなでパブリッククラウド作ろうぜ!
RubyKaigi 2024に行ってきた＆しゃべってきた
沖縄、那覇で行われたRubyKaigi 2024に参加してきた。いやあ、もう、最高でしたね。
(Photo by @hsbt -san)
しゃべってきた
"Namespace, What and Why" というタイトルで話してきた。
これはいま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のキーノート
こんな言葉が最後の最後に出てくる? マジで? って、もうなんかよくわからん感じになって一人で感極まってた。もうだめっていう。頑張るぞ!
(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日。
またNamespace on readはRubyアソシエーションの開発助成事業というものの対象プロジェクトに選ばれていたんだけど、その結果報告イベントがあって、そこでプロジェクトの経緯や内容について話します。Namespace on readの設計や実装をどう進めたかなど、RubyKaigiよりもうちょっと詳細に触れられるんじゃないか*2と思っているので、こちらも興味のある方はぜひどうぞ。7月19日。
AWS LambdaのRuby .zipパッケージでgitから取得したgemを使う
AWS LambdaでRubyランタイムを使っててzipアーカイブで関数コードをアップロードしてる人向け。
基本的にはGemfileに依存関係書いてbundle config set --local path 'vendor/bundle'してbundle installすればいい。以下のドキュメントを読もう。
んだけど、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リポジトリ経由で入れるようにしたほうがいいかなと思います。
PathtraqというLifeLogサービスを作った
最近何をやっていたかというと、タイトルの通り、Pathtraqというサービス、iPhoneアプリを作っていた。どんなサービスかと聞かれるとLifeLogというのが一番適切だと思うけど、LifeLogにも種類があって、これは位置情報を記録して検索するサービスになる。
どういうためのものかというと、普段生活したりどこかに行ったりして、以下のようなことが気になる方向けです。
- この場所/店/街、最後に来たのいつだっけ?
- 前に飲みにいってふらっと入ったあの店、どこにあった何ていう店だっけ?
- 前にあそこからあっちに移動したとき、どのくらい時間かかったっけ?
なんかさあ、この程度のこと、全部記録とってあれば簡単にわかるはずなんだけど、いまいちそうなってない*1。いいかげん解決されてくれよ、2023年だぞ! という気分で作った。
このアプリは基本的にバックグラウンドで動作して、自分がどこにいたのかを、24時間・365日記録する。もちろん記録するだけじゃ役に立たないので、時間を指定していつからいつまでの間にどこからどこまでどのように移動したかを表示できるし、場所(エリア)を指定して、その範囲のログはいつ記録されたのか、つまりある場所に行ったのはいつだったかを検索できる。あれこれチューニング頑張ったので、同様の機能*2に較べて高精度のログが、バッテリー負荷低くとれているはず。
あとはお決まりのチェックイン。人間は行った場所にチェックインしたい。自分もしたい。あと写真もつけたかったのでつけられるようにした。あまり大量につけられると良からぬことに使われるから、いちおういまは4枚までだけど。
OGP画像生成なんかも頑張ったのでFacebookやXやThreadsにリンクすると格好よく展開される! はず!*3
データはサーバサイドに送って保存してます。写真やチェックイン情報も。いつどこにいたかの情報は、もちろんユーザのもので、必要なときはアーカイブダウンロードできます。やったね。
ということで、興味がある人は使ってみてください! 無料! どうぞ!
データとかどうなるの
いちおうそれなりの知識と経験のあるプログラマだという自負はあって、その自覚と責任のもとで、必要な安全性を担保できる程度にはセキュリティのことを考えて作っています。
またどのBig Techとも関係ない完全に独立したアプリであって、かつ広告なども現状入れておらず、データを個人情報を結び付けることは絶対にしない、というポリシーのもとで作っています。また、データを何らかの形で使用するサービスを作るときには絶対にopt-inとする、というポリシーをもっています。詳しくはFAQをどうぞ。
なぜ作ったの
自分は遠くも近くもあちこち行くのが好きなんだけど、どこに行ったか・いつ行ったか、について、過去のことを正確に思い出せないこともよくある。友人たちと飲みにいったあと、2軒めにふらっと入った店がすごくよかったんだけどしこたま酔っ払ったせいでどこの何という店だったかが正確にはわからない、とか。近所の庭園に散歩に行くのに、前に紅葉がすごくよかったのはいつ頃だったっけ? とか。ひさしぶりの街を歩いてるんだけど色々変わってて、あれー、前に来たのいつだっけ? とか。
もちろん個人でGPSログを記録するだけなら色々方法はあるんだけど、デバイスを持ち歩くには充電に気をつかわないといけなかったり、単にiPhone内に記録するだけだとマシな検索機能を作るのが大変だったり機種変更のときに気を遣うことになったり、あれこれ大変。なので、いつも使ってるスマホ(iPhone)を持ち歩いていれば解決されるようにしたい、というのが動機。
あとはチェックインかな。人間はチェックインしたい。Swarm(旧Foursquare)とかを使ってる人もいるけど、個人的にはゲーミフィケーションがいらないというか、そういうものを見せてほしくないんだよね。チェックインするときは単にチェックインしたい。あと写真を添付したい。Facebookのチェックインが条件にぴったりではあるので使ってたんだけど、Facebookに囲い込まれたまんまなのは嫌だなとちょっと思っていたので、機能をつけた。んでSNS等でシェアしたとき格好がつくようにOGP画像をがんばってみた。
どう作ったの
この記事を読む人は気になっているかも。どうかな。
iPhoneアプリの方は完全にSwiftUIで作った。iOS開発からもだいぶ(12年!)離れてたので、プロトタイプ版(UIKit)のスクラッチからの書きおこしだけ友人に(有償で)お願いして、その上に基本機能を作っていき、目途がついた時点でSwiftUIでのプロダクション版を自分で書きおこした。かなり時間をかけたけど、自分にとって不自然な使い勝手の箇所はだいぶなくなった。
サーバサイドはRuby + AWS Lambdaの完全サーバレス。メンテ作業なんかも全部Lambda経由でやるようにしているので常時稼動してるEC2もコンテナ(ECS/Fargate/EKS)もゼロ。ひとりで作るのにサーバの面倒とか見てらんないし。とはいえ完全Lambdaだとパフォーマンスとか管理とか料金とかが多少心配なところも無くはないので、これはユーザが増えてきたらそのうち考えなおすかもしれない。
Webはあまりないけど、React(create-react-app)でSPA。ただチェックインのWebページにいきなり飛ばれたときにOGP画像出したいとかはあって、そのあたりはちょっと苦労して実装した。だからだいたいはS3ホスティングで済んでるけど、サーバサイドのエンドポイントも多少ある。
これからどうするの
自分で使いたいサービスなので、何があっても当面は運用するつもり。ユーザが(かなり?)増えたら運用や開発体制を何か考える。増えなければ、低コストで運用し続けられるように、特にサーバサイドをシュリンクするとかはあるかもしれない。しばらくは細かい改善と機能追加を続けるつもり。
Androidアプリは直近の計画にはないが、そのうち作れたらいいなー、くらいで考えている。自分でやることにこだわってるわけでもないので、誰かに請負でお願いしてもいいなあ。もし興味のあるAndroidアプリエンジニアの人がいたらご連絡ください。
あとWebページなんかは完全に素人の仕事になっているので、誰かプロのデザイナーさんにいつか頼みたいなーと考えてもいる。これも誰かご興味あればご連絡ください。
まとめ
ゼロ年代の個人ウェブサービス全盛だった頃に自分では何も作らなかったのが、今回真面目に全部自分で作ったので、ちょっとスッキリしたね。フルスタックエンジニアだ!
*1:GoogleMapsのタイムラインは? っていう人がいると思うけど、場所(エリア)から「いつ」を検索することはできない
*2:たとえばGoogle Mapsのタイムライン
