す

【プロジェクト概要】 スタンドアロンで動作するAmazon ECS互換のコンテナ実行環境を実現する「KECS」というOSS。つまり、ローカルでAWS無しで実行できるECS。これを企画、設計、実装までを担当。 【開発の背景】 ECSはAWS独自のサービスであり、これを利用するには当然AWS環境が必須となる（ECS Anywhereという特殊な手段もあるが）。 これまで、多くのECS利用プロジェクトではdev環境や本番環境がECSなのに、ローカル環境がComposeでお茶を濁すことがほとんどでした。 また、ECSのAPIを活用した運用ツールを開発するにしても、AWS環境は不可欠でした。ECSを取り巻くエコシステムは、Kubernetesに比べれば十分ではありません。 そこで、ローカルやGitHub Actions上でスタンドアロンで動作するECSがあれば、一種のゲームチェンジャーではないかと考えました。LocalStackもありますが、肝心のECS部分は有料です。 【KECSの仕組みと特徴】 Kubernetesをスタンドアロンで実行する軽量なディストリビューションであるk3d上でKECSは動きます。KECSはECS互換のAPIを持つため、aws ecsコマンドで操作できます。ECS以外のAPIはLocalStackに流すことができ、Service Discovery、CloudWatch Logs、Parameter Store, SecretsManagerといったリソースを透過的に統合します。ELBはLocalStackで有料なため、Traefikで代替することで同等のものを実現します。 また、KECSは開発体験向上のためTUIを備えています。Bubbleteaを使ったk9sライクのTUIで、ECSタスクの操作やログの閲覧などを効率的に行えます。 【AIをフル活用した開発】 KECSの99%はClaude Codeで実装されています。当方はコンセプトデザイン、設計、クオリティの担保、コードレビューに集中しています。また、AIが開発の本質を逸脱しないようなガードレールやエコシステムを整備し、可能な限りAIが自律的に開発できるようにしています。

※業務委託で参画したプロジェクト 【プロジェクト概要】 ネットショップ開設サービスで提供するFTP機能があり、現状はプライベートクラウドでProFTPDで提供されている。FTP自体は古いプロトコルだが、ユーザーに影響を与えずそのままの仕様でAWSへ移設する。AWSでのアーキテクチャ設計、実装、運用までを担当した。 【新FTPサーバの構築】 ECS(Fargate),Route53, Transfer Family, S3で刷新。マネージドとしてTransfer Familyがあるが、独自機能（容量制限）を実現するため、その前段に独自にGoで実装したFTP-Proxyを配置した。これは極力RFCに準拠した形で実装した。 旧システムではFTPサーバが単一障害点であったが、AWS環境ではDNSラウンドロビン+複数のECSタスクで冗長構成を実現（FTPの特性上NLBは実は使えない）。さらに、Blue/Greenデプロイメントの仕組みを構築して、スタンバイ環境でインテグレーションテストを通過したバージョンのみリリースできる堅牢な機構を実現した。 【運用・監視】 AWSリソースはTerraformで構成を管理している(ECS以外)。また、Managed Prometheus+ADOT+Grafanaでの監視を構築。ftp-proxyのSLI/SLOを定義し、OTELメトリクスを実装。ECS Container Insightsのメトリクスも組み合わせて、多面的な運用監視を実現。 【コンテンツ配信面】 FTPアップロードされたコンテンツは、CloudFront、CloudFront Functions+KVS、S3構成で配信している。 ユーザーのロック、退会によってコンテンツの配信を止めるため、CloudFront Functions+KVSでACLを実装して制御している。KVSキーの制限が上限1000個の制限があるため、データ構造を工夫してシャーディングを実装し、多くのユーザーコンテンツのACL制御を実現した。 【AIコーディング】 後半はClaude Codeが台頭したため、ほぼVibe Codingでこなした。スラッシュコマンドやエージェントの整備、Serenaの活用、Runbook・PlaybookのMCP提供なども行った。

※非常勤技術アドバイザーとして参画中 【概要】 開発拠点が日本・ベトナムに分かれている会社で、急速に成長してきたがコードベースの拡大とともに技術的負債が拡大し、開発のアジリティが大きく低下している。また若いメンバーも多く、技術・組織で統率を取れるメンバーも不在のため、自分も含め他社数名が1on1や技術アドバイザーを非常勤で行っている。 【業務内容】 ・キーマンとの1on1 ・開発組織が抱える課題と処方箋を代表取締役、開発組織管掌役員へのフィードバック ・ベストプラクティスの共有、Playground的プロジェクトの作成 ・開発組織のバリュー、ミッション制定のサポート ・評価制度が皆無だったため、エンジニアのキャリアパスとキャリアラダーを制定し、現状の実力値と給与の乖離を可視化した ・タスク型目標設定を成果型目標設定への転換を支援 ・エンジニア採用面談に同席し、技術アセスメントを担当

・社内基盤組織のソフトウェアデリバリー部隊をスピンアウトして、新たにメディア管轄の開発生産性向上にコミットするDeveloper Productivity室を設立し、室長を担う ・ABEMAのFeature Flags基盤開発部隊も合流し、約10人規模で俊敏性のあるソフトウェアデリバリーを組織で実現する体制を構築 ・PipeCDやBucketeerのOSS公開、PipeCDのCNCF Sandbox加入活動などを後方支援 ・新卒・中途問わず採用活動にコミットし、社内外問わずソフトウェアデリバリーに強い関心を持つ人材を多くアトラクトした ・その他管轄内の横軸活動として、管轄内での技術指針を示すMEDIA TECH VISION 2020-2023のDevOps領域の策定を担当。「かいはつ速度アゲ太郎」ワーキンググループに参加し、Four keysの活用や定着に関する勉強会を実施 ・活動が評価された？のか、DP室はメディア管轄の組織から全社組織へとステップアップした ・次世代の室長候補を育成し、2023.09を持って室長を後継者へバトンタッチした

古くなり、トレンドに即していない社内基盤組織の刷新をテックリードとして担当（自分で手もかなり動かしているためテックリードとしているが、役割的にはCTOが近いかもしれない） 多くの企業において、重複開発を避ける意図での基盤組織やプロダクトが次々に生まれると思うが、安易に工数削減だけを目的に始まったプロダクトは、社外のSaaSプロダクトと比較すると緩やかに競争力を失っていく。 そこで既存の基盤組織に新たに参画し、「基盤」と「基盤組織」そのものを再定義することにした。今日、Webサービスが1日でも早くサービスをユーザーに届けるためには、短期的には開発効率や高いDeveloper Productivity、中・長期的には運用負荷が少ないSaaSを使わない手は無い。 世界に視野を広げると、次々と開発支援系のスタートアップが立ち上がっていくため、今までと同じことをやっていては短期的な工数削減しかできない魅力の無いプロダクトを作り続けることになる。従来型の基盤組織ではとても太刀打ちできず、継続的に価値を出せるSaaSを作るための組織にならないと意味がない。 そこで社内の一基盤組織ではなく、対外的に売り出していくSaaSプロバイダーとしてチームを再編することにした。開発するSaaSプロダクトは基本的に社外のユーザーにも提供していく。社内で閉じているより社外に出した方がフィードバックの量が雲泥の差のため、開発者に価値にとってある（お金の取れる）プロダクトを作る組織にリビルドした。社内のサービスへの貢献はもちろんだが、これまでのような事実上の受託組織ではなく、エンジニア主導で世の中に求められるものを考え出して提供していくことを目的としている。 さらに、開発するSaaSプロダクトはOSSとしても公開していく。マネージドだけ提供しているSaaSはたくさん存在するが、OSSとして公開することでプルリク相乗効果や、活発な開発コミュニティの醸成が期待できる。また、シングルテナント・マルチテナント選択可や、様々なプラットフォームで運用できる高いポータビリティを追求することで、開発者により自由度の高い状態で提供できる。何よりもOSS化によって安心感をもたらすことができる。今日、Kubernetesがまさにこのモデルで成功しており、プロダクトとして成長を続けている。この組織ではOpenSasSモデルを標榜してプロダクト開発を進めていく。 テックリードとしては、使いやすいSaaS（シンプルな仕様、gRPCでのAPI提供や、Swaggerの提供、開発環境の迅速な提供）や、透明性（メトリクスの積極公開、利用状況の可視化）、高いポータビリティ（Full Kubernetes化、Helm、Kustomize対応、Istioによるサービスメッシュ化）、高可用性（高速AutoScaleやFastlyの活用）といった技術戦略を着々と進めている。

ライブ配信プラットフォーム「FRESH LIVE」の立ち上げから参画し、テックリードを務める。 初期アーキテクチャ（Amazon ECS+Microservices）、次期アーキテクチャ（AWS + Kubernetes + Microservices + gRPC）の両フェーズでのアーキテクチャ構築を担当。 基本思想はFull Dockernizedであり、その他利用しているクラウドサービスについてはTerraformによるInfrastructure as Codeを徹底している。 サーバサイドの実装においては、GoとKotlinを採用。初期はGoをメインで利用していたが、低レイヤーや動画周りはGoで、フロントエンドやiOS/Androidに提供するAPI部分はKotlinを採用した。おそらくServerSide Kotlinの採用としては先駆的なプロジェクトであり、SpringBoot/gRPC/SparkFrameworkでの開発例等は自分も他のメンバーも含めかなり積極的に行いプレゼンスを高めることができた。 プロジェクトの後期は、より高いオペレーションの志向や、コンピューティングリソースの効率的な利用、GPUノードの活用によるコスト削減を目指して、Amazon ECSからKubernetesへの移行を行った。EKSはまだ利用できない時期だったため、kopsでクラスタ構築を行った。 「Docker/Kubernetes 実践コンテナ開発入門」の執筆やチーム内勉強会を行うなどして、メンバーのKubernetesスキルを高めていった。この本における運用的なポイントのほとんどこのプロジェクトにおいて培われたものとなる。 各MicroservicesはHelmによってパッケージ管理されており、Slackから簡単にリリースできるツールを開発した。 メトリクスはPrometheusで管理し、grafanaやalertmanagerの整備等を行った。 可用性の担保ではHPA(Horizonal Pod Autoscaler）やCluster Autoscalerの導入等で、ピーク帯やコストを意識したPodやノードのオートスケールを行っている。 動画周りではFRESH LIVEで配信中のものを、Periscopeへ同時配信する（RTMPのrelay）といった機能の実装も行い、それに付随する配信管理画面（React.js、Redux）といった実装も行った。 また、テックリードという役割ではあったが、各エンジニアのマネージメントも行っており、プロジェクトにおける事実上のVPoEの役割も兼務した。