keitakn の職務経歴、スキルシートです。
生成AI・LLMを利用したプロダクト開発と、AIエージェントの利用を前提とした開発体制づくりを得意としています。
2023年からLLMを利用した開発案件に参加し、直近の2年間はAIエージェント向けの開発基盤（ハーネス）の構築、MCPサーバーを含むバックエンド基盤の設計、AI駆動開発の導入支援を中心に仕事をしています。具体的な実績は 提供できること と 主な職務経歴 をご覧ください。
| 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 |
- AIエージェント、LLMを利用したアプリケーションの設計・開発
- LLMによる旅程生成機能や、観光スポットのデータを収集するAIエージェントなどの開発実績があります
- AI駆動開発の導入支援
- AIエージェント向けのハーネス構築、コーディングルールやCIの整備を行い、2つの組織で開発体制の刷新を実施しました
- MCPサーバーを含むバックエンド基盤、認証基盤の設計と刷新
- 直近では有効会員400万人以上のサービスの認証基盤移行を担当しています
- ビジネス状況に合わせた技術選定、アーキテクチャ設計
- 経営・事業の状況を踏まえた開発優先度の整理
- 現在参画中の企業では経営会議にも参加しています
- AIエージェントが高品質なコードを生成し続けられる開発基盤（ハーネス）を作る事
- コーディングルールやCIの整備、テスト戦略、git worktreeを使った並列開発の仕組み化など
- 対象のソフトウェアが解決しようとしている問題領域を理解して、ビジネス状況に合わせた技術選定を行う事
- テストコードや設計手法を工夫して、保守性・拡張性の高いシステムを構築する事
- 未知の技術でも比較的短い期間でキャッチアップを行う事
- アジャイル開発（スクラム）を用いたチームビルディング
- フロントエンドからインフラ構築も含めたバックエンドまでWeb開発の一通りの工程を1人でこなす事が出来る事
- 相手に伝わりやすい非同期コニュニケーションを行う事が出来て、コミュニケーションの仕組みを構築出来る
過去には既存システムの問題点を解決したリプレイスや新規開発案件を数多く対応しました。
現在の状況を見て最適なシステム構成を提案・実行させて頂きます。
またチームや組織の心理的な安全性を再重視しており、相手によって態度を変えない、フラットで丁寧なコミュニケーションを取る事を常に意識しております。
最近は自らをプロダクトエンジニアと名乗っています。
プロダクトを第一に考え、プロダクトに最適な技術選定や問題解決手段を選択するように心がけています。
- Webデザイン（CSSは出来ますがUX等を考えたUIを作るスキルはありません）
- 背景・目的が不明確で言われた事だけをやる開発スタイル
フロントエンド、バックエンド、インフラ（クラウド）でそれぞれどのような事を意識しているかを記載しておきます。
最近はNext.js（App Router）とReactをメインに扱っていますので、これらの技術を使った際の話を記載させて頂きます。
Propsにのみ依存する純粋なComponentと副作用を持つ部分を明確に分ける事を意識しています。React Server Componentsが使えるようになってからは、Server ComponentとClient Componentの使い分けもこの延長線上で考えています。
テストコードに関しては以下の2つのテストにリソースを投入しています。
- Storybookを流用したテストコード
- E2Eテスト（フロントエンドの動作担保を行う為には、やはりE2Eテストが必須）
Componentが持つ振る舞いはStorybook上で全て表現し、Chromaticで誰でも閲覧・レビュー出来る状態にしています。UIに関するコミュニケーションが円滑になるので、少々時間はかかりますが行う価値がある方法だと思っています。（以下は自分が書いた記事です）
https://zenn.dev/keitakn/articles/storybook-deploy-to-chromatic
友人と共同運営しているサービス LGTMeow では自分がフロントエンドの開発を担当しています。
https://github.com/nekochans/lgtm-cat-frontend
最近はPython（FastAPI）をメインに書いていますので、その前提で記載させて頂きます。
あまり重厚なフレームワークは使わずに、FastAPIなどの軽量フレームワークで小さく始める事をしています。
とは言え、テストを書きやすい構造にしておかないと後々プロジェクトが肥大化した際に困る事になるので、レイヤードアーキテクチャを採用してDDDライクな設計にする事が多いです。
テストコードはアプリケーション層（ユースケース層とも言う）に対して必ず実装するスタイルを取っています。この形であれば後に大規模なリファクタリングが必要になった際もテストコードを頼りに進めやすいからです。
DBへの接続部分はモックを使わずにテスト用のDBを用意するスタイルを基本と考えています。（モックに差し替えられる設計にはした上で）
DBに意図した通りにデータが登録されるかどうかもバックエンドのAPIにとっては重要なファクターなのでテストコードで担保すべきという考えからです。テストの実行速度が遅くならないように以下の記事のような工夫も行っています。（以下は自分が書いた記事です）
https://zenn.dev/keitakn/articles/accelerate-planetscale-test-code
負荷対策については、会員数2000万人程度、スループット5000rpsの負荷がかかった状態で参照系のAPIが150ms以内にレスポンスを返す事を目標としたシステムを担当した経験があります。性能試験を行う際は、システムをスケールアウトした際にそれに伴って性能が向上する事を確認するようにしています。
参考までに生成AIを利用した個人サービス AI Meow Cat のソースコードを記載しておきます。（Python + FastAPIによる実装）
https://github.com/nekochans/ai-cat-api
過去にはそこそこの規模（会員数100万人ほど）のWebサービスのリプレイスでAWSのネットワーク設計をゼロから行った事があります。
最近はスタートアップ企業でのお仕事が多い事もあり、Fly.ioのような安価で簡単にコンテナ実行環境が構築出来るプラットフォームや、PlanetScaleのようなDBaaS（Database-as-a-Service）を選定する事が多いです。インフラ環境のメンテナンスコストを可能な限り削減し、開発リソースをアプリケーション開発に集中させるという考え方からです。
とは言え一定規模以上のシステムだとAWS等を利用したほうが費用も安くノウハウもたくさんあるのでその場合はAWS等を利用します。
AWSリソースはTerraformで構成管理を行い、AWS Well-Architected フレームワーク 等のベストプラクティスに準拠したセキュリティを意識した設計を心がけています。
| 名前 | 備考 |
|---|---|
| TypeScript | 最も経験が長い言語です。ブラウザ、Node.js共に経験があり、最新の仕様にも追従しています。 |
| Python | 2023年にLLMを利用した開発案件で使い始め、現在はバックエンドの主力言語です。FastAPIでの基盤刷新を1人で完遂した経験があります。 |
| Next.js（React） | 2015年頃からReactで開発しています。新規開発でApp Routerを複数回採用しました。 |
| FastAPI | 業務でのバックエンド基盤の刷新で継続して利用しています。バックエンドをゼロから作る際の第一候補です。 |
| Hono | 個人開発の他、業務でもバックエンドのアプリケーション層で利用しています。 |
| MySQL | 設計からパフォーマンスチューニングまで対応出来ます。最近はPlanetScaleのようなDBaaS上で利用する事が多いです。 |
| Terraform | AWSやGoogle Cloudの構成管理でよく利用しています。 |
| GitHub Actions | CI・CDの構築で利用しています。開発の初期段階からCI/CDを整備する事を重視しています。 |
キャリアの前半はPHP（Laravel、FuelPHP等）を5年ほど、その後はGo、Ruby（Ruby on Rails）、Node.js（Express）等でバックエンドの開発を行ってきました。JavaやScalaも保守案件で触った経験があります。
AWSは2015年頃から利用しており、EC2、ECS、AWS Lambda等を組み合わせてゼロからインフラ全体（Webアプリケーションも含む）を構築した経験があります。CognitoやDynamoDBを使った認証・認可基盤の構築、Kinesis Data FirehoseとAthenaを使ったログ基盤の構築なども行いました。具体的にどの案件で何を使ったかは 主な職務経歴 をご覧ください。
Google Cloudは株式会社Algomaticの案件で利用しました。にじチャットで、REST APIをCloud Runで動かす為のインフラをTerraformで構築しています。構成はGoogleが公開しているベストプラクティスに沿った形にしました。
PostgreSQLはにじボイス、にじチャットで利用しました。認証基盤にSupabaseを採用した為、RDBもSupabaseに付属するPostgreSQLをそのまま利用する構成にしました。
その他、オンプレ環境でRedis Sentinelを使った自動フェイルオーバーの仕組みを構築した経験や、LLMを利用した案件でMilvus(Zilliz Cloud)のようなVectorDBを利用した経験もあります。
経験した事がない技術のキャッチアップコストはAIエージェントの活用で大幅に下がっているので、ここに載っていない技術での開発もそれほど問題にならないと考えています。
私のGitHubを見て頂き、どの程度の技術力なのかを判断して頂くのが良いと思っております。
コーディングエージェントに関しては記載していません。
コーディングエージェントが開発を行うように設計を行うのはもはや当たり前でコーディングエージェントのモデルの進化に一喜一憂する事は本質的ではないと考えているからです。
もちろんClaudeはMax (20x)に入っていますし、OpenAIも200$のプランに加入しているので常にフロンティアモデルで開発をしています。（費用は私自身が負担しています）
私は安いモデルで工夫してどうにかするみたいなアプローチは採用しておりません。
開発においては成果物の品質が最も重要ですので、私の考えではモデルの費用を節約するよりも今の高性能モデルを使って改善を加速させる事が最も重要と考えています。
https://tanstack.com/start/latest
AIが生成するコード品質を優先して業務では Next.jsのApp Routerを使う事が多いのですが、
TanStack Startは以下のような点が優れていると感じます。
- ルーティングからサーバー関数まで型安全に書ける事
- Next.jsに比べて色々なプラットフォームで動作させる事が容易
Cloudflareには未来があると感じています。
Durable Objects（オブジェクト毎に専用のSQLiteデータベースを持てる仕組み）などの便利な仕組みがあります。
WebSocketのHibernation APIと組み合わせるとリアルタイム通信を安価に実装出来たり、将来的にどこかで採用する機会があれば採用したいと考えています。
https://developers.cloudflare.com/durable-objects/
以前実験的に導入した事があってその際は結局不採用になりましたが、基本的に育てていくAIエージェントとしてはこれが一番筋がいいと思っています。
普段から自分の雑務等はAIエージェント向けのエージェントスキルとして作り込んでいるので将来的には Hermes Agent に任せられないかを考えています。
ちなみに以下のようなマネージドサービスがあります。まずは個人開発で運用している LGTMeow の裏側の業務から徐々に移行しようと思います。
最近Dockerfileを書けばバックエンドのコンテナも動作するようになりさらに便利になりました。
Mastraも裏側でVercel AI SDKを使っているので、AI周りも強いのでやっぱりNext.jsを運用するならVercelかなーと思ってます。
ちなみに個人開発で運用している LGTMeow はVercelです。
最近出た eve も楽しみですね。
https://vercel.com/blog/introducing-eve
課金すればDBの作成数に制限がないので、マルチテナントでDBを安全に分割出来るアーキテクチャが現実になってきたなと感じます。
このサービスとCloudflareのD1がSQLiteをProduction Readyにしたなと感じています。
ちなみに個人開発で運用している LGTMeow の認証用のDBはTursoです。
OpenAIのRealtime APIやGeminiのLive APIのような、音声や映像を使ってリアルタイムにAIと会話する為のAPIに興味があります。
https://aistudio.google.com/live-api
以前、GeminiのLive APIでAIと擬似的なビデオ通話が出来るアプリケーションを作りました。（大分古いのでもう動かないです）
https://github.com/keitakn/realtime-api-web-console
私は将来的に自分の分身のAIがビデオ会議等に参加してきて欲しいなと考えていたりするのでリアルタイムでのビデオ通話や音声通話の分野は興味あります。
2017年に自分が中心になって実施した。看護師さん向けのコミュニティサイトの案件を受け持った大手人材系会社さんの案件になります。
2026年-1月〜2026年4月で看護師さん向けのコミュニティサイトのリプレイスを実施しましたが今回は看護師さん向けのメディアサービスの認証基盤のリプレイスを実施する事になりました。
- Better Auth 1.6 系
- Next.js 16系（App Router）
- Prisma（v6、途中からv7系に変更）
- Vitest
- TypeScript
プロジェクト責任者1名、開発リーダー1名、自分1名
合計3名
元々独自実装されていた認証基盤をNext.js 16系（App Router）で再構築します。
こちらもAI向けのハーネス構築から始めて基本的な技術基盤を実装した後でデータ移行の計画を作成した後にデータ移行を実施します。
有効会員が400万人以上いるのでデータ移行の難易度はかなり高いですが、AIエージェントを上手く活用してデータを安全に移行する為のスクリプトを実装しています。
まだ途中なので案件終了後に記載します。
旅行を支援するプロダクトを提供する自社サービス企業 の旅行支援アプリの超大型アップデートになります。
UI側はもちろんの事、バックエンド側にも大幅な改修が必要で新しい基盤を構築するレベルの開発が必要となる案件です。
- Python 3.14.6
- uv（Pythonのpackage管理）
- FastAPI 0.137.1系
- Fly.io
- PlanetScale
- Mastra（1.35.0）
- Flutter 3
自分（1名）、CEO（1名）、CTO（1名）、エンジニア（3名）、プロダクトマネージャー（1名）
合計7名
- バックエンド側で必要となった新しいデータベースの設計
- バックエンド側の開発を並列で行う為のハーネスを整備
- 旅行で使う観光スポットのデータを収集するAIエージェントの開発・設計
このプロジェクトの実施が決まった際にまず最初にやったのは以前自分が作成したAIエージェントのハーネスをgit worktreeを使った並列実行前提の構成に変更する事でした。
具体的にはAPIをバージョン毎に管理出来るようにディレクトリ構成を分けたり、各アプリ毎の機能毎にAI向けのルールを整備して新旧のバージョンでAIに余計なコンテキストが渡らないような設計にしました。
これによって並列で開発が実施出来るようになりました。
また以前よりもAIエージェントが賢くなったので自社で持てなかった観光スポットのデータの収集（もちろん合法的な方法でやっています）や間違った観光スポットのデータを訂正出来るAIエージェントの開発等もこの機会に実施しました。
期日が厳しい案件でしたが、テーブル設計も将来的な仕様変更に耐えられるようにしっかりと行い変更に強い構造にしました。
前回私がAI向けにハーネスの基礎を作り込んでいた事もあり、規模の割には短い時間で高品質なアプリをリリース出来ました。
これまでは期日と機能のスコープはトレードオフで一部の機能をリリース後対応にする事もありましたが、今回の改修は機能が多くデータ構造にも大幅な追加・変更・データ移行が必要でしたが全て当初の目標通りに達成出来ました。
AIの発展ももちろん追い風にはなっていますが、旅程生成や観光スポットのオススメアルゴリズム等は以前までのバージョンのアプリより格段に向上しました。
プロダクトマネージャーが実施している、ユーザーインタビューにも参加しているのですが、前回バージョンのアプリよりも良いフィードバックが得られています。
新しい事をやる際には最初の設計に時間を使う事が多く、並列開発の仕組みはすぐには有効に機能しませんでしたがリリース後の改善対応等はこれまでの倍くらいのリリース速度で機能改善が出来るようになりました。
AI活用でプロダクトの品質を大幅に向上させる事が出来た良いプロジェクトでした。
2017年に自分が中心になって実施した。看護師さん向けのコミュニティサイトの案件を受け持った大手人材系会社さんの案件になります。
自分が離脱してから、色々と事業も方向性もかわりサービスの方向性を大幅に変える事になりました。
AIを使って開発体制を見直し開発速度を上げられないかの相談を持ちかけられたので、サービスの一部をリプレイスしつつ、AIネイティブな開発が出来るように開発体制をアップデートしました。
- Bun（1系）
- Hono（v4系）
- Next.js（v16系）
- Tailwind CSS（v4系）
- Prisma（v6、途中からv7系に変更）
- Vitest
- TypeScript
- Ultracite
- Claude Code
- Codex CLI
- AWS全般
プロジェクト責任者1名、開発リーダー1名、自分1名
合計3名
LaravelとNuxt.jsで出来たサービスをNext.jsのApp Routerを用いた形に置き換えました。
Ultracite 等のAI用のルールが含まれたLinterの採用等、テストケース毎にDBを作成する等の工夫を行いCIの実行時間が長くならないようにしました。
Tailwind CSS 4系やNext.js 16系はAIが対象バージョンの知識を持っておらず古いコードを書いてしまう問題がありましたが、そのあたりのコーディングルールを整備したりLinterによるルール縛りを行う事で最新のNext.jsのApp Routerに最適なコードが生成される土台を整備する事にしました。
ちなみにORMのPrismaですが私の中では現在は Drizzle ORM のほうが型安全性やシンプルさでAIが生成するコードが安定しやすいので推奨はDrizzle ORMでしたが、組織のエンジニアの習熟度も考慮して最終的にはPrismaを選択しました。
またCloudflare等で運用費用を安価にする提案も行いましたが組織内でAWSでのインフラの運用が非常に高いレベルで出来ている事からAWSを採用するメリットが大きいと判断してAWSを引き続き採用しました。
対象のプロダクトには常時5名のエンジニアを必要とする規模でしたが、私が新アーキテクチャと開発基盤を整備した影響で2名体制の開発・運用が可能になりました。
私が入る前はNext.js App Routerへのリプレイスを私を含めて6名で行う予定だったそうですが、最終的には私と開発リーダーの2名で完了させる事が出来ました。
私は関わってはないですが、残った4名のエンジニアで進めたかった別プロダクトの開発を進める事が出来たという話を聞いており、組織内の開発生産性を大きく向上させる事が出来ました。
旅行を支援するプロダクトを提供する自社サービス企業でのMCPサーバーおよびAIを利用した旅程生成機能の新基盤開発 と平行して組織全般の業務に対してAIエージェント利用を前提とした開発体制の再構築を実施しました。
- Claude Code
- Codex CLI
自分（1名）、CEO（1名）、CTO（1名）、エンジニア（2名）
合計5名
- どの部分をAIに任せるのかの業務設計の提案
- 導入ツールの選定
- AI向けのハーネスの構築
- 各リポジトリ向けのAI向けのハーネスの構築
どのような業務があるのかを洗い出して自動化出来る部分を徹底的に自動化しました。
まずは業務内容をスキル化してGitリポジトリにして誰でも利用出来るようにしました。
その後、一部はAIエージェントやBatch処理による定期実行に切り替えました。
組織全体の生産性を大幅に向上させる事が出来ました。
組織全体で以前よりも 何を作るべきか？ という部分に時間を割くことが出来るようになりました。
これは どう作るべきか？ という部分をAIが解決しやすい状態に全体を設計した事による成果だと考えています。
自分も経営会議等に参加するようになり、組織全体を見た上でプロダクト開発を行うという一段上の視点を持って仕事が出来るようになりました。
旅行を支援するネイティブアプリを提供する自社開発企業にて、バックエンドサーバーの全面刷新を行いました。
当初はRuby on Railsを用いたAPIサーバーが存在しましたがバージョンが古く、またRubyにはLLMのAPI利用を行う為のSDK等の整備が不十分な事から自分からアーキテクチャの刷新を提案しそれを実施しました。
- Python 3.13系
- uv（Pythonのpackage管理）
- FastAPI 0.115系
- google-genai（2025年に出たGoogle Gen AI SDKの新バージョン）
- Fly.io
- PlanetScale
自分（1名）、CEO（1名）、CTO（1名）
合計3名
- 技術選定
- バックエンド開発、インフラ構築全般
新しいシステムでは以下のようにAI主体で開発が出来るように徹底的に開発環境の整備を実施しました。 （もちろん開発速度は落とさないように事業上優先度の高い開発は平行して行うようにしました。）
- PlanetScaleによるデプロイリクエストを利用したスキーマ管理の仕組みを入れたので、安全にDB構造を変更・ロールバックが出来るようになった
- 最初からAI駆動で開発を行う前提でAIエージェント向けのガードレール（AGENTS.md や CLAUDE.md の整備やCIの仕組みを徹底的に整備する事でAI主体で開発出来るコードベースとした）
- AIが設計方針に迷わないように、ドメイン駆動設計等で分かりやすいアーキテクチャとして採用されるオニオンアーキテクチャを採用（もちろんAIルール）
- テストコードの作成ルールを徹底的に整備、テストケース毎にDBを独立した形で生成するようにしてDBを使ったテストを並列で実行出来るようにしてCIの速度が落ちない事を徹底しました
- 元々RailsのDB構造に引っ張られないように技術負債を持ち越さない形でDBのテーブル設計を再構築しました、データ移行もサービスを止めない形で段階的に行い3ヶ月で必要なデータを全て移行しました（事故も一度も発生しませんでした）
- LLMによる旅程生成機能でいつでも裏側のLLMのモデルを変更出来るような設計を実施しました
- LLMによる旅程生成機能でLLMの出力を上手く制御する為に旅程機能の評価を行うエージェントスキルを作成して常にそれを実行するようにする事で旅程の質を低下させないようにしました（この仕組みが存在する事でLLMのモデルを変更を容易に行えるようになっています）
開始当初は旅行業界に対するドメイン知識が十分ではなかったので、DB設計部分の一部でCTOのレビューを依頼しましたが、基本的には他のエンジニアの手を止める事なく最後まで完遂しました。
大規模な移行でしたが、開始10日でメインの一部の機能を移行する事に成功しました。
その後、3ヶ月をかけてアプリ機能の開発と平行して主用機能をほぼ全てを移行が完了しました。
新しい技術基盤に移行した事で組織全体の生産性を大幅に向上させる事が出来ました。
AIエージェントの導入効果もありますが新機能開発に1ヶ月程かかっていたのが、新システム移行後は比較的大きな開発でも3日〜5日で形になるようになったので明らかに組織全体の生産性が上がったと全員が認識出来るレベルになりました。
音声合成サービス、にじチャットの開発業務。
にじボイスは入力されたテキストを音声データに変換するサービスです。
- Next.js 15系
- Vercel
- HeroUI
- ESLint
- Supabase（認証基盤）
- Hono（バックエンド側のアプリケーション層で利用）
- Python 3.13系
- uv（Pythonのpackage管理）
- FastAPI 0.115系
- 独自構築されたTTS
- Cloud Run（APIサーバーとして利用）
自分（1名）、開発者（2名）、事業責任者（1名）、クリエイター（1名）、デザイナー（1名）
合計6名
- プロトタイプ作成
- 全体のアーキテクチャ選定
- 認証基盤選定
- フロントエンド開発
- バックエンド開発
- インフラ構築
メインの成果と言えるかどうか微妙ですが、このサービスを開発しようという意思決定に至った経緯ですが、自分が年末にGeminiのLive APIでにじボイスのキャラクターとおしゃべり出来る社内アプリを開発して遊んでいた事がきっかけになります。
完全に結果論ですが、自分が遊びで作った物をきっかけに本格的なプロダクトとしてリリースされるという経験は初めてだったので、良い経験になったと思っています。
にじボイスで開発した音声APIの基盤等もありますが、音声チャットの部分に関しては自分が遊びで作った物を流用出来たりしたので、β版を3週間程でリリースする事が出来ました。
サービスは2026年の2月に閉鎖してしまいましたが、ここで培ったAPIの基盤やインフラ構築の基盤等は他のサービスの流用される事も多く、様々なサービス開発を加速させる要因の1つになれたと考えています。
音声合成サービス、にじボイスの開発業務。
にじボイスは入力されたテキストを音声データに変換するサービスです。
- Next.js 15系
- Vercel
- HeroUI
- ESLint
- Supabase（認証基盤）
- Hono（バックエンド側のアプリケーション層で利用）
- Python 3.13系
- uv（Pythonのpackage管理）
- FastAPI 0.115系
- 独自構築されたTTS
- Cloud Run（APIサーバーとして利用）
- Stripe（決済）
自分（1名）、開発者（2名）、事業責任者（1名）、クリエイター（1名）、デザイナー（1名）
合計6名
- フロントエンド側のアーキテクチャ選定
- β版全体のアーキテクチャ選定
- 認証基盤選定
- フロントエンド開発
- バックエンド開発
またメインの業務から少し外れますが自分のXのアカウントでサービスの紹介や新機能のリリースをポストしたり、公式のDiscordサーバーでユーザーさんと直接対話しながらプロダクト改善を実施しています。
例えば↓のような感じです↓
https://x.com/keita_kn_web/status/1878722748350173612
ログイン機能なしのβ版を1人で開発開始から2週間でスピードリリース、多くの方に利用して頂き（1週間で生成文字数が1千万程度）結果としてかなり早い段階でPMFを達成できた。
その後、優秀な2名のエンジニアが新しくJOINしてきてくれて、新しい2人のエンジニアと協力しながら以下の開発を行った。
- にじボイスを有料化してログイン機能、決済機能を追加
- にじボイスのAPI公開
優秀なメンバーが揃っていた事もあり価値ある機能に絞って優先的に対応する事で短い期日で高品質なアプリケーションが開発出来たと感じています。
この開発時の話は↓のポッドキャストで話をしています（自分が緊張して上手く話せてないですが・・・）
https://x.com/keita_kn_web/status/1871855600788984065
動画ファイルをアップロードすると動画内の音声を翻訳した字幕を付けた動画を生成するアプリケーションの新規開発になります。
- 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の運用ルール等を習得しました。