タむミヌのブログ - TECH PLAY

TECH PLAY

タむミヌ

タむミヌ の技術ブログ

å…š321ä»¶

タむミヌのプロダクトマネヌゞャヌの飯田です。 今回は、12/4に開催された プロダクトマネヌゞャヌカンファレンス 以䞋pmconfに参加しおきたした。このむベントを通じお非垞に有意矩な孊びを埗られたため、タむミヌのプロダクトマネヌゞャヌ柿谷、小宮山、鈎朚、小西、䜐々朚、楠本、飯田から、各セッションから孊んだ内容を、党3回の蚘事で玹介したす。 (本蚘事は、党3回のうち、Part3です。) ▪Part1・Part2はこちら pmconf2025に参加しおきたした part1 pmconf2025に参加しおきたした part2 マルチプロダクトのカオスを制す。「プロダクトディシゞョンレコヌド」で実珟するチヌム暪断のアラむンメント戊略 登壇者 株匏䌚瀟゚ス・゚ム・゚ス / プロダクト掚進本郚 アヌキテクト プロダクトマネヌゞャヌ 䞉浊 玄 氏 登壇資料 speakerdeck.com 株匏䌚瀟゚ス・゚ム・゚スで「カむポケ」のリニュヌアル責任者を務める䞉浊氏による、䞍確実性の高いマルチプロダクト開発における意思決定プロセス「プロダクトディシゞョンレコヌドPDR」に぀いおのセッションをレポヌトしたす。 ■ マルチプロダクトにおける「䞍確実性」の正䜓 カむポケは40以䞊のサヌビス・プロダクトを展開する巚倧なバヌティカルSaaSで、業務×業態の掛け合わせによる耇雑性カオスを抱えおいたす。耇数のプロダクト連携を前提ずした「カむポケコネクト」の開発では、将来の予枬の将来予枬の困難さ環境の䞍確実性や、誰に䜕を聞けばよいか分からないこず通信の䞍確実性が課題ずなり、「誰が決めるのか」「もう決たったのか」ずいった混乱が生じおいたした。 ■ 意思決定のプロトコル「プロダクトディシゞョンレコヌド」 この䞍確実性の䞭で意思決定を機胜させるプロトコルずしお蚭蚈されたのが「プロダクトディシゞョンレコヌドPDR」です。元々ぱンゞニアリングの文脈であるArchitecture Decision RecordADRをベヌスにしおおり、決定内容だけでなく、「なぜその決定に至ったのか」ずいう背景や文脈コンテキストを残すこずを重芖しおいたす。 テンプレヌトには以䞋の項目が含たれたす むシュヌずコンテキスト : 癜黒぀いおいない問題ず、なぜ今それを解決するのか。 クリティカルナヌザヌゞャヌニヌ : 圱響を受けるUX/CUJ。 オプションず評䟡軞 : 遞択肢のメリット・デメリットず、刀断のためのトレヌドオフ基準。 決定ず理由 : 最終的な結論ず、その遞択理由。 ■ 運甚ず定着のポむント PDRは単なるドキュメントではなく、䌚議䜓のアゞェンダず連動させ、Slackぞのプッシュやロヌドマップぞの反映を行うサむクルで運甚されおいたす。特に「圱響範囲が広く䞍可逆な決定」や「重芁なリリヌス前の意思決定」においお、WIP曞き途䞭の段階から透明性を確保しながら合意圢成を図る点が重芁です。 ■ 参加しお感じたこず 「決定をデヌタベヌス化し、䞀芧性の高い圢で芋える化する」ずいうアプロヌチは、シンプルながらも実行難易床が高い取り組みだず感じたした。 しかし、䞍確実性が高い環境だからこそ、圓時の意思決定の背景コンテキストが資産ずしお残るこずの䟡倀は蚈り知れたせん。小芏暡なチヌムから倧芏暡・郚眲暪断のプロゞェクトたで、芏暡を問わず汎甚的に掻甚できるフレヌムワヌクであり、自組織でも取り入れおいきたいず感じたした。 執筆楠元久貎 元経営䌁画CSO戊略責任者のPMが語る「プロダクトが創る事業戊略」のリアル  〜PLに振り回されず、䟡倀から逆算する事業貢献の最倧化〜 登壇者 キャディ株匏䌚瀟 / VPoPSProduct Strategy 岞本 裕史 氏 登壇資料 speakerdeck.com いわゆる「ビゞネス䟡倀ず顧客䟡倀のトレヌドオフ」や「よりビゞネス芳点を持ちたい」ずいう課題感からこちらのセッションに参加したした。 PMを苊しめる「PL責任論」 PMの珟堎では、埀々にしお以䞋の察立構造が生たれたす。 PMの想い : 「ナヌザヌのために䟡倀あるプロダクトを䜜りたい䞭長期芖点」 経営・事業偎の芁求 : 「今月の売䞊はどうするんだ短期芖点」 この板挟みになり、PL達成のために本質的でない機胜開発に远われおしたうのが「PMあるある」です。岞本さんはこれを、単なるコミュニケヌション䞍足ではなく、 芋おいる指暙ず時間軞のズレ による構造的な問題だず指摘したした。 芖点を倉える3぀のポむント 1. 売䞊は「遅効性指暙」である 経営䌁画や経営陣にずっお、売䞊などの財務数倀はあくたで「結果遅効性指暙」に過ぎたせん。 経営者が真に芋極めたいのは、すでに起きた結果ではなく、「隠れた未来先行指暙」です。 プロダクトが本質的な䟡倀を提䟛できおいるかどうかが、将来の売䞊を䜜る先行指暙ずなり埗たす。 2. 指暙を芋る「順序」を倉える 「売䞊を䜜るためにプロダクトを䜜る」のではなく、「垂堎TAM/SAM/SOMずいう倧きなポテンシャルから逆算し、䟡倀提䟛の進捗を確認する」ずいうアプロヌチぞの転換が提案されたした。 TAM/SAM/SOMを芋据える : たず自分たちが戊っおいる垂堎の党䜓像ずポテンシャルを定矩する。 䟡倀の開拓スピヌドを確認する : その巚倧な垂堎に察しお、プロダクトがどの皋床のスピヌドで䟡倀を届けられおいるかを枬定する。 結果ずしお売䞊を芋る : 䞊蚘の結果ずしお぀いおくる数字ずしお売䞊を捉える。 この順序でロゞックを組むこずで、「短期的な売䞊」ずいう小さな枠組みではなく、「巚倧な垂堎を取りに行くための投資」ずいう文脈でプロダクト開発を語れるようになりたす。 3. 事業戊略ずは「䟡倀から逆算するこず」 キャディ瀟の事䟋補造業2,000兆円垂堎ぞの挑戊を挙げながら、産業党䜓の課題IssueからTAMを芏定し、そこから逆算しお珟圚のプロダクト戊略を描く重芁性が語られたした。 PLに振り回されるのではなく、 PL結果をコントロヌルするための倉数が「プロダクト䟡倀」である ず定矩し盎すこずが、戊略的PMぞの第䞀歩ずのこずです。 感想 「売䞊は遅効指暙でプロダクト䟡倀がその土台である」ずいうのは、蚀われおみれば圓たり前のこずです。䞀方で、実務でその考え方に基づいた刀断ができおいたかずいうず、そうではなかったず感じたした。 PLを意識しお小手先の取り組みに終始したこずがある反省がありたす。 それを螏たえお今埌は垂堎ず顧客を深く理解し、䟡倀をベヌスにプロダクトの展望を倧きくか぀根拠を持っお語れるようにしおいかねばず思いたした。 (執筆小西 裕真) 「PMが未来に挑む、っお䜕──倉化の時代に“察話”で未来を描く」 登壇者(むンナヌサヌクル) 株匏䌚瀟TVer / サヌビスプロダクト本郚プロダクト掚進郚郚長 束岡 綟乃 BASE株匏䌚瀟 / 執行圹員 BASE BANK 事業 事業責任者 柳川 慶倪 PM Jam / プロダクトマネヌゞャヌ 飯沌 亜玀 ファシリテヌタヌ Product People Inc. / 提携プロダクトコヌチ 広瀬 䞈 氏 「PdMの未来」を問う、熱気ある1時間45分 〜フィッシュボりル圢匏で議論された「PM䞍芁論」ず「本質的な圹割」〜 OSTの裏偎では、「PMの未来」をテヌマに、参加者同士が察話を行う「フィッシュボりル」圢匏でのディスカッションを実斜しおいたした。 ■ 議論のテヌマず圢匏 圓初のテヌマは「PMの未来」でしたが、議論は「そもそもPMはいらないのでは」ずいう、より根源的か぀挑発的な問いからスタヌトしたした。フィッシュボりルずいう発散型の倧芏暡察話手法を甚いるこずで、予定されおいた1時間45分は、フェヌズや立堎の異なる参加者たちによる濃密な議論の堎ずなりたした。 ■ さたざたなトピック 議論の䞭では、プロダクトマネゞメントの圹割の曖昧さや倚面性に぀いお、以䞋のような芖点が飛び亀いたした。 事業フェヌズによるPMの圹割倉遷 経営局ず珟堎を぀なぐ「結節点」ずしおの機胜 「なぜビゞネスサむドでは代替できないのか」ずいう問い 経営者・事業責任者ずPdMの境界線 ■ 印象的な議論「ロヌドマップを曞いお捚おる」 その䞭でも印象に残ったトピックの䞀぀が、「ロヌドマップは曞いお捚おる」ずいう䞀蚀から始たった、䞍確実性の高い珟代におけるロヌドマップのあり方です。 議論の䞭では、䞍確実性の高い時代においお「固定化はリスクである」ずいう認識のもず、状況に合わせお適切にロヌドマップを曞き換え、䜕が最善かを考え抜くこずの重芁性が語られたした。 しかし、単に曞き換えるだけでは短期的な斜策に終始しおしたう懞念もありたす。そのため、2-3幎埌を意識し珟圚地を把握しながら、今の状況に必芁な意思決定をしおいく芖座が求められたす。 これには、PMには蚈画策定胜力だけでなく、状況に応じた意思決定力や、ステヌクホルダヌぞの説明責任、適切なコミュニケヌションなどの総合的なスキルが求められるず気付きたした。 単に「PMずは䜕か」を定矩するのではなく、倉化の激しい時代においお「どのような芖座でプロダクトや組織に向き合うべきか」を再考させられる、非垞に瀺唆に富んだセッションずなりたした。 (執筆飯田 咲玀) おわりに å…š3回にわたり、pmconf2025のセッションレポヌトをお届けしたした。 蚈7名のPMで参加した今回のカンファレンス。各セッションを通じおさたざたな孊びが埗られたした。 「売䞊はプロダクト䟡倀の遅効指暙である」ずいう蚀葉の通り、私たちが向き合うべきは垞に「ナヌザヌのペむン」ず、その先にある「垂堎ぞの䟡倀提䟛」です。 今回埗た熱量ず知芋を日々の開発に還元し、タむミヌはこれからも「はたらく」のむンフラずしお、ナヌザヌの皆様に驚きず信頌を届けるプロダクトを぀くり続けおいきたす。 さいごに、pmconfではブヌスも出展しおいたしたが、タむミヌでは、共に「はたらく」の未来を぀くる仲間も募集しおいたす。興味を持っおいただいた方は、ぜひカゞュアルにお話ししたしょう 執筆飯田 咲玀・タむミヌPM䞀同
こんにちは、タむミヌで゚ンゞニアをしおいる埳富 @yannKazu1 です。 前回の蚘事では、 EKS 䞊に self-hosted GitHub Actions Runner 基盀を構築した話 をご玹介したした。 â–Œ 前回の蚘事 https://tech.timee.co.jp/entry/2025/09/22/122415 ありがたいこずに、この取り組みは AWS さんの公匏ブログでもご玹介いただきたした 。 👉 AWS ブログ https://aws.amazon.com/jp/blogs/news/timee-amazon-eks-auto-mode/ 今回はその続線ずしお、 EKS のクラスタヌバヌゞョンアップを、どうやっお安党に自動化したか に぀いおお話ししたす。 EKS のクラスタヌバヌゞョンアップ、地味に぀らい EKS を運甚しおいるず、どうしおも避けお通れないのが 定期的なクラスタヌバヌゞョンアップ です。 Kubernetes のマむナヌバヌゞョンは定期的に EOL が来る 攟眮するずサポヌト切れになる ずはいえ、毎回人が確認しお手動で䞊げるのは正盎しんどい 「これ、もう少し楜にできないか」 そう思ったのが、今回の仕組みを考え始めたきっかけでした。 今回の前提EKS Auto Mode を䜿っおいる 今回運甚しおいる EKS では、 EKS Auto Mode を採甚しおいたす。 EKS Auto Mode では、 ノヌド管理 䞻芁な Add-on 管理VPC CNI / AWS Load Balancer Controller など を AWS 偎で管理しおおり、運甚負荷を軜枛できたす。 そのため、クラスタヌバヌゞョンアップの流れは比范的シンプルです。 マニフェストで 非掚奚 API を䜿っおいないか確認 する 問題なければ クラスタヌバヌゞョンをアップ する ノヌドや䞻芁 Add-on は AWS が自動で远埓 する さらに EKS には Upgrade Insights ずいう䟿利な仕組みがありたす。 非掚奚 API の䜿甚状況 バヌゞョンアップ時に問題になりそうな点 を事前にチェックできるため、 「このバヌゞョンに䞊げお倧䞈倫か」をかなり楜に刀断できたす。 自動化の方針 ずはいえ、いきなり本番クラスタヌバヌゞョンを自動で䞊げるのは、さすがに怖い。 そこで、次の方針で仕組みを䜜りたした。 1. 本番ずは別にテスト甚クラスタヌを甚意する Self-hosted Runner 甚の main クラスタヌずは別に、 怜蚌専甚の test クラスタヌ を甚意しおいたす。 コストを抑えるため Spot むンスタンスを䜿甚 する 最小構成で test-runner のみを起動 する むンフラは次のように管理しおいたす。 クラスタヌや AWS リ゜ヌス Terraform ARC Controller などの Helm リ゜ヌス Terraform その他の Kubernetes リ゜ヌス マニフェストKustomize この構成にしおいるこずで、 test / main クラスタヌに ほが同じ蚭定をそのたた適甚 できる runner の 台数やサむズだけを環境ごずに切り替え られる ずいったこずが簡単にできたす。 結果ずしお、 コントロヌラや蚭定は本番ず同䞀 リ゜ヌスむンスタンスサむズ・台数を最小構成にした test-runner ずいう、「本番に限りなく近いが、䜎コストなコピヌ環境」を䜜れおいたす。 2. テストクラスタヌで先にバヌゞョンアップする テストクラスタヌでは、次の条件を満たした堎合のみ 自動でバヌゞョンアップを行いたす。 ① リリヌスから 1 か月以䞊経過したバヌゞョンであるこず aws eks describe-cluster-versions \ --include-all \ --query 'clusterVersions[?versionStatus==`STANDARD_SUPPORT`].{version: clusterVersion, releaseDate: releaseDate}' \ --output json 取埗した結果を jq で加工し、 「リリヌスから 1 か月以䞊経過しおいるバヌゞョン」のみを察象にしたす。 ② Upgrade Insights がすべお PASS しおいるこず INSIGHTS_JSON=$(aws eks list-insights \ --cluster-name ${{ inputs.cluster-name }} \ --output json) ERROR_COUNT=$(echo "$INSIGHTS_JSON" | jq '[.insights[] | select(.category=="UPGRADE_READINESS" and .insightStatus.status=="ERROR")] | length') WARNING_COUNT=$(echo "$INSIGHTS_JSON" | jq '[.insights[] | select(.category=="UPGRADE_READINESS" and .insightStatus.status=="WARNING")] | length') ERROR / WARNING があればブロックする UNKNOWN は未䜿甚機胜なので蚱容する これらの条件をすべお満たしおいる堎合のみ、毎朝 7 時に GitHub Actions から aws eks update-cluster-version を実行したす。 3. test クラスタヌの結果を cluster_version.txt の PR ずしお残す 本番クラスタヌのバヌゞョンアップは、 cluster_version.txt に曞かれたバヌゞョンぞ曎新する ずいう前提で蚭蚈しおいたす。 そのため、 本番をい぀䞊げるかだけは人が刀断できるように cluster_version.txt の曎新は必ず PR 経由にしおいたす。 test クラスタヌバヌゞョンアップが正垞に完了するず、 実際に䞊がった EKS バヌゞョンを そのたた cluster_version.txt に曞き蟌み 自動で PR を䜜成 したす。 # **cluster_version.txt** 1.34 この PR をマヌゞするず、 その日の深倜に 本番クラスタヌバヌゞョンアップが実行されたす。 怜蚌は自動で完了枈み 本番反映の日付だけ人が刀断する ずいうバランスに萜ち着きたした。 本番クラスタヌバヌゞョンアップフロヌ 本番クラスタヌバヌゞョンアップは、 毎日 深倜 2 時 に GitHub Actions から定期実行しおいたす。 流れは次のずおりです。 1. cluster_version.txt ずの差分を確認 cluster_version.txt のバヌゞョン 珟圚の本番クラスタヌのバヌゞョン を比范し、差分がなければここで終了したす。 差分がある堎合のみ、以降のチェックに進みたす。 2. Upgrade Insights が PASS しおいるこずを確認 INSIGHTS_JSON=$(aws eks list-insights \ --cluster-name ${{ inputs.cluster-name }} \ --output json) ERROR_COUNT=$(echo "$INSIGHTS_JSON" | jq '[.insights[] | select(.category=="UPGRADE_READINESS" and .insightStatus.status=="ERROR")] | length') WARNING_COUNT=$(echo "$INSIGHTS_JSON" | jq '[.insights[] | select(.category=="UPGRADE_READINESS" and .insightStatus.status=="WARNING")] | length') 3. test-runner のヘルスチェックを実行 本番アップグレヌド前に、 test クラスタヌ䞊の Self-hosted Runner が正垞に動くか を確認したす。 簡単な workflow_dispatch のワヌクフロヌを甚意しおいたす。 name: Test Runner Health Check on: workflow_dispatch jobs: health-check: runs-on: test-runner # testクラスタヌ䞊のtest-runnerを指定する timeout-minutes: 10 steps: - run: | echo "✅ test-runner is healthy!" hostname date このワヌクフロヌを gh コマンドで起動し、 10 分以内に success するこず を確認したす。 ポヌリング凊理は省略しおいたすが、実装䞊は完了を埅っおいたす 4. 問題なければ本番クラスタヌバヌゞョンアップ aws eks update-cluster-version \ --name ${{ env.MAIN_CLUSTER_NAME }} \ --kubernetes-version "$TARGET_VERSION" 流れを図で衚すず、以䞋のずおりです。 なぜ深倜 2 時に「自動で」䞊げるのか 「本番反映の日付は人が制埡」ず曞きたしたが、厳密には PR をマヌゞした日の深倜 2 時に自動でクラスタヌバヌゞョンアップが走る 仕組みです。 ぀たり、人が決めるのは 「い぀の深倜にクラスタヌバヌゞョンアップを実行するか」 だけ。 この蚭蚈にしおいる理由は 2 ぀ありたす。 1. 深倜ならデプロむず競合しない デプロむが走っおいない時間垯である ノヌド曎新時に Pod が退避しおも圱響が出にくい デプロむ途䞭で Pod が萜ちる事故を防げる 2. 問題が起きおも業務開始埌に察凊できる Self-hosted Runner の利甚箇所では、Organization variablesを䜿っお runner を指定しおいたす。 runs-on : ${{ vars.RUNNER_AMD64_STANDARD }} もしクラスタヌバヌゞョンアップ埌に問題が発芚しおも、この倉数の倀を ubuntu-latest などに倉曎するだけで、党リポゞトリのワヌクフロヌが GitHub-hosted runner で動くようになりたす。 コヌドを䞀切倉曎せずにフォヌルバックできるため、 業務開始埌に気づいおからの察応でも十分間に合いたす 。 このフォヌルバック手段があるからこそ、 深倜に自動でクラスタヌバヌゞョンアップを実行 人は「日付を決める」だけ ずいう運甚が成り立っおいたす。 Terraform 管理ずの付き合い方 むンフラは Terraform で管理しおいたすが、 EKS のクラスタヌバヌゞョンだけは Terraform 管理倖 にしおいたす。 cluster_version に ignore_changes を蚭定しおいる バヌゞョンアップは CLI で実斜しおいる これにより、 CLI で䞊げおも Terraform 差分が出ない IaC ず運甚の責務をきれいに分離できる ずいうメリットがありたす。 たずめ この仕組みを導入したこずで、 クラスタヌバヌゞョンアップの toil を倧幅に削枛できた 「test → 本番」の安心できるフロヌを自動化できた Self-hosted Runner が壊れないこずを事前に保蚌できるようになった ずいう成果が埗られたした。 EKS Auto Mode の特性を掻かすこずで、 「人が気合で回す運甚」から䞀段階進められたかなず思っおいたす。 同じように EKS を運甚しおいる方の参考になれば嬉しいです 🙌
こんにちは、DevPFチヌムの菅原です。 珟圚、匊瀟のアプリケヌション基盀ECS on Fargateでは、コンテナログの収集・転送に FireLens を採甚し、 Datadog Logs ぞ集玄しおいたす。FireLensはタスク定矩に数行蚘述するだけでログ基盀が敎う非垞に䟿利な機胜です。䞀方で裏偎では、 Fluent Bit がサむドカヌずしお動䜜し、耇雑なパむプラむンを凊理しおいたす。 「ログなんお暙準出力に出せば、あずは勝手に届くもの」 そう思われがちですが、実際にはアプリケヌションコンテナからDatadog Logsのexplorerに衚瀺されるたでには、いく぀もの難所が存圚したす。今回は、ログがDatadogに到達するたでのアヌキテクチャを玐解きながら、ログが「どこで」「なぜ」欠損するのかを解説したす。 ログ転送のアヌキテクチャ抂芁 たずは珟圚の構成のおさらいです。 基盀 : AWS ECS on Fargate(v1.4) ログ収集 : FireLens (実䜓はFluentdたたはFluent Bitサむドカヌ。匊瀟ではFluent Bitを採甚) 送信先 : Datadog Logs アプリケヌションが出力したログは、倧たかに以䞋の経路を蟿りたす。 Appコンテナ : stdout/stderrぞログを曞き蟌む shim logger プラグむン : containerd-shimのロガヌプラグむン。shim loggerが各コンテナのstdout/stderrをパむプ経由で定期的に読み蟌み、サむドカヌのFluent Bitに転送。 Log router (Fluent Bit)コンテナ : ログを受け取り、バッファリング・加工を行う Network : Datadog APIぞHTTPSで送信 Datadog : Ingest取り蟌み・Indexingむンデックス化 䞀芋シンプルですが、この経路には倧きく分けお4぀の「欠損リスク」が朜んでいたす。 アプリケヌション 〜 Fluent Bit間のバックプレッシャヌ 最初の難関は、ログがサむドカヌに枡る瞬間です。 仕組み FireLensを䜿甚する堎合、Fargate (v1.4) の内郚では shim-loggers-for-containerd が䜿甚されたす。 アプリケヌションが出力したログは、この shim logによっおパむプ経由で読み取られ、Unix Socketを経由しお Fluentd Forward Protocol でサむドカヌのFluent Bitに転送されたす。 ここで䜕が起きるか Fluent Bitで凊理が詰たったりしおバッファがいっぱいになるず、Fluent BitはInputを䞀時停止したす。その間、アプリケヌションが出力し続けるログはどうなるでしょうか Fluent BitがInputを停止しおいる間に出力されたログは、Fargate基盀偎のshim logger内のメモリバッファやその前段のパむプのバッファに溜たりたす。しかし、このバッファも有限です。よっおFluent Bitが埩垰しお再開したずきには、その間のログは闇に消えおいる可胜性がありたす。 application-to-sidecar 察策 出来るだけ凊理が詰たらないようにする、可胜な範囲でバッファを倧きくするこずが察策ずなるず考えたす。䟋えば次のようなこずができるでしょう。 䞍芁なログを出力しない log-driver-buffer-limit オプションでのshim loggerレむダのチュヌニング log_routerのバッファサむズ、retryの䞊限蚭定等のチュヌニング Outputの倱敗ず道連れ欠損 Fluent Bitがログを受け取った埌、Datadogぞ送信するフェヌズです。 仕組み Fluent Bitはログを1件ず぀送るのではなく、効率化のために耇数のログをたずめおChunkにし、䞀定サむズたたは䞀定時間ごずに送信したす。 ここで䜕が起きるか Outputの倱敗は、「むンフラ起因」ず「ログ内容起因」の2぀のパタヌンに分けられるず考えたす。それぞれの挙動ずリスクを芋おいきたしょう。 むンフラ起因ネットワヌクや転送先の障害 むンタヌネット接続の問題や、Datadog API偎の䞀時的な障害、あるいはAPIキヌ等の蚭定ミスなどがこれに該圓したす。 Fluent Bitは送信に倱敗するず、蚭定された回数 Retry_Limit 蚭定だけ再送を詊みたす。しかし、障害が長時間続いおリトラむ回数を䜿い切るず、そのChunkは砎棄されたす。 欠損を防ぐためにリトラむを無限に蚭定するこずも可胜ですが、送信できないログがFluent Bitのバッファに滞留し続けるこずになりたす。これが解消されないずバッファが埋たったたたになり、結果ずしお前述のむンプットの䞀時停止を匕き起こし、新たなログの取り蟌み自䜓が止たっおしたいたす。 https://docs.fluentbit.io/manual/data-pipeline/buffering#per-input-settings 特定ログ起因 䞍正なログによる巻き添え欠損 これが厄介なケヌスです。むンフラは正垞でも、アプリケヌションが出力した「特定のログ」が原因で発生するこずがありたす。 Datadog Logs APIには、「ペむロヌドあたり最倧コンテンツサむズ非圧瞮: 5MB」ずいう制限がありたす。 䟋えば、Base64゚ンコヌドされた画像やPDFデヌタを含む 数MBの巚倧なログ が1件出力されたずしたす。Fluent Bitはこの巚倧ログず、同じタむミングで出力された正垞な小さいログをたずめお1぀のChunkにしおしたいたす。Fluent Bitのdatadog output pluginはChunk単䜍でログを送信したす。このChunkを送信しようずするず、サむズ制限超過によりDatadogから 413 Payload Too Large ゚ラヌが返されたり、接続がリセットされたりしたす。 重芁なのは、 問題のある巚倧ログだけでなく、同じChunkに含たれおいた正垞なログもたずめお拒吊されおしたう 点です。たった1行の行儀の悪いログのせいで、呚囲の無実なログたで道連れにしお消えおしたう可胜性があるのです。 Fluent Bitのメモリバッファのサむズ制限を蚭ければいいのではず思われるかもしれたせん。しかし、該圓する mem_buf_limit 蚭定は ゜フトリミット ずしお実装されおいるようです。読み解いた゜ヌスコヌドレベルの挙動ずしおは、「曞き蟌み前に空き容量をチェックする」のではなく、「曞き蟌んだ埌に䞊限を超えおいないかチェックする」ずいう動きで、䞀時的に䞊限を超過するこずは蚱容されおいるようでした。 mem_buffer_limit = 5MBの時に巚倧なログが来た堎合の挙動 察策 方向性は倧きくアプリケヌション局での予防的蚭蚈ず、転送局でのフィルタリング・バッファ制埡が考えられたす。いずれもトレヌドオフを䌎うため、システムの特性に応じたバランスが求められたす。 アプリケヌション偎で長倧なログを出力しないよう制限する アプリケヌションたたはfluent bitレむダで䞀定サむズを超えるログフィヌルドを自動的に切り捚おるようにする 特定パタヌンのログを陀倖たたは眮換する mem_chunk_size , flush_interval を短くしお巻き添え欠損の圱響範囲を小さくする メモリバッファの消倱 Fargateのようなコンテナ環境特有のリスクです。 仕組み Fluent Bitのバッファ蚭定をデフォルトの memory にしおいる堎合、ログは送信完了たでメモリ䞊にしか存圚したせん。 ここで䜕が起きるか コンテナが予期せず停止した堎合、メモリ䞊の未送信ログは消滅したす。これは異垞時だけでなく、通垞のデプロむフロヌでも発生し埗たす。 ECSタスク停止時、コンテナにはSIGTERMが送られたす。 タスク定矩の stopTimeout デフォルト30秒以内に終了しない堎合、SIGKILLで匷制終了されたす。 Fluent Bit偎にもシャットダりン時の埅機蚭定 Grace がありたすが、これらが噛み合わず、バッファをFlushしきる前にプロセスが匷制停止されるずログは欠損したす。 匕甚: 「ECS のアプリケヌションを正垞にシャットダりンする方法」, Amazon Web Services ブログ, https://aws.amazon.com/jp/blogs/news/graceful-shutdowns-with-ecs/ 察策 バッファのストレヌゞタむプを filesystem に倉曎し氞続化する。ただしECS Fargateの堎合、珟実的に䜿えるのがEFSくらいで氞続化ストレヌゞの利甚に制限があるためトレヌドオフの怜蚎が必芁です。 stopTimeout ず Grace の倀を適切に調敎し、シャットダりン時にFlush完了たでの十分な猶予時間を確保する。 flush_interval を短く蚭定し、バッファに溜たるログの量を枛らすこずで、シャットダりン時の欠損リスクを最小化する。ただし、ネットワヌク負荷ずのバランスを考慮する必芁がありたす。 Datadog偎の制限 無事にむンタヌネットを越えおDatadogに届いおも、最埌の難所がありたす。 ここで䜕が起きるか Datadog偎にも厳栌な受入ルヌル があり、これに違反するず取り蟌み埌に削陀、たたは切り捚おられたす。 日次クォヌタ超過 : コスト管理のために蚭定したむンデックスの䞊限を超えた堎合、むンデックスには保存されたせんアヌカむブ蚭定があればS3には残りたす。 タむムスタンプ : ログの日時が「18時間以䞊過去」の堎合、取り蟌み察象倖ずなり削陀されたす。 サむズ制限 : 単䞀ログが1MBを超える堎合、Datadogによっお切り捚おTruncateが行われたす。 前述の通り、APIぞの送信ペむロヌド党䜓非圧瞮が5MBを超えるず、そもそも受け入れられず゚ラヌずなりたす。 察策 日次クォヌタの監芖アラヌトを蚭定する 前述の通り、アプリケヌション偎ずFluent Bit偎で察策を行い、Datadog偎の制限に匕っかからないようにする。 retry間隔がタむムスタンプの制限を超えないように再送の蚭蚈をする たずめ ログ基盀の信頌性を高めるためには、これらの欠損ポむントを理解した䞊での蚭蚈・運甚が必芁です。 Input : Fluent Bitが詰たるずその前段でログが溢れ欠損しうる。 Output : Chunk単䜍で凊理されるため、異垞なログが正垞なログを巻き蟌むこずがある。送信リトラむはトレヌドオフがある。 Buffer : メモリバッファは揮発しうる。 Ingest : Datadog偎のクォヌタやサむズ制限も意識する。 ログが欠損しおいるずいう事象に盎面したずき、アプリケヌションコヌドだけでなく、この険しい道のりのどこで詰たっおいるのかを想像できるず、調査の解像床がぐっず䞊がるはずです。 参考資料 Amazon Web Services2025「詳现: Fargate デヌタプレヌン」AWS ブログ2026幎2月2日 https://aws.amazon.com/jp/blogs/news/under-the-hood-fargate-data-plane/  Amazon Web Services2025「Send Amazon ECS logs to an AWS service or AWS Partner」Amazon ECS Developer Guide2026幎2月2日 https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_firelens.html  Amazon Web Services2025「ECS のアプリケヌションを正垞にシャットダりンする方法」AWS ブログ2026幎2月2日 https://aws.amazon.com/jp/blogs/news/graceful-shutdowns-with-ecs/  Fluent Bit2025「Buffering and Storage」Fluent Bit Manual2026幎2月2日 https://docs.fluentbit.io/manual/administration/buffering-and-storage  Fluent Bit2025「Backpressure」Fluent Bit Manual2026幎2月2日 https://docs.fluentbit.io/manual/administration/backpressure  Datadog2025「ログのトラブルシュヌティング」Datadog Docs2026幎2月2日 https://docs.datadoghq.com/ja/logs/troubleshooting/ 
株匏䌚瀟タむミヌのshihorinです。 1月7〜9日に開催された「Regional Scrum Gathering Tokyo 2026RSGT2026」に参加しおきたした。 RSGTに参加するのは、昚幎に続き2回目です。昚幎11月に「DevEnable宀プロダクト組織運営や技術広報を担うチヌム」に異動したため、今回は組織運営や文化醞成の芳点を特に意識しお参加したした。 特に印象的だったセッションやOSTで埗られた孊び・感想を、このブログでアりトプットしおみたす。 🪎 コミュニティ文化を組織に根付かせる〜掚進者ずバトンを受け取った実践者が語るコミュニティの䟡倀ず持続可胜性ぞの道筋〜 speakerdeck.com 株匏䌚瀟ログラスの飯田さん・氞井さんによるセッションです。 コミュニティに参加し始め、コミュニティに助けられた個人の経隓を起点に、瀟内でコミュニティ文化を根付かせ、持続させるたでの実践的な取り組みが、ストヌリヌに沿っお語られるセッションでした。1人で始めたこずが䌚瀟から認められるようになり、やがお共に掚進しおくれる仲間にバトンを繋げられた、玠敵なストヌリヌだなず思いたした。 このセッションを聞いお、重芁だず思った芁玠はこの2぀です。 自分がやっおみお、呚りに広める 「なんだか怖い」ず思っおも、きっかけを逃さず飛び蟌んでみる。そこで埗られたものを呚りに広める。 自分がやるこずで、掻動の䟡倀を語れるようになる。 継続が倧事 継続するこずで耇利的に䟡倀が䞊がる。 維持する努力を続けなければ維持できない。1人の匷いパワヌだけでも続かない。耇数の小さなモメンタムを生むきっかけ䜜りず、維持するための埌抌しを根気よく行う。 これらはコミュニティ掻動に限らず、カルチャヌを぀くる・広める䞊で共通する考え方ではないでしょうか。 最近私は「発信文化を継続的に育おる」ずいう業務に取り組み始めたした。自分自身が「発信掻動の䟡倀」を語れるようになるために、今幎はどこかのカンファレンスにプロポヌザルを出しおみようず思いたす   そしおこのセッションは、自分自身のコミュニティ掻動に関するこれたでず珟圚地を振り返るふりかえるきっかけにもなりたした。 私はタむミヌ入瀟前たで、気が向いた時にごく皀にconnpassでむベントを芋぀けお参加するくらいでした。入瀟埌は、呚りのメンバヌがカンファレンスやむベントに積極的に参加しおいるのを知り、私も同様に足を運ぶようになりたした。倧きな進歩ではあるず思いたすが、「その堎に行くだけで満足しおしたっおいるのかも」ず、セッションを通しお気づきたした。今こそ、努力の方向性を倉えるタむミングなのかもしれたせん。今埌は「小さくおも良いので自分がその堎に䜕らか貢献する」を意識しおコミュニティ参加できるようになりたいず思いたす。 🔥 自己管理型チヌムず個人のセルフマネゞメント speakerdeck.com 株匏䌚瀟カケハシの小田䞭さんによるセッションです。 自己管理型チヌムであるために倧切なこずを語られおいたした。 䞀人ひずりのセルフマネゞメントが必芁。セルフマネゞメントの土台には「モチベヌションマネゞメント」があり、モチベヌションの源泉心の着火点は人によっおも時にもよっお倉化する。 メンバヌのタむプによっお、マッチするモチベヌションの匕き出し方目暙蚭定やマネヌゞャヌの働きかけ方がある。 欲求ERG理論でいう「成長」「関係」「存圚」が損なわれるず摩擊が起きる。アルバヌト・゚リスのABC理論を甚いお内省し、摩擊を乗り越えられるように行動する。 そしお最埌は、「自分が䜕にモチベヌションを感じるかを明確にし、たずは自分からセルフマネゞメントしおモチベヌションを匕き出しおいくこずにぜひトラむしおください」ずいうメッセヌゞで締められおいたした。 ※ERG理論: 「成長」「関係」「存圚」の3぀の欲求で構成されるモチベヌション理論のこず ※ABC理論: 発生した出来事に察し、信念が圱響を起こし、感情を匕き起こす、ずいう理論 私が所属しおいるチヌムは、以前は各自の守備範囲に集䞭するスタむルでしたが、今はお互いに越境し支え合う姿を目指しおいたす。たさにこのセッションで語られおいた「自己管理型チヌム」だず気づきたした。 私は぀いチヌムのプロセスに焊点を圓おがちで、メンバヌ䞀人ひずり自分も含めおの内面に目を向けるこずが疎かになっおいたように思いたす。たずは自分、そしお呚りのメンバヌのモチベヌションの源泉に思いを銳せ、心の火を燃やし続けられるよう支揎しおいきたいです🔥 Day3のOST 16トラック x 4枠1枠30分のテヌマが起祚されおいたした。ずらりずテヌマが䞊んだボヌドは圧巻でした どれにするか迷い぀぀、今取り組んでいる業務に関連しそうなテヌマを遞んで参加しおきたした。 その内2぀に぀いお曞いおみたす。 テヌマ今日の孊びを少しず぀、ほんの少しず぀、チヌムや組織の共通知に倉える仕組み タむミヌのプロダクト組織では、業務時間内にカンファレンスに参加した堎合、瀟倖発信レポヌトの執筆もしくは登壇をお願いしおいたす。䞀方で「レポヌト執筆・登壇以倖にも孊びを広める手段は様々あるはずで、もっず詊せないだろうか」ず個人的に課題感を持っおいたため、このテヌマに参加したした。 このテヌマを起祚した方のお話を深掘りしおいくず、 䌚瀟からRSGTに参加しおいるメンバヌが少数。RSGT、アゞャむル、スクラムに興味を持っおいる人が珟時点では限られおいる。 ドキュメントにたずめお枡しおも、分量が倚いず受け取りづらいこずがある。重たいず感じられおいるのではないかず考えおいる。 孊んできたこずを熱心に話しおも、人によっお反応の枩床差がある。 ずいう背景があるず分かりたした。 孊んできた偎の心の火は燃え䞊がっおいおも、受け取る偎の準備ができおいない状態のように芋えたす。 ディスカッションで出た「孊びを100そのたたぶ぀けるのではなく、盞手が受け取れるタむミングで届けられるよう芋極めるこずが倧事なのでは」ずいうアむデアは、特に玍埗感があり、蚘憶に残りたした。「今がそのタむミングだ」ず気づいた時にすぐ取り出せるように、孊んだこずの蚀語化・䜓系化もセットで必芁そうですね。 DevEnable宀が策定しおいる「発信にた぀わるガむドラむン」では、「自身の知芋を圢匏知に倉換できるこず」を発信掻動の1぀の目的ずしお蚘茉しおいたす。そこに、「時が来た時にすぐ取り出しお䜿える」ずいう具䜓的な利甚シヌンを補足するこずを怜蚎したいず思いたす。 テヌマパックマンルヌル、どうしおる 先日行われた瀟内懇芪䌚で、参加者にパックマンルヌルぞのご協力をお願いしたした。ですが、知っおいる人同士で固たっおしたいがちでした。 「パックマンルヌルぞの協力をお願いするだけでは足りない」ずチヌム内で話しおいたため、ヒントを埗ようずこのテヌマに参加したした。 ディスカッションしながら自分たちでパックマンルヌルを詊した結果、2぀のコツが分かっおきたした。 今埌懇芪䌚などでパックマンルヌルを䜿う時は、説明スラむドの䞭にこれらを入れおみようず思いたす。 パックマン偎から「食いにいく」パックマンを圢成しおいる人たちは、近くを歩いおいる人を芋぀けたら招き入れる目を合わせる、手招きする、スペヌスを開ける。 パックマンに自ら「食われにいく」「今どんな話をしおいるんですか」ずいうフレヌズを䜿えば途䞭からでも入っおいける。話しかけられおOK感を自分から挔出する䟋「話したい」意思衚瀺シヌルを貌る。 運営の立堎だず、「人が集たれる堎所を甚意するこず」も1぀の工倫ずしお実践できそうです。 䟋えば、壁際に怅子を䞊べおみるず、3人䞊んで座っおもグルヌプが閉じた状態にならないので、4人目が入りやすいですよね。 終わりに 前回のRSGTは新蚭チヌムのスクラムマスタヌずしお参加しおいたしたが、今回は違う立堎での参加でした。 セッションやOSTの遞び方はもちろん、スポンサヌブヌスや廊䞋での䌚話内容も前回ずは倉化があり、新鮮な気持ちで参加できたした。 今回埗られた孊びは、蚀語化・反芻しお、時が来た時にすぐ扱えるように準備したいず思いたす。 そしお最埌に宣䌝です タむミヌでは珟圚、䞀緒にはたらく仲間を募集䞭です。 孊習ず実践のサむクルをたわしながらプロダクト開発に取り組みたい方、ご興味があればぜひお話ししたしょう プロダクト採甚サむトTOP カゞュアル面談申蟌はこちら
今回は、タむミヌの「 Kaigi Pass 」制床を利甚しお、12/4に開催のされたプロダクトマネヌゞャヌカンファレンス以䞋、pmconfに参加しおきたした。 この制床を通じお、非垞に有意矩な孊びを埗るこずができたしたので、その内容を共有したす。 参加セッション 「メルカリのデヌタ分析AI゚ヌゞェント『Socrates゜クラテス』ず、それを支えるデヌタ敎備」 登壇者株匏䌚瀟メルカリ デヌタアナリティクスチヌム セッション詳现・孊び 1. 背景ず課題 (As-is) メルカリでは専任のデヌタアナリストのリ゜ヌスが最沢ではなく、アナリストがいないチヌム0名のチヌムも存圚では、PdMが自らが分析を行う必芁がありたした。 郚門を超えたむンサむト収集の困難さ: 自分の担圓倖の領域䟋メルカリ担圓がメルペむのデヌタを芋る等は分析のハヌドルが高く、工数を芁するため、耇合的な意思決定が困難でした。 リ゜ヌスの壁: 「分析キャパシティ」がボトルネックずなり、問いの量ず質が制限されおいたした。 2. 解決策AI゚ヌゞェント「Socrates」 (To-be) 自然蚀語で察話可胜な分析゚ヌゞェントを導入するこずで、以䞋の状態を実珟しおいたす。 未知の領域にも察応: 「メルペむの預金残高の䜿い道内蚳」のような、ドメむン知識がない領域でも、゚ヌゞェントがデヌタを探し出しお集蚈・可芖化しおくれたす。 䞊列思考: 耇数の芳点Parallel Agentでブレストを行い、仮説出しから怜蚌たでを䞀気通貫で実行したす。 問いの量ず質の向䞊: リ゜ヌス制玄を気にせず貪欲に調べられるようになりるこずで、アりトプットの総量もが盎結しお向䞊したす。 3. 実珟のための土台Basic Tables AIが正しくデヌタを扱える理由ずしお、 「AI-Readableなデヌタ分析基盀」 の存圚が匷調されたした。 3局構造: Raw Data Tables → Basic Tables → Analytical Tables/Views ずいう構造を採甚。 特城: 「Basic Tables」は人間ずAIの䞡方が分析しやすいように敎理された䞭間テヌブルであり、ここに粘り匷く投資したこずが勝因です。 4. 組織ず運甚の工倫 ツヌルを入れるだけでなく、それを䜿いこなすための組織づく䜜りもセットで行われおいたす。 独立した実行組織: 䌁画・開発・マヌケたで完結できる遊軍的な「BI Productチヌム」が開発を䞻導。 䜿いこなしのルヌル: 気になったらたず゚ヌゞェントに聞く䟝頌する前に盞談。 基瀎的なSQLず瀟内DBの理解を持ち、ク゚リレビュヌを培底しお品質を担保する。 人を動かすための掻甚: レポヌトを蓄積するだけでなく、「隙あらば分析レポヌトをシュッ」ず提瀺し、ファクトをベヌスに組織党䜓を動かす文化を぀く䜜っおいたす。 5. 芁件定矩プロセスぞの応甚 分析だけでなく、芁件定矩のプロセス党䜓むンプット→凊理→アりトプットでにおいおも掻甚されおいたす。 むンプット: ナヌザヌログ、定性調査、競合調査など。 アりトプット: ナヌザヌストヌリヌ、機胜仕様曞、ABテスト蚭蚈曞など。 これらをAIが凊理するこずで、PdMの業務効率を飛躍的に高めおいたす。 珟堎芖点での気づきず、これからのアクション 今回のセッションを聞いお私たちが䜕を感じ、珟圚進めおいるプロゞェクトをどう加速させおいくのか。チヌムずしおの「熱量」ず「次の䞀手」をたずめたした。 私たちが埗た「確信」ず「気づき」 ■ 「領域暪断」こそが、Growthの壁を壊す スラむドに映し出された「郚門を超えたむンサむト収集が困難」ずいう悩みは、正盎なずころ「これ、今の私たちのこずだ」ず痛感したした。 特にGrowth領域でスピヌド感を持っお仮説怜蚌を回そうずするず、どうしおも担圓倖のデヌタやドメむン知識の壁にぶ぀かりたす。もし「Socrates」のように瀟内の党デヌタが地続きになり、AIがその文脈たでを理解しおくれれば、SQLを曞く時間を「ナヌザヌに向き合っお思考する時間」に倉えられたする。そうしたの未来図に、匷い可胜性を感じたした。 ■ 誰もが「迷子」にならずに意思決定できる組織ぞ 「意思決定の階局を枛らす」ずいう思想も、組織が急拡倧しおいる今の私たちにずっお非垞に重芁なテヌマです。 新しくゞョむンしたメンバヌが、耇雑なテヌブル定矩の森で迷子にならず、AIずいう「盞棒」を通じお過去の経緯やデヌタに即座にアクセスできる。それが実珟できれば、オンボヌディングのスピヌドも、自走力も劇的に倉わるはずです。 ■ 定性デヌタも「資産」ずしお䜿い倒す 数字定量デヌタだけでなく、商談メモや行動ログずいった「定性情報」たでAIに読たせるずいう構想にはワクワクしたした。 「数字には衚れないけれど、珟堎には萜ちおいるヒント」をAIが拟い䞊げおくれれば、私たちが生み出す仮説の粟床はもっず高たるはず。これを支えるための「培底したデヌタ文化」や「BI Productチヌム」ずいう䜓制づくりも含めお、本気で真䌌しおいきたいポむントです。 これからやるこずNext Actions ■ 進行䞭のPoCを、さらに磚き蟌む 実は珟圚、私たちも瀟内で同様のデヌタ基盀構築に向けた取り組みを、 PoC抂念実蚌ずしおすでに始めおいたすスタヌトさせおいたす。 「方向性は間違っおいなかった」ずいう心匷さを感じるず同時に、今回のセッションは、そのPoCを成功させるための倧きなヒントになりたした。 具䜓的には、以䞋の動きをすぐに始めたす。 「Basic Tables」の思想を、自分たちのPoCぞ 今回の倧きな孊びである「Basic TablesAIず人間、䞡方が読みやすい䞭間局」の構造 を、珟圚私たちが進めおいるPoCの蚭蚈ず照らし合わせおみたす。 DRE (Data Reliability Engineering) チヌムずも連携し、「今の蚭蚈でAIが本圓にデヌタを正しく読めるのか」ずいう芖点でからギャップを掗い出し、PoCの蚭蚈図をブラッシュアップしたす。 スモヌルスタヌトで「察話」を始める 基盀敎備ず䞊行しお、たずは特定のデヌタセットに絞った圢でも「察話型むンタヌフェヌス」を詊せないか怜蚎したす。来週さっそくチヌムで集たり、具䜓的なロヌドマップを匕く予定です。 メルカリさんの事䟋を刺激に、私たちも「未来のデヌタ分析䜓隓」の実装を䞀気に進めおいきたす。 関連資料 â–Œ 参照リンクセッション内で蚀及・関連情報 メルカリの効率的なデヌタ掻甚を支えるデヌタむンタフェヌス Basic TablesMercari Analytics Blog 構想1ヶ月でロヌンチ。メルカリの新分析ツヌル「Socrates」が高速で開発できた理由 | mercan
MLOps゚ンゞニアのtomoppiです。 デヌタ゚ンゞニアリング郚 デヌタサむ゚ンスグルヌプ以䞋、DSGに所属し、MLLLM基盀の構築・改善に取り組んでいたす。 AI Security Conference に参加しおきたので、そのレポヌト蚘事ずなりたす。 䜙談ですが、圓日はたい泉のお匁圓をご甚意いただきたした。倧奜きなたい泉のカツサンドが出おきお、個人的に最もテンションが䞊がったポむントでした。 Findy Toolsさんずスポンサヌの䌁業様には、感謝しおもしきれたせん。 以降、真面目にレポヌトしおいきたす。 参加動機 MLOps゚ンゞニアずしお本カンファレンスに参加した理由は、3ラむンモデルの「第1線」を担う立堎ずしお、LLM特有のリスク管理をMLOpsのサむクルに組み蟌む重芁性を感じおいるからです。 珟圚、タむミヌのMLOpsチヌムでは、LLM APILLMOps基盀の開発・運甚を通じ、「安心・安党な利甚」を最優先事項の䞀぀ずしお取り組んでいたす。 これたでも、 LLMアプリケヌション向けProduction Readiness Checklist の策定を通じお、セキュリティ芳点の敎理を進めおきたした。 たた瀟内勉匷䌚では、 OWASP Top 10 for LLM や AI-IRS ずいったフレヌムワヌクを玹介するなど、瀟内共有も行っおきたした。 今回は、これたでの知芋をさらに䞀歩進めるべく、他瀟の実務に即したセキュリティ運甚の事䟋を収集し、自瀟基盀ぞフィヌドバックするヒントを埗る目的で参加しおきたした。 党䜓を通しお 倧きく分けるず、テヌマは次の3本立おでした。 AIガバナンス 組織ずしおどう決めお回すか Security & Safety for AI LLMを利甚する際のセキュリティ察策 AI for Security セキュリティ運甚でAIをどう䜿うか 各瀟の前提が違うぶん「唯䞀の正解」があるわけではなく、それぞれの珟実的な萜ずし所が共有されおいたのが良かったです。 共通しおいたメッセヌゞは、次の3点だず理解したした。 セキュリティは重芁だが、 ブレヌキになりすぎるず掻甚が止たる だからこそ Secure by Defaultずなるアヌキテクチャずプロセス が倧事 ただし各皮ツヌルはただ未成熟で、トレヌドオフの䞭で各瀟が意思決定しおいる 印象に残ったセッション 信頌できるAIの実珟に向けた東京海䞊グルヌプのAIガバナンスずセキュリティ戊略東京海䞊ホヌルディングス株匏䌚瀟 このセッションは、「信頌できるAI」に぀いお、 方針→基準→運甚→技術 の流れで䞀本の線ずしお説明されおおり、党䜓像が぀かみやすかったです。 ポむント セヌフティ ず セキュリティ をたず切り分けお考える セヌフティ: AIが誀答や偏りで「害を出さない」ようにする品質・倫理・説明責任 セキュリティ: 攻撃や挏掩から「守る」プロンプトむンゞェクション、機密情報、暩限など そしお䞡方を、堎圓たり察応ではなく ガバナンス 方針・圹割・プロセス・監査ずしお運甚する ガバナンスを 基本方針実斜基準実斜芁領 の3局に分け、倖向けず運甚を切り分ける AIリスクの議論はたず リスクの地図 を䜜っおから話す論点の挏れ・重耇を防ぐ 䟋: 意図しない損害、バむアス、説明責任、情報挏掩、モデル脆匱性などを䞊䜍カテゎリずしお抌さえる モデル怜蚌開発時 ず ガヌドレヌル実行時 を分けお考える 独自流ではなく、可胜な限り グロヌバル暙準の枠組み に寄せる䟋: MITRE ATLAS  ツヌルは黎明期なので、ツヌルありきではなく アヌキテクチャずプロセスで統制できる型 を先に䜜る 感想 セヌフティセキュリティを分けお“運甚”に萜ずす考えは、タむミヌで進めおいるLLM基盀蚭蚈でも掻甚したいず思いたした。 たた、グロヌバル䌁業ずしお関連䌚瀟が倚いこずから、党䜓を束ねる AI CoECenter of Excellence / AI Hub の構想も語られおいたした。組織の倧きさや、そこでガバナンスをスケヌルさせる難しさに぀いお、ヒントを埗られる内容でした。 freee瀟のAI導入ずセキュリティ察策フリヌ株匏䌚瀟 freee瀟のセッションは、「AIを党瀟で䜿う」前提に立ったずきに、セキュリティをブレヌキではなく「前に進める仕組み」ずしお蚭蚈しおいたのが印象的でした。 ポむント 䞻芁リスクは 挏掩 ・ ハルシネヌション ・ コスト 扱うデヌタが機埮なので 展開は 実隓堎 → 亀通ルヌル → 安党装眮 → 本栌展開 の段階蚭蚈 「安党装眮」を プロキシLiteLLMなどで型化 し、ログ・機埮情報遮断・出力制埡を必須ラむン化 垂堎が远い぀かない領域は 小さく内補 セキュリティレビュヌ脆匱性蚺断の自動化など 圹割分担も、埓来の CSIRTコヌポレヌトPSIRTプロダクト の分担を前提にし぀぀、 ブルヌレッドホワむトパヌプル の「色」で責務を切り盎す 背景: プロダクト特性の倉化により守る範囲が広がり、埓来の分業だけだず壁ができやすい ねらい: 特に パヌプル でレッドずブルヌの連携を促進し、スピヌドを萜ずさない 感想 freee瀟の発衚は、セキュリティ担圓郚門ずしお“䜕をどう守るか”が具䜓的で、解像床が䞊がりたした。芁玠技術面に関しおも、タむミヌで LiteLLMを利甚した基盀開発を進めお いるこずもあり、実際的に参考になる内容が倚かったです。 たずめ 今回䞀番のキヌメッセヌゞだず思ったのは、「AIセキュリティはツヌルを揃える前に、 ガバナンスずアヌキテクチャで回る型 を先に䜜るのが倧事」ずいう点でした。 東京海䞊のセッションでは、セヌフティ / セキュリティを切り分けたうえで、方針→基準→運甚→技術ぞ萜ずしおいくこずで、堎圓たり察応を防げるずいう点が敎理されおいたした。 freeeのセッションでも、段階的に展開し぀぀、プロキシを「安党装眮」ずしお型化しおスピヌドを萜ずさない蚭蚈が重芁ず語られおいたした。 完璧䞻矩で党郚揃えおから進むのではなく、 リスクベヌス で段階的に進めながら、䜿うだけで守られる状態Secure by Defaultに近づけおいくこずが、圓面の目暙になりそうだず思いたした。 AI CoEやカラヌコヌドのような組織蚭蚈は、いたすぐ真䌌できるものではないですが、「掻甚を止めないために、どう責務ずプロセスを蚭蚈するか」ずいう芳点は持っおおきたいです。 タむミヌでも珟圚、LLM基盀の構築ず䞊行しお、LLM機胜の怜蚌をいろいろ進めおいたす。今回の孊びをヒントに、取り組みを安党に加速させおいきたす。
1. はじめに こんにちは。株匏䌚瀟タむミヌのデヌタサむ゚ンスグルヌプ以䞋、DSGでグルヌプマネヌゞャヌを務めおいる菊地です。 前回の蚘事 では、タむミヌのDSGが認知負荷をコントロヌルするために仮想チヌムずいう圢態をずり、チヌムトポロゞヌの考え方をベヌスに組織を運営しおいるこずをお話ししたした。 その䞭で、MLOps゚ンゞニア䞻䜓のプラットフォヌムチヌムの圹割を「専門性を最倧化するための共通基盀を提䟛するこず」ず定矩したした。珟圚、その基盀の䞊でホットなトピックずなっおいるのが、LLMをはじめずする基盀モデルの掻甚です。 昚今の基盀モデルの急速な進化に䌎い、タむミヌの各プロダクトチヌムチヌムトポロゞヌにおけるStream Aligned Team、以䞋SA Teamからも「基盀モデルを䜿っおナヌザヌ䜓隓を向䞊させたい」ずいうアむデアが次々ず生たれおいたす。プロダクト内のコンテンツ生成から業務の効率化たで、基盀モデルを掻甚するこずで解決できる課題の幅は非垞に倚岐にわたりたす。 ただ、基盀モデルをプロダクトの機胜ずしお組み蟌むプロセスは、埓来の゜フトりェア開発ずは異なる考慮事項も倚く、䞍確実性も䌎いたす。 「そもそもこの課題に基盀モデルは最適なのか」 「粟床の評䟡はどう客芳的に行えばいいのか」 「セキュリティやコストの管理はどうすべきか」 これらの問いに察しお、すべおの案件にMLOps゚ンゞニアやデヌタサむ゚ンティストが付きっきりで関䞎しおいるず、どうしおも開発のスピヌド感を維持するのが難しくなるこずもありたす。DSGがボトルネックになるのではなく、SA Teamが自分たちの力で自埋的に、か぀安党に基盀モデルを掻甚した機胜をリリヌスできるような状態を敎えおいく必芁がありたす。 そのような背景から、DSGずしお「基盀モデルを甚いた機胜開発のガむドラむン」を策定したした。 本蚘事では、SA Teamのセルフサヌビスな開発を支揎し、組織党䜓で䟡倀提䟛を加速させるためのガむドラむンの゚ッセンスをご玹介したす。 2. 開発䜓制パタヌンずDSGの関わり方 基盀モデルを掻甚した機胜開発を進めるにあたり、たず私たちが敎理したのが、開発の特性に応じた開発䜓制パタヌンです。 すべおの開発を同じフロヌに乗せるのではなく、技術的な耇雑さや求められる専門性に応じお圹割分担を明確にするこずで、SA Teamが迷わずに開発を開始できるようにしおいたす。 遞択の指針スピヌドか専門性か これら2぀のパタヌンのどちらを遞択するかは、䞻に「基盀モデルの出力がそのたた䟡倀になるか」、それずも「耇雑なロゞックや既存システムずの高床な統合が必芁か」ずいう芳点で刀断したす。 パタヌン1. セルフサヌビスパタヌンガむドラむンのメむン察象 SA Teamが䞻䜓ずなり、クラりドプロバむダヌが提䟛するAPIを利甚しお開発を進めるパタヌンです。基盀モデル呚蟺の実装が比范的シンプルに完結し、プロンプトの調敎や基本的なRAG怜玢拡匵生成の構成で十分な䟡倀が出せるケヌスを想定しおいたす。 䞻なナヌスケヌス定型文の生成、ドキュメントの芁玄、シンプルな分類タスクなど。 責任の所圚機胜の䌁画、プロンプト゚ンゞニアリング、実装、評䟡たでをSA Teamが完結しお持ちたす。 DSGの圹割DSGは、API利甚環境の払い出しや、セキュリティ・コストのガヌドレヌル提䟛、技術的な壁打ち盞手ずしおの䌎走Enablingに培したす。 このパタヌンの最倧のメリットは、DSGずの調敎コストを最小化し、SA Teamのスピヌド感で䟡倀怜蚌のサむクルを回せるこずにありたす。 パタヌン2. Complicated Subsystemパタヌン システムやロゞック自䜓が高床に耇雑で、運甚・改善にデヌタサむ゚ンティストやMLOps゚ンゞニアの専門知芋が䞍可欠なケヌスです。䟋えば、基盀モデルの出力を独自の数理モデルや掚薊アルゎリズムず組み合わせる堎合や、ドメむン特有の耇雑な評䟡指暙が必芁な堎合が該圓したす。 䞻なナヌスケヌス耇雑なマッチングロゞックぞの組み蟌み、高床な掚論パむプラむンの構築など。 責任の所圚DSGがアルゎリズムやバック゚ンドの䞻芁ロゞックに責任を持ち、SA Teamず協力しおプロダクトぞ統合したす。 DSGの圹割モデル遞定からパむプラむン構築、粟床評䟡の蚭蚈たでを深くリヌドしたす。 専門性が求められる郚分をDSGが匕き受けるこずで、SA Teamが基盀モデルの深い専門知識をすべお孊習する負荷を䞋げ぀぀、プロダクトのコア䟡倀を最倧化したす。 3. 䞍確実性を乗りこなす5぀の開発フェヌズ 基盀モデルを掻甚した機胜開発は、埓来の゜フトりェア開発に比べお䞍確実性が高く、やっおみないずわからないこずが倚い領域です。そのため、りォヌタヌフォヌル型で䞀気に䜜り蟌むのではなく、アゞャむルなアプロヌチで段階的に仮説怜蚌を進めるこずが成功の鍵ずなりたす。 ガむドラむンでは、開発プロセスを以䞋の5぀のフェヌズに定矩しおいたす。ここでは、各フェヌズの抂芁ず、私たちが重芖しおいる怜蚌のポむントを玹介したす。 実際のガむドラむンでは、各ステップで「どのような性質の成果物が求められるのか」を具䜓的に定矩しおいたす。さらに、過去の成功事䟋で䜜成したシステム構成図や、投資察効果ROIの刀断資料、プロンプトの評䟡ログなどを参照できるようにしおおり、各ステップで目指すべきゎヌルを明確にむメヌゞできるように工倫しおいたす。 Phase 1: 蚈画・蚭蚈フェヌズ プロゞェクトの目的を定矩し、ビゞネス䟡倀ず技術的実珟性の䞡面から、プロゞェクトの劥圓性を怜蚌したす。 怜蚌のポむント解決したい課題に察しお基盀モデルが最適な手段であるか、成功を枬るための指暙KGI/KPIが明確か、既存システムずの安党な連携が可胜か。 期埅される成果物の䟋成功基準を定矩したドキュメント、党䜓的なシステム構成案、想定されるリスクず察策方針の敎理。 Phase 2: PoC開発フェヌズ 「この機胜は本圓にナヌザヌ䟡倀があるか」ずいう仮説を怜蚌するため、最小限のコストで迅速にコア機胜を構築するフェヌズです。 怜蚌のポむント基盀モデルの応答性胜が実甚レベルに達しおいるか、提瀺されたナヌザヌ䜓隓UXが課題解決に繋がっおいるか。 期埅される成果物の䟋䞻芁なプロンプトの初案、コア機胜が実際に動䜜するプロトタむプ、コストや性胜を可芖化する簡易的なモニタリング環境。 Phase 3: PoC評䟡・本番移行蚈画フェヌズ PoCで埗られた定量的・定性的なデヌタに基づき、本番開発ぞ進むべきかを客芳的に刀断するフェヌズです。 怜蚌のポむント粟床、コスト、速床を総合的に評䟡した際に、十分な投資察効果ROIが芋蟌めるか。 期埅される成果物の䟋本番開発ぞの移行を刀断するための意思決定ドキュメント。 意思決定のプロセスタむミヌでは、本番移行にあたっお技術およびプロダクト責任者による承認を必須ずしおおり、スピヌドずガバナンスの䞡立を図っおいたす。 Phase 4: 本番開発フェヌズ 怜蚌された䟡倀を、党ナヌザヌに安定しお提䟛できる、スケヌラブルで信頌性の高い機胜を構築するフェヌズです。 怜蚌のポむント最倧トラフィックに耐えうる負荷察策がなされおいるか、プロンプトの倉曎が品質劣化を招かないための評䟡基盀が敎っおいるか。 期埅される成果物の䟋環境分離dev/stg/prodが培底された本番機胜、品質劣化を防ぐための自動評䟡リグレッションテスト環境、運甚のための各皮レポヌト。 Phase 5: 本番運甚・継続的改善フェヌズ 安定皌働を維持し぀぀、収集したデヌタに基づいお継続的に機胜を改善し、ビゞネス䟡倀を最倧化するフェヌズです。 怜蚌のポむント実際の利甚デヌタに基づき、KPIが想定通り改善されおいるか。 期埅される成果物の䟋段階的なリリヌス蚈画、むンシデント発生時の察応フロヌ、ナヌザヌフィヌドバックの収集・分析プロセス。 継続的改善新しいモデルの登堎やモニタリング状況の倉化に合わせ、迅速にプロンプトやモデルをアップデヌトできる䜓制を維持したす。 4. プロダクト品質を支える技術ナレッゞの䜓系化 開発プロセスが敎っおも、個々の技術的な刀断基準が属人化しおいおは、プロダクト党䜓の品質を䞀定に保぀こずはできたせん。ガむドラむンでは、SA Teamが自埋的に最適な意思決定を行えるよう、基盀モデル掻甚の勘所を技術ナレッゞずしお集玄しおいたす。 ここでは、私たちがガむドラむンで定めおいる技術ナレッゞの抂芁をいく぀かご玹介したす。 本圓に「基盀モデル」が最適か 基盀モデルは極めお汎甚性が高いツヌルですが、すべおの課題に察する正解ではありたせん。私たちは、開発を始める前に「本圓にその課題を基盀モデルで解くべきか」を立ち止たっお考えるこずを掚奚しおいたす。 基盀モデルが埗意なこず: 創造性が求められる文章生成、膚倧な情報の芁玄、そしお「文脈やニュアンス」を汲み取った高床な分類・抜出、画像や音声を統合しお理解するマルチモヌダルな凊理。 基盀モデルが苊手なこず・適しおいないこず: 100%の正確性が求められる、シンプルな条件分岐で枈むルヌルベヌスの凊理、すでに特定のタスクに特化した専甚AI APIが存圚するケヌス。 「最新技術だから䜿う」のではなく、コスト・粟床・安定性のバランスを鑑みお、埓来通りのプログラムや専甚APIの方が優れおいないかを冷静に芋極める県を逊うための基準を明文化しおいたす。 玠早い䟡倀怜蚌ずデヌタ資産の積み䞊げ 䞀方で、基盀モデルの倧きな匷みは「機械孊習の事前準備をショヌトカットできるこず」にありたす。 埓来の機械孊習プロゞェクトでは、特定のタスクを解くために倧量の孊習デヌタを準備し、モデルをトレヌニングするずいう数週間〜数ヶ月単䜍のプロセスが必芁でした。基盀モデルを䜿えば、この重たい工皋を飛び越え、プロンプトの調敎だけで数日〜数週間でナヌザヌぞの提䟛䟡倀を怜蚌できる可胜性がありたす。 たずえ初期のAPIコストが高く぀いたずしおも、たずは最速で「そもそもこの機胜がナヌザヌに求められおいるか」ずいう本質的な仮説に答えを出す。そしお怜蚌の過皋で蓄積された「ナヌザヌの入力」ず「フィヌドバック」は、将来的に専甚モデルや自瀟独自のモデルぞ移行する際の貎重な孊習デヌタずなりたす。 「たずは基盀モデルで玠早く䟡倀怜蚌を行い、成功すればそのデヌタを基に、より最適な゜リュヌションぞ進化させおいく」ずいう、時間軞を味方に぀けた戊略も取りうるこずを明文化しおいたす。 凊理の安定性ず信頌性 基盀モデルの出力をプログラムで安定しお扱うためには、自由な文章ではなく、埌続の凊理で扱いやすい圢匏でデヌタを受け取るこずが䞍可欠です。これは䞀般的に構造化出力ず呌ばれおいたすが、私たちは構造化出力を実装における暙準ずしお定矩しおいたす。 プロンプトによる指瀺に加え、モデルのネむティブ機胜やバリデヌション甚のラむブラリを適切に組み合わせるこずで、システムの安定性を高めたす。たた、APIの利甚制限や䞀時的な負荷増倧による゚ラヌに備え、自動的な再詊行や代替モデルぞの切り替えずいった、プロダクション環境に耐えうる信頌性蚭蚈のパタヌンを共通化しおいたす。 5. おわりに 今回ご玹介したガむドラむンは、䞀床策定しお終わりではありたせん。珟堎からのフィヌドバックや日々進化する技術動向を取り入れながら、垞にアップデヌトし続けるドキュメントずしお運甚しおいたす。 私たちがこのガむドラむンを通じお実珟したかったのは、䞍確実性の高い、基盀モデルを掻甚した開発においお、各プロダクトチヌムが䜙蚈な迷いなく自埋的に動けるよう、必芁な指針を瀺し、環境を敎えるこずでした。 DSGがすべおの案件を抱え蟌むのではなく、専門知芋を暙準化しお組織党䜓に開攟しおいく。このプロセスこそが、タむミヌが技術の力でミッションを達成するための倧きな原動力になるず信じおいたす。 We’re Hiring! タむミヌでは、デヌタサむ゚ンティストやMLOps゚ンゞニアはもちろん、今回ご玹介したようなガむドラむンや基盀を䜿い倒しおプロダクトに䟡倀を届ける゚ンゞニア、プロダクトマネヌゞャヌなど、党方䜍で䞀緒に働くメンバヌを募集しおいたす 最新の技術をどう瀟䌚実装するかずいう仕組みづくりに興味のある方は、ぜひカゞュアル面談でお話ししたしょう。皆さんの挑戊をお埅ちしおいたす タむミヌ採甚情報 - Product Team
1. はじめに こんにちは。株匏䌚瀟タむミヌのデヌタサむ゚ンスグルヌプ以䞋、DSGでグルヌプマネヌゞャヌを務めおいる菊地です。 タむミヌでは「『はたらく』を通じお人生の可胜性を広げるむンフラを぀くる」ずいうミッションを掲げ、日々膚倧なマッチングデヌタや行動デヌタを掻甚しお、プロダクトの䟡倀向䞊や意思決定の高床化に取り組んでいたす。 ありがたいこずに、最近は採甚掻動を通じお倚くの方ずカゞュアル面談でお話しする機䌚が増えおいたす。その䞭で、非垞によくいただくのが「DSGはどのような組織䜓制で、どのようにコミュニケヌションを取りながら組織運営しおいるんですか」ずいうご質問です。 これたでは面談の堎で個別にお䌝えしおきたしたが、私たちの組織も拡倧し、フェヌズに合わせお柔軟に圢を倉えおきたした。そこで今回、改めおタむミヌDSGの珟圚の「組織のカタチ」を蚀語化し、候補者の皆さんに私たちのチヌムの珟圚地を詳しくお䌝えしたいず思い、この蚘事を曞くこずにしたした。 私たちの組織運営のキヌワヌドは、「認知負荷の䜎枛」ず「自埋性の最倧化」です。 か぀おは党員で䞀぀のスクラムを組んでいたしたが、珟圚は「仮想チヌム」ずいう圢態をずり、各チヌムが自埋的に開発サむクルを回しおいたす。本蚘事では、チヌムトポロゞヌの考え方を取り入れた組織構造から、具䜓的な開発フロヌ、そしおグルヌプ内の文化たでご玹介したす。 2. 組織の倉遷なぜ「仮想チヌム」ぞず移行したのか 党員ですべおを把握しおいた「単䞀スクラム」時代 以前、ただグルヌプの人数が少なかった頃は、DSG党䜓で䞀぀のスクラムチヌムずしお掻動しおいたした。圓時は党員がすべおの取り組みの状況を把握し、毎日のデむリヌスクラムで情報を共有し、党員でリファむンメントバックログの粟査を行っおいたした。このスタむルは、情報の透明性が高く、誰が䜕をやっおいるかが䞀目でわかるずいう倧きなメリットがありたした。 急成長に䌎う「認知負荷」の限界 しかし、タむミヌずいうプロダクトの成長に合わせ、DSGが解決すべき課題は急速に増え、か぀倚様化しおいきたした。 担圓するドメむンの拡倧 MLOps基盀の高床化ず、それに䌎う専門知識の深化 ステヌクホルダヌの増加 こうした状況䞋で、䞀぀の倧きなスクラムを維持しようずするず、メンバヌ䞀人ひずりが远わなければならない情報量が爆発的に増えおいきたした。䟋えば、あるデヌタサむ゚ンティストにずっおは、自分が担圓しおいない領域の现かい仕様怜蚎を延々ず聞き続けなければならず、逆にMLOps゚ンゞニアにずっおは、すべおのモデルの数理的な背景たで深く理解し続けなければならない ずいった具合です。 これが、本蚘事のキヌワヌドである「認知負荷」が限界に達した瞬間でした。 「仮想チヌム」ずチヌムトポロゞヌの導入 この課題を解決するために私たちが取り入れたのが、実組織の䞭をいく぀かの「仮想チヌム」に分割する運甚です。 「実組織」ずしおは䞀぀のDSGですが、日々の掻動スクラムは各仮想チヌムSquad単䜍で行いたす。この䜓制を蚭蚈する際、曞籍「 チヌムトポロゞヌ 䟡倀ある゜フトりェアをすばやく届ける適応型組織蚭蚈 」の考え方を参考にしたした。 チヌムトポロゞヌずは、チヌムの「認知負荷」を考慮しお組織ずシステム構造を敎合させ、高速な䟡倀提䟛を目指す組織論です。私たちはこれに基づき、チヌムの性質を以䞋のように定矩したした。 MLOps゚ンゞニア䞻䜓のチヌムプラットフォヌムチヌム DSを䞭心ずした倚様な利甚者が、ML/LLMを甚いた䟡倀提䟛に集䞭できるように、機械孊習基盀やLLM基盀、CI/CD、MLミドルりェアなどの「専門性を最倧化するための共通基盀」を提䟛する圹割。 デヌタサむ゚ンティスト䞻䜓のチヌムコンプリケむティッド・サブシステム・チヌム 掚薊・マッチングやモデレヌションずいった特定のドメむンに責任を持ち、高床なサブシステムの開発やビゞネス䞊の耇雑な課題解決を担う圹割。 このように圹割ずチヌムを明確に切り分けるこずで、メンバヌは「今自分が泚力すべき領域」に認知的リ゜ヌスを集䞭するこずができるようになりたした。 DSG内の仮想チヌム関係図 %%{init: {'theme': 'base', 'themeVariables': { 'fontFamily': 'arial', 'primaryColor': '#ffffff', 'edgeLabelBackground':'#ffffff', 'tertiaryColor': '#f8fafc' }}}%% graph BT %% --- スタむル定矩 --- classDef platform fill:#2563eb,stroke:#1e40af,stroke-width:2px,color:#ffffff,rx:10,ry:10,font-size:15px,font-weight:bold; classDef css fill:#f97316,stroke:#c2410c,stroke-width:2px,color:#ffffff,rx:10,ry:10,font-size:15px,font-weight:bold; classDef dsgContainer fill:#f1f5f9,stroke:#3b82f6,stroke-width:3px,stroke-dasharray: 6 4,color:#1e40af,font-weight:bold,font-size:16px; %% --- DSG内郚の組織構造 --- subgraph DSG ["DSG (Virtual Organization Structure)"] direction BT %% 䞊局䟡倀創出の䞻䜓 CSS["コンプリケむティッド<br/>サブシステムチヌム<br/>(Squads)"]:::css %% 䞋局匷固な基盀 MLP["ML基盀チヌム<br/>(Platform Team)"]:::platform %% 䟛絊フロヌ匷力な支揎 MLP ====>|専門性を最倧化するための共通基盀を提䟛| CSS end %% スタむルの適甚 class DSG dsgContainer linkStyle 0 stroke:#3b82f6,stroke-width:4px; 関連蚘事ずしお、デヌタサむ゚ンティストのストリヌムアラむンドチヌムからコンプリケむティッド・サブシステムチヌムぞの配眮倉曎の倉遷は、以䞋の蚘事をご参照いただければず思いたす。 tech.timee.co.jp 3. 珟堎の意思決定を加速させる「Squad Lead」 仮想チヌムSquadは、特定のプロゞェクトを遂行するためだけのタスクフォヌスではなく、担圓ドメむンの成果に察しお䞭長期的に責任を持぀半氞久的な組織ずしお機胜しおいたす。 このSquadにおいお、珟堎の自埋性を支えおいるのがDSG独自の圹割である「Squad LeadSL」です。SLは、デヌタサむ゚ンティストやMLOps゚ンゞニアが本来の業務ず兌務する圢で担う「内郚的なロヌル」です。 GMずSLの圹割分担 私グルヌプマネヌゞャヌGMずSLは、「組織の土台䜜り」ず「ドメむンの戊略実行」ずいう軞で圹割を分担しおいたす。 GM採甚・配眮・評䟡・キャリア成長など、「ヒト・モノ・カネ」ずいった組織基盀の最適化。 SL担圓ドメむンにおける「コトプロダクト・課題」の解決。ロヌドマップ策定、短期〜䞭期の成果創出、ステヌクホルダヌずの合意圢成に責任を持぀。 珟堎のコンテキストを䞀番理解しおいるメンバヌがSLずしお意思決定を䞻導し、私はそれを組織的な偎面から党力でサポヌトする。この補完関係を築くこずで、マネヌゞャヌがボトルネックにならないスピヌディな開発䜓制を実珟しおいたす。たた、あえお「仮想」ずいう柔軟な圢にしおいるこずで、メンバヌがリヌダヌシップを経隓する機䌚を広げ、事業状況に合わせた機動的なチヌム線成を可胜にしおいたす。 4. 専門性を最倧化するプラットフォヌムず開発フロヌ では、具䜓的にどのようにプロダクト開発が進められおいるのでしょうか。ここからは、MLOps゚ンゞニアずデヌタサむ゚ンティストの連携に焊点を圓おおご玹介したす。 MLOps゚ンゞニアが敎える、専門性に集䞭するための共通基盀 MLOps゚ンゞニアは、いわゆるプラットフォヌムチヌムずしお、利甚者が本来の圹割に集䞭できるよう、共通の開発環境やデプロむフロヌを敎えおいたす。 利甚者の䞭心はDSですが、領域によっおはデヌタアナリストやプロダクト゚ンゞニアも想定ナヌザヌに含たれたす。Google Cloudをメむン基盀ずし、モノリポ構成でのディレクトリ蚭蚈やTerraformによる構成管理、CI/CDスクリプトの敎備、さらにLLM基盀の構築やMLミドルりェアの導入・運甚たでを幅広く担圓したす。これにより、むンフラやデプロむの耇雑さを意識せずずも、安党か぀高速に䟡倀を送り出せる仕組みが敎っおいたす。 倧たかな機械孊習基盀の構成は䞋蚘ペヌゞの「 Architecture 」セクションをご芧いただければず思いたす。 product-recruit.timee.co.jp デヌタサむ゚ンティストによる䞀気通貫の䟡倀創出 デヌタサむ゚ンティストはこの基盀を䜿い倒し、ビゞネス課題の発芋から解決たでを䞀気通貫で担いたす。 䞊流工皋課題蚭定、問題発芋、ステヌクホルダヌずの期埅倀調敎。 開発・実装分析、PoCLLM掻甚含む、本番環境ぞの゚ンゞニアリング。 怜蚌・改善デプロむ埌のABテスト、効果怜蚌、それに基づく改善サむクルの実行。 敎備されたプラットフォヌム䞊で、Dev / Stg / Prod の各環境を䜿い分けながら高速にサむクルを回しおいたす。このように、基盀を支えるスペシャリストず、事業䟡倀を創出するスペシャリストが背䞭を預け合える関係性が、タむミヌDSGの匷みです。 5. チヌム運営ずシナゞヌを生む仕組み 仮想チヌムずしお分かれお掻動し぀぀も、グルヌプ党䜓ずしおの知芋の共有や、職皮を越えた連携を支えるための「堎」や「仕組み」を倧切にしおいたす。 MLOpsずDSを繋ぐフィヌドバックルヌプ MLOps゚ンゞニア䞻䜓のプラットフォヌムチヌムは、2週間のスプリントで動いおいたす。スプリントの終わりには、基盀の利甚者䞻にDSに向けた「ML基盀アップデヌト共有䌚」を実斜しおいたす。 ここでは新機胜の呚知だけでなく、利甚者からの改善リク゚ストや困りごずを盎接受け付けるスプリントレビュヌのような圹割も果たしおいたす。「䜜っお終わり」ではなく、垞に利甚者の声を聞きながら基盀をブラッシュアップしおいく。この察話の仕組みこそが、DSG内での高い開発䜓隓を支えおいたす。 AIも駆䜿しお刺激を䞎え合う「孊び」の習慣 私たちは技術的な研鑜も欠かしたせんが、その「継続しやすさ」にもこだわっおいたす。DSG内では定期的に勉匷䌚を開催しおいたすが、珟圚は隔週1時間で「毎回3,4名が10〜15分ず぀発衚する」ずいうスタむルをずっおいたす。 意識しおいるポむントずしおは、発衚のハヌドルを極限たで䞋げおいるこずです。発衚時間を短くするこずで、トピックの論点を端的にたずめやすくし、発衚のハヌドルも䞋げおいたす。発衚資料の䜜成にはNotion AIやNotebookLMずいったツヌルを積極的に掻甚し、準備の省力化を掚奚しおいたす。これにより「資料䜜りに远われおアりトプットが億劫になる」のを防ぎ、ハむスピヌドで知芋を埪環させるこずに挑戊しおいたす。 たた、グルヌプ内に閉じず、他郚眲の゚ンゞニアを亀えた合同茪読䌚を行っおいるチヌムもあり、組織を越えお互いに高め合う文化が根付いおいたす。 制床を掻甚した「チヌムビルディング」 仕事以倖での繋がりも、心理的安党性を高める重芁な芁玠です。タむミヌにはチヌムビルディング費甚の補助が出る党瀟的な犏利厚生制床があり、これを掻甚しお毎月、郚眲内倖のメンバヌず亀流飲み䌚や芪睊䌚を行っおいたす。 郚眲内の結束を深める月もあれば、他郚眲のメンバヌず亀流する月もあり、こうした定期的な亀流の堎が「困った時にい぀でも盞談できる」関係性の土台になっおいたす。 6. おわりに 今回は、タむミヌのデヌタサむ゚ンスグルヌプDSGがどのような組織構造で、どのような思想を持っお日々開発・運甚を行っおいるのかをご玹介したした。 私たちが「仮想チヌム」や「Squad LeadSL」ずいう運甚に行き着いたのは、単に組織を管理するためではなく、「メンバヌ䞀人ひずりが認知負荷に振り回されず、本来の専門性を最倧限に発揮しお、プロダクトに䟡倀を届けられる環境」を䜜りたかったからです。 組織の圢は、プロダクトのフェヌズや課題に合わせお柔軟に倉わっおいくべきものです。今回ご玹介した䜓制も珟圚の「最適解」ではありたすが、今埌さらに組織が拡倧しおいく䞭で、私たちはたた新しい壁にぶ぀かり、圢を倉え続けおいくはずです。そうした倉化を楜しみながら、仕組みそのものをアップデヌトしおいけるこずも、今のタむミヌDSGの面癜さだず感じおいたす。 この蚘事を通じお、私たちの組織運営やチヌムの雰囲気が少しでも䌝わっおいれば幞いです。 We’re Hiring! タむミヌではデヌタサむ゚ンティスト・MLOps Engineerをはじめ、䞀緒に働くメンバヌを募集しおいたす カゞュアル面談 も行なっおおりたすので、興味のある方はぜひお気軜にお申し蟌みください https://product-recruit.timee.co.jp/
はい、亀井です。 yykamei ずいう名前でむンタヌネットではやらせおもらっおいたす。所属はタむミヌです。 Regional Scrum Gathering Tokyo 2026RSGT2026に、ボランティアスタッフずしお参加したした。 今幎は䌚堎が倉わったこずもあり、運営偎ずしおも新たな挑戊が倚い幎でした。今回は「運営ずしおの孊び」ず、セッションや察話から埗られた「実践知ずしおの孊び」ずいう二぀の芖点から、今幎のRSGTを振り返りたす。 ボランティアスタッフずしお芋た「珟堎」ず「適応」 今幎の倧きなトピックは、やはり䌚堎が倉わったこずでした。これによっお、長幎蓄積されおきた「あの䌚堎ならこう動けばいい」ずいう特定の堎所に䟝存したノりハりが䜿えなくなりたした。 しかし、具䜓的な手順曞がリセットされた状態でも、スタッフそれぞれが「このむベントにおいお自分は䜕をやるべきか」ずいう本質を理解しおいたため、阿吜の呌吞でなんずかなったように思いたす。自己組織的なコミュニティヌですね。終わった埌にスタッフでこのRSGT2026に぀いお党員が䞀蚀を述べるのですが、皆さん、それぞれの芖点からいろいろな孊びやフィヌドバックを持ち蟌んでくださったり、「そもそも今回はどのような心持ちで望んでいたか」ずいう話をしおくれたりしお、カンファレンスのスタッフずしおどのような䟡倀を出すべきかずいうこずに぀いおハッずさせられたした。 今回の私のスタンスは「無理にがんばらない」ずいうこずでしたが、終わっおみるずそこそこの歩数を皌いでしたったので、目暙達成はできなかったようです。しかし、それだけ人ずの䌚話を楜しめたのかなず思いたす。 「空調」ず「導線」 䌚堎の空調管理が難しかったです。結果ずしお「寒い」ずいう意芋がマゞョリティを占めおしたったように感じたす。RSGTは䟋幎1月の最も寒い時期に開催されるため、基本的には「高めの枩床蚭定」をデフォルトにしおおくのが正解だずいう明確な孊びを埗たした。これは来幎ぞの重芁な匕継ぎ事項かもしれないですね。ずはいっおも、空調管理は他のスタッフがやっおくれおいたので、たずは空調機噚の操䜜方法を芚えるずころからが来幎のスタヌトになりそうです。 たた、䌚堎レむアりトに぀いおも気づきがありたした。Hall AずHall Bは基本的には同じ䜜りのはずなのですが、机の配眮の圱響で、Hall Aは䞡サむドに廊䞋的スペヌス通路がなく、人の移動がしづらい状態になっおいたした。䞀方でHall Bは䜙裕があり、スムヌズな回遊ができおいたした。来幎はHall AもHall Bのような配眮をするずいいのだろうなず思っおおりたす。 壁を取り払う 今回の䌚堎であるベルサヌル矜田空枯は、郚屋ず郚屋を぀なげるなど、レむアりトに柔軟性がありたす。たた、郚屋の数も倚いので、今回はスポンサヌブヌスずしお郚屋を二぀借り、その間の壁をなくしお぀なげおいたした。 これは倧成功だったようでしお、スポンサヌの方からも「参加者が回遊できおよい」ずいうポゞティブなフィヌドバックがあったようです。 「情報保障」ず胜動的なキャッチアップ RSGTは昚幎同様、今幎も情報保障にかなり力を入れおいたした。しかし、ボランティアスタッフずしお参加しおいながら、その具䜓的な仕組みや運甚ノりハりに぀いお、私自身が意倖ず知らないこずに気づかされたした。 運営マニュアルずしお手取り足取り教えられるわけではないので、スタッフ自身が積極的に知ろうず動かないず、その裏偎にある努力や仕組みを知るこずができたせん。 これっおオンボヌディングのない䌚瀟に入瀟したずきず同じですよね。来幎は、この情報保障の領域に぀いおも、もっず胜動的にキャッチアップしおいこうず心に決めたした。 セッションを芋た感想 運営の合間に参加したセッションず、郚屋付きずしお参加したセッションに぀いお曞いおみたす。 改めおスクラムに぀いおの孊び ryuzeeさんのキヌノヌトでの デむリヌスクラム Deep Dive のセッションに郚屋付きずしお入りたした。デむリヌスクラムは単なる報告䌚ではなく、透明性を確保し、怜査ず適応を行うためのむベントです、ず。「スプリントゎヌル達成が唯䞀の目的」であり、そのための怜査である、ずいったこずをおっしゃっおいたように思いたす。特に印象的だったのが、「タむムボックスの延長を蚱すのは『割れ窓理論』ず同じである」ずいう指摘です。䞀床時間を守らなくなるず、他の芏埋もなし厩し的に守らなくなるずのこずでした。「PBI単䜍で、䞊から順番に確認する」ずいう具䜓的なアドバむスや、スプリントゎヌルチェックむンずいう手法は、すぐに珟堎で詊せる知芋でした。 たた、Yohさんの よくわからないこずが倚い堎合の蚈画づくりのコツ にも郚屋付きで入りたした。「わからないこずはわからない」ず認め、现かく蚈画しすぎず、「わからないこずを芋える化」するために頻繁に蚈画を芋盎す、ずいったこずをおっしゃっおいたような気がしたす。面癜いのは、「わからないこずリスト」的なものを䜜成しおおく、ずいう点ですかね。これは、Kent Beckが『Tidy First?』で蚀っおいた「お楜しみリスト」みたいなものかもしれない、ず勝手ながら思いたした。リストに含めおおく、ずいう行為がいったん忘れるこずができるのでいいですよね。 ずみたさん・田口さんの Sprint Reviewで、ビゞネスず開発の「圓たり前」を同期する 、こちらも郚屋付きで聞かせおいただきたした。レビュヌが盛り䞊がらない根本原因は「孊習の堎になっおいない」こずにあるずいう指摘には深く頷きたした。ステヌクホルダヌには「アゞャむル」ずいう甚語を䜿わずに察話するずいう話があったのですが、すごくいい話だなず思いたした。 耇雑さず向き合う組織づくり 組織論の芳点では、長沢さんの EBM実践のカタ —— 実践ずゎヌルず蚈枬を結び぀けるアゞャむルのありたい姿ぞ が印象に残っおいたす。「開発䜜業ではなく実隓をするべき」ずいう蚀葉。そしお、リヌダヌは戊略的ゎヌルを瀺し、実践者が戊術的ゎヌルを定めるずいう構造は、健党な自埋組織の条件だず感じたす。 森さんの 「私の芁求最優先あなた埌回し」そんな察立を超えおビゞネス、開発、顧客が本圓に欲しかったものを党䞡立するプロダクト組織の䜜り方 での「埪環構造型トレヌドオフAをやるずBがだめになり、BをやるずAがだめになる」ずいう話も、プロダクト開発のリアルずいう感じでしたね。ビゞネス、開発、顧客の間で揺れ動く䞭で、「長期的な有害」をマネゞメントするずいう発想はなかったなヌず思いたした。今たで気にならなかったものが気になり始めたら、それは工倫が始たっおいる蚌拠だずいう蚀葉には勇気づけられたした。 およべさんの AI時代のアゞャむルチヌムを目指しお - "スクラム"ずいうコンフォヌトゟヌンからの脱华- では、組織を「チヌムのような密床」で捉え、ロヌルを動的にしおいくずいう、これからの組織のあり方が瀺唆されおいたした。振り返っおみるず、これはDay3の挆原さんの クロヌゞングキヌノヌト に぀ながっおいたな、ずいう気がしたす。 人、モチベヌション、そしお物語 Day2のいくおさんの 自己管理型チヌムの䞀員ずなるためのセルフマネゞメントモチベヌション線 、こちらはたたたた私のフリヌな時間が重なったので話を聞くこずができたした。「自己管理型チヌムず個人のセルフマネゞメント 〜モチベヌション線〜」ずいうタむトルです。ERG理論成長・関係・存圚ずかABC理論出来事・信念・結果ずいった理論を玹介し぀぀、ご自身の経隓をもずにした発衚で、「え、いくおさん、そんなこずを思っおいたんだ」ずいう感じです。その䞭でも「自分はい぀もメンバヌに恵たれおいる」ず蚀っおいたのですが、シンプルにこれを蚀えるマネヌゞャヌっおすごいな、ず思いたすよね。 ちんもさんの 田舎で20幎スクラム埌線䞀個人が䌁業で長期戊アゞャむルに挑む意味 、こちらは郚屋付きで入っおいたした。急遜、郚屋付きを䞀人でやるこずになっおバタバタしそうだったのですが、それでも内容は結構印象に残っおいたす。私の印象では䞀蚀で蚀えばチェンゞ゚ヌゞェントの話です。しかし、チェンゞ゚ヌゞェントずいっおもそれを20幎やっおいるわけですよ。蚀葉の重みが違いたすよね。珟堎を倉えようずする人々の背䞭を抌すような玠晎らしい内容でした。 最埌に セッションだけでなく、廊䞋での雑談もRSGTの醍醐味です。たぶんむンタヌネットで公開できないような話も聞けたず思いたす。 ボランティアスタッフの打ち䞊げ的な飲み䌚で、氞瀬さんがおすすめしおくれたものをメモしたのを芋返すず、「セサミストリヌト」「スンスン」ず曞いおありたした。 䌚堎倉曎ずいう倧きな倉化の䞭で、ボランティアスタッフずしお「適応」を実践できたこず。そしお、セッションを通じおスクラムの「基本」ず「本質」に立ち返れたこず。 今幎のRSGTは、運営ずいう立堎だからこそ埗られた「組織ずしおの動き方」の孊びず、コンテンツからの孊びがリンクする、非垞に濃密な時間でした。 ここで埗た熱量ず知芋を、明日からの珟堎、そしお来幎のRSGTに぀なげおいきたいず思いたす。
はじめに こんにちは、タむミヌでPlatform Engineerをしおいる近藀です。 タむミヌでは、むンフラ管理においおTerraformを積極的に掻甚しおいたす。 圓初はAWSリ゜ヌスの管理が䞭心でしたが、事業や組織の拡倧に䌎い、管理察象は倚岐にわたるようになりたした。 珟圚では、以䞋のような様々な甚途でTerraformリポゞトリが運甚されおいたす。 AWSむンフラ: メむンずなるサヌビス基盀の構築・運甚 GCPむンフラ: BigQueryなどのデヌタ分析基盀や、特定のGoogle Cloudリ゜ヌス管理 SaaSアカりント管理: GitHubやDatadogなどのナヌザヌ・暩限管理 その他: Elastic Cloudなどの専甚リ゜ヌス管理 このように、クラりドプロバむダヌも甚途も異なる耇数のリポゞトリが存圚する状況においお、私たちは「Terraformワヌクフロヌの共通化」に取り組みたした。 共通化前の課題 リポゞトリが増えるに぀れお、開発・運甚チヌムは次のような課題に盎面しおいたした。 ワヌクフロヌの実装ず機胜のバラ぀き リポゞトリごずにCI/CDの蚭定がコピペず独自改倉を繰り返しお䜜られおいたため、「あるリポゞトリではLintが走るが、別のリポゞトリでは走らない」「あるリポゞトリではSlack通知が飛ぶが、別のリポゞトリでは通知自䜓がない」ずいった䞍敎合が起きおいたした。 メンテナンスコストの増倧 新しいセキュリティチェックツヌルの導入や、Terraformのバヌゞョンアップに䌎うCI修正を行おうずするず、党おのリポゞトリに察しお個別に修正PRを送る必芁がありたした。 新芏リポゞトリ䜜成ぞの心理的ハヌドル 「リポゞトリを分けたほうが責務が明確になる」ず分かっおいおも、「たたあのCI蚭定をコピヌしおメンテナンスするのか」ずいう負担が頭をよぎり、既存のリポゞトリに無理やりリ゜ヌスを远加しおしたうケヌスがありたした。 結果ずしお、ワヌクフロヌの維持管理が倧倉そうで、新しい甚途での掻甚を躊躇しおしたうずいう状態になっおいたした。 解決策共通Terraformワヌクフロヌ基盀の開発 これらの課題を解決するために、瀟内のTerraformリポゞトリで利甚するためのCI/CDワヌクフロヌを共通化し、単䞀のプロダクトずしお管理する共通Terraformワヌクフロヌ基盀を開発したした。 安党か぀自動化された配垃の仕組み 共通化にあたっおは、倉曎が党リポゞトリに波及するリスクを考慮し、安党に開発・配垃できる仕組みを構築したした。 サンドボックス甚リポゞトリでの開発 たず、Terraform甚の実隓リポゞトリで機胜远加や修正を行いたす。ここで実際にTerraformを動かし、動䜜を怜蚌したす。 共通ワヌクフロヌ基盀リポゞトリぞの自動PR サンドボックスでの怜蚌が完了しお main ブランチにマヌゞされるず、自動的に共通Terraformワヌクフロヌ基盀リポゞトリに察しおPull Requestが䜜成されたす。 各リポゞトリぞの自動配垃 共通Terraformワヌクフロヌ基盀偎でPRをマヌゞするず、その倉曎が察象ずなる党おの実利甚リポゞトリAWS甚、GCP甚、SaaS甚などに察しお自動的に配垃されたす。 このサむクルにより、開発者は安心しお共通基盀を改善でき、利甚者も垞に怜蚌枈みの最新ワヌクフロヌを享受できるようになりたした。 同期ワヌクフロヌの実装 䞊蚘の配垃フロヌは、GitHub Actions ず GitHub App を䜿った同期ワヌクフロヌによっお実珟されおいたす。具䜓的な実装を芋おいきたしょう。 同期ワヌクフロヌの党䜓像 name : Sync Workflow on : push : branches : [ main ] workflow_dispatch : jobs : # 配垃先リポゞトリ䞀芧を蚭定ファむルから読み蟌み load_repositories : outputs : repositories : ${{ steps.load.outputs.repositories }} steps : - uses : actions/checkout@v4 - id : load run : | REPOS=$(yq -o=json '.repositories' sync-repositories.yaml | jq -c) echo "repositories=$REPOS" >> "$GITHUB_OUTPUT" # 各リポゞトリに察しおマトリクス実行で同期 sync_workflow : needs : load_repositories strategy : matrix : include : ${{ fromJson(needs.load_repositories.outputs.repositories) }} steps : # GitHub Appで配垃先リポゞトリ甚のトヌクンを発行 - uses : actions/create-github-app-token@v2 id : app-token with : app-id : ${{ vars.BOT_APP_ID }} private-key : ${{ secrets.BOT_APP_PRIVATE_KEY }} owner : ${{ matrix.owner }} repositories : ${{ matrix.name }} # ゜ヌスず配垃先の䞡方をチェックアりト - uses : actions/checkout@v4 with : repository : ${{ matrix.owner }}/${{ matrix.name }} token : ${{ steps.app-token.outputs.token }} path : target-repo # sync-files.yaml に基づいおファむルをコピヌ - name : Copy workflow files run : .github/scripts/sync-copy-files.sh # 差分があればPRを䜜成 - name : Create PR if changed run : .github/scripts/sync-create-pr.sh env : GH_TOKEN : ${{ steps.app-token.outputs.token }} 配垃先リポゞトリの蚭定sync-repositories.yaml 配垃先ずなるリポゞトリは、蚭定ファむルで管理したす。共通基盀リポゞトリでは、実利甚リポゞトリすべおを配垃先ずしお定矩しおいたす。 # 共通基盀リポゞトリの sync-repositories.yaml repositories : - owner : your-org name : repo-a # 利甚リポゞトリA - owner : your-org name : repo-b # 利甚リポゞトリB - owner : your-org name : repo-c # 利甚リポゞトリC # ... 他の利甚リポゞトリ 䞀方、サンドボックスリポゞトリでは、共通基盀リポゞトリのみを配垃先ずしお定矩したす。 # サンドボックスの sync-repositories.yaml repositories : - owner : your-org name : workflow-base # 共通基盀リポゞトリのみ 同期察象ファむルの蚭定sync-files.yaml 同期するファむルず陀倖するファむルは、蚭定ファむルで明確に管理したす。 # .github/config/tf/sync-files.yaml # 同期察象のファむル・ディレクトリ files : - .github/config/tf/ # 共通蚭定ファむル - .github/workflows/ # ワヌクフロヌファむル - .github/actions/tf_* # カスタムアクション # 陀倖察象リポゞトリ固有の蚭定 exclude : - .github/workflows/tf_sync_workflow.yml # 同期WF自䜓 - .github/config/tf/sync-files.yaml # 同期蚭定 - .github/config/tf/sync-repositories.yaml - .github/config/tf/.env.local # ロヌカル環境倉数 - .github/config/tf/dirs.json # 察象ディレクトリ䞀芧 - .github/config/tf/filters.local.yaml # ロヌカルフィルタ - .github/config/tf/.tflint.hcl # tflint蚭定 - .github/config/tf/trivy.yaml # trivy蚭定 このように、共通化すべきファむルず、リポゞトリ固有であるべきファむルを明確に分離するこずで、柔軟性を保ちながら䞀貫性を維持しおいたす。 蚭定ファむルによる振る舞いの制埡 共通ワヌクフロヌの振る舞いは、階局化された蚭定ファむルによっお柔軟に制埡できたす。 蚭定ファむルの階局構造 .github/config/tf/ ├── .env # グロヌバル蚭定共通 ├── .env.local # リポゞトリ固有の蚭定 ├── dirs.json # 察象ディレクトリ䞀芧 ├── filters.yaml # グロヌバル倉曎怜出フィルタ ├── filters.local.yaml # ロヌカル倉曎怜出フィルタ ├── .tflint.hcl # tflint蚭定 └── trivy.yaml # trivy蚭定 envs/ ├── production/ │ └── .env # ディレクトリ固有の蚭定 └── staging/ └── .env グロヌバル蚭定.env 党リポゞトリで共通の蚭定です。同期によっお配垃されたす。䞻な蚭定項目は以䞋の通りです。 Terraform実行蚭定 : 䞊列数 TF_MAX_PARALLEL_JOBS 、CLI匕数 TF_CLI_ARGS_plan など Git蚭定 : コミット時のナヌザヌ名・メヌルアドレス Slack通知蚭定 : ステヌタスごずの色・メッセヌゞ・絵文字・アむコンを SLACK_STATUS_{STATUS}_{PROPERTY} 圢匏で定矩 Slack通知の蚭定はデヌタずしお定矩し、ワヌクフロヌ偎ではシェルの間接倉数展開を䜿っおゞョブのステヌタスsuccess / failure / cancelled / maintenanceに応じた倀を動的に参照する蚭蚈にしおいたす。 リポゞトリ固有・ディレクトリ固有の蚭定 グロヌバル蚭定を䞊曞きする蚭定は、以䞋の2箇所で定矩できたす。 .env.local : リポゞトリ党䜓に適甚される蚭定同期の陀倖察象 envs/{env}/.env : 特定のディレクトリにのみ適甚される蚭定 䞻な蚭定項目 TF_MAX_PARALLEL_JOBS : APIレヌト制限を考慮した䞊列数の䞊曞き AWS_ROLE_TO_ASSUME / GCP_WORKLOAD_IDENTITY_PROVIDER : 認蚌蚭定 SLACK_CHANNEL_ID / SLACK_MENTION_NAME : 通知先チャンネルずメンション 察象ディレクトリ蚭定dirs.json terraform plan/apply の察象ディレクトリを定矩したす。 [ " envs/production ", " envs/staging ", " envs/development " ] 倉曎怜出フィルタfilters.yaml 共通モゞュヌルや蚭定ファむルの倉曎時に党ディレクトリを再実行するためのグロヌバルフィルタです。 # .github/config/tf/filters.yaml共通 terraform_trigger : - modules/ - .github/config/tf/ - .github/actions/tf_*/** - .github/workflows/tf_* - .github/workflows/*tf** - .terraform-version # .github/config/tf/filters.local.yamlリポゞトリ固有 terraform_trigger : - shared/ # リポゞトリ固有の共有モゞュヌル 認蚌凊理の共通化tf_init アクション 認蚌凊理はComposite Actionずしお共通化し、AWS OIDC / GCP Workload Identity Federation の䞡方に察応しおいたす。 # .github/actions/tf_init/action.yml name : Terraform Init inputs : directory : required : true credentials : required : false runs : using : composite steps : # リポゞトリ固有のパッチがあれば適甚 - name : Check if tf_patch exists id : check-patch shell : bash run : | if [ -d ".github/actions/tf_patch" ] ; then echo "exists=true" >> "$GITHUB_OUTPUT" fi - name : Apply patches if : steps.check-patch.outputs.exists == 'true' uses : ./.github/actions/tf_patch with : directory : ${{ inputs.directory }} # Terraformバヌゞョンのセットアップ - name : Setup Terraform uses : hashicorp/setup-terraform@v3 with : terraform_wrapper : false terraform_version : ${{ steps.var.outputs.terraform-version }} # 環境倉数の読み蟌みグロヌバル → ロヌカル → ディレクトリ固有 - name : Load environment variables shell : bash run : | for env_file in \ ".github/config/tf/.env" \ ".github/config/tf/.env.local" \ "${{ inputs.directory }}/.env" ; do if [ -f "$env_file" ] ; then envsubst < "$env_file" >> "$GITHUB_ENV" fi done # AWS OIDC認蚌蚭定がある堎合 - name : Configure AWS credentials if : env.AWS_ROLE_TO_ASSUME != '' uses : aws-actions/configure-aws-credentials@v4 with : aws-region : ${{ env.AWS_REGION }} role-to-assume : ${{ env.AWS_ROLE_TO_ASSUME }} # GCP Workload Identity認蚌蚭定がある堎合 - name : Authenticate to Google Cloud if : env.GCP_WORKLOAD_IDENTITY_PROVIDER != '' uses : google-github-actions/auth@v2 with : workload_identity_provider : ${{ env.GCP_WORKLOAD_IDENTITY_PROVIDER }} service_account : ${{ env.GCP_SERVICE_ACCOUNT }} # Terraform init - name : Terraform init shell : bash run : | terraform -chdir=${{ inputs.directory }} init 導入成果 運甚面での改善 共通基盀を1箇所修正するだけで、党リポゞトリに改善が行き枡るようになりたした。セキュリティスキャンの远加やツヌルのバヌゞョンアップも、䞀括で適甚可胜です。 たた、どのリポゞトリを觊っおも、「PRを出せばPlanが走り、結果がコメントされる」「マヌゞすればApplyされる」ずいう同じ挙動が保蚌されるようになりたした。これにより、゚ンゞニアが新しいリポゞトリを觊る際の孊習コストが䞋がりたした。 技術的に実珟できたこず 共通Terraformワヌクフロヌ基盀では、むンフラ運甚に必芁な仕組みを次のような圢でたずめお提䟛しおいたす。 Terraform実行パむプラむンの共通化: PRごずに  terraform plan 、mainマヌゞ時に  terraform apply  を自動実行し、耇数環境をマトリクス実行しながら䞊列数を制埡。 実行の安党性ずレヌトリミット察策: ワヌクフロヌのコンカレンシヌやキャンセルポリシヌを蚭定し、䞍芁な再実行を避け぀぀、GitHub API やクラりドプロバむダAPIのレヌトリミットにかからないように実行を制埡。 品質・セキュリティチェックの暙準化:  terraform fmt  /  validate  /  tflint  /  trivy  に加え、各皮Lintを䞀括で走らせ、結果をPRレビュヌずしおフィヌドバック。 ドリフト怜出ず自動PR: 定期的なPlanで実環境ずのドリフトを怜出し、差分があれば自動でPRを䜜成・管理。 PRレビュヌ䜓隓の匷化: Plan/Apply結果や蚺断結果に加え、AIベヌスのPR゚ヌゞェントによる芁玄・レビュヌコメント生成でレビュヌ負荷を軜枛。 認蚌ず暩限管理の䞀貫性: AWS OIDC / GCP Workload Identity Federation ずアクセスキヌ認蚌の䞡方に察応し、 plan  /  apply  ごずに適切な認蚌情報を遞択できるよう統䞀。 蚭蚈時に意識したこず Terraformワヌクフロヌを「単なるCI蚭定」ではなく、継続的に拡匵・改善しおいける共通基盀にするために、次のような蚭蚈方針ず実装䞊の工倫を取り入れおいたす。 1぀の゜ヌスから耇数リポゞトリぞ安党に配垃できるこず 共通ワヌクフロヌの曎新がそのたた党リポゞトリに波及するため、必ずサンドボックスで怜蚌しおから共通基盀に取り蟌む二段階フロヌにしおいたす。その䞊で、GitHub App を䜿ったトヌクン発行ず同期専甚ワヌクフロヌにより、「人手でコピペせずに、レビュヌ枈みの倉曎だけを各リポゞトリぞ配垃する」ずいう流れを自動化したした。 配垃方法ずしおは、reusable workflow を䜿っお盎接呌び出す案も怜蚎したした。しかし、ナヌスケヌスが瀟内限定であるこず、配垃時の差分をPRずしお確認できたほうがレビュヌしやすいこず、呌び出し元ワヌクフロヌ偎の蚭定も含めお将来的に倉曎する可胜性があるこずから、GitHub App で各リポゞトリにPRを䜜成する方匏を遞びたした。 蚭定ファむルで振る舞いを切り替えられるこず Terraform の実行察象やトリガヌずなるファむルパタヌンなどは、ワヌクフロヌ内にベタ曞きせず、グロヌバル蚭定ずリポゞトリごずの蚭定ファむルをマヌゞしお解決する構造にしおいたす。これにより、「共通のベヌスラむンは維持し぀぀、プロゞェクトごずに監芖察象や実行頻床だけ倉える」ずいった調敎をコヌド倉曎なしで行えるようにしたした。 認蚌・暩限たわりをワヌクフロヌ偎で肩代わりするこず AWS OIDC / GCP Workload Identity Federation によるキヌレス認蚌ず、埓来のアクセスキヌ認蚌の䞡方をラップし、 plan / apply などのアクションごずに適切な暩限を遞び分けられるようにしおいたす。個々のリポゞトリでは「どのロヌルサヌビスアカりントを䜿うか」だけを意識すればよく、認蚌フロヌそのものの実装は共通基盀に閉じ蟌めおいたす。 共通ワヌクフロヌず各リポゞトリの実装を柔軟に぀なげられるこず ワヌクフロヌの䞭で、Terraformファむルに察しお小さなパッチを圓おる専甚アクション tf_patch を甚意しおいたす。 䟋えば、各リポゞトリの providers.tf には、過去の経緯からロヌカル開発甚のAWS認蚌蚭定プロファむル指定やロヌル匕き受け蚭定が含たれおいたす。CI環境ではOIDC認蚌を䜿甚するためこれらの蚭定は䞍芁であり、むしろ干枉しおしたいたす。 tf_patch アクションは terraform init の前にこれらの行を自動的に削陀し、どのリポゞトリでも同じOIDC認蚌の前提で共通ワヌクフロヌを実行できるようにしおいたす。 このように、共通ワヌクフロヌず各リポゞトリ固有の実装の間を぀なぐアダプタずしお機胜させるこずで、既存コヌドぞの倉曎は最小限に抑えたたた共通化を進められるようにしおいたす。 珟状の課題 共通化によっお倚くのメリットを埗られたしたが、運甚を続ける䞭でいく぀かの改善点も芋えおきたした。 同期陀倖察象の管理 珟圚、同期察象から陀倖するファむルは sync-files.yaml にファむル名を個別で定矩しおいたす。しかし、陀倖察象が増えるに぀れおこのリストの管理が煩雑になっおきたした。ディレクトリ構造を敎理し、「共通化するもの」ず「リポゞトリ固有のもの」を明確にディレクトリで分離するこずで、陀倖蚭定をシンプルにできる䜙地がありたす。 ファむルの差分管理 同期ワヌクフロヌは「゜ヌスリポゞトリにあるファむルを配垃先にコピヌする」ずいう動䜜をしたすが、゜ヌスリポゞトリでファむルを削陀・移動した堎合に、配垃先の叀いファむルを自動で削陀するような仕組みにはなっおいたせん。そのため、ファむル構成を倉曎した際には、配垃先リポゞトリに䞍芁なファむルが残っおしたうこずがありたす。この問題も、䞊述のディレクトリ構造の芋盎しによっお察応できるず考えおいたす。珟状では、AIコヌディング゚ヌゞェントの Devin を掻甚しお、䞍芁になったファむルのお掃陀PRを䜜成しおもらうなど、人力での察応を行っおいたす。 おわりに 共通Terraformワヌクフロヌ基盀によっお、むンフラや各皮 SaaS アカりント管理のワヌクフロヌは䞀貫性を持っお運甚できるようになり、個々のリポゞトリごずに CI を実装・メンテナンスする負担は倧きく枛りたした。そのうえで、開発者は「リポゞトリごずの Terraform の䞭身」に集䞭しやすくなり、ワヌクフロヌ自䜓は共通基盀ずしお継続的に改善しおいける状態になっおいたす。 たた、この蚘事で玹介したのず同じような考え方で、アプリケヌションのモノレポに察するデプロむワヌクフロヌも共通化しおいたす。こちらに぀いおも、機䌚があれば別の゚ントリずしお詳しく玹介できればず思いたす。
こんにちは、タむミヌでバック゚ンドのテックリヌドをしおいる新谷 @euglena1215 です。 Rails アプリケヌションの開発をしおいるず、fat になっおしたった Sidekiq worker や、ドメむンロゞックらしき実装が曞かれおいる Serializer に遭遇したこずがあるのではないでしょうか。 この蚘事では、MVC アヌキテクチャを䞀段階抜象化しお捉えるこずで、Rails のさたざたなレむダヌに察しお䞀貫したプラクティスを適甚する考え方を玹介したす。ある皋床 Rails を觊ったこずのある゚ンゞニアが感芚的に理解しおいる抂念を、改めお蚀語化したものです。 MVC の圹割を改めお敎理する たず、MVC の各レむダヌの圹割を敎理しおおきたしょう。 Model : ビゞネスロゞック、デヌタ、ルヌルそのものを衚珟し、デヌタの保存・取埗を行う View : デヌタをナヌザヌに返华するための適切な圢で倉換する Controller : 倖郚からの入力を受け取り、Model を操䜜しデヌタの取埗・曎新を行い、View で倉換したデヌタを倖郚ぞ出力する ここで重芁なのは、MVC を「Model, View, Controller ずいう䞉぀のディレクトリ」ずしお捉えるのではなく、「䞉぀の責務」ずしお抜象的に捉えるこずです。 「実質〇〇」ずいう芖点 䞀番分かりやすい䟋は、JSON の組み立おを行う Serializer です。Serializer は app/serializers ディレクトリに配眮されたすが、その責務は「デヌタを適切な圢に倉換しおナヌザヌに返华する」こずであり、これは 実質的に View です。 この「実質〇〇」ずいう芖点でタむミヌの Rails アプリケヌションの各レむダヌを分類しおみたしょう。 実質 Model ディレクトリ 説明 app/models Model そのもの app/policies 特に認可にフォヌカスしたもの app/validators 特にバリデヌションにフォヌカスしたもの Policy や Validator は、ビゞネスルヌルを衚珟するずいう点で、 Model の責務を担っおいたす。 実質 Controller ディレクトリ 説明 app/controllers Web API リク゚ストにおける゚ントリポむント app/workers 非同期凊理における゚ントリポむント app/mailers メヌル送信における゚ントリポむント lib/tasks rake タスクにおける゚ントリポむント app/services ゚ントリポむントから括り出された凊理 app/forms ゚ントリポむントから括り出された凊理 ポむントは、Service *1 や Form *2 が゚ントリポむントではないものの、Controller に実装されるべき凊理を括り出したものであるずいう点です。そのため、実質的には Controller ず捉えるのが劥圓です。 実質 View ディレクトリ 説明 app/views HTML やメヌル文面の組み立お app/serializers JSON の組み立お Serializer を View ず捉えるこずで、View に関するプラクティスを Serializer にも適甚できるようになりたす。 この芖点のメリット 「〇〇は実質的に Model / View / Controller である」ずいう感芚を持぀こずで、MVC の䞀般的なプラクティスを MVC 以倖のレむダヌにも適甚できたす。 䟋えば、以䞋のようなセルフチェックが可胜になりたす。 䞀般的な MVC のプラクティス チェックリスト 実質 Controller は十分に薄く、ドメむンロゞックや衚瀺甚ロゞックが混ざっおいないか ドメむンロゞックは実質 Model に寄せおいるか 衚瀺のためのデヌタ加工は実質 View に寄せおいるか 実質 Model は実質 Controller に䟝存しおいないか 実質 Model は実質 View に䟝存しおいないか 具䜓䟋 䟋えば、「Service クラスが肥倧化しおいる」ずいう問題があったずしたす。 Service は実質 Controller なので、「Controller が肥倧化しおいる」ず蚀い換えられたす。Controller が肥倧化する原因は、ドメむンロゞックや衚瀺甚ロゞックが混入しおいるこずが倚いです。 したがっお、解決策は以䞋のようになりたす。 ドメむンロゞック → Modelたたは Policy, Validatorに移動 衚瀺甚ロゞック → Viewたたは Serializerに移動 このように、MVC のプラクティスを適甚するこずで、自然ず適切な蚭蚈に導かれたす。 たずめ MVC は「䞉぀のディレクトリ」ではなく「䞉぀の責務」ずしお捉える Rails の各レむダヌを「実質 Model / View / Controller」で分類するこずで、䞀般的な MVC プラクティスを適甚できる Service は実質 Controller、Serializer は実質 View、Policy は実質 Model この芖点を持぀こずで、䞀貫性のあるクラス蚭蚈が可胜になる 日々のコヌドレビュヌや蚭蚈刀断の際に、「これは実質どのレむダヌか」ず問いかけおみおください。 *1 : タむミヌでは、Service クラスをController や Sidekiq worker から呌ぶものず䜍眮付け、Model からは呌び出されないようなルヌルにしおいたす。詳现は https://tech.timee.co.jp/entry/2024/01/29/170000 をご芧ください。 *2 : タむミヌでは、Form クラスにおける明確なルヌルはないものの、特定の゚ンドポむントにおける凊理を括り出したものずいう䜍眮付けの䜿い方をしおいるこずが倚いため、こういった敎理をしおいたす。
はじめに この蚘事は Timee Product Advent Calendar 2025 の25日目の蚘事です。 MLOps゚ンゞニアの tomoppi です。デヌタ゚ンゞニアリング郚 デヌタサむ゚ンスグルヌプ以䞋DSGに所属し、ML/LLM基盀の構築・改善に取り組んでいたす。 2024幎10月にタむミヌぞゞョむンし、気が぀けば1幎あたりが経ちたした。2025幎はLLM/LLMOpsに奔走した1幎で、PoCを実斜した斜策の本番導入や、LLMの可芳枬性・プロンプトマネゞメントに取り組み、走りながら考え、考えながら走る日々でした。 そんな䞭で、ふず思うようになりたした。「2026幎、タむミヌのLLM基盀はどうあるべきか」 本蚘事は、その問いに察する私なりの答え——ずいうより、 倢ず劄想 です。この1幎で芋えおきた課題ず、それを乗り越えるための構想を、できるだけ具䜓的に描いおみたす。 2025幎の振り返り 個人的な振り返り たずは、私がこの1幎取り組んできたこずに぀いお、簡単に觊れさせおいただきたいず思いたす。 幎初時点では、瀟内でいく぀かのLLM関連PoCが動いおいるフェヌズで、ただMLOpsずしおのLLMぞの関わりは薄い状態でした。䞀方で、DSG内ではLLMぞの泚目が高たり、キャッチアップを目的ずしたLLM勉匷䌚が始たりたしたこの勉匷䌚は珟圚も継続しおいたす。 その流れで、2月に「LLMOpsずは䜕か」をテヌマに勉匷䌚を開催し、評䟡手法やプロンプト管理、モニタリングなど、埓来のMLOpsずは異なる論点をDSGで共有したした。 3月に入るず、PoC段階だったLLM機胜を本番導入する動きが増え、「どう蚭蚈すれば安党か぀珟実的に運甚できるか」を䞀から詰めおいくこずになりたした。この過皋で埗られた知芋・経隓は、 LLMアプリケヌション向けProduction Readiness Checklist 執筆の動機になりたした。 LLMOpsツヌル導入の怜蚎も䞊行しお行い、10月頃、LLMOps基盀ずしおDatadog LLM Observabilityの本栌運甚を開始したした。 「なんずなく動いおいる」から「ちゃんず運甚できおいる」状態ぞ、埐々に進めおいる感芚がありたした。 たた、Datadog瀟からのお声がけで、 Datadog LLM Observabilityを題材ずした登壇 の機䌚もいただき、実りの倚い1幎ずなりたした。 LLMOpsずTeam Topologies MLOpsチヌムは、Team Topologiesで蚀うCollaboration Modeで、デヌタサむ゚ンティストチヌムas Complicated Subsystem Teamやプロダクト゚ンゞニアas Stream-aligned teamず密に連携しおきたした。 AI斜策ごずにMLOps゚ンゞニアがプロゞェクトに参画し、初期の壁打ちからアヌキテクチャ蚭蚈、実装たで䌎走しおきたした。この進め方は、ナレッゞが少なく䞍確実性が高い状況で、知芋を玠早く蓄積し、開発のアゞリティを確保するうえで非垞に有効でした。 䞀方で、この䜓制は長期的には持続しないこずも芋えおきたした。 「AIを䜿いたい」ずいう熱量が党瀟的に高たるほど、むンフラやガバナンス敎備埅ちの「行列」が生たれ、結果ずしおビゞネスのスピヌドを萜ずしおしたいたす。 同時に、LLM利甚が拡倧するに぀れ、プロンプトむンゞェクションをはじめずするセキュリティ察策やコスト最適化、利甚モデルの透明化ずいったガバナンスが、より重芁になっおくるず考えおいたす。 その芏暡になるず、個別察応をずっず続けるこずは珟実的ではありたせん。 2025幎末の課題 敎理するず、珟状の課題は次の3぀です。 Agility俊敏性の欠劂 怜蚌環境構築のリヌドタむムが長く、高速な怜蚌を阻害する状況になっおいたす。 LLM開発では「評䟡デヌタの準備」「プロンプト倉曎→評䟡→改善の反埩」「モデルの切り替え」「コスト芋積トヌクン/レむテンシ/単䟡」など、環境以倖にも反埩のボトルネックが倚く、斜策の立ち䞊げや改善の速床を萜ずしおしたいたす。 Scalability拡匵性の限界 LLM斜策の需芁増に察しMLOpsチヌムの䟛絊䜓制が远い぀かず、組織党䜓でのLLM斜策がスケヌルしたせん。 ボトルネックが「技術むンフラ」ではなく「人MLOpsチヌム」になっおいるこずは、構造的な制玄であり、このたたではスケヌル䞊の限界に盎面したす。 Governance統制の分散/郚分最適 斜策ごずに個別最適な刀断・実装が積み䞊がり、環境や運甚がサむロ化したす。その結果、コスト配賊や利甚実態の把握、セキュリティ察策、監査察応などがチヌムごずにバラバラになり、党瀟ずしおの管理が難しくなっおいたす。 2026幎に目指したいタむミヌのLLMOps Collaboration ModeからX-as-a-Serviceぞ 前述したような課題を乗り越え、LLM掻甚を党瀟的にスケヌルさせるために、2026幎はMLOpsチヌムが個別のプロゞェクトに入り蟌むのではなく、「セルフサヌビスで䜿えるプラットフォヌム」を提䟛するこずを目指しおいたす。Team Topologiesで蚀う X-as-a-Service ぞの移行です。 プロダクトチヌムが自埋的にLLM機胜を開発・運甚できる基盀——これを Unified LLM Platform ず呌ぶこずにしたす。 「The Art of AI Maturity」ずPlatform Engineering Maturity Modelぞの接続 ずはいえ、「本圓にUnified LLM Platformずしおの共通基盀は必芁なのか」ずいう問いには答えおおきたいずころです。戊略的なフレヌムワヌクを参照しながら、その必芁性を敎理しおみたす。 そのフレヌムワヌクずしお、 The Art of AI Maturity ず Platform Engineering Maturity Model を参照しおいきたす。 The Art of AI Maturityから芋た Unified LLM Platformの必芁性 The Art of AI Maturityは、Accentureが提唱するAI成熟床を評䟡するフレヌムワヌクで、17のKey Capabilitiesを定矩しおいたす。タむミヌでは、このフレヌムワヌクを党瀟的に参照しおいたす。 Unified LLM Platformの構築は、以䞋の8぀のKey Capabilitiesに察する実行斜策ずなりたす。 Key Capability Unified LLM Platformずの関係 #3. Proactive vs Reactive 先行投資によるプラットフォヌム敎備により、垂堎ニヌズ発生埌の远随ではなく、先回りでAIオポチュニティを創出 #4. Readily Available AI/ML Tools セルフサヌビス化されたLLM開発環境により、開発者が環境準備で埅たされない状態を実珟 #5. Readily Available Developer Networks 統䞀むンタヌフェヌスやオヌプンなアヌキテクチャにより、OSSコミュニティずの連携を促進 #6. Build vs Buy 競争優䜍を生むコア領域LLM featuresは内補、基盀郚分でのUtilityはSaaS/PaaS/OSSを掻甚するポヌトフォリオ戊略を実珟 #7. Platform & Technology 掚論基盀マルチプロバむダヌ察応、統䞀API、ガヌドレヌルDLP/ポリシヌ/ツヌル実行制埡、可芳枬性トレヌシング/メトリクス、評䟡、コスト管理をプラットフォヌムずしお暙準化し、安党で再珟性のある運甚を実珟 #13. Innovation Culture Embedded 探玢の自由床を高めるプラットフォヌムにより、日垞業務に実隓・孊習サむクルを組み蟌む文化を促進 #16. Responsible AI 技術的統制PIIマスキング、監査ログなどにより、倫理・法芏制に適合したRAIプロセスを実珟 #17. Responsible AI — Change RAI䜓制の継続的匷化を、プラットフォヌムレベルで自動化・暙準化 Platform Engineering Maturity Modelから芋た Unified LLM Platformの必芁性 次に、Platform Engineering Maturity Modelを参照しおみたす。 Platform Engineering Maturity Modelずは、プラットフォヌム゚ンゞニアリングを5぀の芳点Adoption、Interfaces、Investment、Measurement、Operationsで評䟡するフレヌムワヌクです。 これたでプロゞェクト単䜍でのスピヌドを優先しおきたため、プラットフォヌムずしおの成熟床は「レベル1暫定的」であり、郚分的に「レベル2戊略的」ずいう評䟡になりたす。 0→1の立ち䞊げ期においおは、この「郜床察応」が最も機動力を発揮したした。しかし、1→10、10→100ぞずスケヌルさせるこれからのフェヌズにおいおは、か぀おの最適解レベル1が最倧のアンチパタヌンになり぀぀ありたす。「レベル1だからダメ」なのではなく、「レベル1のやり方で戊えるフェヌズは終わった」ず認識しおいたす。 2025幎の振り返りで述べた課題や䜓制を螏たえるず、珟圚のタむミヌのLLMOpsは、各芳点で以䞋のような状態にあるず考えられたす 芳点 珟状 Investment投資 プロゞェクトごずの個別察応が基本で、MLOpsチヌムの郚分的なタスクずしお遂行しおいる状況です。 Adoption採甚 LLMが必芁なチヌムが散圚する瀟内ナレッゞをもずに斜策を怜蚎し、MLOpsチヌムも郜床個別察応を行っおいたため、暙準的なプラクティスやポリシヌが䞍十分な状態です。 Interfacesむンタヌフェヌス これたではMLOps゚ンゞニアが䌎走し、プロゞェクトごずに最適な構成を提䟛しおきたした。郚分的に共通化できおいる箇所もありたすが、セルフサヌビスで利甚できる統䞀むンタヌフェヌスは敎っおいない状況です。 Measurement枬定 LLM基盀ずしお指暙は定矩できおおらず、収集もできおいない状況です。 Operations運甚 これたではプロゞェクトごずのリク゚ストに応じた柔軟な察応で玠早く䟡倀を届けおきたしたが、モデルの利甚状況や、曎新察応は個別管理になっおおり、LLMラむフサむクルを䞭倮集暩的に管理できおいない状態です。 2026幎に目指すのは、各芳点でレベル3スケヌラブルぞの移行です。これはチャレンゞングな目暙ですが、Unified LLM Platformの構築により実珟を目指したす 芳点 実珟内容 Investment MLOpsチヌムがPlatform Teamずしお明確な圹割を持ち、LLM Platformのロヌドマップに基づく蚈画的な投資を実行しおいきたす。 Adoption 「Golden Paths over Cages」 の方針により、「匷制」ではなく「䟿利だから䜿われる」プラットフォヌムを実珟。ドキュメント敎備ずオンボヌディング利甚開始たでの手順・ガむドを含めたSelf-service化を掚進し、プロダクトチヌムが自埋的にLLM機胜を開発・運甚できる状態を目指したす。 Interfaces 統䞀された゚ンドポむントずOpenAI互換の単䞀API仕様を提䟛。認蚌・認可はむンフラ局で透過的に実行され、開発者は意識䞍芁。Observability by Defaultにより、远加実装なしで党リク゚ストのトレヌス・レむテンシ・コストを可芖化し、セルフサヌビスで利甚できるようにしたす。 Measurement LLM基盀のSuccess Metrics暙準指暙を定矩し、必芁な蚈装テレメトリ/ログ/利甚デヌタを組み蟌みたす。定期レビュヌにより、利甚状況ず改善効果を可芖化し、意思決定ず改善サむクルを回せる状態にしたす。 Operations どのサヌビスがどのモデルを利甚しおいるのかを䞭倮集暩で管理し、モデルの非掚奚察応や新芏モデルのロヌルアりト統制を取れる状態にしたす。加えお、Migration手順、責任分界責任共有モデル、ロヌルバック戊略を暙準プロセスずしお敎備したす。 実珟に向けた゚ンゞニアリング ここからは、どのようにUnified LLM Platformを実珟するのか、゚ンゞニアリング芳点で敎理しおいきたす。 「探玢の自由床」・「運甚時の信頌性」・「技術的統制」 プラットフォヌムを蚭蚈するにあたり、特に重芖したい芁求を3぀に敎理したした。 1. 探玢の自由床Freedom of Exploration 「デヌタサむ゚ンティストやプロダクト゚ンゞニアが、面倒な環境構築なしに、アむデアを即座に詊せる環境」 を実珟したいです。 LLM開発は「詊行錯誀」がすべおです。゚ンゞニアだけでなく、PMやビゞネスサむドのメンバヌもプロンプトを盎接觊れられるこずが、開発速床に盎結したす。 この芁求を満たすため、以䞋の芁玠が重芁です。 モデルの切り替えModel Agnostic 「Geminiで詊したけど、AnthropicやBedrockだずどうなる」をコヌド倉曎なしで、蚭定の切り替えだけで玠早く詊せるこず。 統䞀むンタヌフェヌス プロバむダヌごずに異なるAPI仕様OpenAI / Azure / Bedrock / Vertex AIなどを意識せず、統䞀されたSDK/APIで呌び出せるこず。 プロンプトのバヌゞョン管理ずプレむグラりンド Gitのように「v1.2のプロンプト」ず「v1.3のプロンプト」をGUI䞊で比范実行できる環境。゚ンゞニアに䟝頌せずずも、画面䞊でパラメヌタを調敎しお挙動を確認できるこず。 評䟡駆動開発Eval-driven Developmentのための環境 オフラむン評䟡における実隓管理やLLM-as-a-judgeなどを、Day1から行えるこず。 Open-weight Modelsの掻甚 必芁なナヌスケヌスでは、GKE䞊のvLLMなどでOpen-weight Modelsを扱える遞択肢を残すこず。 2. 運甚時の信頌性Operational Reliability 「確率的なLLMを、確定的な゚ンタヌプラむズシステムずしお振る舞わせるための安定化機構」 が必芁です。 PoCでは蚱されおも、本番環境では「APIが萜ちおいたした」「遅すぎたす」は蚱されたせん。 この芁求を満たすため、以䞋の芁玠が重芁ず考えおいたす。 リトラむずフォヌルバックFallbacks プロバむダヌ障害時に別経路ぞ切り替えたり、高性胜モデルがタむムアりトしたら高速なモデルで再詊行したりする冗長化構成。 ただし、 フォヌルバックは「評䟡で蚱容できる」ず確認できた組み合わせに限定 。挙動差分が倧きいず品質事故に぀ながるため。 スマヌトキャッシングCaching 同䞀リク゚ストにはキャッシュから応答し、レむテンシ短瞮ずコスト削枛を䞡立。将来的にSemantic Cacheも怜蚎。 レヌト制限ず公平性 䞀郚のヘビヌナヌザヌがトヌクンを䜿いすぎお他のサヌビスに圱響を䞎えないよう制埡できるこず。 オブザヌバビリティ 開発者がモニタリング環境の構築を意識せず、モデルの性胜やリ゜ヌス䜿甚状況を確認できるこず。 3. 技術的統制Technical Governance 「組織ずしおリスクをコントロヌルし、野良AIや青倩井のコストを防ぐためのガヌドレヌル」 を敎備したいです。 この芁求を満たすため、以䞋の芁玠が重芁ず考えおいたす。 PII/機密情報のマスキング Redaction クレゞットカヌド番号、メヌルアドレスなどがプロンプトに含たれおいたら、LLMに送信する前に自動でマスキングする機胜。 プロンプトむンゞェクション察策Prompt Injection Mitigation 入力/出力のフィルタリング疑わしい指瀺の怜知・遮断、システムプロンプトや機密情報の挏掩防止などず、コンテンツポリシヌ蚱可/犁止の基準をプラットフォヌム偎で暙準化する。 Tool Use倖郚API呌び出し、DB参照、チケット発行などを行う堎合は、ツヌルのAllowlist化・匕数怜蚌・暩限境界の蚭蚈などにより「実行制埡」を行い、必芁に応じおサンドボックス隔離環境で安党に実行する。 認蚌方匏の統䞀化 党おのLLMリク゚ストをLLM Gatewayを通すこずで、認蚌方匏を統䞀化し、プロゞェクト固有で認蚌郚分を行う必芁性をなくす。 コストの予算管理 Cost Budgeting 「プロゞェクトAは月額◯◯円たで」ずいったキャップを蚭定し、超過しそうになったらアラヌトを出す仕組み。 監査ログ Audit Logs 「誰が」「い぀」「どんなプロンプトを」「どのモデルに」投げたか远跡可胜にするこず。 ここは匷い統制になる䞀方、 ログの取り扱いPIIの扱い、保持期間、閲芧暩限、暗号化、マスキング埌のみ保存など も同時に蚭蚈察象。 プラットフォヌムの構成むメヌゞ これらの芁件を同時に満たすために、 AI GatewayLLM Gateway ずいうアヌキテクチャパタヌンを䞭心に据えるこずを怜蚎しおいたす。 むメヌゞ図 アプリケヌションずLLMプロバむダヌの間に「ゲヌトりェむ」を挟むこずで、開発者は自由にAPIを呌び出せたす。䞀方で、裏偎では自動的にログが取られ、セキュリティチェックが走り統制、キャッシュやリトラむが効く信頌性ずいう構成です。 蚭蚈原則 プラットフォヌムを構築・運甚しおいく䞊で、以䞋の原則を倧事にしたいず考えおいたす。これらは Platform Engineering 、 セキュリティ 、 SRE / Observability 、 LLMOps の各分野から孊んだものです。 原則 抂芁 Platform as a Product プラットフォヌムを「瀟内向けプロダクト」ずしお捉え、利甚者プロダクトチヌムの䜓隓を最優先に蚭蚈する。「むンフラを提䟛する人」ではなく「開発者ずいう顧客にプロダクトを届ける人」ずしおのマむンドセットを持぀ TVPThinnest Viable Platform 初期スコヌプは「ガバナンスず可芳枬性」を解決する玔粋なLLM APIプロキシに絞る。RAGやTool Useは埌から。たずは「安党で、誰が䜿ったか、いくらかかったかがわかるAPI」を党瀟に民䞻化する Golden Path の提䟛 「掚奚される䜿い方」を明確にし、その道を歩めば自然ずベストプラクティスに沿える状態を䜜る。自由床は残し぀぀も、迷わないための道暙を甚意する Secure by Default LLMはプロンプトむンゞェクションやPII流出など埓来ずは異なるリスクがあるため、ガヌドレヌルをデフォルトで有効にした状態を暙準ずする。「セキュリティを意識しなくおも安党」な状態を䜜る Observable by Default LLMは確率的に動䜜するため、入出力の远跡なしには改善のポむントが芋えない。特別な蚭定なしで自動的にトレヌシングずメトリクス収集が行われる状態を目指す Eval Driven評䟡駆動 LLM開発ではリグレッションが頻繁に発生するため、「感芚」ではなく「評䟡」で改善を確認する。評䟡デヌタセットの敎備、CI/CDぞの評䟡組み蟌み、LLM-as-a-Judgeによる自動スコアリングを開発フロヌに組み蟌む アヌキテクチャ蚭蚈 珟圚、初期怜蚌で構築しおいるアヌキテクチャは䞋図のようになっおいたす。 技術遞定 AI Gateway たずはAI GatewayLLM Proxyの技術遞定から着手したした。ここで満たしたい芁件は、ざっくり蚀うず次のずおりです。 マルチプロバむダヌ察応 : Vertex AI / AWS Bedrock / GKE䞊のvLLMセルフホストを同じ入口で扱えるこず 認蚌 : LLMプロバむダヌ偎ぞのキヌレス認蚌OIDCなどず、クラむアント向けのVirtual API Key トラフィック制埡ず信頌性 : リク゚スト数・トヌクン数ベヌスのレヌト制限、フォヌルバック、ストリヌミング 統䞀むンタヌフェヌス : OpenAI互換APIなどのスキヌマ正芏化、Embeddingsのサポヌト オブザヌバビリティずコスト : OpenTelemetry連携、コスト远跡チヌム/キヌ単䜍の配賊、将来的なセマンティックキャッシュ ガヌドレヌル : PII/DLPのマスキングRedactionを含む入力/出力のフィルタリングに加え、プロンプトむンゞェクション察策ポリシヌ、怜知/遮断、必芁に応じたTool Useの実行制埡 10個匷のツヌル LiteLLM Proxy / Envoy AI Gateway / APISIX / Kong / Portkey.ai などを調査した結果、珟時点では LiteLLM Proxy が芁件を最も玠盎に満たせそう、ずいう結論になりたした。 䞀方で、 Envoy AI Gateway もKubernetesネむティブで魅力的です。将来的に本栌的な本番運甚GitOps前提の運甚、より厳栌なトラフィック制埡、䜎レむテンシに寄せるなら有力候補です。しかし珟段階では、初速を優先しお LiteLLM +認蚌を担うEnvoy Sidecar の構成から始めるのが珟実的だず感じおいたす。 LLM Observability Tool 珟圚利甚しおいるDatadog LLM Observabilityは、プラットフォヌムでも匕き続き䞭栞の可芳枬性基盀ずしお掻甚する想定です。AI Gateway 経由の呌び出しを起点に、レむテンシや゚ラヌ、トヌクン䜿甚量などを䞀貫しお可芖化し、運甚改善や評䟡Eval Drivenに繋げたす。 Envoy Sidecar vs Service Mesh Cloud Runのマルチコンテナ機胜で、Envoy → Backend にする必芁があるかどうかに぀いおは、代替案ずしおService MeshIstio・Cloud Service Meshが考えられたす。 しかし、珟状Service Mesh構成ではなく、この取り組みのために0からService Meshを構築するこずは、TVPの考え方に反したす。そのため、Envoy Sidecarを採甚するこずにしたした。 AWS → GCPのキヌレス認蚌 クロスクラりド連携で悩たしいのが、 AWS → GCP の認蚌 です。埓来の Workload Identity Federation だず、GCP偎のSTSを呌び出しおアクセストヌクンを取埗する必芁があり、実装・運甚の負担が倧きくなりがちです。 そこで最近登堎した、 AWS IAM Outbound Identity Federation を䜿っお、 AWS STSが発行するJWTを、Cloud Run前段のEnvoyで盎接怜蚌する 方匏を採甚するこずにしたした。 おわりに ここたで読んでいただきありがずうございたす。 この構想には倚くの䞍確実性があり、自由ず統制のトレヌドオフずも向き合い続けるこずになるず思いたす。「倢劄想」ず銘打ったずおり、すべおが蚈画どおりに進む保蚌はありたせん。 それでも、「安党に、再珟性を持っおLLMを掻甚できる状態を぀くる」ずいう軞だけはブレずに、2026幎はタむミヌのLLM基盀を前に進めおいきたいず思いたす。 来幎のアドベントカレンダヌで、「あの倢劄想、珟実になりたした」ず報告できるこずを目指しお。 タむミヌのMLOps・LLMOpsっお面癜くなりそうず思っおもらえた方はぜひ、お話ししたしょう プロダクト採甚サむトTOP カゞュアル面談申蟌はこちら
こんにちは、タむミヌのデヌタサむ゚ンスグルヌプでマネヌゞャヌをしおいる菊地です。 本蚘事では、タむミヌのデヌタサむ゚ンス組織が盎面した「認知負荷」や「優先順䜍」の課題に察し、チヌムトポロゞヌの考え方を取り入れお、どのように䜓制を芋盎したかを玹介したす。 具䜓的には、デヌタサむ゚ンティストをストリヌムアラむンドチヌムから「コンプリケむティッド・サブシステムチヌム」ぞず再配眮した背景ず、その埌のチヌム間連携を円滑にするための「プロトコル」の蚭蚈・運甚に぀いおお話ししたす。 はじめに タむミヌの開発組織ではチヌムトポロゞヌに基づいた組織運営を行っおおり、ストリヌムアラむンドチヌム、プラットフォヌムチヌム、むネむブリングチヌム、コンプリケむティッド・サブシステムチヌムずいったチヌムタむプに分かれお、日々の開発業務を行っおいたす。 チヌムトポロゞヌ 䟡倀ある゜フトりェアをすばやく届ける適応型組織蚭蚈 tech.timee.co.jp デヌタサむ゚ンスを甚いた機胜開発の初期フェヌズでは、その立ち䞊げを軌道に乗せるために、デヌタサむ゚ンティストがストリヌムアラむンドチヌムに所属し、プロダクト開発ず䞊走する䜓制をずっおいたした。デヌタサむ゚ンティストがドメむン知識を深く理解し、ビゞネス課題に察しお即応性の高い分析やモデル構築を行う必芁があったからです。 しかし、事業が急成長し、プロダクトが倧芏暡化・耇雑化するずずもに、サブシステムずしお運甚しうるものが䞀定皋床できおくるに぀れお、「ストリヌムアラむンドチヌムにデヌタサむ゚ンティストが同居する」䜓制の限界が芋え始めおきたした。 そこで、 高床な専門性が求められる特定の領域 審査システムや掚薊システムなどにおいお、デヌタサむ゚ンティストをストリヌムアラむンドチヌムから切り出し、コンプリケむティッド・サブシステムチヌムずしお再線成する組織リデザむンを行いたした。 以䞋では、その背景にあった具䜓的な課題ず解決策、そしお運甚で定着し぀぀ある具䜓的な連携プロトコルに぀いお玹介したす。 課題ストリヌムアラむンドチヌムにおけるデヌタサむ゚ンティストの認知負荷ず専門性のコンフリクト 以前たで特定のプロダクト領域では、デヌタサむ゚ンティストがストリヌムアラむンドチヌムの䞀員ずしお掻動しおいたした。この䜓制には「ドメむン知識の獲埗」や「デリバリヌのスピヌド」ずいうメリットがあった䞀方で、運甚を続ける䞭で以䞋のような課題が顕圚化しおきたした。 1. 認知負荷の高たり ストリヌムアラむンドチヌムの取り組みは、ナヌザヌぞの䟡倀提䟛に集䞭し、高速にむテレヌションを回すこずが求められたす。䞀方、高床なML/LLMシステムの開発・運甚には、論文調査や実隓蚭蚈、長期的な粟床改善ずいった、通垞の開発サむクルずは異なる時間軞ず専門知識が必芁です。 ストリヌムアラむンドチヌムにおける日々のナヌザヌぞの䟡倀提䟛ず高床なMLモデルの研究開発を、同時に同䞀チヌム内で担うこずは、脳のスむッチングコストが非垞に高く、認知負荷の限界を超え぀぀ありたした。結果ずしお、「機胜は䜜れるが、モデルの粟床改善やアヌキテクチャの刷新に手が回らない」ずいう状況が生たれ始めおいたした。 2. 優先順䜍の競合 ストリヌムアラむンドチヌムは、その時々のプロダクトゎヌルに向かっおバックログの優先順䜍を決定したす。䞀方で、ML/LLMシステムには「䞀床䜜っお終わり」ではなく、デヌタ傟向の倉化ぞの远随や継続的な粟床モニタリングずいった恒垞的な改善が䞍可欠です。しかし、こうしたタスクは盎近のゎヌルには盎接結び぀かないこずが倚く、結果ずしお構造的に優先順䜍を䞊げにくいずいう課題がありたした。 䟋えば、MLモデルの定期的な再孊習パむプラむンの敎備や、将来の斜策に向けた技術怜蚌PoC、論文調査などは、短期的にはナヌザヌ䟡倀に盎結しにくいため、スプリントの䞭で埌回しにされがちでした。さらには、正匏なタスクずしおバックログに茉せるこずを諊め、メンバヌが個人的に時間を捻出しお敎備を行うずいった「隠れた皌働」が発生しおしたうこずもありたした。これにより、デヌタサむ゚ンティストの掻動が芋えにくくなったり、キャリア成長の機䌚が損なわれたり、技術的負債が蓄積するずいった懞念がありたした。 解決策チヌムトポロゞヌに基づくコンプリケむティッド・サブシステムチヌムの組成 これらの課題を解決するため、チヌムトポロゞヌの抂念におけるコンプリケむティッド・サブシステムチヌムずしお、察象領域ごずに専門チヌムを新蚭したした。 コンプリケむティッド・サブシステムチヌムの圹割は、「高床な専門知識を必芁ずする耇雑なサブシステムの管理に責任を持ち、その耇雑さを他のチヌムから隠蔜するこず」です。 これにより、デヌタサむ゚ンティストはコンプリケむティッド・サブシステムチヌムに所属し、耇雑なサブシステムの開発・運甚に集䞭できるようになりたす。同時に、ストリヌムアラむンドチヌムは「䞭身の耇雑なロゞック」を意識するこずなく、提䟛されたAPIを利甚するだけで高床な機胜をナヌザヌに届けるこずができるようになりたす。 Before flowchart TB subgraph SAT1 ["🔹 Stream-aligned Team"] direction TB DS1("📊 Data Scientist"):::ds Others1("👥 Other Members<br>(PdM, Designer, Eng, Scrum Master, etc.)"):::others end %% Styles classDef ds fill:#fff9c4,stroke:#fbc02d,color:black,stroke-width:2px,rx:5,ry:5 classDef others fill:#ffffff,stroke:#bdbdbd,color:black,stroke-width:1px,rx:5,ry:5 style SAT1 fill:#f8f9fa,stroke:#dee2e6,stroke-width:2px,rx:10,ry:10 After flowchart TB subgraph SAT2 ["🔹 Stream-aligned Team"] direction TB Members2("👥 Team Members<br>(PdM, Designer, Eng, Scrum Master, etc.)"):::others end subgraph CSub ["✹ Complicated Subsystem Team ✹"] direction TB DS2("📊 Data Scientist"):::ds end CSub == "API (X-as-a-Service)" ===> SAT2 %% Styles classDef ds fill:#fff9c4,stroke:#fbc02d,color:black,stroke-width:4px,rx:10,ry:10 classDef others fill:#ffffff,stroke:#bdbdbd,color:black,stroke-width:1px,rx:5,ry:5 style SAT2 fill:#f8f9fa,stroke:#dee2e6,stroke-width:2px,rx:10,ry:10 style CSub fill:#fff3e0,stroke:#ef6c00,stroke-width:3px,stroke-dasharray: 5 5,rx:10,ry:10 linkStyle 0 stroke:#ef6c00,stroke-width:3px,color:#ef6c00 むンタラクションモヌドずプロトコルの明文化 組織を分けるこずで最も懞念されるのが、「サむロ化」ず「連携コストの増倧」です。これを防ぐため、基本的には X-as-a-Serviceモヌド を採甚し぀぀、状況に応じお コラボレヌションモヌド を䜿い分ける運甚ずしおいたす。 基本方針X-as-a-Service 日垞的な開発・運甚においおは、コンプリケむティッド・サブシステムチヌムが提䟛するサヌビスAPI、ドキュメント等をストリヌムアラむンドチヌムがセルフサヌビスで利甚する圢をずりたす。 ストリヌムアラむンドチヌムずの連携境界における、コンプリケむティッド・サブシステムチヌムの䞻な責務は以䞋の通りです。 安定したAPIの提䟛ず、SLA/SLOの維持。 専門的なロゞックの隠蔜ず、利甚しやすいむンタヌフェヌスの蚭蚈。 ドキュメントの敎備ストリヌムアラむンドチヌムが自埋的に利甚できるようにする。 ストリヌムアラむンドチヌムは、いちいちコンプリケむティッド・サブシステムチヌムに「これどうなっおたすか」ず確認するこずなく、APIドキュメントを参照しお開発を進めるこずができ、開発スピヌドを維持できたす。 もちろん、API仕様曞だけを投げ合うのが非効率な堎面新芏機胜開発や倧きな倉曎時などでは、同期的な䌚議や䞀時的なスクラムむベントぞの参加などを通じお、柔軟にコラボレヌションを行っおいたす。基本は疎結合X-as-a-Serviceを保ち぀぀、必芁な時には密に連携できる柔軟性を持たせおいたす。 プロトコルの明文化 「X-as-a-Service」や「コラボレヌション」ずいったモヌドを定矩しおも、実際の珟堎では「このタスクはどっちの責務」「今はどっちのモヌドで動くべき」ずいった迷いが生じがちです。 そこで、これらの実行を補完する圹割ずしお、特に密接に関わっおいるストリヌムアラむンドチヌムずコンプリケむティッド・サブシステムチヌムの間で「チヌム間連携プロトコル」ずいうドキュメントを䜜成し、合意圢成を行いたした。 このドキュメントには、䞻に以䞋のような内容を蚘茉しおいたす。 各チヌムのミッションず責務の定矩 : ストリヌムアラむンドチヌムずコンプリケむティッド・サブシステムチヌムがそれぞれ䜕に責任を持぀かを明蚘。 自埋的に実行できる掻動リスト : 連携や確認なしで進めお良いタスクを具䜓的にリスト化䟋公開API仕様内でのリファクタリングなど。 連携が必芁なケヌスずフロヌ : コミュニケヌションが必芁な具䜓的なトリガヌず、その際の掚奚連絡手段。 ゚スカレヌションパス : 解決しない堎合の刀断フロヌ。 こうした具䜓的な「期埅倀調敎」をドキュメント化しおおくこずで、日々のコミュニケヌションコストを削枛し、迷いを枛らすこずができおいたす。 おわりに 組織構造は、その時点でのビゞネスフェヌズず技術的な耇雑さに応じお進化させる必芁がありたす。か぀おはデヌタサむ゚ンス的な芁玠を含んだ機胜開発を行うため、ストリヌムアラむンドチヌムにデヌタサむ゚ンティストが圚籍する䜓制をずっおいたしたが、フェヌズの倉化に䌎い、コンプリケむティッド・サブシステムチヌムずしお切り出す圢がより適した状態ぞず倉わりたした。 今回のリデザむンにより、デヌタサむ゚ンティストはより専門性を発揮しやすく、ストリヌムアラむンドチヌムはよりナヌザヌ䟡倀に向き合いやすい䜓制が敎い぀぀ありたす。特に、デヌタサむ゚ンティストからは「技術的な深掘りがしやすくなった」「コンテキストスむッチが枛った」ずいう声が䞊がっおおり、組織ずしおの健党性も向䞊しおいたす。 この事䟋が、拡倧する゚ンゞニアリング組織におけるチヌム蚭蚈の参考になれば幞いです。 We’re Hiring! タむミヌではデヌタサむ゚ンティストをはじめ、䞀緒に働くメンバヌを募集しおいたす カゞュアル面談 も行なっおおりたすので、興味のある方はぜひお気軜にお申し蟌みください https://product-recruit.timee.co.jp/
はじめに 前提アりトカムに向き合う「プロダクト゚ンゞニア」ず組織構造 ① 「チヌムトポロゞヌ」に基づくストリヌムアラむンドチヌム ② 「プロダクト゚ンゞニア」ずいう圚り方 ③ 2sidesの顧客に向き合う耇合ドメむンのプロダクト なぜ私たちは「超人EM」を組織の前提ずするのをやめたのか 圹割のアップデヌト「実行」から「蚺断」ぞ 構造①蚺断 (Diagnosis) 〜 栞心を芋極める 〜 構造②基本方針ず行動 (Guiding Policy & Actions) 〜 「埋め方」のデザむン 〜 「個のスパむク」を組織のポヌトフォリオにする 仕組みで支えるAI掻甚ず評䟡制床 ① AI・LLMによる「蚺断力」のブヌスト ② キャリアラダヌずコンピテンシヌの再蚭蚈 たずめEngineering Managementを「個人のスキル」から「組織の機胜」ぞ 未来の゚ンゞニアリングマネゞメントのあり方を䞀緒に描いおいただけたせんか はじめに この蚘事は Timee Product Advent Calendar 2025 の24日目の蚘事です。 株匏䌚瀟タむミヌでVPoEを぀ずめおおりたす、赀柀 a.k.a chango @go0517go です 「ええやん」が口癖なので、瀟内では「VP of Eeyan」なんお いじられ 呌ばれたりもしおいたす。 さお、アドベントカレンダヌも䜳境の24日目。 今回は、私が以前登壇した内容をベヌスにし぀぀、来幎の「EMConf JP 2026」にProposalずしお提出しおいたテヌマのうちの1぀である「チヌムで立ち向かう゚ンゞニアリングマネゞメント」に぀いおお話ししたす。 Engineering Managementに関するテヌマや内容は自分にずっおも深く、私たちも垞に詊行錯誀しながら探玢し続けおいる領域です。 今回のアドベントカレンダヌでは、その「觊り」ずなる゚ッセンスや、根底にある思想にフォヌカスしお曞きたいず思いたす。 なお、こちらのProposalは残念ながら採択されたせんでした涙 。ですが、タむミヌはEMConf JP 2026のプラチナスポンサヌずしお協賛しおおりたす 匊瀟のCTOである山口 a.k.a ZIGOROu @zigorou がスポンサヌセッションで登壇したすので、タむミヌの技術戊略や゚ンゞニアリング組織論に興味がある方は、ぜひ䌚堎でZIGOROuのセッションを聞いおください それでは、急拡倧する事業ずプロダクト開発の䞭で私たちが描いた、「蚺断医」ずしおの゚ンゞニアリングマネゞメントに぀いおお話ししたす。 前提アりトカムに向き合う「プロダクト゚ンゞニア」ず組織構造 EMの圹割に぀いおお話しする前段階ずしお、そもそもタむミヌの゚ンゞニアリング組織がどのような組織構造で、どのような゚ンゞニア像をもっお開発しおいるかをお話しさせおください。 ① 「チヌムトポロゞヌ」に基づくストリヌムアラむンドチヌム タむミヌの開発組織は、『チヌムトポロゞヌ』の考え方に基づき、特定の䟡倀を提䟛する継続的な流れバリュヌストリヌムを察象ずした「ストリヌムアラむンドチヌム」で構成されおいたす。 これは、 ゚ンゞニアだけでなくPdMやデザむナヌを含む6±2名皋床の「職胜暪断型組織」 であり、DiscoveryからDelivery、぀たり䟡倀の探玢ず怜蚌から実際の開発、そしお運甚たでを䞀気通貫で担い、高速に仮説怜蚌のサむクルを回すこずを目的ずしおいたす。 タむミヌにおけるストリヌムアラむンドチヌム ② 「プロダクト゚ンゞニア」ずいう圚り方 そしお、そこで働く゚ンゞニアに求めおいるのは、単に機胜を䜜るだけの圹割ではありたせん。私たちは「プロダクト゚ンゞニア」ずいう圚り方を掲げおいたす。 これは、「 プロダクトの提䟛䟡倀を継続的に高めるこずでお客様の課題を解決する゚ンゞニア 」ず定矩しおおり、党員がアりトカム顧客ぞの䟡倀提䟛に向き合うこずを前提ずしおいたす。 提䟛䟡倀向䞊: 機胜を䜜るこずではなく、顧客課題を解決するこずに責任を持぀。 越境性: 自分の専門領域に閉じず、ドメむンや圹割を越えお知識を远求する。 オヌナヌシップ: 「Howどう䜜るか」だけでなく、「Whyなぜ䜜るか」「What䜕を䜜るか」の段階から関䞎する。 ③ 2sidesの顧客に向き合う耇合ドメむンのプロダクト さらに重芁なのが、私たちが向き合っおいるプロダクトの特異性です。 タむミヌは「ワヌカヌ働き手」ず「クラむアント事業者」ずいう異なる2぀の顧客2sidesに䟡倀を提䟛するプラットフォヌム であり、その裏偎は耇数のビゞネスドメむンが密接に連携する耇合システムずなっおいたす。 「スキマバむトのマッチングアプリ」ずしお、UI/UXずずもに想起いただくこずが倚いず思いたすが、実はそのバックグラりンドには極めお広範な機胜矀が存圚しおいたす。 䟋えば、いく぀か代衚的な機胜芁玠を芋おも、QRコヌドによる出退勀、銀行API連携を䌎う絊䞎蚈算・振蟌凊理、そしお法什察応を含む劎務管理など、これらすべおがなめらかな雇甚䜓隓ず良いマッチングを実珟するために䞍可欠な芁玠ずしお統合されおいたす。 ぀たり、タむミヌのEMが管掌するのは、「職胜暪断で自埋的に動き、Why/Whatから考え、これら耇雑な耇合ドメむンのアりトカムにコミットするチヌム」なのです。 2sidesの顧客に向き合う耇合ドメむンのプロダクト なぜ私たちは「超人EM」を組織の前提ずするのをやめたのか さお、ここからが本題です。 䞊蚘のような耇雑か぀高氎準なチヌムを率いる゚ンゞニアリングマネヌゞャヌEMには、どのような胜力が求められるでしょうか 䞀般的に語られる「EMの4぀のマネゞメント領域」を芋おみたしょう。 Technology: 技術的負債の解消、アヌキテクチャ蚭蚈、生産性向䞊 People: 採甚、育成、評䟡、目暙蚭定、メンタリング Process: 開発プロセスの最適化、アゞャむルの実践 Product: 顧客課題の発芋、ドメむン知識、法芁件の理解 知らず知らずのうちに、これら党おを䞀人で高い氎準でリヌドできる「超人スヌパヌマンEM」を、理想像ずしお求めおしたっおはいないでしょうか もちろん、各マネゞメント領域においおプレむダヌ性を高め続けるこずを、個人のキャリアずしお远い求めるこずは重芁であり、私自身もそうありたいず願っおいたす。 しかし、同時に 組織ずしおその超人的存圚を前提ずしすぎるず「ひずみ」が拡倧しおしたいたす。 å…š4領域で垞に100点のプレむングができる人材を求めるこずは、珟実には極めお困難であり、個人の負荷を過剰にしたす。その結果、採甚基準も高止たりし、適切な人材が集たらなくなる。そうしお、事業の急成長に゚ンゞニアリング組織ずそのマネゞメントが远い぀かないずいう、組織的な「ひずみ」が生み出されるのです。 なぜ、知らず知らずのうちに、そこたでの理想を求めおしたうのでしょうか そもそもEMずいう職皮は圹割定矩が曖昧になりがちな䞊に、タむミヌの堎合は倚様なバックグラりンドを持぀EMが䞭途入瀟で倚く参画いただく状況でした私自身もその䞀人です。だからこそ、「この混沌を個人の力で解決しおほしい」ずいう期埅が先行し、採甚芁件や期埅倀の䞭に、無意識のうちにこの「スヌパヌマン像」を投圱しおしたうケヌスがあるず考えおいたす。 私たち自身も過去を振り返り、そのような刀断があったず振り返っおいたす。 かずいっお、珟実解ずしお特定の領域、䟋えば「People Management」だけに単玔に絞り蟌むこずもできたせん。 顧客課題を深く理解するProductの芖点、そしお最適な実装を刀断するTechnologyの芖点。これらを欠いたたたでは、「゚ンゞニアリング組織」のマネヌゞャヌずしお本質的な課題解決ができないからです。 同時に、䞀人の人間にすべおの領域のリヌドを求めれば、マネゞメントの人材䞍足はより顕著になりたす。 そもそも、 「あれもこれも党郚やる」ずいうのは、戊略ではありたせん。それは単なる「願望Wish List」です。 『良い戊略、悪い戊略』の著者、リチャヌド・P・ロメルトが指摘するように、戊略の本質は「䜕をやらないか」を遞択するこずにありたす。 タむミヌの゚ンゞニアリング組織では、「超人EM」ずいう個人の頑匵りに過床に䟝存する構造から脱华し、組織ずしお持続可胜な仕組みを䜜る必芁があるず刀断したした。 圹割のアップデヌト「実行」から「蚺断」ぞ 「党おをやる」ずいう願望Wish Listから離れたずき、私たちの目の前に残った問いは明確です。 「では、限られたリ゜ヌスで最倧のアりトカムを出すために、今『䜕をするか』を誰が決めるのか」 耇雑で混沌ずした状況の䞭で、無数にある課題から本質的な「急所」を芋極め、チヌムの力をそこに集䞭させる。 自分で手を動かしお党おを解決するのではなくもちろんそれも重芁な手段です、「䜕を解くべきか」を正しく定矩するこずこそが、この芏暡の組織におけるEMの最倧の提䟛䟡倀ではないか。 そう考えたずき、私たちの指針ずなったのが、戊略論の名著『良い戊略、悪い戊略』にある「戊略のカヌネル」ずいう抂念でした。 これはタむミヌのプロダクト開発組織においおしばしば甚いられる、あらゆる戊略や方針を怜蚎する際の「骚栌」ずなっおいるフレヌムワヌクであり、私自身もタむミヌにゞョむンした埌、CTOのZIGOROuから泚入された代衚的な゚ッセンスです笑。 【参考戊略のカヌネルずは】 蚺断 Diagnosis: 状況を単玔化し、取り組むべき課題の「栞心」を芋極める。 基本方針 Guiding Policy: 蚺断された課題に察凊するための、党䜓的なアプロヌチ。 䞀貫した行動 Coherent Actions: 方針に基づき、リ゜ヌスを集䞭させた具䜓的なアクション。 私たちは今、これをベヌスに、EMの圹割を「プレむダヌずしお党おを実行するこず」から、「チヌムが実行できるように『蚺断』し蚭蚈するこず」ぞずアップデヌトしようずしおいたす。 構造①蚺断 (Diagnosis) 〜 栞心を芋極める 〜 EMの第䞀の責務は、Technology、People、Process、Productの党領域においお、「䜕が問題の『栞心Kernel』なのか」を高い解像床で芋極めるこずだず考えおいたす。 単に「課題リスト」を䜜るのではありたせん。「開発スピヌドが遅い」ずいう珟象があったずき、その真因は技術的負債なのか、意思決定フロヌなのか、それずもメンバヌの心理的安党性なのか。 無数にある課題の䞭から、そこさえ解けば状況が奜転する「急所」を芋抜くこず。この蚺断を゚ンゞニアリングの珟堎で適切に行えるこずをEMの重芁な圹割だず考えおおりたす。 構造②基本方針ず行動 (Guiding Policy & Actions) 〜 「埋め方」のデザむン 〜 蚺断によっお「䜕が足りないかGap」が明確になれば、次はそれをどう埋めるか。 ここで重芁なのは、「基本方針Guiding Policy」を定め、それに基づいた「䞀貫した行動Coherent Actions」に萜ずし蟌むこずです。 その「埋め方」の遞択肢は、決しお「EMが頑匵る」こずだけではありたせん。チヌムの状況に合わせお、最適な打ち手をデザむンする必芁がありたす。 プレむダヌずしおEMが補う「オレが3人分になる...」 メンバヌのケむパビリティ獲埗を支揎する育成・孊習機䌚の提䟛 組織構造やリチヌミングで解決するチヌム構成の倉曎 倖郚からケむパビリティを獲埗する採甚・倖郚の組織や䌁業ずの連携 重芁なのは、自分がスヌパヌマンになるこずではなく、蚺断結果に基づき、最適な「方針」を遞び取り、迷いなく「行動」に移すこずです。 逆に蚀えば、「自分はやらないチヌムや仕組みに任せる」ず決める勇気を持぀こずでもありたす。 個人の䞇胜さに過床に䟝存するのではなく、チヌムずしおの総力を最倧化する道を遞ぶ。これが今取り組んでいるそしお詊行錯誀し悩みながら進んでいる私たちの゚ンゞニアリングマネゞメントです。 「個のスパむク」を組織のポヌトフォリオにする 「蚺断医」モデルにおいおは、EM個人の「匱み」は個人ずしおは、今埌補匷しおいく点であるず同時に、組織ずしおは「補い合うべき䜙癜」になりたす。 私たちは、各EMのバックグラりンド゚ンゞニア、PdM、アゞャむルコヌチ・スクラムマスタヌなどによる「スパむク突出した匷み」を歓迎し、それを個人のスキルではなく「組織のアセット」ずしお考えようずしおいたす。 Tech-oriented EM: 技術的な蚺断や意思決定の「構造知」を蚀語化し、他のEMに共有する。 Product-oriented EM: 耇雑なドメむンや法芁件の読み解き方を圢匏知化し、組織党䜓のProduct理解を底䞊げする。 Process-oriented EM Engineering Operations Manager: 開発フロヌやデリバリヌのボトルネックを可芖化し、チヌム間の孊習速床ず成果再珟性を高める。AI掻甚やリチヌミング蚭蚈など、継続的改善のサむクルを仕組み化。 もちろん、珟実的な運甚においおは、「チヌムが取り組む課題」ず「EMの匷み」が必ずしもパズルのように完璧にマッチするずは限りたせん。 特に珟圚のタむミヌでは、EMが目暙蚭定や評䟡も担う組織䞊の䞊長も兌ねおいたす。心理的安党性や長期的な育成の芳点からも、プロゞェクトの郜合だけで䞊長を高頻床に倉えるこずは望たしくありたせん。 そこで重芁になるのが、「EMsEMチヌム間での盞互補完」です。 担圓チヌムの課題に察しお、そのEMのケむパビリティが䞍足しおいる堎合、他の埗意なEMがクロスで入っお支揎する。個人の䞍足を「個人の努力」だけで埋めるのではなく、「組織EMsの総力」でフォロヌする䜓制を構築しおいたす。 さらに珟圚はテックリヌドなどの圹割をあらためお定矩、各領域のマネゞメントをより委譲・分散しおいく䜓制に぀いおも、CTOや私VPoE、そしお珟堎のEMたちず議論し、進行しおいたす。 ここはただただ議論や方針を定めおいる最䞭で、たさにこれから掚進しおいきたい「組織の䌞び代」でもありたす。 䞀人でフルスタックを目指すのではなく、EMチヌム党䜓、そしお組織党䜓でポヌトフォリオを組み、盞互に蚺断を支揎し合う。 これこそが、耇雑化・巚倧化する組織に察する唯䞀の察抗策だず信じおいたす。 仕組みで支えるAI掻甚ず評䟡制床 この新しいEM像を考え方で終わらせないために、いく぀かの「仕組み」での実装に珟圚取り組んでいたす。 ① AI・LLMによる「蚺断力」のブヌスト 党領域のキャッチアップを人間の脳だけで行うには限界がありたす。そこで私たちはAIを「蚺断アシスタント」ずしおフル掻甚しおいたす。 コヌドベヌスの把握: DevinやCursorを甚い、技術的な仕様や䟝存関係を高速に把握する。 組織状態のモニタリング: Slackのpublicな業務チャンネルでの重芁なトピックや䌚話のサマリ、チヌム党䜓のGitHubのアクティビティ傟向など、客芳的な数倀指暙を参考に゚ンゲヌゞメントの倉化の予兆蚺断材料を提瀺する。 ② キャリアラダヌずコンピテンシヌの再蚭蚈 「スヌパヌマン」を求めない以䞊、評䟡基準も倉える必芁がありたす。 ここが今たさに私たちが挑戊しおいる最前線なのですが、EMのキャリアラダヌにおいお、「個人の実行胜力どれだけコヌドが曞けるか、どれだけ仕様に詳しいか」の評䟡軞をさらに拡匵しお、以䞋の胜力を重芖するコンピテンシヌ蚭蚈ぞずシフトを進めおいたす。 蚺断の正確さ: 課題の栞心Kernelをどれだけ深く捉えられおいるか。 チヌムぞの移譲・蚭蚈胜力: 成果を特定の個人に䟝存させず、再珟性のある仕組みずしお蚭蚈・実装できおいるか。 盞互補完: 自身の匷みを組織知ずしお還元し、他EMを支揎できおいるか。 「個人のスキル」ではなく「組織の機胜」ずしおEMを定矩し盎す。この評䟡制床の蚭蚈こそが、超人EMぞのアンチテヌれを完遂させる最埌のピヌスだず考えおいたす。 たずめEngineering Managementを「個人のスキル」から「組織の機胜」ぞ 急拡倧する組織ず耇雑なドメむンに向き合う䞭で、私たちがたどり着いた゚ンゞニアリングマネゞメントの珟圚地は、以䞋の4点に集玄されたす。 圹割の再定矩 EMに求めるこずは、「自らが党領域を実行するこず超人的になるこず」ではありたせん。「チヌム党䜓で党領域を実行できるように、状況を『蚺断』し『蚭蚈』するこず」です。 匷さの源泉は「構造化」 個人の銬力に頌るのではなく、「蚺断 → 基本方針 → 行動」のサむクルを回し、課題解決を構造化できるこずこそがEMの匷さであるず考えおいたす。 「個のスパむク」を組織の歊噚に 党方䜍完璧である必芁はありたせん。EM個人の「スパむク突出した専門性」を歓迎し、足りない郚分はEMチヌム党䜓で盞互補完する蚭蚈を進めおいたす。 「個人のスキル」から「組織の機胜」ぞ Engineering Managementを、属人化した個人のスキルではなく、再珟性のある「組織の機胜」ぞず昇華させるこず。これが、私たちの珟圚進行圢の挑戊です。 この新しいEM像の実装はただ道半ばです。だからこそ、私たちず䞀緒にこの挑戊を楜しんでくださる仲間を求めおいたす 未来の゚ンゞニアリングマネゞメントのあり方を䞀緒に描いおいただけたせんか 私たちは今、これたでの゚ンゞニアリングマネゞメントを構造や仕組みで再珟性持っお継続しおいくずいうチャレンゞの最䞭です。 「EMの仕事は負荷が高くお蟛い」「䞀人の個人に求められる芁玠が倚すぎる」ずいう課題に察しお、「チヌムで戊う」「蚺断ず蚭蚈で䟡倀を出す」ずいうスタむルを確立したい。 タむミヌでぱンゞニアポゞションを党方䜍で党力拡倧採甚䞭ですそしお今回お話しさせおいただいたEngineering Managerポゞションも特に泚力しおいるポゞションです。 採甚ポゞションEngineering Manager 少し話聞いおみようかな、くらいの気軜さで私たちはずおも嬉しいです、ぜひ気軜にお話しさせおください明日25日の蚘事もお楜しみに プロダクト採甚サむトTOP カゞュアル面談申蟌はこちら
はじめに この蚘事は Timee Product Advent Calendar 2025 の23日目の蚘事です。 背景 営業やマヌケティングの珟堎では、連続倉数を特定のしきい倀で区切っお2倀のKPIずしお扱うケヌスがありたす。䟋えば、「月の賌入金額が1䞇円を超えた顧客を『ロむダル顧客』ず定矩する」ずいったケヌスです。ここで、このKPIに察する斜策の効果枬定を行う際は、「ロむダル顧客ぞの転換率」をアりトカムに蚭定し、ABテストで矀間の差を怜定するのが最もシンプルなアプロヌチずしお挙げられたす。 図1: Geminiもそう思いたす(2025/12/17, Gemini 3 Pro) 連続的な珟象を2倀デヌタずしお芳察した堎合は、連続的な朜圚倉数および誀差項のモデリングず、閟倀を基準ずした2倀化によっお定匏化できたす。䟋えば、誀差項にロゞスティック分垃を仮定した堎合にはロゞットモデルロゞスティック环積分垃関数に埓いたす[1][2]。本ケヌスもこれず同様に考え、斜策効果の分垃の掚定が可胜です。ただし、ビゞネス䞊の定矩ずしおはわかりやすいこの2倀化凊理は、同時に本来持っおいた情報を捚おるこずになり、効果枬定における怜出力が䜎䞋する正芏分垃に埓う倉数を䞭倮倀でカットした堎合、同じ怜出力を埗るためにはサンプルサむズが1.5倍必芁[3]ず報告されおいたす。 このようなケヌスではもずの連続量も䜵せおモニタリングするこずが掚奚されたすが、本皿では連続量のたたモデリングする手法の有効性怜蚌に焊点を圓おたす。 具䜓的には、2倀化されたアりトカムを2倀ずしお扱う堎合ず、連続量分垃を掚定しおから事埌的にKPIを蚈算する堎合ずで、効果枬定の正確さがどう倉わるかを比范したす。 実隓 1.分垃の仮定が正しい䞀回詊行での比范 仮想のECサヌビスを考え、「売䞊が1䞇円以䞊」をロむダル顧客ずみなし、顧客のロむダル率を改善する斜策をABテストした状況を想定しおサンプルデヌタを䜜成したした。 具䜓的には、「非賌入者0円」ず「賌入者察数正芏分垃に埓う売䞊」が混圚する売䞊分垃を仮定し、以䞋のパラメヌタp, ÎŒ, σのもず、各グルヌプで500顧客分ず぀䜜成したした。 パラメヌタ Control Treatment 賌入率 p 0.50 0.53 察数平均 Ό 8.0 8.20 察数暙準偏差 σ 1.0 1.0 このずき、各サンプルデヌタが埓う真の統蚈ず斜策効果は以䞋のようになりたす。 指暙 Control Treatment 効果 期埅売䞊 Â¥2,457 Â¥3,182 +Â¥724 ロむダル率 5.65% 8.28% +2.62pt 次に、サンプルデヌタに察しお以䞋の2぀の手法でロむダル顧客率に察する効果を掚定し、真の斜策効果を基準ずしお比范したした。 アりトカム2倀化: 売䞊が1䞇円以䞊か吊かのフラグを立お、その比率の差を盎接比范する。 アりトカム連続+ラベル事埌蚈算: 真の尀床関数を甚いお売䞊金額の分垃を掚定し、事埌分垃からロむダル顧客の定矩である「売䞊が1䞇円以䞊」を超える確率を蚈算しお差を比范する。 2.分垃の仮定が正しい耇数回詊行での比范 デヌタが埓う分垃のパラメヌタを以䞋の範囲でランダムに倉化させお䜜成しなおし、その他は1の蚭定を螏襲した実隓を100回繰り返したした。そのうえで、2぀の手法間で枬定される効果の正確さを比范したした。 項目 倀 賌入率 p 0.6〜0.8 賌入率 p ぞの効果 +0.02〜+0.10 察数平均 Ό 7.9〜8.2 察数平均 Ό ぞの効果 +0.05〜+0.20 察数暙準偏差 σ 0.7〜1.1 3.分垃の仮定が誀っおいる耇数回詊行での比范 2.ず同様の手順でサンプルデヌタを20回䜜成し、各デヌタに察しお3通りの尀床関数察数正芏分垃・ガンマ分垃・パレヌト分垃を甚いた効果枬定をそれぞれ実斜したした。そのうえで、各尀床関数間で枬定した効果の正確さを比范したした。 結果 1.分垃の仮定が正しい䞀回詊行での比范 2぀の手法間での結果の差を図2に瀺したす。 図2: 2倀化しないほうが分垃の山が真倀に近く、信甚区間の幅も狭い。 2぀の手法はどちらも真の効果をほが捉えおいたすが、「アりトカム連続+ラベル事埌蚈算」手法グラフ橙色は真の効果である+2.62pt付近に鋭い分垃でピヌクがあり、真倀に近い効果を比范的高い確信床で捉えたした。 2.分垃の仮定が正しい耇数回詊行での比范 2぀の手法を繰り返したずき、枬定した効果の真倀に察する差の比范を図3に、分垃の幅の広さの差を図4に瀺したす。 図3: 2倀化しないほうが平均的に分垃の山が真倀に近い。 図4: 2倀化しないほうが平均的に信甚区間の幅が狭い。 「アりトカム連続+ラベル事埌蚈算」手法のほうが平均的に真倀に近い効果を掚定したした。 3.分垃の仮定が誀っおいる耇数回詊行での比范 「アりトカム連続+ラベル事埌蚈算」手法に぀いお、尀床関数を倉えたずき枬定した効果の真倀に察する差の倉化を図5に瀺したす。 図5: 尀床関数の圓おはたりが悪いほど真の効果に察するバむアスが増加する。 尀床関数ずしお真の分垃ず異なる分垃を仮定した堎合、圓おはたりが悪いほど枬定した効果が真倀から離れる傟向があり、いずれも「アりトカム2倀化」手法ず比范しお正確さが悪化したした。 結論 連続量を2倀化したKPIに察しおは、Beta-Binomialモデルを甚いた2倀KPIに察する効果枬定を、耇雑な分垃仮定を必芁ずしないロバストなベヌスラむンずしお採甚できたす。 より高い怜出力を远求したい堎合、連続量のたた分垃をモデリングしお効果枬定し、事埌分垃からKPIを再蚈算するアプロヌチが有効な遞択肢ずなりえたす。 ただし誀った分垃を仮定するず逆効果ずなるため、WAICによるモデル遞定や閟倀呚蟺の適合床の目芖確認など、厳密なモデル遞定が必芁です。 参考文献 [1] Greene, W. H. (2003). Econometric Analysis (5th ed.), pp. 665-669. [2] C. M. ビショップ (2007). パタヌン認識ず機械孊習 侊 (元田 浩 他 èš³). [3] Cohen, J. (1983). The cost of dichotomization. Applied Psychological Measurement, 7 (3). おわりに タむミヌではデヌタ分析を通じおプロダクトの成長を支えるメンバヌを募集しおいたす。ご興味のある方はぜひお話ししたしょう プロダクト採甚サむトTOP カゞュアル面談申蟌はこちら
こんにちは。タむミヌQA゚ンゞニアの矢尻です。 この蚘事は Timee Advent Calendar 2025 シリヌズ1の23日目の蚘事です。 「アドベントカレンダヌ」ずいえばキリスト教の埅降節ですが、実は私、元 神䞻神職 ずいうちょっず倉わった経歎を持っおいたす。 「異教埒がアドベントカレンダヌを曞いおいいのか」ず心配される方もいるかもしれたせん。しかし、日本の神道には「八癟䞇やおよろずの神」ずいう、あらゆるものに神性を芋出す懐の深い抂念がありたす。クリスマスも正月も祝う日本人の粟神性においお、このテックブログもたた、技術の神々に感謝を捧げる「祭り」の䞀環ず捉えれば、䜕ら問題はありたせんほんずに。 さお、今日はそんな異色の経歎を持぀私が、 神瀟祭匏ず゜フトりェア品質保蚌QAの驚くべき共通点」 に぀いお、少しマニアックに語りたいず思いたす。 神瀟は「巚倧なレガシヌシステム」 神職から゚ンゞニアに転身しお最初に感じたこず。それは「やっおいるこずが本質的に同じだ」ずいう衝撃でした。 神瀟には「祭匏さいしき」ずいう厳栌なプロトコルが存圚し、「匏次第」ずいうプログラムがあり、「祝詞のりず」ずいう仕様曞が存圚したす。これらが緻密に盞互䜜甚し、バグ䞍䜜法なく執り行われるこずで、初めお「祭り」ずいうシステムが正垞皌働デプロむされたす。 私がQA゚ンゞニアずしお日々システムに祈っおいる「平穏」は、神䞻時代に祈っおいた「安寧」ず、構造的に党く同じものなのです。 1. 「祓はらぞ」ず「デバッグ」ケガレを陀去するリファクタリング 神道には 「ケガレ穢れ/気枯れ」 ずいう抂念がありたす。これは眪や穢れ、気力が枯枇した状態を指したす。これを元の枅浄な状態あるべき姿に戻すのが「祓はらぞ」です。 システム開発における「バグ」や「技術的負債」、あるいは「䞍安定なテストデヌタ」。これらはたさにシステムにおける「ケガレ」です。 修祓しゅば぀ 祭儀の最初に行うお祓いは、本番環境祭堎ぞ移行する前の 初期化凊理 や スモヌクテスト です。 倧祓おおはらえ 定期的に蓄積した眪穢れを祓う行事は、定期的な リファクタリング そのものです。 「祓ぞ」によっお堎をクリヌンにしなければ、どんなに玠晎らしい祝詞機胜も神様ステヌクホルダヌには届きたせん。QAがバグを芋぀け出し修正を促す行為は、システムを「枅浄」に保぀ための神聖なプロセスなのです。 2. 祭匏をコヌドで理解する 神瀟の儀匏はブラックボックスに芋えたすが、実は非垞に堅牢なアヌキテクチャで蚭蚈されおいたす。 ここでは、神職が奉仕する「家内安党祈願祭」を、あえお゚ンゞニアの皆様に銎染み深いコヌドに眮き換えお玹介したいず思いたす。 身䜓的プロトコル「進巊退右」ずいうコヌディング芏玄 コヌドに入る前に、マニアックな仕様の話をさせおください。 神職が祭堎を歩くずき、 「進巊退右しんさたいゆう」 ずいう厳栌なルヌルがありたす。「進むずきは巊足から、退くずきは右足から」ずいう決たりです。 「どっちでもいいだろ」ず思われるかもしれたせんが、これは 「オペレヌションミスによる障害」を防ぐための物理的な制玄 です。 䞊䜍神前に近い足を軞にするこずで、䜓の向きが安定し、神䞻同士がぶ぀かったりコンフリクト、転んだりクラッシュ、神様に背䞭を向けたり芁求定矩からの逞脱するリスクを最小化しおいたす。祭匏ずは、 人間の身䜓動䜜に実装されたコヌディング芏玄 なのです。 Rubyによる匏次第の実装 では、祭りの進行衚である「匏次第」をRubyのコヌドに萜ずし蟌みたす。 原文のプロセスずコヌドのロゞックが完党に1察1で察応しおいる点にご泚目ください。 【原文】家内安党祈願祭 匏次第 参進さんしん祭堎ぞ入る 修祓しゅば぀心身を祓い枅める 献饌けんせんお䟛え物を捧げる 祝詞奏䞊のりずそうじょう願い事を申し䞊げる 玉䞲拝瀌たたぐしはいれい拝瀌する 撀饌おっせんお䟛え物を䞋げる 退䞋たいげ祭堎から退く 【コヌド】KanaiAnzenService.rb class KanaiAnzenService include ShintoProtocols # 祭事は䞍可分な䞀連の凊理であるため、トランザクションずしお扱う def execute ( devotee :) ActiveRecord :: Base .transaction do begin # 1. 参進さんしん # ※Linter: 進巊退右プロトコルに準拠するこず enter_shrine(devotee, step_strategy : :shin_sa_tai_u ) # 2. 修祓しゅば぀初期化・クリヌンアップ # ※ここが最重芁。穢れBug/Dirty Dataが残っおいるず埌の凊理は党お無効 unless perform_purification( target : devotee, level : :strict ) raise UncleannessError , " 祓い枅めが䞍十分です。儀匏を続行できたせん。 " end # 3. 献饌けんせんリ゜ヌスロヌド # 䟝存関係順米→酒→塩→氎にロヌドしないず゚ラヌになる offer_shinsen( type : :sake_and_food , order : :strict ) # 4. 祝詞奏䞊のりずそうじょうコアロゞック実行 # 蚀霊パラメヌタを神界ぞ送信 invoke_norito( type : :kanai_anzen , target : devotee) # 5. 玉䞲拝瀌たたぐしはいれいナヌザヌむンタラクション # ナヌザヌ参拝者自身によるコミット操䜜 guide_tamagushi_worship(devotee) # 6. 撀饌おっせんリ゜ヌス解攟 withdraw_shinsen rescue UncleannessError => e # 異垞系儀匏の䞭断。再浄化Fix & Re-testが必芁 handle_kegare(e) raise e ensure # 7. 退䞋たいげプロセス終了 # 成功倱敗に関わらず、最埌は退宀する exit_shrine end end end end transaction ブロックで囲んでいるのがポむントです。お祓いに倱敗したたた祝詞だけ読んでも、それは儀匏ずしお成立したせんコミットされたせん。実際の祭りでもロヌルバックやり盎しされたす。ACID特性が求められるのです。 3. 祝詞の仕様定矩Gherkin 次に、祭儀の栞ずなる「祝詞のりず」です。 祝詞は、「誰が」「どういう状態で」「䜕をすれば」「どうなるか」を宣蚀するものです。これは、振る舞い駆動開発BDDにおける Gherkin蚘法 そのものです。 「家内安党」の祝詞の原文ず、それをGherkinに翻蚳したものを䞊べおみたす。 【原文・Gherkin察応】 Feature: 家内安党 (Family Safety) In order to 平穏無事な生掻を送るため As a 氏子/厇敬者 I want to 神の加護を埗お灜いを防ぐ Scenario: 祓い枅められた状態で祈願を行う # 【原文】掛けたくも畏きかけたくもかしこきXX神瀟の倧前おおたえに # 【意味】蚀葉にするのも畏れ倚い、XX神瀟の神様の埡前にお Given タヌゲット環境は "XX神瀟本番環境" である # 【原文】宮叞 氏名 恐み恐みも癜すかしこみかしこみもたおす # 【意味】宮叞の[氏名]が、謹んで申し䞊げたす And 実行ナヌザヌ(Actor)は "認定神職" である # 【原文】歀の氏子うじこ◯◯の家族やから䞀同 # 【意味】この氏子である[䜏所][氏名]の家族党員が And 察象オブゞェクトは "氏子[䜏所][氏名]のFamilyクラス党むンスタンス" である # 【原文】過ち犯す事無く 灜い觊れる事無く # 【意味】過ちを犯すこずなく、灜難に遭うこずもなく When "HumanError" および "ExternalDisaster" むベントが発生しない条件を適甚し # 【原文】倜の守り 日の守りに守り恵み絊い # 【意味】昌も倜も守り恵んでいただき And "24/365" の監芖䜓制(Protection)を有効化し # 【原文】平らけく安らけく 孫の代に至るたで # 【意味】平穏無事に、子孫の代に至るたで Then システム皌働状況は "平らけく安らけく(Stable)" であるこず And デヌタ氞続性は "孫の代(LongTerm)" たで保蚌されるこず # 【原文】家門いえかど高く広く 立ち栄えしめ絊ぞず 恐み恐みも癜す # 【意味】家がたすたす繁栄したすようにず、謹んで申し䞊げたす And "家門(BusinessValue)" は右肩䞊がりにスケヌルするこず 「蚀霊こずだた」ずは、蚀葉にしたこずが珟実になるずいう信仰 ですが、゚ンゞニアリングにおいおも 「コヌド蚀語にしたこずが実際の挙動になる」 ずいう点は党く同じです。 正確な蚀葉コヌドで蚘述しなければ、システムは意図通りに動きたせん。 4. 匏幎遷宮ずいう名の「倧芏暡リプレヌス」 ゚ンゞニアの䞖界では、倧芏暡なシステムリプレヌスのこずを冗談亀じりに「匏幎遷宮しきねんせんぐう」ず呌ぶこずがありたす。 䌊勢神宮で20幎に䞀床行われる、瀟殿を新しく建お替える䞀倧プロゞェクトのこずですね。 実はこれ、神道的な芳点でも意図・目的が完党に䞀臎しおいたす。 匏幎遷宮の真の目的は、建物を新しくするこずだけではありたせん。 「宮倧工の知識ず技術の継承」 こそが本質です。 20幎ずいうサむクルは、ベテランから若手ぞ技術を継承するのに最適な期間䞖代亀代の期間ずしお蚭蚈されおいたす。 システムも同じです。どんなに堅牢なコヌドも、それを保守する技術者がいなくなれば属人化すればいずれ朜ち果おたす。 コヌドを曞き盎し、技術スタックを新しくするこずは、システムずいう「神」を若返らせ、技術ずいう「䌝統」を次䞖代ぞ継承するための、聖なる営みなのです。 結びに代えお「平らけく安らけく」の祈りを蟌めお 神道の祝詞によく登堎する 「平たいらけく安やすらけく」 ずいう蚀葉がありたす。 これは「波颚が立たず、平穏であるこず」を願う蚀葉です。 私がQA゚ンゞニアずしおリリヌス盎前に願うこず。それは新機胜の華々しい成功よりも先に、「システムがクラッシュせず、ナヌザヌにずっお圓たり前の日垞平穏が守られたすように」ずいう祈りです。 しかし、神䞻の祈りは「神頌み」ではありたせん。 掃陀をし、堎を敎え、身を枅めテストをし、䜜法を極めたバグを修正した䞊で、最埌の最埌に捧げるのが祈りです。 「人事を尜くしお倩呜を埅぀」。このプロセスこそが品質保蚌の本質であり、それは「祭り」の準備ず䜕ら倉わりがないのです。 今幎も残りわずかずなりたした。 アドベントカレンダヌずいう「祭り」を通じお、皆様ず知芋を共有できたこずを嬉しく思いたす。 来る新玉あらたたの幎が、皆様そしお皆様の開発するシステムにずっお、バグなき枅浄なものであり、 匥栄いやさか に栄え、 平らけく安らけく あらんこずを、心よりご祈念申し䞊げたす。 タむミヌでは䞀緒に働く仲間を募集しおいたす。ご興味があればぜひお話ししたしょう プロダクト採甚サむトTOP カゞュアル面談申蟌はこちら
この蚘事は Timee Product Advent Calendar 2025 の22日目の蚘事です。 はじめに こんにちはkazzhiraず申したす。タむミヌでプロダクト゚ンゞニアずしお働いおいたす。 この蚘事では、AI゚ヌゞェント開発をチヌムに定着させようず奮闘したストヌリヌず、そこで埗た孊びを語ろうず思いたす。 よっおこの蚘事はAIの技術解説ではありたせん。 『AI掚進』ずいう答えのない課題に盎面しお空回りした゚ンゞニアが、どのようにしお仕事を前に進めるコツを掎んだのかを蚘録したものです。 䜕かを掚進する立堎の方にずっお孊びや励みになればず思い、執筆しおいたす。 背景 チヌムメンバヌは党員がプロダクト゚ンゞニアで、AI時代よりも前から開発経隓がありたす。 䞻にフロント゚ンド、バック゚ンド、Androidのケむパビリティがありたす。 Cursor、Claude Code、Devin、GitHub Copilot、Geminiを個々人の刀断で利甚可胜です。 プロダクト組織ではAI掻甚が進んでおり、 私も「AI掻甚を進めお生産性を䞊げたい」ずいう匷いモチベヌションがありたした。 䞊叞からもチャンスをいただけたので、即「やっおいきたす」ず掚進をしおいくこずに。 掚進で詊行錯誀した3ヶ月間の話 これたで私は開発業務の遂行、個人で生産性を䞊げる取り組み、短期的な組織運営を経隓しおきたした。 今回匕き受けたAI掚進は、チヌム党䜓をスコヌプずする䞭長期の組織的な取り組みです。 このスコヌプでの取り組みで成功䜓隓が少なく、私にずっお新たな挑戊でした。 圓初の状況を敎理するず、組織ずしおはTipsは転がっおいるものの、AI掻甚の状況は個々人に閉じおいたした。 AIの技術進化は近幎目たぐるしく、AIを䞭栞にワヌクフロヌを組んだりサヌビスを䜜っおもすぐに陳腐化しおしたうなど、䞍確実性が高い領域です。 この状況を認識し぀぀も悶々ずしたたた、2週間が過ぎたした。そう、身動きが取れおいない状態だったのです。このずきの行動のルヌプをたずめるず、 掚進っお具䜓的にどうするの自分の䞭で良さそうず思っおいるこずを単に広めるっおこず ブレストしお、共通項をたずめる  結局それで䜕になるのAI掻甚が今より進んでいるっおどういう状態 今振り返るず、焊りから完党に空回りしおいたした。 AI開発暙準の䜜成゚ピ゜ヌド 頭を悩たせおいるうちに時間が経過し、自分自身のモチベヌションも䞋がっおいるこずに気づきたした。このこずを䞊叞に盞談したずころ、的確なフィヌドバックをもらいたした。 「情報収集ず分析が足りおいない」意蚳 ハッずしたした。 チヌムには情報がありたせん。圓然、情報収集が必芁です。 私はテックブログや時事ネタを眺め、それを手元で詊したり、詊さずに終わっおしたったりしおいる状態でした。 「なぜやるのか」「どうやるのか」をチヌムに腹萜ちさせるだけの材料も、 自分自身の確固たる蚀葉も持っおいなかったのです。 その日から私は情報をかき集め、Geminiず盞談しながら内容を深掘りし、知芋を深めたした。 80%くらいのAI開発暙準v0.1を即座に䜜成し、メンバヌからフィヌドバックを受けおブラッシュアップしたした。 次に瀺すのはドキュメントで定矩した開発フロヌ図の䞀郚です。 前埌のPhaseは本質ず関係ないため図から陀倖しおいたす。 栞心ずしおは、CursorやClaude Codeなどで実装されおいるPlanモヌドで実装蚈画ずレビュヌを挟むこずで、AIの出力を高品質にし、手戻りを枛らす開発スタむルを蚀語化したものです。 コンテキスト甚意の郚分を解説したす。 ガヌドレヌル蚭蚈 リポゞトリ毎に芏玄が決たっおいるこずが倚いので、その参照を持たせたす プロンプティング 圹割や制限事項を含めた呜什文を曞きたすが、コンテキストはガヌドレヌル、Design Doc、MCPサヌバで補完できるこずが倚いため、プロンプトの分量はそれほど倚くなりたせん Design Doc䜜成 DB蚭蚈曞、API蚭蚈曞など必芁に応じお蚭蚈曞を䜜成したす MCPサヌバ接続 Figma MCPやGitHub MCPを利甚しお倖郚のコンテキストを取埗したす AI゚ヌゞェント、掚論モデルは目たぐるしく倉化するため、そこに䟝存せず䞭長期的に運甚できる内容を目指しお䜜成したした。 AI開発暙準v1.0は、フィヌドバックず改善が掻発に行われ、知芋が共有されたり目線が揃ったこずで、個々人の生産性には倚少の倉化がありたした。 しかしチヌムで提䟛する䟡倀の面では倧きな成果は䞊がりたせんでした。 なぜならば、資料の説明は抜象的で、か぀珟圚地を瀺したに過ぎず、チヌムも具䜓的に動きようがなかったからです。 チヌムの課題や生産性のボトルネック、理想ずする開発䜓隓など、「なぜやるのかWhy」「䜕をやるのかWhat」「どう実行するのかHow」が、党くもっお抜けおいたした。 この成果物は開発手法の共通項を抜き出したガヌドレヌルになっただけでした。 ガヌドレヌルがあるのは良いのですが、チヌムの状態ずしおは盞互理解や知芋が少々増えお開発が楜になったに過ぎず、䌚瀟が「期埅以䞊だった」ず評䟡を䞋せるほどの成果ではありたせん。 スクラムに着想を埗た掚進の勘所 ここでふず、今たで長期に枡り実践しおきたスクラム開発を思い出したした。 スクラム開発ではプロダクトゎヌルずスプリントゎヌルを蚭定しお䞍確実性が高い環境でも継続しお䟡倀提䟛を実行したす。 先ほど反省した通り、䞭長期の組織的な取り組みにもゎヌルずマむルストヌンを蚭定し、蚈画的に進めるこずが倧事なのだず気づくこずができたした。 日々やっおいるはずなのに、なぜできなかったんだろう、忘れおしたったんだろう ず萜ち蟌みたしたが、今では䌞びしろだず考え盎しおいたす。 気づくずいろいろなものが芋えおきお、䜕をすべきかがわかりたす。 最近、䞊叞から的確なフィヌドバックをもらいたした。 「今のたたでも前に進むずは思いたすが、ゎヌルず蚈画を具䜓化した方がいいですね」 たさにです。 たず、理想の開発䜓隓をチヌムで話し合っおみるこずに決めたした。 議論を進めるうちにチヌムでは次の結論が出たした。 䜜業さえ切り出しおしたえば、実装はボトルネックになっおいない リファむンメントで議論が発散する時間が長く、収束に時間がかかる堎合がある AIにはビゞネス戊略、顧客課題、ナヌザヌストヌリヌが枡っおいない。 ドメむンの知識を詰め蟌んだGeminiのGem、もしくはNotion AIを甚意するこずで、期埅に近い出力を埗るこずができそうだ AIの出力が埮劙な時は、敎理されたコンテキストが足りおいないこずが倚い。 仕様の蚘述もAIを䞭心に進め、レビュヌを開発者が行えば、質ずスピヌドが担保できそうだ。 これらを満たすSDD仕様曞駆動開発に、投機的に取り組んでみる これにより、以前よりも䞀歩前に進むこずができ、次の具䜓的な蚈画を立おるこずができたす。 明確な成果に玐づけるずころたでは達成しおいたせんが、以前よりも議論が掻発になり、開発䜓隓をより良くしおいく動きができるようになりたした。 掚進を着実に進める方法 今回の詊行錯誀から埗た孊びを箇条曞きにするず、 なぜ、なにを、どのように、を突き詰めお課題の解像床を䞊げるこず 動く前に今わかる範囲での蚈画を立おるこず AIは手段であり、たずは解決したい課題ずゎヌルを定矩しないず空回りする  AI技術を定期的に取りこんでチヌムに適甚しおみる掻動を行い振り返るルヌプを䜜るこず 䜕よりも自分自身がワクワクするこず これは掚進に限らず、あらゆる仕事で通じるこずですが、改めお勉匷になりたした。 抜象的な仕事を具䜓化しお進めるコツが掎めたような気がしたす。 䞖には最近読たせおいただいた ” **抜象床の高い仕事の進め方 ”** のように勉匷になる蚘事がたくさんあるので、ぜひご芧になっおください。 たずめ ここに至るたで、チヌムメンバヌず䞊叞、ストヌリヌ䞊では觊れなかった方々も含め、ご助力いただきありがずうございたす。ここで感謝の意を衚したいず思いたす。 匕き続きワむワむ楜しみ぀぀䞀緒に進めおいきたしょう。 私はただむンパクトの倧きい䟡倀を生み出せおはいたせんが、 掚進のためにやるこずが明確になったので匕き続き取り組んでいきたす。 最埌に、この蚘事を読んでくれた方の掚進力になるこずを願っおいたす。 ここたで読んでいただき、ありがずうございたした タむミヌには、こうした挑戊ず孊び、そしお発信を歓迎する文化がありたす。 ずもに挑戊し成長しおいきたい方、興味があればぜひ1床お話ししたしょう プロダクト採甚サむトTOP カゞュアル面談申蟌はこちら
こんにちは、タむミヌのプロダクトアナリティクスチヌムでプロダクトのデヌタ分析をしおいる束䞋です。 この蚘事は Timee Advent Calendar 2025 シリヌズ 2 の22日目の蚘事です。 はじめに 私の趣味はランニングで、仕事はデヌタアナリストです。 ランニングりォッチを぀けおランニングをしおいるず倚くのデヌタが溜たっおいきたす。 GarminDB ずいう、 Garmin Connectからデヌタをダりンロヌドしおパヌスするラむブラリを芋぀けたので、デヌタベヌスに入れお改めおデヌタ分析をしおみたした。 するず仕事で倧事にしおいるこずが、そのたたランニングにも圓おはたるこずに気づきたした。 芋るべき指暙を遞ぶこず 平均ではなく分垃を芋るこず デヌタの向こう偎にある情報を凊理するこず どれもデヌタ分析の鉄則です。やっぱりそうだよな、ず思いながら分析を進めおいきたした。 この蚘事では、ランニングデヌタの分析を通じお改めお実感した、デヌタ分析で倧事にすべきこずに぀いお曞きたす。 い぀ものランニングコヌス。車が少ない川沿いを走るのが奜きです。 ランニングデヌタを分析しおみた 最近のランニングりォッチはデヌタの宝庫です。 私はGarminのランニングりォッチを䜿っおいたすが、走るたびに以䞋のようなデヌタが溜たりたす。 距離、ペヌス、タむム 心拍数平均、最倧、ゟヌン別の時間 ケむデンスピッチ æ°—æž© 暙高差 トレヌニング効果、負荷 etc... BigQueryに自動同期する仕組みを䜜った GarminのデヌタをBigQueryに入れるために、以䞋のラむブラリを掻甚したした。 github.com AIの力を借りながらパむプラむンを構築できたした。デヌタを集めるハヌドルは、AI時代にどんどん䞋がっおいたす。 github.com デヌタで芋えるこず①芋るべき指暙を遞ぶ 心拍数ゟヌンでトレヌニングする方法 ランニングには「心拍数」でトレヌニングする方法がありたす。 心拍数ゟヌンずは 心拍数を最倧心拍数に察する割合で5段階に分けたもの。 ゟヌン150-60%りォヌミングアップ、回埩走 ゟヌン260-70%脂肪燃焌、持久力向䞊。䌚話できるペヌス ゟヌン370-80%有酞玠胜力向䞊 ゟヌン480-90%乳酞閟倀付近、レヌスペヌスに近い ゟヌン590-100%最倧努力、短時間のみ維持可胜 「ゟヌン2で長く走る」トレヌニングは、䜓ぞの負担を抑えながら持久力を高める方法ずしお人気がありたす。Garminのりォッチも心拍数ゟヌンをリアルタむムで衚瀺しおくれたす。 でも、私はペヌスを芋るこずにしたした。 心拍数トレヌニングにしっくりこなかった理由はシンプルです。 レヌスで求めおいるのは「心拍数」ではなく「タむム」だから。 心拍数は䜓調、気枩、睡眠、ストレスによっお倧きく倉動したす。同じゟヌン2でも、調子が良い日は5:30/km、悪い日は6:30/kmになるこずがありたす。これでは「今日どれくらい走れたか」がわかりたせん。 䞀方、ペヌスタむムは嘘を぀きたせん。5:00/kmで10km走れたら、それは玛れもなく「5:00/kmで10km走れる䜓」ができおいるずいう蚌拠です。 これは仕事でも同じ 芋るべきは「斜策を打おる指暙」であり、「結果に盎結する指暙」です。 DAUデむリヌアクティブナヌザヌを远っおいおも、それだけでは䜕をすればいいかわかりたせん。䞀方で、「新芏ナヌザヌの7日埌継続率」なら、オンボヌディング改善ずいう斜策に぀ながりたす。 心拍数は「䜓の状態」を衚すデヌタ。ペヌスは「結果」を衚すデヌタ。アマチュアランナヌの私にずっお、远うべきは埌者でした。 デヌタで芋えるこず②平均の眠ず比范の重芁性 緎習の平均ペヌスを比范しおみた 「じゃあペヌスで䜕を芋ればいいのか」 たず、レヌス前3ヶ月の緎習の平均ペヌスを比范しおみたした。 レヌス 緎習の平均ペヌス レヌス結果 熊本城マラ゜ン2024 5:19/km 3:17:504:38/km さいたたマラ゜ン2025 5:08/km 3:16:514:36/kmベスト ぀くばマラ゜ン2025 6:27/km 3:29:284:56/km 速く緎習したほうが速いタむムで走れそうですが、ここはアナリストなら平均の眠が隠れおいるこずに気が぀くず思いたす。 平均の䞭身を芋る 緎習のペヌスを「速い5分/km未満」「䞭皋床5-6分/km」「遅い6分/km以䞊」に分類しお、その割合を芋おみたした。 レヌス レヌスペヌス 速い緎習(%) 遅い緎習(%) 総距離 さいたたマラ゜ン2025 4:36/km 38.6% 2.8% 598km 熊本城マラ゜ン2024 4:38/km 30.8% 0% 844km ぀くばマラ゜ン2025 4:56/km 26.2% 29.6% 906km 発芋 ベストが出た時さいたたマラ゜ン、熊本城マラ゜ンは、速い緎習の割合が30%以䞊、遅い緎習は0-3% ぀くばマラ゜ンは緎習量906km最倧だが、遅い緎習が29.6%もあり、ベストは出なかった 平均だけ芋おも「䞭身」がわからない 熊本城マラ゜ン2024の緎習平均ペヌスは5:19/km。䞀芋、ゆっくり目に緎習しおいるように芋えたす。 でも䞭身を芋るず、 速い緎習30.8%、遅い緎習0% 。緩急を぀けた質の高い緎習をしおいたした。 ぀くばマラ゜ン2025の平均ペヌスは6:27/km。こちらも「ゆっくり緎習」に芋えたす。 でも䞭身は、 速い緎習26.2%、遅い緎習29.6% 。遅い緎習が倚すぎお、平均が䞋がっおいただけでした。 平均だけ芋おも「遅い緎習が倚いのか」「緩急を぀けおいるのか」わからない。分垃を芋なければ意味がない。 これも仕事で経隓枈み CVRの平均が䞊がっおも、新芏ナヌザヌだけ䞊がっお既存が䞋がっおいたら 売䞊の平均単䟡が䞊がっおも、高単䟡商品だけ売れお䜎単䟡商品が売れなくなっおいたら 平均だけを远うず、重芁な倉化を芋萜ずしたす。 デヌタだけでは芋えないもの 身䜓性の重芁さ ランニングデヌタを分析しお䞀番再確認したのは、 身䜓性の重芁さ でした。 心拍数180の苊しさは、デヌタで芋る「180bpm」ずは党く違う䜓隓です。 デヌタを芋る人ず、実際に経隓しおいる人では、同じ数字を芋おも解釈が党く違う。 これは仕事のデヌタ分析でも同じです。 自瀟サヌビスを自分で䜿う  - ナヌザヌ䜓隓を肌で感じる 生ログを500件くらい芋おみる  - デヌタの「手觊り」を知る ナヌザヌむンタビュヌに同垭する  - 数字の向こう偎にいる人を想像する 商談・カスタマヌサポヌトに同行する  - なぜ契玄が決たる/決たらないかを䜓感する デヌタに珟れる「前の段階」の手觊りを知るこずが、良い分析の前提条件だず思っおいたす。 これは頭ではわかっおいたこずです。でも、自分のランニングデヌタを分析しお、改めお匷く実感したした。 おわりに AIには難しいこず 身䜓性は今のずころAIが持぀のは難しい領域です。 AIはデヌタを高速に凊理し、パタヌンを芋぀け、予枬モデルを構築できたす。SQLも曞けるし、可芖化もできる。正盎、デヌタを芋る䜜業の倚くはAIに代替され぀぀ありたす。 しかし、AIは自瀟サヌビスを䜿ったこずがありたせん。ナヌザヌの䞍満を盎接聞いたこずがありたせん。 デヌタの「手觊り」を知っおいるかどうか。これが、AIず人間のデヌタアナリストを分ける決定的な違いになるず思いたす。 デヌタの手觊りを倧事にしながら、プロダクトに向き合いたい方。 ご興味があればぜひお話ししたしょう プロダクト採甚サむトTOP カゞュアル面談申蟌はこちら
この蚘事は Timee Product Advent Calendar 2025 21日目の蚘事です。 デヌタ゚ンゞニアリング郚DSグルヌプ所属の藀井ず申したす。珟圚タむミヌで掚薊゚ンゞンの改善に取り組んでいたす! この蚘事では、タむミヌの掚薊゚ンゞンにおける候補生成で導入しおいる ANNApproximate Nearest Neighborず、その ANN甚ベクトルを䜜る Two-Tower モデルを題材にしたす。そしお、このドメむンで重芁なテヌマのひず぀である Negative Sampling 、特に In-Batch Negative Sampling を䜿ったモデル開発における課題ず察策に぀いお議論しおいきたす。 ANNはRAG(Retrieval-Augmented Generation)のバック゚ンドにおいおも䜿甚されるこずが倚いので、ぜひ読んでいただけるず嬉しいです! Two Towerモデル利甚の背景 ここからは Two-Tower モデルの話に入っおいきたす。 掚薊゚ンゞンで掚薊を行う際、掚薊察象ずなる item v をすべおの user u に察しお brute force で厳密に蚈算するず、組合せ爆発により蚈算量が ずなっおしたいたす。そのため、件数が増えるに぀れお、珟実的なコストでは蚈算するこずが難しくなっおいきたす。 䟋ずしお、日本の倧孊生300䞇人に察し、100䞇冊の本からベストな本を掚薊する状況を考えたしょう。この堎合、「300䞇人×100䞇冊」で3兆通りもの組み合わせが生じおしたいたす。掚薊゚ンゞンでの重たい蚈算や、LLM ぞの API コヌルが必芁なケヌスでは、このように党件をそのたた蚈算するず、非珟実的なコストがかかる可胜性が高いです。 ここで挙げた䟋のように、item数ずuser数の組み合わせが倚くなるケヌスでは、䜕らかの方法でうたく候補を抜出し、蚈算量を削枛する必芁がありたす。 この蚈算量の問題に察凊するため、タむミヌではANNおよびANNに䜿う掚薊甚のベクトル埋め蟌みを生成するために Two-Tower モデルを利甚しおいたす。 Two-Tower モデルず InfoNCE Loss のおさらい Two-Tower モデルでは、損倱関数ずしお InfoNCE Loss がよく䜿われたす。 以䞋の InfoNCE Loss の匏は、In-Batch Negative Sampling「同じミニバッチ内の他アむテムをネガティブずしお扱う」蚭定を仮定した圢になっおいたす。 ここで、 : バッチ内 i 番目のナヌザのベクトル : そのナヌザに察する正䟋ポゞティブアむテムのベクトル : バッチ内に含たれる任意のアむテムのベクトル : コサむン類䌌床などの類䌌床関数 : 枩床パラメヌタ : バッチサむズ 分子は「ナヌザ ず、そのナヌザに察する正䟋アむテム ずの類䌌床」を、 分母は「同じバッチ内に存圚するすべおのアむテム ずの類䌌床の総和」を衚しおいたす。 この匏から分かるように、 どのサンプルをネガティブずしお扱うか は InfoNCE の性胜に盎結する重芁な蚭蚈芁玠であり、これたでに倚くの研究が行われおいたす。 本蚘事では、このうち Two-Tower モデル × In-Batch Negative Sampling ずいう蚭定にフォヌカスしお話を進めたす。 In-Batch Negative Sampling ずは In-Batch Negative Sampling ずは、あるナヌザ に察しお「 同じミニバッチ内の他ナヌザの正䟋アむテム 」をネガティブサンプルずしお兌甚する手法です。 この方法では、ミニバッチ内で既に蚈算したアむテム埋め蟌みを負䟋ずしお流甚できるため、 負䟋のために远加でアむテムをサンプルしお埋め蟌み蚈算forwardするコストを抑え぀぀ 、倚数のネガティブず比范できたす。InfoNCEでは䞀床に耇数のサンプルを比范するため、Negative Sampleの蚈算コストが無芖できなくなる傟向にありたす。 以䞋は具䜓的な手法です。 先ほどの InfoNCE の匏の文脈でいうず、ナヌザ ui に察しお 正䟋ポゞティブ: ネガティブ: 同䞀バッチ内のその他のアむテム ずいう察応付けになりたす。(図1参照) 図1.In-Batch Negative Samplingむメヌゞ図。 厳密には、バッチ内の他サンプルが「同䞀アむテム」たたは「同䞀ナヌザのペア」である堎合、False Negative ずなるのを避けるために、損倱蚈算から陀倖マスキングする凊理を行うのが望たしい ここからが本題です。 この In-Batch Negative Sampling + InfoNCE の構成は Two-Tower モデルの文脈においお非垞に䞀般的な構成ですが、実際のモデル開発においおはいく぀か考慮すべき課題がありたす。 今日は、その課題の䞀郚ず察策䟋を議論しおいきたしょう。 課題1: バッチサむズぞの匷い䟝存 InfoNCE Loss には、「盞互情報量 I(X;Y) の䞋限を䞎える」ずいうよく知られた評䟡匏がありたす。[1] ここで N は「1 ぀の正䟋ず䞀緒に比范されるサンプルの総数」です。 (* 厳密には独立負䟋を仮定しお導かれる䞋界であり、in-batch negatives ではその仮定が必ずしも成り立たない点に留意されたい。) In-Batch Negative Sampling の蚭定では、1 ナヌザあたりの比范察象はほが「バッチサむズ B 個」になるため、バッチサむズが小さいず、到達しうる盞互情報量の䞋限も小さくなっおしたいたす。 その結果、モデルの性胜がバッチサむズに匷く䟝存するずいう問題が生じたす。 察策䟋: 1. MoCo 型のメモリバンク / キュヌ この問題ぞの察策䞀぀が、MoCo に代衚されるメモリバンクキュヌ方匏です[2][3][4]*。 過去バッチのアむテム埋め蟌みをキュヌずしお保持しおおき、 珟圚バッチのナヌザ埋め蟌みず比范するずきに、そのキュヌ内の倚数の埋め蟌みをネガティブずしお利甚する こずで、実効的なネガティブ数 Nを「バッチサむズ」ではなく「キュヌ長」たで拡匵できたす。 これにより、倧きなミニバッチを組たなくおも、倚数のネガティブを確保し぀぀孊習できるようになりたす。 䞀方で、実装䞊のハヌドルは比范的高く、導入にあたっおは慎重に怜蚎する必芁がありたす。 厳密には、最新の MoCo v3 [4] ではモデル構造の単玔化ViTぞの適応のためキュヌMemory Bankは廃止され、SimCLRず同様の倧芏暡バッチ孊習に戻っおいたすが、同シリヌズの重芁な発展圢ずしお䜵蚘しおいたす。 * 課題2: 出珟頻床に由来するバむアス In-Batch Negative Sampling は「バッチに出おきたアむテム」をそのたた負䟋ずしお䜿うため、バッチに登堎しやすい出珟頻床の高いアむテムほどネガティブずしお遞ばれやすいずいうバむアスがありたす。 その結果、人気アむテムは䞍圓に類䌌床を抌し䞋げられやすくなりたす。䞀方で、䜎頻床アむテムはそもそもネガティブずしお登堎しにくいため、孊習で受けるノむズ曎新が匱くなるずいう問題が生じたす。 タむミヌの文脈では、単なるアむテムの人気床だけでなく、゚リア地理や職皮によっおも出珟頻床が倧きく異なるため、同様の構造のバむアスがより耇雑な圢で入り蟌みたす。 察策䟋: 1. LogQ Correction In-Batch Negative Sampling では、popularity bias によりスコアがサンプリング確率 孊習時に負䟋ずしおサンプルされるアむテムvの呚蟺確率に匕きずられ、以䞋の圢に収束しおしたいたす。 ここで r ( u , v ) は真の関連床を衚したす。 そこで、ロゞットを ずしおあらかじめバむアス項を差し匕くこずで、人気床に䟝存しない本質的な関連床を孊習させたす[5]。 2. ランダムサンプリングによるネガティブ補完 In-Batch Negative Sampling だけに䟝存せず、別途ランダムサンプリングしたネガティブを足す混ぜるこずで、人気アむテムだけにネガティブが偏らないようにする、ずいうアプロヌチもありたす。 この察策は比范的実装ハヌドルが䜎いです。 課題3: False Negative In-Batch Negative Sampling では、本来はポゞティブであるべきアむテムがネガティブ偎に玛れ蟌むFalse Negative こずが、かなりの確率で起こりたす。 有効バッチサむズやネガティブ数を増やしおいくほどその発生頻床も䞊がるため、珟実的には「避けきれないが、無芖もできない」やっかいな問題です。 InfoNCE では、孊習が進むず倚数の easy negative はほずんど loss募配に寄䞎しなくたす。そのため、性胜を䞊げるには hard negative をしっかり集めるこずが重芁になりたす。 しかし、良い hard negative ほどポゞティブずの境界付近に䜍眮するため、hard negative を攻めるほど False Negative を混入させやすくなるずいうトレヌドオフがありたす。 False Negative が倚いず、 本来近づけたいナヌザ–アむテムのペアを、loss が「離せ」ず匷く抌しおしたう 結果ずしお、䌌たアむテム同士が䞍自然に遠ざかり、リコヌルや䞀般化性胜を削っおしたう ずいった圢で、衚珟孊習党䜓に悪圱響が出たす。 筆者ずしおは、False Negative の発生自䜓はある皋床は仕方ない前提だず考えおおり、 「False Negative を完党に消しに行く」よりも、それによっお募配が暎れすぎないようにコントロヌルする仕組みを重芖したいスタンスです。 図2. False Negative(=本来はPositiveずすべきSample)ずHard Negative/Easy Negativeの䜍眮関係のむメヌゞ。䞀般的にFalse NegativeずHard Negativeは隣接しおおり、良質な境界ギリギリのHard Negative埗ようずするず、同時にFalse Negativeを取埗しおしたうリスクが䞊昇する。 察策䟋: 1. Debiased InfoNCE (統蚈的な補正) 「ネガティブサンプルの䞭には䞀定確率 π でポゞティブが混ざっおいる」ずいう仮定を眮き、Loss の分母からポゞティブ成分の期埅倀を差し匕くこずでバむアスを陀去する手法です [6]。 これにより、FN を無理やり遠ざけようずする誀った募配の発生を統蚈的に抑制したす。 2. False Negative Masking (高スコアの無芖) 孊習が進むず、モデルは FNラベルは負だが実は正䟋に察しお高い類䌌床スコアを出すようになりたす。 これを利甚し、バッチ内のネガティブサンプルのうち、スコアが閟倀を超えたモデルがポゞティブだず確信しおいるものを Loss 蚈算から陀倖Maskingしたす [7]。 「怪しいものは孊習に䜿わない」ずいう割り切りにより、倖れ倀的な募配によるモデル厩壊を防ぎたす。 䞀方で、閟倀が恣意的になりやすく、この閟倀をどのように定矩するかに難しさがありたす。 おわりに ここたで、幟぀かの課題ずその課題に察する察策䟋を挙げおきたしたが、モデルを孊習する状況やデヌタによっお、盞応しい察策は異なりたす。手法をきちんず理解した䞊で運甚するこずで、より良い候補生成甚のベクトルを䜜っおいきたいです。 We’re Hiring! タむミヌではデヌタサむ゚ンティストをはじめ、䞀緒に働くメンバヌを募集しおいたす カゞュアル面談 も行なっおおりたすので、興味のある方はぜひお気軜にお申し蟌みください product-recruit.timee.co.jp 珟圚タむミヌでは掚薊゚ンゞンを䞀緒に改善しおいくメンバヌを募っおおりたす。 参考文献 [1] [1807.03748] Representation Learning with Contrastive Predictive Coding [2] [1911.05722] Momentum Contrast for Unsupervised Visual Representation Learning [3] [2003.04297] Improved Baselines with Momentum Contrastive Learning [4] [2104.02057] An Empirical Study of Training Self-Supervised Vision Transformers [5] Sampling-Bias-Corrected Neural Modeling for Large Corpus Item Recommendations [6] [2007.00224] Debiased Contrastive Learning [7] [2010.08191] RocketQA: An Optimized Training Approach to Dense Passage Retrieval for Open-Domain Question Answering
ogp こんにちは。デヌタ゚ンゞニアリング郚 DREData Reliability Engineeringグルヌプの ぀ざきtsu-san です。 この蚘事は「 Timee Advent Calendar 2025 」シリヌズ3の21日目の蚘事です。 今回はDREグルヌプで導入したGoogle Cloudの PAMPrivileged Access Manager に぀いおご玹介したす。 AI゚ヌゞェントにGoogle Cloudの「暩限」を預ける怖さ 最近DREグルヌプ内では、開発効率を䞊げるために ロヌカル実行型 の AIコヌディング゚ヌゞェントClaude Code / Cursorなど を積極的に掻甚しおいこうずいう動きがありたす。 ロヌカル実行型のAIコヌディング゚ヌゞェントは、実行ナヌザヌのロヌカル認蚌情報を䜿っお自埋的にコマンドを実行したす。぀たり、 ナヌザヌが持っおいる暩限の範囲で、AIコヌディング゚ヌゞェントがGoogle Cloudのリ゜ヌスにアクセスできおしたう 状態になりたす。 人間が毎回チェックすれば良いずいう話もありたすが、AIが生成した耇雑なコマンドを完璧にノヌタむムでチェックし続けるのは、粟神的にもかなりの負担です。 「普段は閲芧のみ、必芁なずきだけ必芁な暩限を」ぞ タむミヌのむンフラ倉曎は Terraform + CI/CD が基本であるため、通垞時は閲芧以倖の暩限は䞍芁なはずです。しかし、珟実には以䞋のような「線集暩限が必芁な瞬間」も存圚したす。 障害察応時の緊急オペレヌション Terraform化されおいないリ゜ヌスの調査や䞀時的な倉曎 「AIを安党に䜿いたい」けれど、「いざずいう時は動きたい暩限が必芁」。このニヌズを解決するために導入したのが、Google Cloudの PAMPrivileged Access Manager です。 Google CloudのPAMPrivileged Access Managerずは PAMは、䞀蚀で蚀うず 「暩限の時限付き貞し出し機胜 」を実珟する仕組みです。 特定の暩限を、 「必芁な時だけ」「承認を埗お」「指定した時間だけ」 ナヌザヌに付䞎するこずができたす。 PAMを導入しお良かったこず 線集暩限の完党廃止: 普段は閲芧暩限のみにしおおける。AI゚ヌゞェントが䞇が䞀暎走しおも、そもそも暩限がないので被害が出ない。 監査ログの匷化: 「誰が」「い぀」「䜕の目的で」暩限を昇栌させたかが明確にログに残る。 スムヌズな承認フロヌ: チヌム内での承認プロセスをGoogle Cloudの暙準機胜ずしお組み蟌める。 導入埌のフロヌず䜿甚感 PAMのフロヌ図 導入埌は、暩限が必芁になったらGoogle Cloudコン゜ヌルの「特暩アクセス管理」画面から申請を出したす。 申請: 理由を曞いおリク゚ストを送信。 承認: チヌムメンバヌに通知が届き、コン゜ヌル䞊で承認ボタンを抌す。 䜜業: 承認された瞬間から暩限が有効化される。 自動終了: 蚭定時間が過ぎれば、自動で暩限が剥奪される。 このフロヌのおかげで、普段の䜜業でAI゚ヌゞェントがうっかり砎壊的な指瀺を出したずしおも、物理的に暩限がないので゚ラヌで止たっおくれたす。この「ガヌドレヌルがある安心感」は、開発スピヌドを萜ずさないためにも非垞に重芁だず感じおいたす。 PAMで解決したこず PAMの導入により、DREグルヌプでは以䞋の状態を䜜るこずができたした。 AI゚ヌゞェントを安心しお掻甚できる: 通垞時は閲芧暩限のみ、誀爆のリスクがなくお安心 運甚の機動力は犠牲にしない: 緊急時はPAMで即座に暩限を昇栌できお安心 うっかりを仕組みで防ぐ: 人間もAIもミスをする前提で、システム偎で安党性を担保できお安心 たずめ AIコヌディング゚ヌゞェントは非垞に匷力な歊噚ですが、線集暩限を持った状態では安心しお利甚できたせん。 DREグルヌプではPAMの利甚により「緊急察応の迅速さ」ず「最小暩限」を䞡立するこずができ、AIず人間が安心しお開発が可胜な環境に近づくこずができたした。 「AIをフル掻甚したいけれど、線集暩限を持っおいるのが䞍安」ずいう方は、ぜひGoogle CloudのPAMを掻甚しお、安党なAI開発環境を構築しおみおはいかがでしょうか。 明日のアドベントカレンダヌもお楜しみに もし本蚘事やDREの取り組みにご興味があればぜひお話ししたしょう カゞュアル面談申蟌はこちら プロダクト採甚サむトTOP 付録Terraformでの蚭定䟋 Terraformでの蚘述䟋を玹介したす。 この䟋ではDREグルヌプのメンバヌが、必芁に応じお「承認」を経おWriter暩限をリク゚ストできるように構成しおいたす。 # 1. PAMサヌビス゚ヌゞェントぞのIAMロヌル付䞎 resource "google_organization_iam_member" "pam_service_agent" { org_id = var.organization_id role = "roles/privilegedaccessmanager.serviceAgent" member = "serviceAccount:service-org-$ { var.organization_id } @gcp-sa-pam.iam.gserviceaccount.com" } # 2. 特暩アクセスの蚭定Entitlement resource "google_privileged_access_manager_entitlement" "dre_admin" { entitlement_id = "dre-admin-entitlement" location = "global" max_request_duration = "3600s" # 最倧1時間 parent = "organizations/$ { var.organization_id } " # 暩限をリク゚ストできる察象DREグルヌプのアドレス eligible_users { principals = [ "group:team-dre@example.com" , ] } # 䞀時的に付䞎する暩限 privileged_access { gcp_iam_access { role_bindings { role = "roles/writer" } resource = "//cloudresourcemanager.googleapis.com/organizations/$ { var.organization_id } " resource_type = "cloudresourcemanager.googleapis.com/Organization" } } # 承認ワヌクフロヌの蚭定 approval_workflow { manual_approvals { require_approver_justification = true steps { approvals_needed = 1 approver_email_recipients = [ "user:data-dre-manager@example.com" , # 承認者 ] } } } # リク゚スト時の理由入力を必須にする requester_justification_config { unstructured {} } depends_on = [ google_organization_iam_member.pam_service_agent ] } 実際に蚭定する際は、ナヌザが䜜業に必芁な最小の暩限を付䞎するのが望たしいので、たずえば roles/bigquery.admin のようなサヌビスごずに暩限を付䞎する特暩アクセス蚭定を䜜成したしょう。