スタメンでCTOしております、 @tnir ( X: @takuya_stmn , note: @takuya_stmn ) です。 2023年9月、スタメン技術ブログで次の記事を公開しました。 ドメイン駆動設計は何を解決する手法なのか 記事では、TUNAG の技術的負債解消に向けてドメイン駆動設計（DDD）の導入を検討している、と書きました。その後の対外的な印象として、「スタメンは DDD を積極導入している」と読まれる場面がありました。 本記事の目的は二つです。 当時の検討表明と、いまの実装実態のあいだにある差分を正確に共有すること その後に行った小規模な試験導入（PoC）から得た、Rails 文脈での技術的・組織的な学びを共有すること 結論を先に述べます。私たちの設計の軸は ActiveRecord で、DDD はバックエンドのごく小さな範囲で試しました。その結果、ActiveRecord を軸にする方針を選んでいます。ただしこれは DDD全般の評価ではなく、私たちの文脈での記録です。小さく試し、合うものを残し、合わないものを手放すプロセス自体は、今でも有効なエンジニアリング判断だと考えています。 2023年の記事が書いていたこと 当時の記事の冒頭は、次のとおりです。 株式会社スタメンでは、企業エンゲージメント構築サービス TUNAG（ツナグ）の技術的負債解消と今後の持続的成長のため、ドメイン駆動設計(DDD)の導入を検討しています。 記事は実装報告ではなく、コアドメインを軸に「DDD が何を解決する手法なのか」を整理する解説でした。実装詳細は扱わない、とも明記しています。締めは、将来に向けた表明です。 つまり本文の事実は「導入を検討している」までであり、「すでに積極導入している」ではありません。ただし、解説の熱量や「邁進していきます」という結びが重なると、読後印象としては積極導入企業のように残りやすい面もありました。このギャップを、いま実装と検証結果に基づいて補正します。 当時の課題提起がなければ、机上の議論で終わっていた可能性もあります。検討を公開し、その後に実コードで検証まで進めたからこそ、本記事で共有するトレードオフが見えました。 何を、どこまで試したか 私たちのプロダクトは、大きくバックエンド（API）とフロントエンドに分かれます。 領域 DDD との関係 フロントエンド 導入なし バックエンド全体 教科書的な全面適用はなし。LoC ベースで全体の 1% を大きく下回る範囲で、部分的・実践的な試験のみ 試験の主例 社内教育・テスト（ナレッジテスト）領域の新規 API 見送り後の比較例 タスク依頼・ToDo 領域の新規 API 本記事では前者を 業務DXサービスA API 、後者を 業務DXサービスB API と呼びます。どちらも TUNAG 本体から独立した形で実装されたグリーンフィールドサービスのバックエンドです。 業務DXサービスA API は、MVC でくくると Model がおおよそ 2,000 LoC 前後、View + Controller がおおよそ数百 LoC 規模でした。期間は 2023年12月からの約3ヶ月です。ここでの DDD は、Evans 流の戦術パターンを全面適用したものではなく、不変条件が重要な箇所に限定した実用主義的な導入（DDD-lite としても呼ばれることがある）でした。設問・選択肢・合格判定・受験セッションなど、「壊れると困るルール」が比較的はっきりしている領域だったため、試験対象として適していました。 実コードでは、たとえば次が確認できます。 ドメイン層を ActiveRecord から分離した pure Ruby のオブジェクトがある 選択肢数・重複・合格ラインなどの不変条件を、生成時や操作時に検証する実装がある 一部の更新経路では、リポジトリ経由で集約を再構成してから永続化する 一方で、次の限界もありました。 単純更新・複製・一部セッション更新は ActiveRecord 直叩きのまま残り、層を迂回した 一部のドメインオブジェクトは、振る舞いに乏しいデータホルダーに近い ドメインイベントや、依存逆転を徹底した古典的構成までは採っていない つまり「DDD を名乗るに足る部分実装はあった」が、「プロダクト全体の標準アーキテクチャになった」わけではありません。 時系列は次のとおりです。 時期 内容 2023年9月 技術ブログで導入検討を表明 2023年12月〜約3ヶ月 業務DXサービスA API で部分的・実践的な DDD を試験導入 2024年3〜4月 PoC 振り返り。本格採用を見送り、業務DXサービスB API では採用しない方針を合意 2024年5月〜約3ヶ月 業務DXサービスB API を、DDD 非採用前提で初期開発 現在 フロント未導入。バックエンドでも局所試験の知見にとどまり、標準は ActiveRecord を軸にした設計 業務DXサービスB API は「DDD 導入の第2弾」ではありません。振り返りの結果、採らないと決めたあとの開発です。境界の分離や外部モデルの漏洩防止など、マイクロサービスとして当然の設計はありますが、それを DDD の戦術導入とは数えません。 なぜ本格採用を見送ったか — 技術的・組織的な理由 ここが本記事の本題です。「やらなければよかった」ではなく、「何が効き、何が合わなかったか」を残します。 1. 本来の課題と手法がずれた 2023年の検討の出発点は、TUNAG の技術的負債解消でした。ところが検証が進むにつれ、 手法の導入そのものが目的化しやすい 局面がありました。 負債解消で本当に解きたかったのは、たとえば次のようなことだと考えています。 変更影響の見通しを良くすること ドメイン知識をコード上で追跡しやすくすること チームが安全に改修できる速度を保つこと 一方で、層分け・用語・パターンの整備が進むと、「DDD らしく書けているか」が評価軸になりやすい。すると、負債解消や変更容易性への寄与より、導入の完成度が議論の中心になります。業務DXサービスA API での試験は、この目的化を本体から切り離して観測するためにも有用でした。振り返りの結論は明確で、 その時点のスタメンの文脈では、DDD の本格導入は TUNAG の技術的負債解消に適していない 、でした。 2. Rails / ActiveRecord との摩擦コストが高かった 業務DXサービスA API は Rails API です。ActiveRecord は永続化だけでなく、クエリ・バリデーション・ライフサイクル・関連の中心でもあります。ここに戦術的 DDD（集約の再構成、リポジトリ、pure ドメインモデル）を部分導入すると、少なくとも次のコストが発生しました。 二重モデル化 : DB 行としての AR と、ドメイン上のオブジェクトを往復させる変換が必要になる 経路の分岐 : 不変条件が強い操作だけドメイン経由、単純 CRUD は AR 直叩き、という二系統が同居する 認知負荷 : 「この変更はどの層に書くべきか」の判断自体が、機能追加のたびに発生する 複雑な採点や、正式版の訂正ルールのように、壊れ方が高い箇所では、pure なドメインオブジェクトに寄せる利点はありました。逆に、大半の更新が CRUD に近い画面・API では、変換と層分けのコストが、得られる安全性を上回りやすかった、というのが率直な感触です。 Rails way（責務を散らさない Model、明確な UseCase、必要なら concern）を主軸にした方が、少人数チームでの変更速度と学習コストのバランスが良かった、というのが本格採用見送りの技術的な中核です。 3. 効く範囲が、プロダクト全体のボトルネックと一致しなかった DDD が相対的に効きやすいのは、ルールが複雑で、不変条件の破壊がそのまま障害になる領域です。業務DXサービスA API でも、設問制約や採点のようにその種の箇所には部分適用の合理性がありました。 しかし TUNAG 本体を含むプロダクト全体の負債の主因が、「集約境界が無いこと」だけだったわけではありません。認証委譲、サービス分割、スキーマ契約、運用、データ整合、画面を含む変更伝播など、別種の複雑性の方が大きい局面も多い。戦術 DDD を局所に厚くしても、プロダクト全体の変更容易性が線形に改善するとは限らない、というのが PoC 後の整理です。 4. 小さく試せたから、大きく間違わずに済んだ 見送り自体を失敗とは捉えていません。新規の小さい API で約3ヶ月試し、振り返り、次の新規 API では使わないと決めた。この切れ方の方が、本体へ先に全面適用するより健全でした。 組織として得られた整理は、次です。 DDD は銀の弾丸ではない 導入を目的化すると、負債解消から離れる Rails 中心のプロダクトでは、戦術 DDD の全面適用より、ActiveRecord を軸に複雑箇所だけ設計を厚くする方が現実的なことが多い 手法の採否は、流行や完成度ではなく、事業成長と開発生産性（保守性・変更容易性を含む）で見る いまの設計方針 PoC 後の標準は、ActiveRecord を軸に置いています。UseCase（アプリケーションサービス）でユースケースの流れとトランザクション境界を担保しつつ、永続化モデル側は ActiveRecord 本来の表現力を活かす。そのうえで、モデルを無秩序に太らせないために、関心事ごとに concern へ閉じる、という形です。 これは「Fat Model に戻した」という意味ではありません。ドメイン層と AR を二重に持つコストを下げつつ、ユースケースのオーケストレーションは UseCase に残し、モデルに散らばりがちな関心事だけを concern で分割する、という選択です。Concern の濫用が神オブジェクトの隠蔽になりうることは認識したうえで、DDD-lite の二重モデルより、この分割の方がチームの認知負荷と変更速度に合う、と判断しています。 対外的な事実関係は、次で足ります。 2023年の記事は導入検討の表明であり、全面採用の報告ではない フロントエンドでは DDD を導入していない バックエンドでも、LoC ベースで全体の 1% を大きく下回る範囲での部分的・実践的な試験にとどまる 主例は業務DXサービスA API（2023年12月〜約3ヶ月） 2024年3〜4月の振り返りで本格採用を見送り、業務DXサービスB API（2024年5月〜約3ヶ月）では非採用前提で開発した 現在のスタメンを「DDD積極導入企業」と呼ぶのは実態に合わない 小さく検証し、合わなければ採用しない、という判断は今後も取りうる 手法の是非を好みで決めず、小さく試し、事業成長と変更容易性を含む生産性、および本来の課題（技術的負債解消）への寄与で採否を決める。業務DXサービスA API での試験と、業務DXサービスB API での見送りは、その一例です。 おわりに この記事は、過去のチャレンジ計画ブログ記事を消すためのものではありません。当時の検討や、その後の試験を否定するものでもありません。むしろ、2023年の記事が課題を言語化し、仮説を外に出したからこそ、机上の空論で終わらせず実コードでトレードオフを検証できました。話題の手法をスローガンで終わらせず、小さなプロダクトに落として確かめ、本格採用を見送った記録です。 エンジニアリングにおいて重要なのは、流行を追うことでも、一度選んだ手法に固執することでもありません。自社のプロダクト特性、フレームワークの前提、チームの認知負荷に照らして、効く設計を残し、効かない設計を手放せることです。今回の PoC は、その判断をコードと振り返りで一度通した事例だと考えています。 設計の話をするときも、採用の話をするときも、「スタメンは DDD を積極導入している」ではなく、「小さく試し、Rails / ActiveRecord を軸に UseCase と concern で整理する設計を主軸として選び直した」と読んでいただけると、実態に近いです。 今現在、主に採用しているシンプルな Rails Way に準じたアーキテクチャに関しては別の記事でコメントできればと思います。

はじめに こんにちは。職種横断ダイレクトリクルーティングサイト「ウェルミージョブ（旧カイゴジョブ）」でQAを担当している林です。 アジャイルな開発チームメンバーの一員として、よりよいQAを目指して日々トライを楽しんでいます。 エス・エム・エスではAIエージェントを積極的に業務へ活用しています。 ウェルミージョブの開発チームではGitHub Copilot、Claude Code、Codex、Devin、Geminiなど、用途にあわせて様々なAIエージェントやAIアシスタントを使っており、その中でも私はDevinというAIエージェントを主にQA業務に活用しています。 私はDevinを Slackのオープンチャンネル で使い、その経験を QAの事例共有会 で発表することで、活用方法を日々ブラッシュアップしています。 今日は、AIエージェントDevinをこっそり使わずオープンに利用することで得られたメリット、さらには職域を超えたDevinの活用方法についてもお話しします！ 0. Who is Devin？ Devinは、自律的にコードの作成・実行・テストまで達成するAIソフトウェアエンジニアです。（※参考： Devin公式ドキュメント ） プロダクトのソースコードを読み込んで調査やドキュメント作成を行ってくれるほか、プルリクエストの作成まで一手に引き受けてくれます。 AIエージェントを導入する際、真っ先に壁となるのが「機密情報やコードが外部に漏れるのでは？」という不安ですよね。その点、Devinは入力情報やソースコードの漏洩対策が徹底されています。オプトアウト設定を行えばデータ学習を停止できるため、情報流出を心配することなく安心して活用できます。 ※参考： Devin公式ドキュメント Devin を改善するために、どのようにデータが利用されますか？ 既定では、サービスの改善および強化を目的として、お客様のデータをモデル学習に利用する場合があります。有料プランをご利用の場合は、Data Controls 設定ページでいつでもオプトアウトできます。 また、個人のPC上で動かすだけでなく、SlackやTeamsなどのチャットツールのスレッドにメンションするだけでチームの会話へシームレスに参加させられる点も特筆すべき特徴です。 1. DevinをSlackのオープンチャンネルで使っています！ ウェルミージョブ開発チームでは、Slackに専用チャンネルを設けて「オープンにDevinを使える環境」を整えています。 このチャンネルには、開発やQAはもちろんデザイナー・インフラ担当・PdM・マーケター・データアナリストといったプロダクトに関わる多様なドメインのメンバーが参加し、それぞれの業務パートナーとして以下のように日々Devinを活用しています。 現行仕様や振る舞いの調査、フロー図やユーザーシナリオの作成 データ抽出用SQLクエリの作成（DBは直接参照せずにソースコードとスキーマ情報をベースにクエリを作成） テストケースやテスト手順書の作成、テストデータスクリプトの作成 障害の原因調査、障害修正プルリクエストの作成 インフラ関連の現状の設定の確認、修正やバージョンアップ対応用のプルリクエストの作成 新しい仕様についての相談、ユーザー要望をコードベースで整理・要約 ユーザー向け説明書の作成、ユーザー問合せを想定したご案内文面の作成 データアナリストが正しくデータを可視化・分析するためにDB情報を起点としたモデル挙動を調査 プロダクト関係者にも広く開かれたオープンな場所でDevinを使って実感した、 3つの大きなメリット をご紹介します。 1)「AIの使い方の知見」がチームに自然と伝播する。失敗も財産になる プロンプト作成やタスク設計に悩むメンバーであっても、オープンチャンネルでのやり取りをウォッチするだけで「適切な依頼の粒度」や「実践的な活用アイデア」を自走して学習できます。 さらに、失敗した際のリカバリー手順までオープンになっている点もポイントです。他メンバーの試行錯誤のプロセスまでも見られることにより、エラーへの抵抗感が薄れ、チーム全体の「Devin利用への心理的ハードル」を大きく下げる結果につながっています。 2)ブラックボックス化を防ぎ、周囲がフォローしあえる Devinとのやりとりはすべてオープンにしているため、Devinがもし見当違いな方向へ進みそうになっても周囲のメンバーがすかさずスレッドでフォローしてくれます。 実際にもらったアドバイスは多岐にわたります。 Devinの調査結果の抜け漏れの指摘 Devinが作成したテストデータスクリプトの不備をフォロー 『こう聞くとQAに役立つかも』といったプロンプトの提案 最近の大きな変化は、QAメンバーがDevinを活用して軽微なバグ修正のプルリクエスト作成を行うようになったことです。 QAとDevinのやりとりを開発エンジニアが温かく見守り、必要に応じてスレッドでフォローしてくれるおかげで、普段コードを書かないQAでも軽やかかつ安全にバグ修正ができています。 もちろん助けてもらうばかりではなく、私自身も他メンバーのスレッドに入ってハルシネーションを指摘したりよりよいプロンプトを提案するなど、自分の強みを活かして貢献しています。 3)フルリモートでも、周囲のメンバーの困り事や興味関心がわかる 現在私たちはフルリモートで業務を行っています。朝会・夕会や1on1などでコミュニケーションの機会は多いものの「廊下で会ったついでに軽くおしゃべりする」ような偶発的なコミュニケーションは生まれにくいのが現状です。 そんな中、Slackに流れるDevinへのプロンプトが予期せぬ架け橋になっています。他メンバーのプロンプトから「今どんな困り事に直面しているか」「何に興味があるのか」が自然と見えてくるのです。 そこから技術的な情報交換や課題解決に繋がるのはもちろん、興味関心から会話が広がったり、困っている仲間を労われたりと、メンバー間の心理的距離がより縮まる良いきっかけになっています。 また、Slackというオープンな場にDevinを招き入れた効果は、マーケターやPdMのコメントにも色濃く表れています。 マーケターの声: 「些細な疑問でもDevinに気軽に問いかけられるため、仕事のスピード感や精度、プロダクトそのものへの理解が大きく深まった」 「たまにスレッドの中でエンジニアの方がコメントしてくれたり、リアクションしてくれるのもSlackならではのポイント」 PdMの声: 「Devinは仕様特化エージェントと思っていて、コミュニケーションの中心であるSlackでやり取りできるというのは、活用や運用するという上では非常に相性がいい」 「ちょっとしたアイデアや壁打ちを常に開いてるSlackで思いついたら会話できるという体験は、イノベーションを生む」 気軽に使えるSlackでDevinをオープン運用する価値は、まさに想像以上です。 2. 社内コミュニティ「AI4QA事例共有会」で体験談を発表しました！ カイポケQA中村さんのテックブログ『QAエンジニアがAI活用事例を「全力でパクる」ための会をはじめました』でご紹介の通り、弊社ではプロダクト横断の社内QAコミュニティにおいて「AI4QA事例共有会」が開催されていました。 tech.bm-sms.co.jp 私は「Devinをオープンに活用する価値」を他のQAメンバーにも知ってもらいたいと強く思い、今まで2回にわたり活用事例を発表しました。 この発表を通じて、私は知見を広めるだけでなく、自分自身も 2つの大きなメリット を得ることができました。 1)QA視点のフィードバックを得て、活用方法をブラッシュアップできた 共有会では、1回目に『Devinの紹介とGOODな体験談』、2回目に『失敗談と新たなTRY』をテーマに発表しました。 視聴していたQAメンバーから現場ならではのフィードバックを受け取れたことは大きな収穫でした。作業に没頭していると見落としがちな視点や、次なる挑戦へのヒントを数多く獲得でき、フィードバックはすぐに取り入れて自身のDevin活用方法を即座にアップデートしました。 「コードを見る特性上、Devinのテスト観点はホワイトボックステストに偏りがちかも？」 💡言われてみれば確かにそう。「コード構造ベースではなく、ユーザー操作の視点でテスト観点を出して」と明示的に指示してみよう！ 「Devinが提案したテスト観点の中で『この発想はなかった！』というものはどれくらいある？」 💡Devinと自分の得意・不得意を常に意識し、お互いの弱点を相互補完していかなきゃ！ 「Devinに機能仕様書を作らせたり、テスト設計のレビューをやってもらったりできる？」 💡「そのうちやろう」と後回しにしていたレビュータスク。さっそく実践に移す！ 「Devinって使えば使うほど自動で賢くなるの？」 💡調べてみるとセッションは独立しており、単に会話を重ねるだけでは学習されないと判明。調査の過程でナレッジ機能や「DeepWiki」に出会ったので、こちらを活用してみよう！ 2)発表する前提でプロンプトを丁寧に言語化したら、いろいろな人が読みやすくなった AIエージェント利用時はどうしても「どう書けば思い通りの結果が得られるか」という目先のテクニックに意識が向きがちです。 しかし私は「共有会でDevinとのやりとりを紹介する」という前提を持つようになってから、プロンプトの記述を丁寧に言語化し、指示の背景やコンテキストまでしっかり補足する癖がつきました。 その結果、周囲のメンバーにとって理解しやすいだけでなく、Devinにとっても迷いのない高精度な指示が出せるようになりました。さらに、後から自分の過去プロンプトを見返す際も意図がひと目で分かり、次なるプロンプト改善の土台になるなど、巡り巡って自分自身の財産になっています。 番外編：開発・QAだけじゃない！職域を超えたDevinの活用方法 ウェルミージョブにおけるDevinの活用は、単なる『作業の効率化』だけに留まりません。開発・QA・デザイナー・PdM・マーケター・データアナリスト・社内システム管理者など職種の壁を越えたコラボレーションを生み、プロダクト開発全体の動きを加速させるポテンシャルを秘めています。ここからは、魅力的なDevinの活用事例を3つご紹介します。 1)DeepWiki Devinには、リポジトリ全体のアーキテクチャ図やドキュメント、ソースコードへのリンクを自動生成してくれる「DeepWiki」という機能があります。（※参考： Devin公式ドキュメント ） ドキュメントのメンテナンスは不要で、Wikiの再生成を実行するだけでDevinが最新のコードを読み解いて「システムの最新説明書」を自動で立ち上げてくれます。設定で日本語化も可能です。 AIがコードから読み取った説明書なので正式な仕様書そのものではありませんが、システム・機能の全体像やインフラ周りの情報を短時間でつかむ分には十分です。開発・QAだけでなく、プロダクトや機能をざっくり知りたいPdMなどのメンバーにとっても大いに役立っています。 2)リリースノート Devinに過去1週間で本番デプロイされたプルリクエストを抽出してもらい、その内容を要約してもらうことで『自動リリースノート』を生成させています。 単にプルリクエストを収集するだけでなく、要約のプロンプトを「コードを読まない非エンジニア向け」にチューニングしているのがポイントです。開発者以外のステークホルダーにとっても「何がどう変わったのか」が直感的に伝わる情報に整うため、プロダクトに関わる人へ幅広く重宝されるアウトプットになります。 3)社内ユーザー向けの仕様質問アプリ Devinの優れた『コード・仕様の調査能力』に目をつけたPdMが、その力を全社で還元すべく、Devinを用いた『仕様質問アプリ』を内製し社内リリースしてくれました。 Slack上でも仕様調査は可能でしたが、あえて「質問専用のインターフェース」を用意して用途を限定。これにより、Slackの操作に不慣れなメンバーでも直感的に使いこなせるようになり、以下のような大きな成果と可能性が生まれています。 双方ハッピーな体験：質問者はエンジニアの手を止めずに「即時回答」が得られ、エンジニア側は回答対応の割り込み工数を削減 ナレッジ化によるコスト削減：FAQとして過去の回答を蓄積・再利用することで、重複する質問への対応コストをカット プロダクト改善への還元：寄せられた質問ログを分析し、ユーザーが躓きやすいポイントを今後のプロダクト改善へと繋げていく予定 まとめ：オープン活用とアウトプットが生むナレッジの循環 今回ご紹介したように、Devinをオープンな場で運用・共有することには多くのメリットがあります。 チームへの波及効果: プロンプトや試行錯誤が可視化され、利用ハードルの低下と相互フォローの文化が醸成される 自身への還元: 共有を前提とした言語化により、プロンプト精度向上とナレッジの資産化が実現する 組織への広がり: 開発・QAにとどまらず、PdMやステークホルダー巻き込み型の活用へと発展する セキュリティ対策を整えた上で「みんなの見える場所でAIを使う」環境を作ることが、個人と組織双方のプロダクト開発能力を加速させる強力な基盤になります。 本記事が、みなさまのチームにおけるAIエージェント活用のヒントとなれば幸いです。 告知！ ウェルミージョブの開発をリードする @moro が、「 Kaigi on Rails 2026 」に登壇いたします。トークのタイトルは「 Event is what happens 」！過去3回のKaigi on Railsでも好評を博した@moroの講演にどうぞご期待ください！ 昨年までの発表 Simplicity on Rails - RDB, REST and Ruby / MOROHASHI Kyosuke - Kaigi on Rails 2023 Identifying User Identity / MOROHASHI Kyosuke - Kaigi on Rails 2024 Kaigi on Rails 2025 Keynote: dynamic!

こんにちは！このたびタイミーは、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コミュニティを盛り上げていけるよう、継続して関わっていけると嬉しいです。 最後になりますが、タイミーでは一緒にはたらく仲間を募集しています。ご興味をお持ちいただけましたら、ぜひカジュアル面談にお申し込みください！ プロダクト組織の概要や募集職種 シニアバックエンドエンジニア（プラットフォーム領域）採用情報 カジュアル面談のお申し込みはこちら