こんにちは、CTO の 
id:motemen です。
Hatena Developer Blogの連載企画「卒業生訪問インタビュー」では、創業からはてなの開発に関わってきた取締役の 
id:onishi、CTOの id:motemen、エンジニアリングマネージャーの 
id:onkが、いま会いたい元はてなスタッフを訪問してお話を伺っていきます。
id:motemen が担当する第17回のゲストは、採用管理システム「HERP Hire」などの開発・提供で知られる株式会社HERPでエンジニアリング領域 統括として活躍している 
id:taketo957さんこと、佐々木健人さんです。
id:taketo957 さんは、京都大学大学院情報学研究科を修了後、2016年に新卒で株式会社はてなに入社。SREとして、はてなのtoCサービスの運用や構築を中心に、在籍した5年間で、さまざまなプロジェクトで貢献いただきました。
はてな卒業後の2021年に株式会社HERPにSREとしてご入社され、2024年からは技術関連の責任を負う役割でもある、エンジニア組織のトップ（Head of Engineering）としてご活躍されています。
今回はid:taketo957さんに、HERPさんでのこれまでの取り組みや、現在の「統括」としてのお仕事や考え方について、お話をお伺いしました。
佐々木健人さん（
2016年4月～2021年7月 はてな在籍
X：https://x.com/taketo957
Blog：https://taketo957.hatenablog.com/
HERPの事業とtaketoさんの現在の役割
id:motemen（以下、） お会いしたいと思ってたので嬉しいです。本日は色々聞かせてください！よろしくお願いします。
id:taketo957（以下、）ありがとうございます！僕もお話できるのを楽しみにしてきました。よろしくお願いします。
id:taketo957 こと、株式会社HERP 佐々木健人さん: 24年10月に公開された、エンジニアリング組織の立ち上げと、taketoさんのリーダー就任についての記事を拝見しました。
このプロセスについても聞いてみたいですし、就任から1年半経過した現在の取り組みについてもお伺いしていけたらなと思ってます。
最近のtaketoさんの話に入る前に、HERPさんについて教えてください。ATS（採用管理システム）である「HERP Hire」のほかにも、いろいろなプロダクトを展開していっているという記事も拝見してます。
真のユーザーファーストが、日本にはまだなかったのでは？──HERP庄田氏の、“人生の時間”を解き放つコンパウンドHR戦略 | FastGrow
: ありがとうございます。HERPは、HRテックの中でも特に採用という領域にフォーカスしたさまざまなサービスを提供している会社です。一番初めはATSである「HERP Hire」の提供から始まって、いまではさまざまな企業さまに使っていただけるようになりました。
最近は、これまでATSで使ってきたリソースや顧客基盤を使い、採用市場全体を動かしていこう、ということを掲げて、新たにエージェント向けのサービスや求職者向けのサービスを展開しています。
採用市場は、お金を持っている企業と、転職のタイミングでしか市場に出てこない求職者という、構造的に不均衡がある業界です。そのため、企業向けの体験が重視されがちですが、会社としてはそもそも“求職者に選ばれるサービス”でないと本質的な価値を提供できないと考えており、市場全体を変えていくためには求職者にもサービスを提供していく必要がある、という考えをもっています。そうした背景があり、サービスの拡大や、新サービスの企画が動いている状況ですね。
HERPのことを知りたいすべての方へ より引用
: いまHERPさんには、エンジニアは何名くらいいらっしゃるんですか？
: 正社員でちょうど30名です。直近で4人ぐらい一気に入社してくれて、30名になりました。
: 単一プロダクトだったところから、色々なプロダクトを増やしていて、エンジニア組織も成長中ということですね。そんななかで、いまはエンジニア組織の統括を担当されているということで。やることが色々ありそうだ（笑）
:めちゃくちゃあります（笑）
: 役割としては「CTO」や「技術責任者」というイメージで良いでしょうか？
: そうですね、役職としては置いていないのですが、そう言い換えても問題ないとは思います。現場のエンジニアリング全体に責任を持ってやる役割という感じです。エンジニアがたくさんいて、その最終的な責任や権限を持っている人、というロールです。
:エンジニアリング組織を作ったことが、今のロールになるきっかけのひとつになったと聞いてます。先ほどの記事にあったエンジニアリング組織の成り立ちの話も改めてお聞かせいただいてもいいですか？
: HERPは経営陣3名全員が技術的なバックグラウンドがない面々で、創業以来、ずっとビジネス的な意思決定を優先してきたところがありました。ユーザーの要望に基づいてサービスの増改築を繰り返していると、技術的・プロダクト的に色々な不具合が出てきますよね。それが、ユーザーの要望に応えられないレベルで、可用性やリリース速度に影響が出てくるようになったのが、いまから2年ほど前です。
経営陣もそこを認識していたと思いますが、「さすがに技術的な部分に対して、経営レベルで打ち手を考えられるようにしていかないといけない」という話があったんだと思います。そこに対して、ボトムアップで「色々な課題があるけど、本当のボトルネックはエンジニアが組織立って動けてないことだ」という課題感を持ったエンジニアが自分ともう2人いたんです。
その3人で「三角会議」という名前の場を立ち上げ、技術的な決め事をできるようにしていこう、と。トップダウンの課題感とボトムアップの取り組みが合流して、ちゃんと組織を作ろう、という流れになったのが、組織発足のきっかけです。
: その三角会議が種になって技術組織が作られていったのですね。
: そうですね、種になった感じです。最初は、その3人に色々な権限を渡すから、まずは経営陣との橋渡し役になってくれ、という期待をもらっていました。ただ、それだけだと上手く回らない部分もあったので、やっぱり最終的に責任を取る人が1人必要だ、という話になった時に、社長から僕に「やってほしい」というコミュニケーションがあって、「やってみます」と直接伝えたのが、このポジションに就くことになった経緯です。
: 面白いですね。その三角会議のメンバーはどのようなバックグラウンドの方々だったのですか？
: 僕はインフラやDevOpsなど、プロダクト開発以外の部分に目が回る立ち位置で参加していました。もう1人が、本当にプロダクト開発をゴリゴリやる人。もう1人は、どちらかというとエンジニアリングマネージャー的な組織作りに強い人でした。その3人でバランス良く、色々な部分の課題を見ていました。
: 確かに、バランスが良さそう。課題感を持っていて、自ら動く側の人たちだったと。そういう人たちが集まって、エンジニア領域全体の課題を見つけ、取り組んでいったのですね。
: そうですね、最初はそういうかたちでスタートしました。
: 少人数でちゃんと見れるのはいいですね。対等な立場で話せる3人だった、という感じでしょうか。
: はい、本当に対等に話せますし、今もその2人とは色々な話をすることが多いです。
:その三角会議のメンバーのなかから、teketoさんが適任だということでリーダーを任されたそうですね。技術責任者は昔からいるエンジニアや創業者がなることが多いイメージもあるので、経緯に関心があります。
: 代表の庄田が人としての成熟度というのを重視していて、その人間的な部分を評価していただいたのが一つです。あとは、創業メンバーは全員新卒で入社しているため、尖った技術選定になった部分もあると思いますが（笑）、経営陣の一人が他社の経験を重視したい、と言っていたのを耳にしたことがあります。
: なるほど。それは確かに重要ですね。自分も新卒でずっとはてなにいるので、それってどうしようもないんですよね。だからこそ、外から来てくれた中途の方に色々と教えてもらったり、感覚を聞くことがあります。そういう経験的なバックグラウンドと、信頼できる人間的な部分を兼ね備えていたのですね。
: 自分で言うのは少し恥ずかしいですが。
: でも実際そうだったのでしょう。その三角会議では、どんなことから始めたんですか？
: まずは色々な課題を明らかにすることからやっていきました。あとは、技術選定が昔から大きな課題であり続けていたので、一つの方針をちゃんと決めよう、ということをやりました。フレームワークやライブラリに、HaskellやCycle.js、fp-tsなどの関数型プログラミングの技術や概念が使われていて、作るのはいけても本番運用が大変な状態でした。
あとは、障害やパフォーマンスの問題、リリース速度の遅さといった、本当の要因が何なのかを3人で考えていったりしてました。
技術部門の現状と課題
:現在の開発体制としては、エンジニアだけの組織ではなく、プロダクト開発チームと横断チームがある、という感じでしょうか？
: 組織的な話からいくと、事業側のチームが複数と、それを横串で見る横断チームが複数ある形になっています。事業部の箱は大きく3つあって、横断組織は、インフラ・DevOpsを見るチーム、技術的な全体方針を考えるためのチーム、そして最近作り変えた、データを直接売上に繋げるためのチームがあります。これはKPIとして売上への貢献を持ってもらい、データ基盤やデータサイエンスを駆使して色々やってもらうチームですね。今後の目標や計画を考えた時に、これが良いだろうと思って作ってみましたが、まだどうなるかわからない（笑）
: 研究開発のチームなんですね。taketoさんは横断組織だけを見ているわけではないんですか？
: 責任的には全部自分に集約されていますが、実際のところは、横断チームの全体的な技術方針を考えることにフォーカスしています。あとは、各事業部のEMとコミュニケーションしながら、事業の方針と連携して組み立てています。
: 横断組織にうまく動いてもらって、事業チームともコミュニケーションしていくイメージでしょうか？
: そうですね。直近は事業チームの人たちにも、かなり色々やってもらっています。事業的な都合だけでなく、記事にもあったように、技術的負債の話なども具体的に動いてもらう必要があるので、事業的な部分とかなり連携しながら進めています。
: チーム主導で技術的負債の返済ができるようになったという話が面白いなと思っていました。それってなかなか難しいことですよね。
: ここまでで、いくつかターニングポイントがあったと思います。明確なトリガーが何だったのかは正直僕もよくわかっていないのですが、まず、技術的負債によって様々な影響が出ていた、という現象がありました。
ただ、僕らが三角会議で色々な問題を可視化した時に、ATSという基幹事業の技術的負債が、無視できない大きな問題である、と可視化できたことはきっかけのひとつだったかなと思います。
あと、僕がこのポジションに就いた時に、エンジニアのリソースがどういう活動に投入されているかについても可視化したんです。短期・中期・長期の時間軸に、売上を伸ばすための取り組み・マイナスをゼロにするための取り組み、という2軸でプロットしてみました。そうしたら、明らかに短期的に売上を積む領域に偏っていて、マイナスをゼロにする取り組みに投資が足りていないことが明らかになったんです。こうして現状について可視化したことが、いい方向に変化するきっかけになったんじゃないかと思ってます。
あとはICU（集中治療室）という取り組みです。事業責任者に「週にこのぐらいの時間をください」と言って、その時間のなかでエンジニアが課題を改善していく。小さいものからどんどんやっていきました。そこで「色々直したい」と思っていたエンジニアのやる気がかなり高まって、事業責任者もその変化を感じてくれたのかなと。
一番面白かったのは、社内のエンジニアの声で「最近は本当に開発をしているという実感がある」と言われるようになったことです。
: いいですね。
: 機能開発の要望に応えるだけでなく、色々な部分を直すということを繰り返していくうちに、そういう声が上がるようになりました。
その時に、基幹事業の技術責任者的な人が「目標に入れます」と言ってくれて、事業責任者もすんなり分かってくれたんです。色々なものの積み重ねで、そうなっていったのかなと思います。
: 何かひとつのプレゼンで全部が変わる、というのではなく、皆が「このやり方ならうまくいく」と実感できた、変化を積み重ねていったのですね。現場のエンジニアは技術的負債を肌で感じていると思いますが、それにフォーカスできていない現状を、ちゃんと経営陣とコミュニケーションしたのが、taketoさんの仕事だった、と。
はてなは創業者も今の社長もエンジニアだったりして、ここはかなりイージーモードだろうなと自分では思っているんで。そういうコミュニケーションができる人はすごいなと思ってます。
: いやいや、そういう意味では、はてなもすごかったと思いますね。そういうコミュニケーションがなくても、みんなが自然と取り組むという空気やカルチャーがあったな、と感じてます。
: そう言ってもらえると嬉しいです。先ほどの「本当に開発をしている」という実感は、エンジニアがタスクやシステムに対してオーナーシップを持てるようになった、ということなのかなと。システムに継ぎ足すだけでなく、システムを可愛がりながら育てていくムードになれたというのは、すごいポジティブな変化ですね。
: そうですね。明確にエンジニアの無力感が漂っていたわけではないですが、「これ、どうするの？」みたいな部分が少しあって、そこに対してちゃんと動けるようになった時に、エンジニアの雰囲気が全体的に明るくなった、という変化が明確にありました。
: これはいいなぁ。やりがいがありますね。エンジニアだけの仕事ではなく、コミュニケーションで組織全体の雰囲気を変えていく仕事ですね。
: はい。色々な人が種をまいてくれて、それが最終的に繋がった、という感じなので、気持ちいい体験ではあったけど、みんなの力だと思います。一人ではできないですからね。
プロダクトの多角化と技術的課題
: 基幹システムの話に加えて、会社としてプロダクトの数が増えていったことによる変化も大きかったと想像していますが、技術的・組織的な面での変化はありましたか？
: そうですね。僕が入社してからしばらくの間は、ATS一本で、ターゲットをスタートアップ企業に絞って、それをどんどんエンタープライズに広げていく戦略を取っていました。そこから、もっと大きな会社の成長を目指したい、という話や、代表の考えでもある、求職者の体験価値を高めることによって、求職者優位の採用市場に変えていきたい、という思いもあって、プロダクトを増やしていきました。
: 新しいプロダクトを作ったり、M&Aもしましたよね。そこから出てきた技術的な課題はありましたか？自分は急速な成長とか、横展開とか、経験したことないので、どういう感じなのかなぁと思って。
: 買収する前にデューデリジェンスをやるのですが、新しく買ったプロダクトが社内の標準技術から大きくかけ離れているものだったんです。気にはなりつつ、動かしてはいけるだろうと判断したのですが、やはり、特定のスキルを持った人たちで動かしていくことを考えると、社内で技術的に浮いてしまう存在の扱いがかなり難しいな、というのは、受け入れてから改めて感じています。
: 完全に同一にはできないし、難しいですよね。はてなも、今は需要によって技術がバラバラになっていると思いますが、どこまで統一して、どこまで分散させるかのバランス感覚が難しそうです。大きなものや重要なものに関しては、全部変えるなんて無理な話ですし。
: 難しい課題ですよね。ただ、前提として、事業が伸びているのは大事だな、とM&Aを通じて思いました。社内のエンジニアに開発や運用を任せる時、事業が伸びているだけで面白みが出てきます。社内の標準から離れていると、キャリアパス的にメインストリームから外れてしまう、という育成的な観点で見ると課題があるのですが、事業が伸びていると、その面白さでそこをクリアできるんだな、という気づきがありました。
: 事業が伸びて、数字が伸びているのが一番良いのは間違いないですね。技術的には多様性があった方が、本人の成長にもなるし、前のチームの良かった点を別のチームに持ち込む、といったこともできるので、ある程度の変化はあった方が良いのでしょうけど、バランスは難しいですね。
いろんな成長や変化に合わせて出てくる問題や課題に向き合っているということだと思うんですが、いまエンジニア組織として優先していることでいうと何になるんですか？
: 重要な課題をいくつか掲げていますが、一つ目は、やはり開発生産性ですね。具体的な中身はFour Keysなどを参考にしていますが、これに主体的に向き合って、開発責任者と事業責任者がコミュニケーションをとりながら色々決めていけるようにすることです。
もう一つは、事業的な成長を果たすために、toBが得意な会社であるHERPが、toCサービスをどんどん作れるようになることです。toBは目の前のユーザーの要望を聞いてサービスを組み立てますが、toCは「作りたいもの」があって、まず出してみて初めてわかる、という部分が大きいと感じています。はてなでの経験を改めて振り返ってそう思いました。
現状、HERPはセキュリティを重視しているので、インフラを含めて全体的にかっちりした作りになっています。そこで、toC領域向けに規制緩和したような区間を作り、サービスをどんどん出せるようにしたいです。素早くAWSアカウントを発行し、インフラをすぐに立ち上げて、気軽に実験的なサービスを載せ、いらなくなったらすぐ畳めるようなデプロイパイプライン込みのインフラを、今作っているところです。
: おもしろそう。考え方がだいぶ変わりますよね。人材情報を扱っている事業という緊張感はかなりありますよね。法律的な規制も多いですし。気軽に試せる環境がないと、なかなか新しいものも作れませんよね。
技術や事業の変化とメンタリティ
: toCとtoBの違い、おもしろいですね。 taketoさん個人としては、はてなからHERPさんに移って、技術的にも事業的にも大きく変化があったわけですよね。
: そうですね、そこのギャップにはかなり苦しみました。
はてなから転職しようと思ったきっかけの一つに、toBをやってみたいという理由があったのですが、飛び込んでみたら、ものの考え方や、大事にする部分、ものの作り方といった点でのtoCとの違いに、最初はかなり苦しみました。はてなは今はtoBサービスが増えていますが、僕はtoCの領域を担当していたので。
toCは比較的プロダクトアウト的なものの作り方をしますが、toBではマーケットインという考え方が求められたりします。また、toCでは多くの顧客に使ってもらうことが重視されますが、toBでは1リクエストを大事にしたり、セキュリティを重視したりします。そうした違いから、日々の技術的な意思決定で「自分がtoC出身の人間なんだな」と思い知らされることが多かったです。入社した当時は「それ、本当にいる？」というような反応をもらっていた気がします。
: なにをやろうとして「それいる？」みたいなフィードバックをもらったんですか？
:例えば、SLOの設定などです。サービスにSLOを設定しようとしたときに、レスポンス速度を重視したんです。当時は「1秒でも速くして、ユーザー体験を良くすることが一番重要だ」と考えていましたし、最初に出した改善提案も、そういうものが多かったと思います。
もちろん今でもレスポンス速度は大事だとは思ってますが、業務フローにシステムを組み込むような顧客にとっては、「確実に、安全に動き続けること」のほうが圧倒的に重要なんですよね。
いかにして安心して契約できる状態を作るか、そちらのほうが大切だと気付くまでに、少し時間がかかってしまいました。
: でも、事業の構造がシステムに影響を与えるのを感じられるのは、すごく面白い体験だろうなと思いますね。自分も学生でサービスを作っていたところから、延長でtoCをやっている会社であるはてなに入った、という感じなので。最初のころは、自分が思うように作ったらいいだろう、という感覚から抜け出せていない部分はあったな、と思っています。事業の環境が変わるのを体験するのは、すごく良いですね。taketoさんも言ってくれている通り、はてなも最近はtoBのビジネスがかなり増えて、サービスの作り方も変わってきたなと思います。
: そうですよね。
: あとは、技術責任者になって、社長と話す機会が増えたり、責任や期待も変わってきたと思うのですが、その変化にどうキャッチアップしていきましたか？
: 今もまだキャッチアップ中ですね。ビジネスや事業に関する知識はまだ勉強中です。記事にもあったのですが、社内勉強会「戦略筋トレ塾」というものに参加しています。これは、事業戦略を考えるための基礎的なリテラシーを身につけるための輪読会みたいなものです。事業責任者間で共通言語を作り、それを自分の事業にどう当てはめるかをアウトプットしてぶつけ合う場なのですが、事業責任者ではない僕も、技術責任者として毎回参加しています。そこで共通言語を作り、事業責任者が生で考えていることを理解することで、キャッチアップしている部分が多いと思います。
: それはすごく良いですね、うらやましいです。
: でも、めちゃくちゃ大変です（笑）。ペースも早いですし、自分の土台がないので、技術書を読むのとは全然速度感が違います。
: 強制的に成長させられる感じですね。でも、みんなで成長していくのは良いですね。エンジニアからはtaketoさんだけが出ているのですか？
: 今のフェーズでは、最初に経営陣だけでやって、その次に現場メンバーが入ったのですが、技術責任者である僕が一人だけ参加しています。今後は他のエンジニアにも誰か参加してもらおうかと考えているところです。
: どうですか？気持ちのうえでは、プレッシャーや孤独を感じることはありますか？
: 孤独はめちゃくちゃ感じますね（笑）
: あー、そうか...
: 「本当にこれでいいのだろうか」というのは常に考えてしまいます。あと、これ、書かなくてもいいんですけど、立場を得たことで、素直にコミュニケーションを取ってもらえなくなった、と感じることもあります。
メンタリティの部分でいうと、自分でも頑張ってますとアピールしたいときがあるんですけど、社長と飲んだ時に「色々頑張っているのはわかるけど、事業成果という視点で見たときに、その頑張りを主張することにどれだけの意味があるのか」と言われたことがあって。その時、「僕だけが頑張っているというのは、技術者全体で見るとどうでもいい話なんだな」と気づけたんです。社長にそう言ってもらえたことに感謝しています。組織がどう動いているか、どういう方向に向かっているかという部分に、ちゃんと目を向けられるようになったのが、メンタル的な部分でちょっとは成長できたかなと思えた部分かなと自分では思っています。まだまだ経営陣と対等に何かをする際に埋めなくてはいけないギャップはメンタル面でもスキル面でもたくさんあるんですが。
ここまで伺ってきたエンジニア組織の統括としての取り組みについては、taketoさん個人のブログでも最新のふりかえり記事が公開されているので、そちらもぜひご覧ください
taketo957.hatenablog.com
はてなで取り組んだプロジェクト
: はてなでの経験が今に活きていることはありますか？
: motemenさんとも関わった、サービスプラットフォームチームの前身で、データセンターからクラウドへ移行するなど、すごく大きくて複雑なものを正面からそのまま受け入れる経験は、今の組織を扱うマインドに役立っています。
また、はてなは「自分たちが作りたいものを作っている会社」だと感じていて、それが今HERPが必要としている部分だと自分では感じています。「はてなの時はこうだったな」と振り返って、参考になる部分がたくさんあります。
: そうなんだ、嬉しいです。
:自分でも、人を大事にしたいという考え方を持ってるんですが、はてなは技術者を育てることで事業を成長させ、技術そのものをビジネスにつなげることが明確な強みになっていると、出てから改めて思いました。そういう会社にしていきたい、という一つの目標になっています。
: ありがとうございます。いいこと言ってくれるじゃん（笑）
:あと、プロジェクトで言うと、非機能要件的な話を考える上でネイティブ広告配信サービスに関わっていた経験も、大きかったなと思います。
: 当時のはてなとしては異色のプロジェクトでしたよね。可用性が求められるし、toBで提供するシステムなので、あんまり公になってないかも。
:入社直後に関わったプロジェクトで、構築と負荷試験をひたすらやっていましたね。そこでいろいろ学ばせてもらったなと思って。いまだに結構覚えているし、すごく印象的です。
: 広告配信システムだから、結構な低レイテンシーが求められるってことで、Gatlingで負荷試験してましたよね。
:そうですね、あとは、オンプレから始まってた時なんで、結構構成も特殊だったはずなんですよね。今でこそ、確か、Kubernetesに移設してから転職したはずなんですけど。最初、オンプレで本当にUNIXドメインソケット使って、アプリケーションとDBとかRedis繋いでたみたいな記憶があって。
: めっちゃISUCONぽい（笑）
当時はアプリケーションエンジニアは
id:pokutunaさんで、SREの先輩としては
id:y_uukiさん？（参考：さくらインターネットで活躍中の id:y_uukiを訪問 | はてな卒業生訪問企画 [#9] - Hatena Developer Blog）
:そうです。当時は id:y_uuki さんや 
id:ichirin2501さん（さくらインターネット株式会社 西川元晃氏）には本当にいろんなことを学ばせてもらってました。pokutunaさんもほんとご一緒できてよかったですね。pokutunaさんって、すごく「ちゃんとしている」方で、仕事への姿勢が素晴らしく、安心して一緒に仕事をさせてもらえる方でした。先輩にこんな言い方していいのかわかんないんですけど（笑）サービスの仕様から僕らの領域まで、広い範囲に目が利くのに、極端な意思決定をすることなく、着実にものをつくり、周囲との連携もこなす方でした。
: 今もはてなのトップエンジニアとして活躍していますよ。広告領域を離れて、今は新サービス「toitta」のAIエンジニアをやっています。
: すごいですね！pokutunaさんだったのか！ああいう領域に強い方が入ってtoitta作ったのかと思っていました。
: そうなんです。
id:pokutuna と踊る taketoさん（2017年頃）いまのはてなはどう見える？
: いい話をいっぱい聞けてますが、逆に、はてなへの苦言やアドバイスはありませんか？
: 苦言はないですね。事業構造の変化なのか、toBの割合が増えているように外から見えます。M&Aなども含め、常に新しい変化をしているなと感じます。難しいなー。そうだなぁ、個人的にはMackerelが好きなので、頑張ってほしいなと思っています。いろんなことを学んだいま、Mackerelのことを振り返ると、toBならではのむずかしさもあるんだと思うんですが、頑張ってほしいです！
: はてな時代はエンジニアだったtaketoさんと、今の仕事について共通する話ができて、僕自身もすごく楽しかったです。
: 僕もこれをきっかけに、motemenさんに色々聞いてみたいことが生まれたので、またお話させていただけると嬉しいです。
: こちらこそ、勉強させてください。また話しましょう。
id:taketo957こと佐々木さん、ご協力ありがとうございました。次回の「はてな卒業生訪問企画」は2025年11月頃更新予定、担当はid:onkです。
id:motemen
大坪 弘尚（おおつぼ・ひろなお）
CTO（最高技術責任者）兼 サービスプラットフォーム部 部長
2008年、東京大学大学院情報理工学系研究科を中退後、アプリケーションエンジニアとして新卒入社。うごメモはてな、Mackerelなどのサービス開発に携わり、2012年より技術グループ チーフエンジニア、2016年に最高技術責任者に就任。
Twitter: @motemen
GitHub: motemen
blog: 詩と創作・思索のひろば
