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

FORTRANのシステム発注は、現状調査とPoC、範囲を定めた本開発、結果検証と受入れの順に進めると、計算業務を止めずに刷新しやすくなります。

発注形態の選び方から委託先の比べ方まで、この流れに沿って説明します。全体像はFORTRANのシステム開発の完全ガイドもご覧ください。

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

FORTRANのシステム発注・外注で最初に決める事項

FORTRANのシステムには、画面や帳票のほか、数値計算エンジン、ライブラリ、バッチが含まれます。さらに、データ形式、実行環境、結果の判定ルールも、発注の対象として整理しておく必要があります。

発注の前に「何を作るか」と「何を変えてはいけないか」を決めておくと、価格だけで委託先を選ぶ失敗を防ぎやすくなります。

業務成果で定める発注の目的

発注の目的は、達成したい業務成果で書きます。「FORTRANを新しい言語に変える」は、その目的を実現する手段のひとつです。

  • 停止を防ぐ:設計計算を止めずに、新しいOSへ移行する
  • 入力を効率化する:計算担当者がWeb画面から条件を入れられる形にする
  • 待ち時間を減らす:計算が完了するまでの時間を短くする

言語の変換そのものを目的にすると、画面が新しくなっても、丸め処理や境界条件といった業務ルールが抜け落ちるおそれがあります。

経営層に説明するときは、停止できる時間や利用者数、計算件数などの指標を使うと、投資判断につながります。また、保守費用や担当者の引き継ぎも、同じ指標で示す対象になります。

計算結果と再現性の合格基準

画面が表示されて処理が終わっても、FORTRANの外注が納品完了とは限りません。計算結果が正しいかは別に確かめる必要があり、そのため、合格基準をあらかじめ決めておきます。

  • 結果の許容範囲:同じ入力を旧新環境に与えたうえで、完全一致を求めるか、工学的に許容できる誤差を認めるかを決める
  • 比較用データ:通常値と境界値に加えて、異常値や欠損値、最大規模のデータを用意する
  • 判定記録:入出力と実行環境、コンパイラやオプション、判定者の記録

比較用データは、「ゴールデンデータ」として扱います。特に、安全率や規制対応に関係する計算では、許容誤差の根拠と承認者をRFPに記載します。

発注形態の選び方

段階発注、請負発注、準委任・ラボ型発注を3つのパネルで整理した図。
調査で不確実性を減らし、範囲が固まった作業から契約形態を選べます。

発注形態は、現状の整理度と、成果物を固定できるかどうか、専門人材をどこまで確保できるかで選びます。特にFORTRANの移行は、調査・PoCで不確実性を減らしてから本開発に進む段階発注が適しています。

調査・PoCを先に依頼する段階発注

ソースや実行環境が分からない、仕様書が足りない、過去の出力しか正解データがないといった場合は、現状調査とPoCを分けて発注します。

  • 現状調査:ソースと実行環境(コンパイラ、OS、ライブラリ)、入出力形式、ジョブ、外部連携、運用手順を一覧にする
  • PoC:代表ケースを新環境で動かし、コンパイルの難所や計算差異、処理性能、移行候補を確かめる

リサーチノートでの目安は、3〜10人月、約300万〜1,500万円、1〜3か月程度です。ただし、これはFORTRAN固有の定価ではなく、対象範囲から算出した推定レンジです。

成果物を固定できる部分の請負発注

要件と対象範囲、受入基準、納期、成果物を明確にできる部分は、請負契約で依頼するのが適しています。

  • 計算エンジン:特定モジュールの再コンパイル
  • 画面・帳票:入力画面や帳票の追加と刷新
  • 連携機能:APIの開発

「計算結果を完全一致させる」とだけ書くと、浮動小数点や並列実行の差異をめぐって争いが起きます。このため、対象ケースや許容誤差などの条件を、再現条件やテスト件数、未達時の扱いとあわせて、成果物と受入条件に記載します。

専門人材を確保する準委任・ラボ型発注

要件が変わりやすい場合や、古いコードを読みながら業務部門と仕様を固める場合は、準委任やラボ型が候補です。さらに、社内にFORTRANとHPCの知見を蓄積したい場合にも検討できます。

  • 柔軟な進行:稼働時間や体制を確保し、優先順位に沿って調査・設計・レビュー・実装を進める
  • 成果の管理:成果物と納期は自動で保証されないため、月次で成果と残課題を確認する
  • 発注側の体制:プロダクト責任者、業務担当者、受入担当者の配置

ポイント

発注形態は、仕様や正解データがどこまで固まっているかで選びます。固まっていない部分は調査・PoCから始め、範囲が定まった部分から請負や準委任に切り替えるのが目安です。

RFPと要件整理で伝える内容

RFPに整理する現行資産、機能要件、非機能要件と納品物、運用資料を示すチェックリスト図。
情報の範囲をそろえると、各社の見積り前提を比べやすくなります。

RFPは、見積りを依頼するための資料です。同時に、発注側が自社の業務とリスクを整理するための資料にもなります。

機能一覧だけでは工数を見積もれません。ソースと実行環境、正解データ、周辺システムに加え、性能、セキュリティ、保守の条件を示すと、各社の前提がそろい、見積りを比べやすくなります。

現行資産と依存関係の一覧

現行資産と依存関係について、RFPには次の情報を記載します。

  • 言語とソース:FORTRANのバージョン、固定形式か自由形式か、ソース行数
  • 実行環境:コンパイラ名と版、OS、CPU、数値計算ライブラリ
  • 連携と入出力:CやCOBOLのサブルーチン、ジョブ管理、入力ファイル、出力帳票
  • 特殊な依存:COMMONブロック、暗黙型、非標準拡張、文字コード、固定長ファイル、外部DLLや共有ライブラリ

分からない項目は空欄にせず、「調査対象」と書きます。そのうえで、受注者が調査する場合の費用と期間を、別枠で見積もってもらいます。

計算業務の流れで書く機能要件

機能要件は、計算業務の一連の流れに沿って書きます。「入力画面を作る」のような書き方は避けます。

  • 条件入力:設計担当者による材料条件と荷重条件の入力、妥当性エラーの確認
  • 計算と承認:計算の実行と結果の承認
  • 保存:帳票と元データの保存

入力では、入力項目と単位、初期値を中心に整理します。あわせて、必須と任意の区別、異常値、計算式も、その範囲に入れます。さらに、再実行や取消、版管理、帳票を同じように整理し、Excel・CSVの前処理も業務機能に入れます。

非機能要件と納品物の具体化

非機能要件と納品物は、運用や将来の保守に必要な範囲まで、次のとおり指定しておきます。

  • 性能・稼働:処理時間や同時実行数、計算ノード、稼働時間
  • 安全性:バックアップ、障害復旧、認証・権限、監査ログ、脆弱性対応、データ保存期間
  • 環境:クラウドやオンプレミスの制約
  • 納品物:ソースコード、ビルド手順、環境定義、ライブラリ・ライセンス一覧、テスト仕様書
  • 運用資料:旧新結果比較表、操作マニュアル、運用・復旧手順、既知の制約、引き継ぎ資料

納品の基準を、別の会社でも保守できる状態に定めておくと、ベンダーロックインのリスクを下げられます。

FORTRANのシステム開発を外注する手順

まず発注側の体制を整え、そのうえで候補会社を選びます。続いて、RFPを配布して提案と見積りの前提をそろえ、調査・PoCで技術リスクを確かめます。

その後、本開発と受入れへ進みます。各段階の判断条件を先に決めておくと、問題が起きたときに計画を見直しやすくなります。

技術領域と体制による候補会社の絞り込み

候補会社は、FORTRANの経験だけでなく、必要な技術領域の組み合わせで探します。

  • 移行・計算:レガシー移行、数値計算、HPC
  • 周辺システム:Web・API、データベース、業界知識
  • 運用:開発後の運用保守

たとえば、日立は栗本鐵工所のVOS1上にある技術計算FORTRAN資産を、オープンシステムへ移行しました。また、川重テクノロジーは耐震設計プログラムを、ホスト・UNIXからWindows PCへ移植しました。

ただし、事例が自社の案件と完全に一致するとは限りません。そのため、担当者の経験や再現性の検証方法、対応コンパイラ、ソースの権利と納品範囲を確認します。

提案書と見積りの前提のそろえ方

各社には、同じRFPと代表データ、質疑回答を渡して、見積りの対象をそろえます。

  • 提案内容:移行方式の理由、対象外範囲、前提、リスク、体制、工程
  • 品質と保守:テスト方法、受入基準、保守費用、発注側に必要な作業
  • 見積内訳:工程別人月、役割別単価、再委託、追加費用の条件

極端に安い見積りでは、調査やテストが含まれていない可能性があります。さらに、文書化や移行支援が抜けていることもあります。

契約時から設計する受入れと運用移行

受入れでは、機能テストに加えて、次の4つの面から確かめます。

  • 計算結果と処理速度:旧新結果の比較、許容誤差、性能の確認
  • 運用:バッチの再実行、障害復旧、権限、ログ、バックアップ
  • 利用者:受入れと操作教育
  • 引き継ぎ:問い合わせ窓口、障害時の一次切り分け、保守会社への受け渡し

旧システムは、すぐには停止せず、一定期間は並行稼働するか、参照できる状態に残しておきます。そのため、差異が出たときに、入力やコードなどのどこに原因があるかを追跡できます。

並行稼働と差異の追跡に加えて、教育、問い合わせ、障害対応、保守引き継ぎも、本番移行の作業として見積もります。

ポイント

外注は、候補会社を技術領域で絞り、同じRFPで見積りをそろえてから進めます。本開発に入る前に調査・PoCで技術リスクを確かめ、受入れの基準も契約時に決めておきます。

FORTRAN外注の契約形態の選び方

契約形態は、調査や要件定義の不確実性と、納品物の確定度で決めます。具体的には、調査は準委任、本開発のうち確定した部分は請負、保守と改善は準委任とする組み合わせが現実的です。

契約書では、成果物や作業範囲、責任の分け方を確認します。さらに、知的財産や変更手続き、検収の扱いを見ておきます。再委託と秘密保持も、契約書に書いておく項目です。

調査や変化の多い工程に向く準委任契約

準委任は、専門家に調査や設計、開発支援を委託する契約です。レビューも、同じ契約の中で受けられます。

  • 資産調査:現行資産を読み解きながら要件を詰める
  • 仕様検討:社内の業務担当者と仕様を固める
  • 性能改善:HPC上での改善策の試行

成果が曖昧なままだと、作業時間だけが過ぎてしまいます。そのため、月次の成果物や残課題、次月の優先順位を合意しておきます。

稼働実績や品質指標も、あわせて決めておきます。さらに、発注側が意思決定を止めない体制も必要です。

受入条件を固定できる工程に向く請負契約

請負は、決められた成果物を完成させ、発注者が検収する工程に向きます。

  • 画面・API:完成条件を定めた機能の開発
  • データ移行:データを移すツールの作成
  • モジュール移植:特定の範囲を新環境へ移す

環境の変更で計算差異が出る可能性がある場合は、入力セットと比較方法、許容値を受入テストで定めておきます。そのうえで、未達時の追加対応と仕様変更の扱いを、契約書や個別契約に反映します。

ポイント

工程ごとに契約を分けるのが現実的です。不確かな調査や要件定義は準委任で進め、確定した部分だけを請負に切り替えると、成果の責任を発注側と受注側で分けて持てます。

FORTRANのシステム外注費用・相場の目安

調査・PoC、小規模移植、中規模刷新、大規模刷新の概算費用レンジを横棒で比較した図。
規模が上がるほど概算額の幅も大きくなります。

FORTRANのシステム開発には、一律の公開価格がほとんどありません。費用は、ソースの量そのものより、依存関係や計算結果の検証で変わります。

また、入出力や周辺連携、移行データが費用を左右します。性能、セキュリティ、運用の引き継ぎについても、費用に影響します。

これは、リサーチノートで参照したJUAS「ソフトウェア・メトリクス調査2025」の単価情報と想定工数から求めた概算で、個別案件の確定価格ではありません。

調査・移植・刷新の費用レンジ

規模別の概算を見るときは、対象範囲と期間をあわせて確認します。

  • 調査・PoC:3〜10人月、約300万〜1,500万円、1〜3か月程度
  • 小規模移植:再コンパイル・PCまたはLinux移植で10〜30人月、約1,000万〜4,300万円、3〜8か月程度
  • 中規模刷新:UI、DB、帳票、認証、バッチ、データ移行、性能試験を含み30〜100人月、約3,000万〜1億4,400万円、6〜18か月程度
  • 大規模刷新:100〜500人月、約9,600万〜7億2,000万円

大規模案件は、基幹やHPC、メインフレーム、リアルタイム連携を含み、複数工場にまたがる複数言語も対象になります。さらに、厳格な精度保証や24時間運用も対象となり、期間は1〜3年程度またはそれ以上かかる可能性があります。

試算は、JUASの参考単価を基準にしています。たとえば、スクラッチ開発の加重平均は96万円/人月、パッケージ利用開発は144万円/人月です。

試算は、FORTRANの市場価格を断定するものではありません(出典: JUAS「ソフトウェア・メトリクス調査2025」、2025年)。

見積りに含める費用と別建てにする費用

見積りの内訳と、別建てになる費用は分けて確認します。

  • 開発工程:要件定義、資産解析、設計、移植・再実装、画面・API、DB、帳票、外部連携
  • 移行・定着:テスト、データの移し替え、教育、運用引き継ぎ
  • 別建て費用:商用コンパイラ・数値ライブラリ、HPCサーバー・GPU、クラウド計算・保存・転送、監視、診断、現地試験、旧環境の延命

クラウドHPCは初期費用を抑えやすい一方で、ジョブ数や計算時間によって従量費が変動します。そのため、月次の上限と利用量の監視を設けます。

保守・運用費と初期開発費の分け方

保守契約では、含める作業と対応条件を具体的に確認します。

  • 障害・改修:障害対応、問い合わせ、軽微な改修
  • 環境・安全:コンパイラ・OS更新、脆弱性対応、バックアップ確認
  • 計算運用:性能監視、HPCリソース管理、定期的な結果検証

業務システム全般では、保守費用を初期開発費の15〜20%程度とする目安があります。一方で、FORTRANのように希少な人材を専任で確保する案件では、上振れする可能性があります。

年額は割合だけで決めず、対応時間や対象環境、緊急対応を分けて見積もります。さらに、月の作業時間と契約外作業の単価も、別々に確認します。

ポイント

FORTRANの外注に公開価格はないため、規模別の概算は参考にとどめます。比べる際は、計算基盤や保守の費用まで含めた総額で見ます。

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

委託先には、FORTRANを書けることに加えて、計算業務を安全に引き継げる能力を求めます。

提案書の見栄えや総額より先に、代表ケースの検証方法や難しい資産への対応、説明力、納品後の保守体制を確かめます。

候補会社には同じ質問をし、回答を記録して比べられるようにします。

言語・数値計算・移行の実績

候補会社の対応技術と実績は、案件で使う要素に合わせて確認します。

  • 言語・連携:FORTRAN 77・90・95・2003・2008、固定形式、非標準拡張、C・COBOL連携
  • 計算技術:BLAS・LAPACK、OpenMP・MPI、CPUベクトル化、GPUオフロード
  • 実行環境:Linux、Windows、メインフレーム、Web API、データベース

Intelの2025.3公式文書では、従来型のIntel Fortran Compiler Classic(ifort)の終了が示されています。終了の時期は、2024.2のリリース後です。さらに、同文書はLLVMベースのifxへの移行を推奨しています。

ifortを使う案件では、発注側が移行経験や警告・非標準拡張への対応、旧新結果の比較方法を質問します(出典: Intel「Fortran Compiler Developer Guide and Reference」、2025年)。

工程・人月・前提条件に分けた見積りの比較

各社の見積りは同じ項目を横並びにし、費用差の理由を確認します。

  • 金額・体制:総額、期間、体制、工程別人月、単価
  • 範囲:成果物、対象外、リスク対応費、再委託費
  • 運用費:ライセンス費、保守費

特に、現状調査とテスト、発注側の作業人月を見ます。工程を極端に短くした提案では、検証やレビューが削られている場合があります。

JUASの調査事例では、外部委託先の工数・工期や、要件・設計・テスト・移行計画の節目の確認に、メトリクスを使っています(出典: JUASソフトウェアメトリクス調査、2025年)。

保守・セキュリティ・引き継ぎに関する質問

保守と引き継ぎの責任、ソースや環境の扱い、セキュリティ対応を確認します。

  • 保守担当:担当者の退職後に誰が保守するか
  • 資産の保有:発注者がソースとビルド環境を保有し、第三者が再ビルドできるかどうか
  • セキュリティ:脆弱性の対応時間、クラウドの保管場所と削除方法

生成AIをコード解析やリファクタリングに使う場合は、入力データを学習に使わない設定を契約で定めておきます。あわせて、人手レビューとライセンス確認、結果検証の記録も決めておきます。

NTT DATAは、Fortranを含むレガシーアプリについて、コード解析から性能改善、セキュリティ強化、データ連携までを段階的に進める考え方を紹介しています(出典: NTT DATA「Generative AI: A Transformative Force in Legacy App Modernization」、2025年)。

ポイント

委託先は、FORTRANの経験だけでなく、代表ケースの検証方法や納品後の保守体制で比べます。見積りは同じ項目を横並びにし、費用差の理由を一社ずつ確かめます。

クラウド・HPCを含む発注での注意点

クラウドHPCでは、必要なときに多並列や大容量メモリ、GPUを使える可能性があります。ただし、クラウドに移したからといって、自動的に安く速くなるとは限りません。

RFPには、データ転送やライセンス、機密性に関する条件を含めます。ネットワークや並列化の条件も書いておきます。

計算ノードの確保や従量課金、障害時の再実行も盛り込みます。また、オンプレミスとの比較も行います。

計算量と費用を管理できる設計

利用量と予算を把握し、上限を超える前に対応できる設計にします。

  • 利用量:ジョブごとのCPU・GPU時間、メモリ、ストレージ、転送量の記録
  • 自動制御:ジョブの自動停止とアイドルリソースの解放
  • 予算管理:部署別の上限、利用量アラート、結果データの保存期間の設定

CTCのRescale ScaleXは、HPC向けの従量課金サービスで、ブラウザからジョブを投入できます。同サービスは、通信経路とストレージを暗号化し、SOC2・ITAR・CSAの認証を取得していると説明されています。

自社データや契約条件への適合は、個別に確認します(出典: 伊藤忠テクノソリューションズ「Rescale Platform」、確認日2026年8月)。

性能改善と精度維持の別々の検証

並列化やGPUオフロードでは、処理時間だけでなく、実行順序の変化による浮動小数点の差異も確認します。

  1. 逐次実行による旧新結果の比較
  2. OpenMPやMPIなどの並列化の適用
  3. 各段階での精度と処理時間の記録

誤差が許容範囲内でも、再実行で差が広がる、異常値を見落とす、ログが残らないといった場合は、本番へ進めません。そのため、性能目標と精度目標、実行ログを、それぞれ別の受入条件として評価します。

FORTRANの外注で起きやすい失敗と対策

失敗は、FORTRANを使ったことより、発注前の不確実性を見積りと契約に反映しないことで起きます。そのため、計算結果の責任と仕様書にない現場ルールを、先に明確にしておきます。

古い環境の再現や、引き継ぎと保守の担当も、あわせて決めておきます。

全面Rewriteを先に決めてしまう失敗

全面書き換えは保守性を高める可能性がありますが、計算ロジックの再実装と検証には、大きな工数がかかります。

  • オープン化の事例:日立が栗本鐵工所のVOS1上のFORTRAN資産をオープンシステムへ移した
  • 移植事例:川重テクノロジーが、アルゴリズムを変えずに耐震計算の差異を従来比1%以内に抑えた

自社では、再コンパイルやラッパー化、UI刷新、部分再構築、全面Rewriteを比べてから方式を決めます。

最安値だけで決めてテストが不足する失敗

安い見積りが悪いとは限りません。ただし、調査や受入テストが削られていないかは確認します。文書化や教育が含まれているかも、あわせて見ます。

費用差が大きい場合は、同じRFPに対する工数と工程を分けて比べ、差の理由を質問します。体制、対象外、リスク予備費についても、同じ観点で比べます。

発注側は、業務担当者に必要な参加時間も確認し、社内の負担を含めた総コストで判断します。

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

FORTRANの発注では、対応会社、移行の要否、費用、準備物について、よく質問されます。発注の前に判断できるよう、主な質問に答えます。

FORTRANのシステムを開発・移行できる会社はありますか?

あります。ただし、FORTRANを書けることに加えて、既存コードの調査や数値計算の検証にも対応できる必要があります。さらに、周辺連携やクラウド・HPC、運用保守への対応も求められます。

確認したいのは、対象コンパイラやFORTRAN 77・非標準拡張への対応です。あわせて、旧新結果の比較方法と、ソースやビルド環境の納品範囲も見ます。

FORTRANはJavaやPythonへ書き換えるべきですか?

必ずしも書き換える必要はありません。計算ロジックが安定していて、課題がOSや画面にある場合もあります。連携や保守人材が課題になることもあります。

OSや画面、連携の課題は、再コンパイルやリホスト、ラッパー化、UI刷新で解決できる場合があります。

全面Rewriteは、機能追加や保守性に明確な効果があり、旧新結果を検証する期間と予算を確保できる場合に選びます。

FORTRANのシステム外注費用はどのくらいですか?

目安として、現状調査・PoCは約300万〜1,500万円、小規模移植は約1,000万〜4,300万円、中規模刷新は約3,000万〜1億4,400万円の推定レンジです。

大規模な基幹・HPC案件は、1億円未満から数億円以上まで幅があります。その幅は、対象範囲と検証要件で変わります。

試算は、JUASの人月単価を参考にしたものです。ただし、コンパイラやライセンス、計算基盤、クラウド、データ移行、保守は、別費用になる場合があります。

RFPがなくても開発会社へ相談できますか?

相談できます。仕様書やソースが不足している場合は、本開発の見積りは求めず、現状調査とPoCを提案してもらいます。

利用目的や利用者、計算の入出力(過去の代表的な入出力を含む)を伝えると、調査範囲を決めやすくなります。稼働環境や困りごと、停止可能時間も、あわせて伝えます。

まとめ

FORTRANの外注では、言語の新しさや見積りの安さだけで委託先を決めないことが重要です。

まず、現行資産や計算業務、入出力、正解データを洗い出します。そのうえで、実行環境や周辺連携、保守課題も一覧にします。また、計算結果の再現性と許容誤差についても合意します。

最初に発注する調査・PoCと判断材料

仕様書や担当者が不足している場合は、調査・PoCを独立して発注し、再構築の方法を判断します。

  • 調査・PoC:3〜10人月程度をかけた判断材料づくり
  • 方式比較:再コンパイル、リホスト、ラッパー化、部分再構築、全面Rewriteの比較
  • RFP:機能要件、性能、精度、ログ、バックアップ、セキュリティ、納品物、引き継ぎを含めた内容
  • 判断の体制:同じ前提で複数社を比べ、業務責任者と受入担当者が旧新比較と利用者承認を行う

体制が整えば、計算業務を止めずに段階的に刷新できます。

計算結果を守りながら保守できるパートナーの選び方

FORTRAN開発は、画面やコードを納品して終わるプロジェクトではありません。そのため、納品後も計算結果を守りながら保守できる相手を選びます。

  • 成功条件:結果の説明可能性と再現性、処理性能、監査可能性、障害復旧、将来の引き継ぎまでを含める
  • パートナー選定:技術と業務の両方を理解する相手を選び、長期運用の安定につなげる

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

会社紹介

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

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

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

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

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

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