たごもりすメモ

コードとかその他の話とか。

Fluentdのflush_mode immediateはいつ使うのか

Fluentd実践入門をあらためて手元でぱらぱらやってたら、しまった! この話をどこかにちょっとでも書こうと思ってたのに忘れてた! という話が出てきたので、忘れないうちに書いて放流する。

flush_modeとはなにか

FluentdのOutputプラグインには<buffer>セクションで指定できるflush_modeというパラメータがあって、これはOutputプラグインがどういう基準でバッファ内のデータを書き出す(writeメソッドを呼ぶ)かという戦略をコントロールする。有効な値はdefault、immediate、interval、lazyの4つ。

ただし多くのケースでこのパラメータは明示的には指定されていないはず。というのも、デフォルト値であるところのdefaultの場合には、<buffer>セクションに指定されている他のパラメータ((と、例外的に<buffer>セクションの外側に指定されているflush_intervalも見ている。これはFluentd v0.12以前のプラグインの使い方をそのまま踏襲している設定について、動作を壊さないための措置。))を確認して適切なモードを自動的に選ぶようになっているからだ。たとえばバッファのチャンクキーにtimeが指定されている場合にはlazyが選ばれる。

といったようなことは「Fluentd実践入門」のp166-167あたりにもちろん書いてある。みんな買って読もう!(宣伝)

flush_mode immediateとは何か

ところで、flush_modeのうちには、他のパラメータをどうセットしても暗黙には選ばれないものがあって、それがimmediateだ。これはFluentd v1系*1における完全に新しい機能・挙動なので、特に過去の設定パターンとの互換性を考える必要がないため。

これがどう動作するかというと、バッファリングは行うが、データが書き込まれたバッファチャンクは即座にflushされる。つまり一回のemitで渡ってきたデータは即座にwriteに渡される。

flush_mode immediateは低レイテンシ、かつ出力リトライが必要な場合に使う

ここからが書き忘れたところ。

immediateは、動作としては非バッファOutputプラグインに近いが、データが一度バッファチャンクに書き込まれる点が異なる。で、このモードをどう使うのかという話。

データ処理基盤を作っていると、とにかくこのデータだけは低レイテンシで処理したい、ということがたまにある。全データに低レイテンシを求めるのは非効率だが、それでもごく一部のデータに限ってであれば、イベントの発生から処理の最後、典型的にはオペレータへの通知など、までを数秒で行いたいというような要求はありうる。

ただし、低レイテンシで処理を行うからには非バッファOutputプラグインを使えばいいかというと、それも困るケースがある。ネットワーク転送などを行っているときに障害が発生したら即座にデータが失われるようではマズい。このため、普段は可能な限り低レイテンシで出力を行うが、障害時にはバッファリングとリトライを行い、その間にOutputプラグインが受け取るデータはバッファチャンクに適切に貯まるようにしたい。flush_mode immediateを指定していればこれが実現できる。

過去に(現在でも?)これを実現する方法のひとつとしては、flush_intervalを0や1にセットしてしまうという手があり、実際にやっている例も知っている。ただしこれはデータの到着にバラつきがあるときでもflushスレッドがかなり忙しくループしてしまうため、全体としてはあまり効率的ではない、という問題があるし、設定の意図があまり明確ではなくなるという難点もあった。

immediateは気軽に使っていいのか

あまり気軽に使うのはオススメしない。バッファOutputプラグインは実装としては通常の、バッファチャンクが適切なサイズに育ってから一気に出力するような処理をするように書かれているだろうから、それを半ば無理矢理に高頻度で呼ぶようになるので、想定していなかった問題が起きないとも限らない。

またflush_mode immediateを使って出力を行っている場合、通常の状況では出力単位が1〜数イベント、サイズにして数KB程度までとなることが多いだろう。一方で障害時にはリトライを続けている間に到着したデータはchunk_limit_sizeで設定したサイズまでチャンクに溜め込まれるため、障害が解消した直後はいきなり数MBのデータがどかっと出力されることになる。出力データサイズの不均衡は後々の処理において、処理性能や使用メモリサイズなどの点で問題を誘発することが多い。

なので、データ処理パイプライン全体をちゃんと考えて、どうしても低レイテンシ・出力リトライを両立させたいところのみでflush_mode immediateを使用しましょう。

まあ、実際のところこれを必要とするのはごく一部の大規模なデータを扱っている人達だけじゃないかなとは思う(ので書き忘れてた)。他にも大規模データ基盤向けの話はいくつもあるんだけど、それをまとめた章を書こうとしたときに手が止まったんだよなあ。対象読者数があまりに少ない内容になるんで……。

というようなことが

Fluentdの他の部分についてえんえんと書かれているFluentd実践入門をよろしく!!!!!!

Fluentd実践入門 ──統合ログ基盤のためのデータ収集ツール：書籍案内｜技術評論社

amzn.to

*1:v0.14以降のこと

「Fluentd実践入門」を10月8日に出版します

Fluentd実践入門

Fluentdの現バージョン(v1.15)について世界で一番詳しい本です。というか、Fluentdそのものだけについての、おそらく世界で唯一の技術書です。 出版社は技術評論社です。電子版もGihyo.jpやKindleはじめ各社で出ます。買ってね!

gihyo.jp

TL;DR

  • 発売日は10月8日です
    • 一部書店ではちょっと早く9月末に並ぶかも
    • 電子版は発売日よりちょっと前に出るかも1
  • 544ページ、Fluentd本体については考えられる限り盛り込みました
    • Fluentdをなんとなく使っている人が確信を持って使えるようになれるはず
    • 組込みプラグインの頻出用法、本番環境での運用ノウハウ、プラグイン開発からテストなどまで
  • エコシステム的な部分についてはカバーできていません
    • Kubernetes上での運用やFluent Bitとの組み合わせとか
    • AWS FireLensやGCP CloudLoggingなどで使うときのノウハウとか
    • でもそのへんを調べるときの基礎的な知識が得られるでしょう

最後のゲラのチェックと修正はさっき終わらせたぞ!

なお、本の一部に見開きで左右ぶち抜きの表があります。まあまあな数あります。これがもしかしたら、電子版ではちょっと見にくいかもしれません。残念ですが各ページには収まらなかったのでこうなっています。電子版を購入される方にはすみません。

アピールポイント

Fluentdについて、前にけっこうやったしだいたい知ってる、と思う人もいると思います。おそらくその人達の多くは次のことを知らないでしょう。

  • out_forwardの送信先リスト2、今では再起動なしで増やしたり減らしたりできる
  • Fluentdの設定ファイルはYAMLで書ける

ひとつめはFluentd v1.8でサポートされたService Discoveryプラグインによるもので、ふたつめはFluentd v1.15で入ったばかりのものです。この本で両方とも(後者はコラムでだけど)解説されてます。Service Discoveryプラグインを使ったプラグインの作りかたももちろん解説されています。ということで、最近便利になった情報もがっつり盛り込みました。

また、Fluentdのことは詳しくは知らないけど、なんか設定してみたら使えたしそのまま動かしている、という人もいると思います。というか、おそらくそういう人は世界中にものすごく多くて、それでなんとなく使えるFluentdはいいソフトウェアだということなんです。

が、それだと高負荷時に何か起きてしまうとか、エンタープライズ案件の超高信頼性が要求されるケースで使うことになってあらゆるパラメータを調べないといけなくなったとか、そういう場合にすごく困る。ドキュメントに書いてあることも多いんだけど英語だし、各々のプラグインのパラメータ起点でしか説明されていないから、全体像としてバッファリングやリトライがどうなっているのか、イベントはどこから来てどこへ行くのか、そもそもイベントって、レコードやタグやtimeって何???? みたいなことがたぶん起きてるはずなんですよ。

あとは、プラグイン書けば簡単に済むはずのことをすごく苦労してる人も多いんじゃないかと思ってて、その人たちにプラグインを書くということがどれだけ簡単なことなのかを伝えられてもいないんじゃないかと思います。

ということで、この本ではそのへんのことがだいたい全部書かれています。いるはずです。そのへんのことに世界で二番か、もしかしたら一番目に詳しいのが自分です。なので、この本は世界で自分しか書けなかったと思います3。

Fluentdがもうちょっと流行ってる感ある数年前に出せてればよかったかなと思う反面、ログの扱いという需要が消滅することは絶対に無くて、かつ代替OSSも出てきていないと思うので、たぶんみんな静かに当たり前に使うフェイズになっているのかな、と思うんですよ。なので、もしかして今こそ、多くの人に届くのかもしれないな、とも思います。

残念だったけど今後に期待ポイント

で、Fluentdそのものについてはだいたい全部書いたんですが、もちろん書かれていないこともいっぱいあります。

サードパーティプラグイン各々の紹介とか、統合ログ基盤なるものの全体をどう作ってどう使うのかとか、極端に大規模・大トラフィックな環境に特化した運用ノウハウとか。 あと最近ではKubernetes環境での使用方法とか運用ノウハウ、Fluent Bitとの連携やFluentd Bitそのものの解説、AWS FireLensやGCP CloudLoggingなどのFluentdの陰が見え隠れするロギングサービスとの関係、連携、などなど。

もちろん1冊の本で森羅万象をカバーできないので、そのへんは、今後・他の本や記事に期待、ということになります。Kubernetes環境やFluent Bitについては書きたい気持ちもありましたが、ボリューム的な問題や、自分にその周辺のノウハウがほぼ無いことも含めて、ちょっと難しかったです。

しかし、今現在、そのへんの技術や製品のドキュメントをちょっと見ると、なんか普通にみんなFluentdについてのごく簡単な説明をするだけとか、「Fluentdについてはオンラインドキュメントを見てください。さて……」みたいな感じになってるんですよ。でも、ちょっとFluentdのドキュメントサイト見て全部分かれっていうの、だいぶ無理があるはずだったと思うんですよね。なので、この本が出たことで、「この本を読んでください」と言える状態まで持っていけたんじゃないかなとは思っています。

また、今までだとそのへんの発展的なトピックについて解説したり本を書こうとしたりしても「ええ……まずFluentdの解説するの……?」みたいな感じがあったんじゃないかなという気がします。今後はそのへんを「この本読め!」でスキップできると思うので、より発展的なトピックについて、もっと気軽に・詳しく解説してくれる人が増えてくれるといいなと期待しています。

経緯や感慨

この本、ほんとはもっと何年も早く出せるといいなと思って書きはじめたんですよねー。最初は編集さんもつけず、単独でやってました。そしたら最初の半分近くまでは一気に書けたものの、ある章のあるトピックを書こうとして「いや、これ全部書くの無理じゃない……?」みたいな感じで手が止まってしまい4、いきなりすごい期間が空いてしまって。んで、その後なんとか再開したもののぜんぜん進まず、そこから編集の @inao さんに泣きついて、もう何から何までお世話になりながら、なんとか出版までこぎつけました。@inaoさんには本当にもう絶対頭が上がりません。

ぶっちゃけ、途中の手が止まった時期には、できてる分の原稿だけで同人誌として出しちゃってお茶を濁そうかな、とか思った時期もあったんですよ。そうしなくて良かったです。今にして思えば、必要なことがまだあれこれ書かれていなかったし、全体の組み立ても考えられていなくて、本としての出来は3割以下だったんじゃないかという。あれで出して終わってたら、世間に出すべき知識と経験が埋もれたまま終わっちゃってたなと思います。

出せてよかったなと思うのは、前にも書いたけど、これ書けるの本当に自分しかいないなっていうのはあって、今回やれるだけのことはやったから肩の荷が降りたと感じてる部分かな。Fluentd v5とかv10とかになるとまた違うんだろうけど、これでFluentdについてやらないといけなかったことを全部やった、という感じはあります。5

まあ何にしろね、単著ですよ単著。自分が通っているあの本屋に自分が書いた本が置かれる! かもしれない! ウヒョー!

雑誌での執筆は何度もあったけど、本を書くとなると雑誌の原稿とは全然違う作業が大量に、死ぬほど大量にあって大変でした。正直ナメてた。みんなこんな大変なことやってたんだな。すごい。でも単著だったから自分で全部やらないといけなくて大変だったのかもしれない。が、ちょっと共著にはトラウマがあってさ……。6

しかし、とにかくこれで出ます。もう自分が何もやらなくても出るはず。いやー、正直な話、前の会社を辞めてから色々やりつつも、ずっとこの原稿のことが頭や直近のTODOにあって、それがキツくて……。自分は大きいタスクを2並行では処理できないんだなと思い知りました。この本の原稿の作業がようやく終わりそうになった最近、ついに脳内のバックグラウンドでいま書いてるサービスの実装をどうするかを考えられるようになってきて、それがちょっと嬉しいです。

まとめ

がんばって書きました。Fluentd使っている・使いそうな方はぜひどうぞ! Fluentdに関係なくてもどうぞ!

  1. 紙版の発売日10/8に対して、Kindle版は10/6で登録されていますね↩

  2. <server>で並べて書いてたやつ、YAMLやJSONファイルに書いて読ませるか、DNSのSRVレコードを使う↩

  3. だって@repeatedlyは技術書とか書かないじゃん、ぜったい↩

  4. これは実際には書こうとしていたトピックに無理があって、最終的に収録範囲からは外しました↩

  5. これはなんなんだ、と思ったけど、ISUCONが完全に自分と関係ないイベントとして勝手に続いているのを見るのと似た感じなのかなといま思いました↩

  6. だいぶ昔にある共著の話に誘ってもらって参加して、原稿の担当分の半分くらいは書いたんだけど、そのまま編集さんがどっか行って話がポシャったことがあって、あれはかなり悲しかった。あるところで技術書の共著が話題になったとき、当時の共著者メンバーが一人いたのでふと目をやると、ばっちりその人と目が合って、思わず二人で笑ったことが忘れられない。↩

React appを手元でProduction modeで動かす

react-scripts startで使えるDevelopment modeだとなんか変なことがちょいちょい起きるので、動作確認をProduction modeでやりたい。

ところでこのアプリからはCORSリクエストを送りまくるのでHTTPSのサイトとしてlocalhostにアクセスしたい。Development modeについては、これはpackage.jsonに以下のように書いておいてnpm startすることで実現できる。

...
  "scripts": {
    "start": "HTTPS=true react-scripts start",
...

React appをProduction modeで動かす

単に動かすならドキュメントにあるようにnpm run buildでビルドしたあと、それを配信するサーバを実行すればいい。

$ npm run build
$ npm install -g serve
$ serve -s build

serveコマンドをHTTPSを有効にして実行する

ところがこれだとHTTPなので、HTTPSにしたいときには困る。見てみたらserveコマンドには--ssl-certと--ssl-keyオプションがあって、このふたつを指定してあればHTTPSで動いてくれるっぽい。ちょいちょいと鍵と証明書を作って実行する。

$ openssl genrsa -out key.pem
$ openssl req -new -key key.pem -out csr.pem
(色々聞かれるが、全部Enter連打でいい)
$ openssl x509 -req -days 9999 -in csr.pem -signkey key.pem -out cert.pem
$ serve -s build --ssl-cert cert.pem --ssl-key key.pem 

   ┌─────────────────────────────────────────────────────┐
   │                                                     │
   │   Serving!                                          │
   │                                                     │
   │   - Local:            https://localhost:3000        │
   │   - On Your Network:  https://192.168.68.103:3000   │
   │                                                     │
   │   Copied local address to clipboard!                │
   │                                                     │
   └─────────────────────────────────────────────────────┘

できた。

Chromeで証明書チェックをスキップする

できたと思ってChromeでhttps://localhost:3000を開くと証明書チェックにひっかかって進めない。Development modeのときはAdvanced以下に開くリンクが出るんだけど、こっちでは出ないのは何の違いによるものなのか。

なんでだよと思って調べてみたら、このページ上で(どこかをクリックしてから?) thisisunsafe とタイプすると開けるとのこと。マジかよと思ってやってみたら、できた。マジかよ。

yuki.world

まとめ

できた。やれやれ。

@react-google-maps/apiでの描画地図にPolylineで線を描くと消えなくなる

という問題が起きてあれこれやってた。React難しいの巻。たぶんnpm startで起動できるDevelopment modeでだけ起きる問題。

問題

@react-google-maps/apiでReactアプリ上にGoogle Mapsを表示*1し、そこに好き勝手にマーカーとか線を描きたい。以下のような感じ。

// MyMapComponent
import { LoadScript, GoogleMap, Marker, Polyline } from "@react-google-maps/api";

// ...中略
// in function MyMapComponent
return (
  <LoadScript googleMapsApiKey={myApiKey}>
    <GoogleMaps
      id="myMap"
      mapContainerStyle={{height: "80%", width: "100%}}
      zoom={calculatedZoom}
      center={{lat: calculatedCenterLat, lng: calculatedCenterLng}}
      mapOptions={{disabledDefaultUI: true, zoomControl: true}}
    >
      <Marker key={"map-marker-start-" + start.uuid} position={{lat: start.lat, lng: start.lng}} />
      <Marker key={"map-marker-end-" + end.uuid} position={{lat: end.lat, lng: end.lng}} />
      <Polyline
        key={"map-line-" + start.uuid + end.uuid}
        path={pathFromStartToEnd}
      />
    </GoogleMaps>
  </LoadScript>
);

startとかendあるいはpathFromStartToEndなんかはpropsで親から受け取る。これでまあうまく動く、ように見える。 なんだけど、外部から与えてるpropsの中身を変えてマーカーや線を再描画するとマーカーや線が残ることがあって、なんでなんだこれってだいぶ苦労した。

調査

いろいろ調べてると、Google Maps JavaScript APIのドキュメントにこんなのを見掛けた。

Removing Polylines  |  Maps JavaScript API  |  Google Developers

なんかこれがうまく呼べてないんだろうなってことで@react-google-maps/apiの実装を調べてみると、このコードを読む限りではthis.state.polyline.setMap(null);してるように見える。おっかしーな。 で、調査してみようと以下のように<Polyline />コンポーネントの呼び出しにonLoadとonUnmountってフックがあったので、引数にstateに格納しているpolylineオブジェクトを受け取れる。これを以下のように指定して動かしてみた。

const onLoadHook = (line) => {
  console.log({message:"onLoad", line});
};
const onUnmountHook = (line) => {
  console.log({message:"onUnmount", line});
};

return (
  // ... 中略
        <Polyline
        key={"map-line-" + start.uuid + end.uuid}
        path={pathFromStartToEnd}
        onLoad={onLoadHook}
        onUnmount={onUnmountHook}
      />
  // ... 中略
);

そしたらonLoadは2回呼ばれてるのにonUnmountは一回しか呼ばれてないことがわかった。えー。Polylineコンポーネントが作り直されて1回ずつ呼ばれたのか、Polylineコンポーネントは1回だけ作られて2回mountされたのかはよくわかってないんだけど *2 。でもたぶん後者かなという気がする。以下の推論がうまくハマるから。

ひとつのコンポーネントが2回マウントされているとすると、Polylineオブジェクトが作られたあとcomponentDidMountが2回呼ばれてるってことで、それぞれ呼び出しの中でnew google.maps.Polyline({...})が行われてるから、実際の地図上には同じ線が2重に引かれてることになる。

どちらの呼び出しもsetStateでpolylineにnewしたオブジェクトを保存しているので、1回目の呼び出しでstateに保存されたPolylineオブジェクトは上書きされて消えてしまい、setMap(null);が呼ばれることがなくなってしまう、ということっぽい。

で、これはdevelopment mode的なやつでだけ起きてるんじゃないかなとnpm run buildしたものを手元で動かしてみた*3らonLoadフックが1回しか呼ばれなかったので、Production buildすればこの症状は起きない。

が、まあちょっと手元の開発でこれ起きてるの無視するのはねえ……。

解決策

しょうがないので自分でpolyline.setMap(null);を確実に呼ぶようにする。以下のようにonLoadフック経由で対象オブジェクトを受け取り、再レンダリング前のクリーンナップ時に過去描画されたものに対してsetMap(null);を呼ぶ。

import { useEffect } from `react`;

const lines = [];
const onLoadHook = (line) => {
  lines.push(line);
};

useEffect(() => {
  return () => {
    lines.forEach((line) => {
      line.setMap(null);
    });
  };
});

return (
  // ... 中略
        <Polyline
        key={"map-line-" + start.uuid + end.uuid}
        path={pathFromStartToEnd}
        onLoad={onLoadHook}
        onUnmount={onUnmountHook}
      />
  // ... 中略
);

これでうまくいった。useEffectの使いかたがやっとちゃんとわかった気がする。

余談

はてなブログのMarkdown書式、コードハイライトの形式にjsx指定しても無効なの悲しいね。

*1:最初はGoogleのオフィシャルのReact Wrapper使おうと思ったんだけど、細かいところどうやるかのドキュメントが何もないのとロードがうまく動かないのと、あれこれあって諦めて使うライブラリをスイッチしたら一発でできた。なんだよ。

*2:JavaScriptのObjectにもobject_idがあったら便利なのに……。

*3:これをHTTPS有効にしてやるのにまたひとハマりした、ああもう

RubyKaigi Takeout 2021でしゃべった

RubyKaigi Takeout 2021の途中ではあるけど、とりあえず自分の発表終わったのでメモ。

Ractorをワーカーとして使うアプリケーションサーバを作ったよ! という話なんですが、まあこれは話の入りというかそういうもので、実際の内容の中心はRactorではどういうコードが動かないのか、どうすればよいのか、みたいな話です。 で、Ractorで動かないコードは全体的には直していきたいよねということになると思いますが、そうはいっても動かしてみないと確認もできないじゃんということで、主な問題であるところのWebアプリケーションを実際にRactorの上で動かして確認できるようにしておきましたよ、というのが今回作ったright_speedです。

github.com

本当はRactorの数を増やしていくごとにどれくらいのリクエストを処理できるようになるのかとか、MJITを有効にしたときその傾向はどうなるのかとか試したかったんですが、それよりだいぶ手前のところでSEGVを踏んでしまって、セッション録画の提出日までにはちょっとどうにもできませんでした。残念。

副産物

新しい機能なもんで作業してる途中であれこれあって、明確なやつはbugsにいくつか報告してます。

あとそのへんについてのパッチとか。

SEGVってるやつは見てみてはいるんだけど明確にこれかなというのはまだ分かってない*1んで、どうにかなるかなあ。あとRactorまわりの話はいじってると割と簡単にプロセスがビジー状態になったりSEGVったりするのが厳しい。

フィードバック

定数に値を入れるときにデフォルトでshareableだとマークする方法が欲しい、マジックコメントかな? という議論がスライド中であるんだけど、発表中にコメント欄で@ko1さんに教えてもらった。

# shareable_constant_value: true

class Foo
  VALUE = {key: "value"}
end

Ractorのドキュメントにも書いてあったので完全に自分の見落としでした。すいません。

(追記) …… と思ったら今日直されていたのでたぶんドキュメント読んだときはmagic commentだと思わずそのままスルーして忘れてたんだな。無実だったことにしよう。

*1:デバッグ用のカウンタまわりなんじゃないかなと思ってはいるんだけど

Amazon SESのメール受信は特定のリージョンでしか使えない

メモ。ap-northeast-1のコンソールでSES開いてても"Email Receiving"の"Rule Sets"が灰色になった(gray outした)ままで選択できなくて、ドメインのverifyとかIAMとかで何かうまくいってない? と調べてまわってた。

結論としては特定のリージョンでしかサポートされてない。

Email Receiving Endpoints

Amazon SES doesn't support email receiving in the following Regions: US East (Ohio), US West (N. California) Asia Pacific (Mumbai), Asia Pacific (Seoul), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Canada (Central), Europe (Frankfurt), Europe (London), Europe (Paris), Europe (Stockholm), Middle East (Bahrain), South America (São Paulo), and AWS GovCloud (US).

docs.aws.amazon.com

なんだよもー。us-east-1かus-west-2かなあ。
なおリージョンが変われば "Verify a New Domain" もやりなおしみたい。

退職します2021

TL;DR

  • 現職のTreasure Dataを本日を最終出社として退職します
  • しばらくは休みをとりつつ次に何をやるかを考えるつもり
  • 次は自分でビジネスを立ち上げるか、それともエンジニアリングチームを作るところにフォーカスするか、これから考える
  • 技術顧問業もはじめます、が、メインにはしないつもり
  • その他これからの活動にご期待ください

現職について

就職時にこのエントリを書いてから6年3ヶ月、当初思っていたより長く働いたなあという感じです。入ったときはUSと日本で合計40人もいなかったくらいだったと思うけど、今では世界中に同僚がいて規模は約10倍くらいになりました。途中Armによる買収もあって、スタートアップから中規模企業までのビジネスと会社の成長を見てきました。自分もそれなりに貢献できてたんじゃないかなと思います。 いま見直すと就職エントリに書いていた3点、「技術ベンチャーであること」「ベンチャー企業として大きな成功を狙っていること、またそれが有望に見えること」「優秀なプログラマが同僚に多いこと」はすべて見事に満たされていて、データ処理に関する高い技術をベースにビジネスを組み立て、それにより成功したexitを経験できました。優秀なプログラマ大勢と働けていたのは言うまでもありません。

いやー、いい6年余りでした。

特に初期の頃は営業やSE*1、果てはBizDev*2担当のVPなんかとも一緒に仕事をすることがあったりして、顧客を訪問しにベイエリアやシアトル、スコットランドなんかに行って直接話したりもしました。

ここ3〜4年くらいは自分のマネージャや同じチームの同僚が基本的に北米の人ばっかりという状態で、おかげで英会話の機会には困りませんでした。入社時は英会話はうーん、がんばる! くらいだったんですけど、今はもうペラペラ……というと語弊があるけど、日常会話から業務上の議論や交渉、練習なしのプレゼンテーションまでだいたい困らなくなりました。英語圏のIT系企業ならたぶんどこでも働けるくらいにはなれたんじゃないかなと思います。会社から英会話サービスの補助とかも出てたけど、結局まったく使わずに終わってしまった*3。

他はもちろん、お金は大事で、もう非常によい目を見させてもらいました。Treasure Dataの創業者たちがインタビュー等でよく開発者への待遇や見返りについて話していますが、正直彼らのやったことはインタビューで言ってる内容でもまだだいぶ過少に言ってるなという感じで、考えられる限りによい報酬プログラムにしてもらったなと思います。本当に感謝しています。

じゃあなんで辞めるの

単純に次に何をやるか考える時間が欲しくなった、という感じです。Armによる買収の後から「次になにやるの?」という質問が脳内をぐるぐるしていて、けれど普段の業務をやっているとそういうことを考える時間や余裕がなかなか取れないので、いったん休んでそういうこと考えてもいいかという気分になりました。ありがたいことに、金銭的には多少の余裕はあるし。

まあ他にもいち開発者として働いている今のポジション/ロールを変えたくなったこと、会社の規模が大きくなってきたことにより自分がTreasure Dataという組織に求めているものと実態との間のギャップが大きくなってきたこと、なんかもあります。特に自分の役割というか仕事としてやることの内容については、前までは一生いち開発者でいいと思っていたんですが、この6年経験したことを考えると、もうちょっとやりたいことも色々あるなあというか。このへんはまだはっきりしたことが考えられてないので、これからですが。

次どうするの

とりあえず数ヶ月はゆっくり休みをとりつつ考えようかと思っています。現状、次のフルタイム仕事についてはどことも何も話をしていません*4。

が、ちょうどよいタイミングで来た話がありまして、6月からはあるスタートアップの技術顧問を1件引き受けることにしました。技術顧問業を生業にしようとはあまり思っていないのですが、それでも自分の知識と経験を役立てられそうなこと、色々な会社やサービスの実態を見せてもらうのは今の自分の考え事にとっても非常に大きいプラスになりそうなことから、とりあえずやってみようと思っています。 ということで、他にももしお困りのところに自分がお役に立てそうなところがあればご連絡ください。もう数件くらいは引き受けられるかもしれません。

次のメインの仕事はどうするかこれからなんですけど、どちらかというと開発者としての仕事よりは、チームを作る・ビジネスを作る、といった方向かなあとぼんやり考えています。明確なイメージはまだないんですが、どうしたものか。先達の方々に話を聞きに行きたいなあと思っているので、そのうち皆様にお願いに上がるかもしれません。その際はよろしくお願いします。

あとは最近読めてない本を読みまくったり、あまり触ってない方面の言語をやってみたりしつつ、ちょっとは遊んだりします。他にボランティアで参加する活動なんかもありそう。コロナが無ければ世界中旅行して回ったりしたいところなんですけど、それはまた今度の機会かな、しょうがない。飲みにいったりもできると良かったんだけど、コロナ明けまで持ち越しですね。

ということで

今後ともtagomorisをよろしくお願いします!

*1:Sales Engineer

*2:Business Development、日本語で言うの難しいなこれ

*3:というか大学を出て以来、英会話教室的なものには一度も通ったことがない。義務教育と受験英語はなかなかよくできている

*4:実は最近どうかと思える件もあったんだけど、詳しい内容を聞くとこちらの期待との間にギャップがあったのでそのお話は無かったことに