このページは @yagipy の職務経歴を紹介するページです。
最終更新日: 2023/6/13

目次

基本情報

氏名 八木橋 拓之
氏名(フリガナ) ヤギハシ ヒロユキ
生年月日 1998/10/19
性別 男

自己紹介

八木橋拓之です。バックエンドエンジニアです。特にGo/Node.jsを使用したAPIサーバーの開発、AWSを用いたインフラ構築を得意としています。
Reactを使用したWebクライアントの開発、PythonやRuby(Ruby on Rails)を用いたAPIサーバー開発、Androidアプリ開発も実務経験があります。
直近の業務内容は、見積作成、設計(DB設計、API設計、技術選定)、ベースコードの作成、導入事例のない技術の検証と実装を行いつつ他メンバーのサポートをするというのがメインになります。
サポートは主にレビューやペアプロ等を通して設計意図の共有やメンバーが設計に沿った実装を行えるようにしています。
個人の活動では、JS Conf JPやGo Release Partyでの登壇、Node.jsやgolangci-lintへのコントリビュート、プログラミング言語や静的解析ツールの自作などの経験があります。

目標

2025年までには大規模OSSと複雑なシステムの開発をリードする存在になり、様々な技術的課題を解決するという目標があります。
以前は、必要十分に品質の高いプロダクトを1人で作れるようになるという目標がありました。
様々なプロジェクトで設計や技術選定から実装やテストまでを任せていただき、その目標はほぼ達成できたと考えています。
ですが、様々な技術の比較検討を行なっていく中で、あくまで技術の利用者でしかないという感覚と、技術的課題によってできないことがあるという現実の2点を強く感じるようになりました。
今は利用者としてだけではなく提供者として様々な技術に関わっていきたいと考えています。
そして、様々な技術に存在している技術的課題を解決していくことで、作りたいプロダクトが技術的課題によって作れない、ということをなくしていきたいと考えています。

目標に対する現在の行動

大規模OSSの開発をリードする存在になるために、様々なOSSを作成したり大型OSSにコントリビュートをしています。どういったOSSに力を入れていくかはまだ決定できていません。
あと、複雑なシステムの開発をリードする存在になるために、分散システムやデータベースの知識が必要だと考えデータ指向アプリケーションデザインを読んだりyagidbというDBMSの作成などを行っています。

興味

分散システム、プログラミング言語、Rustに興味があります。

分散システムは信頼性、拡張性、保守性が高いレベルで満たされているシステムを設計するのに必須な知識だと考えていて、学習を続けています。
現在はデータ指向アプリケーションデザインを読んだり、yagidbというDBMSを作成することで学習をしています。
yagidbはデータ指向アプリケーションデザインを読んでいく中で、分散システムへの理解を深めるためにデータベースの知識が有用だと感じたため作成を始めました。
現在は低機能ですが、将来的にはシングルリーダーレプリケーションなどの分散システムに関連する機能を実装していきたいと考えています。

プログラミング言語は普段書いている中でどういった仕組みで動いているのか気になり、学習を続けています。
ガベージコレクションを読んだり、Altheaというプログラミング言語を作成することで学習をしています。
特に興味があるのはメモリ管理で、Altheaには所有権付き参照カウントという独自の自動メモリ管理機能を実装しました。
マークスイープ(コンカレント含む)や参照カウンタなどの基本的な自動メモリ管理の仕組みと特徴は理解しているつもりです。
あと、AltheaではバックエンドにLLVMを使用しているため、LLVM IRはある程度読むことができます。

Rustは高性能かつ安全なコードを書くために、よく考えられている機能が多く勉強になるため学習をしています。
特に所有権やライフタイムを使用することでメモリ安全性を保ちつつGCを排除していたり、Option型を導入することでnullを排除している点がよく考えられていると思います。
他にもResult型やデフォルトで変数が不変など細かい部分まで言語レベルで制御可能であり、シビアな要件を達成したい時や厳密にコードを書きたい時に最適だと考えています。
先ほどのAltheaという自作プログラミング言語に使用しています。

職務経歴

からくり株式会社 (2019年4月 ~ 2023年1月)

2019年4月に新卒入社しました。
Webフロントエンド/バックエンドのテックリード、教育グループリーダー、ソフトウェアエンジニアを担当しています。

Webフロントエンド/バックエンドのテックリード (2021年4月 ~ 2023年1月)

Webフロントエンド/バックエンドに関する見積作成、設計(DB設計、API設計、技術選定)、ベースコードの作成、導入事例のない技術の検証と実装を行いつつ、他メンバーのサポートをするというのがメインの業務になります。
ただ、テックリード業務のための工数が毎月あるわけではなく、必要なタイミングで(新規開発立ち上げの際や新しい技術を検証/導入する際など)工数をもらい、実際にプロジェクトに参画する形で業務を行なっています。
主な実績は各プロジェクトの利用技術や技術選定に関する思考と行動の項目に書いています。(各プロジェクトはソフトウェアエンジニアの項目にまとまっています)

※ からくり株式会社では、会社全体のテックリードと案件ごとのテックリードが存在しています。
会社全体のテックリードについては、前に担当されていた方が退職された後、私がそのタスクを担当しております。
ただ、会社全体で組織図を大きく見直すという話があり、2020年9月での発表以降正式な組織図の発表は行われず、事実上は会社全体のテックリードとして業務を行っておりましたが、正式な役職の発表があったわけではありません。

教育グループリーダー (2020年9月 ~ 2023年1月)

教育グループでは、会社レベルでの教育に関する施策の立案や実行を担当しました。(メンバー数最大4名)
教育効果を定量的に測定するために、エンジニア評価制度に関しても作成しました。
施策の立案や実行の過程で、「学習する組織」や「リファクタリング•ウェットウェア」、「成人発達理論による能力の成長」という本を読み、体系的な能力開発に関する知識を得ることができました。
主に行った施策は下記になります。

※ 教育グループリーダーの担当期間を2020年9月 ~ 2023年1月と記載していますが、アクティブに活動していたのは2020年9月 ~ 2021年9月です。
これは、2021年9月に会社全体で組織図を大きく見直すため新しく組織図が決まるまでは必要最低限の活動のみを行うこととなったのですが、
その後組織図が決まることはなかったため、退職時まで必要最低限の活動を行うという形になったためです。

ソフトウェアエンジニア (2019年4月 ~ 2023年1月)

参画した開発プロジェクトを抜粋しています。
テックリードを担当したプロジェクトのみ、利用技術や技術選定に関する思考と行動という項目があります。

プロジェクトの網羅性は下記ブログ記事の方が高いですが、このページの方が各プロジェクトをより詳細に書いています。
2021年の詳細
2020年の詳細

オンライン診療アプリ

参画期間 2021/11~2023/1
担当工程 要件定義、設計、実装、テスト
チーム構成 PM×3名
iOSエンジニア×3名
Androidエンジニア×4名
Webフロントエンド/バックエンドエンジニア×6名(自分)
役割 Webフロントエンド/バックエンドのテックリード
Webフロントエンド/バックエンドのプロジェクトマネジメント(メンバー数最大6名)
主な使用技術 フロントエンド: TypeScript、React、vite、Chakra UI
バックエンド: Go、gqlgen、ent
インフラ: Terraform、AWS、ECS、Fargate、SNS、SES、Aurora(MySQL互換)、CloudFront、Route53、ALB
その他: GitHub Actions、GMOPayment、Twilio、OMRON connect Cloud
プロジェクト概要と担当領域

オンライン診療や医師とのチャットを行うことができるアプリです。
患者用のWebアプリ、医療従事者用のWebアプリ、システム管理者用のWebアプリ、各Webアプリとネイティブアプリに提供するAPIサーバー、インフラ構築を担当しました。

主な担当業務
利用技術や技術選定に関する思考と行動

大きく3つのチャレンジを行いました。

Goの全面的な導入

課題

工事現場での無傷事故報告アプリで部分的なGoの導入を行い、Rubyを使用した際の課題が解決され、かつGoを導入することのメリットを確認できました。
今回のプロジェクトは大規模だったこともあり、全面的に導入することでGoのメリットをより享受できると考えました。
ですが、Goを全面的に導入する際の課題として、プロジェクト参加者に学習コストが発生することが挙げられました。

取り組み、工夫点

課題の対応として、まずは導入の背景や学習コストが発生することをプロジェクト参加予定のメンバーに伝え、合意形成を行いました。
その後、学習コストを最小限にするために、下記を行いました。

成果

上記取り組みによって、下記のような成果が得られました。

なお、全面的に導入することによって、下記のようなメリットをより享受することができました。

GraphQLによるスキーマ駆動開発の導入

課題

GraphQLによるスキーマ駆動開発を導入することによって、工事現場での無傷事故報告アプリで発生したレスポンスを過度に共通化したことによる無駄なプロパティの発生という課題の解決を試みました。

課題についての補足ですが、工事現場での無傷事故報告アプリでは大きく2つの方針でレスポンスを決めていました。

1.原則、レスポンスは対象entityの全てのプロパティを返す
  - セキュリティ上問題がある場合等は除く
2.子のentityが必要な場合は、リクエストで指定する
  - [Stripeのexpand](https://stripe.com/docs/expand)のような仕組み
  - 1に従い、子のentityは全てのプロパティを返す

上記の方針は、画面の表示要素を変えるたびにAPI側のコードを修正しなくても良いようにするために決めたものでした。
ですが、モバイルの開発者から、使用しないプロパティを返さないで欲しいという要望がありました。

取り組み、工夫点

上記課題を解決するためには、画面の表示要素を変えるたびにAPI側のコードを修正しなくても良いという部分は維持しつつ、特定のプロパティのみを返すようにする必要があると考えました。
そのためには、クライアント側でプロパティを指定できるようにすることが必要だと判断しました。

クライアント側でプロパティを指定できるようにする方法として、2つの方法が考えられました。

下記の理由からGraphQLを導入しました。

成果

上記の取り組みによって、クライアント側でプロパティを指定できるようになり、最初にあげたレスポンスを過度に共通化したことによる無駄なプロパティの発生の解決に成功しました。
かつ、工事現場での無傷事故報告アプリでgRPCを導入した際と同じく、スキーマ駆動開発によって各クライアントとの意思疎通が容易になり、ドキュメンテーションにかかる時間も削減できました。

Project-based monorepoの導入

こちらはプロジェクト立ち上げ初期からではなく、途中から導入しました。

課題

初期はAPIサーバー、Webクライアント、GraphQLスキーマの3リポジトリに分け、APIサーバーとWebクライアントでGraphQLスキーマのリポジトリをsubmoduleとして参照していました。
この構成で1ヶ月程度運用してみたところ、下記の問題が発生しました。

取り組み、工夫点

上記の問題を解決するためにAPIサーバー、Webクライアント、GraphQLスキーマの3リポジトリを1つのリポジトリに統合しました。
かつ、GitHub Actionsでgenerateのチェックを行うようにし、generateされていなかった場合はマージをブロックするようにしました。

成果

上記の取り組みによって、下記のように問題が解決されました。

工事現場での無傷事故報告アプリ

参画期間 2021/06~2022/7
担当工程 要件定義、設計、実装、テスト
チーム構成 PM×1名
iOSエンジニア×4名
Androidエンジニア×4名
サーバーサイドエンジニア×7名(自分)
役割 Webフロントエンド/バックエンドのテックリード
Webフロントエンド/バックエンドのプロジェクトマネジメント(メンバー数最大7名)
主な使用技術 フロントエンド: TypeScript、React、Next.js、Recoil、TailwindCSS
バックエンド: gRPC、Go、grpc-gateway、Ruby、guard
インフラ: AWS、ECS、Fargate、SNS、Aurora(MySQL互換)、CloudFront、Route53、ALB
その他: GitHub Actions
プロジェクト概要と担当領域

工事現場で無傷事故(ヒヤリハット)が発生した際に報告を行うアプリです。
報告された内容を確認する管理者用のWeb画面、ネイティブアプリと管理者用Web画面に提供するAPI開発を担当しました。

主な担当業務
利用技術や技術選定に関する思考と行動

大きく3つのチャレンジを行いました。

Goの部分的な導入

今まで会社がメインで使用していたサーバーサイドの言語はRubyでしたが、この案件で初めてGoを導入しました。

課題

この意思決定には、Rubyを使用した際の課題が関係しています。
私が考えている、Rubyを使用した際の課題は下記になります。

取り組み、工夫点

上記課題から、採用する言語は静的型付け言語で、実行速度が早く、コミュニティが盛んである必要があり、いくつか候補がある中からGoを選択しました。(Goの他にKotlinとTypeScriptを検討しました)
Goを選択した理由としては下記になります。

ただ、社内でGoを書ける人が少なかったので、アプリケーションレイヤをマイクロサービス化し、部分的かつ段階的にGoを導入しました。
具体的にはgatewayサーバーはGo、他のサーバーは書けるメンバーが多く社内に知見がたまっているという点でRubyを採用しました。
サーバー間の通信はgRPCを使用しました。

成果

上記取り組みによって、下記のような成果を得ることができました。

「実行速度が遅い」という課題は、問題となっていた大手ハウスメーカー顧客管理サービスを改善した形ではないため、課題が改善されたか計測することはできませんでした。 ですが、一般的にGoはRubyよりも実行速度が速いため、本プロジェクト(工事現場での無傷事故報告アプリ)で実行速度に関係する課題が発生した際に、取り得る選択肢が増えたと考えています。

なお、「外部ライブラリの依存先を比較的少なくできる」というメリットは、Goを全面的に導入した際により実感できると考えています。 そのため、Goを全面的に導入したオンライン診療アプリの方に実際の成果を記載しています。

Protocol BuffersとOpenAPIを使用したスキーマ駆動開発の導入

課題

APIのインターフェースはフロントエンドとバックエンドの間で共通の認識を持つ必要があります。
今までのプロジェクトでは、APIのインターフェースはドキュメントか口頭によって共有されており、下記のような課題がありました。

取り組み、工夫点

上記課題を解決するために、Protocol BuffersでAPIインターフェースを定義し、Protocol BuffersからOpenAPIを自動生成するようなフローでスキーマ駆動開発を実現しました。
なぜそのような構成にしたのかを書いていきます。
まず最初に、スキーマ駆動開発を導入する際の選択肢として一般的かつ実績が豊富なのは下記2つであると考えました。

最初はgRPCで十分にサポートされていない言語やクライアントを考慮しOpenAPIのみを使用することも考えましたが、下記のような理由からProtocol Buffersを書き、OpenAPIを自動生成する形を採用しました。

成果

上記取り組みによって、下記のような成果が得られました。

Amazon ECSとAWS Fargateの導入

Amazon ECSとAWS Fargateは、サーバーレスかつコンテナ化を実現するために導入しましたので、ここでは最初になぜサーバーレスかつコンテナ化を実現したかったのかについて書きます。

課題

今まではAWS EC2にAnsibleでプロビジョニングする形でしたが、下記のような課題がありました。

取り組み、工夫点

上記の問題を、サーバーレスかつコンテナ化をすることで解決したいと考えました。
パブリッククラウドはAWSを使用していたため、AWSで提供されているサービスであるAmazon ECSとAWS Fargateを採用しました。
コントロールプレーンはEKSでも可能でしたが、EKSはECSに比べて学習コストおよび運用コストが高いと考えており、今後何かしらの課題が発生した際はEKSにする可能性はあるが、問題が発生するまではECSで良いと判断しました。

成果

サーバーレスかつコンテナ化することで、下記のような成果が得られました。

認証認可基盤システム

参画期間 2020/10~2023/1
担当工程 要件定義、設計、実装、テスト
チーム構成 PM×1名
Webフロントエンド/バックエンドエンジニア×2名(自分)
役割 Webフロントエンド/バックエンドのテックリード
Webフロントエンド/バックエンドのプロジェクトマネジメント(メンバー数最大2名)
主な使用技術 フロントエンド: TypeScript、React、Next.js、Recoil、TailwindCSS
バックエンド: JavaScript、TypeScript、prisma、ldapjs、samba-client、sequelize、Serverless Framework
インフラ: AWS、Lambda、API Gateway、EC2、RDS、RDS Proxy
その他: GitHub Actions
プロジェクト概要と担当領域

社員が使うアプリの認証が各アプリのサーバーで実装しており、情報が散在しているという課題がありました。
その情報を集約することを目的に、認証認可基盤を作成しました。
管理者が使用するWebアプリとAPI開発を担当しました。

主な担当業務
利用技術や技術選定に関する思考と行動

インフラ構成や言語については、お客さんの方から要望があったため、要望に答える形で実装しました。
APIはAPI Gateway + Lambdaの構成になっています。
DBはMySQL互換のRDSを使用しています。(コネクション管理はRDS Proxyを使用しています。)
管理画面は「アクセスをプライベートネットワークに閉じたい」という要望があったため、会社でよく使っていたS3の静的Webサイトホスティング上でプライベートIPのみを設定できないか調査を行いました。 最初は静的Webサイトホスティングの設定のみで設定できないか調査を行いましたが、設定できないことがわかりました。 上記を調査しているタイミングでAWS PrivateLink for Amazon S3の一般提供が開始され、これで可能になると考えていたのですが、静的WebサイトホスティングはPrivateLinkに対応していないことがわかりました。
最終的にはEC2でホスティング(Nginxを使用しています)を行いました。

そういった中でも、大きく2つのチャレンジを行うことができました。

Serverless Frameworkの導入

こちらはプロジェクト立ち上げ初期からではなく、途中から導入しました。

課題

プロジェクト立ち上げ初期はお客さんの方でもAWS Web コンソールでインフラを変更する可能性があるということだったので、API全体の管理ライブラリは導入せず、シェルスクリプトを独自に組んでデプロイや環境変数の切り替えを行っていました。 Serverless FrameworkやAWS SAMはインフラの設定に意図しない変更が出てしまうことを懸念して導入しないという判断をしました。
しかし運用を続けていく中で、下記のような課題が出てきました。

取り組み、工夫点

解決策として、下記の3つを候補として考えました。

シェルスクリプトの充実は上手く作成することで多くの課題ををカバーできると考えましたが、属人化が進んでしまう可能性があると考え、候補から外しました。 Serverless Frameworkの導入とAWS SAMの導入はどちらでも解決可能でしたが、プラグインの豊富さからServerless Frameworkを導入することにしました。

お客さんの方で変更する部分が大体分かってきたというのもあり、導入にあたって大きく問題が発生しないことは想定できました。 そこで取引会社さんと交渉し、大きな機能追加開発が入るタイミングでServerless Frameworkを導入することができました。

成果

導入によって下記のような成果が得られました。

なお、上記のタイミングでJavaScriptからTypeScriptへの移行も行い、より安全に開発を行えるようになりました。

Recoilの導入

TODO: 詳細を書く

宿泊者管理サービス

参画期間 2020/6~2020/9
担当工程 要件定義、設計、実装、テスト
チーム構成 PM×1名
iOSエンジニア×2名
Webフロントエンド/バックエンドエンジニア×2名(自分)
役割 Webフロントエンド/バックエンドのテックリード
Webフロントエンド/バックエンドのプロジェクトマネジメント(メンバー数最大2名)
主な使用技術 フロントエンド: TypeScript、React、Next.js、Redux、Redux Toolkit、Redux Saga、Apollo Client
バックエンド: Ruby、Ruby on Rails、graphql-ruby、capistrano
インフラ: Terraform、AWS、EC2、RDS、ALB、S3、CloudFront
その他: CircleCI
プロジェクト概要と担当領域

宿泊者の入退室を管理したり、スタッフとチャットやビデオ通話を行うことが出来るアプリです。 システム管理者が使用するWebアプリとAPI開発を担当しました。

主な担当業務
利用技術や技術選定に関する思考と行動

大きく3つのチャレンジを行いました。

GraphQLの導入

課題

大手ハウスメーカー顧客管理サービスで発生していた問題を解決することを試みました。 主に問題となっていたのは下記です。

取り組み、工夫点

解決策として、下記の2つを候補として考えました。

どちらでも課題は解決可能でしたが、下記の理由によりGraphQLを採用しました。

成果

GraphQLの導入によって、下記のような成果が得られました。

Next.jsの導入

TODO: 詳細を書く

Terraformを使用したIaCの導入

TODO: 詳細を書く

大手ハウスメーカー顧客管理サービス

参画期間 2020/2~2020/6
担当工程 要件定義、設計、実装、テスト
チーム構成 PM×1名
PM支援×1名
Webフロントエンド/バックエンドエンジニア×9名(自分)
役割 Webフロントエンド/バックエンドエンジニア
主な使用技術 フロントエンド: TypeScript、React、Create React App、Redux、react-pdf、react-table
バックエンド: Ruby、Ruby on Rails、capistrano
その他: GitHub Actions、CircleCI、Ansible
プロジェクト概要と担当領域

ハウスメーカーと住宅を購入した顧客がコミュニケーションを取るアプリです。 顧客が使用するWebアプリと大手ハウスメーカーが使用するWebアプリ、それぞれのWeb画面に提供するAPIの開発を担当しました。

主な担当業務

大手メガネメーカー店舗向けサービス

参画期間 2019/6~2020/9
担当工程 設計、実装、テスト
チーム構成 PM×1名
iOSエンジニア×2名
Androidエンジニア×3名(自分)
バックエンドエンジニア×2名(自分)
役割 Androidエンジニア
バックエンドエンジニア
主な使用技術 Android: Java、Android、Dagger、RxJava
バックエンド: Ruby、Ruby on Rails
その他: GitHub Actions、Circle CI、Ansible
プロジェクト概要と担当領域

ユーザーがメガネ購入後に、保険証などの情報を管理できるアプリです。 他にもユーザーの投稿、タイムライン、販売中のメガネ一覧、友達招待などの機能があります。 実際にメガネを購入するユーザーが使用するAndroidアプリと、ネイティブアプリに提供するAPIの開発を担当しました。

主な担当業務

株式会社taliki (2018年6月 ~ 2019年3月)

インターンとして参画し、インフラエンジニアを担当しました。

開発プロジェクト一覧

ちあちあ

参画期間 2018/6~2019/3
担当工程 実装
チーム構成 PM×1名
iOSエンジニア×1名
Androidエンジニア×1名
Webフロントエンド/バックエンドエンジニア×1名
インフラエンジニア×1名(自分)
役割 インフラエンジニア
主な使用技術 AWS、EC2、ALB、Route53、Nginx、PostgresQL
プロジェクト概要と担当領域

SNS上で応援を集められるサービスちあちあのインフラ構築を担当しました。

主な担当業務

株式会社Hatty&Co. (2018年6月 ~ 2018年10月)

1人目のエンジニアとして参画し、CTOを担当しました。

開発プロジェクト一覧

Camel

参画期間 2018/6~2018/10
担当工程 要件定義、設計、実装、テスト
チーム構成 PM(代表取締役)×1名
エンジニア×1名(自分)
役割 エンジニア
主な使用技術 Ruby、Ruby on Rails、AWS、EC2、ALB、RDS、Route53、Nginx、MySQL
プロジェクト概要と担当領域

大学のサークルを経由してチャットできるマッチングアプリ、Camelの構築を担当しました。
資金調達や開発が難航したため、リリースには至りませんでした。

主な担当業務

個人の活動

登壇

OSS

Owner - 私自身が作成し運用しているOSSになります
Maintainer - リポジトリに対するWrite権限を持っているOSSになります
Contributor - コントリビュートしたことのあるOSSになります(ここでは私自身が作成したPRがマージされたことのあるOSSに限定しています)

その他

各種リンク