マイナンバー管理システム開発の完全ガイド

マイナンバー管理システムは、自治体や企業で番号を業務に使うための基盤です。番号の紐付け、利用の制御、保存と廃棄を整え、安全に業務を回せる状態をつくります。自治体住民系と企業人事労務系では目的が異なるため、まず対象を分けて考えます。

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

マイナンバー管理システムの概要

このシステムは、特定個人情報を業務上必要な範囲で利用するための仕組みです。誰が、いつ、何の目的で扱ったかを追跡できるようにしておくことも、このシステムの役割です。扱うデータや業務は対象によって異なるため、導入時には自治体向けか企業向けかを切り分けることが欠かせません。

自治体住民系と企業人事労務系の目的の違い

自治体と企業では、番号を使う業務も、管理する情報も異なります。

自治体住民系：住民情報と番号を結び付け、法令で認められた事務に使う仕組みです。
企業人事労務系：番号の収集から、法定調書の出力、退職後の保存と廃棄までを扱います。

自治体では、住民票コード、宛名番号、個人番号を関連付けて、社会保障、地方税、防災などの事務に使います。

住民異動や出生、死亡、転入、転出、氏名変更は複数の業務に反映する必要があるため、照合、職務別の権限、窓口対応の継続性も設計します。

企業では、従業員、扶養親族、支払先から番号を集めます。そのうえで、本人確認や保管を行い、給与・年末調整・法定調書への出力も管理します。

従業員数に応じた月額サービスで足りる場合もあります。一方で、給与、人事、会計との連携や複雑な権限が必要になると、追加開発を検討することになります。

個人番号、マイナンバーカード、関連番号の違い

番号と関連する仕組みの役割を分けて把握すると、連携や権限の設計を進められます。

個人番号：法令に基づいて利用される12桁の番号です。
マイナンバーカード：本人確認や電子証明書に使われるもので、個人番号を自由に読めるものではありません。
住民票コード・宛名番号：住民票コードは住民識別用、宛名番号は自治体内部の住民管理用です。
JPKI・LGWAN：JPKIは公的個人認証サービスによる本人確認、LGWANは行政機関向けの閉域性を持つネットワークです。
中間サーバー：情報照会・情報提供を仲介する仕組みです。

これらを同じ項目として扱うと、連携ミスや過剰な権限付与につながりかねません。そのため、要件定義書で用語を分けて書き、データの経路を図にして、関係者の認識をそろえておきます。

マイナンバー管理システムの主な機能と構成

登録時の照合から利用後の追跡までを一続きで捉えられます。

必要な機能は対象業務によって変わります。ただし、どの対象にも共通する考え方があります。

番号は正確に登録し、必要な人だけが使い、利用状況を検証できるようにします。不要になった情報は適切に処分します。

自治体向けは連携と可用性を重く見ます。一方で、企業向けは収集と給与・会計連携の比重が大きくなります。

登録・照合・業務間連携の整備

登録時に確かめる事項と、業務システム同士で決めておく連携条件を、あらかじめ整理しておきます。

登録：番号入力、本人確認、重複検知、変更・廃止、保存期間の管理。
照合：自治体では、住民異動による更新と番号照合が中心です。
誤紐付け防止：検索、候補表示、二者確認、エラー時の差し戻しを組み込みます。
連携先：住民記録、地方税、国民健康保険、年金、福祉、児童手当、戸籍などです。

入力された番号が正しくても、別人の宛名番号へ結び付いてしまえば重大な事故につながります。

連携方式は、API、ファイル、メッセージから選びます。連携では、項目定義、文字コード、更新頻度を決めます。さらに、再送、重複排除、失敗通知の決め方も定めます。

中間サーバーやマイナポータルと接続する場合は、許可する通信と保持するログを書面に残します。

権限・マスキング・監査ログによる利用の制御

アクセス制御、監査、異常検知を組み合わせることで、番号の利用を追跡できるようにします。

権限：所属や業務を基本に、操作・対象データ・時間帯・端末で絞り込んで定めます。
表示・承認：番号は通常マスキングし、許された操作に限って一時的に表示します。操作ごとの承認も検討します。
監査ログ：利用者、日時、端末を記録します。さらに、対象者、操作、結果、承認者も残します。
異常検知：大量の照会や業務時間外のアクセス、短時間に続く失敗を検知します。

登録、閲覧、出力に加えて、訂正・削除・権限変更にも承認を求めることを検討します。ログは、改ざんを検知できる状態にして保管します。

バックアップと暗号化、鍵管理は非機能要件に記載します。媒体の持ち出し制御と復旧も、非機能要件に含めます。

パッケージ・クラウド・スクラッチの方式の選び方

方式は、既存業務との適合度と標準仕様で比べます。加えて、セキュリティ境界、移行負荷、5年から10年の総額で判断します。

自治体の基幹業務を、番号管理だけのSaaSへ置き換えるのは困難です。そのため、標準準拠システムや既存パッケージを中心に、番号管理を連携させる方法が現実的です。

標準業務と制度対応を重視するときのパッケージ

パッケージを選ぶときは、標準業務への適合度と、制度改正にどう追随するかを見ます。

共通機能：住民記録や番号連携の機能が備わっていて、制度対応や導入手順を確認しやすい方式です。
標準機能への適合：業務を標準機能に合わせるほど、開発期間と将来の保守負担を抑えられます。
独自要件：独自帳票や外字、例外処理を残すほど、追加開発や周辺ツールが増えます。

選定時には、対応している標準仕様の版と、データ要件・連携要件の更新方法を確かめます。さらに、制度改正の費用が保守料に含まれるかも尋ねます。

デジタル庁では、共通機能やデータ要件・連携要件の標準仕様が2026年にも更新されています（出典：デジタル庁「共通機能の標準仕様」、2026年）。そこで、契約時点で適合しているかだけでなく、更新にどう追随するかも評価します。

クラウドとスクラッチの境界と独自性の比較

クラウドの責任分界と、スクラッチ開発で得られる独自性を比べます。

クラウドの利点：冗長化や監視、バックアップ、災害対策を使いやすく、複数業務や共同利用にも有効です。
クラウドの確認点：データの所在、管理者権限、ログ閲覧範囲、通信経路、利用料を確認します。
スクラッチの利点：独自の住民サービスや複雑な業務、既存システムにない連携を作れます。
スクラッチの負担：制度改正、標準仕様の改定、脆弱性、担当の交代、保守要員の確保を長期にわたって担います。

クラウドは、境界と責任分界の設計があって初めて安全に使えます。クラウドを使う場合も、三層分離（番号利用事務系・LGWAN接続系・インターネット接続系）が保たれるかを、導入前に確かめる必要があります。独自開発では、住民サービスや職員業務への価値を数値化したうえで、標準機能では代替できない部分に絞り込みます。

ポイント

方式は既存業務との適合度と5年から10年の総額で比べ、標準仕様の更新に追随できるかも、契約時点の適合とあわせて見ます。どの方式を選ぶにしても、番号管理の境界と責任分界が決まっていなければ判断できません。

マイナンバー管理システム開発の進め方

後工程の検証と移行準備までを見通した工程の並びです。

画面やデータベースを作る前に、利用目的、対象業務、既存データ、通信境界、運用責任を固めておきます。

自治体では、現行システムの棚卸しと移行リハーサルが品質を左右します。

工程は、要件定義、設計・開発、テスト・移行・運用準備の3段階で進めます。

1. 業務・法令・データの要件定義

要件定義では、番号を扱う業務とデータ、委託の範囲、移行で確かめる事項を整理します。

業務・法令：利用目的や担当者、保存期間、廃棄条件を一覧にします。第三者提供や委託・再委託も、同じ表に載せます。
対象業務：自治体では、住民記録、税、福祉、カード交付の業務ごとに、番号を使う場面と使わない場面を分けます。
企業業務：入社から扶養変更、年末調整、退職、支払調書までの流れで整理します。
データ・運用：項目やコード、外字、履歴を洗い出します。さらに、連携頻度、帳票、権限、ログ、障害時の手作業もまとめます。
移行・提案：番号照合と二重の確認を定め、データの不備を見つけます。RFPでは、機能要件と非機能要件を分けて書きます。

移行前に、重複や欠損、表記の揺れを見つける計画を作ります。こうした移行の前提をRFPに書いておけば、提案者が同じ条件で比べられます。

2. 三層分離・連携・権限の設計と開発

番号を扱う領域、通信、画面、連携、ログ・復旧を設計し、現場担当者に確認してもらいます。

通信境界：番号領域と外部との接続を整理し、三層分離で許可する通信を決めます。
画面・連携：マスキングや再認証、出力制御、承認を設けます。あわせて、項目や形式、送受信時刻、再送、エラー通知を決めます。
ログ・復旧：改ざんの防止、暗号鍵の保管、バックアップの世代、復旧目標を確定します。
レビュー・検証：現場、窓口、情報政策、監査の担当者が加わり、外部との連携を早期に確かめます。

システム担当だけでは、例外処理や繁忙期の運用が見落とされがちです。そこで、カードリーダー、認証、帳票、連携バッチを早くから検証し、手戻りを抑えます。

3. テスト・移行・教育・監査の実施

本稼働の前に、システムの動作とデータ移行を確かめ、教育と運用の準備を整えます。

機能、権限、誤入力、連携をテストします。負荷、復旧、脆弱性、ログも検証します。
抽出、変換、クレンジングを行ったうえで、件数照合とサンプル照合を経て承認し、必要なら切り戻します。
移行リハーサルを複数回行い、職員教育の後に本稼働します。

権限のない職員による検索や出力、大量照会の検知を確かめます。また、通信が途切れた後に二重登録や欠落が起きないかも試します。

外字や住所表記、過去履歴、廃止データを後回しにすると、稼働後の窓口業務に影響が出ます。そのため、マニュアルや問い合わせ窓口、制度改正時の更新手順も用意しておきます。

▶ 詳細はこちら：マイナンバー管理システム開発の進め方

マイナンバー管理システムの費用相場と内訳

自治体向けの機能単体について、全国平均の価格統計は確認できません。下に示すのは、類似案件から整理した企画・見積前の推定レンジです。

費用は、人口や対象業務数、既存ベンダーの有無によって変わります。加えて、データ品質、標準化の状況、ネットワーク、セキュリティ要件も影響します。入札価格や正式相場とは分けて考えます。

方式別の初期費用と期間の目安

費用と期間は、企業向けサービスと自治体向けの方式・規模で異なります。

企業向けクラウド：収集・保管のみなら、初期0円から30万円程度、月額1,000円台から数万円程度の公開例があります。
小規模事業者：数日から1か月程度で導入できる場合があります。
自治体パッケージ：既存パッケージの導入・設定だけなら3,000万円から1億円程度で、期間は6か月から12か月程度を見込みます。
連携改修：住民記録・税・福祉との連携改修は8,000万円から3億円程度で、期間は12か月から24か月程度が目安です。
全体更改：独自要件の大規模更改やスクラッチ開発は、企画段階で3億円から10億円超です。期間は18か月から36か月程度を見込みます。個別見積が必要です。

企業向けクラウドの数字は、サービス提供元の公開料金ページを出典としています（2026年8月確認）。

小規模事業者でも、給与・会計連携や複雑なワークフロー、既存データの移行を含めると、別途費用がかかります。

5年TCOによる見積の分解

初期費用に加え、運用と制度対応を含めた総額で見積もりを比べます。

初期費用：要件定義や設計・開発、ライセンス、データ移行、連携API・中間サーバーまでを含めます。
環境・導入：端末やカードリーダー、ネットワーク、セキュリティ評価、教育が対象になります。
運用費：保守やクラウド利用料、制度改正、障害対応を算入します。
長期比較：現行の維持、パッケージ、クラウド、独自開発を、5年または10年のTCOで比べます。

デジタル庁は、標準化対象事務の運用経費について、削減を目指す方針を示しています。

標準準拠システムへの移行完了後は、2018年度比で少なくとも3割の削減を目指します（出典：デジタル庁「地方公共団体の基幹業務システムの統一・標準化」、2026年）。

この方針は、個別案件の値下げを保証するものではありません。そのため、職員の作業や制度改正への対応も、比較に含めて考えます。

初期費用が低くても、移行リハーサルや脆弱性診断、ログ監視、休日対応、データ返却が別料金だと、稼働後に予算が膨らみます。

▶ 詳細はこちら：マイナンバー管理システム開発の見積相場・費用

ポイント

費用は初期費用だけでなく、運用費と制度対応を含めた5年TCOで比べます。初期費用が低くても、別料金の項目が多い見積は稼働後に予算が膨らみやすいため、注意が必要です。

法令・セキュリティ要件の確認事項

運用ルールと技術・業務の検証が保護を支えます。

特定個人情報は、通常の個人情報と同じ感覚では扱えません。利用目的や取得、保管、委託を、業務規程とシステムに反映させます。アクセスや提供、廃棄、漏えい時の対応も含めて、業務規程とシステムの両方で決めておきます。

こうした決まりを運用担当者が説明できる状態にしておく必要があります。システムの安全性に加えて、誤操作や委託先の管理を含む組織的な安全管理措置も求められます。

利用範囲・委託・漏えい時対応の文書化

利用事務と委託先の管理条件を定め、監査や制度改正に備えます。

利用範囲：業務ごとに担当者、目的、照会・出力条件、保存期間、廃棄方法を定めます。
委託管理：安全管理と再委託、アクセス権限を定めます。さらに、監査権や事故連絡の期限、返却・消去も決めておきます。
自治体の監査：個人情報保護評価や内部監査資料と、システムログを突合できるようにします。
制度改正：2025年6月のガイドライン改正を踏まえ、影響分析、テスト、教育、規程改定の責任者を決めます。

個人情報保護委員会の特定個人情報ガイドラインは、2025年6月に一部改正されました（出典：個人情報保護委員会「特定個人情報の適正な取扱いに関するガイドライン」、2025年6月改正）。

技術と業務の両面で行う受入テスト

受入テストでは、技術面の安全性と実際の業務処理の両方を確かめます。

技術確認：通信遮断や認証の失敗、権限の逸脱を試します。暗号化、復元、ログ改ざんの検知も試します。
脅威・災害確認：脆弱性、マルウェア、災害時の切り替えを試します。
業務確認：異動や氏名変更、出生・死亡を検証データで確認します。扶養変更や退職、再雇用、番号の訂正・廃棄も確かめます。
復旧準備：復旧時間、許容データ損失、代替手順、連絡網、再開判断者を定めます。

正しい担当者が正しい範囲だけ操作でき、異常があれば発見、停止、報告、復旧までできることを、受入の条件にします。

検証には実データに近いデータを使い、その結果を年1回以上の訓練や監査につなげます。

ポイント

特定個人情報の扱いは、業務規程とシステムの両方で決めておくことが前提です。委託先の管理や漏えい時の対応まで文書になっているかを、受入の判断材料にします。

開発会社・サービスの選び方

知名度や初期見積の安さに頼らず、まず自治体向けか企業向けかを切り分けます。

標準化、既存連携、特定個人情報の管理体制、導入後の制度改正と障害対応を、同じ評価表で比べます。

類似実績の業務・規模・連携方式までの確認

自治体と企業では、確認すべき実績やサービスの条件が異なります。そのため、対象業務に合わせて照合します。

自治体実績：人口規模、対象業務、住民記録連携、カード交付・窓口業務の有無を確認します。
移行・保守：標準準拠版への移行経験、移行件数、稼働後の保守体制を確認します。
企業向けサービス：管理人数の上限や本人確認、給与・会計との連携を見ます。さらに、退職者データ、管理者の分離、出力、サポート時間も確かめます。
契約終了：無料トライアルの有無よりも、データを安全に返却・消去できるかを確認します。

「自治体の導入実績がある」という説明は、判断材料の一部にとどまります。可能であれば、調達資料や運用資料と提案内容を照合します。

提案時に尋ねる5年TCO・体制・責任分界

提案内容を契約や見積と照らし合わせ、候補を同じ基準で評価します。

質問事項：標準仕様や制度改正、移行責任、障害時SLA、再委託、5年TCOについて尋ねます。
回答の記録：提案書、見積明細、体制表、契約書案に残します。
評価軸：機能適合、セキュリティ、移行、運用に重みを置きます。保守、プロジェクト管理、価格にも重みを付けます。
提案者の確認：不明点を尋ね、標準機能と追加開発の範囲を示せるかを見極めます。

外字・コード変換や保守要員、脆弱性、監査についても尋ねておきます。価格だけで決めると、移行や制度改正への対応が別料金になりがちです。

▶ 詳細はこちら：マイナンバー管理システム開発でおすすめの開発会社6選と選び方

発注・外注・委託を進める方法

要件が固まらないまま開発会社に丸投げしないことが欠かせません。まず、RFIで現状や選択肢を把握し、RFPで比較条件を明記します。

機能と非機能、移行、セキュリティを示します。保守、成果物、検収も示し、複数の提案を同じ条件で比べます。

RFIでの情報収集とRFPでの比較条件の統一

RFIで実現方法を把握して要件を整理し、RFPで各社の回答条件をそろえます。

RFIの基礎情報：業務フロー、既存システム、対象業務を示します。
実現方法の確認：パッケージ、クラウド、連携改修、段階導入の可能性を尋ね、回答をもとに標準機能と独自要件を整理します。
RFPの記載：必須・加点・対象外を分け、画面一覧と連携一覧、移行、三層分離を書きます。
見積の転記：再委託やデータ返却、費目、作業単価、前提条件を書き込み、見積を比較表に転記します。

RFIでは、データ量やネットワーク制約、課題も示します。RFPには、認証、ログ、バックアップ、監査、教育、SLAも盛り込みます。見積は、初期費用と運用費、追加費用に分けて比較し、制度改正への対応も同じ表で揃えて比べます。

契約・検収・運用分担の事前決定

稼働後の責任分担を明確にするため、契約条件や受入基準、発注側の役割を具体的に決めます。

契約条件：成果物、検収、遅延、仕様変更を定めます。瑕疵対応と保守、制度改正に加え、脆弱性、障害報告、再委託も定めます。
データ・要件：秘密保持や監査、返却・消去、要件定義から次の契約への引き継ぎを決めます。未確定の要件に対する追加費用も決めます。
検収：移行件数、権限、ログ、復旧訓練を対象にします。マニュアルや教育、監査資料も検収の対象に含めます。
発注側の体制：意思決定、業務、セキュリティ、現場受入の担当者を置きます。

質問への回答やデータ確認が滞らない体制が必要です。

▶ 詳細はこちら：マイナンバー管理システム開発の発注・外注・委託方法

ポイント

発注では、RFIで現状を把握し、RFPで比較条件をそろえてから提案を比べます。契約と検収、発注側の体制を先に決めておけば、稼働後の責任分担もはっきりします。

2026年時点の最新動向と将来の備え

2026年は、自治体基幹業務の標準化、ガバメントクラウド、標準化されたデータ連携が並行して進んでいます。加えて、電子証明書やスマートフォンによる本人確認の整備も進んでいます。

仕様や認証方式の更新に対応できる構成にしておくと、長期の費用とリスクを抑えられます。

標準仕様とガバメントクラウドへの適合の確認

標準仕様の更新に追随しつつ、クラウド移行後の責任分担と業務継続を確認します。

標準仕様：自治体基幹業務は、標準準拠システムへ移行する方向にあります。
適合確認：仕様書の版や適合の確認、更新時の影響分析とテストの責任範囲を、開発会社に尋ねます。
クラウド運用：アプリやデータ、ネットワークの責任分界を確認します。認証や監視、バックアップの範囲も、同じ表で明らかにします。

データ要件・連携要件の標準仕様は、2026年4月にも更新されました（出典：デジタル庁「データ要件・連携要件の標準仕様」、2026年）。

標準化に合わせた業務の見直し、既存データの移行、障害時の窓口対応の継続まで、設計に含めます。また、移行後の経費と職員の負担も評価します。

変更に強いデータモデルと運用体制づくり

制度や認証方式が変わっても影響を抑え、担当者が替わったあとも運用できる構成を整えます。

構成：業務データと連携アダプターを分離し、コード変換、認証、通知、ログを共通部品にします。
番号の利用：番号を直接参照する画面は増やさず、必要な業務だけが安全なサービスを通して使います。
年間運用：制度情報を集め、影響を分析したうえで、リリース、教育、監査、障害訓練を計画します。
引継ぎ：業務フロー、権限表、連携仕様、復旧手順を、契約・SLAや問い合わせ履歴とあわせて台帳にまとめます。

この構成にすると、仕様変更のときに影響範囲を絞り込めます。また、開発時の担当者にしか分からない状態を避けることが、現実的な将来対策になります。

ポイント

標準仕様やガバメントクラウドの動きは、将来の費用とリスクに直結します。仕様や認証方式が更新されても、影響を抑えて対応できる構成かどうかで評価します。

マイナンバー管理システムに関するよくある質問

自治体と企業では、対象業務もデータも異なります。切り分けておくと、必要な機能や相談先を判断しやすくなります。

企業向けクラウドサービスで足りる範囲

番号を収集・保管して給与や法定調書へ出力するだけであれば、公開クラウドで足りる場合もあります。

本人確認や複数会社の管理、給与・会計連携、独自の承認が必要なら、標準機能と追加開発を確認します。保存・廃棄や監査ログも同じように求められるかを見ます。

自治体の住民情報システムと番号管理の分離可否

分離できるかどうかは、利用事務、既存システムの責任分界、標準仕様、連携方式によって異なります。

番号だけを切り出すと、住民異動や宛名管理との整合性を別途保つ必要が出てきます。

共通基盤に残す機能と周辺へ切り出す機能を業務フローで整理し、連携検証後に判断します。

費用を抑えるための見直し先

まず、対象業務や独自要件、移行データ、連携先、保守範囲を明確にします。そのうえで、標準機能と追加開発の範囲を分けます。

制度改正や監査、バックアップ、障害対応、教育、クラウド料を含めた5年TCOで比べます。また、使われない機能は作らないことも、有効な方法です。

外注先で確認する項目

まず、類似実績、標準仕様、移行経験を確かめます。そのうえで、セキュリティ、再委託、障害連絡・復旧、制度改正、データ返却を見ます。

体制表や見積の前提、検収条件、保守契約案に記載があるかを確かめ、複数の候補を同じ評価表で比べます。

まとめ

この記事の要点

マイナンバー管理システムは、番号を業務のなかで安全に扱うための仕組みです。自治体では、住民記録や宛名管理、番号連携を、番号を介してつなぎます。カード・電子証明書や税・福祉などの業務も、同じ仕組みで扱います。

企業では、収集や本人確認、給与・会計連携、保存、廃棄を安全に運用します。まず対象を自治体住民系と企業人事労務系に分けてから、番号、住民票コード、宛名番号、カード情報の役割を整理します。

導入前の準備

導入前に要件と委託条件を整え、各方式と提案を同じ観点で比べます。

要件：業務とデータを洗い出し、利用目的や権限、ログを要件にします。三層分離、連携、移行、復旧も要件に含めます。
方式・提案：標準化や制度改正、5年TCO、保守、データ返却の観点で比べ、RFIと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を創業。