試されるDataOps!? ~ここ４年間のデータ基盤の軌跡と成長と壁を北の大地で語る〜

2026年1月30日(金)に実施された「試されDATA SAPPORO #2」での発表資料です。
イベントページ：https://tamesaredatahokkaido.connpass.com/event/376777/
登壇者：株式会社kubell 三ツ橋 和宏

Transcript

1. 試されるDataOps!? ~ここ４年間のデータ基盤の軌跡と成長と壁を北の大地で語る〜 みっつ 2026年01月30日
2. スピーカー紹介
 2 みっつ(三ツ橋 和宏) 
 ◦業務経験 　前職では長年に渡ってアドテクノロジーのデータ処理を担当。 　オンプレHadoop, EMR, Redshift, Spark, BigQuery, Beam...etc ◦株式会社kubell(旧Chatwork株式会社) 　Staff Data Engineer ◦Snowflake関連の活動 ❄Data Superhero’26/'25/'24/'23 ❄Data Polaris'22 ◦情報発信 　X：@kaz3284 この資料もアップ予定。
3. 3 事業概要 • 国内最大級のビジネスチャット「Chatwork」を展開。業界のパイオニアであり国内利用者数No.1*1、導入社数は95.3万社*2を突破 • 圧倒的な顧客基盤のあるプラットフォームを背景に、チャット経由で業務を請け負いDXを推進するBPaaSを展開 　ビジネスチャット「Chatwork」 BPaaS (Business Process as a Service) • 国内利用者数No.1*1 有料ユーザーの96%が中小企業ユーザー • 日本の1/5を占める導入社数95.3万社以上*2 792万ユーザー • 全業界・全職種の方が日常的に使うプラットフォーム *1 Nielsen NetView 及びNielsen Mobile NetView Customized Report 2024年4月度調べ月次利用者（MAU:Monthly Active User）調査。 調査対象はChatwork、Microsoft Teams、Slack、LINE WORKS、Skypeを含む41サービスを株式会社kubellにて選定。 *2 2025年9月末時点 チャット経由で業務を請け負いDXを推進 業務代行 経理・総務・事務な ど幅広い業務に対応 人事・労務など専門 性の高い業務に対応 採用 経理・会計 労務 営業事務 AI・SaaSを徹底活用
4. 4 ビジネスチャットを起点に 周辺サービスを展開可能 Chatworkは中小企業のDXを強力に進める稀有なSaaS • Chatworkは約95万社、約792万IDのユーザーを獲得しており、中小企業向けSaaSとして圧倒的なポジションにいる • 全業種・全職種の従業員が業務時間中ずっと使い続けるため、他SaaSと比較して非常に強いユーザー接点を持つ • この高いプラットフォーム性を活かし、BPaaSを軸とした周辺サービス*1の販売を展開。2024年は前年比+53.8％と大幅成長 中小企業への 圧倒的な導入実績 有料契約の96.8%が 300人未満*2 導入社数 95万社を突破 周辺サービスの売上は年々成長 BPaaSやM&Aにより急拡大 DXアドバイザリー サービス BPaaS YoY+53.8% *1 セグメント詳細に関する詳細はAppendixを参照 *2 2025年9月末時点 単位：百万円
5. サービス種類 BPaaSとは 5 BPaaS （Business Process as a Service） SaaS （Software as a Service） PaaS （Platform as a Service） IaaS （Infrastructure as a Service） ハードウェア ミドルウェア アプリケーション ビジネスプロセス 提供範囲 • BPaaSとは Business Process as a Service の略。ソフトウェアの提供ではなく、業務プロセスそのも のを提供するクラウドサービスであり、クラウド経由の業務アウトソーシング(BPO)なイメージ • SaaSよりさらに上流のレイヤーをクラウド化する、次の潮流になっている
6. まずは、プロジェクトの4年間のハイライト
8. データ基盤プロジェクトとして、着実に進歩を重ね、 全社的なデータ利活用の実現までに、 もう少しのところまで来た!
9. ココにいたるには、4年間で様々な壁があった 線形な成長ではなく、非連続な成長だった
10. 壁を越えて、非連続な成長につながった転換点 〜DataOpsの壁を乗り越えた先に見えた新境地〜
11. 11 壁を越えて、非連続な成長につながった転換点 • ステージ１：旧世代を捨て、新世代のデータ基盤をゼロから立ち上げる ◦ 価値があるデータ基盤を素早く立ち上げる（旧世代から新世代へ） ◦ DevOpsを洗練する ◦ 技術負債をコントロールする ◦ カッコよさより実用性を重視する（トレードオフを選択する） ◦ 属人性を作らない（いつでもどこでも非同期に開発できる） • ステージ２：データエンジニアがボトルネックにならない開発体制を実現する ◦ 人手不足の...壁に立ち向かう ◦ 同じ意志をもつ方々（同志）と共に進める ◦ プラットフォームを整える・開放する ◦ 仕組みの展開で領域を広げる ◦ 属人性を排除する（運用でカバーに妥協しない仕組み作り） • ステージ３（現在進行中）：プロジェクトを加速するAI導入について ◦ まずは成果を出しやすいところから導入する ◦ AIは銀の弾丸ではない ◦ R&Dで満足しない（ユースケースを開拓する） ◦ AIによるデータ利活用支援は簡単ではない（何を目指し、目標とするか）
12. ステージ１：旧世代を捨て、新世代のデータ基 盤をゼロから立ち上げる
13. 13 価値があるデータ基盤を素早く立ち上げる（旧世代から新世代へ） 旧世代のボトルネックを克服し、自然と移れる圧倒的な新世代へ。 現行基盤コスト 次世代データ基盤コスト ※横軸：時間。経過時間に対して同じ機能を提供すると仮定 ※コスト：利用料金、開発コスト、運用コスト、技術的負債の蓄積、精神的負荷...の合計値 数千万円/年相当のコスト減。 +α データ利活用の促進。
14. 14 開発・運用を洗練する 最初期から運用のアンチパターンを回避するシステム構成にした。 • パターナリスト症候群 ◦ ゲートキーパー：ある人が権力を持ってしまう体制になってしまう。 • アラート疲れ ◦ アラートが多いと業務時間外の対応が頻発してしまう状況。 参照：「システム運用アンチパターン」 データモデル DWH(SSOT) DB モデル CI 開発（ローカル、 devcontainer） deploy DWH構成 (IaC) deploy deploy ユーザ 管理 同期 SCIM dbt, Cursor, docker GitHub Actions,Dagster Okta GitHub Actions,Terraform GitHub GitHub ※現在の開発・運用フロー図 再初期からあまり変わっていない。（不要になったもの を削ってシンプルになった）
15. 15 技術的負債をコントロールする 限られたリソースの中で何を優先し、何を後回しにするのか（参考までに） • 優先したこと ◦ （自分も含め）誰かの手（権限）が必要なところをシステム化する ◦ 定期に発生する運用を自動化する ◦ 記録に残すこと ▪ 意思決定の経緯（DesignDocs、ADRなど）、mtgの議事録 ▪ 設計、仕様 ▪ リリース・障害対応 • 後回しにしたこと ◦ 自己満足 ◦ 生産性の計測（four keys） ◦ コストが高くつく自動化（フェーズに応じて、適度な塩梅で対応する） ▪ マイグレーション（データ型変更、カラム追加） ▪ 自動リカバリ ▪ CI/CD 15
16. 16 カッコよさより実用性を重視する • dbtを採用した： ◦ データ開発（SQL）にソフトウェア開発の知見を取り込めるようになった。 • ETLツール（ReverseETL）を積極利用した： ◦ 各種SaaSのデータの扱いは専門家に任せる。 • 基本的なデータ取り込みを日次にした： ◦ リアルタイムな取り込み（CDC）も検討したが、インフラコストや運用難度 が上がることを考慮して見送った。 Salesforce market …etc 外部ストレージ AWS Lambda S3 分析DWH DB モデル 取り込み 書き出し 書き出し ETL reverseETL ジョブ実行 制御 Digdag dbt 各種 saas データ利活用 プロダクト データ イベント データ
17. 17 属人性を作らない（環境・コミュニケーションに縛られない開発にする） ×環境・コミュニケーションに縛られる開発 • 開発を始める時は、まず環境構築するところから入る（半日から1日かけて）。 • タスクに着手したら、誰かに必要な情報を聞くことから始める。 • Dev環境の調子が悪いと開発が進まない（できない）。 • 誰かに動作確認（テスト）してもらわないと開発完了にならない。 ◦環境・コミュニケーションに縛られない開発 • 開発を始める時は、PCを起動すればスグに始められる。 • タスクに着手しようとする時は、一人で始められる。 ◦ 方向性または設計が決まっている ◦ 過去の経緯がdocsにあって自分で調べられる • 開発の際に、他の開発者の影響を一切受けずに自分のペースで進められる。 • 自分で確認をしたら開発完了となる。 開発環境のコンテナ化、IaCの整備...DevOpsを洗練することに加えて、 意思決定の過程、検証、設計、議事録などできるだけ記録に残すようにした。
18. ステージ２：データエンジニアがボトル ネックにならない開発体制を実現する
19. 19 人手不足の...壁に立ち向かう 急速な需要の高まりに応じて、越えなければならない壁が見えてきた • 色々な部門、関連会社から同時多発的に需要が起こる • データは生き物、どんどん変化していく ◦ データソース追加、カラム追加(仕様変更) • 人員拡張が困難 ◦ データエンジニアは母数が少ない シンプルな直列型ではデータエンジニアが確実にボトルネッ クに... 直列体制のままの悪循環 • データ基盤の信頼低下 • データ基盤が使われなくスプシ運用が頻発することによるデータのサイロ 化、データスワンプ(沼)...etc • とりあえず動けばよいという大きな泥団子問題...etc 直列型
20. 20 同じ意志をもつ方々（同志）と共に進める • データ基盤はデータ利用が進展してこそ活きるモノ！ • 現場の声に接するアナリスト・アナリティクスエンジニアと共に開発するのが理想！！ cf. https://creators-note.chatwork.com/entry/2024/05/29/094942
21. 21 プラットフォームを整える・開放する システム開発の大規模化に挑戦してきた先人達の知恵をデータ基盤開発に適用 できないか • Scale Architecture(「大規模データ管理」), DataMesh • プラットフォームエンジニアリング、マイクロサービス, DDD, DevOps…etc データエンジニア 直列型 並列型
22. 22 仕組みの展開で領域を広げる 一部で確立した仕組みを全体へ展開してデータ基盤の領域を拡大する。 仕組み化できていれば、素早く展開できる。 Salesforce market …etc 外部ストレージ AWS Lambda S3 分析DWH DB モデル 取り込み 書き出し 書き出し ETL reverseETL ジョブ実行 制御 Digdag dbt 各種 saas データ利活用 プロダクト データ イベント データ 事業A 事業B 事業B
23. 23 属人性を排除する（運用でカバーに妥協しない仕組み作り） データ基盤開発に機動性を持たせるために、 • （誰かに頼まないとできない）属人性はスケールする際のボトルネックになり得る。 • （仕組み化を進める際に感じる）存在価値がなくなることへの疑念は早く手放す方がお得。 ◦ 自転車（二輪車）と同じで常に前進すれば転ぶことはない ◦ データエンジニアリングは、ヤルベキことが無限にある ◦ データ活用に貢献する方が遥かに価値が高い
24. ステージ３（現在進行中）： プロジェクトを加速するAI導入について
25. 25 まずは、成果を出しやすいところから導入する • まずは、AIとの協業の親和性が高い、開発業務の支援から導入を始める。 ◦ 冒頭で紹介した2年連続2倍の機能追加の土台となった。 cf. https://creators-note.chatwork.com/entry/2025/12/02/113550 ◦ 1年目は開発体制の転換の効果が大きかった。 ◦ 2年目はAIによる開発支援で全体的な生産性が底上げできたことが大きかった。 • （属人性排除の目的で進めた）ドキュメンテーション文化が、AIへの＋αの効果が あった。 ◦ 開発支援のコンテキストになった。 ◦ これまでやってきたコトの延長が、コンテキスト整備の文化へ繋がった。 • AIはデータエンジニアリングにも、開発や利用の根幹を変えうる大きな変化の波を もたらしている。この機会を活かせるのはエンジニアの醍醐味かと。
26. 26 AIは銀の弾丸ではない • 開発では人手に頼る「人ボトルネック」を排除できれば、更に開発効率が上がる • ただ、現実では下記の問題にが考えられる。 ◦ レビューでにおいて「人依存」をどう排除できるのか？ ◦ AIで大量に生成された実装の品質をどう担保するか。 ◦ 機能廃止の対応で、「人依存」をどう排除するか？ ◦ 新しく作るより廃止（削除）する方が、影響範囲の考慮など、 多くのコンテキストが必要になる。 ◦ 技術負債の解消の対応で、「人依存」どうを排除するか？ ◦ 負債の解消は、廃止と新機能追加の複雑な組み合わせのイメージ。 ◦ さらに高度なコンテキストの整備が必要そう。 cf. https://speakerdeck.com/kaz3284/minqiang-di-5hui-kubellnodetaji-pan-kai-fa-nozui-xin-zhuang-kuang-toainohuo-yong-noshi-jian-nituit
27. 27 R&Dで満足しない（ユースケースを開拓する） • 開発スピードが上がると、その「スピードを活かしてどこに向かうか」が重要にな る ◦ 我々は、次に開拓すべきはAIによる利用者支援と定めた。 • データ基盤のユースケースは利活用現場にある。 ◦ 現場に近い方々と一緒に進める必要がある。（目標を見失い、有らぬ方向に向 かって崩壊してしまうR&Dを何度経験したことか...） • ユースケースに紐づけてトライ＆エラーを繰り返すことで洗練された形へ到達でき るのではないかと考えている。 cf.https://creators-note.chatwork.com/entry/2026/01/19/160816
29. 29 AIによるデータ利活用支援は簡単ではない（何を目指し、目標とするか） • AIは開発支援の領域で導入すると、スムーズに恩恵を受けられた。 AI（新技術）は、先ずは成果を出しやすいところから適用するのが良い。 • しかし、ボトルネックを克服すると「次は何を目指すのか」が重要になる。 ◦ 間違った方向を目指してしまうと、大きく遠回りしてしまう • 我々はDataOpsを「プロダクト（会社）のデータを資産として生かす技術開発」と して機動性を重視して推進してきた。 • 最終的には、絶え間なく進化する世の中で、変化に即応できるデータドリブンな組 織を実現する礎にしたい！
30. まとめ
31. 31 まとめ • 4年間の取り組みで、壁を乗り越える度に非連続な進化（ステー ジが変わる）を実現できた！ • それぞれのステージのポイント： ◦ ステージ１の立ち上げ期は、素早く基礎を確立する。 ◦ ステージ２の拡大期は、仕組み化でスケールする。 ◦ ステージ３（進行中）は、より多くのユーザーに有効活用し てもらうこと。 • どのステージでも共通するのは： ◦ 小さく価値を出し続けること。 ◦ 属人化しないこと。 ◦ ステークホルダーと一緒に作り上げること。 ◦ 技術は使われるのではなく使うこと。
32. SOUND ONLY
33. 働くをもっと楽しく、創造的に