こんにちは！このたびタイミーは、9/11（金）開催のGo Conference 2026 にGoルドスポンサーとして協賛し、ブースを出展いたしました。 gocon.jp 素敵な場をつくってくださった運営のみなさま、そしてブースにお越しいただいたみなさま、ありがとうございました！ Closingでの発表によると、参加者は会場とオンライン合わせて700人を超えたそうです。その内、300人以上の方がタイミーのブースに立ち寄ってくださいました。 この記事では、タイミーのブース企画と、ブースでいただいた質問をご紹介します。執筆者はこちらの4名です。 Engineering Manager: 新谷（ @euglena1215 ） Backend Engineer: 成田（ @7riatsu ） Backend Engineer: 永田（ nagataaaas · GitHub ） DevEnable室: shihorin（ @shihorin_kjy ） 企画紹介 企画①タイミーでのGo活用紹介 株式会社タイミーは、「働きたい時間」と「働いてほしい時間」をマッチングするスキマバイトサービス「タイミー」を開発・運営しています。 バックエンドはRuby on Railsで主に開発していますが、認証基盤にはGoも活用しています。トータルプラットフォームを実現する構想の中で、Goの出番はこれから広がっていく可能性があります。 ブースでは、システム構成図やプロダクト戦略のイメージ図をご覧いただきながら、Go活用の現状と今後の可能性についてお話しました。 企画②Goの良いところを教えていただくアンケート ブースでは、アンケートへのご回答をタイミーでのお仕事に見立てた体験企画をご用意しました（実際の求人ではありません）。ご回答いただいたお礼にガチャを1回まわしていただき、ストレスボール、ぷくぷくシールなどのノベルティをお渡ししました。 アンケートの設問は「Goを選んでよかったこと、教えてください！」です。タイミーではこれからよりGoを活用していく可能性があります。そのため「Goエンジニアの先輩方からGoの良いところを教えていただきたい！」という意図でこの設問にしました。 結果はこちらです！ 元々用意していた選択肢に加えて、「バージョンUPしやすい」「Gopherがかわいい」という選択肢も途中で追加していただきました。 良いところ 票数 チームで読みやすく、保守しやすい 134 ビルド・デプロイがしやすい 94 並行処理を扱いやすい 69 ツールがそろっていて開発しやすい 49 性能を出しやすい、省リソース 43 Gopherがかわいい 35 まだ使っていない 11 バージョンUPしやすい 10 並行処理の扱いやすさや省リソースであることよりも、ビルド・デプロイの方がかなり票を集めていることに驚きました。 1エンジニアとしての言語の扱いやすさにとどまらず、プロダクトの一部として見たときの取り回しの良さが評価されているのかな？と考察しています。 企画③Reading List タイミーのプロダクト開発をもっと知りたい方向けに、「Reading List（おすすめ記事リスト）」をQRコードで掲示しました。その中から、特に反響のあった記事を紹介します。 タイミーの1,200万超ユーザーを支える認証基盤を Go と Ory Hydra で作っている話 バックエンド開発Handbookを届けるために ― AI時代の知の高速道路を敷く - Timee Product Team Blog プロダクト開発に関する記事の公開情報や登壇情報は、Xでも発信しています。ぜひご覧ください！ Timee Engineering / タイミーエンジニアリング 公式 (@TimeeDev) / X ブースで特にいただいた質問 + 回答 特に多くいただいた質問と、質問への回答をご紹介します。回答の中で出てくる用語は、以下の構成図でご確認ください。 再掲：ブースでお話ししながらご覧いただいた、システム構成図 Q1.「タイミーはGoを使っているのですか？Rubyの印象でした」 A.Goも使っています！基幹API（スポットワークのタイミー）はRubyで動いているのですが、ワーカー（toCユーザー）向けの認証基盤をGoで開発しています。 これまでバックエンドはRubyだけだったのですが、ここからバックエンドの言語のバリエーションを増やすことを前向きに検討していて、その中にGoが含まれています。 Q2.「タイミーの認証基盤はどういうもの？何のために作っている？」 A.複数事業展開を見据え、特定プロダクトに依存しない共通アカウント基盤が必要になったためです。 もともと認証機能は基幹 API（スポットワークのタイミー） に同居していましたが、それを最近切り出しました。スポットワークに隣接する事業を始めるために、同じアカウントでのログインや、データ連携ができるアカウント基盤が必要になったことがきっかけです。既存の認証機能は基幹APIの一部として実装されており、そのままでは共通の認証機能として利用できませんでした。そこで、独立したIdPとしてゼロから構築し、段階的に移行する判断をしました。 再掲：ブースでお話ししながらご覧いただいた、プロダクト戦略のイメージ図 Q3.「認証基盤だけGoなのはなぜ？なぜ認証基盤だけRails以外の技術選定をしたの？」 A.認証機能を既存のRailsアプリから独立したサービスとして切り出すにあたり、言語仕様がシンプルで、標準ライブラリや機能を絞った軽量なライブラリを組み合わせて必要な機能だけを実装しやすいGoを採用しました。型安全性や保守性を確保しやすく、長期運用する基盤との相性がよいことも理由の一つです。 また、OAuth2/OIDCに採用したOry HydraもGo製で、必要に応じて内部実装をコードリーディングで理解しやすいこともメリットでした。 Q4.「今後もGoを選定する予定はありますか？」 A.タイミーでは今後新規事業にも取り組んでいくことを検討しています。その際の技術選定の有力な選択肢としてGoを考えています。（検討・検証段階なので確定ではありません） 技術選定の参考にしたいという意図もあり、今回のブース企画を実施させていただきました。 Q5.「既存RailsアプリはGoにリプレイスするのですか？」 A.言葉通りのリプレイスは考えていません。 先述した認証基盤と同様、複数事業展開に伴い、いくつかの事業で同様の基盤が欲しくなることがあると思います。そういったユースケースが生まれた際に、基幹APIから共通基盤を切り出し移行する可能性は十分にあります。共通基盤の技術選定で、Goは候補のひとつになると考えています。その上で、Goが選ばれるのか、Rubyが選ばれるのか、はたまた別の言語が選ばれるのかはプロジェクト次第になりそうです。 Q6.「整合性チェッカーは何のためにあるのか？」 A.新たに構築した認証基盤(IdP)への移行途中である現在は、既存DBとIdP DBの双方へ書き込むダブルライト構成です。2つのDBでデータがずれる可能性があるため、整合性チェッカーが定期的に両DBを比較し、不整合を検知・通知しています。これは移行期間中の一時的な安全装置であり、読み書きをIdP DBへ完全に切り替え、ダブルライトを終了した後は廃止予定です。 おわりに ここまで読んでくださり、ありがとうございました！これからもGoコミュニティを盛り上げていけるよう、継続して関わっていけると嬉しいです。 最後になりますが、タイミーでは一緒にはたらく仲間を募集しています。ご興味をお持ちいただけましたら、ぜひカジュアル面談にお申し込みください！ プロダクト組織の概要や募集職種 シニアバックエンドエンジニア（プラットフォーム領域）採用情報 カジュアル面談のお申し込みはこちら

イベント概要 Amazon Aurora DSQL に関心をお持ちのお客様に向けて、「Aurora DSQL Day Tokyo」を開催します。本イベントでは、Aurora DSQL の開発を率いる Eric Kraemer のキーノートと AWS のスペシャリストによる Deep Dive セッション、そして日本のお客様 4 社から DSQL の採用事例についてお話いただきます。Aurora DSQL がどう動いているのか、実際の現場でどのように使われているか――ぜひこの機会に体感してください。 皆さまのご参加を心よりお待ちしております。 開催情報 開催日時 2026年9月14日（月）14:00 – 18:00 （13:30 受付開始） 開催場所 AWS 麻布台オフィス（麻布台ヒルズ 35F） 〒106-0041 東京都港区麻布台1丁目3-1 麻布台ヒルズ 森JPタワー 東京メトロ日比谷線 神谷町駅 直結・東京メトロ南北線 六本木一丁目駅より徒歩約4分 ※入退館等詳細は別途ご連絡いたします 参加対象者 分散データベースやマルチリージョン構成に関心のあるエンジニア、アーキテクト、技術リーダーの方々 言語 Keynote: 英語（逐次通訳）、他セッション: 日本語 参加申し込みについて 以下のページよりお申し込みください。 お申し込みはこちら 特にこのような方々に最適なイベントです マルチリージョンでの高可用性データベース構成を検討されている方 分散 SQL データベースのアーキテクチャや設計パターンに興味のある方 Aurora DSQL の具体的な実装方法やベストプラクティスを知りたい方 既存のリレーショナルデータベースからの移行を検討されている方 他社の Aurora DSQL 導入事例を参考にしたい方 プログラム内容 時間 内容 13:30-14:00 受付 14:00-14:05 オープニング 14:05-14:50 What’s Next for Aurora DSQL ― Aurora DSQL が目指す世界 Aurora DSQL サービスチームのプロダクトマネージャーから、プロダクトビジョンや設計思想、今後の方向性、海外のお客様による採用事例などをご紹介します。※逐次通訳付き AWS, Senior Manager PMT – Aurora Distributed SQL Eric Kraemer 14:50-15:40 将来不要になるデータベースタスクから考える Aurora DSQL ― アーキテクチャ・制約・適用判断 ― DB を選定するアーキテクトやエンジニア向けに、Aurora DSQL を「選定後に不要になるタスク」という観点から解説。キャパシティプランニング、シャーディング設計、スキーマ変更に伴う停止時間の調整、フェイルオーバー設計がなぜ不要になるのか、分散アーキテクチャから説明します。同時に、トランザクション競合時のリトライ設計や処理サイズの制限など、アプリケーション設計上の考慮点と適用判断のチェックリストもお持ち帰りいただきます。 アマゾンウェブサービスジャパン合同会社, データベース スペシャリスト ソリューション アーキテクト 永末 健太 15:40-15:50 休憩 15:50-16:15 実践 Rails + Aurora DSQL Ruby on Rails で実際に Aurora DSQL を利用して customer facing なシステムを新規開発・運用する中でのハマり所や工夫、また既存データの AWS Database Migration Service を利用した移行といった様々なエピソードを紹介します。 株式会社 IVRy, Platform & Systems Principal Software Engineer Sorah Fukumori 氏 16:15-16:40 ネットスーパーサービスにおいて AWS DSQL を選定した理由とその後の運用についてのリアル retail HUB ネットスーパーサービスにおいて商品のピッキングシステムを新規に開発する際、ストレージサービスとして DSQL を選定。選定時の検討内容や、開発で遭遇した課題、その後の運用の状況について小売業界の実態も含めつつ実際のところをお話しします。 株式会社エブリー, 開発本部 開発2部 部長 内原 章 氏 16:40-17:05 サッカークラブの広報写真選定システムと Aurora DSQL FC 東京では試合のたびに大量の写真が発生し、記事や SNS に適した写真を探す作業に多くの労力がかかっていました。Amazon Rekognition による人物特定と Amazon Bedrock のマルチモーダル LLM によるシーン・表情・パートナー企業露出の分類を組み合わせた写真選定システムを開発。分類結果を保存する DB として採用した Aurora DSQL について、運用のしやすさや負荷変動が大きい場合のコスト面でのメリットなど、実際に利用して得られた知見をご紹介します。 株式会社 MIXI, ライブエクスペリエンス事業本部 企画推進部 エンジニアリング支援グループ マネージャー 數藤 智幸 氏 17:05-17:30 有事の”切り替え判断”を、なくす。 ― Aurora DSQL で実現する Active-Active DR 戦略 2026年4月の AWS Data & AI イノベーションフォーラムで「DR 戦略の進化」として DSQL 採用の第一歩をお話しいただきました。あれから数ヶ月、検証は着実に進んでいます。マルチリージョン稼働のシステムを構築する中で直面した、ロングトランザクション制限やマルチリージョン設計での整合といった技術課題を、AWS と共に乗り越えている現在地をアップデートしてご紹介いただきます。 東京海上日動システムズ株式会社, IT インフラサービス本部 スペシャリスト 松本 幸大 氏 17:30-17:35 クロージング 17:35-18:00 個別アーキテクチャ相談会 AWS スペシャリストに直接ご相談いただけます。Aurora DSQL に関する具体的な設計・導入のご質問にお答えします。 Amazon Aurora DSQL とは Amazon Aurora DSQL は、事実上無制限のスケーラビリティ、最高の可用性、ゼロインフラ管理を備えた、PostgreSQL 互換のサーバーレス分散 SQL データベースです。Active-Active のマルチリージョン構成で 99.999% の可用性を提供し、従来のデータベースに必要だったインフラストラクチャの管理、キャパシティプランニング、パッチ適用、レプリカ管理などのタスクが不要になります。 強力な一貫性を持つ分散トランザクションを、リージョン内では低レイテンシー（数ミリ秒）で、マルチリージョンでもインタラクティブなレイテンシーで処理できます。PostgreSQL のワイヤプロトコルに対応しているため、既存の PostgreSQL 互換ドライバーやツールをそのまま利用可能です。 お申し込みはこちら

こんにちは。スタメンでCTOしております、ちゃんたく ( @tnir / @takuya_stmn ) です。 先日7月12日にTUNAGプロダクトは10周年を迎えました。（2026-07-12 14:41 JSTコミット） 2016年7月12日git init 私たちは当社主幹プロダクトであるTUNAGの日々の開発にGitHubをフル活用しており、コードの品質とセキュリティを高く保つための取り組みを継続しています。 その一環として、最近GA（一般提供）されたGitHubのネイティブなコードスキャンツールであるCodeQL-powered analysis for Code Qualityを導入し、高度なコードセキュリティ機能をフル活用しています。そのコア技術となっているCodeQLのおかげで、脆弱性の早期発見が可能になり、より安全なプロダクト開発が実現できるように設計しています。 しかし、CodeQLを運用していく中で、とある大きな「壁」にぶつかりました。 今回は、10年以上の歴史を持つリポジトリに約8年間潜んでいたレガシーコードを発見・分離し、実行時間を平均20分から3分へと短縮した取り組みをご紹介します。 課題：長すぎるCodeQLの実行時間（平均20分）とセキュリティ上のリスク CodeQLは非常に強力なツールですが、私たちのメインリポジトリで実行すると、完了するまでに平均で約20分もかかってしまっていました。 20分という時間は、CI/CDパイプラインにおいて致命的です。Pull Requestを作成してから結果が出るまで長時間待たされるため、開発者のフィードバックループが遅延し、開発体験（DX）の著しい低下を招いていました。 さらに重大な問題として、平均20分も時間がかかると、Pull RequestにおけるCIステータスのクオリティゲート（必須ワークフロー）として組み込むことができないという点がありました。マージのたびに20分待たせる運用は現実的ではなかったためです。 その結果、高度なコードセキュリティ機能を導入したものの、 CI/CDプロセス自体はセキュリティ対策として脆弱な状態（危険なコードのマージをCIでブロックできない状態） のまま運用せざるを得ないという本末転倒な状況に陥っていました。 私たちのリポジトリは10年以上にわたって運用されてきた歴史があり、コードベースの肥大化は認識していましたが、セキュリティクオリティゲートを正常に機能させるためにも、この20分という実行時間は絶対に解決すべき課題でした。 Datadog CI/CD Optimization (CI/CD Explorer) を用いた GitHub Code Quality (CodeQLパート) の実行時間分析 原因の特定：導入者は不在…しかし「Gitの歴史」が答えを教えてくれた なぜこれほどまでに時間がかかっているのか、解析のログや対象ファイルを詳細に調査しました。 しかし、調査対象となったコードは、現在在籍しているエンジニアやマネージャーの誰も背景を知らないブラックボックスと化していました。大昔に導入されたものであり、当時の関係者はすでに社内に一人も残っていなかったためです。 ここで力を発揮したのが、すべての変更履歴を正確に記録し続けていたGitでした。 Gitのコミット履歴やそのblameを遡って調査した結果、約8年前にサードパーティーから購入し、リポジトリ内に配備された 「管理画面用のUIライブラリ」 が原因であることが判明しました。一般的な社内エンジニアが実装したJSライブラリやビジネスロジックではなく、静的ファイルとしてリポジトリ内に鎮座し続けていたベンダー製のコードでした。 CodeQLは律儀にこの約8年間放置されていた外部ライブラリの隅々まで脆弱性スキャンを行っていました。私たちが日常的に手を加えることのない古いベンダーコードの解析に、CIの貴重な時間を大量に奪われていました。 解決策：235 MBに及ぶコードの切り出しと別リポジトリでの分離運用 原因が特定できれば、やるべき方針は明確でした。 今回特定されたサードパーティー製ライブラリは、コードの分量が約100 MBにも及ぶ非常に巨大なものでした。これほど大規模なコードを、メインプロダクトの単一リポジトリ内で維持し続ける必要性はありません。 あえてモノリシックに維持するのではなく、メインプロダクトとは明確に 「ライフサイクルの異なるソフトウェア」として、意図的に別リポジトリへ切り出して独立管理するのが適切である と判断しました。 そこで、メインリポジトリからはこの100 MBのUIライブラリを完全に削除し、別リポジトリとして独立させて異なるライフサイクルで管理する施策を実行しました。 驚きの結果とセキュリティクオリティゲートの実現 この235 MBのレガシーコードをメインリポジトリから削除した結果、CodeQLの実行時間は平均20分から「3分」へと劇的に短縮されました！ 実行時間が3分になったことで、CodeQLをPull Requestの必須クオリティゲートとして正式に設定可能となり、セキュリティリスクを抱えたコードがマージされるのをCI上で確実にブロックできるようになりました。 開発者のフィードバックループ（DX）が飛躍的に向上しただけでなく、CI/CDパイプライン全体のセキュリティ強度を真の意味で高めることができました。 ビルドパイプライン ビルドパイプラインは創業時の2016年7月よりRuby on Railsに付属のSprocketsベースのアセットビルドを利用していました。7年強続いたアセットパイプラインを2023年秋に見直していたため、Yarn+esbuildによる実装に修正するプロジェクトがあり、そこから3年ほどはアプリケーションレイヤーのフロントエンドアセットパイプラインを問題なく維持運用していました。 なお、ベースとなるサードパーティー製ライブラリはgulpが設定されていましたが、当該プロダクトへの導入時点よりwebpackでのビルドとして開発されていました。この点はフロントエンドパイプラインをモダナイズする上ではとても助かる点でした。 Bootstrap 4ベースのUIライブラリ 今回切り出した「サードパーティー製ライブラリ」はBootstrap 4.0.0 (alpha) ベースであり、かなりレガシーでした。筆者自身は5年以上前からBootstrap 5.0、そして、最新の5.3に関わるまで1ユーザーでもあるものの、Tailwind CSS v4.3（執筆時の最新バージョン）ベースに切り替えるプロジェクトを未着手のまま温めている状況です。 当該ページ群を使うユーザーはTUNAG全体の大規模なユーザーベースと比べると少ないのですが、いつかはやらなくてはならないタスクだと認識しており、LLMを使って一気に対処してくれるエンジニアを継続募集しています。 読者の皆様へのTakeaway（持ち帰り知識） 今回の私たちの経験から、皆さんの開発現場でも活かせるポイントをまとめました。 CI実行時間の短縮は「セキュリティクオリティゲート化」の絶対条件 セキュリティスキャンツール（SAST）を導入しても、実行時間が長いとPRの必須チェックに設定できず、セキュリティプロセスが形骸化・脆弱化してしまいます。「スキャンを高速化し、必須クオリティゲートとしてCIに組み込むこと」こそが、堅牢なCI/CDセキュリティを実現する鍵となります。 ライフサイクルが異なる巨大コードは別リポジトリへ分離する 200 MBを大幅に超える巨大なサードパーティー製ライブラリをメインリポジトリに含め続けると、静的解析やビルド時間のボトルネックになります。プロダクト本体とライフサイクルが異なるソフトウェアは、あえて同一リポジトリで維持せず、別リポジトリとして分離・運用することがアーキテクチャ上も有効です。 Gitの履歴は属人化したナレッジを救う最強のドキュメント 当時の担当者が一人も残っていない状況でも、Gitの履歴がしっかり残っていれば「いつ・なぜ・何が導入されたのか」を正確に突き止めることができます。歴史あるリポジトリの調査において、Gitのログを辿る重要性を再確認しました。 おわりに CodeQL-powered analysis for Code Qualityは、スキャン対象を最適化しプロジェクトの構成を適切に保つことで、本来の優れたパフォーマンスを発揮してくれます。 10年以上の歴史があるリポジトリでも、適切な棚卸しとアーキテクチャの見直しを行えば、DXとセキュリティの両立は十分に可能です。もし「CIが遅くて必須化できない」とお悩みの場合は、リポジトリ内に長年鎮座している外部コードや分離可能なモジュールがないか、ぜひ探してみてください！ また、われわれと一緒にレガシーアプリケーションの継続的モダナイズをしたいエンジニアを募集しています。詳しくは当社採用サイトをご覧ください。