はじめに こんにちは。医療プラットフォーム本部ビジネス基盤グループでエンジニアをしている熊本です。 ブログへの登場は久々となりますが、2019年に新卒で入社して以来、長らくプロダクト開発のエンジニアをしてきました。そんな私は現在、医療プラットフォーム全体のMA（マーケティングオートメーション）、SFA（営業支援）、CRM（顧客管理）といったITツールおよび業務フローの設計・改善を通じて、事業パフォーマンスの向上を担う開発組織のマネージャーを務めています。 メドレーでは、患者・生活者と、病院・有床診療所、医科診療所、歯科診療所、調剤薬局といった各医療機関向けに事業・プロダクトを展開していますが、今回は、これらの事業を支えるITツールの Salesforce を kintone へ移行したプロジェクトについてお話しします。 背景 SFAが抱えていた課題 弊社では長年、医療プラットフォームにおける複数の事業部門で共通のSalesforceを利用してきましたが、運用を続ける中で以下のような課題が顕在化していました。 最新・正しい情報の把握が困難 ：正規化されていないデータや重複管理による情報の分散 データ分析の壁 ：分析を見据えた設計になっておらず、プロダクト側の利用状況との突合など、柔軟なデータの加工に工数がかかっていた 非効率な業務フロー ：複数ツールの併用や重複する項目の存在などを背景に、手動での転記やダブルチェックが発生している状態 システム管理の属人化 ：目的が不明な項目が乱立し、メンテナンス・レポート作成ができる人が限られている状態 また、130個近くのライセンスを保有していたため、これらの課題を踏まえるとコスト過多な状況にも陥っていました。 全ての顧客体験をプロダクト側が理解し、設計責任を持つ 私たちは、 営業・カスタマーサクセスといった顧客活動から、契約・請求に至るまでを「一連のプロダクト体験」として捉え 、その設計・実装にエンジニアが深く関わることを大切にしています。 この考えに基づき、単なるツールのリプレイス（お引っ越し）ではなく、より良い顧客体験につながる合理的で整理された事業オペレーションを実現するため、 業務・データ・ツールを一体でエンジニアが設計し直す 。これが本プロジェクトの重要なポイントでした。 取り組み 体制構築とアーキテクチャ設計 前述の通り、Salesforceはこれまで複数の事業部門で活用してきました。1人で各事業の業務フローや必要データを把握し再設計するのは困難ですし、何より私たちが大切にしている考え方も踏まえ、プロダクトエンジニアが各事業に深く潜り込んで再設計すべきだと考えました。そこで、各事業領域からプロダクトエンジニアを1名ずつアサインする体制としました。私はPMとして全体設計や車輪の再発明が起きないよう各部門の連携をコントロールする役割を担い、各環境のデータ設計・構築はその事業領域担当のエンジニアが主導する形をとりました。 kintoneは責務分離やメンテナビリティを考慮し、事業領域ごとに環境を分けるアーキテクチャを採用しました。また、kintoneへの移行に伴い、コストや親和性を加味してMAツールの移行も行いましたが、本記事では詳細を割愛させていただきます。 医療プラットフォーム本部の組織体制 ツールの移行イメージ 業務理解と要件定義 まずは、日々の事業活動の中で発生するデータや、業務上必要となるデータ、およびそのフローの現状とあるべき姿を描くため、事業部とコミュニケーションを重ねました。長年利用してきたこともありデータ項目が膨大となっていたため、「このデータをどう活用するのか」を重点的に会話し、そもそも不要ではないか、より活用しやすくするにはどうすべきか、などの整理に時間をかけました。 データ設計 特に工夫したのは、DB観点での「正規化」とユーザー観点での「入力のしやすさ」のバランスをとったデータ設計です。kintoneはDBとUIが一体型であるため、このバランス調整にとても苦労しました。一般的なRDBMSではデータの履歴を残すために専用のテーブルを設けイミュータブルモデリングなどを採用する場面でも、kintoneだとテーブル≒アプリとなるため、テーブルを分けることは単純にユーザーの画面遷移や入力箇所を増やすことに直結してしまいます。こういった場合は完全な正規化をするのではなく、普段の商談管理で使用するアプリとその商談ステータスの履歴を管理するアプリを分け、それぞれのアプリに同類のフィールド（RDBMSのカラムをkintoneではフィールドと呼びます）を設置することを許容しつつも、JavaScriptを用いた自動転記の仕組みを作ることで、ユーザーは商談管理アプリだけに入力していれば良いようにするといった工夫をしました。 泥臭く戦ったポイント：データ移行と同期システム ここからは、エンジニアとして特に苦労した2つのポイントをご紹介します。 1. 冪等性と再現性を追求したデータ移行 100名以上が利用するシステムにおいて、特にデータ移行には慎重を期しました。具体的な方法としては、Salesforceのスキーマをkintoneのスキーマに変換し、データをマッピングした結果をCSVに出力するという一連の処理を、CLIコマンド等の整備によりスクリプト化しました。 データ移行では、一度kintoneに投入した後、UAT期間中に事業部からのフィードバックを受けて設計を見直し、再投入が必要になるケースがありました。また、リハーサル目的で、本番移行前にも何度でも再実行できる仕組みが必要でした。そのため、前述のように一連の処理をスクリプト化し、「再現性」を確保しました。さらに、「冪等性」も重要なポイントでした。今回のケースでは、それぞれのアプリにユニークキーを設けて常にUPSERT処理を行うことで、元データが同じであれば、何度実行しても同じ状態を再現できるようにしました。 kintoneへのインポート処理自体はレコード数に比例して一定の時間がかかってしまうものの、事前に手順化しリハーサルを重ねたことで、本番稼働前日の夜間作業で無事に移行を完了させることができました。ただし、（一定の想定範囲ではあったものの）移行作業直前にSalesforce側でデータの更新や削除が行われたことで、kintone側で関連データ同士の紐付けがうまく設定できないケースも発生しました。これはエラーログを見て個別に対処するしかなく、大変苦労した部分でもありました。 2. Salesforceとkintoneの双方向同期システム Salesforceは長年活用してきたことから、いわゆるSFAとしての機能だけではなく、請求や契約管理としての役割も担っていました。今回のプロジェクトでは事業部側が利用するSFAとしての機能はkintoneへ移行しつつも、請求や契約管理といったバックオフィス領域に関しては将来的な販売管理システムへの移行も見据えてスコープ外としていました。よって、これまでは一つのシステムの中で顧客・商談から契約・請求まで一元管理していたものを分離したため、システム間でデータを連携させる必要がありました。 詳細は省きますが、Salesforceに残った契約・請求関連データの一部は、営業やカスタマーサクセスなどの事業部側と契約・請求処理を担うバックオフィス部門の双方向による書き込みが業務上必要であったため、単にkintoneから必要なデータを一方向で送るだけでは要件を満たせませんでした。そのため、SFA領域とバックオフィス領域のハブとなる「商談」などのデータに関しては、Salesforceとkintone間で一部のスキーマ定義を揃え、両システムを一定間隔で同期させる仕組みとしました。 具体的な仕組みとしては、両システムのスナップショットを一定間隔で取得し、前回との差分を検知して互いのシステムへ反映し合う形をとりました。 ここで壁となったのが、「準リアルタイム性」の要求と「データの競合」です。両方のシステムで日常的にトランザクションが発生するため、「同じレコードの同じ項目が、それぞれのシステムで同時に別の値へ書き換えられる」可能性がありました。この競合状態を安全に解決するためのロジックを構築する必要があり、非常に苦労しました。 この対応にあたっては、当初想定していた対象項目が、本当に準リアルタイムで同期が必要なのかを関係者と徹底的に精査しました。その結果、同期間隔の調整や同期対象の大幅な絞り込みができ、現在は安定して稼働する仕組みを実現できています。 ※ データ移行や同期処理のディープな話は盛りだくさんな内容となってしまうため、また別の機会にブログ化できればと思います！ 成果 80%以上のランニングコスト削減 契約・請求などを担う組織の必要分を除き、90個ほどのアカウントを削除することができました。kintoneの費用を加味しても、全体のランニングコストとして80%以上削減することができました。 BigQuery集約によるデータ分析・可視化の実現 Salesforceのレポート機能の制約から解放され、より柔軟なデータ活用ができるようになりました。 KPIダッシュボードの構築 ：Looker Studioなどのアセットと連携したデータの分析・可視化が可能に 自律的な分析文化 ：勉強会の開催やマニュアル整備のおかげもあり、事業部メンバーが生成AIも活用しながら、より自律的かつスピーディなデータ分析が可能に 横断的分析 ：kintoneの顧客・商談データ、契約データ、プロダクトデータなどをBigQueryに集約し、多角的な分析を実現 また、横断組織にあるデータ戦略グループが、最近「自然言語でBigQuery等のデータを分析できる社内システム」をリリースしました。今回のプロジェクトによるデータ整備とこのシステムが組み合わさり、よりスピーディにデータ分析を行える環境づくりが加速しています。 関連記事： データ分析AIエージェントの実践 - Slack × Devin × Context Engineering 今後の展望 本プロジェクトによって多くの成果を得られましたが、私たちはまだ「業務やデータの一部をツールの移行と共に再設計し、基盤を整えた」に過ぎません。 今後はこの基盤を活かし、KPIなどの定量的なデータや現場ヒアリングを通じて事業の課題・ボトルネックを特定し、継続的に改善を回すサイクルを作っていきたいと考えています。 また、日々顧客と向き合う事業部のメンバー自身が、データ活用や拡張性を見据えて自律的にツールを改修できる状態こそが、組織のアジリティを最も高く保ちながらスケールできる理想の形だと考えています。その実現に向けて、エンジニアリングの専門性を持つ私たちビジネス基盤グループが、誰もが改修・改善しやすい仕組みづくりを牽引していきたいと考えています。 まとめ エンジニアが事業の深い部分に入り込み、業務・データ・ツールを一体で再設計するプロジェクトについてご紹介させていただきました。 メドレーでは、「医療ヘルスケアの未来をつくる」というミッションのもと、エンジニアがビジネスの根幹に関わり、プロダクトと事業を共に成長させる文化があります。自ら課題を発見し、設計から運用までをエンジニアとしてのリーダーシップを発揮しながら一気通貫で推進できる方を絶賛募集しています。 メドレーで働く｜株式会社メドレー メドレーでの働き方や人事制度、求人情報など、採用に関する情報をご紹介します。 www.medley.jp 少しでも興味を持っていただけましたら、ぜひメドレーの採用ページをご覧ください！

はじめに この記事は BASE アドベントカレンダー17日目の記事です。 devblog.thebase.in こんにちは、BASE CSE Group のグループマネージャーをしている @izuhara です。 BASEは「誰でもかんたんにネットショップを開設できる」サービスとして成長し、多くのショップオーナーに利用されてきました。その裏側では、事業規模が拡大するにつれ、オペレーションも複雑さを増し、バックオフィスやオペレーションを行うチームに属人化や手作業が蓄積していくという課題が生まれていました。 こうした背景のもと、事業運営を技術で支えるために立ち上がったのが CSE（Corporate Solution Engineering）チーム です。 現在CSEでは、以下の3つを柱として業務改善・自動化を推進しています。 月次売上計上業務の自動化対応 決済を中心とした社内システムの構築 AI活用を前提とした業務の再構築 本記事では、BASEの裏側を支えるCSEチームの変遷をこの3フェーズに分けて紹介します。 フェーズ1：経理向け月次売上計上業務の自動化（2020年〜） CSEが最初に向き合ったのは、BASEの事業基盤となる月次売上計上業務でした。 当時、売上データの集計や修正作業はすべて手作業で行われており、月次締めの度に数日間にわたる作業が発生していました。 さらに、上場直後であったこともありJ-SOXへの対応強化が求められ、売上金の透明性や監査対応の厳密さが一段と必要とされるタイミングでもありました。 CSEの主な取り組み 売上データ集計・計上処理の自動化 BASE側の決済データと各決済サービスの入金データ、ショップ売上金の整合性チェック機能の構築 詳細はこちらをご覧ください。 devblog.thebase.in 売上計上の整合性チェック 成果 月次作業が数日→数時間に短縮 クエリの叩き間違いなどによる売上計上のヒューマンエラーが大幅に減少 経理チームが安心して業務を進められる安定したプロセスを提供 このフェーズは、CSEがまず「足元の重要業務を支えるエンジニアリングチーム」として役割を確立した時期でした。 フェーズ2：決済を中心とした社内システムの構築（2022年〜） 事業成長に伴い、経理領域以外にも自動化ニーズが急増したタイミングです。 また、このタイミングでIT統制領域が Product Governance チームとして分離され、CSEはより社内業務改善に特化した組織 へと方向転換しました。 社内ではEUC（End User Computing）によるスプレッドシート・手入力運用が多く、業務のブラックボックス化やミスの温床になりつつありました。これらを計画的にシステム化し、再現性と可視性の高い業務基盤へと移行していくことが求められました。 CSEの主な取り組み 請求書発行プロセスの自動化、債権回収モニタリング機能の開発 kintoneを活用した業務アプリケーションの高速構築 EUC依存からの脱却と、業務のシステム化の整備 インボイス制度への対応 成果 手運用で行われていた社内オペレーションの多くをシステム化 kintone等を活用し、小さく始めて早く改善する内製プロセスを社内に定着 請求や債権管理など、ミスが許されない領域で運用リスクを大幅に低減 このフェーズを通じて、CSEは「社内システムの開発パートナー」としての立ち位置を確立しました。 フェーズ3：AI活用を前提とした業務の再構築（2025年〜） 生成AIの登場により、業務改善は新たなステージへ入りました。 従来の「人がやっていた作業を自動化する」から一歩進み、業務プロセスそのものをAI前提で再設計するフェーズです。 まずPoCとして着手したのは、社内でも問い合わせが多い人事・労務領域のAI(RAG)による自動応答です。FAQの回答や書類手続きの案内など、繰り返し発生するコミュニケーションをAIで対応する仕組みづくりを進めました。 PoCで得たAIによる回答品質の高め方や、セキュアな情報をAIで取り扱うための基盤構築などは、その後のカスタマーサポート業務のAI導入にも活かされています。 CSEの主な取り組み 人事・労務・総務など、社内問い合わせのAI自動応答の構築 カスタマーサポート業務のAIによる業務置き換え 社内データを安全に扱うための基盤整備 詳細はこちらの記事をご覧ください。 devblog.thebase.in 社内問い合わせのAI自動応答 成果 問い合わせ対応のAIによる自己解決 AIを活用した業務改善の成功例が蓄積し、AI活用の窓口としての役割の拡がり AI活用はまだまだ始まったばかりで、改善途中にも新たな技術革新が繰り返されているところですが、このフェーズを通じて、CSEは「AI活用で業務を再構築」する新たな改善施策を進められるようになりました。 おわりに CSEチームは、BASEの事業成長に合わせて 「業務の自動化 → 社内システム構築 → AI活用で業務を再構築」 という進化を続けてきました。 今後も社内のあらゆる業務がAIで再構築されていく未来を見据え、BASEの事業を支える目に見えない基盤をつくり続けていきます。 BASEでは、今後の事業成長を支えるエンジニアを募集しています。 ご興味があれば、ぜひ採用情報をご覧ください。 binc.jp 明日のBASEアドベントカレンダーは @ImazekiShota さんの記事です。お楽しみに！

こちらの記事は カケハシ Advent Calendar 2025 の 8日目の記事になります。 はじめに ソフトウェアエンジニアのkackyです。 「kintoneの契約データを、Databricks経由でAWS上のプロダクトに同期したい」 このような要件を受けたとき、どのような開発ステップが浮かぶでしょうか？ kintoneのデータ構造を理解する プロダクト側のAPI仕様を把握し、TypeScriptで書かれたバックエンドと連携する。必要に応じて機能追加する 名寄せ処理のビジネスロジックをDatabricksで正確に実装し、検証する 人手でこれらすべてを横断的に把握し、整合性を保ちながら開…