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

預金管理システムの発注は、現行業務とデータを調べ、RFPで条件を整理したうえで、委託先と契約する流れで進みます。

移行と運用まで検収を分けて確認すると、品質と責任範囲をそろえやすくなります。全体像は預金管理システム開発の完全ガイドもご覧ください。

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

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

預金管理システムの発注・外注の考え方

預金管理システムの発注・外注では、企画支援から運用までの作業を、一部または全部委託先に任せます。委託先には、金融システムに詳しいSI会社、パッケージベンダー、クラウド事業者などがあります。

まず押さえたいのは、委託する作業と、自社が自ら判断し続ける作業を分けることです。元帳の整合性、利息計算、データ移行は、発注範囲と検収条件に含めておきます。障害復旧と監査証跡も、忘れずに含めます。

銀行・信用金庫・デジタルバンクなどは顧客の資産を扱うため、一般的な業務システムより、要件整理と委託先選びに慎重さが求められます。

外注範囲と見積もりの抜け漏れ

外注範囲は広く、現行業務の調査から運用引継ぎまでの工程を含みます。前半では、要件の整理や方式比較、RFP作成支援が中心になります。後半では、要件定義から開発、テストまでを進めたうえで、移行と切替、運用引継ぎまで任せられます。

• 自社に金融業務の知見がある場合：性能試験や移行リハーサルだけを切り出して委託できます。
• 新しい金融サービスを立ち上げる事業会社：勘定・決済の専門家に企画段階から相談する方法もあります。

「開発一式」の見積もりでは、移行回数や並行稼働、監査資料が抜けることがあります。運用訓練や制度改定への対応も、見積もりから抜けることがあります。そのため、対象業務、データ、対象外の作業を明記し、納品物と受入基準も同じ資料で管理します。

金融システムに強い委託先の必要性

預金管理では、残高が1円ずれただけでも、顧客や監査、経営陣に原因と影響を説明しなければなりません。そのため、取引を一度だけ確定させる設計には、例外処理への理解が欠かせません。

発注側は、専門会社を選ぶときに、例外処理と周辺システムとの連携経験を確かめます。

• 例外処理：入出金、振替、取消、組戻し、二重送信、通信断への対応
• 締め処理：日次締め、利払日、休日、うるう年のルールへの対応
• 連携・運用：ATM、インターネットバンキング、営業店、全銀システム、会計、融資、為替、CRM、DWH、本人確認、AML/CFTの担当範囲

候補会社には、預金元帳や移行、APIについて、どこまでを担当するかを確認します。監査や24時間運用についても、担当範囲を確かめます。

預金管理システムの発注形態の選び方

発注形態は5つに分けて比べます。金融向けパッケージや共同利用型、クラウド・コンポーネント型のほか、フルスクラッチとハイブリッドも選択肢になります。比べる際には、5年程度の総保有コスト（TCO）も同じ条件で評価します。

初期費用だけでなく、標準機能に合わせた業務変更や制度改定への対応も確認します。加えて、データを持ち出せるか、障害時の責任分界をどう定めるかも見ておきます。

パッケージ・共同利用型が向く案件

普通預金や定期預金の業務を早期に安定稼働させたい場合は、金融向けパッケージや共同利用型が候補になります。口座開設、残高照会、利息計算などのように標準化しやすい業務ほど、この方式が合います。

• 導入の利点：導入ノウハウや運用手順を活かしやすく、制度改定や保守の要員もベンダーと分担できます。
• 注意点：業務変更への対応、追加開発の単価、更新時期、契約終了時の移行支援は、事前に確認しておく必要があります。

パッケージ価格に加えて、アドオン、接続先の追加、移行を含む5年TCOを提示してもらいます。試験やライセンス更新、保守の費用も、同じ形で含めてもらいます。

クラウド・コンポーネント型の注意点

クラウド・コンポーネント型では、機能の分け方と運用条件をセットで確認します。

• 段階導入：新商品やデジタルチャネルを段階的に追加したい場合や、処理量の増減に対応したい場合に向いている
• 機能分割：元帳と取引処理を中核に置き、画面、API、分析、ワークフローを分ける
• 運用条件：多地域冗長、監視、暗号鍵、バックアップ、データ保存場所、特権アクセス、SLA、障害時の責任共有の決定
• 契約条件：利用料の上限と、終了時のデータ返却の取り決め

機能を分けておくと、画面や顧客向けの変更が元帳などの中核に波及しにくくなります。一方で、クラウドを選べば自動的に安くなるわけではありません。

住信SBIネット銀行は2025年9月、2028年初旬の本番稼働を目指す次世代クラウド勘定系について、3,000万口座を超えるデータ量への対応を公表しています（出典：Amazon Web Services公式ブログ、2025年）。このように大規模な案件ほど、移行と検証が欠かせません。

スクラッチとハイブリッドの使い分け

独自の商品計算や特殊な決済を優先するなら、スクラッチ開発が選択肢になります。既存業務との整合性や固有の性能要件を重く見る場合も、候補に入ります。

• スクラッチの負担：自由度の分、要件定義、例外系試験、制度改定、技術者確保、長期保守を自社と委託先で分け持つ
• 将来の変更：画面の変更より、誰がいくらで実装するかの定義を先に決める
• ハイブリッド：元帳・残高・利息計算を中核に残し、顧客画面、API、分析、申込ワークフローを別に開発する構成も比べる
• システム分割：取引ID、処理結果の正本、再送・再処理、障害時の責任分界のRFPへの記載

預金管理システムの発注・外注の進め方

発注は、現行調査とRFIから始めて、RFPと提案比較を行ったうえで契約へ進みます。契約後は要件定義から始まり、開発とテストを経て移行に進みます。最後は、運用引継ぎで終わります。

段階ごとに決定事項を分けておくと、早い段階で価格だけを競わせて後から追加費用が増える事態を避けられます。

現行調査とRFIの確認事項

現行調査では、口座開設から入出金、振替、締めまでを業務フローにします。さらに、利息、明細、会計連携を経て、問い合わせまでを流れとして押さえます。あわせて、顧客数や商品数、1日の取引件数も洗い出します。

ピーク時の同時処理数や夜間バッチ、休日カレンダーも確かめます。そのうえで、Excelや電話で補っている作業を、移行後も残すか自動化するかを決めます。

RFIでは、各社に対応方式と、標準機能・追加開発の境界を質問します。このほか、次の項目も確認します。

• 類似案件の体制
• 移行経験
• 保守時間
• 再委託の有無

RFIで比べたいのは、確定価格より、実現方式と前提条件です。

候補を3〜5社程度に絞ってから、同じ前提でRFPを配布すると、提案の差が見えてきます。

• 現行業務：取引から問い合わせまでの流れを一覧にする
• データ量：口座数、取引数、保存年数、欠損の洗い出し
• 候補会社：方式、移行経験、体制、保守条件の確認

RFPの記載項目

RFPには、業務範囲、取引シナリオ、測定できる非機能要件を書き込みます。各社が同じ前提で提案できるよう、区分ごとに条件を並べます。

• 前提と成果物：背景、目的、対象と対象外、利用者、商品、口座、接続先、取引量、ピーク時間、日程、予算、成果物、提案様式
• 取引シナリオ：正常系に加え、取消、組戻し、凍結、解約、名義不一致、重複、タイムアウト、通信断、片側成功の各ケース
• 性能・復旧：稼働率、応答時間、同時処理数、ピーク係数、RTO、RPO、ログ保存期間の目標値
• 安全対策：バックアップ、権限分離、暗号化、脆弱性対応、監視、障害受付、拠点切替、復旧訓練の方針

「高可用性」や「安全」といった言葉のままでは比べられないため、測定方法と受入基準も書き添えます。

提案比較の評価項目

提案比較では、各社の提案を同じ区分に揃えて確認します。機能や品質、移行の条件に加えて、運用の条件も同じ枠で比べます。

• 機能・品質：適合率、残高整合性、移行、異常系試験、性能根拠、監査対応
• 体制・変更：運用体制、制度改定への対応、責任者、開発・移行担当者
• 実績：口座数、取引量、商品数、切替方式、障害件数、保守範囲
• 提案区分：標準、設定、追加開発、対象外に分けた評価

区分を揃えておくと、提案が安い理由が要件漏れによるのか、効率的な方式によるのかを判断できます。さらに、類似案件は匿名化した情報を聞き、営業と現場の説明が一致するかを確かめます。

RFP・要件整理で預金管理システムの品質を高める方法

RFPは、提案を比べるための合意文書です。業務やデータ、非機能の条件に加えて、移行、運用、契約条件まで含めて、各社の前提をそろえます。価格だけを競わせる資料ではありません。

レビューには、業務とシステムの担当者に加えて、リスク管理の担当者が参加します。さらに、法務と経理の代表者に加え、監査や運用の代表者も加わります。

業務要件とデータ要件の書き方

業務シナリオと管理データを具体的に書いておくと、提案を出す各社の解釈のずれを抑えられます。

• 業務要件：商品開設、入出金、振替、解約、満期、自動継続、利息、税、手数料、照会、明細、未記帳、訂正、取消、組戻し、凍結、相続、差押え
• データ要件：顧客属性、口座、商品、残高、取引履歴、利息、手数料、証跡、保持期間、名寄せ、コード変換、正本システム
• 例外条件：利払日、途中解約、休日、日付切替、端数処理、取引状態、電文の一意性、再送時の結果

「口座を管理する」と書いただけでは、条件の読み方が各社の解釈に委ねられてしまいます。そのため、期待結果と照合ルールまでRFPに添付しておきます。

非機能要件とセキュリティの数値化

性能、復旧、アクセス管理は、測定や確認ができる条件に分けて書きます。

• 性能・稼働：稼働時間・率、ピーク応答時間、同時処理数、脆弱性対応の期限
• 復旧：RTO、RPO、バックアップ頻度、復元時間、ログ保存期間
• アクセス：職務分掌、承認・再鑑、特権ID、MFA、操作ログ、変更履歴、改ざん防止

FISCは2026年3月、安全対策基準・解説書第14版を公表しました。

この改訂は、金融庁のサイバーセキュリティガイドラインやAI・生成AIを踏まえ、安全対策や障害事例も反映した内容です（出典：金融情報システムセンター刊行物一覧、2026年）。

RFPには「FISC準拠」と書くだけでなく、対象項目や設計、証跡まで落とし込みます。テストや委託先の確認方法も含めます。

データ移行と検収条件の決め方

移行作業と検収試験は分けて考え、それぞれの対象と合格条件を決めます。

• 移行作業：抽出、変換、クレンジング、名寄せ、欠損補正、コード変換、過去明細、匿名化、リハーサル
• 移行照合：新旧の残高、取引件数、利息、帳票の結果の突合
• 検収試験：機能、負荷・障害、脆弱性、復元、DR切替、現新並行、切戻し、運用訓練

移行作業は項目ごとに分けて見積もります。合格基準や未解決課題を、契約前に決めておきます。さらに、重大障害の判定と稼働判定者も決めておくと、納品後の認識違いを抑えやすくなります。

契約形態の選び方（請負と準委任）

請負は、合意した成果物の完成責任を委託先が負うもので、仕様と検収条件を固めやすい開発工程に向いています。一方、準委任は、一定の業務を専門家が遂行する形で、作業内容が変わりやすい工程で使いやすい形態です。

要件定義やPMOは、準委任の候補になります。現行調査やアジャイル開発も、同じ扱いで検討できます。

工程ごとの契約形態の使い分け

工程の確定度に合わせて契約形態を分け、それぞれの契約条件を文書にしておきます。

• 準委任：現行調査や要件定義など、内容が変わりやすい工程に使う
• 請負：要件・成果物が固まった設計、開発、移行ツールに使う
• すべて請負の場合：未確定の業務ルールが価格に上乗せされたり、曖昧な前提で変更費用が膨らんだりする可能性がある
• すべて準委任の場合：完成責任や予算上限が見えにくくなる

契約書では、範囲、成果物、役割を明確にし、前提、納期、検収も明記します。瑕疵対応、変更管理、再委託は、契約書に書いておきます。

そのうえで、秘密保持と個人情報の扱いを定めます。監査権、障害連絡、損害の扱いは、契約書で明確にします。

準委任では、稼働報告に加えて、定例会で意思決定や課題を確認します。品質指標と次月の成果も、同じ場で見ます。

仕様変更と追加費用の管理

仕様変更は、影響を評価したうえで、記録と承認の手順に沿って管理します。

• 影響評価：目的、機能、データ、連携、試験、納期、費用、セキュリティへの波及
• 変更記録：変更前後、範囲、工数、予算、承認者、リリース時期
• 費用条件：制度改定の都度見積もり・年間保守の扱い、緊急単価、優先順位
• 定例運用：RFP対象外か設計不足かの区別、月次枠、承認上限、リリース判定の設定

知的財産・再委託・契約終了時の確認事項

知的財産の権利、再委託先、契約終了時の引継ぎは、契約前に確認しておきます。

• 知的財産：個別開発のコード、設計、試験、手順、データモデル、API、設定の権利・利用範囲
• 標準部品・OSS：改変権、第三者ライセンス、脆弱性情報、終了後の利用可否
• 再委託：会社、工程、データアクセス、所在国、セキュリティ、事故責任、監査方法
• 契約終了：口座・取引データを標準形式で返せるか、移行支援を何か月受けられるか、アカウントと鍵の廃棄

ベンダーを変える準備は、事業継続にもつながります。

預金管理システムの費用相場と見積内訳

預金管理システム単体の公開された見積もりの統計は多くありません。そこで、ここで示すのは、金融向け機能、一般的な基幹システムの価格、移行と試験の工数を組み合わせた、記事用の推定レンジです。

費用は、口座数や顧客数、取引量といった規模に加えて、ピーク性能、連携数、データ量でも変わります。さらに、可用性やRTO・RPO、規制対応、保守時間も費用に影響します。

規模別の費用相場

規模ごとの推定レンジは、対象機能と移行範囲を添えて比べます。

• 小規模：既存勘定系を残し、周辺機能、照会画面、API、基本帳票を追加する案件で、1,000万〜3,000万円、6〜12か月が目安
• 中規模：元帳、利息・手数料、承認、監査ログ、AML・会計・決済・チャネル連携、移行を含む案件で、3,000万〜1億円、12〜24か月
• 大規模：大量口座、高頻度取引、複数商品、24時間運用、遠隔地DR、全履歴移行を含む案件で、1億〜数十億円以上、2〜5年以上になる場合がある

金融向けパッケージは初期3,000万〜数億円、クラウド・コンポーネント型は初期2,000万〜1億円程度です。クラウド・コンポーネント型には、これに月額50万〜500万円程度が加わるという整理もできます。いずれも、対象範囲を明記した推定です。

見積書の内訳の分け方

工程別の比率は、予算を分解するための参考値で、固定された統計ではありません。

• 要件定義・業務分析：15〜20%
• 設計・実装：35〜45%
• テスト・性能・障害試験：15〜25%
• 移行・並行稼働・リハーサル：10〜20%
• PM・監査・教育・インフラ：10〜20%

提案会社から受け取った内訳と比べながら、実際の対象工程に合わせて調整します。

見積書は、工程、成果物、工数ごとに示してもらいます。単価も合わせて示してもらいます。

ライセンスやクラウド利用料、接続先、移行回数は、別々に示してもらいます。試験環境や教育、切替支援に加えて、保守も、同じ形で示してもらいます。

「移行一式」「テスト一式」「運用支援一式」と書かれた項目は、対象データと回数を質問します。担当者と完了条件も、あわせて確かめます。

ランニングコストの内訳

運用費は、項目と契約条件を分けて確認します。

• 基盤・保全：サーバー、ライセンス、監視、バックアップ、ログ保管
• 障害・安全：診断、脆弱性対応、24時間365日受付、障害復旧
• 継続運用：制度改定、保守要員、DR訓練
• 費用確認：保守費は初期開発費の年5〜15%程度との整理もあり、年額と5年総額の提示を求める

クラウド利用料やライセンス更新が、別建てになる場合もあります。初期見積もりが安いときは、非機能要件や移行リハーサルが含まれているかを確認します。異常系テスト、稼働後の要員、再委託管理も確かめます。

予算を抑えたい場合は、機能を減らすことだけでなく、商品やチャネルの段階導入、標準機能の採用、周辺システムの分離も比べます。

委託先選定と見積比較のポイント

委託先を見るときは、企業規模や知名度に加えて、預金業務への理解を確かめます。そのうえで、類似する口座数・取引量と移行経験も見ます。

非機能設計や監査・セキュリティ、運用保守を見るとともに、管理体制も確かめます。見積金額は大切ですが、前提と対象外が異なる提案を、金額の安い順に並べて比べてはいけません。

委託先の実績の確認方法

「金融機関の実績があります」と言われても、判断材料としては不十分です。担当した工程まで聞くと、実績の中身を確かめられます。

• 担当工程：預金コア、周辺API、データ移行、クラウド基盤、運用保守
• 類似案件：口座数、ピーク取引量、移行件数、期間、体制、障害対応、保守状況（開示可能な範囲）
• 製品例：日立製作所のOpenStage、富士通のFujitsu Core Banking xBank、NTTデータの統合バンキングクラウド

富士通は2025年5月、xBank採用のソニー銀行の新勘定系稼働を公表しました。NTTデータも、地銀共同センター参加行13行と2028年のクラウド適用を進めています（出典：各社公式発表、2024〜2025年）。製品の適合性も、評価の対象にします。

見積もりの比較の仕方

見積もりは、スコープ、費用区分、前提条件を同じ形式に並べて比べます。

• 対象項目：要件定義、開発、ライセンス、基盤、連携、移行、試験、教育、切替、保守、制度改定、DR訓練
• 見積条件：費用、期間、担当、成果物、前提、除外、追加単価の記載
• 費用期間：初期、月額、年額保守、5年総額に分けたうえで、差があれば範囲を確認

A社がリハーサルを3回含み、B社が本番移行のみなら、B社は安く見えます。そこで、同じ業務シナリオ、ピーク取引量、RTO・RPOの条件で、各社に再計算してもらいます。評価点とリスクは、別々に記録しておきます。

契約前に委託先へ聞く質問

契約前の質問は、機能の境界、運用責任、契約終了時の扱いに分けると整理しやすくなります。

• 機能・移行：標準機能と追加開発、再処理、残高突合、移行責任、切戻し条件
• 運用・契約：運用時間、制度改定料金、再委託先、監査、コード・データ返却
• 障害対応：取引確定、顧客案内、受付、切り分け、連絡、判断、復旧、分析、再発防止、監査報告

回答は口頭で済ませず、提案書や要件定義書、契約書、SLAのどこに反映されるかを確認します。さらに、役割表も契約に含めます。

2026年時点の最新動向と発注条件への反映

発注条件には、クラウド化やサイバーセキュリティ、AI利用の変化を反映します。第三者委託やマネー・ローンダリング対策の変化も、あわせて反映します。

発注側は、設計と証跡、訓練、報告の責任者を決め、費用の責任者まで定めます。

FISCと金融庁のセキュリティ要件の扱い

発注時には、セキュリティ対策と生成AIの利用条件を、証跡つきで確かめます。

• 金融庁指針：リスク特定、防御、検知、復旧、経営関与、第三者リスクの確認
• 委託先対策：アクセス、脆弱性、ログ、バックアップ・復元、事故報告、再委託管理の状況
• 生成AI：入力制限、利用モデル、ログ、出力レビュー、誤りの責任、学習利用の取り決め

FISC第14版も、開発、導入、運用の安全対策を具体化する資料です。また、生成AIの利用では、預金残高や個人情報を扱う工程と、文書作成の補助工程を分けてリスクを評価します。

AML・CFTの要件の範囲

金融庁の2025年6月資料によると、約4割の金融機関等が、取引フィルタリングのリストや検知基準の有効性について、定期的な検証・調整を実施していなかったとされています。出典は、金融庁「マネー・ローンダリング等及び金融犯罪対策の取組と課題」（2025年6月）です。

この結果を踏まえ、発注条件では、検知の運用と外部サービスの責任を確かめておきます。

• 預金取引との連携：顧客確認、取引モニタリング、制裁・反社会的勢力の照合、凍結・利用制限、調査記録、アラート承認・解除
• 検知の検証：閾値データ、変更履歴、承認者、誤検知分析、再調査、監査レポート
• 外部サービス：元帳との遅延、障害時の制限、データ返却、再委託先の契約への記載

稼働後の運用と改善の発注

稼働後の作業と、委託先のサービス水準は、年間計画とSLAに定めておきます。

• 日常運用：監視、アラート、一次切り分け、再送、組戻し、手動代替、顧客説明、月次報告
• 継続管理：制度改定、脆弱性、アクセスレビュー、復元テスト、DR訓練
• SLA：24時間365日受付、応答・復旧目標、重大度、連絡網、報告書、再発防止期限

NTTデータは、共同利用型勘定系を統合バンキングクラウドへ段階的に搭載し、2028年頃の地銀共同センター更改を見据えた検討を公表しています（出典：NTTデータ公式発表、2024年）。

基盤が変わる案件では、旧新環境の並行稼働と責任分界を、契約時点から計画に含めます。データの可搬性や将来の接続追加も、同じ時点で計画に入れます。

よくある質問（FAQ）

発注・外注では、価格とあわせて、対象範囲と契約を確認します。加えて、移行と運用の条件も見ておきます。

預金管理システムの外注費用はいくらですか？

既存勘定系を残す小規模案件は1,000万〜3,000万円、中規模案件は3,000万〜1億円、大規模更改は1億〜数十億円以上が推定レンジです。

口座数や取引量によって変わるほか、移行履歴やDR、セキュリティ、保守範囲も影響します。そのため、金額と合わせて、工程や対象外も確認します。

請負と準委任はどちらを選べばよいですか？

設計・開発・移行ツールは、成果物と検収条件を決められるなら請負が基本です。一方、現行調査や要件定義は準委任が基本です。PMOや変化の大きい開発支援も、準委任で進めます。

工程ごとに契約を分けても構いません。その場合も、責任範囲、変更管理、品質指標を契約書に明記します。

委託先を選ぶときに最も重視すべきことは何ですか？

重視するのは、預金元帳や取引処理への理解と、類似する口座数・取引量です。そのほか、移行と異常系試験、金融向けの監査・セキュリティ、稼働後の運用力も見ます。

企業規模に加えて、担当工程や責任者を比べます。再委託先や5年TCO、終了時のデータ返却まで比べれば、自社に合う委託先を判断できます。

まとめ

発注の第一歩は、対象範囲を定義することです。元帳や残高、利息、手数料といった中核の業務を、まず対象に含めます。

そのうえで、取消・組戻しや監査を範囲に入れ、移行とDRまでも含めます。方式は、5年TCOと責任分界で比べます。

発注前の準備

現行業務とデータを洗い出し、口座数や商品数、ピーク取引量を把握します。連携先も押さえておきます。そのうえで、RTO・RPO、移行範囲、異常系シナリオをRFPに整理します。

請負と準委任は工程ごとに使い分けます。契約条件には、成果物や検収、変更を入れます。再委託や知的財産、データ返却も、同じ条件に含めます。

見積比較の確認点

初期費用だけでなく、移行リハーサルと障害・性能試験を含めた総額を確認します。ほかに、次の項目も総額に含まれているかを確かめます。

• 監査証跡
• 保守
• 制度改定
• クラウド利用料

候補会社の実績と担当体制を確かめ、同じ条件で提案を再計算すると、予算超過と品質低下を防ぎやすくなります。

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

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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