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

Tektonのシステム開発を外部へ発注するには、既存のCI/CDの現状を洗い出し、要件と契約を整理したうえで、小規模なPoCで確かめてから本番へ進むのが基本です。

流れは、発注形態を選び、RFPで要件をまとめ、契約と費用の目安を確かめ、委託先を比べて、導入後の保守まで決めていく順です。

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

Tektonの発注・外注の意味と範囲

基盤の構築に加え、連携先まで視野に入れた配置です。

Tektonの発注は、Kubernetes上でビルドやテスト、デプロイなどを自動化する仕組みを、外部の開発会社やSIerに任せることです。処理の中身は、イメージ作成、検査、署名まで広がります。

委託範囲は設計から運用まで幅があり、構築や移行もそこに含まれます。なお、Tektonは業務アプリそのものではなく、安全で反復可能なリリースを支える開発・運用基盤です。

Kubernetes上で動くCI/CD基盤のTekton

Tektonでは、処理をTaskに分け、その順序や依存関係をPipelineに定義します。発注時には、こうした処理の定義だけでなく、Tektonを動かす周辺の仕組みまで範囲に含めて決めておく必要があります。

実行単位：TaskRunとPipelineRunが、実際の処理を担います。
起動契機：Gitの変更を受けて、Tekton TriggersがPipelineRunを生成する流れです。
周辺機能：認証やServiceAccountとRBAC、Workspace、秘密情報が中心です。レジストリ、ログ、履歴、再実行、本番前の承認も要件に含めます。

Taskは一つ以上のStepを持ち、各StepはKubernetesクラスタ上のPodとして実行されます（出典: Tekton公式「Tasks」、2026年8月確認）。

Tekton周辺の運用まで含む外注範囲

外注範囲を考えるときは、Tekton単体にとどめず、周辺サービスと構築後の運用まで含めます。

連携先：Git、Kubernetes、レジストリ、秘密情報管理、イメージスキャン、監視・ログとつなぎます。デプロイ先とも連携させます。
Tekton機能：Tekton Pipelinesが処理を担い、TriggersがWebhookを受け付けます。
証跡：Tekton Chainsは、実行情報から署名付きの証跡を作成し、SLSAやin-totoへ接続できます。
委託範囲：クラスタ構築、Jenkins移行、共通Taskは、一つずつ分けて指定します。セキュリティや監視、教育、月次保守も、それぞれ分けて書きます。

Pipelines-as-Codeは、パイプラインの定義をGitレビューの対象にします。

アップグレードと障害対応の担当が曖昧なままだと、稼働後に対応者が不在になりがちです。そのため、担当は初期見積もりの段階で決めておきます。

Tektonの発注形態の選び方

発注形態は、対象アプリの数や既存CI/CDの有無、Kubernetesの運用体制で選びます。セキュリティ要件や将来の拡張性も、判断材料に加わります。

少数のサービスを短期間で自動化するなら、マネージドサービスや既存SaaSとの組み合わせが候補になります。一方で、複数チームの標準化を進めるなら、Tektonを中心とした共通基盤を検討します。

マネージドKubernetesにTektonを構築する形態

EKSやGKE、AKSなどを使う場合、コントロールプレーンの一部運用はクラウド事業者に任せられます。そのうえで、自社標準のPipelineやTaskを設計できます。

向いている企業：クラウドをすでに使っている会社や、オンプレミスのクラスタ運用を新たに抱えたくない会社が該当します。
別途必要な費用・設定：ノード、ストレージ、ロードバランサー、IPアドレスなどが対象です。通信やログ、レジストリ、バックアップも対象に入ります。
提案依頼：開発会社には、利用量や権限、アップグレード方針、障害時の切り分けを確かめてもらいます。

OpenShift Pipelinesのようにサポート込みで導入する形態

OpenShiftが社内標準なら、TektonベースのOpenShift Pipelinesで基盤とサポートをまとめて検討できます。Operatorや認証の扱いも、同じ枠の中で確かめられます。OSSで自前に導入する場合とは、サポートや制約の違いを含めた総額で比べます。

比較しやすい案件：ハイブリッドクラウドや複数クラスタの統制を重視する場合が該当します。
費用と制約：Red Hatのサポート範囲は明確にしやすいものの、サブスクリプション費用がかかり、標準運用への制約もあります。
移行性：OpenShift以外へ移る可能性があるなら、Task、Pipeline、イメージ、IaCのどこまでを持ち出せるかを、RFPに含めます。

PoCから段階的に移行する形態

Jenkinsなどの既存資産が多い場合は、代表的な1〜2サービスから段階を踏んで確かめます。

代表的な1〜2サービスを対象に、PoCを行います。
Git pushから、単体テスト、イメージ作成、脆弱性検査、ステージング配備まで、Pipelineで一続きにつなぎます。
成功した場合だけでなく、再実行、権限不足、レジストリ停止、不正なWebhookも検証します。
合格条件は、リリース時間、失敗率、復旧時間、クラウド費用、手順の実行、監査証跡のそれぞれについて、数値か確認手順で定めます。

合格条件を、画面やYAMLの完成だけに置くことは避けます。また、PoCと本番を同じ会社に頼む場合は、終了時に追加費用と担当の分け方を見直します。

ポイント

どの形態が合うかは、対象アプリの数や既存の仕組み、社内の運用力で変わります。マネージド、OpenShift、段階移行のいずれも、移行範囲とPoCの結果を見てから決めるのが安全です。

TektonのRFPと要件整理の進め方

現状把握から運用条件までを一続きで確認できます。

TektonのRFPは、各社に同じ条件で伝えるための文書です。現状の開発・リリース業務や対象サービス、非機能要件を書き込み、連携先やセキュリティ、成果指標、移行計画も含めます。

業務アプリのRFPとは異なり、開発者体験やクラスタ運用について明記します。実行履歴やパイプラインの再利用性も、RFPに書き込みます。

既存のCI/CDジョブと課題の洗い出し

まず、現行ジョブと業務上の課題を洗い出します。そのうえで、移行範囲とTekton導入の目的を決めます。

ジョブの記録：既存CI/CDのジョブを一覧にして、移行範囲をつかみます。
移行方法：その一覧をもとに、単純移行するジョブと作り直すジョブを分けます。
現状課題：リリース時間やテスト待ち、失敗率、手戻り、夜間対応、属人化した手順を書き出します。
導入目的：不要な工程まで移さないよう、速度、環境差、証跡、属人化の解消のうち、どれを優先するかを決めます。

Jenkins、GitHub Actions、GitLab CI/CDのジョブは、一つずつ記録しておきます。リポジトリと起動条件、頻度を残し、認証情報も記録します。

生成物や配備先、承認者も押さえておきます。また、失敗時の手作業やログ保存期間も記録します。

Pipelineと周辺サービスの機能要件

Pipelineの機能と周辺サービスは分けて書き、ツールごとに担当範囲を決めます。

起動条件：Git pushやPull Requestをきっかけに起動し、ブランチやタグごとに処理を分けます。
Pipeline機能：Task再利用、並列実行、タイムアウト、リトライを含めます。承認や通知、成果物の保管、ロールバックも要件に入れます。
環境差分：開発・検証・本番で変わるパラメーターを整理し、秘密情報の渡し方とWorkspaceやServiceAccountの分け方を記します。
連携サービス：Git、レジストリ、脆弱性スキャン、SBOMとの接続を明確にします。KMSやSecrets管理、監視・ログ、配備先についても、範囲を書きます。
ツール分担：CIをTekton、CDやGitOpsをArgo CDなどで担う場合は、それぞれの担当範囲をRFPに記します。

数値で示すセキュリティと非機能要件

非機能要件は数値で示します。あわせて、履歴の管理やSBOMの扱いも決めておきます。

性能と可用性：同時実行数や1日あたりのPipelineRun数、目標実行時間を決めます。可用性と復旧時間も、数値で示します。
運用条件：保持やバックアップ、ネットワーク、データ所在地、対応時間を、運用の条件として定めます。
セキュリティ：認証や権限、通信、秘密情報、脆弱性、監査について、要件として書き込みます。
リモートTask：取得した内容の検証方法と、参照の仕方を要件に入れます。
SBOM：生成から提供までの運用と、契約上の条件を決めます。

履歴を長く残すと、etcdやAPIサーバーに負荷がかかります。そのため、保持期間と削除方法を決めておきます。

セキュリティ要件には、Webhookの署名検証や最小権限のRBACを記します。Namespaceの分離、非root実行、NetworkPolicy、digest固定も含めます。

秘密情報をログに出さない設定や、脆弱性を検出した後の対応手順、監査ログの取り方を、具体的に書きます。

HTTP ResolverはSHA-256やSHA-512で取得内容を検証できるため、リモートTaskをブランチ名だけで参照しない運用も候補になります（出典: Tekton公式「HTTP Resolver」、2026年8月確認）。

SBOMは、生成者や保管先を明確にしたうえで、脆弱性照合の時期と顧客への提供方法を決めます。

経済産業省のSBOM手引Ver.2.0は、委託契約で要求事項や責任を定める取引モデルを示しています。コスト負担や権利も、同じ契約で定める対象です（出典: 経済産業省「ソフトウェア管理に向けたSBOMの導入に関する手引Ver.2.0」、2024年）。

ポイント

RFPは、各社に同じ条件を伝えられるところまで具体的に書きます。非機能要件は数値で示し、移行と検収の条件も書き込んでおくのが無難です。

Tektonの契約形態の選び方

契約形態は、要件がどこまで固まっているか、成果物を定義しやすいか、試行錯誤が必要かで選びます。

要件整理やPoCと、本番の構築や移行とでは不確実性が異なります。そのため、工程ごとに分けて契約を考える方法が実務的です。

要件整理とPoCに向く準委任契約

準委任契約は、専門家の調査や設計、助言、作業に対して報酬を支払う形です。調査が済んでから作業量が見えてくる工程に向いています。

対象工程：Jenkinsの現状の洗い出し、Kubernetesを使えるかの確認、PoC設計、移行方針の策定が対象です。
契約内容：実施内容と稼働時間は、契約書や個別発注書で定めます。会議体や報告書、次工程へ進む判断基準も含めます。
納品物：課題一覧や現行構成図、PoCのPipeline、試験結果、リスク一覧、概算見積もりなど、判断に必要な資料を明記します。

準委任でも、成果物は決めておきます。作業時間の管理だけでは、判断材料が残らないおそれがあるからです。

完成条件が明確な構築と移行に向く請負契約

請負契約は、合意した成果物を完成させて検収し、引き渡す工程に向いています。完成条件を事前に決められる場合に、検討の対象になります。

成果物：クラスタ構成やTekton、標準Task、指定本数のPipelineが対象です。権限設定、テスト結果、運用手順書も含めます。
検収：正常系に加えて、再実行やロールバック、権限エラー、バックアップ復元も受入試験に含めます。
費用・変更：クラウドや第三者サービスの料金、顧客側の環境提供の遅れに伴う扱いを定めます。仕様変更時の追加請求や、優先順位の変更、納期の延長も含みます。

特に、変更時の扱いを決めておかないと、見積もりが安くてもトラブルになりやすくなります。

保守契約と成果物の権利の定義

保守の範囲と成果物の権利は、契約に含めておきます。そうすれば、ベンダーを替える場面でも、発注側が引き継ぎを進められます。保守作業には、障害調査や履歴削除、Pipelineの追加も含まれます。

保守作業：TektonやKubernetesの更新、Taskイメージの脆弱性、証明書と署名鍵の更新が対象です。
対応条件：対応時間や一次受付、復旧目標を決めます。月次報告や緊急変更、再委託、範囲外作業の単価も定めます。
成果物：ソースコードやYAML、IaCを扱います。設定やテストコードも扱います。設計書やダッシュボード、手順書、SBOM、署名・証跡も含めます。
権利と終了時：著作権や翻案権、OSSの表示、第三者ライブラリの責任を定めます。終わるときのデータ返却とアカウント削除も決めます。

ポイント

完成条件を事前に決められない工程は準委任で進め、判断材料になる成果物を契約で定めておくのが無難です。完成条件を事前に決められる構築や移行は、請負で検収まで含めて定めます。

Tektonのシステム開発の費用相場

導入範囲が広がるにつれて、費用レンジも大きくなります。

Tektonには、一般的な業務SaaSのような導入一式の公開定価はありません。

費用は、基盤とPipelineの設計・実装、移行で決まります。セキュリティや監視、教育、保守、クラウド利用料もそこに加わります。

ここで示すのは、リサーチノートの業務システム開発相場を導入規模に当てはめた、編集上の目安です。個別案件の確定金額ではありません。

PoC・小規模導入の初期費用目安（100万〜300万円）

開発・検証用のKubernetesにTektonを構築し、数本のTaskとPipelineを用意します。Git webhookと簡易ログの確認を行うPoCの初期費用は、100万〜300万円程度が目安です。

期間は1〜2か月程度です。ただし、商用SLAや複数環境、複雑なJenkins移行、厳格な監査要件を含む場合は、この範囲を超える可能性があります。

PoCでは、実行時間やクラスタ資源、ログ保持を測り、脆弱性検査や復旧、操作性も確かめます。PoC費用は本番費用の前払いではなく、本番の工数とリスクを具体化する調査費として評価します。

チーム導入の初期費用目安（300万〜1,000万円）

本番クラスタ一つに複数サービスを載せるチーム導入では、初期費用300万〜1,000万円程度が目安になります。

含む作業：権限分離やレジストリ、テストに加え、ステージング配備も作業に入ります。監視や運用手順の整備も含みます。
期間と変動要因：2〜4か月程度です。工数を変えるのは、サービス数や既存ジョブの複雑さ、マルチテナント、SSO、可用性要件です。
見積項目：要件定義、クラスタ設計、Tekton、共通Task、移行は、別々に示してもらいます。

見積もりでは、セキュリティ、テスト、教育、文書、リリース支援も、別の項目にしてもらいます。「CI/CD基盤構築一式」とだけ書かれた見積もりでは、対象作業を比べられません。そのため、安く見えても注意が必要です。

全社展開の初期費用の目安（1,000万〜5,000万円程度）

全社導入の初期費用は、範囲によって1,000万〜5,000万円程度になるケースがあります。監査ログやKMS、Chainsの証跡も、範囲に含まれます。SBOMや監視も範囲に入り、教育や段階展開も加わります。

対象範囲：大規模Jenkins移行、複数チーム・環境、SSOの有無で規模が変わります。
大規模案件：複数クラスタやDR、厳格な変更管理、24時間運用、基幹連携を含む場合は、5,000万〜1億円以上になる可能性もあります。
期間：部門展開なら6〜12か月、複数クラスタや段階移行を含む場合は12〜24か月が目安です。
見積条件：一律の価格ではなく、業務システム開発の相場を導入規模に当てはめた目安です。対象アプリ、Pipeline、環境、移行ジョブ数をそろえて比べます。

クラウドの実費は、開発費とは分けて考えます。たとえば、AWS EKSの標準サポートは1クラスタ・1時間あたり0.10米ドル、延長サポートは0.60米ドルです。730時間稼働させた場合、管理料だけで月73米ドルまたは438米ドルになります。

管理料とは別に、EC2やEBS、ロードバランサーの料金がかかります。IPv4、通信、ログ、レジストリも対象です（出典: AWS「Amazon EKS pricing」、2026年8月確認）。

Google Cloud GKEの管理料も、1クラスタ・1時間あたり0.10米ドルです。また、延長期間には追加料金がかかります（出典: Google Cloud「Google Kubernetes Engine pricing」、2026年8月確認）。

ポイント

費用の目安は導入規模によって大きく変わるため、規模に合う金額帯で比べます。クラウド実費と保守費は、開発費とは分けて見積もります。

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

委託先は、Kubernetesの運用やTektonの実装、CI/CDの移行を一体で進められるかで選びます。クラウドやセキュリティ、業務側との合意まで含めて確かめます。知名度や提示額は、判断材料の一つにとどめます。

公開情報にTektonの解説があっても、実案件の規模や担当範囲までは分かりません。そのため、提案の場で具体的な質問をします。

導入環境と技術の適合性の確認

候補会社の技術経験は、自社の導入環境と運用要件に照らして確かめます。TerraformなどのIaCを納品できるかも、あわせて確かめます。

環境と納品：EKS、GKE、AKS、オンプレミス、OpenShiftへの対応と、クラスタの運用者を聞きます。
Tekton構成：必要なコンポーネントを、利用範囲と合わせて示せるかを見ます。
実績：Jenkins移行やGitOpsの分担について、経験を尋ねます。digest固定やSBOM、署名、KMS、脆弱性対応、監査ログについても経験を確かめます。
運用説明：失敗時の再実行や秘密情報の保護、履歴削除、更新手順を、具体的に説明できるかを見極めます。

Tekton Pipelines、Triggers、Pipelines-as-Code、Chainsは、どこまで使うのかを確かめます。Results、Dashboard、CLI、Operatorを使うかどうかも、提案の段階で聞いておきます。

見積もりの前提と作業項目のそろえ方

見積もりは、前提と作業項目をそろえてから比べます。そのうえで、自社要件に対する過不足を評価します。

共通の前提：クラスタ、環境、サービス、Pipelineの数や既存ジョブの数をそろえます。対応時間や移行方式、テスト範囲、納品物、保守期間も合わせます。
費用の内訳：要件定義やPoC、設計、構築、移行は、別々の金額で示してもらいます。セキュリティ、テスト、教育、リリース支援、保守も項目ごとに分けます。
不足と過剰：安くても、移行や手順が含まれていない場合があります。高額でも、不要な24時間対応などがあれば過剰かもしれません。

各社には、「含む」「含まない」「別途」を明記してもらいます。そうすれば、前提条件の違いをそろえて比べられます。

納品物と導入後の支援体制の確認

納品物は発注側で管理できる形か、運用上の課題に対応できる支援体制があるかを確かめます。

納品物：構成図や設計書、Task・Pipeline、IaCが基本です。設定値と権限の一覧、テスト仕様と結果、障害対応、復旧と更新の手順、教育資料も求めます。
管理方法：設定がベンダーの画面や担当者の端末だけに残らず、発注側のGitでレビューや変更ができる状態にします。
保守：更新や緊急の脆弱性対応、証明書・署名鍵の扱いを確かめます。履歴の保持と削除、障害対応、利用チームの追加も見ておきます。

Tekton公式は、Tekton Prunerを紹介しています（出典: Tekton公式「Introducing Tekton Pruner」、2026年2月）。保持ポリシーでPipelineRunやTaskRunを自動削除し、etcdやAPI性能への負荷に対応する仕組みです。こうした運用の課題まで説明できる会社を選びます。

ポイント

委託先は金額だけで比べず、見積もりに含まれる作業と自社の責任範囲をそろえて判断します。提案の場で具体的な質問を投げかけると、実案件の力量が見えやすくなります。

Tekton導入後の保守運用の委託範囲

Tektonは構築後も運用の見直しが必要です。KubernetesやTektonの更新、Taskイメージ、クラウド料金の変化への対応が続きます。

さらに、脆弱性や証明書、署名鍵の期限、実行履歴の増加、利用チームの追加にも備えます。そのため、初期構築と保守は契約を分けて、稼働後に誰がどの作業を担当するかを明確にします。

クラウド・Kubernetes・Pipelineの担当の分け方

クラウド事業者が担うのは、基盤の提供までです。そのため、クラスタ内の設定や権限、Task、秘密情報は、別に担当を決める必要があります。テストやPipelineの誤設定も含め、開発会社、クラウド運用会社、社内部門の担当を場面ごとに整理します。

責任範囲：クラスタ障害やPipeline失敗、脆弱性、誤配備、情報漏えい、料金超過が対象です。
障害対応：一次受付の時間や重大度、暫定復旧と恒久対応を決めます。ログの提供や原因報告、再発防止策の期限も含みます。
緊急アクセス：管理者権限をベンダーだけに集中させず、発注側にもアクセスの手順を持たせて、操作ログを残します。

導入効果と運用KPIの継続的な測定

目標と実績を月次で比べ、導入効果と運用上の無駄を見直します。

測定指標：デプロイ頻度や変更のリードタイム、Pipeline成功率を見ます。失敗からの復旧時間と手動作業の時間も測ります。
運用指標：脆弱性の検出から修正までの日数、クラウド費用、実行履歴の保存量を見ます。
月次の見直し：不要なTaskや過剰な資源、長すぎるログ保持、重複するPipelineを、月ごとに洗い直します。

Tektonは、2025年5月のPipelines 1.0以降もリリースが続いており、2026年3月にはCNCFのインキュベーションプロジェクトになりました（出典: Tekton公式「Tekton Joins the CNCF as an Incubating Project」、2026年3月）。

一方で、導入を急ぐ前に、採用するバージョンやサポート期間、互換性、更新の担当を、契約と運用計画に記しておきます。

Tektonのシステム発注・外注でよくある質問

OSSであることから、費用や運用負担を誤解しやすい面があります。また、既存CI/CDの移行範囲も会社ごとに異なります。発注前によく出る疑問に答えます。

Tektonは無料なので導入費用も無料ですか？

いいえ。OSSのライセンス費用がない場合でも、導入が無料とは限りません。

基盤側では、Kubernetesやノード、ストレージ、レジストリ、監視、セキュリティの費用が発生します。導入側では、設計・構築、移行、教育、保守がかかります。そのため、総保有コストで比べます。

Kubernetesの経験がない会社でもTektonを発注できますか？

発注はできます。ただし、Kubernetesの設計や権限、ネットワーク、監視、更新に対応できる会社を選びます。

社内に経験が少ない場合は、PoCや運用手順、教育、稼働後の伴走保守まで含めて、担当者が自走できるまでの支援をRFPに記載します。

JenkinsからTektonへ一度に移行するべきですか？

まずは代表的な1〜2サービスでPoCを行い、並行稼働と段階移行を検討します。

移行の順番や既存成果物との同一性、テスト結果を決めます。切り戻しの条件とJenkinsの停止時期も定め、問題が起きたときに旧環境へ戻せる期間を設けます。

Tektonの委託先に見積もりを依頼するとき何を渡しますか？

対象サービスとリポジトリ、現行ジョブ、クラスタとクラウドの条件を渡します。利用者や環境の数、Pipelineも示します。連携先やセキュリティ、希望時期を伝え、予算や納品物、保守範囲も共有します。

機密情報を含む場合は、先に秘密保持契約を結びます。そのうえで、実データの代わりに構成資料を使って提案を受けます。

まとめ

Tekton発注では、インストールだけでなく、Kubernetesやレジストリとの連携、監視、配備、保守までを、一つの基盤として考えます。

マネージドKubernetesやOpenShift Pipelines、OSS導入、段階移行を比べ、自社の運用体制と拡張性に合う形態を選びます。

発注成功のために押さえる要点

RFPでは、既存CI/CDの課題や対象、機能を具体的に書きます。セキュリティや非機能要件、移行、検収も、具体化しておきます。

費用の目安は、PoC・小規模が100万〜300万円、チーム導入が300万〜1,000万円、全社展開が1,000万〜5,000万円程度です。クラウド実費と保守費は、これとは別に見積もります。

金額だけでなく、見積もりに含まれる作業と自社の責任範囲も比べます。

最初の一歩は既存CI/CDの洗い出しと小規模PoC

全社のPipelineを一度に完成させようとせず、代表サービスでGit pushからテスト、イメージ検査、ステージング配備までを検証します。

結果をもとに、同じRFPで複数社の提案と見積もりを比べます。納品物や契約、保守、ベンダー交代の条件に合意してから、本番展開へ進みます。

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

▼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を創業。