利用者管理システムの発注・外注は、利用者台帳を中心に、記録・請求から家族や関係機関との情報共有までの業務範囲を先に決め、クラウド導入、パッケージのカスタマイズ、個別開発から自社に合う方法を選ぶ流れで進みます。
その後は、RFPで要件を整理し、契約形態、委託先、見積もりの順に比べます。
▼全体ガイドの記事
・利用者管理システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
利用者管理システムの発注・外注で最初に決める範囲
発注前に決めたいのは、画面の見た目よりも、どの情報を正とし、どの業務へ再利用するかです。
利用者情報の入力先が曖昧なまま開発会社へ相談すると、台帳はできても、記録や請求との連携が課題として残ります。そのため、期待した効果が出にくくなります。
業務をつなぐ共通マスタとしての位置づけ
氏名や住所の検索だけを目的にすると、記録や請求の業務で同じ情報を入れ直すことになりがちです。そこで、利用者管理システムは業務をつなぐ共通マスタとして設計します。
基本情報と保険情報を一度登録しておけば、その情報を業務ごとに入れ直さずに使えます。登録する対象には、家族・緊急連絡先、要介護度、ADLが含まれます。そのほか、服薬や医療の情報、同意状況も対象です。
登録した情報は、ケア記録から監査用帳票まで、5つの業務へ引き継がれます。
- ケア記録：利用者の基本情報を、日々の対応の起点にする
- 計画書：同じ基本情報をもとに作成する
- 予約・入退所：受付から退所までの手続きで使う
- 請求：登録済みの保険情報を、入れ直さずに使う
- 監査用帳票：記録や請求の履歴を、あとから確かめられる状態にする
利用者の登録や変更が複数の画面に反映される仕組みを先に決めると、入力漏れや転記ミスを減らせます。たとえば、入所時に登録した保険情報が請求側に連携され、退所後も履歴として参照できる状態が理想です。
2025年4月に、ペースノート老健とケアカルテのAPI連携が始まり、利用者基本情報や保険情報をワンクリックで反映できるようになりました。この事例は、システムの価値が入力画面の数ではなく、業務間のデータ連携にあることを示しています（出典: 株式会社ペースノート、2025年）。
発注者側の現場・決裁者・情報システムの役割分担
発注担当者だけで要件を作ると、決裁者の重視する投資効果、現場の重視する入力のしやすさ、情報システム部門が確認するセキュリティや保守条件が抜けがちです。そのため、事業責任者と現場の代表、請求担当を集め、情報システムか個人情報管理の責任者も加えて、要件を決める会議体を最初に作ります。
現状の業務は「利用開始」「日々の記録」「計画の更新」「請求」「退所・情報提供」に分け、誰が、いつ、何を入力し、誰が承認するかを洗い出します。さらに、職員数や拠点数だけでなく、利用者数、サービス種別、既存ソフト、紙で残す書類、家族への情報提供方法まで書き出すと、外注範囲を過不足なく決められます。
発注形態の選び方：クラウド・カスタマイズ・個別開発の違い
標準的な介護・福祉業務を早く安定させたい場合は、クラウドやパッケージを優先します。既存システムとの連携や独自業務が効果の中心であれば、カスタマイズを検討します。
個別開発は、多拠点・多法人で独自の利用者ポータルや基幹連携まで必要になる場合に限って候補にするのが現実的です。
標準業務を短期間で整えるクラウド・パッケージ
クラウド型は、サーバーを自社で用意せず、月額料金で利用する方式です。バックアップや法改正に伴う更新、障害対応をベンダーに任せやすく、初期投資を抑えて導入できます。
一方で、項目名や帳票、承認フローを製品の標準に合わせる場面があります。そのため、現場のこだわりをすべて追加機能にせず、どこまで標準に合わせるかを判断します。
発注時は、利用者台帳があるかだけでなく、記録・計画・請求とのデータ連携、利用者数や職員数による料金の変わり方、CSV出力、データ移行、解約時の返却条件を比べます。クラウドとオンプレミスの優劣は、アクセス権限、認証、ログ、バックアップ、委託先の運用体制を同じ基準で評価して決めます。
パッケージ＋カスタマイズ・API連携という中間案
標準の介護記録や請求機能は既製品を使い、利用者台帳、家族連絡、予約、ベッド管理、法人内の拠点共有など、不足する部分だけを追加する方法です。ゼロから全機能を作らないため、初期費用と開発期間を抑えながら、自社の重要な業務に合わせやすくなります。
連携を依頼するときは、APIの有無だけでなく、どの項目をどちら向きに連携するか、更新日時と重複判定をどう扱うか、エラー時に誰が再送するかまで決めます。APIがない場合、画面のスクレイピングで代わりにすると、相手製品の画面変更で壊れやすくなります。そのため、標準APIやCSVを優先します。
独自性と将来拡張の優先度で見るスクラッチとローコード
スクラッチ開発は、多数の拠点・法人をまたぐ共通台帳、医療と介護を横断するデータ連携、独自の家族向け画面、既存基幹との複雑な連携が必要な場合に適します。
ただし、要件が固まらないまま全機能を一括発注すると、仕様変更、データ移行、制度改定対応が重なり、予算と納期が膨らみやすくなります。そこで、第1段階で利用者マスタと権限、第2段階で記録・請求連携というように分けます。
ローコードは、台帳、申請、通知などを短期間で試作しやすい一方で、複雑な請求、厳密な訂正履歴、複数サービス間の整合性、長期保守には専門的な設計が必要です。試作の速さだけで決めず、データの持ち出し、ライセンス変更、障害時の復旧、担当会社を変える際の引き継ぎまでRFPに記載します。
RFPと要件整理の進め方
RFPとは、発注者が開発会社やベンダーへ提示する提案依頼書です。
良いRFPは、機能一覧だけでなく、解決したい業務課題と対象範囲を最初に示します。そのうえで、現行環境やデータ、連携の条件を書き、運用、納品物、評価基準まで同じ資料にまとめます。
提案会社が同じ前提で見積もれるため、価格と提案内容を比較しやすくなります。
現行業務と導入後の業務フローの一覧化
まず、紙台帳やExcel、既存の介護記録ソフトや請求ソフトを洗い出します。会計や給与などのソフトも含めます。そのうえで、利用開始から退所後の保存までを時系列に並べ、誰が入力し、誰が参照し、誰が承認し、誰が出力するかを明記します。
発注側は、各機能を「必須」「できれば必要」「今回は対象外」に分けておきます。たとえば、利用者の重複登録防止と権限は必須にします。監査ログや保険期限のアラートも、導入初日に必要な範囲に入れます。
一方で、AIによる記録要約や家族向けポータルは、効果を検証してから第2段階に回す方法があります。要望は全部入れず、導入初日に必要な範囲を先に決めます。
機能要件としてのデータ項目・権限・履歴の定義
利用者台帳の項目は、氏名や住所、生年月日、連絡先のほかにも必要です。家族・緊急連絡先、保険者番号、負担割合、認定期間などは、業務で使う単位に分けて定義します。
医療・服薬情報、ADL、同意取得状況も対象に含めます。あわせて、契約や保存に関わる項目も台帳で扱います。
- 契約書類：利用者台帳の項目として扱う
- 利用開始・終了日：利用期間の始まりと終わりを台帳で把握する
- 退所後の保存期間：退所後も記録を参照できる期間として定義する
自由記述のままでは、集計や連携が難しくなります。そのため、選択肢、必須条件、変更履歴の残し方も決めておきます。権限は、見られるかどうかだけでなく、閲覧、登録、修正、承認、印刷、CSV出力ごとに分け、施設や職種、担当ケースの単位で最小限に設定します。
退職者や異動者のアカウント停止、緊急時のアクセス、操作ログの保存期間もRFPに入れます。医療情報を扱う場合は、厚生労働省が2026年6月に改訂した「医療情報システムの安全管理に関するガイドライン第7.0版」も確認します。そのうえで、委託先との責任分界を明記します（出典: 厚生労働省、2026年）。
将来連携を見据えたAPI・標準仕様・データ返却の確認
2026年4月以降、標準化対応が完了した市町村から介護情報基盤へのデータ送信が始まり、2028年4月には介護情報基盤を経由した情報共有の本格運用開始が予定されています（出典: 厚生労働省「介護情報基盤に係る自治体説明会」資料、2026年）。今すぐすべてを作り替える必要はありませんが、将来の標準連携を妨げないデータ項目、同意、アクセス制御、APIの設計は、発注段階で確認します。
RFPには、対応予定のケアプランデータ連携標準仕様、CSVやAPIの仕様書、連携できる項目、エラー通知、データの更新責任を記載します。さらに、契約終了時に誰が、どの形式で、どの期間にデータを返却するか、バックアップの削除証明を出せるかも押さえます。移行しやすいデータ形式を最初から選ぶことは、将来のベンダーロックインを抑える対策になります。
契約形態と開発手順の設計
契約は、要件変更、成果物、検収、障害対応、知的財産、データ管理のルールを決めるものです。
要件が十分に固まっているか、発注者側が開発中に優先順位を変える可能性があるかによって、請負契約と準委任契約の使い分けを検討します。
成果物と責任で見る請負と準委任の違い
請負契約は、合意した成果物を完成させ、検収を受けることを中心に責任を定める契約です。画面、機能、テスト結果、操作マニュアルなどを成果物として明確にしやすい一方、契約後の追加要望は変更管理が必要です。何をもって完成とするか、検収期間、修正対応の範囲は、契約書や個別仕様書に残します。
準委任契約は、専門人材の稼働や業務遂行を委託する形で、要件を検証しながら進める開発に向きます。利用者や現場の意見を試作品で確かめる段階では有効ですが、納品される機能、稼働時間、報告、品質確認の方法が曖昧にならないようにします。どちらが適切かは、名称だけで判断せず、法務・契約担当とも相談して決めます。
要件定義・試作・本開発・移行の契約上の区分
利用者管理システムでは、最初から全機能を固定するより、要件定義または小規模なPoCを先行し、その成果をもとに本開発を契約する段階方式が安全です。第1段階では利用者マスタ、重複判定、権限、検索、CSV出力を確認し、第2段階で記録・請求・予約などの連携を追加する流れが考えられます。
工程ごとに、担当者、期限、入力データ、成果物、承認者、次工程へ進む条件を決めます。試験では正常系だけでなく、同姓同名、保険情報の更新、退所後の閲覧、権限外の検索、通信障害、連携エラーも確かめます。
現場の代表が、実データに近いサンプルで受入テストを行うと、稼働後の手戻りを抑えられます。
検収後の保守・法改正・障害時対応の取り決め
納品後も、利用者情報を扱うシステムは、法改正、OSやブラウザの更新、脆弱性、職員の異動、拠点追加への対応が続くため、月額保守の範囲は、問い合わせ、障害復旧の目標時間、バックアップ、制度改定対応で分けて確かめます。追加開発の単価も、別に確認します。
障害時には、誰が一次受付をし、どの情報をどの経路で連絡し、紙運用へ切り替えるかを決めます。個人情報の漏えいが疑われる場合の報告、アクセス遮断、ログ保全、利用者や家族への説明も含めたインシデント対応手順は、開発会社の保守範囲と自社の運用範囲に分けておきます。
利用者管理システムの費用相場と見積もり内訳
費用は、利用者管理だけを使うのか、記録・計画・請求・予約・外部連携まで含めるのかで大きく変わります。ここに示す金額は、公開されている介護ソフトの価格と、類似する業務システムの情報をもとにした目安です。
「利用者管理システム単独」の公的な統計はないため、スクラッチのレンジは推定として扱います。最終的な判断は、同じ要件で取った個別見積もりで行います。
クラウド型の費用目安：初期0〜30万円、月額5,000〜5万円程度
ITreviewが2026年に掲載する介護ソフトの相場では、小規模事業所向けは初期費用0〜10万円・月額5,000〜15,000円です。中規模向けは初期10〜30万円・月額15,000〜40,000円、大規模法人向けは初期30万円以上・月額50,000円以上です。出典は、ITreview「介護ソフト（介護記録管理）」（2026年）です。
公開料金の比較例として、カイポケの通所介護向けは月額25,000円、初期費用・サポート費用0円です。職員・利用者・端末数による追加料金はなく、その旨が案内されています（税別、出典: 株式会社エス・エム・エス「カイポケ通所介護の利用料金」、2026年確認）。
トリケアトプスは初期費用0円で、サービス種別により利用者1人あたり月220〜440円などの従量課金と上限額を公開しています（出典: トリケアトプス公式料金ページ、2026年確認）。
利用者管理に絞った場合でも、金額は次の条件で変わります。
- 拠点数・利用者数：料金が増減する単位になる
- 連携：既存ソフトとの接続費用の有無
- 研修：職員向けの操作研修の有無
- データ移行：元データを移すための作業費用
そのため、この相場をそのまま自社の価格とは考えません。このような公開価格は比較の起点になりますが、独自の移行・連携費用が含まれるかは別途確認します。
パッケージ設定・連携・移行を加えた初期費用
パッケージを法人向けに設定する場合は、初期設定、権限設計、帳票変更、拠点追加を分けて見積もります。既存ソフトとのAPI・CSV連携、マスタ整備、データ移行、操作研修も、それぞれ別に出してもらいます。類似する法人・多拠点向けでは、設定・導入支援を含む初期費用30万〜200万円程度、月額5万〜30万円程度が目安になることがありますが、これは個別要件を前提とした幅のある参考レンジです。
特に移行費用は、元データの形式と品質で変わります。Excelが拠点ごとに分かれ、同じ利用者が異なる氏名表記や旧住所で登録されている場合、名寄せ、重複確認、欠損補完、本人確認の工数が発生します。「移行一式」とまとめず、対象件数、項目、変換ルール、検証回数、現場確認の担当を見積書に記載してもらいます。
スクラッチは500万〜2,000万円程度の推定レンジと内訳
複数サービス、既存基幹、権限・監査、外部API、データ移行を含むスクラッチ開発は、初期500万〜2,000万円程度、開発期間6〜15か月程度が一つの推定レンジです。ただし、これは「利用者管理システム」専用の公開統計ではなく、一般的な業務システムの目安を医療・介護の要件に合わせて補正したものです。
小規模な台帳だけであれば下回ることも、医療情報連携や多法人統合で上回ることもあります。見積書では、要件定義、UI・データ設計、開発、API連携を項目別に出してもらいます。加えて、セキュリティ対策、テスト、移行、研修、リリース支援、保守も分けて記載してもらいます。
さらに、運用に関わる費用を月額・年額で分けて、3年または5年の総額を比較します。運用費用には、クラウド利用料、バックアップ、監視のほか、次の費用も含まれます。
- 端末：職員が使う端末にかかる費用
- 認証サービス：ログインや本人確認の仕組みにかかる費用
- 法改正対応：制度改定に合わせた改修にかかる費用
- 追加拠点の費用：拠点を増やしたときの追加分
初期費用の安さだけで発注すると、後から必要な費用が見えにくくなります。
委託先の選び方と見積比較のポイント
委託先は、知名度や提示価格だけでなく、利用者情報を扱う業務への理解、既存システムとの連携力、導入後の支援体制で選びます。
完成済みの製品を導入するベンダーと、ゼロから個別開発するSI会社では役割が違うため、提案書の中で、何を提供する会社かを確かめます。
介護・福祉の業務とデータ移行を説明できる会社
候補会社には、同じサービス種別の導入実績や利用者情報の移行件数を確かめます。既存の記録・請求ソフトとの連携実績、標準仕様への対応状況も見ておきます。実績の社名だけでなく、どの課題を、どの期間で、何人・何拠点に導入し、稼働後にどの指標が改善したかまで聞くと、提案の再現性を見極めやすくなります。
デモでは、利用者登録から記録、計画、請求への連携を一連の流れで見せてもらいます。同姓同名の検索、保険情報の更新、権限外データの表示、退所後の履歴、スマートフォン入力、通信が不安定な場所での動作など、実際の業務に近いシナリオで確認します。
会社の営業担当だけでなく、導入後のサポート責任者にも同席してもらうと安心です。
同じ条件と総額で行う相見積もり
相見積もりは、同じRFP、同じサンプルデータ、同じ対象拠点、同じ納期で依頼します。比較表には、初期費用、月額・年額、保守を並べ、ほかに次の項目も入れます。
- データ移行：元データの整備を含めた範囲と費用
- 連携：既存ソフトとつなぐ範囲と費用
- 研修・追加開発：操作の教育と、後からの機能追加の扱い
- 端末・法改正対応：利用機器の費用と、制度改定への対応
- 解約・データ返却：契約終了時に、データをどう返すかの条件
安い見積もりでは機能が不足して、後から別発注になる可能性があります。そのため、機能の有無だけでなく、標準対応かオプションか、追加費用の算定方法まで記録します。価格差が大きい場合は、単価の違いよりも、見積もりに含まれる範囲を確かめます。
価格差の背景には、要件定義を含まず本開発だけを安く示しているケースや、移行データの整備を発注者側の作業としているケース、保守や制度改定対応が別料金のケースがあります。質問への回答速度、リスクの説明、できないことを明示する姿勢も、契約後の信頼性を判断する材料です。
セキュリティ・サポート・契約終了時の条件
個人情報を扱うため、通信や保存時の暗号化、二要素認証、脆弱性対応、バックアップを確認します。監査ログや権限管理、委託先の再委託、データ保管場所、障害時の復旧目標も見ておきます。
セキュリティチェックシートの提出だけでなく、実際のログ画面やアカウント削除の手順、復元テストの実施頻度まで聞くと、運用の実効性を確認できます。
契約終了や委託先の変更に備えて、次の条件を押さえておきます。
- データ返却：利用者データを、CSVや標準形式で全件返せるか
- 返却対象：画像・添付書類・操作ログを含め、返却後のベンダー側の複製も削除されるか
- 契約上の取り決め：データの所有権、利用権、バックアップ、再委託、秘密保持
導入を失敗させないための運用設計
発注の成否は、納品日ではなく、現場が正しいデータを入力し、必要な人が必要な範囲で使い続けられるかで決まります。
導入前に移行・教育・問い合わせ・評価の運用を決め、稼働後の改善を発注範囲に含めておきます。
1事業所・1サービスのPoCから始める段階的な展開
全拠点を一度に切り替えると、業務の違い、データの欠損、職員の習熟度の差が同時に表面化します。そのため、まず代表的な1事業所または1サービスで、利用者登録、検索、記録、請求連携の一連の流れを試し、入力時間、二重入力の件数、問い合わせ、請求エラー、利用率を測ります。
PoCでは、成功条件を「使えた」で終わらせず、測定できる条件で決めます。たとえば、利用者情報の二重登録を一定割合減らす、月末の転記時間を削減する、必須項目の未入力を減らすといった条件です。結果をもとに画面や権限を修正してから、次の拠点へ展開します。
移行・教育・旧運用の終了条件
データ移行は、元データのバックアップや項目の対応表を用意したうえで、名寄せ、テスト移行、本番移行、件数照合、現場確認の順に進めます。同姓同名や表記ゆれは、自動判定だけで確定せず、候補を現場担当者が確認します。移行後に紙や旧Excelを誰が更新するかを決めずにおくと、新旧データが再び分かれてしまいます。
研修は全員に同じ説明を一度するだけでなく、管理者、入力担当、請求担当、閲覧のみの職員に分けます。操作マニュアル、短い動画、問い合わせ窓口、よくある質問を用意し、旧運用をいつ終了するかを決めます。例外的に紙へ戻す場合も、後から誰がシステムへ反映するかを明確にします。
導入後90日のKPIと人による承認
導入後90日は、利用者登録にかかる時間や重複登録の件数、記録の未入力を定期的に確認します。請求前の修正件数や問い合わせ件数、ログイン率、職員の習熟度も見ていきます。削減した時間だけでなく、情報の正確性、監査資料を探す時間、家族への回答の速さなど、経営・現場・管理の複数の指標で効果を評価します。
AIで記録の要約や検索を補助する場合も、ケア判断や請求確定を自動化する前提にはしません。利用者本人への説明や同意、出力の確認、誤りの訂正、承認者の記録を設け、人が最終確認する運用にします。システムを導入する目的は、入力を機械に置き換えることではなく、利用者情報を正確に引き継ぎ、ケアと事務の品質を上げることです。
利用者管理システムの発注・外注でよくある質問
発注前によく寄せられる疑問を、費用、開発方式、セキュリティ、導入期間などの観点から回答します。自社の条件によって最適な答えは変わるため、ここでの回答をそのまま仕様にせず、RFPの確認項目として使います。
利用者管理システムの開発費用はいくらですか？
標準的なクラウド型は、公開相場として初期0〜30万円、月額5,000〜5万円程度が目安です。
独自の権限、複数拠点、データ移行、API連携、帳票、研修を含むパッケージ設定は30万〜200万円程度、複数サービスを個別開発する場合は500万〜2,000万円程度を推定レンジとして考えます。ただし、いずれも要件で変動します。
クラウドとスクラッチ開発はどちらを選べばよいですか？
標準業務を早く安定させたい、法改正やバックアップを任せたい場合は、クラウドやパッケージが向きます。
多拠点・多法人の独自業務や複雑な連携が競争力に直結する場合は、パッケージのカスタマイズや段階的なスクラッチ開発を検討します。
RFPは自社だけで作成できますか？
現行業務、対象範囲、必須機能は、自社で整理できます。データ項目、連携先、予算と納期の前提も、自社で整理できます。
要件の漏れや優先順位に不安がある場合は、開発会社と契約する前に、要件定義だけを第三者へ支援してもらう方法もあります。RFPには提案会社へ確認したい質問と、評価基準も入れます。
利用者情報をクラウドに預けても安全ですか？
安全性は、クラウドかオンプレミスかよりも、管理の中身で決まります。
二要素認証や最小権限、暗号化、操作ログを確認します。脆弱性対応、バックアップ、復旧手順、委託先との責任分界も確かめ、自社の個人情報保護規程と照らし合わせて判断します。
医療情報を扱う場合は、厚生労働省の安全管理ガイドラインに沿った確認項目を契約前に整理します。
導入までの期間はどのくらいかかりますか？
小規模なクラウド導入は2週間〜2か月、パッケージの設定や連携を含む導入は1〜6か月程度が目安です。複数サービス・多拠点のスクラッチ開発は、要件整理から本番移行まで6〜15か月程度になることがあります。
データの名寄せ、現場の検証、研修を後回しにすると期間が延びるため、開発期間だけでなく準備期間も計画します。
まとめ
利用者管理システムを発注・外注するときは、台帳の画面を作ることから始めず、利用者情報を記録・計画・請求・家族や関係機関との情報共有へつなぐ業務基盤として範囲を定めます。
標準業務が中心ならクラウドやパッケージ、独自連携が重要ならカスタマイズ、独自性が高い場合に段階的な個別開発を選びます。
発注前にRFPへ書く項目の整理
現行業務と導入後のフロー、利用者マスタの項目、権限と監査ログをRFPに入れます。加えて、既存ソフトとの連携、データ移行、標準仕様、保守、障害対応、データ返却もRFPに入れます。
見積もりは初期費用だけでなく、月額・保守・研修・追加開発を含む3年または5年の総額で比較し、同じ条件で複数社へ依頼します。
最初の一歩となる、現場を含めた要件整理
まず、1事業所の代表的な業務を選び、紙・Excel・既存ソフトに分散している情報と二重入力を洗い出します。
発注側が必須範囲を小さく定め、RFP、デモ、相見積もり、PoC、段階導入の順に進めると、費用とリスクを管理しやすくなります。
利用者と職員の双方にとって使い続けられる仕組みになるよう、開発会社と運用の責任分担まで話し合うことが重要です。
▼全体ガイドの記事
・利用者管理システム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。