介護・福祉業向けケアプラン管理システム開発の進め方/やり方/流れや方法/手法/工程/手順

ケアプラン管理システムの開発は、現状業務と要件の整理から始め、方式の選定、設計・開発、テストを経て、小規模な稼働と全体展開へ進みます。

流れの最後は、研修とKPIで現場への定着を図る段階です。費用と見積もりの取り方も、あわせて説明します。

▼全体ガイドの記事
・介護・福祉業向けケアプラン管理システム開発の完全ガイド

介護・福祉業向けケアプラン管理システムの全体像

計画書のサービス内容を中心に、予定・実績、介護記録、請求、LIFEを再利用先として結ぶ図。
一度整えたサービス内容を複数の業務で活用する構造です。

このシステムは、利用者情報から要介護認定、アセスメント、計画書までを扱います。計画書のあとは、会議やモニタリング、評価、更新期限の管理まで、同じシステムで続けて扱います。

帳票の作成だけに絞ると、介護記録や予定・実績、請求、LIFEへの転記が残ります。そのため開発では、誰がいつどの情報を使い、どの業務で再利用するかを先に決めておく必要があります。

入力項目を決めるだけでなく、情報の流れを定めることが出発点になります。

最初に決める目的と対象範囲

必要な業務要件を明確にするため、導入目的と対象範囲を先に決めておきます。目的と範囲がそろうと、どの業務をどこまで載せるかを、発注側と開発会社が同じ前提で話し合えます。

  • 導入目的:入力時間の削減、転記防止、更新漏れ防止などから選び、一文にまとめた優先目標
  • 対象事業:居宅だけか施設も含むか、訪問介護・通所介護・障害福祉まで広げるかの範囲
  • 必要な業務:対象サービスごとの、中心となる計画・記録・連携

目的が曖昧なまま機能を増やすと、入力の負担が重くなり、紙との二重管理も生じます。

居宅では、居宅サービス計画書第1〜3表、サービス利用票・別表、担当者会議、モニタリングが中心になります。一方で、施設では、施設サービス計画や介護記録に加えて、夜勤の申し送り、栄養・看護など多職種記録との連携が重要です。

必要な機能とデータのつながり

業務の流れを支える機能と、訪問先で使う端末の要件を、あらかじめ整理しておきます。

  • 利用者と計画:利用者、家族、主治医、緊急連絡先、認定情報に加え、アセスメント、課題分析、長期・短期目標、サービス内容、週間予定を扱う
  • 記録と進行管理:モニタリング、評価、会議録、計画変更履歴、更新期限・未入力アラートの備え
  • 訪問時の端末利用:通信が不安定なときの一時保存と、端末紛失時の遠隔ロック(要件に含める項目)

計画書のサービス内容は、予定・実績、介護記録、請求、LIFEへ再利用できるデータ構造にしておきます。そうすると、一度入力した内容を複数の業務で使えます。

厚生労働省は、ベンダー間連携の標準仕様を公開しており、2024年度の改訂履歴には第4.0版と第4.1版が記載されています(出典:厚生労働省「介護テクノロジーの利用促進」、2026年確認)。

発注前には、対応する仕様の版、CSVの入出力項目、APIの有無を確かめておきます。また、連携先でエラーが起きたときに備えて、原因と対象データを追える設計も必要です。

ポイント

目的と対象範囲を先に決め、どの情報をどの業務で再利用するかを定めておくと、機能の追加や連携先の選定で迷いが減ります。

介護・福祉業向けケアプラン管理システム開発の進め方

現状業務と要件の整理から、方式比較、設計・開発、テスト、小規模稼働と全体展開へ進む開発工程図。
各工程の確認を重ねてから稼働範囲を広げます。

現状業務を一覧にして、標準機能、データ移行、現場運用を検証しながら段階的に進めます。各段階の終了条件を決めておくと、追加要望による納期や予算の膨張を抑えられます。

開発は6つのフェーズで進みます。下の順番で確認すると、作業の抜けに気づきやすくなります。

  1. 現状業務と要件の整理
  2. 製品・開発方式の比較と選定
  3. 画面・データ・連携の設計と開発
  4. 帳票・連携・現場操作のテスト
  5. 小規模な稼働と全体展開
  6. 研修とKPIによる現場への定着

フェーズ1:現状業務の把握と要件整理

聞き取りは、管理者だけでなく、ケアマネジャー、介護職、看護職、事務、請求担当、情報システム担当にも行います。利用者登録から更新までを業務フローに描き、紙、Excel、FAX、既存ソフトへの入力回数を数えて記録します。

「面倒だから紙に戻る」場面を見つけるには、会議室での聞き取りに加えて、訪問や記録の現場を実際に見ることも有効です。

作って残すものは、業務フロー、利用者・計画・実績のデータ項目、法定帳票の各一覧です。権限、外部連携、優先順位についても、それぞれ一覧にしておきます。

要件は、法令・加算・請求に関わる必須要件、日々の負担を減らす重要要件、将来のAIや分析などの検討要件に分けておきます。

初回リリースでは、アセスメントからモニタリングまでを確実に運用することに絞ります。請求やAIは、連携条件を整理したあとに広げる方法もあります。

要件の抜けを防ぐため、業務範囲とシステムの運用条件をあわせて整理します。

  • 業務範囲:サービス種別、拠点数、利用者数、必要な帳票
  • システム連携:既存ソフト、予定・実績の交換、LIFE・医療機関との連携
  • 運用・管理:端末、通信環境、権限、ログ、バックアップの扱い
  • 導入後の責任:移行範囲、法改正時の更新責任、問い合わせ窓口の担当

フェーズ2:製品・開発方式の比較と選定

標準SaaS、パッケージ、既存製品への連携追加、ローコード、スクラッチ開発を比べます。標準の業務に合わせられる場合は、SaaSやパッケージのほうが、法改正対応や保守、導入期間を小さく抑えられます。

複数法人にまたがる独自の承認、既存基幹との深い統合、独自分析が競争力に直結する場合は、パッケージと個別開発を組み合わせる方法もあります。方式の違いは、業務への合い方、運用体制、拡張性から評価します。

  • 業務適合:標準機能で必要な流れに対応できるか
  • 運用体制:法改正、保守、障害時対応、研修を続けられるか
  • 拡張性:独自承認や基幹連携、経営分析が必要か

デモでは匿名化した実際の利用者ケースを使い、認定登録から計画変更までの流れを操作してもらいます。そのうえで、モニタリングと予定・実績の出力も確かめます。

確認するのは、入力回数、帳票の修正、誤入力の戻し方です。加えて、履歴、CSV、権限ごとの表示も見ます。

評価表には、機能の有無だけでなく、移行と標準仕様を含めます。さらに、セキュリティや障害対応、研修を項目に入れ、解約時のデータ返却と5年間の総額も、評価の対象にします。

AI機能がある製品には、提案の根拠と学習データの扱いを質問します。人の確認・修正・承認、操作ログ、停止方法も、あわせて尋ねておきます。

フェーズ3:業務画面・データ・連携の設計と開発

設計では、データの再利用と変更履歴を一貫して定めます。権限と安全管理も、同じ方針でそろえます。

  • データ設計:利用者、認定、アセスメント、計画、サービス、実績、モニタリング、請求を管理し、帳票や記録で再利用する
  • 履歴と権限:計画変更の履歴と、役割別の権限の設計
  • 安全管理:要配慮個人情報を守るための安全管理策の決定

計画の現行版と過去版を分け、修正者と承認者、日時を記録します。権限は役割ごとに分け、ケアマネジャー、サービス管理責任者、介護職を対象にします。看護職、請求担当、拠点・本部管理者も、この役割の対象に含めます。

安全管理では、暗号化、多要素認証、閲覧・出力・削除のログを定めます。あわせて、バックアップ、復旧手順、委託先との間でどこまでを誰が受け持つかも決めておきます。そのうえで、厚生労働省のガイドラインを参照し、自社規程とクラウド事業者の対策を対応表にまとめます。

ケアプランデータ連携システムのV4対応版は、2025年4月30日にリリースされ、国民健康保険中央会が運用しています(出典:国民健康保険中央会「ケアプランデータ連携システム」、2025年)。

2026年以降は、介護情報基盤との接続方針も変わる可能性があります。標準CSVの出力だけでなく、エラーを追えるかも確認します。また、現在の方式と将来の更新責任を契約に記載します。

フェーズ4:法定帳票・連携・現場操作のテスト

現場の一連の業務、例外処理、帳票と連携を通して確かめます。

  • 業務シナリオ:標準的な手順と、現場で起きる例外の両方
  • 帳票:第1〜3表、利用票・別表、施設系帳票の印刷・PDFを紙と照合し、文字切れ、改ページ、日付、単位、計画期間、利用者名、変更履歴を見る
  • 連携と移行:送受信の件数、項目、文字コード、重複、エラー再送、取消を確かめ、匿名化データを使った移行リハーサル

テストの範囲は、新規登録から更新までです。認定入力からアセスメント、計画書、会議まで、予定作成から実績取込、モニタリング、評価までを含みます。

要介護度の変更や計画の差し替えも試します。さらに、サービス中止、担当変更、複数拠点への異動も確かめます。

受入テストは開発会社だけで完了させず、現場の代表者も参加します。入力にかかった時間、迷った画面、紙に戻したくなった箇所を記録します。

重大不具合の定義、修正期限、再テスト、未解決事項の承認者を決めます。最後に、稼働判定会議で利用できる状態を合意します。

フェーズ5:小規模な稼働と全体展開

一部の拠点で運用を試し、移行の内容と切り替えの条件を確かめてから、全体に展開します。

パイロットでは、1拠点か1サービスを選びます。さらに、利用者数、ケアマネジャー数、帳票、外部連携の範囲を絞ります。

運用期間はシステムの規模によって変わるため固定しませんが、目安として2〜4週間程度の実運用で課題を出します。

  1. 月次の予定・実績処理を一度経験し、課題を整理したうえでの全体展開の判断
  2. 切替前に決めるもの:移行データ、バックアップ、旧システムの参照期間、紙帳票の保管、問い合わせ先、障害時の代替手順
  3. 移行後に照合するもの:件数、利用者と計画の紐付け、期間、担当者、履歴、未完了のモニタリング
  4. 切替時間帯と責任者、切り戻しの条件の用意

厚生労働省は、標準化対応済みの市町村から2026年4月1日以降に順次、移行と情報共有を始め、2028年4月1日までに全市町村での活用開始を目指しています(出典:厚生労働省「介護情報基盤について」、2026年)。

稼働判定では、現在の業務だけでなく、標準仕様や将来の連携更新に対応できる保守体制も確認します。

フェーズ6:研修とKPIによる現場への定着

全員一律の長時間研修より、役割別の短い研修と、実データに近い演習が向いています。

  • ケアマネジャー・介護職:計画・モニタリング、記録・申し送りを、実データに近い演習で習得
  • 管理者・請求担当:承認・未入力の確認、予定・実績とエラー対応の手順
  • 拠点の相談体制:操作に詳しい推進担当者による、現場内での一次相談対応

KPIは、ログイン回数だけでなく業務成果に結びつけておきます。たとえば、1利用者あたりの転記回数や、計画書作成から承認までの日数を、導入前後で比べます。

確認したいのは、モニタリングの未入力件数、FAX送信件数、記録の差し戻し件数です。さらに、月末の残業時間と連携エラー件数も見ます。

最初の30日、60日、90日で数値を確かめます。その結果をもとに、画面の変更や研修の追加を行う流れを回していきます。

AIは候補の提示や記録の要約にとどめ、生成された結果をそのまま正式な計画にしない運用にします。そのため、ケアマネジャーが根拠、本人の意向、家族の状況を確認・修正・承認する手順を定めておきます。

学習利用の可否、入力データの保存場所、ログ、誤った提案の報告先も、明文化しておきます。これらの確認は、AI利用への信頼を保つための条件になります。

ポイント

要件整理から小規模な稼働まで、工程ごとに終了条件を決めておくと、作業の抜けや追加要望による納期・予算の膨張を早めに見つけられます。

介護・福祉業向けケアプラン管理システムの費用相場とコスト内訳

費用は利用料だけでなく、総額で比べます。総額には、利用者数、拠点、サービス種別、帳票、移行、外部連携が含まれます。さらに、端末、セキュリティ、研修、保守、法改正対応も、総額の検討に入れます。

ここで示す数字は目安です。公開価格、一般的な業務システム開発の相場、介護固有の連携・安全管理の要件をもとにしたもので、このテーマ専用の公的な市場統計ではありません。最終的な金額は、要件と見積書で確定します。

公開価格から見えるSaaS・連携サービスの下限

公開されている価格は、標準の利用や連携基盤の料金なので、個別に導入したときの総額とは範囲が異なります。

  • ケア樹Free:1年目は税別52,000円・税込57,200円、2年目は税込46,200円
  • ケアプランデータ連携システム:1事業所番号あたり年額21,000円(税込)(出典:国民健康保険中央会「ケアプランデータ連携システムについて」、2026年確認)

ケア樹Freeは居宅介護支援向けで、価格は2025年9月の改定後の金額です(出典:株式会社グッドツリー「ケア樹Free」、2026年確認)。

小規模事業所向けには、年額数万円台の標準プランもあります。ただし、ケア樹Freeの価格には、個別帳票、移行、連携、訪問サポートを含む開発費は入っていません。

連携システムの料金も、基盤の利用料にあたります。ソフト本体、初期設定、移行、相手事業所との調整費は、この料金とは別になるため、連携料金だけで本体の予算を判断しないようにします。

導入形態ごとの初期費用・月額の目安

方式ごとの初期費用と月額は、標準SaaS、設定・移行付きパッケージ、個別・スクラッチ開発の3つに分けて示します。

  • 標準SaaS:初期0〜100万円程度、月額2万〜30万円程度
  • 設定・移行付きパッケージ:初期100万〜500万円程度、月額10万〜50万円程度
  • 個別・スクラッチ開発:初期300万〜2,000万円程度、月額10万〜100万円程度

小規模なSaaSの公開プランには、年5万〜30万円台の例もあります。ただし、複数サービスや拠点、利用者数、請求や記録の追加によって、金額は変わります。

契約単位が事業所・拠点・ユーザーのどれなのかを確認します。あわせて、閲覧だけの利用者にも課金されるかを確かめます。

パッケージは、データ整備や帳票の追加、複数拠点の権限が増えると上振れします。API・CSV連携や訪問支援も、同じく費用を押し上げます。見積書では、人月、拠点数、帳票数を分けて示してもらいます。

個別開発の金額は、製品の公表価格ではなく、一般的な業務システム開発の相場と要件をもとにした編集部の推定です。

複数法人の連携、24時間運用、医療連携、AI、独自分析、厳格な監査要件があると、2,000万円を超える可能性があります。

価格だけでなく、標準製品との差分が将来の業務価値につながるかを、あわせて見ます。

見落としやすい運用費と開発期間

運用費と導入期間は、契約後の負担や現場の混乱まで含めて比べます。

  • 継続費:ライセンス、クラウド、端末、通信、バックアップ、監視、保守、法改正、研修、問い合わせ、連携オプション
  • 終了・更新費:契約終了時のデータ出力、移行時の変換、保守終了時のアップグレード
  • 5年総額:初期費、月額・年額、従量課金、オプション、想定追加費を分けて積み上げた総額

開発期間の初期目安は、標準SaaSが1〜3か月、パッケージの設定・移行が3〜6か月、個別開発が6〜12か月以上です。期間は、データの品質、承認の速さ、連携の調整、受入テストの回数によって変わります。

短納期を優先してテストや研修を削ると、稼働後の二重入力や問い合わせが増えます。その結果、現場の混乱が、見かけの開発期間より長引くことがあります。

ポイント

初期費用や月額だけで比べず、移行、連携、端末、研修、保守、解約時の返却まで含めた5年総額で各社の提案を並べると、判断がぶれにくくなります。

見積もりを取る際のポイントとチェックリスト

見積条件をそろえるための事業所と業務範囲、連携要件、検収条件の3項目を並べたチェックリスト。
前提条件をそろえると、各社の見積もりを比べやすくなります。

見積もりの精度は、発注側が業務とデータを整理できているかで変わります。「使いやすい」「介護に詳しい」といった依頼では、各社の前提がそろわず、追加費用が発生しやすくなります。

RFPには、対象範囲、帳票、連携、移行を記載します。さらに、セキュリティ、研修、保守、納品するもの、検収条件も書き込みます。曖昧な依頼を避けるため、各社が同じ条件で積算できるようにします。

要件定義書とRFPに書く内容

見積もりの条件をそろえるため、RFPには業務範囲、連携仕様、受入時の確認条件を記載します。

  • 事業所と業務範囲:事業所の種類と規模、業務フローを明記
  • 連携要件:連携先、情報の交換条件、利用目的を整理
  • 検収条件:納品するものと、受入時に確認する条件の取り決め

業務範囲には、事業所の種別、拠点・ユーザー・利用者の数、端末の条件を書いておくと、各社の前提がそろいます。利用の仕方に関わる条件も見積もりの前提を固める材料になるため、次の項目もRFPに書き加えておきます。

  • 同時利用
  • 通信環境
  • 業務時間
  • 法定帳票
  • 対象期間とデータの保持年数

居宅と施設をまとめる場合は、共通フローと個別フローを分けます。匿名化したExcelや帳票の例を添付すると、必要な項目や画面を具体的に見積もってもらえます。

連携ごとに、相手システム、方向、頻度、項目、方式を表にまとめます。あわせて、エラー通知、再送、責任者も書き込みます。標準仕様、入退院時情報、訪問看護計画、LIFE、請求、会計も、対象に含めます。

各連携で使う情報と業務を示します。APIがない場合のCSVや手動の確認は、初期の範囲と将来の拡張に分けて書きます。

検収では、機能、帳票の一致、移行件数、連携の成功率を確認します。さらに、権限、性能、復元、ログも見ます。マニュアルや研修、未解決の重大不具合の数も含めます。

受入時に確認できない曖昧な条件は、追加費用や、受け持ちの範囲をめぐる争いにつながります。

複数社を同じ条件で比較する方法

候補は、標準SaaS、総合介護ソフト、複数拠点向けパッケージ、AIケアプラン、個別開発・PoCの5種類に分けて考えます。各候補は、知名度やAIの有無で判断せず、同じ質問票で評価します。

比較では、業務・制度、導入・運用、費用・リスクの3点をそろえて確認します。

  • 業務・制度:介護業務の理解、法改正への更新、標準仕様・API・CSV
  • 導入・運用:移行実績、サポート、改善体制、データ返却
  • 費用・リスク:初期費用、月額、5年総額、追加条件、障害対応

比較表には、移行費、連携費、端末・研修費を書き込みます。保守の範囲、障害対応時間、解約時のデータ形式も、同じ表に記載します。

未確定の価格は、「利用者数で変動」「帳票追加は別途」「連携先の試験後に確定」など、前提を明示してもらいます。

可能であれば、2〜3社に同じ匿名化ケースでデモを依頼し、現場の代表者が採点します。

入力の少なさに加えて、省略時の警告、履歴、検索、印刷、出力、エラーの分かりやすさを見ます。

候補企業には、同規模・同サービス種別の事例を尋ねます。あわせて、導入期間、利用率、転記・残業の削減、問い合わせ件数などの効果指標も確認します。

リスクと補助制度の見積もりへの反映

見積もりには、導入リスクへの対策と、補助制度を使えない場合の予算も含めます。

  • 導入リスク:要件定義、切替、移行、仕様、受け持ちの範囲、AI、法改正費のリスクへの備え
  • 仕様・AIの管理:仕様の版と更新責任の契約への明記、AIの人による承認の必須化、個人情報の保存・学習利用・ログの確認
  • 制度と予算:年度ごとの公募要件と事業予算の確認
  • 申請条件:補助金に頼らない予算の作成

現場の代表者を意思決定に加え、1拠点で検証し、移行リハーサルを行います。

補助制度については、国、都道府県、自治体の年度ごとの募集要項を確認します。申請前の契約や発注が認められない場合もあるため、募集要項と交付決定時期をあわせて確かめます。

厚生労働省は、令和7年度補正予算で「介護テクノロジー導入・協働化・経営改善等支援事業」に220億円を計上する予定を案内しています(出典:厚生労働省、2026年3月説明会案内)。

確認するのは、対象経費、申請者、申請の時期、標準仕様への対応です。さらに、契約・発注の時期、交付決定、実績報告、財産処分の制限、保守費も見ます。

対象の費用と対象外の費用を分け、採択を前提にはしません。補助金がなくても続けられるかを確かめるため、5年総額とROIを計算します。

ポイント

見積もりを頼む前に、事業所の種類と規模、業務フロー、連携先、検収条件を文書にしておくと、各社が同じ条件で積算でき、金額を比べやすくなります。

よくある質問(FAQ)

適切なシステムは、規模、事業形態、既存ソフト、連携範囲によって変わります。導入前によくある疑問と判断の目安を、あわせて確認します。

居宅介護支援と施設では、必要なシステムが違いますか?

居宅と施設では、必要なシステムが異なります。居宅では、計画書、利用票、担当者会議、モニタリング、事業所間の予定・実績の連携が中心です。

一方、施設では、施設サービス計画に加えて、介護・看護・栄養などの多職種記録、申し送り、日々の実績との連動が重要です。両方を運営する法人は、共通のデータと、サービス別の画面・帳票を分けて比べます。

クラウド型のケアプラン管理システムは安全ですか?

安全性は、クラウドかオンプレミスかという形態よりも、対策の中身で決まります。確認するのは、暗号化、多要素認証、役割別権限です。さらに、操作・出力ログ、バックアップ、復旧目標も見ます。

脆弱性への対応、委託先の管理、退職者のアカウント停止、解約時のデータ返却も確認します。そのうえで、自社端末やパスワードの運用を含め、どこまでを誰が受け持つかを一覧にし、事故時の連絡と初動を契約に記載します。

AIが作ったケアプランをそのまま使えますか?

AIは、候補の提示や情報の整理を支援する機能として扱い、そのまま正式な計画にはしません。正式な計画にするまでに、ケアマネジャーが本人の意向、生活状況、家族の希望、医療情報、サービス提供の可能性を確かめます。

修正と承認の手順も定めておきます。また、提案の根拠、参照データ、生成日時、修正者の記録が残るか、入力情報が学習に使われるかを、ベンダーに確認します。

導入費用に補助金を使える可能性はありますか?

可能性はありますが、年度、自治体、対象サービス、製品要件、申請時期によって異なります。厚生労働省や都道府県の公募要領で、標準仕様への対応や導入後の効果報告が条件に含まれるかを確認します。

採択前の契約が対象外となる場合もあります。そのため、補助金に頼らない予算を作り、申請用の見積書や導入効果の資料を早めに準備します。

ポイント

居宅と施設の違い、クラウドの安全性、AIの扱い、補助金の条件は、規模や連携範囲で答えが変わります。社内の前提を決めてから、ベンダーに確かめるのが確実です。

まとめ:6フェーズで小さく検証し、現場に定着させる進め方

導入前に確認する最終チェック

開発は、現状業務とデータの流れを整理することから始まります。目的と範囲を決め、方式を比べ、画面と連携を設計してから、帳票・移行・権限をテストします。

その後は、1拠点や1サービスで稼働させ、研修とKPIで定着を図ります。導入前の最終確認では、3つの視点をそろえます。

  • 現場と業務:目的、対象範囲、優先順位、業務フロー
  • データと安全:連携、移行、権限、法改正・保守の責任
  • 導入判断:小規模検証、5年総額、効果を測るKPI

次に進めるべき準備

費用は公開SaaS価格から個別開発まで幅があるため、初期費用だけでは比べられません。5年総額には、移行や連携、端末の費用を含めます。研修、保守、法改正、解約時の返却も、同じ総額に入れます。

転記時間、FAX、残業、記録漏れ、連携エラーなどのKPIで効果を確かめます。2026年以降の介護情報基盤や標準仕様の更新を見据え、将来の連携責任まで確認したうえで、方式を選びます。

▼全体ガイドの記事
・介護・福祉業向けケアプラン管理システム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。