ゲスト紹介と経歴
ken
はい、London Tech TalkのKen Wakazumaです。今日もロンドンからお届けしています。今日はちょっと数が忙しいので、ホストの方は私一人で収録していこうと思うんですけれども、今日も素敵なゲストの方をお呼びしています。
じゃあ、Higashiguchiさん、今日はよろしくお願いします。
Kazuki Higashiguchi
よろしくお願いします。ロンドンではなく、日本の神奈川からお送りしています。Higashiguchiです。よろしくお願いします。
ken
はい、神奈川なんだ。そうかそうか。
Kazuki Higashiguchi
はい。
ken
はい、ということで、まずね、今回Higashiguchiさんをゲストにね、お呼びして、ちょっと軽く経緯からご紹介しようかなと思うんですけども、
なんか昔から、あの、ポッドキャストは聞いてくれてたみたいで、Twitterでね、僕と何回かコメントのやり取りをしたことは、あの、記憶してるんだけど、
Kazuki Higashiguchi
はい。
ken
そう、で、その時、あ、え、なんかSREされてるってことは認識していて、いつか呼べたらいいなと思ってたんだけど、
なんとなんと、あの、ゲストとしてね、出てくれたこじさん、あの、が、この前ちょっと会って遊びに来て話してた時に、
なんか大学の友人で、ぜひゲストにおしたい方がいるんだよねってこう言われて、
OK、OK、誰誰って聞いたら、あの、Higashiguchiさんっていうこと、あの、友達がいてね、つって、
Twitter見せてもらったら、あ、この人知ってるわって、アサイ君となんか仲良い、あの、ワンワンもしてる人だよね、みたいなことがあって、
Kazuki Higashiguchi
あ、伝わってた、よかったです。
ken
そうそうそう。
Kazuki Higashiguchi
そのエピソードで何とか思い出してもらえるかなって言ってたんですよ。
ken
あ、そういうこと。そう、そんな経緯なんですよ。じゃあちょっとHigashiguchiさんの方からもね、あの、自己紹介もらおうかなと思います。
Kazuki Higashiguchi
はい。
ken
はい。
いいですか。
Kazuki Higashiguchi
はい、Higashiguchi和樹と言います。
えー、社内ではカズって言われてるんですけど、ちょっとカズさんはもう、もっと有名なカズさんがいらっしゃるので、あの、Higashiguchiで今回はやろうと思ってます。
カズさん、あの、ケンさんとの共通点としては、SREっていうところと、ま、日本にいるんですけど、えー、仕事は英語環境でやっています。
っていうのは、今現職は、あの、オーティファイという会社でシニアSREとして働いていて、そのオーティファイがヘッドクォーターがサンフランシスコで、拠点は日本にあるんですけどエンジニア拠点ですね。
で、大体7割8割が結構英語話者なので、ま、コミュニケーションは全部英語で、もう、あの、ワンオンとか採用とかそういうのも含めて全部英語でやっているっていうので、
ま、ロンドンTikTokのリスナーさんの、あの、関心だったりとか、えー、属性としてもちょっと近いところにいるのかなとは思っています。
で、それ以前はですね、あの、ま、ベースっていう、ネットショップ作成サービスのベースっていう会社で、テクニカとかEMしてたり。
で、もっとそれ以前だとPOSシステムとかの自宅開発をしていたりですね。
で、もっと前にコジさん、先ほど紹介していたあのコジさんに大学生の時に、あの、会って、えー、そっからずっと開発合宿、温泉旅館で開発合宿に行ったり、
なんかプライベートなスタッフチャンネルでワイワイ喋ったりっていうのを、もう、かれこれ思えばそうか10年ぐらい続けているっていうような関係性にさって、楽しませてもらっています。
開発合宿の経験
Kazuki Higashiguchi
めちゃくちゃいい仲ですね。そっか。いや、今いろいろあげてくれたキーワードの中で、僕一番深掘りしたいのはその温泉合宿なんだけど。
ken
なになにそれ。仲間でさ、こう、ちょ、ちょっと集まって温泉を浸かりながら合宿しようかみたいなノリで行ったってこと?
Kazuki Higashiguchi
そうですね。3回ぐらい行って行って、最初は確か大学4年の時に道後温泉っていう高地かな、のところに、なんかもう、開発合宿っていう、なんか楽しい文化がエンジニアにはあるらしいし、
俺らも行きたいみたいな感じで、パソコン持って温泉旅館に行って、特に観光するわけでもなく、各々やりたい開発をするっていう。
ken
めっちゃいいっすね。楽しそう。その時は何を開発したんですか?道後温泉に行った時は。覚えてる?
Kazuki Higashiguchi
道後温泉の時はもう10年前ですからね。覚えてないかな。その後社会人になって、社会人になると2017年かぐらいの時に、千葉のそれまた、多分コワーキングのところに泊まりに行って、
その時は、4人で共同で何かのプロジェクトを作ろうって言って、どういうやつか忘れたんですけど、とりあえずフロントエンドとバックエンドがあって、名前をSASUKEっていう、確かそういうプロジェクトをやってました。
ken
SASUKE。かっこいい。それは、なんか勝手にハッカソンするみたいななんかノリで。
Kazuki Higashiguchi
そんな感じですね。確か当時はみんなまだちょっとやってみたい技術みたいなのを盛り込んでいこうとかで、語言語だったりとか、画面だったかな、フロントエンド何をチャレンジしたか忘れたんですけども、技術的チャレンジを盛り込みながら、
なんか一つのアプリを2泊3日ぐらいで作ろうみたいなことをしたりしてました。
ken
いやめちゃくちゃ面白そうっすね。なんかやりたいな、僕もそういうの。
Kazuki Higashiguchi
それ良かったですね。なんか全員がまだ独身だったので、結構自由な時間も多く取れたっていうのも背景にあったと思うんですけど、
確かにね。あの時やれて良かったなって思いますね。今だとちょっといろんな交渉が必要だから。
ken
わかるわかる。僕もさ、子供いるんだけどさ、あの、ホストの数とかさ、前ホストしてくれたアサイくんとかとさ、みんな子供いるから、
ファミリー連れで、なんかちょっとそのファミリーホテルみたいなところに集まって、なんか旅行してもいいよねみたいなノリ話して、まだ実現してないんだけど、
その時にパパたちは勝手に開発合宿してもいいなとか、今ちょっと思ったけど。
職業の選択と変遷
Kazuki Higashiguchi
ああ、それ素敵ですね。それだと全員ウィンウィンですからね。
ken
そうそう、全員ハッピーみたいな感じでね。
Kazuki Higashiguchi
子供も友達がいるし、遊べるし。
ken
そうそうそうそう、そっか。最初の会社がなんかPOSとかベースだったんだね、ということは、一応僕も今eコマースの会社だから、コマース話もちょっとできるということで。
Kazuki Higashiguchi
そうですね、ショッピファイ、なんかショッピファイをちょっと真面目に調べてた時期がちょっとだけあるんですけど、
めちゃめちゃ知ってるドメインだわって思ってました。結構いろんなことが金融領域の展開してるサービスも含めて。
元々僕はベースの中で金融領域の新規事業を作るチームでいろいろやってたんですけど、
なんかその時やってたこととかのナレッジが、ああわかる、こうなるよねとかいろいろ裏側が思い浮かぶような感じでした。
もちろんスケールはやっぱりプラネットスケールだったりすると思うので、もうちょっと変わると思うんですけど、
ドメインとしては結構慣れ親しんでいると思います。
ken
そうだよね、もろかぶりだよね。あれチラッと言ってたけど、テックリードとかプロダクトマネジャー?
Kazuki Higashiguchi
エンジニアリングマネジャーですね。
ken
エンジニアリングマネジャーだった。そっか、じゃあその時はチームを見たりマネジメントしたりが主で、
SREになったのはOtifyに入ってからってことか。
Kazuki Higashiguchi
そうです。
ken
おお、じゃあちょっとその当時の何だろう、転職というかジョブチェンジに至った時の心境の変化とか、
SREになりたくてなったのか、それともOtifyに入ることが先だったのか、どっちもだったのかとか聞いてみたいですね。
Kazuki Higashiguchi
Otifyに入るのが先ですね、これは。
ベースからOtifyに転職した時に考えていたこととして、英語環境に完全にシフトしたいっていうふうなことを考えたんですね。
何でかって言うと、なんか日本語でアウトプット、カンファレンスに登壇するとか、ブログ書くとか結構積極的にやっていたんですけど、
例えば外資とかにエンジニアリング転職するとなった時に、そのナレッジってそのままパブリックにコピペで伝わらないし、
で、やってて日本の中でしか、世界観でしかやっていないことが、自分が死んだ時に、死ぬ直前にちょっと後悔するんじゃないかとふと思った時に、
ちょっと環境ごとちょっと変えないといけないかなというふうなことを思いに立ったんですよね。
それで、いくつか当時選択できる選択肢を考えた時に、オーティファイっていうのは魅力的な選択肢だったというのが、最初オーティファイに入るきっかけっていうので、
そこからSREに、ある意味明確にロールはSRE、オーティファイの中でジョブチェーン、ジョブチェーンとは言わないかな、ロールの名前を変えて今SREとしてやってるんですけど、
もともとはただのバックエンドエンジニアだったかな、それでちょっと込み入ったシステムの設計、開発、運用を全部やってて、
なんかこれやってること、あんまりバックエンドエンジニアっぽくなくて、限りなくSREなんだけどみたいな話をしている中で、
じゃあSREにまずロールを変えて、チームとしてもSREに移動するっていうことをやってきたっていう変遷です。
ken
おー、なんかスタートアップらしくてめちゃくちゃ楽しそうですよね。いろんなハットを被るじゃないですか。
あれ、やってるうちに、あれこれやってるのって自分のジョブロールとマッチしてないよねみたいなのがよくあるんで、
そこでSREになっていったと、なんか面白いムーブだなと思って聞いていましたね。
Kazuki Higashiguchi
そうですね、まさしくそんな感じで、僕が入社したときのオーティファイは30人弱で、今150人いて、
そんだけ変わると、そのジョブロールもちゃんとした整地化されていったっていうのもあって、
整地化されてきたジョブロールを見ていく中で、ちょっと違うんじゃないかと思ってたっていう感じですね。
ken
そうですよね、こう外部でね、登壇とかしたり、あとは採用とかしていくときに、
本当はSREのスキルセットがある人が欲しいんだけど、
例えばDevOpsとかバックエンドで募集すると、違うスキルセットの人を募集してきたりするんで、結構大事なんですよね。
ちょっとじゃあ最初のモチベーションに戻りますけど、
英語でグローバルのマーケットに向けてアウトプットしていきたいみたいな、
僕も当時はすごいそれを持ってて、本当に共感するんですよ。
僕の場合は第一歩を踏み出すのがすっごい時間もかかったし、難しかったんですよね。
それ入る前は結構何かやってました。
例えば英語でブログ記事書いてみたりとか、GitHubでオープンソースされてたりとか、
なんか2022年のSREcon APACかな、そこで何か発表されてたみたいなことも聞いたのでそこにも触れたいんだけど、
それはOtifyに入られてからのデザインシステム、システムデザインの発表されたと思うんですけど、
その前は、入る前は何だろう、どういう状態だったのかなと思って。
Kazuki Higashiguchi
入る前もいくつかやっていて、
オープンソースで言うと、元々ベースっていう会社がCakePHPっていうPHP製のフレームワークを使っていて、
そこの英語ドキュメントの日本語翻訳っていうのは結構は、
24、25の時に割と積極的にやっていて、
で、登壇とかアウトプットっていう観点で言うと、
GoFalcon 2019年っていう、あれはアメリカサンディエゴで開催されたところに行って、
ライトニングトークしに行ったり、
あとは日本であったCakeFestっていう、これもCakePHPのカンファレンスですね。
初めてジャパンだったのかな、確か。
で、今、Cakeのコントリビューターとかメンテナーが集まる日本の渋谷にっていうところにイベントがあったんで、
そこにTDDのライブデモを英語でやるみたいなことをチャレンジしたり。
英語環境での挑戦
ken
ライブデモを英語でやる。
Kazuki Higashiguchi
相当厳しかったですね。
ken
僕聞いただけでも今日ちょっとなかなかハードル高いけどな。
Kazuki Higashiguchi
かなり厳しかったですね。
いろんな理由があったんですけど、かなり厳しいチャレンジではあったんですけど、
そういうチャレンジをいくつかやってましたね。
ken
でもすごいな、結構スポットスポットでチャレンジされてたんですね。
なんかその翻訳の話すごい好きですね。
今話聞いて思い出して、僕も似たようなことやったんですよ。
Modularの翻訳やったことがあって、
それももやもやしてて、英語で発信したいなできないな、でも翻訳ができるかなと思ってやってたんで似てますね。
Kazuki Higashiguchi
そうですね。結構コントロールしやすかったっていうのと、
割とアウトデイテッドだったんで、
どうしても日本語話者エンジニアは日本語のドキュメントをまず見るっていうときに、
そのドキュメントがアウトデイテッドでちょっと違うコテをプリクエストで出てくるみたいなことが何個かあったときに、
なんかこれは会社としてもちゃんとドキュメントを、
俺がコントリュートした方がいいんじゃないかみたいな謎の使命感が当時あったことを今思い出しました。
ken
かっこいいなあ、その使命感。
Kazuki Higashiguchi
でもすぐやめちゃったんですけど。
ken
大事な一歩ですよね。
もやもやとして何もしないよりは何かして、いろんなチャレンジをしてエディティしててみたり、翻訳してみたり、
英語環境に身を置いてみたりということで、
実際そのオーディファに入ってみて、多分いろんな新しいチャレンジ、技術的なチャレンジもあったと思うし、
ドメインもeコマースからオーディファに変えたみたいなのあったと思うんですけど、
その英語環境に身を変えたという意味での自分にとってのチャレンジとか学びとか、
ジョブロールの適応
ken
その実際どうでした?働き方が結構変わったと思うんですけど。
Kazuki Higashiguchi
そうですね。思いつく感じで3つぐらい変わったことがあったなと思っていて、
興味ある。
1個目が英語は思ったより難しいっていうことが、当たり前ですけどわかったっていうのがあって、
僕入社して最初の1週間目で、元々コントラクターでちょっとプロジェクトやったんですよ。
で、それの設計のデモンストレーションっていうんですかね、
シェアをするっていうのを全エンジニアの前でやるっていうのが最初の1週間の金曜日の仕事だったんですけど、
俺こんなに英語なんかたどたどしいんだって思ったっていうのが最初の印象だったんで、
もっとこれは英語は真面目にやらないとやばいなと、
身を置いて理解したっていうところと、
とはいっても日常をなんとかやらなければならないっていうのがあったんで、
かなりドキュメントを書くようになりました、それで。
ken
なるほど、なるほど。
それは書くことなら割とコントリビュートできるからそこから始めようみたいなそういう考えですか?
Kazuki Higashiguchi
そうですね、考え方としては書く、事前に書いて渡す方が簡単だっていうことですね。
あ、わかるわかる。
割と書きはできるんで、書いてしまって渡して、
基本非同期のドキュメントレビューとか設計レビューで済むようにすれば、
口頭での不確かな英語力もそこまで問題にはならないし、
やっている間の中でオーラルのコミュニケーションもブラッシュアップしていこうというような戦略を取ったっていうのが、
コメのちょっと転機というか、実際に英語環境に入っての違いかなというふうに思います。
ken
素晴らしい。
なんかその気づきっていうのは自分で気づいた感じですか?
それともなんか助言してくれるメンターだったりリーダーみたいな人がいたんですか?
Kazuki Higashiguchi
最初のモチベーションは自分で気づきました。
もう1個あるのは今オータファイでスタッフエンジニアされている岩永亮介さんっていう方が、
AmazonからAWSからちょっと転職された時のタイミングで、
ナラティブスタイルドキュメント、いわゆるこのドキュメント読んだだけで完全に理解できる、
そういうドキュメントを全社席に書いていこうよという文化をインストールしてくださったっていうのがあって、
そのタイミングでドキュメントを書いた方がもっとコミュニケーションしやすいっていう意識と、
ドキュメントの書き方、こうした方がもっとドキュメントで意図が伝わるっていうところのテクニックがミックスされて、
っていうこの両軸でこの動きができたという感じです。
ken
なるほど。
だからその会社が求めているそのドキュメント、ナラティブドキュメントを書いていこうという流れと、
自分のその弱みを補完して強みにしていこうみたいな軸を合わせていったってことですね。
Kazuki Higashiguchi
そうですね。
ken
かっこいいですね。
これが一つ目。
Kazuki Higashiguchi
これが一つ目ですね。
ken
二つ目は。
Kazuki Higashiguchi
二つ目はこのジョブロールの考え方とかっていうのに適応していったっていうのが二つ目で、
これは当時何考えてたかで思い出すと、
当時リードエンジニアとCTOがいて、結構いろんなことを全部やってたんですね。
インフラのアラートのあってオンコールだったり、サービスの開発におけるいろんなことをやっていて、
日本のエンジニアの僕のキャリアの間の中で考えると、
例えばインディビジュアルコントリビューターの方がEMになるとか、
その中でステップアップしていくみたいなのがメジャーっていうふうに思ってたんですけど、
どちらかというとこのジョブロールでVP用エンジニアリングを募集して入ってきてもらえますみたいな世界線ちょっと違うなと思ったんですよね。
エンジニアリングマネージャーはエンジニアリングマネージャーで専門で採用します。
ジョブディスクリプションを作って採用してきますっていうので、
そういうふうになった時に自分の隙間の見つけ方っていうか、
コントリビューションの隙間、将来的な隙間の見つけ方がちょっと違うなと思ったんですよね。
日本とアメリカ、いわゆる外資の企業っていうんですかね。
この人は恐らくこういう昇進とかロールの変更があるんだろうなって考えると、
今この人の役割を自分が見慣れるようになった方がいいっていう考え方よりかは、
おそらく、というよりかはジョブロールが足りないところに対しては発行されて、
オープンジョブが出て、そこに対して人が入ってくるんだろうから、
そのムーブはそんなにワークしないだろうみたいなところのギャップを調整するっていうのが
2つ目のアダプションですね。
ken
結構それはそうですよね。
日本のスタートアップから外資のスタートアップに転縮すると大きな変化の一つですよね。
結構早い段階で気づいたんですか?
Kazuki Higashiguchi
これはそうですね、たぶん3ヶ月目くらいかもしれないですね。
こういう動きをしてたらいいかなって思っていたのに対して、
足りない役割だったりとか保管する役割として新しい人が入ってきたっていうタイミングで、
なるほど、そういう匠なんだ、外資はって思ったっていう。
ken
そうかそうかそうか。
でもそれ結構早いタイミングで気づけた。
だから結構こぼれ玉っていっぱいこぼれてくると思うんですけど、
それを自分の領域を越えて拾っていけばいいのかっていうと、
実はそうでもないっていうのは大きいですよね。
Kazuki Higashiguchi
そうですね。
ken
そういうベースというかね。
Kazuki Higashiguchi
拾えば拾うほどいいみたいな世界線で生きてたから、
そういうもんでもないっていうことにちょっと自分のマインドを調整したっていうような背景がありました。
採用プロセスの違い
ken
やっぱり英語でジョブマーケットがあった方が日本語のエンジニア史上より、
キャンディデートも多いから結構スルッと入ってきたりするんですよね。
お金があってちゃんと伸びてるスタートアップすると。
だから一人が頑張っていろんなハットを被らなくていいみたいな、
そういうのもあると思うんで、それは間違いない大きなカルチャーギャップですよね。
Kazuki Higashiguchi
そうですね、まさしくで。
採用に関連するのが3つ目で、採用の仕方も違うなと。
どう違ったんですか?
学んだって感じですね。
結構僕はベースの時にも採用とかしたんですけど、
あまり形式的なフォーマライズされた方法を取ってなかったなと思っていて、
割とレジュメを見て、ちょっと気になったところを深掘りしながら、
割とちょっと俗人性のあるような評価の結果として採用を決めるみたいな形があったなと思っていて、
逆にこっちだともうジョブディスクリプションは明確に書いて、
評価のインタビューの形式もおおむね89割決まっていて、
それに対しておおむね誰がやってもスキルのあるエンジニア、
スキルのある採用、経験のあるエンジニアであればできるし、
っていうのが割と僕が最初採用に関わるようになってから、
エンジニアに採用に関わるようになってから、
結構全く違う採用の仕方だなっていうので、
いろいろ調整をかけた、自分の方法論に調整をかけた、
そういうのがありましたね。
ken
なるほどね。
僕もかじった程度ですけど、
有名な話だとGoogleで言われていた面接が構造化面接と呼ばれていて、
結局誰がインタビュアに入ってもバイアスとかがないように、
ちゃんとスキルセット評価できるみたいなのが手法としてあるみたいですけど、
聞いた感じそれを目指しているような感じなのかなと思います。
Kazuki Higashiguchi
そういうような気がします。
そこまでやっぱりスタートアップでいろんなハットを被る仕事ではあるので、
結構評価はとはいってもばらつくっていうのがあると思うんですけど、
ただそれでもおおむねいろいろな方法論とかプロシジャーっていうものが、
かなり形式化されているっていうところが、
3つ目ちょっと面白い変化だったなと思っています。
ken
いいですね。そっかそっか。
結構カルチャーギャップもある中でも結構楽しんできたと。
なんかその入ってみて予想しなかったすごいポジティブなアップワード、
例えば英語環境を求めて入ったわけですよね。
あとは他に期待して入ったことはどういうところなのかな。
例えばオーティファイのビジネスなのか、
それともスタートアップのフェーズなのか、
それともいろんなハットを被るみたいなスタートアップで求められるエンジニアの姿なのか、
みたいなところがありますか。
Kazuki Higashiguchi
これはビジネスですね。
オーティファイ、僕がこれまで言及してなかったもう1個のメジャーなモチベーションは、
デベロッパー向けっていうかソフトウェアエンジニアリング業界向けのプロダクト、
ビジネスっていうものにかかってみたいなって思ったのが2つ目の大きなモチベーションで。
ken
詳しく聞いてみたい。
Kazuki Higashiguchi
自分、前職でいろいろ開発業務とかをしていく中で、
割と裏テーマを持っていろいろソフトウェア業のテクニックだったりとか、
ナレッジ、あるいは方法論に対して考えを深めていったりとか、
もっとこうした方がいいんじゃないかとか、
こういうアイデアをインストールすればチームは良くなるんじゃないかみたいなことをいろいろやってたんですね。
これはキーワードで言うとアジャイルだったりとかTDDだったりBDD、
その他技術的なところでもGoとかPHPとか様々あったんですけど、
最後のほうは割とベースに入ってから結構テストっていうものに結構強い興味があって、
テストへの情熱
Kazuki Higashiguchi
ベース入った時にはユニットテストを結構社内でも詳しい方になろうと思っていろいろ頑張っていたりとか、
そこから言い継いテストの受動化とかっていうようなものをいろいろやっていて、
こういうところにモチベーションを感じる人間だよなと思った時に、
このモチベーションを感じる先がオーテファイとかこういうソフトウェア業界向けのエンジニアの組織だと、
直でビジネスとマッチングしているよなと思ったんですよね。
いわゆると自分の興味関心がそのままビジネスだし顧客の関心だしっていうので、
かなりストレートに自分の価値貢献っていうところと興味がマッチするんじゃないかって思って、
それが大きなもう一個の理由ですね、オーテファイっていうものを選択した。
ken
じゃあもうこうパーフェクトマッチじゃないですか。
英語環境でも働きたいしテストに興味があって、そこで技術者向けのプロダクトみたいな。
そうなんだ。
Kazuki Higashiguchi
そうでしたね、思います。
僕がこのコントラクターで入ったのが2021年の8月とかだったんですけど、
その時もCEOの近澤さんが当時のツイッターで、
こういうアイディアを無限化してくれるコントラクターの方、副業の方を探してますみたいな感じで喋られてて、
じゃあ僕それ興味ありますってオーテファイをしてたんで、DMを送った時に結構その時も話が盛り上がった記憶があって、
近澤さんからのBDD、ATDDのプレゼンテーションをした人ですよねみたいな感じで認知していただいていて、
覚えてくれたんだ。
ちょうどその話してたんですよみたいなことをされていて、
結構そこで興味関心が近澤さんの見てる世界とかも面白いなと思ったし、結構マッチしてるなって思ったっていうのが、
結構大きな理由だった気がしますね。
ken
なんかその時の多分話は盛り上がったんでしょうね、科学反応みたいな感じで、お互いこうパッション持ってる領域が近いというか。
じゃあベースの時に戻りますけど、その時にテストに興味を持った時の話をちょっと聞いてみたくて、
なぜそのテストに興味を持ち始めたのか。
例えばユニットテストが少なかったことによって障害を出しているみたいな現状があったのか、
例えばその隙間領域として自分が貢献できそうな領域として原石を見つけた感じじゃないけど、
そこに可能性を見出したのか。
その当時のことを覚えている範囲で、なぜそこでテストに興味を持ち始めたのかっていう、
当時の東口さんのね、聞いてみたいんですけど覚えてますか。
Kazuki Higashiguchi
当時の僕は確かに23歳とかなんですよね、ベースに入社したのが。
新卒のEC-POSの会社を1年10ヶ月で辞めてベースに入っているので、
その時でいうと相当隙間をまず探していたっていうのはあります。
なんでかっていうと他のエンジニアがみんな一世代上だったんですよね。
30代前後とか、スタートアップなんで新卒でやってないっていうのもあって、
かなり若手の部類だったので、その中でプレゼンスを出すためには、
隙間、まだあんまり開拓されてないところがいるんじゃないかっていうことは漠然と考えていて、
その中でテストっていうものには入社前、ベースに入社前から興味があって、
これは結構品質があんまりテストされていない、
そういうプロダクトを頑張って品質を上げるみたいな仕事を結構していたので、
そのあった時に結構ユニットテストがあればなってすごい話してたんですね。
チーム1個、2個前の会社の同僚とかと。
なるほど。
で、実際ウェブサービスの会社にエンジニアとしてジョインして、
じゃあやっぱり当時22ぐらいの僕がユニットテストというものがあればと願っていたことは実践したいと思っていて、
ken
なるほどね。
Kazuki Higashiguchi
で、実際にベースの中で当時のあんまりテストっていう文化はなくて、
ほぼ主力のサービスのテストは多分なかったですよね、コードが。
だからそこから01でやるのは結構価値があるし、
あと僕ももう1個の何人か師匠が自分の中でいるんですけど、
クニットさんっていうPHPの業界でいろいろかつて今も活躍されている、
ちょっとその時の僕の中でレジェンド的な方がいて、
その方がTDDの勉強会をやります、TDD読書会しますみたいなので、
僕はその人レジェンドだと思ったんで、僕ちょっと勉強したいっす、お願いしますみたいな感じで。
弟子入りしたんですね。
はい、という感じで弟子させてもらったっていうのも背景になります。
ken
おお、そうなんだ。
ちょうどそのTDDの師匠も見つけて、それを導入できる可能性のある現場を見つけてと。
ちなみにユニットテストを書き始めるというのってTDDとしてのカルチャーを入れていくって、
運命の差の違いがあるかなと思うんですけど、
どういうステップで入れていったんですか?
というのも僕もテストって結構SREとして、
レジリエンシーを担保するための大事な手法の一つなんですよね。
ユニットテストから、インテグレーションテストから、
あとはマシンに立てていくテスト、何ていうんだろう、
エンドポイントを叩き入れてレスポンスチェックするみたいな、
そういういろいろなテスト手法があって、
それを適度に活用することでレジリエンシーを上げていくみたいな、
僕も好きなトピックの一つなんですけど、
その導入していった当時の過程、
まずはボトムアップでユニットテストを書き上げていったり、
あとTDDのナレッジシェアリングをしていったりとか、
どういう感じだったのかというのがすごい興味ありますね。
Kazuki Higashiguchi
はい。結構これは面白いトピック、
当時僕も面白いトピックだったんですけど、
TDDを、TDDは結局自分の中では自分の技能として落とし込んだっていうのが最終的な着地点で、
割とユニットテストを変えていくっていう意味では、
当時の戦略は使用化テストと日本で呼んでいて、
英語ではCharacteristic Testingかな、
っていうテストがないところにテストを書くことで、
既存の振る舞いをテストによって使用化するっていう技法、
いわゆるレガシーシステムにおける一つのリファクタリングテクニックがあるんですけど、
そこから始めたっていうのがメインで、
その中でテストのカバレッジを広めていく、
今ある既存のものに対してテストを変えていくっていうところからスタートしたっていうのが大きな流れで、
そういうことをやっていく中でテストのスキル、
テストの書き方っていうものに成熟していく中で、
自分の新しい開発においては最初からテストをまず書いて、
テストに対してコードを書き通し、リファクタリングをし、
DDDのサイクルを回していくっていうアプローチをスキルとして、
自分の開発のライフサイクルに入れ込んでいったっていうのが僕の中でアプローチでしたね。
BDDの実装と展望
ken
なるほど、そうか。デブサイクルの中にDDDを持ち込んでいって、
初期としてはその使用化テストを入れていったと。
確かに。それは僕もやりますね。聞いたことある。
テストがないところにいきなりテストを入れるときにどうするかというと、
まず既存のシステムの枠組みを壊さないようにテストを入れていくことで、
動き方も分かるし、システムの使用も分かるし、
それもドキュメント化されてナレッジシェアもできるし、一石二鳥ですよね。
Kazuki Higashiguchi
そうですね。特に自分のチームはペイメントの決済代行を触るチームだったので、
わりとワンミスで死ぬ世界だったんで、
ワンミスで死ぬ世界なのに、コントローラー、ケークPHPではMVCフレームワークなんですけど、
このコントローラーの行数は数千ぐらいいっちゃってるみたいな世界線だったんで、
ken
なかなか激しい。
Kazuki Higashiguchi
そうすると使用化テストのアプローチはわりとメイクセンスしてるというか、
そこからやっていくのは、同時にフレーキネステストのリスクはあるんですが、
それでもメリットはあったかなというところですね。
ken
なるほどね。すごいな。
後半のほうではOTIにおけるSREの話も聞きたいんですけど、
ベースにおける東口さんのテストみたいな文脈で言うと、
他に取り組まれたこととかキーワードとかあったりします?
Kazuki Higashiguchi
もう一つのキーワードは、TDDとかに関しては、
いろいろこのカンファレンスの登壇とかも含めてアウトプットをいろいろしたんですけど、
TDDからちょっと円を広くしてBDD、ATDD、いわゆるエンドツーエンドのテストも含めた
TDDライフサイクルを実装するような考え方にも興味が出始めて、
その興味はそのままアジャイルテスティングっていう、
アジャイルの中でいかにテストをうまくやっていくかざっくりとそういう感じのアイディアにも興味が出始めたんで、
結構ベースの晩年、ベース時代の僕の晩年はアジャイルテスティングをどうチームの中で実践できるかっていうことを考えてました。
ken
なるほど。BDDについてちょっと簡単に説明してもらってもいいですか?
TDDは僕本とか読んだり結構いろんなデベロッパーも聞いたことあるし、
BDDについてもキーワードを聞いたことあるんだけど、実際に実装するカルチャーに入れていくってどういうことなの?
っていうのはピンときてないんですけど、ぜひ教えてもらいたい。
Kazuki Higashiguchi
はい。これはBDD自体はフルマイク動化予発とか呼ばれていたり、いろんな呼び方があって、
Specification by Designって呼んでいる人もいれば、
Acceptance Test Driven Developmentって呼んでいる人もいたり、いろんな言葉がありますね。
僕はAcceptance Test Driven Developmentの考え方のアイディアを多く学んだので、
そこをベースにしゃべると、受け入れ条件をまず最初にテスト化して、
受け入れ条件のテストをまず大きなライフサイクル、開発のライフサイクルに入れることによって、
ちっちゃいTDDのライフサイクルを回しながら、
エンドツーエンドに受ける条件も自動的に満たしていることを常に検証し続けるっていうアイディアかな。
そういうアイディアで、
テクニカルなキーワードで言うとQCAMバーとか、
何があったかな。
当時はゲージっていう、今も多分元気だと思うんですけども、
いわゆるこの自然言語でテストのスペックを書いて、
その自然言語のスペックが通るようにテストの実装もして、
プロダクトの実装もして、
ken
っていうものをシームレスに行うっていうアイディア。
Kazuki Higashiguchi
そういうものをチームの開発のスプリントの中で入れれるかな、
みたいなことをいろいろ考えていたっていう。
ken
なるほど。だからそのアクセプタンテストを自然言語でいろんなツールを使って表現して、
そこを目指してチームのデブサイクルを回していこうみたいな考え方なのかな。
確かにTDDより広いというか。
それは面白いですね。
なんかテストの話だけでもまた一本別の収録してみたいですね。
Kazuki Higashiguchi
確かに。
テストはいろいろ考えていたからあれですね。
ここ10年来ぐらいの話だったらいろいろできる気がしますね。
ken
そうですよね。そこに情熱ある方がOtifyに入った、確かにそれは熱い話ですね。
SREの成り立ちと初期プロジェクト
ken
僕もSREなのでOtifyにおけるSREみたいな文脈でもちょっと詳しい話を聞いてみたいんですけども、
まずはSREじゃない仕事で入って中で仕事していったら、
それがSREっぽい仕事だよねということでジョブタイトルがついていたっていう話だったんですけど、
そこら辺のムーブは東口さんにとっては意識してやってたわけではないと思うんですけど、
SREになるならないみたいなのは自分の中で結構大きい話だったんですか、
それともやってたことやったらタイトルがついた、それが自分のタイトルではないみたいな。
どういう感情でSREを受け入れたのかな。
SREになるストーリーって結構人それぞれだと思うんですよね。
なりたくてなった人、結果としてなった人、やってたらそれがSREになった人、
いろいろいると思うんですけど、東口さんのSREストーリーはどうだったのかなと思って。
Kazuki Higashiguchi
僕は能動的なストーリーですね、ここは。
ken
おー、興味ある。いいですね。
Kazuki Higashiguchi
オーティファイの中でやっていた最初の開発っていうのが、
オーティファイコネクトっていう機能を当時作っていて、
これが技術的に何をしていたかっていうと、
お客さんがプライベートな環境で、ネットワークが厳しい環境だから、
パブリックにテストの環境を公開できない。
だからプライベートな通信網を作ってオーティファイと連携すれば、
社内ネットワーク内のテストシステムをテストできますよっていう機能を実装するために、
Layer7 HTTP上で双方向のコネクションをトンネルを作って、
そこでテストリクエストをオーティファイから投げるっていう、
そういうネットワークアーキテクチャを実現するっていう、
インフラ的にも結構いろいろ代々的で、アーキテクチャもこびっていて、
かつユーザーインターフェースも結構いろんなとこ触んなきゃいけない。
でもエンジニアリングリソース僕一人が向上的に割り当てられてるっていう状況だったんですよ。
ken
なかなかチャレンジ面白そうですね。
Kazuki Higashiguchi
なかなかプロジェクトモニュメントとかチャレンジがあったんですけど、
その中で何がスケーラブルにマンパワーを投入できて、
何ができないかって考えたときに、
マンパワーが投入できるのはわりとユーザーインターフェースに近い開発だったら、
他のちょっと興味があるから手伝ってみたいっていう、
ボランティアしてくれるエンジニアの人にもちょっと手伝ってもらえるし、
他のコントラクターの力も限るしって考えたときに、
自分じゃないと厳しいっていうところはどこかって考えると、
オペレーショナルの部分、いわゆるこの運用をどうやっていくかとか、
オブザーバビティをどう設計していくか、
デプロイメントファイプラインの変え方も難しかったんで、
そういう込み入った部分、
自分じゃないとちょっと厳しいなっていうところにフォーカスしていった結果、
わりとSREがやるようなDevOpsだったりとか、
オブザーバビティ、プロダクションを見据えた設計とか、
そういうところに焦点が当たっていって、
最終的に最後の方でやっていたのは、
するとデプロイメントをどう安全に作り切れるかっていうことをやっていたっていう背景があるんですよね。
そこで自分は、これはなんかちょっとバッケージなくなってきたなってタイミングで、
SREというロールに明確に変えたいとマネージャーに言って、
いろいろな議論の結果、当時SREチームの中にバジェットがなかったんで、
じゃあ開発チームの中でM.NET SREという形でやりましょうという風に、
ロール名を変えてもらって、いろいろあってバジェットができて、
SREチームにジョインしたっていう労働的なアプローチで変わってます。
現在のSREチームの構成
Kazuki Higashiguchi
熱いな、僕そういう話めっちゃ好きですね。
ken
労働的に動いて周りを変えてって実現したみたいなストーリーすごい好きですね。
当時、そうか、別にSREチームはあって、まずはEmbedded SREになったっていう話なんですね。
Kazuki Higashiguchi
そうですね。
ken
なるほどなるほど。
で、今はSREチームの方に入ったということなんですね。
Kazuki Higashiguchi
そうです。
ken
今のSREチームの形とか業務内容ってどういう形なのか聞いてみてもいいですか。
例えばSREと一口によっても、1000人規模の会社のSREと、
150人規模のスタートアップのSREと結構やってることが違ったりして、
すごいガリガリ行動を書くことが求められるSREも教科書通りいれば、
あとはインシデントマネジメントばっかりやってるようなSREもいれば、
あとはDevOpsとかプラットフォームエンジニアリングチームが別にいるところは結構レジリエンシーにフォーカスできるけれども、
意外とそのプラットフォームエンジニアリングとかオブザーバブリティエンジニアリングもまとめてやってますみたいなところもあると思うんですけど、
今の現状における2025年、夏前におけるSREのメンバー人数とかやってることってどんな感じですか。
Kazuki Higashiguchi
今のSREチームのメンバーは150人の組織、大体150人の組織体に対して、
今ICが2人、マネージャーが1人って3人体制ですね。
で、やっていて横断的に複数プロダクトがあるんですけど、横断的にプロダクトに関わっていくっていう関わり方をしています。
それぞれのプロダクトに対してエンジニアリングチームがある状態で、やってることとしては幅広い幅広くて、
いわゆる今のメジャーのプロダクト、ノーコードウェブっていうノーコードE2E鉄道とかプラットフォームがあるんですけど、
それはKubernetes上で動いているので、EKSで動いているKubernetesのクラスターアドミニストレーターをしていたり、
あとはクラウドのアドミニス自体もやってますね。
そういうアドミニス的な側面もあれば、
オブザーバビリティの設計実装、いわゆるこういう風にロギングをしていこう、こういう風にメトリックストレースを出していこうっていうアイディアの設計と提案、
あとはそれをインストラメントしていくっていうようなオブザーバビリティを手を動かすっていうのもあります。
インシデントハンドリングで言うと、これはみんながオンコールローテーションに入ってます。
これはつまり全エンジニアですね。
全エンジニアがタイヤ、服装の中に入っていて、
SREはインフラスペシフィックでめちゃめちゃインフラだわって時に、
ダイレクトにインストラクションする時あるんですけど、
基本的にはみんながオンコールを見ていって、
その中のパートとしてSREもやっているというような形でやってます。
今後の技術的な興味
ken
なるほど。いいですね。
なんかいろんなことやってて楽しそう。
プラットフォーム、アドミニス的なこともやりつつ、オブザーバビリティにも口を出せるということで。
その中でレジリエンシーという文脈で言うと、
本当に今挙げてくれたようにセキュリティとかアドミン権限とかロギングオブザーバビリティ、
インシデントマネジメントいろいろありますけれども、
東口さんが例えばいろんなスキルセットが求められる中で、
例えば特定の領域に興味があったりするのか、
それとも幅広く大きなアンブレラの中でSREを楽しんでいるのか、
例えばオブザーバビリティちょっと磨いていきたいんだよね、みたいなのがあるのか。
さっき言ってたけど、デプロイメントパイプラインちょっと頑張った時期があるって言ってたので、
そこら辺に興味があるであったり、現時点で何かあったりしますか。
Kazuki Higashiguchi
現時点での興味で言うと、割と今2025年5月9日時点だと、
Kubernetes Cloud Nativeの技術には個人的に興味があって、
これは何でかというと、6月にクラウドコン、キューベコン、ジャパン2025があって、
そこに参加するっていうのがあって、
そこに向けていろいろCKA、Certificated Kubernetes Administratorの資格を勉強していたりとかするっていうのがあるので、
個人的な技術の興味はそこにあります。
ビジネス的とかいろいろ会社との要求の兼ね合いの中でと言うと2つあって、
1つが今の昨今のLLM AIの中で、
LLM in Productionって言うんですかね、
本番環境でLLMをどう付き合っていくか、
あるいはセルフホスティックなアプローチも含めてどうSRとして貢献できるか、
そういうのは今進行形でいろいろ考えていて、
2つ目は結構インキュベーター後、いわゆるプロダクションに出す前っていうところにも関わっていくことが増えてきたので、
その中でどのように何を優先順位をつけてやるべきか、
いわゆるアラーティング、モニタリング、デプロイメントオートメーション、
そういったのに対する優先順位をどう考えるべきか、
どうビジネスバリューを考えるかっていうところも最近は考えることが多いです。
ken
それ2つともどっちも大事ですよね。
ちょっと2つ目の方をピックしてフォローアップクエスチョンしてみたいんですけど、
例えばそのSREのなってしまうアンチパターンとしてよく言われるのが、
SREはゲートキーパーになっちゃったみたいなケースがあったりして、
ゲートキーパーっていうのは例えば開発チームからすると、
今からローンチするぞ、デッドラインも迫ってて、
俺らもこういうの作ったからよし出すぞって時になんかのこのこ現れてきて、
いやこれちょっとこういうスケールしないよねとか、
なんかコストすごいやってるよねみたいなゲートキーパーになっちゃうみたいなパターンもある中で、
そこの優先順位の決め方ってめちゃくちゃ難しいと思うんですよね。
やろうと思えばやることで無限じゃないですか。
レジリエンシーにおいてやることは消えないので、
優先順位ってチームとして、もしくは東口さん自身の中でもいいんだけど、
その3人チームをどうやって決めてますかね。
じゃあインキュベーションからプロダクションローンチするぞ、
いろいろやることがあるよね。
プロダクションレディネスチェックリストでも何でもいいですけど、
チェックリストがあった時に、
これとこれとこれはやってからプロダクションローンチしなきゃいけないみたいなそこの決め付けっていうのは
SREが経験を元に優先順位をつけてますか。
その優先順位のつけ方という観点で言うと今どういう動き方になってますかね。
Kazuki Higashiguchi
これはもう今まさにどうしようかなと思ってるトピックであるんですけど、
結構今現時点では正直リアクティブになっていて、
特にエンジニアルUチームとSREチームは別のチームの中でやってるので、
チーム間コラボレーションの中で優先順位とかを決めていくっていうことを考えると、
実際にあったこととしてはそこまだできてなかったんだっけみたいなことが結構あるんですよね。
分かる分かる。
で、本番結構ギリギリでそれをキャッチアップして、
やばいやらなきゃみたいなことがいくつか起きてきたので、
相当残念ながらリアクティブにこういうリスクが今起きているから、
このリスクプロブレムに対して対応しないとこういう問題が起きえるから対応しましょうっていう議論をSREチームの中ではするんですけど、
結構プロブレムオリエンティットになっているので、
TDD/BDDへの情熱
Kazuki Higashiguchi
いわゆるプロアクティブにこれをどうできるかっていうところはどうしようかなと思っているところです。
ken
そうですよね。結構難しいですよね。
特にチームが別でレポートラインが違ったりとかすると、
優先順位の決め方でどうしてもコンフリクトが起こったりとか調整が必要だったりするんで、
それはそうですよね。
かといって早いタイミングでSREが入ればいいかというとマンパワーの話もありますし、
起きてしまったことはしょうがないみたいな話もあったりするので。
そうなんですよね。面白いな。
1個目の話は僕も自身、LLMのプロダクションにおけるSREの話を僕自身も今学んでいるところだったりするので、
お互い知見が溜まったら別で収録したいなと思ってたりします。
Kazuki Higashiguchi
そうですね。いつか壁打ちしてもらいたいトピックではあります。
ken
同じくSRE仲間が増えて嬉しいです。
さっきもちらっと言ってましたけど、
カンファレンスに参加されるって言ってましたけど、これがあれですか?ライトニングトークされるやつ。
Kazuki Higashiguchi
そうです。
ken
結構もう50分くらい話してきたので、そろそろクロージングに向かおうと思うんですけど、最後にその宣伝をしてもらっていいですか?
Kazuki Higashiguchi
はい。このライトニングトーク自体はアクセプトしてもらったというので非常にありがたいんですけど、
僕のメインの宣伝としては友達を募集中という感じですと。
何かというと、6月ですね。
キベコン、クラウドネイティブコン、ノンジャパン2025、初の日本の開催のこのカンファレンスに今回参加してますので、
もしこのリスナーの方で、私も僕も参加するよっていう方でいたら、ぜひ東口に声をかけてもらいたいっていう宣伝になります。
僕がちょっと人見知りなので、結構自分から声かけられないっていう属性がありまして、
ライトニングトークの、トワイトメインのところでやると思うので、そこでちょっと顔を覚えてもらえれば、
こんにちは、だけでいいんで、ちょっと話していけたらなと思ってます。
ken
はい、ぜひその宣伝をお手伝いさせてくださいということで。
じゃあライトニングトークの中、リストみたいなの出てるんですか?そこで東口っていうのを探せばOK?
Kazuki Higashiguchi
確かに、そうですね。
トピックは、Production Monitoring for Knative Servingだったかな。
そういうタイトルだった気がします。
KnativeというCNCFプロジェクトのエンドユーザーとして、どうモニタリングアラートするかみたいな5分間のライトニングトークするので、
カンファレンスでの発表
Kazuki Higashiguchi
ぜひぜひ来てくださいっていう感じがします。
ken
素晴らしい、じゃあぜひショーノートの方にも連絡先とかね、後で聞くので貼らせていただきます。
これを聞いて東口さんとテストの話をしたい、オーティファイルの話をしたい、何でもいいですけど、
温泉合宿の話聞きたいみたいな方はぜひちょっと話しかけてみてください。
Kazuki Higashiguchi
ぜひぜひ。
ken
いや、そんなところかな。
初回ということなんで、いつもの例にならって、まずいろいろ幅広いトピックを話してもらって、
また2回目3回目来てもらって深掘りしていきたいなと思うんですけど、最後に言い残したこととかあったりしますか。
Kazuki Higashiguchi
言い残したことか。
このロンドテックトークのポッドキャストはずっと聞いていたので、出演できて超ハッピーです。ありがとうございました。
ken
めちゃくちゃ嬉しいですね。
聞き始めてくれたのはなんか育休の時からでしたっけ?
Kazuki Higashiguchi
そうですね。2024年の育休のタイミングで、ポッドキャストということ自体を聞き始めて、その中で聞きました。
ken
わかる。耳から入ってくる情報、インプット、貴重なんですよね。子供抱っこしてるときとかね。
Kazuki Higashiguchi
そうなんですよね。1時間2時間ずっと抱っこしながら寝かしつけてるときに、耳だけしかアベイラブルではないという状況が非常に多かったので。
ken
そうそうそうそう。意外とKindleとかでも片手がつったりとかすごい。うわー懐かしいですね。
Kazuki Higashiguchi
そうなんですよね。暗いから画面をつけるだけでもちょっとビクビクしてしまうという状況だった。
ken
わかるー。大きいちゃうんですよね。
いやー、ということでパパトークもゆくゆくはできるということで、東口さんが今回はコーチさんと川崎君の知り合いで入ってきてくれて嬉しいです。
引き続きまた収録にお呼びしたいと思いますが、本日は東口さんをお呼びしてキャリアの変遷だったりオーティファイにおけるSREの話やテストの話をしてきました。
今日はありがとうございました。
Kazuki Higashiguchi
ありがとうございました。
