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

目次

基本情報

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

自己紹介

八木橋拓之(Hiroyuki YAGIHASHI)です。 バックエンドエンジニアです。特に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に力を入れていくかはまだ決定できていません。
あと複雑なシステムを高品質に保つためには分散システムの知識が必要だと感じ、データ指向アプリケーションデザインなどの本を読んでいます。

興味

分散システム、プログラミング言語(主にメモリ管理)、Rustに興味があります。

分散システムは信頼性、拡張性、保守性が高いレベルで満たされているシステムを設計するのに必須な知識だと考えていて、学習を続けています。
現在はデータ指向アプリケーションデザインやAzureアーキテクチャセンターなどを読んで学習しています。

プログラミング言語は普段書いている中でどういった仕組みで動いているのか気になり、学習を続けています。
ガベージコレクションを読んだり、Altheaという言語処理系を自作することで学習をしています。
自作の言語処理系ではバックエンドにLLVMを使用しているため、LLVM IRはある程度読むことができます。
メモリ管理にも興味があり、自作の言語処理系に独自のGCアルゴリズムの実装を進めています。
マークスイープ(コンカレント含む)や参照カウンタなどの基本的なGCアルゴリズムの仕組みと特徴は理解しているつもりですが、実際の言語処理系に実装するのはそれなりに時間がかかる(大枠の方針を立てて実装は進められる)、くらいの知識です。

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

職務経歴

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

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

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

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

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

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

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

ソフトウェアエンジニア (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~2023/1
担当工程 要件定義、設計、実装、テスト
チーム構成 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を使用しました。

成果

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

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のみを設定できないか調査を行いました。
上記を調査しているタイミングでAWS PrivateLink for Amazon S3の一般提供が開始され、これで可能になると考えていたのですが、静的WebサイトホスティングはPrivateLinkに対応していないことがわかりました。
最終的にはEC2でホスティング(Nginxを使用しています)を行いました。

最初はお客さんの方でもAWS Web コンソールでインフラを変更する可能性があるということだったので、API全体の管理ライブラリは導入せず、デプロイや環境変数の切り替えはシェルスクリプトを独自に組んで使用していました。
Serverless FrameworkやAWS SAMはインフラの設定に意図しない変更が出てしまうことを懸念して導入しないという判断をしました。
ですが、取引会社さんの方で変更する部分が大体分かってきたというのもあり、取引会社さんと交渉し、大きな機能追加開発が入るタイミングでServerless Frameworkを導入しました。
導入によって基盤全体の見通しが良くなっただけではなく、属人化の排除、インフラ設定の共通化、テスト環境と開発環境での実行が容易に出来るようになりました。
なお、上記のタイミングでJavaScriptからTypeScriptへの移行も行い、より安全に開発を行えるようになりました。

TODO: 更新する Webアプリは新しくRecoilを導入しました。

宿泊者管理サービス

参画期間 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の導入ですが、大手ハウスメーカー顧客管理サービスで発生していた問題を解決することを試みました。 主に問題となっていたのは下記の3つです。

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

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

その結果、問題が解決されただけではなく、今後の開発においてもGraphQLという選択肢を取ることが以前より容易になり、会社全体としても問題解決の幅が広がったと考えています。

TODO: Next.jsの導入の思考を書く
TODO: Terraformを使用したIaCの導入の思考を書く

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

参画期間 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に限定しています)

その他

各種リンク