はてなで働くエンジニアにアンケートシリーズ第13回は、ブックマークチームのWebアプリケーションエンジニア、id:itchynyに話を聞きました。
- はてなidはかぶらないように適当に付けた
- Haskellが得意な自分ならScalaも書けるだろうと思って
- チーム間で協力しながら新しいAPIの仕様を策定
- TLとして、チーム横断での依頼の窓口にも
- 夕方から深夜にかけて頭が冴える
- より戦略的にOSSへ貢献する体制作りをしたい
- スプリントごとに常に方法を改善
- 実装力を活かして良いシステム構成にできた時に手応えが
- 意思決定の過程を書き残すのは重要なこと
- 意欲がある人はいくらでも学べる会社
はてなidはかぶらないように適当に付けた
── Q1. はてなidとその由来を教えてください
id:itchyny (いちにぃ)です。本名ばれせず、かつかぶらないよう適当に付けたので、由来はありません。
Haskellが得意な自分ならScalaも書けるだろうと思って
── Q2. いつどんなきっかけで入社されましたか?
2015年4月に新卒で入社しました。当時、電子系や自動車関連の会社で就職先を探していたのですが、どの会社もなかなかフィットしませんでした。大学での専門(電子系、特に量子計算)よりも自分の得意なプログラミングを活かせる会社を探す中で、研究室の先輩のつてで紹介してもらいました。
サーバー監視サービス「Mackerel」がScalaを採用していることは知っていて、Haskellが得意な自分ならScalaも書けるだろうと思って入社しました。MackerelではScalaやGoを採用しており、どちらも入社してから覚えたのですが、今では(特にGoは)自分の最も得意な言語となっています。
チーム間で協力しながら新しいAPIの仕様を策定
── Q3. 現在の仕事を教えてください
入社以来4年ほどMackerelチームに所属していましたが、2019年8月にブックマークチームへ異動し、今は主にサーバーサイドのエンジニアをしています。
ブックマークで提供するスマートフォンアプリ用のAPIが、本体のリニューアルプロジェクトに伴う内部モデルの刷新に追従できておらず、老朽化していました。現在、スマートフォンアプリを担当するチームと協力して、APIを刷新するために既存のAPIの仕様調査と新しいAPIの仕様策定、実装を行っています。
また、現在ブックマークの各マイクロサービスのサーバーをAWSに移転しています。 アプリケーションのログ出力や定期実行する処理、監視などをクラウドネイティブな方法に書き換えながら、サーバーを移行する手伝いをしています。AWS CDKの採用によってインフラのコード化が進み、アプリケーションエンジニアでもインフラの設定を変更しやすくなりました。
TLとして、チーム横断での依頼の窓口にも
── Q. チーム内の立ち位置を教えてください
ブックマークチームのテックリード(TL)という立場で、主にWeb側のエンジニアを束ねるロールに就いています。各プロジェクトのタスクを管理し、エンジニア間の知見共有を促進しています。
他にも、スマートフォンアプリエンジニアと仕様の調整をしたり、SRE(Site Reliability Engineer)とAWS移転の相談をしたりしています。また、脆弱性への対応など、チームを横断した組織からの依頼を受ける窓口の役割も担っています。
夕方から深夜にかけて頭が冴える
── Q. 1日の仕事の流れを教えてください
朝はまずGitHubの通知を確認し、自分のOSSやwatchしているリポジトリのissueに返信します。その後は社内wikiの記事や自分に来ている連絡、1日の予定をチェックをしてから仕事を始めます。午前中はコードを書いていることが多いです。昼前にコードレビューを行います。
午後はまずチームの昼会から始まります。そこでは、進行中のタスクの状況確認や困っていることの相談などが行われます。
その後は実装の続きや次のスプリントのタスクの整理、リリースなどを行います。会議があると集中力が途切れがちなのですが、夕方から深夜にかけて頭が冴えるタイプなので、この時間が一番実装が進む時間だと思っています。
より戦略的にOSSへ貢献する体制作りをしたい
── Q. OSSとの向き合い方を教えてください
個人ではlightline.vimやgojqといったOSSを作ってメンテナンスしています。また、プロダクトで使っているOSS(jQuery、AngularJS、Goなど)のコントリビューションをしたこともあります。OSSに触れるのは好きです。
- jqのGo実装 gojq を作りました! ― スタックマシン型インタープリタによるイテレータセマンティクスの実装 - プログラムモグモグ
- lightline.vimがGitHub 5000スター達成 - プログラムモグモグ
- gojq が homebrew/core に入りました、他近況 - プログラムモグモグ
最近では企業とOSSのあり方、あるいは個人的なOSSとの付き合い方について考えています。会社として技術に関するアウトプットをしていく仕組み作りは、この開発者ブログのような形で整えられてきていますし、OSSコミュニティが主催する技術カンファレンスへのスポンサーやはてなブログの「OSSコミュニティ支援プログラム」などの形でOSSへの貢献に取り組んでいますが、一方で各エンジニアによるOSSへの貢献は個別で行われていると感じていて、もっとそれを良い形にできないかと考えています。
社内のSlackには #oss-guild というチャンネルがあって、OSSが好きなメンバーが集っています。:oss-chance:
() という絵文字もあって、Slackでの発言にこのemojiでリアクションすることにより #oss-guild に通知が流れます。このように間口を広げることで、OSSに貢献したいけど踏み出せない人を応援しています。
OSSに貢献するエンジニアが社内でもっと増えてほしいと思うと共に、ゆくゆくは企業として、より戦略的にOSSへ貢献できるような体制作りもしていきたいと思っています。
スプリントごとに常に方法を改善
── Q. 最近うまくいっていないことは何ですか?
先述したアプリ用APIの刷新プロジェクトでは、いろいろと新しい経験をしています。
依存のあるタスクをきちんと見抜けなかったり、技術的判断が遅れて実装タスクをブロックしてしまったりすることもありました。また、仕様の共有に不備があり、必要な処理が抜けたままリリースしてしまったことも。チームのスプリントごとにうまく進まなかったところを振り返り、常に方法を改善しています。
実装力を活かして良いシステム構成にできた時に手応えが
── Q. 最近うまくいったことは何ですか?
ブックマークチームでは内部をScalaで実装するリニューアルプロジェクトが完了し、新しい機能や、リニューアルに伴って優先順位を調整していたものを実装するフェーズに入っています。タグの一括編集機能はその1つです。ユーザーがタグを編集すると、関連するブックマークのインデックスを更新する必要がありますが、その数が大量にある場合もあるので同期的に行うことはできません。新しいシステムで実装されているドメインイベント(DDDの用語で、モデルに生じたイベント)を非同期に扱う処理はとても良くできていて、ブックマーク数が多いユーザーが編集しても、サーバーの負荷を制御できるようになっています。
最近は、社内でSRE(Site Reliability Engineering)のエラーバジェット(Error Budget、エラー予算)という考え方が浸透しつつあります。ブックマークチームでもSLO(Service Level Objective、サービスレベル目標)を順番に定義している途中です。
先日、不正なリクエストによってエラーレートが上がった際に、SLO基準を満たせないことを根拠として、スプリントタスクよりもエラーの対応を優先させる判断を行いました。エラーバジェットに基づく意思決定がこれからも増えていくと良いなと思っています。
また、AWS移転のために、アプリケーションを改修しなければならないことはよくあります。改修しなくてもworkaroundはあったのですが、ファイルシステムに状態を持っているアプリケーションを修正し、Amazon DynamoDBに状態を保存する実装を行いました。自分の実装力を活かして良いシステム構成にできた時は、うまくいったと感じます。
意思決定の過程を書き残すのは重要なこと
── Q. 普段大切にしていることは何ですか?
テックリードになってからは、開発速度を維持しつつ知見を紡いでいく方法について考えるようになりました。
まずは知見や意思決定過程を文書で残すこと。私はリニューアルプロジェクトの後にチームにジョインしましたが、リニューアル時のさまざまな意思決定が詳細に残っていて助かっています。松竹梅で実装プランを比較・検討し、最終的にどのプランを採用したのか、その理由などが書かれているのが良いと思います。また、現在のチームのスキルマップを把握して、サービスにとって重要な技術なのに触れる人が少ない箇所については知見共有会を開催しています。
意欲がある人はいくらでも学べる会社
── Q. はてなはどんな会社ですか?
個人の裁量が大きく、挑戦をサポートしてくれます。そして各々に得意な分野があって、それを尊重する文化があります。
学びたい分野があれば、同じ興味を持つ人たちが集まって勉強会をすることもあります。1年ほど前にはなりますが、圏論勉強会が開催されていて、私も参加していました。他にも開発プロセス、GraphQL、コンパイラ、ルービックキューブなど、それぞれ好きな人たちが集まるSlackチャンネルがあります。
さまざまな技術が各サービスを支えていて、それらを解説する文書が社内でたくさん共有されています。意欲がある人はいくらでも学ぶことができる、そういう会社だと思います。
はてなのWebアプリケーションエンジニアには、自分の担当サービスに積極的に関わっていく姿勢が求められます。技術の進歩のスピードが速いこの業界では、品質の高いコードを書くだけでなく、新しい技術へのキャッチアップも必須。技術はエンジニアの共通言語であり、他職種と連携するための道具です。技術に対する向上心を持つ仲間を募集しています。ご連絡をお待ちしております!
▼ Webアプリケーションエンジニア職 転職・中途 - 採用情報
▼ Webアプリケーションエンジニア職 新卒採用 - 採用情報