ID:78504さん

### 経験したプロジェクト **社内業務の自動化・効率化を目的としたシステム開発（株式会社Techouse）** 【プロジェクト名】社内業務の自動化・効率化システム開発（株式会社Techouse） 【期間】2022年8月～2024年9月 【概要】 属人化・手動作業が蔓延していた社内業務を効率化・標準化するため、PythonとFlaskを用いて複数の業務自動化ツールを構築。初期はAWS Lambdaによるサーバーレス実装からスタートし、その後ECS Fargate上にFlaskベースのWebアプリとして再構築・統合。全プロセスを1人で担当し、開発・インフラ・CI/CD・IaCの全てをカバー。 【チーム構成と役割】 1名（自分のみ）で担当。要件定義、設計、実装、インフラ構築、CI/CD整備、運用までをすべて単独で実施。技術統括がアドバイザーとしてAWSアーキテクチャに関する助言を担当。 【開発・実装内容①：業務自動化Webアプリケーション群の構築】 ＜課題＞ 社内の各部署において、CSV加工・データ集計・レポート作成といった定型業務が、担当者ごとのローカル環境やExcelベースで属人化しており、ヒューマンエラーや非効率な作業が多発していた。 ＜工夫＞ Python + FlaskによりWebアプリケーション化し、処理を共通化・モジュール化。初期はAWS Lambda上でサーバーレスに構築し、PoCとして社内導入。その後、再利用性・拡張性を重視し、ECS Fargate上のFlaskアプリ群として統合。Celery/Celery Beatによる非同期処理の導入、Transit Gatewayを用いた他ネットワークへのDB接続なども実施。 ＜成果＞ 1ツールあたり週数時間〜十数時間に及ぶ業務を削減。各ツールは複数部署間で再利用される汎用的な設計とし、属人化を排除。再利用性・保守性の高い業務プラットフォームへと進化。 【開発・実装内容②：インフラ構築・CI/CD・IaC整備】 ＜課題＞ 手動デプロイ・環境差異によるトラブルが多く、再現性や安定運用に課題。環境構築の属人性も高く、開発・運用効率が低下していた。 ＜工夫＞ Terraform・Terraform Cloudを用いて、ECS Fargate、ALB、CloudFront、IAMポリシーなどのAWSリソースをすべてIaCで定義。GitHub Actionsを用いてCI/CDパイプラインを構築し、mainブランチへのマージをトリガーに自動デプロイを実現。ローカル検証環境のDocker化も合わせて行い、開発者目線での再現性も向上。 ＜成果＞ コード変更から本番反映までの時間を数日→数分に短縮。環境構築やデプロイ作業の属人化を排除し、インフラの透明性と信頼性が大幅に向上。 【技術スタック】 Python / Flask / Celery / HTML / CSS / JavaScript / SQL / AWS（ECS Fargate, Lambda, CloudFront, IAM, Transit Gateway）/ Docker / Terraform / Terraform Cloud / GitHub Actions / Linux

**LLMサービス「光 / Hikari」の開発およびエンジニアリングマネジメント（燈株式会社）** 【期間】2024年10月～現在 【概要】 建設業界向けSaaS「光 / Hikari」にて、LLM（大規模言語モデル）を活用したAIエージェントサービスの開発・運用を担当。バックエンド・インフラの実装・整備に加え、EM（エンジニアリングマネージャー）兼EL（エンジニアリード）としてチームビルディング、開発プロセス設計、技術的意思決定を主導。フロントエンド領域では、Next.jsの構造的な課題に対するリファクタリングプロジェクトを業務委託エンジニアと共に進行中。 【チーム構成と役割】 • チーム構成：エンジニア5名（バックエンド2名、フロントエンド1名［業務委託］、インターン生2名、EM兼ELの自分） • 自身の役割：EM兼ELとして、技術選定・設計方針策定・コードレビュー・実装・インフラ構築・チームマネジメントを一貫して担当。特にインフラとバックエンド領域では実装・保守をフルリード。 【開発・実装内容①：バックエンドの品質改善・再構築】 ＜課題＞ インターン生が主に実装していたFastAPIベースのバックエンドは、技術的負債が非常に大きく、可読性・保守性ともに深刻な状態だった。クラスはほぼ使われておらず、1関数が500行を超えるケースもあり、ネストも深く、ロジックの追跡が極めて困難だった。コメントも皆無で、処理の意図が読み取れず、運用・保守・改修がすべて困難な状況だった。結果として、日常的に大量のバグと社内外問わず終わりの見えない問い合わせ・対応が発生し続けていた。 ＜工夫＞ 既存コードの全容を読み解いたうえで設計を全面的に見直し、一気に書き直すレベルのフルリファクタリングを実施。クラスベースの設計へ移行し、処理の分割、命名規則の統一、構造の整理、適切なコメントの追加を行い、コード全体の可読性・拡張性を大幅に向上させた。既存のpydanticモデルは維持しつつ、処理の流れを明快に再構成した。 ＜成果＞ これにより、Pythonバックエンド由来のバグは激減し、運用中の問い合わせも大幅に減少。残った問題の多くがフロントエンド側に起因するものであることが明らかになり、技術的負債の分離と切り分けにも成功。属人化とブラックボックス状態を解消し、機能追加・保守が容易な状態を構築したことで、開発スピードと品質が共に大きく向上した。 【開発・実装内容②：Azure上のインフラ運用と整備体制の再構築】 ＜課題＞ Azure上のインフラは構築済みだったものの、設計意図・構成情報・CI/CD運用に関する引き継ぎが一切行われておらず、Terraformコードのみが断片的に残されている状態だった。全体像の把握が困難で、運用・改修時のリスクが高く、保守可能な体制が整っていなかった。 ＜工夫＞ Terraformコードを徹底的に読み解きながら、開発用サーバーの新規構築を通して構成の理解を深め、各リソースの役割や依存関係を整理。得られた知識をもとに、インフラ構成・CI/CD・運用フローをドキュメント化し、チーム内で共有できるナレッジとして整備。 ＜成果＞ 属人化していたインフラ運用のブラックボックスを解消し、将来的な引き継ぎや運用負荷分散を見据えた体制の土台を整備。現時点ではインフラ運用・トラブル対応は自分がフルで担っている状態だが、ドキュメントにより他メンバーへの教育・移譲も可能な状態にまで可視化・体系化できている。 【開発・実装内容③：フロントエンドリファクタリングプロジェクト（進行中）】 ＜課題＞ Next.jsを用いて構築された既存フロントエンドは、クライアント側とサーバー側の責務が混在しており、バックエンドロジックまでもがNextアプリ内に実装されていた。その結果、認証処理・データ加工・DBアクセスがフロントエンド側に存在し、開発・運用・保守のいずれの観点でも複雑化していた。 ＜工夫＞ 業務委託のフロントエンドエンジニアと定期的に設計・実装方針のすり合わせを行い、UIレイヤーとバックエンドロジックの責務を分離。フロントエンドのフロントエンドを再構築する一方で、Next.js内に存在していたバックエンド処理についてはGo言語による独立APIサーバとして再設計・置き換え実施。 ＜成果＞ フロントエンド側の技術的負債を段階的に解消中。責務の明確化により今後の拡張・変更に強い構成へと移行中であり、 バックエンドサーバーとしてのGoによる分離設計によってパフォーマンスや運用性の向上を狙った。 私自身はGo側のバックエンド・インフラなどを全て開発。 Claude Codeを駆使した開発で2ヶ月余り、当初予定されていた機能を全て、テストカバレッジ89%を維持しながら作成した。 【技術スタック】 Python / Flask / FastAPI / TypeScript / React / Next.js / Go（導入中）/ Azure（VNet, Blob Storage, IAM, VM, Azure Database for PostgreSQL, DNS Zone, ACR, App Service, CDN, Azure Key Vault, Redis Cache）/ Terraform / GitHub Actions / Docker