keitakn の職務経歴、スキルシートです。
| key | value |
|---|---|
| Name | KeitaKoga |
| Location | Tokyo |
| https://twitter.com/keita_kn_web | |
| keita.koga.work@gmail.com | |
| GitHub | keitakn |
| GitHub(友人と共同で運営しているOrganization) | nekochans |
| Qiita | keitakn |
| Zenn | keitakn |
- 対象のソフトウェアが解決しようとしている問題領域を理解して、ビジネス状況に合わせた技術選定を行う事
- テストコードや設計手法を工夫して、保守性・拡張性の高いシステムを構築する事
- 未知の技術でも比較的短い期間でキャッチアップを行う事
- アジャイル開発（スクラム）を用いたチームビルディング
- フロントエンドからインフラ構築も含めたバックエンドまでWeb開発の一通りの工程を1人でこなす事が出来る事
- 相手に伝わりやすい非同期コニュニケーションを行う事が出来て、コミュニケーションの仕組みを構築出来る
過去には既存システムの問題点を解決したリプレイスや新規開発案件を数多く対応しました。
現在の状況を見て最適なシステム構成を提案・実行させて頂きます。
またチームや組織の心理的な安全性を再重視しており、相手によって態度を変えない、フラットで丁寧なコミュニケーションを取る事を常に意識しております。
最近は自らをプロダクトエンジニアと名乗っています。
プロダクトを第一に考え、プロダクトに最適な技術選定や問題解決手段を選択するように心がけています。
- Webデザイン（CSSは出来ますがUX等を考えたUIを作るスキルはありません）
- 背景・目的が不明確で言われた事だけをやる開発スタイル
フロントエンド、バックエンド、インフラ（クラウド）でそれぞれどのような事を意識しているかを記載しておきます。
最近はNext.jsやReactをメインに扱っていますので、これらの技術を使った際の話を記載させて頂きます。
Propsにのみ依存する純粋なComponentと副作用を持つ部分を明確に分ける事を意識しています。
テストコードに関しては以下の2つのテストにリソースを投入しています。
- Storybookを流用したテストコード
- E2Eテスト（フロントエンドの動作担保を行う為には、やはりE2Eテストが必須）
スナップショットテストや作成した関数に対する単体テスト等も場合によっては実装します。
Storybookに関しては、そのComponentが持つ振る舞いをStorybook上で全て表現しています。
またStorybookを静的Buildして、生成されたHTMLを閲覧出来る状態を作成しています。 最近だとChromaticというサービスを利用しています。（以下は自分が書いた記事です。）
https://zenn.dev/keitakn/articles/storybook-deploy-to-chromatic
これを行う事でUIのレビューが効率よく実行出来るようになります。
これは過去に関わった現場がやっていたのを真似しているのですが、UIに関するコミュニケーションを非常に円滑にしてくれるので、少々時間はかかりますが、行う価値がある方法だと思っています。
Cloudflare Workers や Vercel Edge Runtime 等の 非Node.js環境でも移植できるような設計を意識しています。
最近ではReact Server ComponentsがNext.jsによって利用可能になったので、Server ComponentsとClientComponentの使い分けを意識するようになりました。
自分が友人と運用しているサービス LGTMeow のソースコード載せておきます。
このサービスは友人との共同運営ですが、バックエンド、フロントエンドで開発担当を分けており、自分はフロントエンドで開発を行っています。
最近は生成AI関連の開発を中心に活動しているのもあってPythonをメインに書いていますので、その前提で記載させて頂きます。
あまり重厚なフレームワークは使わずに、FastAPIなどの軽量フレームワークで小さく始める事をしています。
とは言え、テストを書きやすい構造にしておかないと後々プロジェクトが肥大化した際に困る事になるので、レイヤードアーキテクチャを採用してDDDライクな設計にする事が多いです。
テストコードはアプリケーション層（ユースケース層とも言う）に対して必ず実装するスタイルを取っています。
この形であれば後に大規模なリファクタリングが必要になった際もテストコードを頼りに進めやすいからです。
なおプロジェクトの規模によりますが、DBへの接続部分はモックを使わずにテスト用のDBを用意するスタイルを基本と考えています。（モックに差し替えられる設計にはした上で）
DBに意図した通りにデータが登録されるかどうかもバックエンドのAPIにとっては重要なファクターなのでテストコードで担保すべきという考えからです。
DBを使うとどうしてもテストの実行が遅くなるので、テストの実行速度が遅くならないように以下の記事のような工夫も行っています。（以下は自分が書いた記事です）
https://zenn.dev/keitakn/articles/accelerate-planetscale-test-code
次に負荷対策についてですが、過去にはやった事がある最大規模のシステムは以下の通りです。
- 会員数が2000万人程度
- スループットの目標値が5000rps
- この負荷がかかった状態で参照系のAPIを150ms以内にレスポンスを返す事を目標にする
クラウドやServerless環境で運用を行うケースが大半なので、性能試験を行う際は、システムをスケールアウトした際にそれに伴って性能が向上する事を確認する事を意識しています。
参考までに生成AIを利用した個人サービス AI Meow Cat のソースコードを記載しておきます。（Python + FastAPIによる実装）
https://github.com/nekochans/ai-cat-api
SREやクラウドエンジニアを専門でやった事はないのですが、過去にはそこそこの規模（会員数100万人ほど）のWebサービスのリプレイスでAWSのネットワーク設計をゼロから行った事があります。
最近はスタートアップ企業でのお仕事が多い事もあり、AWSのような大手のパブリッククラウドを利用するよりもCloudflare Workersのような高性能なServerlessプラットフォームやFly.ioのような安価で簡単にコンテナ実行環境が構築出来るプラットフォームを選定しています。これはインフラ環境のメンテナンスコストを可能な限り削減し開発リソースをアプリケーション開発に集中させるという考え方からです。
これはRDBなどのDBに関しても同じでPlanetScaleなどの安価なDBaaS（Database-as-a-Service）を採用しています。 ブランチ機能やSafe migrationsなどの機能により開発体験も良くなるのでメリットはかなり大きいと感じています。
とは言え一定規模以上のシステムだとAWS等を利用したほうが費用も安くノウハウもたくさんあるのでその場合はAWS等を利用します。
AWSリソースはTerraformで構成管理を行うようにしています。
誰がいつどのように変更したのかを把握するのと、環境構築手順をコード化して保存するのが目的です。
AWS Well-Architected フレームワーク 等のAWSのベストプラクティスに準拠しセキュリティを意識した設計を心がけています。
結構前に書いたコードにはなりますが自分が個人で運用しているAWS環境のTerraformです。（バージョンアップしたい）
https://github.com/keitakn/my-terraform
スキルの習熟度の目安は下記の通りです。
あくまでも自己評価です。
S: その技術における現時点でのベストプラクティスをある程度理解しており、実装出来るA: 業務レベルで普通に開発が出来るB: 業務経験ありだが経験が少ないC: 学習した事がある程度
| 言語名 | スキルレベル | 備考 |
|---|---|---|
| HTML | A | フロントエンドをやっていた事もあるので普通に書けます。 |
| CSS | A | フロントエンドをやっていた事もあるので普通に書けます。 |
| JavaScript | S | ブラウザ、Node.js共に経験あり、最新の仕様も把握しています。 |
| TypeScript | S | ブラウザ、Node.js共に経験あり、最新の仕様も把握しています。 |
| Go | S | WebAPI（REST）とgRPCアプリケーションを開発した事があります、フレームワークは未使用。 |
| PHP | S | ファーストキャリアで触れた言語です。最近は利用していません。 |
| Ruby | A | Ruby2.2、2.3の頃に利用していました、最近は利用していません。 |
| Java | B | 保守案件でJava8 + Spring Frameworkの組み合わせで少し開発した程度。 |
| Scala | B | PlayFramework2.4を少しだけ保守案件で触った程度、Gatlingでテストシナリオを書いていました。 |
| Python | A | LLMの操作でPythonの情報量が最も多いので学習を開始しました。LLMを利用したアプリケーション開発で利用しています。 |
JavaScript（TypeScript）がもっとも経験が長いです。最新の仕様にも追従出来ております。
PHPはファーストキャリアから扱っている言語で5年ほど扱っていましたが、最近触っていないので、最新の仕様には疎いです。（7.3系あたりで知識が止まっています）
最近、React、Next.jsでのフロントエンド開発やインフラ側のコードをAWS Lambdaで書く事が多いのでTypeScriptやGoを書く機会が一番多いです。
Rubyはそこそこ書けますが長い間書いていないので最新の仕様には疎いです。
Java, Scalaに関しては、まだ経験不足なところが否めないと感じております。
最近LLMを利用したアプリケーションの新規開発案件に参加しており、今バックエンドで一番触る機会が多い言語となっています。
私のGitHubを見て頂き、どの程度の技術力なのかを判断して頂くのが良いと思っております。
| 名前 | スキルレベル | 備考 |
|---|---|---|
| Zend Framework | A | 一番最初に触ったフレームワークです。バージョンは1系でした。 |
| FuelPHP | A | 1から導入した経験があります。 |
| Laravel | A | 1から導入した経験があります。最後にやったPHP案件がこれでした。 |
| Express | S | 2015年頃サーバーサイドでNode.jsをやる際に良く利用していました。 |
| Ruby on Rails | B | 1から開発経験アリです。WebAPIの開発で利用しました。当時は4系だったので最新の仕様には追従出来ていません。 |
| Sinatra | A | 1から開発経験アリです。 |
| Spring Framework | B | 保守案件で少し触った程度で習熟度は高くありません。 |
| Play Framework | B | 2.4系を少しだけ保守案件で触った程度で習熟度は高くありません。 |
| Hono | A | 個人開発で利用しました。 |
| FastAPI | S | 個人開発、LLMを使った開発案件で利用しました。最近はこれを触っています。 |
最近の自分の考えとしては、以下のような理由からバックエンドに関してはフルスタックなフレームワークを駆使してモノリシックなシステムを開発するより、Hono のような薄いフレームワークとCloudflare Workersのようなサービスを使って小規模で疎結合なシステムを構築していくのが良いと考えています。
- Next.jsのようなフレームワークの進化により、フロントエンドにアプリケーション開発の比重が寄ってきている（LLMを利用したアプリケーションは別）
- クラウドサービスたライブラリの進化によりバックエンドで書くコード量が減っている
もちろんモノリシックに作ったほうが早い場合も多々あるので全てのケースでは当てはまらないと思います。
Goに関してはフレームワークを利用せずに標準パッケージだけで小さなコンテナ用アプリケーションを作成するスタイルを取っています。
TypeScriptで開発を実施する際は Cloudflare Workers のようなEdgeサーバーで動作する環境を利用出来ないか検討します。
またNode.jsで開発する際もなるべく非Node.js環境に移行しやすいような設計を意識しています。
| 名前 | スキルレベル | 備考 |
|---|---|---|
| jQuery | A | JavaScriptで初めて触ったライブラリです。それなりに長く業務でも使っていましたが最近は全く触っていません。 |
| React | S | 2015年頃からこれで開発をしています。ベストプラクティスもある程度は把握しています。 |
| Vue.js | B | Reactよりは習熟度が高くないですが、Vuexも含めたSPA開発を行った事があります。 |
| Next.js | S | 新規開発のアプリケーションで複数回利用しました。 |
| Nuxt.js | A | 新規開発のアプリケーションで複数回利用しました。 |
| Angular | C | 1系の頃に少し学習しましたが最近は全く触っていません。 |
npmを用いたフロントエンド周りの環境構築等も問題なく行う事が出来ます。
最近はNext.js(React)がメインです。
少し前までは、Redux を使う事が多かったですが、最近は Redux を使わずに SWR や標準の React.Context を使う事もあります。
最近ではシンプルなステート管理ライブラリの valtio も気に入っています。
Svelte、Solid、Qwik等新しいライブラリが出てきていますが、個人的には現時点では React を選択するのが無難だと考えています。理由は以下の通りです。
- エコシステムが育っている
- メンテナンスの継続性が安定している
- 最も普及しているので良質な情報が多い
Server Components等の比較的新しい分野もReact界隈から主に発信されているので、未来のフロントエンドを見据えた時にReactをキャッチアップしていると得られる情報も多いというのもメリットだと思っています。
| 名前 | スキルレベル | 備考 |
|---|---|---|
| MySQL | A | 一番良く利用しています。5.1系の時代から5.7系までのバージョンを利用した経験があります。 |
| Redis | A | オンプレでRedis Sentinelを使って自動フェイルオーバーの仕組みを構築した経験があります。 |
| memcached | A | キャリア初期の頃にCacheサーバーとして利用していました。 |
| MongoDB | B | 社内システムの構築時に一度だけ使った事があります。 |
| DynamoDB | B | ServerlessアーキテクチャでAPIの認可基盤を開発した際に利用しました。 |
上記に記載したDBは全て導入からチューニングまで対応しておりました。
ただしMongoDBだけは、アクセス数が限定可された社内システムでの利用だったので、高負荷時のパフォーマンス・チューニングの経験はありません。
MySQLに関しては、現在においても最も重要なRDBMSだと思っているので、設計やパフォーマンスチューニングにはそれなりに拘りを持っています。
最近ではPlanetScaleなどの安価なDBaaS（Database-as-a-Service）を採用しています。 ブランチ機能やSafe migrationsなどの機能により開発体験も良くなるのでメリットはかなり大きいと感じています。
| 名前 | スキルレベル | 備考 |
|---|---|---|
| Milvus(Zilliz Cloud) | B | LLM案件で初めて利用したVectorDBです。 |
| Pinecone | C | 。 |
業務経験があるのは Milvus(Zilliz Cloud) のみです。
ただ環境構築は別のメンバーが実施したので、自分はまだVectorDBをゼロから導入した経験がありません。
Pinecone serverless が出たのでこれを利用して何か作ってみようと思います。
| 名前 | スキルレベル | 備考 |
|---|---|---|
| Terraform | S | AWSの構成管理でよく利用しています。 |
| GitHub Actions | S | 最近ではCI・CDの構築にこれを用いる事が多いです。 |
AWS等のパブリッククラウドを利用する場合はTerraformを用いたAWSの構成管理を行う事が多いです。
Kubernetesはマイクロサービスでアプリケーションを設計する機会があり、その際に利用しました。
CI・CDの設定に関しては、GitHub Actionsを利用するのが現時点ではベストな選択と考えています。 開発の初期段階でもCI/CDを構築する事でデプロイ回数を増加させ価値提供までの時間を短縮出来るので、CI・CDはかなり重要だと考えています。
AWSで利用した事があるサービス一覧です。
| サービス名 | スキルレベル | 備考 |
|---|---|---|
| EC2 | S | Webサーバーとして利用していました。 |
| ECS | A | 最近はFargateを利用する機会が多いです。 |
| ELB, ALB | S | 今はALBをメインに使っています。 |
| AWS Lambda | S | 最近利用機会が多くなっています。REST APIやインフラ周りのタスク等様々な場面で利用しています。 |
| S3 | A | 様々な用途で利用しています。 |
| CloudFront | A | CDNとして利用しています。 |
| Route 53 | A | 利用しています。ドメインの購入もこちらのサービスを利用した事があります。 |
| API Gateway | A | AWS Lambdaと組み合わせて様々なAPIを開発した事があります。 |
| RDS | A | Multi-AZを意識した構成も構築した事があります。 |
| DynamoDB | A | Lambdaと合わせてAPIサーバのDBとして利用した事があります。 |
| ElastiCache | A | Laravel製のアプリケーションのキャッシュサーバとして利用しました。（Redisを利用） |
| Cognito | A | UserPoolを用いて認証基盤を構築。社内向け、エンドユーザー向け、両方構築経験があります。 |
| CloudFormation | B | TerraformのほうがAWSの新機能への対応が早いので最近はあまり使っていません。 |
| X-Ray | B | サーバーレスアプリケーションの監視・分析に利用しました。 |
| CodeDeploy | A | EC2でのBlue/Greenデプロイの仕組みを構築した事があります。 |
| CodeBuild | A | ECRへのプッシュ等、様々な用途で利用しています。 |
| Kinesis Data Firehose | A | アプリケーションログをS3バケットに転送する為に利用しました。 |
| Athena | A | Firehoseで集めたログをSQLで検索する為に利用しました。 |
| EKS | C | マイクロサービスのアプリケーション基盤作成で利用しました。（それほど複雑な設定は行っていません） |
| Rekognition | A | 画像に不適切な物が写っていないか確認する際に利用しました。個人サービスでも利用しています。 |
VPCやCloudWatch等のAWSを利用すれば必ず利用するような物は含めておりません。
AWSは2015年頃から積極的に利用しており、0から上記のサービスを用いてインフラ全体（Webアプリケーションも含む）を構築した経験があります。
業務ではChatGPTやGitHub Copilotを業務効率化に利用しています。
今まで解決出来なかった領域の問題解決が出来る可能性がある事からLLMを利用したアプリケーション開発に強い関心があり、2023年7月頃から実際に案件に参加するようになりました。
OpenAI APIで実装されているtools（Function Calling等）と同様の機能がClaude 3でも実装された事から今後は各組織でAIエージェント的なシステムが構築されていくと予想しています。
実はNext.jsは2017年頃に触っていたのですが、ISR(Incremental Static Regeneration が画期的な仕組みと考え注目し始めました。
特にISRは自分が関わっている多くのサービスの応答速度を改善出来る可能性を秘めているので、注目しています。
Next.js 13 からは React Server Components を利用可能なApp Routerが安定版になり、ますます重要な技術になったと感じています。
個人サービス LGTMeow もApp Routerを使った構成に乗り換えました。
https://github.com/nekochans/lgtm-cat-frontend
ただし Vercel を採用出来ない場合インフラ構築コストや運用コストが大幅に増えてしまうので、その場合は Remix のようなシンプルなフレームワークを採用するのが良いと思います。
Next.js 12から実装されたMiddleware や Remix などエッジコンピューティングを利用した仕組みが登場しています。
これらの仕組みを利用するとフロントエンドの大幅な高速化やABテスト等様々な利用用途が考えられるので、注目しています。
また今後はVercelのEdgeランタイムのようなNode.js以外のJSランタイムでも動作するコードを作成する事が必要になると感じています。
その為 Hono のような様々なJSランタイムで動作する軽量なフレームワークにも注目しています。
友人と一緒に開発している個人サービス LGTMeow でもNext.jsをVercel上で動作させているので、BFF層をEdge Runtimeで実装しています。
CDNの提供やDDoS対策だけでなく、Cloudflare Workersのような高性能なServerlessプラットフォームやD1のようなデータベースも安定版になり、AWSの代わりに利用するような機会が増えるのでは？と予想しています。
自分が最近最も注目しているのは以下の記事です。
https://blog.cloudflare.com/python-workers
PythonがCloudflare Workersに正式対応した事によりAIアプリケーションとの相性がますます良くなったと感じています。
バックエンド開発のトレンドもコンテナの次にWASI（Web Assembly System Interface）が主流になる可能性もあるので、これらをサポートしているという点も注目ポイントです。
Next.js 13.4からApp Routerが安定版となり React Server Components が利用出来るようになりました。
https://nextjs.org/blog/next-13-4
実際に試してみたところ、ダウンロードされるJSのサイズが大幅に削減されており、これを上手く使う事で動的コンテンツを中心に提供するようなサービスでもページスピードを大幅に改善出来る可能性がるので今後は React Server Components を上手くアプリケーションの設計に取り入れる事が必要だと感じています。
以下で開発しているアプリケーションではApp Routerを採用しています。
認証基盤として利用出来ないか調査した事があります。
その時は条件に合わずに採用は見送りましたが安価な費用でRDBも利用できるので、今後条件が合う時は是非とも採用してみたいサービスになります。
安価で利用できるので、低予算で運用しないといけない組織においては良い選択肢になると考えています。
https://zenn.dev/keitakn/scraps/3fd37cb11321c2
動画ファイルをアップロードすると動画内の音声を翻訳した字幕を付けた動画を生成するアプリケーションの新規開発になります。
- Next.js 14系
- Vercel
- NextUI
- Biome
- Prettier
- Python 3.12系
- Rye（Pythonのpackage管理）
- FastAPI 0.112系
- OpenAI API
- Anthropic API
- Gemini API
- Cloud Run（APIサーバーとして利用）
- Google Cloud Workflows
- Modal（サーバレスGPUを提供するサービス）
- Stripe（決済）
自分（1名）、開発者（3名）、プロダクトマネージャー（1名）
- フロントエンド側のアーキテクチャ選定
- フロントエンド、バックエンドの開発
- 開発者向けのドキュメンテーション作成
- プロジェクト進行役（スクラムマスターのような役割）
元々いたリードエンジニアの方が作成したLLMを使って動画の文字起こし、翻訳を行うコードを参考にアプリケーションとして提供可能な形に組み上げました。
スピードと品質を両立する為にフロント側は Next.js(App Router) + Vercel + NextUIで素早く実装、バックエンド側は既に社内で利用実績があったCloud Runを用いて素早く実装しました。
今回始めてOpenAI以外にもAnthropic（Claude 3.5 Sonnetを利用）やGemini APIを必要に応じて使い分けました。
結果としては以下のようにスピードと品質を両立する事が出来たと思っています。
- 限られた稼働時間（週2日）でスピードと品質を両立して3週間でΒ版をリリース、その後の正式版も遅延なく9月にリリース
- デザイナーが不在だったのでUIライブラリを用いてデザイン部分も担当（その後にデザイナーがアサインして正式なデザインに変更しています）
- 限られた時間で成果を出す為に課題の分離と優先度付けを明確にして見える化した
前回、生成AIを利用した新卒就活（日本人の就活生向け）支援用アプリケーションでお世話になった会社さんのオウンドメディアとAIエージェントの作成になります。
会社の紹介等の基本情報に加えて、受託開発に関する質問に回答したり、営業担当者との連絡も行うAIエージェント的な機能も存在します。
- Next.js 14系
- Vercel
- ESLint
- Prettier
- Python 3.12系
- Rye（Pythonのpackage管理）
- FastAPI 0.100系
- OpenAI API
- Fly.io（APIサーバーとして利用）
- Milvus（Zilliz Cloud）
自分（1名）、開発者（1名）、別会社のデザイナー（1名）、プロダクトマネージャー（1名）
- 全体的なアーキテクチャの選定、設計・開発
- 開発者向けのドキュメンテーション作成
- プロジェクト進行役（スクラムマスターのような役割）
OpenAIのtoolsを利用した設計により、AIエージェントとして機能拡張可能な設計としました。
現在はAIがエンドユーザーとの会話内容を判定して受注の見込みがありそうな場合は営業担当者にメール送信をする機能が実装されています。
ちなみにフロントエンドは多言語化対応を実施しています。
大手クレジットカード会社向けのサポート用チャットボットの開発になります。
クレジットカードに関するFAQに返答するチャットボットになります。
- Python 3.12系
- Rye（Pythonのpackage管理）
- FastAPI 0.100系
- OpenAI API
- AWS（ECS Fargateを利用）
- Milvus（Zilliz Cloud）
- LINE Messaging API
自分（1名）、開発者（5名）、プロダクトマネージャー（2名）
- チャットボットのバックエンド側のインフラ設計・構築
- バックエンド側のアーキテクチャの選定、設計・開発
関係者が多くコミュニケーションに齟齬が起きやすい状況でしたが積極的にドキュメント化を実施して各開発者から同じ質問が発生しないように意識しました。
初期段階でCI/CDの仕組みを整えて、デプロイ回数を増やす事で改善までのフィードバック期間を短くする事で素早い開発が可能になったと考えています。
生成AIを利用した新卒就活（日本人の就活生向け）支援用アプリケーションの新規開発です。
日本就活の独自文化であるES作成やガクチカ作成等を生成AIで作成出来るサービスになります。
- React 18系
- Next.js 13系
- Jest
- ESLint
- Prettier
- Vercel
- Upstash
- Auth.js
- Python 3.11系
- Poetry（Pythonのpackage管理）
- FastAPI 0.100系
- OpenAI API
- Milvus（Zilliz Cloud）
- PlanetScale
- Fly.io（APIサーバーとして利用）
自分（1名）、開発者（2名）、デザイナー（1名）、プロダクトマネージャー（1名）
- 認証基盤周りの技術選定・設計・実装
- バックエンド側のアーキテクチャの選定、設計・開発
- 開発者向けのドキュメンテーション作成
- プロジェクト進行役（スクラムマスターのような役割）
スタートアップの案件という事もあり限られた予算・期日でいかに本質的な価値を提供出来るか？を常に意識しました。
メンバー全員が副業メンバーで同期的なコミュニケーションを取る為のコストが高い状況でもありました。（スケジュールを調整するのが難しい）
その為、以下を実施しました。
- 自身が考えている事は言語化してSlackやGitHubのissue、ドキュメント化により積極的に情報共有を実施
- GitHubProjectによるプロジェクト状況の見える化を実施
- GitHubProjectのボードの運用方法等のドキュメント化
- プロジェクトに遅延が発生した時の考え方をドキュメント化して共有
- 小さくリリースして改善フィードバックのサイクルを早める事の重要性
- 不確実性を受け入れて、変化に対応する
- 計画通りに進める事が成功ではなく、価値のある物を作る事が成功
- 常に今作っている機能が本当に顧客に価値を提供するか？を意識してスコープの見直しや仕様変更の提案を実施
期日がタイト（予算が限られている為）でさらに実装面ではPythonやFastAPI、App Router等の実務では初めて触る技術（個人開発ではやった事はありました）も多くありましたが、単純なコーディング部分は積極的に生成AIを活用して開発速度を上げる等で速度面と品質の両立が出来たと考えています。
多くのサービスを運用しているクライアントの案件です。
認証・認可やアカウント登録を担っているシステムの保守性が低下していて、開発速度が低下している状態です。
また利用しているpackageのバージョンが古いが、テストコードが存在しない為、バージョンアップも容易に出来ない状況です。
これらの状態を改善する事が目的です。
- React 18系
- Next.js 13系
- Storybook
- Jest
- ESLint
- Prettier
- Vercel
- Authlete
- Upstash
自分（1名）、開発者（1名）、デザイナー（1名）の合計3名。
- プロジェクトマネージャー
- アーキテクチャの選定、設計・開発
- 開発者向けのドキュメンテーション作成
- 開発者のサポート、コードレビュー
前回の医療系メディアとは違い、アカウント情報をリアルタイムで取得したり、ログインなどの認証処理が多いのでISRではなく、SSRがメインの実装となりました。
その為、Edge MiddlewareやEdge API Routesを部分的に利用する事でレイテンシを抑える努力をしました。
結果としてSSR中心のアプリケーションながらUpstashとEdge API Routesで作成したBFF層を上手く活用する事でPageSpeed Insightsで80点付近を安定して出す事が出来るようになりました。
また認証・認可のドメイン知識を整理した事で保守性が大幅に向上しました
具体的には以前は週に2回デプロイするのがやっとな程の開発速度でしたが、1週間あたり平均して7回程デプロイされるように開発速度が改善しています。
これによりABテストを積極的に回せるようになり、事業成長に貢献出来るシステム構成に改善されました。
多くのサービスを運用しているクライアントの案件です。
医療系メディアサービスのフロントエンドの大幅改修です。
以下の問題を解決するのが目的です。
- 応徳速度が遅いので高速化したい
- フロントエンドに対しての要件が複雑化してきているので、それに耐えられる開発基盤を構築したい
また他のサービスのフロントエンドも同様の改修を予定しており、他のサービスのリプレイスが効率的に実行出来るように開発基盤を整える事も目的としています。
- React 18系
- Next.js 12系
- Storybook
- Jest
- ESLint
- Prettier
- Vercel
プロダクトマネージャー（1名）、自分（1名）、開発者（1名）、デザイナー（1名）の合計4名。
アーキテクチャの選定、設計・開発、各サービス開発者向けのドキュメンテーション作成。
開発者のサポート、コードレビュー。
技術選定にNext.jsを採用した理由ですが、ISRがメディアサービスとの相性が良く、応答速度を大幅に改善出来る可能性があったのが最も大きな理由です。
Next.jsを動かす環境としてはVercelを選択しました。
Next.jsのメリットを最大限に享受する為にはVercelが最も無難な選択だと判断した為です。
HeaderやFooter等が色々なサービスで同じデザインで利用されていました。
デザイナーさんと協業しながら、GitHub Packagesを利用して共通のUIComponentとしてprivate packageとして利用出来る仕組みを構築しました。
package化する際は smarthr-ui 等を参考にしました。
これらの対応により以下の問題が解決しました。
- 応答速度の大幅改善（PageSpeed Insightsのスコアが40%程度改善）
- フロントエンドの開発基盤と開発ルールが作成された
デザインシステムに関しては今後 SmartHR Design System のようにルールを整備して外部公開出来るくらいのクオリティに仕上げて行きたいと考えています。
多くのサービスを運用しているクライアントで同じ内容のメール送信処理を複数のアプリケーションから行っており、メール文言の修正等でも複数箇所の修正が必要な状態でした。
メール送信処理を一元化して管理しやすい状態にするのが目的です。
- Go
- AWS Lambda
- SendGrid Web API v3
- Serverless Framework
- GitHub Actions
- Terraform
プロダクトマネージャー（1名）、自分（1名）の合計2名。
郵便番号から住所検索を行うAPIと同じくAWS Lambdaを利用しました。
メール送信用のサービスにはSendGridを利用しました。
リリース前には IPウォームアップ を行い大量送信時にも送信遅延が発生しないように考慮し、独自ドメインからメール送信が出来る設定も追加しました。
これにより以下の問題を解決する事が出来ました。
- メール送信ロジックを一元管理出来るようになった
- 元々SESを使っていたのだが、それに比べてメールの到達率が向上した
- SendGridに変えた事によってバウンスメールの管理も容易になった
試算だとこのままの事業成長を続けた場合、あと少しでLambdaの同時実行制限にかかってくる可能性が出てきました。その為、現在ははApp Runnerに移行しています。
多くのサービスを運用しているクライアントで郵便番号から住所を検索する処理が色々なところで行われており、郵便番号の一覧や住所マスタも各サービスでバラバラに管理されている状態でした。
様々なサービスで利用出来るように住所検索用の共通APIを作成する事が目的です。
- Go
- AWS Lambda
- ケンオール
- Serverless Framework
- GitHub Actions
プロダクトマネージャー（1名）、自分（1名）の合計2名。
アーキテクチャの選定、設計・開発、各サービス開発者向けのドキュメンテーション作成。
Go + AWS Lambda で ケンオール のAPIに通信を行い、住所情報を返すAPIを実装しました。
住所検索APIとして ケンオール は新しいサービスですが、APIインターフェースの設計が非常に優れていて、かつ低料金で利用出来るので、採用しました。
それにより以下の問題を解決する事が出来ました。
- バラバラになっていた郵便番号から住所を取得する処理が統一された
- 住所マスタのメンテナンスが不要になった
CI/CDの設定はGitHub Actionsを用いて行いました。
スピード感を重視して AWS Lambda を利用しましたが、リリース後、アクセス数が増えてきており、Lambdaの同時実行制限にかかってくる可能性が出てきました。
コールドスタートも発生しているので、今後はApp Runnerに移行する可能性があります。
クラウドファンディングサービスでプロジェクトの実行者と支援者がメッセージのやり取りを出来る機能があるのですが、実行者が全ての支援者に一斉送信を行う際にタイムアウトが発生して送信出来ない問題がありました。
支援者が多いプロジェクトでも一斉送信が出来るように改修する事が目的です。
- Ruby on Rails（5系）
- Amazon Aurora（MySQL5.7互換）
- SendGrid
プロダクトマネージャー（1名）、自分（1名）の合計2名。
メッセージ一斉送信機能を再構築する為に必要な課題出しや設計・開発。
メール送信に時間がかかるという問題とDBへのデータのインサートに時間がかかるという問題がありました。
データ量が多く、テーブル構造を大幅に変える事が難しかったので、既存のテーブル構造を活かしつつ、一斉送信用の関連テーブルを作る事で対応しました。
メール送信にはSendGridを利用する事を提案し実現しました。
SendGridは1000件ずつアドレスを指定して送信出来るので、メールの送信時間を大幅に短縮出来る事が選定理由です。
また処理をDelayed Jobを使って非同期処理にしました。
その結果、以下の問題を解決出来ました。
- 改修前は3000件程度が限界だったが、20000件を超えても送信出来るようになった
- 非同期処理にした事でユーザーの待ち時間がなくなった
Rails の devise で構築された認証基盤を IDaaS（Identity as a Service）を利用した形に置き換える。
また初期リリースのスコープではないが、様々なサービスのIDを利用したソーシャルログインやパスワードログイン以外の認証手段も追加予定です。
- Go（CognitoUserPoolのカスタムLambdaやUserPoolのデータを操作するAPIを実装）
- React（16系）
- OpenAPI（V3）
- Terraform
初期は開発リーダー1名、自分の2名。
途中から開発者2名と相談役の方が1名追加。
- 既存の認証基盤から新しい認証基盤にデータを移行する方法を設計・実装
- ログイン状態を維持出来る仕組みの設計
- Goを用いて、CognitoUserPoolのカスタムLambdaやUserPoolのデータを操作するAPIを実装
- ERBで作成されていた登録フォームやログインフォームをReactを使って再構築
スケジュールも短めだったので、最初に案件概要を聞いた時は Auth0 を使う事でスムーズな認証基盤の移行が出来ると考えましたが、予算的な都合でより安価で運用出来るCognitoUserPoolを利用する事になりました。
CognitoUserPoolはAPIのレートリミットに厳しい制限があったり、カスタマイズLambdaやユーザー移行Lambdaを駆使しないと無停止でのデータ移行が難しかったりしたので、課題を解決する為に必要な技術検証を慎重に行いました。
その結果、以下のような状態を構築する事が出来ました。
- サービスを停止する事なく既存認証基盤から新しい認証基盤にデータを移行する仕組みが出来たので、長時間のメンテナンスによる機会損失を回避出来た
- 少ない工数でソーシャルログインの追加が行えるようになった（OpenIDConnectに準拠している必要はある）
クラウドファンディングのプロジェクトには多くの応援コメントが投稿されますが、コメントが多すぎるプロジェクトではコメント表示遅延が発生していました。
コメントが多いプロジェクトでも正常に全てのコメントが表示されるようにする事が目的となります。
- React（16系）
- Ruby on Rails（5系）
- Amazon Aurora（MySQL5.7互換）
- OpenAPI（V3）
プロダクトマネージャー（1名）、自分（1名）の合計2名。
他コードレビューなどに関わって頂いた方が3名ほど。
- OpenAPIのスキーマを用いてAPIの設計
- 上記スキーマを元にRailsでAPIの実装
- ERBで作成されていた画面をReactを使ってSPA化
以下のような制約があり、厳しい状況でしたが、現場のエンジニアの方のサポートもあり何とか乗り切る事が出来ました。
- 優先度が高く、期日が短かった
- コメント取得用のテーブル構造を変更する事は時間的な制約上非常に難しい
- こちらの現場がOpenAPIのスキーマを導入してまだ間もない事もあり、決まっていないルールが多数あった
- この現場にアサインされて初の案件だったので、ドメイン知識がほぼ0の状態だった
こちらの現場では段階的にアプリケーションのマイクロサービス化を行っていた事もあり、現場のエンジニアの方と話し合った結果、以下の方針で実装する事になりました。
- コメントの表示部分はSPA化、スクロールする度に新しいコメントを取得して表示
- コメントを取得するAPIを実装（ページングも考慮する）
バックエンドのAPIを実装する際はスロークエリが発生しないように心掛け、フロント側の実装の際は React Developer Tools を見ながら、パフォーマンスを考慮し実装しました。
APIのインターフェースも後にDBのテーブル構造の変更を行った後でも、インターフェースを変えずに運用出来るように意識して設計しました。
またOpenAPIスキーマの設計の際は決まっていない事が多かったですが、現場のエンジニアの方と議論して一緒に設計の際のルール決めなども行いました。
以下の現象が解消されたので案件の目的は達成する事は出来たと思います。
- 大量のコメントが存在するプロジェクトでもコメントの表示遅延がなくなった
- スクロールを行う事で全てのコメントを確認出来るようになった（元々コメントの表示件数に上限が設置されていた）
ユーザーの様々なアクションに関して通知を送るAPIをマイクロサービスで開発。
（例）ユーザーが投稿した記事にコメントが付いた際や、コメントに返信があった際に通知を送る。
- AWS（EKS）
- Go
- gRPC
- Terraform
自分と開発者1名。
- アーキテクチャ全体の決定
- Goを用いたgRPCでアプリケーションの開発
- EKS上でアプリケーションを構築出来る基盤が出来た
- PHP中心の現場でGoでの開発の知見を広める事が出来た
Goでの開発能力を向上させる為、Goに詳しいエンジニア（社外の方です）に講師を依頼したりするなどを行い、積極的に技術情報をアウトプットする事を意識しました。
この現場はPHPが中心だったので、Goでも開発で注意すべき点や、PHPで書いていたコードをGoで書く場合、どのような点に気をつけるか？等を社内ドキュメントにまとめました。
これによってこのプロジェクトに深く関わっているメンバー以外もGoによる開発がある程度出来るようになりました。
リリースを行ったものの、予算的な都合で当初予定していたよりも小規模な形で運用する事になってしまいました。
時間的な理由でEKSの構成管理やCI/CD等の仕組みが納得出来る物に出来なかったのが悔やまれます。
自分がKubernetesやgRPCを扱うのが初めてだった事もありますが、もう少し深く技術調査をすべきでした。
Kubernetesを扱えた事自体は貴重な経験になったと思っています。
クラウド広告運用ツールの新環境の構築。
- AWS（様々のサービスを利用）
- Terraform
自分とCTOの2名
- アーキテクチャ全体の決定
- Terraformを用いてマルチリージョンで運用可能なクラウド環境を構築
- コード管理されていないインフラ環境がコードで管理されるようになった
- 海外進出の際にも他国のリージョンでアプリケーションが運用可能になった
EC2で運用中のアプリケーションをFargateで動作するように改修。
- AWS Fargate
- AWS CodeBuild
- ECR
- Docker Hub
- Terraform
- CircleCI
- Gatling（性能試験ツール）
自分と開発者1名
- 全体的な方針決め
- Fargateのログを分析出来る基盤の構築
- 各アプリケーションのDockerfileの作成
- コンテナベースになった事で開発者同士の環境差異による問題が減少
- デプロイ速度の高速化
- 運用料金の最適化
一部のアプリケーションは Twelve-Factor App の要件を満たすように改修を行いました。
個人としてもDocker運用の為の基本的なノウハウを蓄積する事が出来ました。
看護師さん向けのコミュニティサイトのDBも含めた全面リプレイス
- PHP7.2（Laravel5.5）
- TypeScript
- Next.js（React）
- Nuxt.js（Vue.js）
- AWS（様々なサービスを利用）
- JIRA（プロジェクト管理ツール）
- Confluence（ドキュメント管理ツール）
- GitHub
- CircleCI
- 開発リーダー（自分）、開発者5名、プロジェクトマネージャー1名
- システム全体のアーキテクチャを決定
- スクラムマスターとしてスクラムチームの開発効率を上げる為に様々な施策を実施
- AWSを用いたインフラ構築全般（Terraform構成管理、デプロイの仕組み、ログ解析基盤）
- AWS Lambda + TypeScriptを用いたOpenIDConnectに準拠したAPIの認可基盤
- PHP7.2（Laravel5.5）を用いたWebAPIの開発
- Next.js, Nuxt.jsによるフロントエンドの開発
- CognitoUserPoolを用いたユーザーの認証基盤（管理サイトで利用）
- モノリシックな構成からマイクロサービス（厳密なマイクロサービスではない）に移行した事でシステム全体が疎結合になった
- レガシーな開発手法を行っていたチームにAtlassian製品の導入やZenHub、AWSの導入等を行った事で開発効率が大幅に上がった
- 自走出来る開発チームを作り上げる事が出来たので、開発効率、品質共に大きく向上させる事が出来た
チームマネジメントからアーキテクチャの設計、インフラ構築、フロントエンド・バックエンドの開発・設計等、ほぼ全ての工程に関わる事が出来ました。
データ移行もトラブルが少なく、前回関わったリプレイス案件よりもスムーズにプロジェクト進行を行う事が出来ました。
こちら はその時に作ったシステムの一部を紹介したスライドです。
老朽化していた会員基盤システムをDB構造等も含めて全面的にリプレイス。
会員数はこの時点で約2000万人程になります。
- Java8(API サーバ)
- Spring Framework4系
- Ruby on Rails 4（管理サイト）
- MySQL5.6
- Couchbase3系（バックエンドのキャッシュサーバとして利用）
- Redis ※APIが利用するメッセージングサーバとして利用
- AWS（ステージング環境、性能試験環境として利用）
- Vagrant
- Ansible
- Docker
- JIRA（プロジェクト管理ツール）
- Confluence（ドキュメント管理ツール）
- Bitbucket（Git管理ツール）
- Jenkins
開発リーダー（自分）、技術顧問1名、開発者7名、ディレクター2名、プロジェクトマネージャー
- 開発リーダー（自分）
- 旧DBから新DBへのデータ移行計画の作成
- データ移行時のテストを自動化
- 全体的なシステムアーキテクチャを決定
- 新会員基盤APIの設計
- 新会員管理サイトの要件定義・設計・開発
- Ansibleを用いたサーバ構成管理
- APIの開発
- DB構造の一新をした事で性能が大幅に向上し急激な会員数の増加にも耐えられるようになった
- 性能試験環境をAWSで構築した事により、ミドルウェアの性能試験を気軽に行えるようになった
大規模案件で技術負債が多く困難を極めましたが何とかやり遂げる事が出来ました。
この案件で主に学んだ事は以下の3つです。
- リプレイス案件で最も高難易度なのはデータの移行である事
- 少数精鋭のチームを作る事の重要性（頭数を揃えても開発スピードは上がらない）
- 技術検証を事前にやる事は非常に大切である
社内向けのAPIを一元管理する為、OAuth2.0の仕組みを使った認可基盤を開発。
Amazon API Gatewayの簡易版のようなイメージです。
- Node.js（Express）
- Redis ※API Gatewayのキャッシュサーバとして利用
- PHP5.4.X（FuelPHP）※クライアントID等を管理する管理側のサイト
- MySQL5.5
- Jenkins
- JMeter
プロジェクトマネージャー、設計・開発者（自分含め6名）
- クライアントID等を管理する管理側のサイトの要件定義〜設計、開発まで全て
- Node.jsでのAPIの実装・ユニットテストの作成、パフォーマンステストの実施
- 今まで独自実装していたAPIの認証・認可の仕組みが一般的な仕組みに置き換わりました。
- APIのアクセス管理が出来るようになったのでどのクライアントがどの機能を利用しているか明確になりました。
- 今までのプロジェクトでは出来ていなかった、継続的インテグレーションが出来るようになり、リリース後の不具合が大幅に減少しました。
OAuthProviderの実装はOpenIDConnectの公式仕様を見ながら実装に落とし込む事が出来ました。
この案件でRFCや公式ドキュメント等の1次情報（主に英語の情報）を読むことの重要性を改めて理解しました。
独自実装されたデプロイツール（テストなし、再現環境なし）を一般的なツールにリプレイス。
- Jenkins
- Capistrano（Ruby）
自分、プロジェクトマネージャーの2名
- 要件定義〜設計、開発まで全て
今まで俗に言う「秘伝のタレ」だったデプロイツールを一般的なツールに置き換える事で誰でもメンテナンスが出来るようになりました。
某大手ECサイトにソーシャルログイン機能を導入。
初期リリースではFacebookとGoogleに対応しました。
- PHP5.3.X
- Zend Framework 1.X.XX
- Facebook API
- Google API
自分（開発リーダー）、開発者1名、ディレクター1名の計3名
- 案件の要件定義
- 設計全般
- プログラム実装
リリース後、一ヶ月で会員登録数が50万人増加しました。
会員登録という重要機能だったので、安全なOAuthクライアントの実装方法を調査し設計・実装しました。
この案件でOAuthやOpenIDConnectの基礎的な内容を理解する事が出来ました。
ユーザーの個人情報を取得するAPIの性能向上。
- PHP5.3.X
- Zend Framework 1.X.XX
- MySQL5.1系
- MySQL5.5系
自分1人（レビュワーに先輩エンジニア1名）
- memcachedを利用したキャッシュの導入による処理高速化
- MySQLのクエリチューニングによるSQL実行速度の高速化
- MySQLサーバーのバージョンアップ
テーブル構造が10年近く前から存在するレガシーな物という制約がある中でSQLの組み立てを工夫して性能改善を行いました。
平均応答速度が400msから150msに改善する事が出来ました。
性能的に実用レベルに達した事もあり、これ以降このAPIが実際のプロダクトで利用されるようになりました。
ユーザーデータにアクセスしている機能をWebAPI化し分離する。
- PHP5.3.X
- Zend Framework 1.X.XX
- MySQL5.1系
自分を含めエンジニア3名、ディレクター1名
- APIの開発・ユニットテストの作成
- APIの内部設計（外部設計は先輩エンジニアが担当）
正社員エンジニアとしては初めての案件です。
ユニットテストが書かれていないクラスにも積極的にユニットテストを追加しテストの自動化に貢献しました。
コードレビューを通じて、変更に強い設計手法、Gitの運用ルール等を習得しました。