年金システム開発の発注/外注/依頼/委託方法について

年金システムの発注は、対象制度と責任の分け方を決め、要件と計算事例を整え、移行と検証まで委託範囲に含めると、給付や支払を安定して運用しやすくなります。

方式や費用、委託先の選び方も、この流れに沿って順に説明します。

▼全体ガイドの記事
・年金システム開発の完全ガイド

年金システムの概要と発注範囲の決め方

年金システムは、制度のルールをデータと計算に反映し、加入と受給の記録を給付や報告へつなぐ業務基盤です。

対象は、公的年金と企業年金、確定拠出年金、個人年金保険に分かれます。

発注書には対象制度を明記し、管理する範囲と連携先を切り分けておきます。

企業年金と個人年金保険の区別

制度が違えば、管理する情報も計算の単位も変わります。対象制度ごとに、この違いを整理しておきます。

  • 企業年金:制度・規約マスタ、事業所、加入者、受給権者、扶養情報、資格取得・喪失、休職・復職、給与連携、掛金、給付、退職一時金、源泉徴収、基金経理、帳票
  • DB・DC:確定給付企業年金(DB)は給付の算定と長期の履歴、確定拠出年金(DC)は拠出・配分と、記録関連運営管理機関との連携が重要
  • 個人年金保険:生命保険会社の契約、証券、保険料、積立金、予定利率、年金開始、支払、解約・減額、受取人、税務、数理計算、代理店・顧客チャネル連携

キャッシュバランス制度や旧厚生年金基金の記録を含む場合は、制度の適用時点を正確に再現できるかを確かめます。

企業年金と個人年金保険では計算単位とデータの正本が異なるため、RFPには契約・被保険者・受取人のどの情報を管理するかを記します。

機能一覧より先のデータの正本の決定

主要機能と連携対象を洗い出すと、発注範囲を具体化できます。

  • 制度・記録:制度・規約・給付設計マスタ、加入者・受給権者台帳、資格異動
  • 計算・支払:掛金・拠出金、給付、遡及裁定、支払、源泉徴収、年金経理
  • 運用・統制:帳票、電子申請、ポータル、権限、操作ログ、バックアップ
  • 外部連携:人事給与、会計、銀行、信託銀行、生命保険会社、記録関連運営管理機関

連携方式は、APIや暗号化ファイルから、閉域網や手動取込まで含めて選びます。

金額だけでなく、規約版や加入者の履歴、入力値を追跡できる設計にします。端数処理と承認者も、追跡できるようにします。

受信やエラーの件数、照合差額、再処理の結果も記録しておく必要があります。記録がなければ、判断の根拠が担当者のExcelだけに残ってしまいます。

ポイント

発注範囲は、対象制度ごとの計算単位とデータの正本が一致するかで区切ると判断しやすくなります。正本を先に決めておけば、機能一覧の洗い出しも進みます。

年金システムの発注・外注の進め方

年金システムの発注が現状分析から提案比較、設計・移行・受入、本番切替を経て保守へ進む流れを示した図。
本番切替の前に移行リハーサルと受入が続きます。

年金システムの発注は、現状分析から保守まで段階を踏んで進みます。発注側には業務責任者を置き、各成果物の承認者も決めておきます。

  1. 現状分析、RFI、要件定義、RFPを順に行う
  2. 提案を比較し、契約先を決める
  3. 設計・設定・開発、移行リハーサル、テスト、受入を進める
  4. 並行稼働と本番切替を経て、保守へ移る

製品デモや画面から始めると、規約の例外や旧制度の履歴、支払の締め、連携エラーが後から見つかりやすくなります。

現行業務とデータの洗い出しとRFI

候補会社に同じ前提で回答してもらうため、業務資料と規模の数字をそろえます。

  • 業務資料:規約・細則、給付設計書、事務処理要領、計算表、帳票、申請書
  • 運用資料:月次・年次の締め手順、現行項目定義、連携ファイル、手作業のチェックリスト
  • 規模情報:制度・事業所・加入者・受給権者数、履歴年数、資格異動・年間支払件数
  • 処理条件:帳票数、連携本数、同時利用者数、許容停止時間

データは項目名や形式などを一覧にします。欠損や重複、訂正履歴の扱いも、同じ表に書いておきます。たとえば、資格喪失日が空欄なら、未入力か受給待期かで給付判定が変わります。

RFIでは、対象制度の実績や標準機能を尋ねます。移行方法と法改正への対応、保守もあわせて質問します。期間と概算費用も、同じ回答に含めてもらいます。

数字がそろうほど、候補会社の回答も同じ前提にそろいます。

個人情報を含むサンプルは、マスキングとアクセス管理を済ませてから渡します。

RFPに載せる計算事例と受入条件

RFPには対象業務と提案条件を記します。そのうえで、計算事例を使って制度要件を具体的に示します。

  • 対象と規模:目的、制度、業務、利用者、データ量、連携先、帳票
  • 導入と運用:非機能要件、移行範囲、教育、保守、費用の提示形式
  • 計算事例:入力値、期待結果、根拠規約、計算日、承認者
  • 例外ケース:休職・復職、転籍、死亡、再加入、遡及、支給停止、過払い訂正、制度改定の境界日

受入条件には、金額の一致と件数の照合、差異の説明、再計算を含めます。帳票と支払ファイル、ログも受入の対象です。権限、性能、障害復旧も条件に加えます。

発注側は、シナリオの件数と実施回数、重大障害の上限、未解決差異の承認者も明記します。

提案書では、標準機能と設定、追加開発を分けてもらいます。

業務変更への対応も、別の項目として示してもらいます。

移行リハーサルと旧新の並行計算の範囲

移行の品質を確かめるには、複数回のリハーサルと補正ルールの合意が欠かせません。

  • 移行確認:抽出、変換、取込、件数・金額照合、履歴確認を行う
  • データ補正:欠損・重複を補正する時期、担当者、ルールを決める
  • 旧記録:旧厚生年金基金や制度統合前の記録は、保管・参照方法を設計する

切替の前に、代表ケースと全件データを旧新システムで並行計算します。

掛金と給付、支払額を、加入者・受給権者ごとに照合します。源泉徴収や会計仕訳、通知書も、同じ単位で突き合わせます。

差異は、まず規約の解釈と入力データのどちらが原因かで分けます。端数や旧制度の扱いによる差異は、別に分類します。

検収の条件には、重大な未解決差異がないことと、支払データを承認できることを含めます。

障害が起きたときに備え、ロールバックと手作業の代替手順も実際に動かして確かめます。

ポイント

製品デモに進む前に、要件と計算事例がそろっているかで判断します。そろっていなければ、現行業務の洗い出しとRFIを先に進めます。

年金システムの発注形態の選び方

パッケージ、クラウド・SaaS、スクラッチ、ハイブリッドの特性を4つのパネルで示した図。
標準機能を活かす方式と独自要件に合わせる方式があります。

発注形態には、パッケージやクラウド・SaaS、スクラッチなどがあります。ハイブリッドや要件定義の先行委託も含めて比べます。判断の基準は、制度改正への対応と長期履歴、計算根拠です。加えて、連携先の拡張や5年後の保守性も見ます。

パッケージ・クラウドの標準機能と責任の分け方

標準機能を活かせるか、運用の責任を分けられるかを、方式選定の基準にします。

  • パッケージ:制度知識を取り込みやすく、法改正や保守を計画しやすい
  • クラウド・SaaS:初期インフラを抑え、バックアップ、監視、複数拠点利用、災害対策を標準化しやすい

パッケージでは、Fit to Standardを優先します。独自の制度や特殊帳票は、設定かアドオン、追加開発のどれで対応するかを分けて考えます。特に、個別の改修を重ねると、バージョンアップや制度改正のたびに費用が増えやすくなります。

クラウド契約では、保管場所とテナント分離、暗号鍵を確認します。ログや可用性、目標復旧時間も、契約の前に見ておきます。また、障害連絡と、サービス終了時のデータ返却も契約に定めます。

基盤の管理は委ねられます。ただし、制度の解釈と入力の正確性は発注側に残ります。計算結果の承認や支払指図も、発注側が担います。

スクラッチ・ハイブリッドの長期変更の見積もり

独自要件の程度と、複数社の責任の分け方を見て、個別開発の範囲を決めます。

  • スクラッチ:独自給付、特殊連携、保険契約・数理処理、既存基幹との深い統合に向く場合がある
  • ハイブリッド:制度・給付・台帳をパッケージ、ポータル・分析・連携をクラウドや個別開発に分ける

スクラッチでは、制度改正のたびに分析と改修、回帰テストと計算検証が必要になります。そのため、年金業務と技術の人材を継続して確保し、規約版と適用期間を管理できる設計にする必要があります。

ハイブリッドは費用と変更範囲を抑えやすい一方で、正本、再計算、連携障害の責任を定める必要があります。手動運用への切替も決めておきます。RFPには構成図とデータフローを添えて、各社に同じ責任の分け方で見積もってもらいます。

資料が不足する場合の要件定義の先行委託

本開発の前に現状分析を委託すると、対象制度や概算工数が整理でき、相見積もりに進めます。

  • 調査対象:例外処理、データ品質、連携、移行方針
  • 成果物:業務フロー、機能・非機能要件、計算事例、データ項目表
  • 計画資料:課題一覧、優先順位、概算計画、RFP

先行委託先が本開発を有利に運ぶ可能性も、あらかじめ考慮しておきます。

成果物の著作権と利用権、第三者への開示は、契約で定めます。データの返却と、入札に使える形式も、契約に書いておきます。

本開発を別の会社に委託する可能性があるなら、特定の製品に依存しない業務要件と比較の基準を求めます。

年金システムの契約形態の使い分け

準委任と請負は、不確実性と成果物の明確さに応じて、工程ごとに使い分けます。契約名だけでなく、作業範囲や成果物、検収の条件まで確認します。変更管理や責任の分け方、再委託、データの扱いも、あわせて確かめます。

準委任契約が向く調査・要件定義・保守

制度の解釈や現行データの品質が未確定な段階では、完成物を先に固めるより、専門家と発注側が一緒に作業を進められる準委任が適しています。

  • 対象工程:調査、業務整理、要件定義、プロジェクト管理、運用支援
  • 定める内容:稼働時間、会議体、報告書、課題管理、意思決定支援

作業の証跡としては、月次の調査報告や課題一覧、RFP案を定めます。さらに、計算事例やデータ診断、次工程の見積条件も証跡として残します。

制度仕様を承認する人や、回答が遅れた場合の期間延長は、契約書と個別仕様書に記します。再委託の範囲と機密情報へのアクセス方法も、同じ書類に書いておきます。

請負契約の成果物と検収条件

完成させる成果物が明確な設計や開発の工程は、請負に向きます。

  • 主な成果物:基本設計、設定済みパッケージ、追加機能、連携プログラム、移行ツール
  • 運用資料:テスト仕様書、操作マニュアル

検収では、画面の表示だけでなく、計算結果と規約版を確かめます。履歴や帳票、支払データも対象です。ログや性能、脆弱性への対応も含めます。

要件変更をすべて追加費用とするのか、法改正や規約改定を保守に含めるのかを、あらかじめ分けておきます。

例外が見つかったときの協議や、追加見積の期限、納期への影響も定めます。

瑕疵対応と損害賠償を明記します。さらに、再委託の承認と契約終了時のデータ返却も定めます。計算誤りが起きたときは、制度仕様、入力データ、プログラムのどこに原因があるかを切り分ける手順を決めておきます。

個人情報・再委託・法改正の契約条項

契約では、個人情報の管理、再委託、制度改正への対応範囲を具体的に定めます。

  • 情報管理:氏名、住所、生年月日、給付情報、基礎年金番号、個人番号を扱う可能性がある
  • 安全管理:委託先の選定、取扱状況の把握、秘密保持、目的外利用の禁止、持ち出し制限、漏えい時の責任、返却・廃棄、教育、報告、監査を定める
  • 再委託:委託先、業務範囲、データ保管場所、アクセス権、監査方法、事故時の連絡経路を把握する
  • 制度改正:分析、仕様変更、開発、テスト、リリース、利用者告知のうち月額保守に含む範囲を分ける

個人番号を扱う場合、個人情報保護委員会の特定個人情報ガイドラインは委託先の監督を求めています。

FISC「金融機関等コンピュータシステムの安全対策基準・解説書」は2025年3月に第13版が発行されました(出典:FISC、2025年)。

同書は金融機関等の安全対策を示す資料です。そのため、案件ごとに適用範囲を確かめ、年金システムすべてに一律で適用される法律としては扱いません。

厚生労働省の施行スケジュールでは、2026年4月に企業型DCの手続き簡素化と拠出限度額拡充が予定されています(出典:厚生労働省「私的年金制度の主な改正事項の施行スケジュール」、2026年)。

同スケジュールでは、2026年12月にiDeCoの加入可能年齢と拠出限度額の引き上げも予定されています(出典:厚生労働省「私的年金制度の主な改正事項の施行スケジュール」、2026年)。

DCを扱う契約では、法改正の情報収集と回帰テストの責任者を、あらかじめ明らかにします。

ポイント

工程ごとに、成果物を今の時点で固められるかで準委任と請負を分けます。個人情報や再委託、法改正の条項は、どちらの契約でも省けません。

年金システムの費用相場と見積もり内訳

簡易ツール、専門パッケージ、複数制度統合、大規模刷新の初期費用レンジを横棒で比較した図。
対象範囲が広がるにつれて、初期費用のレンジも上がります。

全国共通の公開価格表は少ないため、ここで示すのは2026年時点の概算レンジです。

費用は、制度数や加入者・受給権者数、履歴年数で変わります。さらに、連携本数やデータ品質、帳票の量も影響します。監査、可用性、移行・並行稼働の有無も、費用を左右します。

この概算は、同じ条件で見積もるための基準として使い、価格を保証するものとは扱いません。

規模別の初期費用の目安(300万円〜10億円超)

対象規模と移行・連携の範囲ごとに、初期費用と導入期間を見積もります。

  • 簡易ツール:制度・利用者・連携が限定され、大規模な過去履歴移行がない場合、300万〜3,000万円、1〜3か月程度
  • 専門パッケージ:設定、初期移行、人事給与・会計・記録関連運営管理機関との1〜3本の連携、教育を含み、1,000万〜5,000万円、3〜9か月程度
  • 複数制度統合:DB・DC・退職一時金・旧制度、複数拠点、長期履歴、ポータル、支払、経理、並行計算を含み、5,000万〜3億円、9か月〜2年程度
  • 大規模刷新:大量データ、高可用性、複雑な独自給付、複数外部機関、厳格な監査、段階移行を含み、3億〜10億円超、18か月〜3年以上となる可能性

JUAS「ソフトウェア・メトリクス調査2025」は、195プロジェクトの費用と工数の回帰分析から人月単価127.14万円を妥当と報告しています(出典:一般社団法人日本情報システム・ユーザー協会、2025年)。

この単価で計算すると、30人月は約3,814万円、100人月は約1億2,714万円になります。ただし、年金案件では規約の解析やデータ移行が加わるうえ、全件検証と法改正テストも必要です。そのため、この機械的な計算をそのまま契約価格とはみなしません。

要件・開発・移行・保守を分けた見積もり

見積項目を分けると、作業範囲と抜け漏れを比較しやすくなります。

  • 要件・分析:要件定義、制度分析は10〜20%程度
  • 設計・実装:設計・実装は40〜50%程度
  • 検証:テスト・計算検証は15〜25%程度
  • 導入:インフラ・移行・教育は10〜25%程度

この配分は、年金案件の公定比率ではありません。比較用に作業範囲を分解するための目安です。

初期費用のほかに、クラウドとネットワークの費用が発生します。監視やバックアップ、脆弱性診断、保守も、別途かかります。

法改正や追加帳票の対応、問い合わせ対応にも費用がかかります。教育や外部接続、データ返却も、費用の対象です。

保守費を初期開発費の年10〜20%程度で仮置きする方法もあります。実額は、SLAや休日対応の範囲で変わります。さらに、法改正や更新、障害対応の範囲でも左右されます。

初期費用と5年間の利用・保守・移行・終了費用を合算して比べます。

5年TCOによる安さと将来負担の比較

5年間の導入・運用・終了費用を通算し、製品ごとの将来負担を比べます。

  • 初期・導入費:初期開発、導入支援、データ整備、移行リハーサル
  • 利用・運用費:クラウド・ライセンス、保守、法改正、追加連携、監査、教育、障害対応
  • 終了費:契約終了時のデータ返却費用
  • 将来負担:パッケージは制度知識や回帰テストが保守に含まれる場合があり、スクラッチは人員交代や制度変更のたびに解析・改修費が発生する可能性がある

候補会社には、年度別の費用と価格の前提を示してもらいます。

加入者や制度、連携先が増えたときの追加単価も確かめます。法改正や障害復旧の対応にかかる単価も、あわせて確認します。最低利用期間と解約予告は、契約の前に確かめます。データ形式や撤去費、保守終了後の支援も確認します。

発注側が契約条件を見落とすと、乗り換えの時点でベンダーロックインに陥るおそれがあります。

ポイント

初期費用の幅は対象範囲で変わるため、同じ条件で見積もる基準として使います。内訳は要件、開発、移行、保守に分け、5年間の総額で比べます。

年金システムの委託先選定と見積比較のポイント

委託先は、知名度や価格ではなく、対象制度と役割の適合性で選びます。

企業年金基幹や旧制度の履歴・遡及裁定、DC連携では、必要な専門性が異なります。企業型DCの人事事務や基金経理クラウド、中小企業の制度DXでも、求められる専門性は変わります。

同じ質問票と計算事例で評価し、提案の見栄えよりも、移行・検証・保守を実行する体制を確かめます。

年金業務の実績と担当者の専門性

実績と担当者を確かめる質問をそろえると、導入後の対応力を見極めやすくなります。

  • 導入経験:可能なら同規模・同制度の事例で、制度種別、対象人数、導入時期、移行履歴年数、連携先
  • 稼働後の経験:並行稼働、保守年数、計算検証、切替差異、障害・法改正対応
  • 担当体制:年金業務、移行、品質保証、保守の各責任者が提案に参加するか

大手SIerは、統合や大規模な管理に強みがあります。一方で、制度の判断を別の会社に頼る場合もあります。年金専門のベンダーは規約や給付、履歴に強い反面、クラウドや全社基幹との統合範囲を確かめる必要があります。

DC連携会社や経理クラウド会社には、基幹全体を扱えると誤認しないよう、対象外の業務と連携方法を尋ねます。

同じWBSと前提条件による見積書の比較

作業分解構成(WBS)を共通にして、総額の内訳と評価の観点をそろえます。

  • 共通の作業項目:要件定義、Fit&Gap、設計、設定、追加開発、インフラ、連携
  • 導入作業:データクレンジング・整備、移行、テスト、並行稼働、教育、保守、法改正対応
  • 明細条件:工数、人月単価、前提、対象外、再委託費、税、納期

評価表では、業務適合性と計算再現性、移行・検証、連携を採点します。セキュリティや可用性、保守の扱いも採点します。さらに、法改正への対応と体制、契約も評価の対象に入れます。

配点の例では、価格に30点を置きます。機能・業務適合は25点、移行・テストは20点です。体制・保守は15点、セキュリティ・契約は10点です。この例のように評価の観点を先に決め、安さだけで有利にならないようにします。

安さの裏にある追加費用とロックイン

初期見積の対象外費用と将来の乗換条件を確認し、総費用を見通します。

  • 対象外費用:履歴、特殊給付、帳票、連携、性能試験、診断、教育、休日切替、法改正、問い合わせ
  • 変更単価:追加開発、連携先追加、制度追加の費用
  • 移行条件:標準形式の出力、設定・計算ルールの文書化、権利、運用手順、第三者保守
  • 解約時:履歴、証跡、帳票、添付資料の返却形式、期限、費用

起こりやすい変更は別見積にしておくと、予算の超過を事前に見通せます。

候補会社が、発注側の将来の選択肢まで説明できるかも、選定の材料になります。

ポイント

委託先は、対象制度の専門性と移行・検証の実行体制で絞り込みます。見積は同じWBSと前提条件で並べ、対象外費用とロックインを見て判断します。

よくある質問(FAQ)

費用や方式は、制度とデータの条件によって変わります。回答をRFPに移すときは、対象範囲と前提を確かめます。

年金システムの開発費用は最低いくらですか?

初期費用は、対象範囲の規模に応じて幅があります。

  • 限定ツール:計算・照会・経理補助に絞ると300万〜3,000万円程度が推定の目安
  • 複数制度対応:長期履歴、支払、経理、外部連携、移行、並行計算まで含めると1,000万〜5,000万円以上
  • 大規模刷新:統合基幹では数億円から10億円超となる可能性

最低価格よりも、移行・テスト・保守の対象範囲を確かめてください。

パッケージとスクラッチはどちらを選ぶべきですか?

標準的な企業年金の制度管理や給付、経理、帳票を安定して運用するなら、年金専門パッケージを中心に、独自要件を追加する方式が有力です。

特殊な給付や保険会社固有の契約・数理処理、既存基幹との深い統合が必要なら、ハイブリッドやスクラッチを検討します。判断は、制度改正への追随と計算根拠で分けて考えます。担当者の継続性や5年TCOも比べて決めます。

RFPを作る前に何を準備すればよいですか?

業務、データ、運用の条件を集め、候補会社が同じ前提で提案できる資料をそろえます。

  • 制度・規模:規約・細則、給付設計書、制度・事業所一覧、加入者・受給権者数、履歴年数、代表計算事例
  • 現行運用:帳票、データ項目表、連携先、月次・年次処理、セキュリティ基準、希望時期
  • データ品質:個人情報をマスキングし、欠損・重複・訂正履歴を説明できるようにする
  • 資料不足時:調査・要件定義を先行発注してから本開発のRFPを作成する

年金業務を知らない開発会社にも外注できますか?

外注は可能ですが、年金業務の専門家と開発会社の連携体制を整えます。

  • 責任者:制度解釈、計算検証、移行、支払の担当を発注前に決める
  • 業務理解:規約例外、長期履歴、端数処理、遡及、支給停止の判断を、Web開発力とは別に見る必要がある
  • 連携と承認:年金専門ベンダー、受託金融機関、業務コンサルタントとの連携体制と業務仕様の承認者を確認する

年金システムは準委任と請負のどちらがよいですか?

不確実性の高い現行調査・要件定義は準委任、仕様が確定した設計・開発・移行ツール作成は請負に向きます。

工程の性質で分けるのが基本で、契約名だけで責任範囲を決めてはいけません。成果物と検収、変更管理は、工程ごとに定めます。計算誤りの切り分けや保守、再委託、データ返却は、契約書で明確にします。

まとめ

発注時は、まず対象制度を決めます。そのうえで、制度と規約、履歴を定義します。給付と支払、経理、連携範囲も定義します。

データの正本、計算根拠、承認者を先に定めてから方式を選びます。パッケージやクラウド、スクラッチ、ハイブリッドは、いずれも5年TCOで比べます。

資料が不足する場合は、調査と要件定義を先に委託します。RFPには、計算事例や移行、並行計算を含めます。さらに、受入やセキュリティ、法改正、データ返却も盛り込みます。

委託先は、制度対応や専門性、長期履歴の移行、全件照合の経験で選びます。保守や再委託、障害時の責任の分け方も、選定の材料にします。加えて、準委任と請負は工程ごとに使い分け、計算誤りや連携障害の原因を説明できる体制を契約に定めます。

発注前に確認する項目

発注前の前提を一枚にまとめ、候補会社へ同じ形式で提出を依頼します。

  • 対象範囲:制度、制度数、人数、履歴年数、計算事例
  • 導入条件:連携先、帳票、移行対象、セキュリティ、希望時期
  • 見積条件:標準・設定・追加開発、初期・年間費用、法改正、検証
  • 運用条件:担当者、再委託、データ返却

次に進める現行整理と相見積もり

規約と計算事例を確認できる業務責任者を置き、現行データをマスキングして候補会社へ相談します。

最初から総額だけを競わせず、調査・要件定義から保守までを、パッケージ導入や個別開発の部分ごとに分けて比べます。そのため、費用とリスクの根拠を説明しやすくなります。

▼全体ガイドの記事
・年金システム開発の完全ガイド

会社紹介

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

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

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

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

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

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