後期高齢者医療システム開発の見積相場や費用/コスト/値段について

結論：後期高齢者医療システムの開発費用は、システム本体の価格だけで決まりません。

住民基本台帳・税・国民健康保険・収納システムとの連携、後期高齢者医療広域連合とのデータ授受、

データ移行、帳票、クラウド利用料、制度改正対応まで含めて見積もる必要があります。

本記事では、2026年時点で公開されている自治体の調達事例をもとに、後期高齢者医療システム開発の費用・相場・コスト・値段を案件範囲別に整理します。

過渡期の連携対応から標準準拠システムへの移行、大規模な再構築までの価格帯、費用が変動する要因、

見積書で確認する項目、コストを抑えながら品質を落とさない方法を解説します。

▼全体ガイドの記事
・後期高齢者医療システム開発の完全ガイド

後期高齢者医療システム開発の費用相場はいくらですか？

後期高齢者医療システムの開発費用に、全国共通の定価はありません。市区町村が利用する窓口・資格・賦課・徴収システムだけを対象にするのか、

広域連合側のシステムや医療費助成まで含めるのかによって、必要な機能と費用が変わるためです。

さらに、既存パッケージを改修する案件と、標準準拠システムへ移行する案件では、同じ「システム開発」

でも見積もりの構成が異なります。

初期相談時の仮置きとしては、既存システムの過渡期連携・制度改修なら150万円から1,500万円程度、

標準準拠パッケージへの移行なら3,000万円から1億5,000万円程度が一つの目安です。

複数業務との連携を含む大規模な移行は1億円から3億円程度、独自要件が多い再構築やスクラッチ開発は3億円から8億円超になることがあります。

これらは公開された後期高齢者医療単体の標準価格ではなく、自治体基幹システムの公開調達と案件範囲から推定したレンジです。

見積もりを比較するときは、初期費用だけでなく、5年から10年の総保有コスト（TCO）で見ることが大切です。

初期費用が安くても、毎年の制度改正対応やクラウド従量料金、帳票印刷、運用要員、データ抽出費用が高い場合は、

長期的な負担が大きくなります。

公開調達から見る後期高齢者医療システムの価格帯

公開調達で確認できる金額は、後期高齢者医療システムだけをゼロから作る場合の価格表ではありません。

移行、連携、機器、運用保守など、契約に含まれる範囲を読み取って比較する必要があります。

ここでは、2025年度から2026年度に確認できる公開事例を、費用の大きさではなく、

何に対する支出かという観点で見ていきます。

150万円台の過渡期連携・既存パッケージ対応

浦安市の2025年度の公開資料では、後期高齢者システムの標準化過渡期連携業務委託が158万4,000円と公表されています。

これは特定移行支援システムとのデータ連携など、限定された業務範囲の金額です。すでに稼働しているパッケージを利用し、

接続先や変換処理を追加するだけなら、このような小規模案件になる可能性があります。

1,000万円前後のIF・文字変換・切替対応

• 確認対象：この見出しで扱う範囲と前提を整理します。
• 比較の観点：初期・継続・追加の要素を分けて確認します。
• 判断の基準：自社の要件と運用体制に照らして検討します。

富田林市の2025年度の随意契約一覧では。富士通JapanのMCWEL後期高齢者システムに関する標準化過渡期連携対応が1,075万8,000円と公表されています。

税データ連携、IF変換ツール、連携テスト、文字変換、システム入替、本稼働対応などが含まれるため、単なる設定変更よりも高額です。

外字や旧システムのデータ形式、連携先の数が増えると、同じパッケージでも費用が上がります。

5億円台の移行・長期運用保守

• 確認対象：この見出しで扱う範囲と前提を整理します。
• 比較の観点：初期・継続・追加の要素を分けて確認します。
• 判断の基準：自社の要件と運用体制に照らして検討します。

世田谷区の2025年度調達の説明書では、現行システムからガバメントクラウド上の標準準拠システムへの移行に加え。

2027年から2031年までの運用・保守などを含む提案限度額が税込5億9,070万円でした。

2025年度の移行業務だけで見ると上限は税込5,623万2,000円です。

この事例は大規模区の移行・長期運用を含むため、後期高齢者医療システム単体の初期開発費として扱うことはできませんが。移行と保守を一括契約すると総額が数億円規模になることを示しています。

機器・ミドルウェア・基盤更改は別レイヤーで考えます

• 確認対象：この見出しで扱う範囲と前提を整理します。
• 比較の観点：初期・継続・追加の要素を分けて確認します。
• 判断の基準：自社の要件と運用体制に照らして検討します。

京都府後期高齢者医療広域連合の公開契約では、ミドルウェア調達が税込711万143円。電算処理システムの機器更改および運用計画などの作成が税込6億5,576万7,200円と公表されています。

後者は単一機能の開発ではなく、機器・基盤・計画策定を含む契約です。アプリケーション開発費、基盤費、機器費、運用計画費を混ぜると価格比較を誤るため、見積書では項目を分けて提出してもらいます。

費用の根拠として参照する標準仕様書も固定ではありません。厚生労働省の「標準仕様書（後期高齢者医療）」では、2026年1月の第1版、機能・帳票要件、帳票詳細要件、帳票レイアウトが公開されています。

RFPや見積依頼書には、どの版への適合を前提にするかを明記し、改版時の対応費用を別枠で確認します。

後期高齢者医療システム開発の費用内訳

後期高齢者医療システムの見積もりは、「開発費一式」とまとめず、業務・データ・基盤・運用のレイヤーに分けると比較しやすくなります。

最低限、次の項目を見積書に記載してもらいます。

要件定義・Fit & Gap分析費

• 確認対象：この見出しで扱う範囲と前提を整理します。
• 比較の観点：初期・継続・追加の要素を分けて確認します。
• 判断の基準：自社の要件と運用体制に照らして検討します。

現行業務の棚卸し、標準仕様書とのFit & Gap分析、責任分界の整理、業務フロー作成、RFI・RFPの支援にかかる費用です。

市区町村の窓口担当、徴収担当、税担当、住基担当、広域連合、現行ベンダーなど、参加者が多いほど調整工数が増えます。

標準機能で業務を合わせる範囲、自治体固有の運用として残す範囲、廃止・後期高齢者医療システム開発する範囲を早い段階で決めると、後工程の手戻りを抑えられます。

資格・賦課・徴収・給付などのアプリケーション費

• 確認対象：この見出しで扱う範囲と前提を整理します。
• 比較の観点：初期・継続・追加の要素を分けて確認します。
• 判断の基準：自社の要件と運用体制に照らして検討します。

主な機能には、宛名・世帯・住民基本台帳との連携、資格の取得・喪失・異動、所得情報を利用した保険料の賦課、軽減・減免。

普通徴収・特別徴収・併行徴収の収納、高額療養費などの給付申請、照会・統計・監査用の検索があります。

既存パッケージを導入する場合は、ライセンス、利用団体数、同時利用者数、設定、追加開発を分けます。スクラッチ開発では、画面数よりも業務ルール、年度更新、例外処理、履歴・監査要件が工数に影響します。

連携・データ移行・文字変換費

• 確認対象：この見出しで扱う範囲と前提を整理します。
• 比較の観点：初期・継続・追加の要素を分けて確認します。
• 判断の基準：自社の要件と運用体制に照らして検討します。

後期高齢者医療システムでは、広域連合との資格・所得・収納データの送受信が中心になります。加えて、住民基本台帳、税、国民健康保険、収納、番号連携、医療費助成、電子申請、帳票印刷などとの接続を設計します。

連携ごとに、データ項目、送受信方向、頻度、文字コード、エラー時の再送、責任者、テストデータを定義するため、連携本数が増えるほど費用が上がります。

移行では、宛名、資格、賦課、収納、還付、滞納、給付などのデータを抽出・クレンジング・変換・突合します。

外字、旧住所、氏名変更、世帯分離、過年度の更正、重複宛名が残っていると、移行設計と検証に時間がかかります。

本番切替前に複数回のリハーサルを行い、件数一致だけでなく、金額、資格状態、年度、還付状況まで業務単位で確認することが重要です。

帳票・印刷・通知対応費

• 確認対象：この見出しで扱う範囲と前提を整理します。
• 比較の観点：初期・継続・追加の要素を分けて確認します。
• 判断の基準：自社の要件と運用体制に照らして検討します。

納付書、保険料決定通知書、変更通知、督促、還付通知、資格関係の通知など、自治体業務では帳票が多くなります。

帳票の種類、レイアウト、宛名印字、封入・封緘、再発行、点字や読みやすさへの配慮、電子通知との併用が費用に影響します。

標準帳票を採用できる場合は追加費用を抑えやすい一方、自治体独自の文言や印刷工程を残すと、設計・テスト・制度改正時の修正費が増えます。

クラウド・運用保守・制度改正対応費

• 確認対象：この見出しで扱う範囲と前提を整理します。
• 比較の観点：初期・継続・追加の要素を分けて確認します。
• 判断の基準：自社の要件と運用体制に照らして検討します。

クラウド利用料、データベース、バックアップ、監視、ログ保管、通信、障害対応、問い合わせ窓口、定期メンテナンス、職員の権限棚卸しなどがランニング費用になります。

ガバメントクラウドを利用する場合も、利用料が自動的に最安になるとは限りません。

デジタル庁は、標準化・ガバメントクラウド移行後に費用増が見込まれる自治体があることも説明しているため、利用料、運用作業。移行後の最適化を分けてTCOを試算します。

制度改正対応は、改修費の単価、年間の対応回数、標準仕様書改版への追随範囲、緊急改修の扱いを契約で定めます。

「法改正対応は保守に含む」とだけ書くと、帳票変更、データ移行、テスト、職員説明まで含むのか判断できません。

通常改正、軽微な改修、緊急対応、自治体独自変更の4区分で単価と納期を確認します。

後期高齢者医療システムの費用が変動する7つの要因

被保険者数は参考になりますが、費用を決める唯一の指標ではありません。少人数の自治体でも、

古いデータや独自帳票、複雑な連携が残っていれば高額になることがあります。特に次の7項目を、

見積依頼の前提条件として整理します。

• 対象範囲：市区町村の窓口・徴収だけか、広域連合、医療費助成、保健事業、コールセンター照会まで含むかで変わります。
• 被保険者数と自治体数：データ量やピーク時の処理量、共同利用の単位、権限設計に影響します。
• 連携先と連携本数：住基、税、国保、収納、広域連合、番号連携、電子申請などの接続が増えるほど設計・テスト費が増えます。

現行データの品質：外字、重複宛名、過年度データ、欠損、コード体系の違いが移行費を左右します。

標準仕様との差分：独自画面、独自帳票、独自の賦課・減免運用を残すほど追加開発が必要になります。

移行方式と切替条件：一括切替、並行稼働、複数回のリハーサル、繁忙期を避けた切替などで期間と費用が変わります。

運用・セキュリティ要件：24時間監視、災害復旧、多要素認証、操作ログ、バックアップ世代数、復旧目標、再委託管理の水準が費用に反映されます。

2026年の標準化動向が費用に与える影響

地方公共団体の基幹業務システムは、原則として2025年度末までに標準準拠システムへ移行する方針で進められてきました。

2026年度以降に移行せざるを得ないシステムは、現行システムがメインフレーム、個別開発、

事業者撤退、事業者リソース不足などの事情を確認したうえで、特定移行支援システムとして移行完了期限を設定します。

デジタル庁の2026年7月更新ページでは、2026年3月末時点で、標準準拠システムへの移行対象となる全34,366システムのうち10,013システム、

29.1％が特定移行支援システムとされています。これは後期高齢者医療システムだけの数字ではありませんが、

2026年以降も移行案件、過渡期連携、現行システムの延命対応が続く背景を示しています。

自団体が該当するか、該当する場合の期限、支援対象、現行システムをいつまで維持するかを、

ベンダー任せにせず確認します。

また、デジタル庁は2026年7月28日にデータ要件・連携要件標準仕様書の改定スケジュールを更新しています。

標準仕様書は一度導入したら終わりではなく、改版への追随が継続します。見積もりでは、

初期移行費の安さだけでなく、版更新時の調査、影響分析、改修、テスト、リリースまでの費用を5年分程度で比較します。

詳しくは、デジタル庁「地方公共団体の基幹業務システムの統一・標準化」で、特定移行支援システムの状況、

ガバメントクラウド、共通機能、データ要件・連携要件の更新を確認できます。自治体の調達担当者は、

RFIの実施時点とRFPの公告時点で、参照する版が変わっていないかを確認します。

後期高齢者医療システムのコストを最適化する8つのポイント

コスト最適化は、機能を削って安くすることではありません。制度上必要な処理、住民への通知、

監査・セキュリティ、障害時の業務継続を守りながら、重複開発や不要なカスタマイズを減らすことです。

次の順番で検討すると、価格と品質のバランスを取りやすくなります。

1. 標準機能・独自要件・廃止対象を分けます

• 確認対象：この見出しで扱う範囲と前提を整理します。
• 比較の観点：初期・継続・追加の要素を分けて確認します。
• 判断の基準：自社の要件と運用体制に照らして検討します。

現行画面をそのまま新システムに再現する前に、業務を「法令・標準仕様上必須」「自治体として必要」「慣習的に残っている」に分類します。

慣習的な帳票や二重入力を廃止できれば、追加開発だけでなく、テスト、研修、制度改正時の保守費も減らせます。標準仕様書の機能・帳票要件と現行業務を並べたFit

& Gap表を作り、差分の理由を記録します。

2. 標準パッケージを第一候補にします

• 確認対象：この見出しで扱う範囲と前提を整理します。
• 比較の観点：初期・継続・追加の要素を分けて確認します。
• 判断の基準：自社の要件と運用体制に照らして検討します。

後期高齢者医療は、資格、賦課、徴収、給付、帳票、年度更新など制度業務の共通部分が多いため、標準パッケージの設定変更と連携拡張を基本にすると。

スクラッチ開発より初期費用と将来の改修費を抑えやすくなります。

ただし、パッケージ価格だけで決めず、標準仕様書の適合確認、広域連合との接続実績、データ抽出の可否、契約終了時の返却条件を確認します。

3. 移行前にデータを棚卸しします

• 確認対象：この見出しで扱う範囲と前提を整理します。
• 比較の観点：初期・継続・追加の要素を分けて確認します。
• 判断の基準：自社の要件と運用体制に照らして検討します。

移行費は、実際にデータを抽出してみるまで不確定になりがちです。資格、賦課、収納、還付、滞納、宛名を業務単位で一覧化し、保存年限、件数、欠損、外字、コード、更新頻度、移行後の利用目的を確認します。

不要な履歴を新システムに持ち込まない判断も、移行費と保守費の削減につながります。ただし、監査・返還・住民問い合わせに必要な過年度情報を一律に廃棄しないよう、保存要件を確認します。

4. 連携方式と責任分界を先に決めます

• 確認対象：この見出しで扱う範囲と前提を整理します。
• 比較の観点：初期・継続・追加の要素を分けて確認します。
• 判断の基準：自社の要件と運用体制に照らして検討します。

連携先ごとに個別の変換処理を作ると、初期開発費だけでなく、制度改正時の保守費も増えます。標準化されたデータ要件・連携要件を利用し、共通の変換基盤や再利用可能なIFを設計できないか検討します。

市区町村、広域連合、現行ベンダー、新ベンダーのどこが抽出・変換・送信・エラー対応を担うかを責任分界表に記載し、二重計上や対応漏れを防ぎます。

5. クラウド費を従量項目まで分解します

• 確認対象：この見出しで扱う範囲と前提を整理します。
• 比較の観点：初期・継続・追加の要素を分けて確認します。
• 判断の基準：自社の要件と運用体制に照らして検討します。

クラウド費は、月額固定費だけでなく、データ転送、ログ保管、バックアップ、監視、検証環境、繁忙期の性能増強などで変動します。

通常月、年度更新月、災害時、リハーサル時の利用量を想定し、上限額とアラートを設定します。

複数業務を同一基盤に載せる場合も、業務別の利用量と負担割合を分けておくと、後からコストの原因を追跡しやすくなります。

6. 初期費用と保守費を分けて比較します

複数年契約を結ぶ場合は、移行、ライセンス、クラウド、運用、制度改正、追加開発、問い合わせを分けて提示してもらいます。

初年度だけ安く、2年目以降に保守や改版費が膨らむ提案もあるため、年度別の支払額と5年TCOを同じ表で比較します。

固定価格に含む作業と、別途請求になる作業、単価、上限、変更管理の手順を契約書に記載します。

7. RFIとRFPで競争条件を整えます

• 確認対象：この見出しで扱う範囲と前提を整理します。
• 比較の観点：初期・継続・追加の要素を分けて確認します。
• 判断の基準：自社の要件と運用体制に照らして検討します。

現行ベンダーからしか情報が出ない状態では、データ移行費や保守費の妥当性を比較できません。

RFIで複数ベンダーに、対応製品、標準仕様書の版、移行可能時期、広域連合との接続、外字・帳票、クラウド構成、制度改正対応。契約終了時のデータ返却を同じ質問で確認します。

RFPでは価格だけでなく、標準適合の証跡、移行リハーサル、障害復旧、操作教育、運用体制を評価項目に入れます。

8. 稼働後の職員負担も費用として測定します

• 確認対象：この見出しで扱う範囲と前提を整理します。
• 比較の観点：初期・継続・追加の要素を分けて確認します。
• 判断の基準：自社の要件と運用体制に照らして検討します。

開発費が安くても、毎月の手作業、二重入力、エラー確認、帳票の再発行、ベンダーへの問い合わせが増えると、実質的なコストは高くなります。

稼働後に、処理時間、問い合わせ件数、再処理件数、帳票エラー、手作業の時間、障害復旧時間を測定します。

職員が使いにくい画面を我慢して使う前提にせず、窓口担当や徴収担当を受入テストに参加させ、改善効果を確認します。

見積依頼・RFPで確認すべき項目

見積もりの精度を上げるには、ベンダーに金額だけを聞くのではなく、前提条件と成果物をそろえて提示します。

次の項目をRFI・RFPの質問票に入れると、提案間の比較がしやすくなります。

• 標準仕様書の対象版と、機能・帳票要件への適合状況
• 標準準拠システム、特定移行支援システム、過渡期連携の対応実績
• 市区町村と後期高齢者医療広域連合の責任分界

住基、税、国保、収納、番号連携、医療費助成、電子申請との接続範囲

移行対象データ、抽出方法、変換、クレンジング、突合、リハーサル回数

外字、文字コード、宛名、帳票レイアウト、印刷・封入・電子通知の対応

初期費用、移行費、連携費、教育費、クラウド費、保守費、制度改正費の内訳

通常時・繁忙期・障害時の性能、バックアップ、復旧目標、監視、ログ保全

再委託先、データ所在地、契約終了時のデータ返却・消去・移行支援

標準仕様書改版時の対応期限、費用負担、テスト・リリース手順

特に重要なのは、見積もりの除外事項です。「データ移行は別途」「帳票変更は別途」「制度改正は都度見積もり」

とだけ書かれている場合、初期予算に含まれない作業が多く残ります。作業単位、数量、

単価、前提、納品物、受入基準、追加費用が発生する条件を記載してもらいます。

費用と期間を抑える開発の進め方

後期高齢者医療システムの移行は、契約してから要件を考えると遅延しやすくなります。

標準仕様書と現行業務の差分、データの状態、広域連合との接続条件を先に確認し、見積もりの不確実性を減らします。

一般的には、次の順番で進めます。

1. 現状把握：業務フロー、利用者、処理件数、帳票、連携先、データ保存状況、現行契約を棚卸しします。
2. Fit & Gap：標準仕様書の機能・帳票要件と照合し、標準利用、設定、追加開発、廃止に分類します。
3. RFI：複数ベンダーに標準適合、移行時期、費用、保守、契約終了条件を確認します。

方式選定：既存パッケージ継続、標準パッケージ移行、ガバメントクラウド、スクラッチのTCOを比較します。

移行・連携設計：データ項目、変換、エラー処理、再送、責任分界、テストデータを定義します。

テスト・切替：年度更新、75歳到達、転入転出、所得更正、保険料変更、死亡、還付、再送などを検証します。

稼働後運用：制度改正、権限棚卸し、ログ監査、バックアップ復元、クラウド費、問い合わせを定例化します。

短期間で安く導入することだけを目標にせず、切替後に業務が止まらないことを優先します。

年度更新や保険料通知の時期を避け、並行稼働や本番切替リハーサルを計画します。費用を削る場合も、

移行検証、障害復旧、監査ログ、セキュリティテストを削らないことが重要です。

後期高齢者医療システム開発のよくある質問

後期高齢者医療システムの開発費用は、1億円以内に収まりますか？

小規模な既存パッケージの改修や標準準拠パッケージへの移行であれば、1億円以内に収まる可能性があります。

ただし、税・住基・収納・広域連合との連携、データ移行、帳票、研修、クラウド、複数年の保守まで含めると、

自治体規模によっては1億円を超えます。まず初期構築費、移行費、運用費、制度改正費を分けて見積もります。

パッケージ導入とスクラッチ開発はどちらが安いですか？

• 確認対象：この見出しで扱う範囲と前提を整理します。
• 比較の観点：初期・継続・追加の要素を分けて確認します。
• 判断の基準：自社の要件と運用体制に照らして検討します。

一般には、制度業務に対応した標準パッケージを利用し、設定変更と必要な連携だけを追加する方が、初期費用と制度改正対応費を抑えやすいです。

ただし、既存データの品質、独自帳票、連携方式、ライセンス条件によっては移行費が高くなることがあります。初期費用だけでなく、5年から10年のTCO、データ返却、ベンダーロックインのリスクまで比較します。

ガバメントクラウドに移行するとコストは必ず下がりますか？

必ず下がるとは限りません。セキュリティ、災害対策、運用の共通化、拡張性などの効果が期待できる一方、

クラウド利用料、ネットワーク、監視、バックアップ、移行、運用設計によっては費用が増える場合があります。

通常時だけでなく、年度更新、検証環境、データ転送、ログ保管、障害時の復旧まで含めた利用量で試算します。

2026年度以降も現行システムを使い続けられますか？

2026年度以降の移行となることが具体化したシステムは、特定移行支援システムとして個別の完了期限や支援状況を確認します。

すべての自治体が自由に期限を延長できるという意味ではありません。自団体の対象業務、

移行計画、標準化基準の適用日、過渡期連携の必要性を、デジタル庁・総務省・制度所管省庁の最新情報とベンダーの計画で確認してください。

見積もりを取る前に自治体側で準備すべき資料は何ですか？

• 確認対象：この見出しで扱う範囲と前提を整理します。
• 比較の観点：初期・継続・追加の要素を分けて確認します。
• 判断の基準：自社の要件と運用体制に照らして検討します。

現行システムの構成図、業務フロー、機能・帳票一覧、連携一覧、データ項目と件数、外字の有無、利用者数、ピーク時の処理量、過去の障害、保守契約。切替希望時期を準備します。

これらがそろうほど、ベンダーは前提をそろえた見積もりを出しやすくなります。資料が不足している場合は、要件定義・現状調査を先行する費用も含めて提案してもらいます。

後期高齢者医療システム開発の費用・相場まとめ

後期高齢者医療システム開発の費用は、過渡期連携・制度改修で150万円から1,500万円程度、

標準準拠パッケージへの移行で3,000万円から1億5,000万円程度、大規模な複数業務連携で1億円から3億円程度、

独自要件の多い再構築で3億円から8億円超が初期検討時の目安です。ただし、公開調達の金額は契約範囲によって大きく異なるため、

単純な価格表として扱わないようにします。

適正な見積もりを作るには、システム本体と、要件定義、データ移行、広域連合・住基・税・収納との連携、

帳票、クラウド、運用保守、制度改正対応を分けます。さらに、標準仕様書の版、特定移行支援システムの扱い、

移行リハーサル、障害復旧、データ返却条件までRFPに記載し、初期費用ではなく5年から10年のTCOで比較します。

コストを最適化する基本は、標準機能を優先し、不要な独自カスタマイズを減らし、移行前にデータを整理し、

連携と責任分界を明確にすることです。安さだけでベンダーを選ぶのではなく、標準適合の証跡、

データ移行の実績、広域連合との接続力、制度改正への追随、運用体制を総合的に評価します。

▼全体ガイドの記事
・後期高齢者医療システム開発の完全ガイド

会社紹介

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

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

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

株式会社riplaの会社HPはこちら

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

執筆者プロフィール

張田谷凌央

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