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

Seasar2のシステムを発注・外注するときは、現行資産を洗い出して把握し、その結果をもとに発注形態と契約形態を選んで進めます。業務を止めずに移行できるか、移行後に保守を続けられるかを基準に、段階的に委託するのが安全です。

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

Seasar2のシステムを発注・外注する前に知るべき全体像

Seasar2を中心に、SAStruts・JSP、S2Dao・S2JDBC、バッチ・外部連携を注釈で示した構成図。
発注範囲を見積もるときは、周辺資産も合わせて確認します。

Seasar2は、Javaの業務Webシステム構築に国内で広く使われたフレームワークです。S2ContainerによるDIやAOP、S2Dao・S2JDBCなどのデータアクセスを組み合わせて作られ、SAStrutsやJSPの画面、バッチ、外部連携も含めて動いているケースが多くあります。

「Seasar2」という名称だけで見積もると、周辺資産の分が抜けてしまい、正確な見積もりになりません。

Seasar2は新規開発より移行・保守を前提とした考え方

Seasarプロジェクトの多くのプロダクトは、2016年9月26日にEOLとなりました。そのため、公式のメンテナンスとサポートはすでに終了しています(出典: The Seasar Project公式、EOL情報)。

公式サイトでは、ドキュメント、ソースコード、Mavenリポジトリが今も公開されています。ただし、この公開が続いていても、現在のJDK・OS・APサーバーや新たな脆弱性に対する公式サポートがあるとはいえません。

2026年時点では、新しい業務システムをSeasar2で作る前提の発注を慎重に見直す必要があります。保守の続けやすさや採用、セキュリティ、クラウド対応まで含めて検討します。

  • 短期延命:移行までの時間を確保するための方法です。
  • 段階移行:画面や機能単位で移していく進め方です。
  • 業務パッケージへの置換:業務単位で置き換えていく方法です。

方式を選ぶときは、業務停止を許容できる時間と担当者の退職リスクを見ます。さらに、データの重要度や外部連携数、JDKやDBの更新期限も判断材料にします。

発注対象は、フレームワークだけでなく業務資産全体

発注前には、Seasar2本体のバージョンと、周辺のフレームワーク・設定・連携機能を一覧にしておきます。

  • 画面・設定:SAStruts・S2Struts・Teeda・JSPの画面と、dicon、インターセプターの設定。
  • データ処理:S2Dao、S2JDBC、S2Hibernateを使う処理、バッチ、帳票、ジョブ管理。
  • 運用・連携:認証・権限、外部API、メール、ファイル連携。

ソースコードの行数だけでは、締め処理や例外処理の複雑さは評価できません。業務仕様がコードや担当者の経験に分散しているケースもあります。

画面が表示されても、月次締めや金額計算、取消の処理だけが旧システムと異なることがあります。権限変更や再実行、夜間バッチも、画面を見るだけでは見落としやすい処理です。

成果物には、コードのほかに、業務フローとデータ定義を含めます。さらに、テストケースや運用手順、障害時の切り戻し方法も含めます。

Seasar2のシステム発注で選ぶ発注形態

既存資産が大きい場合は、まず診断・棚卸しを小さな契約で先行させます。その結果を確かめてから移行本体を発注する進め方が安全です。一方で、仕様をすでに把握できているなら、一括請負という選び方もあります。

仕様が不明な部分、いわゆるブラックボックスが残る場合は、調査と実装を分けておくと、追加費用や責任範囲を管理しやすくなります。

診断・資産棚卸しだけを先に外注する方法

現行構成が分からない場合は、移行診断を先に発注して、技術資産と稼働状況を把握します。

  • 調査対象:リポジトリ、dicon、DBスキーマ、JDK、APサーバー、OS。
  • 稼働状況:画面、帳票、バッチ、外部連携を、稼働中・未使用・重複・廃止候補に分けたもの。
  • 技術上の難所:S2Daoのマッピング、独自拡張、トランザクション、認証・認可、テスト有無。

診断・棚卸しは2〜6週間、100万〜500万円程度が目安です。公開相場と調査範囲をもとにした推定で、Seasar2専用の公定価格ではありません。

診断の成果物には、対象一覧、依存関係、移行方式案などが含まれるかを確認します。リスク一覧と概算人月、優先順位は、一緒に受け取れるかを見ます。次工程のRFP案も含まれているかを確かめます。

部分移行・段階移行による業務停止リスクの抑え方

全機能を一度に移すと、テスト範囲が広がり、切り戻しも難しくなります。そのため、段階移行では移行の順序と条件を先に決めておきます。

  • 移行対象:利用頻度が高く独立性のある業務を、Spring MVCやSpring Bootなどへ移す。
  • 共存方法:APIやデータ連携を境界にして、旧システムと新システムを一時的に共存させる。
  • 移行順:参照系画面を先に移し、登録・承認・締め処理は後に移して、利用者の確認を受ける。

あわせて、旧システムと新システムのデータ整合性と、二重更新の防止を決めておきます。障害時の切り戻しや、旧環境を停止する条件も、移行を始める前に決めておく必要があります。

委託先には、機能ごとの完了条件を示してもらいます。画面が表示されるかだけでなく、業務結果が旧システムと一致するかを受入条件にします。

パッケージ・SaaS・スクラッチの業務単位での比較

Seasar2の機能を、そのまま作り直すとは限りません。業務の標準化しやすさや独自性に応じて、方式を業務ごとに比べます。

  • SaaS・パッケージ:勤怠、経費、ワークフロー、顧客管理など、標準化しやすい業務。
  • スクラッチ開発:独自性が高く、競争力に直結する業務を対象にする。
  • 組み合わせ:標準業務は既製サービスを使い、独自機能は個別に開発する。

業務を変えられない部分を無理にパッケージへ合わせると、追加のカスタマイズで費用が膨らみます。一方で、独自機能をすべて作り直すと、移行リスクが高まります。

候補ごとに、業務への適合度と移行できない機能を比べます。あわせて、運用負荷と5年程度の総保有コストも見ます。

契約面では、月額利用料とユーザー数課金を確認します。機能面では、データ移行とAPI連携、帳票を見ます。加えて、権限と監査ログを確かめ、バックアップと終了時のデータ返却も見ます。

候補を同じ観点で比べれば、安く見える選択肢で必要な機能を見落とすことを防げます。

ポイント

既存資産の規模と、仕様をどこまで把握できているかで発注形態を決めます。仕様が不明な部分は診断を先に発注し、段階移行や業務単位の比較と組み合わせると、業務停止のリスクを抑えられます。

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

発注は、会社を探して見積もりを取るだけで終わるものではありません。発注者が目的と制約を整理して、候補会社が同じ条件で提案できる状態を作ります。

工程は、診断からRFP作成、提案比較、契約へと進みます。その後に要件定義と開発、テスト、移行後保守が続きます。工程ごとに分けておくと、前提が変わったときにも判断しやすくなります。

目的・対象範囲・業務上の成功条件の整理

まず、「何を改善すれば事業が継続できるか」を言葉にします。「Seasar2を新しくする」を目的にせず、この問いから成功条件を決めていきます。

成功条件と対象範囲は、四つの観点で整理します。

  • 成功条件:JDK・APサーバーのサポート切れ解消、障害復旧時間の短縮、月次締め処理の時間短縮。
  • 保守性:担当者が代わっても保守を続けられる状態。
  • 対象範囲:画面、帳票、バッチ、DB、外部システム、利用者、権限、データ件数。
  • 制約:停止できる時間、法令・監査要件、現行資料の不足や不明点。

技術変更だけを目的にすると、利用者の業務課題が後回しになりがちです。

現行資料が足りない場合は、「不明」として調査項目に入れます。不明点が残ったまま固定価格を求めると、受注後に追加見積もりが出ることがあります。

RFPに書く現行構成と移行後の成果物

RFPには、提案条件と現行情報を明記します。成果物と、自動変換ツールの扱いも書きます。

  • 提案条件:背景、目的、対象業務、移行先、対象外、時期、予算、体制、期限、評価基準。
  • 現行情報:Seasar2の版、S2Dao・S2JDBC、dicon、Java・JDK、APサーバー、DB、OS、ミドルウェア。
  • 成果物:設計書、コード、設定、DB定義、テストコード・結果、移行・切り戻し手順。
  • 運用・変換:運用設計、監視、脆弱性方針、OSS一覧、引き継ぎ、変換範囲・ログ・利用権。

現行情報には、ソース規模やテスト資産、外部連携も含めて、可能な範囲で示します。また、自動変換を使う場合は、手修正の割合と将来の再実行方法も確認します。

提案依頼で求める技術案・体制・リスク対応の粒度

S2Daoなどの周辺資産の扱いから実行体制まで、同じ観点で提案を照らし合わせれば、移行案の実現性を見極められます。

  • 技術案:移行方式、対象範囲、工程、S2Dao、独自拡張、JSP、帳票、バッチ、外部API。
  • 提案条件:役割分担、前提、除外事項、リスク、テスト、データ移行、保守体制、概算費用。
  • 担当体制:診断責任者、移行設計者、テスト責任者、運用引き継ぎ担当者。

「Springへ移行できます」という説明を聞いたら、Seasar2の構成を理解した担当者が提案に加わるかも確かめます。さらに、契約後に実際に作業する人も明らかにしてもらいます。

たとえば、スタイルズは、Seasar 2.4とS2DaoからSpring 5への移行事例を公開しています。案件の規模は、Webアプリ3本、約300メソッド、約16万ステップです。同事例の工数は約20人月、期間は約5か月です(出典: 株式会社スタイルズ公開事例)。

公開事例のような具体的な実績は、対応可否の確認より有効な比較材料になります。

ポイント

目的と制約を整理してから、同じ条件で候補会社に提案を求める流れで進めます。現行資料に不明点が残るうちは固定価格を避け、調査の工程を先に置きます。

Seasar2のシステム委託で選ぶ契約形態と責任分界

準委任契約と請負契約を並べ、現行調査・要件定義と成果物の完成・検収という向く工程を対比した図。
作業範囲と検収条件の確定度が契約選びの目安です。

診断や要件定義は準委任、仕様が固まった移行開発は請負にするなど、工程ごとに契約を分けると実態に合いやすくなります。

成果物と作業範囲、検収条件は、文書にして残します。さらに、変更管理の方法も明記します。

再委託や知的財産、情報管理は、契約で決めておきます。障害対応や終了時の引き継ぎについても、契約書に含めます。

責任範囲は、契約名だけでは分かりません。条項の中身まで確かめることが大切です。

調査・要件定義に向く準委任契約

準委任契約は、一定の業務を専門家に委託し、稼働時間や役割に応じて報酬を払う形です。調査や要件定義では、合意しておきたいことが三つあります。

  • 向く工程:現行調査、業務ヒアリング、移行方針の検討、技術検証。
  • 管理方法:月次の成果報告、レビュー、課題一覧、次月の計画。
  • 発注者の協力:資料・担当者の提供時期、検証環境の用意、遅延時の扱い。

着手前に作業量や難所を確定しにくい工程に向いています。ただし、完成品の品質を一括で保証する契約ではありません。

ヒアリングや環境の用意が遅れたり、データを確認できる人がいなかったりすると、委託先だけでは作業を進められません。そのため、発注者の協力事項は、契約書や作業計画に記載しておきます。

範囲と検収条件が固まった請負契約

請負契約は、合意した成果物を完成させ、検収後に報酬を支払う形です。予算・納期と検収条件を決める際は、三つの点を確定させます。

  • 対象範囲:移行対象、画面・帳票・バッチ、性能、対応ブラウザ。
  • 移行・検査:データ件数、テスト合格基準、切り替え条件。
  • 追加変更:対象外機能、仕様変更の見積単位と承認者。

要件が曖昧なまま「一式」で請負にすると、対象外の機能や仕様変更が追加費用になることがあります。

検収は、納品の確認だけでなく、業務受入テストへの合格として定めます。その中身には、旧システムとの結果比較と境界値、権限を含めます。さらに、異常系や再実行、締め処理を含めます。また、外部連携が停止したときの挙動も含めます。

契約に入れる知的財産・セキュリティ・保守移管

成果物の権利と情報管理を文書で明らかにし、障害時の対応や保守移管まで決めておくと、委託終了後の引き継ぎに備えられます。

  • 権利・成果物:コード、設定、IaC、テスト、設計書、変換出力、ログ、OSSとライセンス。
  • 情報管理:再委託先、国外保管、個人情報へのアクセス、バックアップ暗号化、ログ保存期間。
  • 保守・障害:重大度別の受付時間、一次回答、復旧目標、脆弱性対応、更新、監視。
  • 引き継ぎ:定期報告、担当が代わるときの資料の受け渡し、別会社への保守移管。

既存コードの著作権や共通部品の利用条件が曖昧だと、別会社への保守移管に支障が出ます。脆弱性の調査と修正、JDK・OS・DBの更新も、保守範囲に含めて定めます。

IPAの「情報セキュリティ10大脅威2026」では、組織向けの1位がランサム攻撃です。また、2位はサプライチェーンや委託先を狙った攻撃、4位はシステムの脆弱性を悪用した攻撃です(出典: IPA、情報セキュリティ10大脅威2026)。

そのため、EOLのシステムを外注する場合は、委託先の管理そのものを要件に含めます。IPAの脅威情報を踏まえた管理が必要です。

ポイント

作業範囲と検収条件がどこまで確定しているかで、準委任と請負を選びます。確定していない部分は準委任で進め、請負は範囲が固まってから結びます。

Seasar2のシステム発注費用・移行費用の相場

移行診断・棚卸し、小規模な部分移行、中規模の移行・刷新の費用レンジを横棒で比較した図。
対象範囲が広がるにつれて、費用レンジも上がります。

Seasar2専用の公的な価格表はありません。費用は、現行資産の複雑さや業務仕様の不明確さ、画面・帳票・バッチの数によって変わり、外部連携の有無も影響します。

DB移行やテスト範囲も、費用に影響します。さらに、停止できない時間や、JDK・OS・APサーバーの更新、クラウド化の有無も関わります。

ここに示すのは、2025〜2026年の一般的な相場と公開事例をもとにした目安です。特定の案件の確定金額ではありません。

診断・部分移行・中規模刷新のレンジの分け方

診断から中規模の刷新まで、対象範囲に応じた費用と期間の目安を比べます。

  • 移行診断・棚卸し:2〜6週間程度、100万〜500万円程度。
  • 小規模な部分移行:数十画面、単一DB、外部連携が少ない場合に300万〜1,500万円程度、期間は3〜8か月程度。
  • 中規模の移行・刷新:1,200万〜4,000万円程度、期間は6〜15か月程度。

中規模の案件には、複数のWebアプリや、S2DaoやS2JDBCを使う処理が含まれることがあります。さらに、バッチや帳票、外部APIのほか、データ移行が加わることもあります。

大規模な基幹システムでは、複数部門や複数DBにまたがることがあります。24時間運用や並行稼働、厳格な監査が必要な場合は、3,000万円〜1億円超となる可能性があります。期間も、12か月から数年に及ぶことがあります。

2026年の一般的な相場では、人月単価は60万〜200万円程度です。規模別では、小規模が100万〜300万円、中規模が500万〜1,000万円、大規模が1,000万円〜数千万円以上とする紹介もあります(出典: SIA株式会社「システム開発の費用・相場 2026年版」)。

Seasar2の移行には調査や回帰テストが加わるため、新規のCRUD開発の相場をそのまま当てはめないようにします。

公開事例と人月単価による概算の組み立て

公開事例に人月単価を掛けた額は、あくまで参考の試算です。個別の見積もりでは、周辺費用や発注側の準備条件も含めて考えます。

  • 開発費:PM、要件定義、環境構築に必要な人月。
  • 基盤費:クラウド、ライセンス。
  • 移行後費用:データ移行、セキュリティ診断、教育、保守。

公開事例の約20人月に、一般的な人月単価60万〜200万円を掛けると、1,200万〜4,000万円になります。ただし、これはスタイルズの見積額ではなく、参考の計算です。

金額は、発注者がテストデータや業務仕様を用意できるかどうかや、旧システムと新システムの比較を何件行うかによって変わります。Java・DB・APサーバーの同時更新も、金額に影響します。

見積書では、総額のほかに工程別の人月と役割別の単価を確認します。あわせて、前提と対象外作業を確かめ、予備費と追加変更の単価も見ます。

保守・運用費と移行しない場合のリスクの予算化

保守・運用費と移行を先送りする場合の費用を、契約範囲や運用リスクに応じて予算化します。

  • 保守費の目安:初期開発費の年15〜25%程度を基準とする考え方もありますが、契約内容によって変わります。
  • 契約範囲:更新、脆弱性診断、監視、バックアップ、障害対応、追加改修。
  • 延命時の備え:脆弱性監視、アクセス制限、復旧訓練、担当者育成、移行原資。

保守の契約に、JDK・OS・APサーバー・DBの更新や脆弱性診断が含まれるかで、月額や年額の意味が変わります。加えて、監視とバックアップ、障害対応と追加改修の扱いも確かめます。

安い保守契約でも、EOL製品の脆弱性修正や担当者不在の場合の対応は含まれないことがあります。そのため、対象外に何が入っているかを確認します。

移行を先送りしても、費用がゼロになるわけではありません。古いJDKやAPサーバーを動かすための特別な環境が必要になるほか、障害対応が特定の担当者に頼る状態になる可能性があります。採用の難しさや、監査対応が生じることもあります。

緊急のサーバー更新が必要になったり、事業停止による損失が出たりする可能性もあります。

ポイント

移行費用は、対象範囲の広さと仕様の確定度で幅が出ます。公開事例は参考として扱い、保守費と先送りのリスクも同じ予算に含めて判断します。

Seasar2の委託先選定と見積比較で確認するポイント

委託先は、会社名や見積金額だけで決めるものではありません。Seasar2の知識に加えて、業務仕様を読み解く力や、Java・DB・APサーバーの同時更新、現新比較テストの進め方も確認します。

データ移行や運用引き継ぎ、EOL後の脆弱性対応も見ておきます。そのうえで、候補を2〜4社程度に絞り、同じRFPで提案を依頼すると比べやすくなります。

Seasar2の構成要素別の実績と移行後の技術力

確認するのは、Seasar2の構成要素別の実績と移行後の保守力です。「Javaに強い」という説明だけで判断しないようにします。

  • 現行資産の経験:S2Container、dicon、S2Dao・S2JDBC、SAStruts、JSP、バッチ、帳票、独自拡張。
  • 移行先の設計:Spring MVC・Spring Boot、MyBatisなどへの変更、既存DBの維持。
  • 移行支援の実績:解析、変換、テスト、Java・DB・APサーバーの変更、移行後保守。

自社で保守できるための設計判断と教育があるかも評価します。たとえば、ウェインはSeasar2からSpringへの移行を案内しています。

ウェインの支援内容には、資産解析や自動変換、カバレッジ検証があります。

また、TDCソフトは、2026年にMovina Javaフレームワークマイグレーションサービスを公開しました。Seasar2などからSpring Framework等への移行を案内しています。同サービスは、コード解析と自動変換、自動テストを、業務システムの知見と組み合わせます(出典: 各社の公式サービス情報)。

サービスの掲載情報だけで、自社案件に合うかは確定できません。提案の場で、担当者、実績、対象範囲を確かめます。

見積書の前提・工数・除外項目の比較

各社の見積もり範囲と金額差の理由を比べます。特に、四つの観点をそろえて確認します。

  • 範囲:診断・開発、クラウド費用、保守の含有と条件。
  • 工程・費用:要件定義、設計、実装、移行、テスト、教育、切り替え、PM、予備費。
  • 低価格時:テスト、文書、障害対応、並行稼働、手修正、データ整備の有無。
  • 高価格時:不要な再構築、過剰なクラウド、未使用機能、過大なPM体制。

工程別の項目は、含む、含まない、条件付きのどれかに分けて確認します。価格が極端に安い場合は、必要な作業の抜けがないかを調べます。

金額差の理由と、前提が変わったときの再見積もりの方法を説明できる会社を、候補に残します。

候補会社への質問による責任分界と将来の保守性の確認

候補会社には、技術への対応や責任分界、移行後の保守について質問します。

  • 移行経験:Seasar2の対応件数、S2Daoの手修正箇所、現新比較テストのケース数。
  • 責任分界:旧DBの継続期間、基盤更新の担当、障害時の切り戻し。
  • 保守移管:成果物の引き渡し、担当が代わるときの資料、社内への知識の受け渡し。

回答が具体的で、前提やリスクを隠さないかも見ておきます。さらに、保守を担当する人が移行開発の担当と同じかも確認します。

自動変換ツールは工数の短縮に役立ちます。ただし、業務ルールの正しさは自動では判定できません。そのため、ツールを理由にテストやレビューを削らない提案かどうかを見極めます。

ポイント

委託先は、Seasar2の構成要素ごとの実績と移行後の保守体制で比べます。見積もりは、前提と除外項目をそろえてから金額を見ると、比較の精度が上がります。

よくある質問(FAQ)

発注では、技術的に可能かどうかに加えて、現行業務を止めずに移行できるか、移行後に保守できるかを見ることが大切です。よくある質問には、判断の条件を添えて答えます。

Seasar2で新規システムを開発しても問題ありませんか?

2026年時点では、新規開発の第一候補にSeasar2を選ぶことはおすすめできません。多くのプロダクトが2016年9月26日にEOLとなり、公式サポートが終了しているためです。

既存資産を使い続ける事情がある場合も、短期延命とSpringなどへの移行計画を並行して作ります。その際は、脆弱性と人材、保守契約のリスクを評価します。

Seasar2からSpringへの移行費用はいくらですか?

目安として、診断は100万〜500万円程度、部分移行は300万〜1,500万円程度、中規模の移行・刷新は1,200万〜4,000万円程度という推定があります。

これはSeasar2専用の公定価格ではなく、一般的な業務システムの相場と公開された移行事例から整理した目安です。見積もりの前提として、RFPには画面数やS2Daoやバッチ、外部連携の範囲を書きます。テストやデータ移行、JDK・DB更新の範囲も書いておきます。

同じ条件で、複数社から見積もりを取ります。

Springへ移行するとデータや業務機能は失われませんか?

棚卸し、データ移行の設計、旧システムと新システムの比較テストを行えば、データや機能を維持する計画は立てられます。ただし、無条件に失われないとは言い切れません。

確認するのは、独自SQLやS2Daoのマッピング、dicon設定です。さらに、バッチや帳票、例外処理、権限も見ます。過去データの欠損や重複も調べます。

移行前のバックアップやリハーサルを行い、受入テストと切り戻しの条件を、契約と計画に含めます。

何社に見積もりを依頼すると比較しやすいですか?

まず2〜4社程度に同じRFPで依頼すると、比較と発注者側の負荷のバランスを取りやすくなります。候補は、構成要素別の実績や業務システムの経験で絞ります。

診断の進め方や、テストと保守の提案も確認します。金額だけでなく、前提と除外項目を並べて評価します。さらに、体制や成果物、移行後の責任分界も比べます。

まとめ

発注前の現行資産と業務上の制約の確認

Seasar2のシステムを発注・外注するときは、公式サポートが終わった技術だと踏まえて、現行資産と業務知識を洗い出します。

延命や部分移行、Springなどへの刷新を比べ、SaaS・パッケージへの置換も候補に入れます。そのうえで、業務停止のリスクと将来の保守性に合う方式を選びます。

契約・予算・保守を一つの計画として比べる方法

発注計画では、RFPと契約を一貫させ、予算・見積もりと保守・委託先の確認も同じ計画に含めます。

  • RFP:目的、範囲、現行構成、外部連携、テスト、移行、切り戻し、成果物、保守。
  • 契約:診断・要件整理は準委任、範囲と検収条件が固まった開発は請負。
  • 費用比較:診断100万〜500万円、部分移行300万〜1,500万円、中規模1,200万〜4,000万円程度。
  • 委託先:技術理解、現新比較、データ移行、脆弱性対応、成果物、移行後保守。

工程に応じて契約を分けると、責任分界が明確になります。見積書については、前提、工数、除外項目を照合します。

最初に現行構成と、業務上止められない処理を書き出して、診断の範囲を定めておけば、発注の失敗を減らせます。

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

会社紹介

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

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

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

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

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

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