500名弱規模の組織のPythonプロジェクト(dbt) をどう管理するか？

500名弱規模の組織の Python プロジェクトをどう管理するか？
PyCon JP 2026@広島 2026/08/22(Day2) お好みトークの資料
https://2026.pycon.jp/ja/lt

Transcript

1. 500名弱規模の組織のPythonプロジェクト (dbt) をどう管理するか？ PyCon JP 2026 8/21(Day 2) お好みトーク ファインディ株式会社 データエンジニア 開 功昂 © Findy Inc. 1
2. 会社概要 会社名 代表取締役 設⽴ 全従業員数 資本⾦ 住所 事業許可番号 ファインディ株式会社 / Findy Inc. ⼭⽥ 裕⼀朗 2014 年 2 ⽉ ※ 本格的な事業開始は2016年7⽉ 478 名 ※2026年1⽉時点 つくる⼈がもっとかがやけば、 世界はきっと豊かになる。 19億9,692万円 ※ 資本準備⾦含む 東京都品川区大崎1-2-2 アートヴィレッジ大崎セントラルタワー 5階 ビジョン 13-ユ-308478 ‧IT/Webエンジニアの転職サービス「Findy」 ‧ハイスキルなフリーランスエンジニア紹介サービス「Findy Freelance」 サービス 経営理念 ‧経営と開発現場をつなぐAI時代の開発資本プラットフォーム「Findy Team+」 挑戦するエンジニアの プラットフォームをつくる。 ‧開発ツールのレビューサイト「Findy Tools」 ‧テックカンファレンスのプラットフォーム「Findy Conference」 ‧仮説検証‧事業開発を加速させるAIエージェント「Findy Insights」等 投資家 グローバル‧ブレイン、ユナイテッド、SMBCベンチャーキャピタル、KDDI、 JA三井リース、みずほキャピタル、博報堂ＤＹベンチャーズ、Carbide Ventures、等 © 2024 Findy Inc.
3. サービス紹介 ファインディが展開するエンジニアプラットフォーム © Findy Inc. 3
4. 今⽇話すこと • • • • 組織や事業が育つと、Pythonプロジェクト（dbt）も増える ◦ dbt: データパイプラインに使われる技術（SQL で変換ロジックを記述） ◦ 組織: 100名/年増、プロダクトも 1 年で 4 つ増、データチームは少数精鋭のまま プロジェクトごとにバージョンやルールがバラバラ 解決策：設定とパッケージ管理だけを共通リポジトリに切り出す まとめ © Findy Inc. 4
5. 組織が伸びるとプロジェクトも増える 事業の成⻑に伴う分散化 各チームがデータ活⽤を⾏うため、独⾃のデータ分析基盤 （dbt/Python環境）を作成 • • 結果として、共通管理ではなく個別のリポジトリが次々と新 設 最初 事業‧チーム増 dbt / Python repo Team A repo Team B repo Team A repo Team B repo Team C repo Team D repo 気づけば社内に複数のdbt/Pythonプロジェクトが独⽴して 並⾛する状態へ 複数並⾛ 組織規模の拡⼤に伴い、リポジトリが⾃然発⽣的に増加 © Findy Inc. 5
6. 気づけばリポジトリごとにバージョンがバラバラ 微妙な⾷い違いが発⽣ • 各チームが⾃律的に独⽴したリポジトリを⽴ち上げた 結果、設定が少しずつズレる • この微妙な差異がのちのバージョンアップやセキュリ ティ対応時の重い負担へ… 同じdbtプロジェクトなのに異なる環境 Repo A Repo B Repo C Python 3.9 Python 3.10 Python 3.11 dbt 1.4 dbt 1.6 dbt 1.7 Rule: Loose Rule: Strict Rule: Custom ⚠ バージョン‧ルールが完全に不⼀致 横断対応時の確認コスト‧エラー発⽣率を押し上げる要因に © Findy Inc.
7. リポジトリの増加がもたらす「3つの⼤変」 ① バージョンアップ対応 ② セキュリティ対応 • dependabotのPRがリポジ トリの数だけ届く • 新たな脆弱性が発表される たびに対応が必要 • 1つずつ⼿作業でマージ‧検 証を⾏う⼿間が線形に増加 • 「⾃社の全リポジトリ」を 個別に⾒て回る状況が発⽣ ③ CI/lintの機能差分 • 同じ会社‧チーム内なのに リポジトリで規約がバラバ ラ • ある環境では厳格なチェッ クが、別では緩いまま放置 © Findy Inc.
8. 「設定とパッケージ管理」だけを切り出したリポジトリを作る 共通部分だけを切り出し集約 • 全部を1つのリポジトリに統合しない ◦ • 共通設定サブリポジトリによる部品化の構造 共通設定リポジトリ 固有ロジックや運⽤チームは別 で 開発や CI/CD を独⽴ lintルール / パッケージ バージョン 共通設定を集約 ◦ pyproject.toml と uv.lock の バージョン管理を⼀元化 ◦ → Dependabot 対応や Cooldown 設定も⼀回で済む Project Repo A Project Repo B Project Repo C ✔ 固有ロジックのみ ✔ 固有ロジックのみ ✔ 固有ロジックのみ 共通設定を「部品」参照 共通設定を「部品」参照 共通設定を「部品」参照 © Findy Inc.
9. SQL lintルールの共通化 共通設定ファイルの⼀元管理 ディレクトリ構成と役割の境界 SQLの整形ルール（.sqlfluff相当の設定ファイル） を共通リポジトリにのみ設置 📁your-project/プロジェクト側リポジトリ 各プロジェクト側でのlint実⾏イメージ ├──📁models/👉 lint対象のSQL（個別ロジック） └──📁shared-config/submodule (共通リポジトリ) ├──📄pyproject.toml(共通の実⾏環境定義) ├──📄uv.lock(環境のバージョンロック) # 共通リポジトリ（Submodule）側を指定 $ uv run --project shared-config \ └──📄.sqlfluff(共通ルールの実体) sqlfluff lint \ --config shared-config/.sqlfluff \ models/ © Findy Inc. 9
10. Taskfileによる操作インターフェースの抽象化 インターフェースの⼀元管理 Taskfileによる抽象化の仕組み 「lintを実⾏する」「dbtを実⾏する」といったコ マンドの叩き⽅をTaskfileで揃える 📁 your-project/プロジェクト側リポジトリ 開発者が利⽤するコマンド（実⾏イメージ） ├── 📄 Taskfile.yml 👉 コマンドを定義（共通化の窓⼝） • lint:sql ➔ uv run sqlfluff...を裏で実⾏ • dbt ➔ uv run dbt...を裏で実⾏ └── 📁 shared-config/ submodule (共通環境) # SQLのLint・フォーマットを実行 $ task lint:sql # dbtモデルの実行（引数も透過的に渡せる） ├── 📄 pyproject.toml (ツールのバージョンを⼀元管理) └── 📄 .sqlfluff (共通のスタイル‧ルール定義) $ task dbt -- run © Findy Inc. 10
11. まとめ：共通化を進めるコツ t i r d 前提を整理、制約を確認 変わらないものを共通部品へ e g データを使う社員やデータを⽣み出すプロダクトは 「変わらないもの（環境‧規約‧セキュリティ対 n e 今後も増える（つまりプロジェクトは増える） 応）」を共通部品として切り出すアプローチを徹底 データチームは劇的に増える可能性が低い 「変わるもの（ビジネスロジック）」だけに集中で d t きる体制を作る i s n g u ご清聴ありがとうございました p © Findy Inc. 11