教務システム開発の完全ガイド - ブログ

学籍を軸に、履修、出欠、成績、帳票などの業務をどうつなぐかが、教務システム開発の中心です。

機能、導入方式、進め方、費用、開発会社の選び方を、学校種別、教育業務、運用規模に合わせて整理すると、業務の情報を学籍のもとにまとめやすくなります。各テーマの詳細は関連記事で確認できます。

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

教務システムの概要

学籍を起点に、校内の記録と帳票がつながります。

教務システムは、児童生徒や学生の基礎情報と、教育・学務の業務データをつなぐ業務システムです。

学籍を原本として登録し、そこから出欠、成績、進路、保健、帳票などへデータを連携します。入力画面を電子にするだけでなく、校内に散らばった情報の持ち方と業務の流れをそろえる点が特徴です。

小中高校と大学・専門学校の呼び方と範囲の違い

対象となるシステムと必要な機能は、学校種別によって変わります。

小中高校：校務支援の中に、成績処理、出欠、学籍、指導要録、保健などの教務機能が組み込まれることが多いです。
大学・専門学校：学務・学生情報システムの対象は、入試、履修、成績、単位認定、卒業判定、証明書発行などです。

たとえば、小学校では学級編成や通知表、中高では評定や進路調査、大学では履修制限や単位互換が中心になります。

小中高校では、さらに保護者への欠席連絡や校内連絡、勤務・施設管理まで連携する場合もあります。

要件定義の段階で、対象の校種と学校数、児童生徒・学生数と教職員数、制度上の帳票をはっきりさせておきます。この前提がそろっていないと、製品や見積もりを比べられません。

校務支援システム・学務システム・LMSの役割の違い

導入前に、各システムの役割と、連携するデータの正本を整理しておきます。

校務支援・学務：公式な学籍、成績、出欠などの記録を担います。
LMS：教材配信、課題提出、テスト、学習履歴などの学習面を支えます。

連携のときに正本を決めておかないと、氏名や学籍番号を複数の場所で修正する手間が残ります。

業務ごとに、原本、確定の時期と担当者、訂正履歴の保存先を決めておきます。学籍を原本に、履修やクラスを年度ごとに展開し、成績や出欠を入力したうえで、必要な範囲を帳票や外部サービスへ連携します。この流れを押さえると、各業務で誰がどこまで責任を持つかが明確になります。

教務システムの主な機能と導入効果

機能の一覧は多く見えても、選定では機能数より、学籍を起点に各業務がつながるかを見ることが大切です。なかでも年度更新、進級、転入・転出、成績確定、帳票出力は、実際の操作で確かめます。

学籍・履修・時間割の一連の流れ

学籍から履修・時間割まで、扱う情報は校種に応じて変わります。

学籍：入学、在籍、学年・クラス、住所、保護者、転入・転出、休学・退学、卒業を含みます。
大学・専門学校の学籍：入試区分、所属、保証人、休学・復学、学籍異動に加え、学位や課程も扱います。
履修・時間割：科目・講座、担当教員、定員、前提科目、教室・施設予約を管理します。

情報が整うと、年度替わりの名簿作成や、複数のExcelへの転記を減らせます。反対に、学籍番号の重複や旧年度データの扱いが曖昧なままだと、情報を一つにまとめられません。

入学前の仮登録、年度途中の異動、氏名変更といった例外も、通常の流れと同じくらい確かめておく必要があります。

出欠・成績・帳票の連携と転記の削減

出欠と成績の記録から帳票の出力までをつなぐと、集計や転記の負担を抑えられます。

出欠：出席、欠席、遅刻、早退、校外活動の記録です。
成績：試験、評定、観点、単位、進級・卒業判定などが対象です。
帳票：通知表、指導要録、調査書、成績証明書を、登録データから出力します。

様式は学校や自治体によって異なります。そのため、標準の帳票と、個別設定や追加開発で対応する部分の境目を、デモと見積もりで確かめます。

導入前に、成績締めの時間、帳票の作成時間、訂正の件数、年度更新の日数、問い合わせの件数を測っておくと、導入後と見比べる基準になります。

下書き、承認、差し戻し、最終確定の履歴を残しておくと、誤入力を見つけ、経緯を説明する材料になります。

進路・保健・連絡情報の権限と目的の分け方

進路希望と面談・指導記録は、閲覧する人も利用の目的も同じとは限りません。ほかにも、次の情報は閲覧する人や利用の目的が分かれることがあります。

奨学金・就学支援：支援の手続きに関わる情報
健康診断：心身の状態に関わる情報
保健室記録：来室や手当ての記録
家庭連絡：保護者と学校のやり取り

そのため、担任、教務、養護など、役割ごとにアクセスできる範囲を設計します。管理職、事務、児童生徒・保護者も、その対象に含まれます。

欠席連絡や通知には、送信前の確認、宛先の制限、送信履歴、訂正の方法を用意しておきます。連携が増えるほど、閲覧、編集、出力、外部送信の権限も複雑になります。だからこそ、機能を追加するたびに、権限表と個人情報の利用目的を見直す必要があります。

ポイント

機能の数より、学籍を起点に各業務がつながるかで比べるのが目安です。年度更新や成績確定は実際に操作して確かめ、保健や進路の情報は閲覧者ごとに権限を分けて考えます。

教務システムの種類と導入方式

方式は、クラウドとパッケージ、オンプレミスとプライベートクラウド、スクラッチ開発に分けて見ると整理しやすくなります。優劣を先に決めず、学校数や既存ネットワーク、帳票の要件に照らして選びます。また、セキュリティ方針、連携、保守人員も含めて判断します。

クラウドとパッケージの標準化と運用負担の比較

方式ごとに、標準化の範囲と学校側が担う運用作業を確かめます。

クラウド：サーバー調達やOS更新を自校で抱えにくく、複数の拠点から利用できます。
パッケージ：共通業務が実装済みで、短期間で始めやすく、制度改定に対応した更新を受ける場合があります。

クラウドでも、回線、認証、端末、障害時の連絡手段は必要です。また、パッケージでも、独自帳票や特殊な進級判定を追加すると費用が増えます。

標準機能に合わせて見直す業務と、学校固有の要件として残す業務を分けることで、費用と使いやすさのバランスが決まります。

オンプレミスとプライベートクラウドの統制と継続費用

統制や専用性を重視する場合は、運用の責任と継続費用も判断材料になります。

オンプレミス：学校や自治体のサーバーに構築し、閉域網や認証基盤に合わせやすい場合があります。
プライベートクラウド：専用性や統制を重視しながら、運用を外部に委ねられます。

オンプレミスでは、サーバーの更新や冗長化、バックアップを自組織が担います。災害対策、脆弱性への対応、引き継ぎも、自組織の役目になります。このため、機器の更新周期と保守人員も含めて判断することになります。

サービスレベルと保管場所、管理者権限を確認します。加えて、バックアップ世代、復旧時間、契約終了時のデータ返却も見ておきます。

移行の途中でクラウドとオンプレミスが併存すると、認証やログの扱いが変わります。そのため、切替が終わるまでの暫定ルールも決めておきます。

スクラッチ開発は独自性が高い業務に限定

独自開発の範囲と、長期の保守体制をあわせて検討します。

適する要件：独自制度、複雑な履修規則、特殊帳票、複数システムのデータモデル。
リスクを抑える案：標準パッケージを基盤に、差別化の部分だけを連携や追加開発で対応します。

要件定義、画面・帳票設計、テストのほか、制度変更への対応と保守人材を長期で確保する必要があります。

採用の際は、5年後も仕様を理解している人がいるかどうかと、制度変更時の改修費用・期間を確認します。

納品範囲は契約に記載します。対象には、ソースコード、設計書、テスト仕様、データ定義、API仕様、運用手順が含まれます。

教務システムの導入・開発の進め方

代表校で確かめてから全体展開へ進む構成です。

導入は、現状把握から要件整理、比較、検証、移行、研修、稼働後の改善までを一続きの計画として立てます。

年度替わりに稼働させる場合は、データ確定、名寄せ、リハーサル、研修の順に、稼働日から逆算して日程を組みます。

人・紙・Excel・旧システムの流れの整理

ヒアリングでは、困っている機能だけでなく、例外や手戻りも掘り下げて聞き、年度業務の流れを一覧にします。

参加者：教務主任、担任、教科担当、養護、事務、情報担当、管理職、教育委員会。
年度の流れ：入学、編成、履修、出欠、成績、帳票、転入、年度更新を時系列で並べます。
入力・転記：誰が何をどのファイルへ入力し、どの帳票へ転記しているかを書き出します。
例外：同名、評定修正、履修取消、復学、出欠訂正、自治体独自帳票などの扱いを聞き取ります。

通常のケースだけでデモやRFPを作ると、稼働後に追加開発が必要になりがちです。

MUSTとWANTに分けた要件とRFP

要件は、初回稼働に欠かせないものと、将来実現したいものに分けます。

MUST：法令、制度、帳票、年度更新、学籍、履修、出欠、成績、判定、権限、ログ、移行、連携。
WANT：高度な分析、予測、AI補助、追加通知などです。初回稼働に必要かどうかを評価します。

RFPには操作シナリオを書きます。たとえば、4月の新入生登録・クラス編成と、年度途中の転入生の出欠・成績登録を取り上げます。さらに、成績確定後の通知表出力や保健情報の閲覧制御も含めます。

発注側は、候補ごとに同じ条件で実演してもらい、操作と結果を比べます。

代表校・代表学年での検証と全体展開

複数校や大規模な学校法人では、代表校・代表学年・代表業務を選び、PoCや先行導入を行います。

検証対象：名寄せ、回線、認証、帳票、年度更新、訂正履歴、問い合わせ窓口、障害時の代替手順。
課題管理：不具合、要件、運用ルール、研修の不足に分けて扱います。

追加開発で解決する課題だけでなく、設定変更や手順書で解決できる課題も切り分けます。

全体展開に進む判定条件は、事前に決めておきます。たとえば、重大障害ゼロ、移行データの照合、教職員研修などです。

移行・研修・稼働後支援の年度計画への組み込み

移行では、旧システムやExcelのデータを、そのまま取り込めるとは限りません。そのため、保存と廃棄の条件も決めておきます。

データ整備：氏名、学籍番号、住所、在籍区分、科目コード、年度、成績区分をそろえ、重複・欠損・不整合を確かめます。
保存方針：保存年数、原本とみなす期間、紙資料の保管・廃棄を、情報管理担当と取り決めます。
リハーサル：少なくとも複数回行い、件数、エラー、照合結果、所要時間を記録します。

年度替わりに作業が集中しないよう、担当者と予備日を確保しておきます。研修も、説明会だけで済ませず、役割別の演習、訂正の練習、窓口の周知、稼働直後の伴走支援まで含めると、現場に定着しやすくなります。

ポイント

年度替わりに稼働するなら、稼働日からデータ確定、名寄せ、リハーサル、研修を逆算して計画するのが目安です。代表校で課題を切り分けてから全体展開へ進むと、手戻りを抑えられます。

教務システムの費用相場とコストの内訳

費用は、学校数や児童生徒・学生数、教職員数などの規模によって大きく変わります。さらに、移行データや帳票、連携の範囲によっても変わります。支援や保守の方式も、費用に関わります。

統一された公的な相場はありません。そのため、公開料金と一般的な業務システムの見積もりを教務の要件に当てはめた、参考のレンジを示します。

最終的な判断では、初期費用だけでなく、5年分の総保有コストで比べます。

▶ 詳細はこちら：教務システム開発の見積相場や費用/コスト/値段について

導入方式ごとの初期費用と期間の目安

費用と期間は、方式や規模によって変わります。次に示すのは参考のレンジで、学校数や要件に基づく推定です。

1校クラウド：標準機能中心なら初期0万〜30万円程度、月額2万〜5万円程度、1〜3か月。
移行等込み：パッケージ・クラウドは初期100万〜800万円程度、3〜6か月。
複数校・自治体：500万〜3,000万円程度、6〜12か月。独自開発などは1,500万〜5,000万円以上、9〜18か月以上となる場合があります。

公開料金の例では、学校向けの校務支援クラウドが1校あたり月額2万2,000円、初期33万円となっています（出典: 教育機関向けサービス公式料金ページ、2026年8月確認）。

金額の目安は、学校数や要件による推定のレンジで、開発規模を確定する数字ではありません。

初期費用以外の移行・連携・保守・研修の計上

見積もりは費目ごとに分けて、作業の範囲と金額の前提を確認します。

開発・検証：要件定義、設定、追加開発、画面・帳票、テスト。
環境・移行：データ移行、連携、認証、端末・ネットワーク対応。
運用：研修、導入支援、保守、サポート、バックアップ、利用料。
移行・帳票費：対象年度、件数、データ整形、照合方法によって変わります。

5年TCOは、初期費用に60か月分の利用料・保守費を加えます。そのうえで、追加開発や端末更新、回線増強も含めます。さらに、再研修、障害対応、データ返却費も加えます。

紙、印刷、郵送、手入力の作業時間も、導入の前後で測ります。公開事例では、出席情報の自動連携により、入力を約2,900時間削減しました（出典: 教育サービス事業者の導入事例、2025年）。

同じ効果が自校で出るとは限りませんが、削減時間を測るKPIの参考になります。

対象範囲と前提条件による見積もりの差

同じ機能名でも、含まれる作業や運用の前提によって、工数と費用は異なります。

成績管理：入力のみか、承認、差し戻し、確定履歴、帳票まで含むか。
連携：CSV手動取込かAPI自動連携か、エラー時に再送できるか。
見積条件：対象校数、利用者数、データ件数、連携回数、帳票数、サポート時間、稼働時間帯。

標準機能に合わせて業務を見直せば、追加費用を抑えられます。なお、安い見積もりが有利とは限りません。現場への説明なく機能を削ると、稼働後にExcelへ戻る可能性があります。

候補ごとに、標準、設定変更、追加開発、運用対応の区分をそろえて、差額の理由を比べます。

ポイント

費用は初期費用だけで比べず、5年分の総保有コストで比べるのが目安です。見積もりは費目ごとに分け、対象範囲と前提条件をそろえてから比較します。

教務システムの開発会社・ベンダーの選び方

知名度や機能数だけでなく、校種、規模、移行経験を評価します。さらに、年度更新の支援、連携、セキュリティ、データ返却も見ます。

提案の力と、日常の問い合わせや制度変更に対応する運用体制は、分けて確認します。

学校種別と規模に近い導入経験の確認

自校に近い校種や規模での経験と、導入後の支援体制を確かめます。

小中高：教育委員会や複数校での利用経験。
大学：履修制限や単位認定の経験。
専門学校：異なるコース・学年の在籍管理の経験。移行件数、帳票、連携、期間、導入後支援も確認します。

稼働後のサポート担当、障害時の連絡先、制度変更の窓口も確認します。導入の担当者と保守の担当者が異なるときは、引き継ぎの責任を決めておきます。

実績の数だけでなく、特殊な要件を標準の仕組みに収められるか、難しい場合に費用と納期を説明できるかを見ます。

通常業務と例外業務を同じシナリオで比べるデモ

候補には同じ条件で実演してもらい、通常業務と例外処理を確かめます。

業務操作：新入生登録、クラス編成、履修登録、出欠訂正、成績差し戻し、進級・卒業判定。
例外・出力：帳票の再出力、転入・転出、保護者通知を、実データに近い件数で試します。
連携：LMS、認証基盤、保護者連絡、学校徴収金、自治体基盤との接続と、その復旧方法。

API・CSVの仕様と文字コード、同期の頻度を確認します。さらに、重複の処理、エラー通知、再実行、どこまでを誰が受け持つかも確かめます。

連携に失敗したデータを、誰がどの画面で復旧するかまで確かめ、稼働後に残る手作業を把握します。

契約・サポート・データ返却の条件

契約の時点で、サービス水準、データ管理、変更手順を明確にしておきます。

サービス水準：稼働率、停止通知、復旧時間、バックアップ世代。
管理体制：脆弱性対応、再委託先、保管場所、監査報告。
変更管理：追加開発の単価、受付、影響分析、費用・納期、承認、テスト、公開。

クラウドでは、契約終了時のデータ形式、返却期間、移行支援、削除証明を確認します。また、利用料の改定や機能削減の条件も、5年TCOに影響します。

仕様書やデータ定義を学校側で保有できるか、担当者が替わっても引き継げるかを確かめます。こうした確認は、長期のベンダーロックインを抑えるうえで役立ちます。

ポイント

知名度や機能数よりも、自校に近い校種と規模の導入経験、契約終了時のデータ返却条件を基準にすると判断しやすくなります。

教務システムのセキュリティと個人情報管理

日常のアクセス管理と障害への備えを組み合わせます。

教務システムは、学籍、成績、健康、指導、家庭連絡などの機微な情報を扱います。

文部科学省の教育情報セキュリティポリシーに関するガイドラインは2025年3月に改訂されました（出典: 文部科学省、2025年）。

改訂では、情報資産の分類、次世代校務DX環境への移行期間、強固なアクセス制御などが整理されています。そのうえで、設置者の規程や個人情報保護法に沿って運用します。

最小権限・認証・ログのセット設計

役割に応じて、権限、認証、記録・点検の方法を組み合わせます。

権限：閲覧、登録、編集、承認、出力、送信を分けて、職務ごとに設定します。
認証・見直し：異動時に権限を更新し、共有アカウントを避けたうえで、多要素や端末による認証などを評価します。
ログ・検証：閲覧、変更前後、出力、削除、権限変更、連携を記録し、保存、確認、通知、調査の手順を決めておきます。

本番データをテスト環境へ複製する場合は、匿名化やマスキングを施します。そうすることで、開発の担当者が不要な個人情報を見なくて済みます。

漏えい・障害・災害時の復旧手順と訓練

個人情報保護委員会は2025年6月、2023年4月から2025年4月までの学校の漏えい等を分析し、注意点と再発防止策を公表しました（出典: 個人情報保護委員会、2025年）。

学校は、漏えいへの対策と、障害時の代替・復旧手順を事前に定めて、訓練しておきます。

事故防止：誤送信、権限、端末、帳票への備えとして、確認画面、出力制御、持ち出しルール、連絡体制を整えます。
臨時運用：電話や紙へ切り替える基準、判断する人、復旧見込みを共有する時期。
復旧訓練：復元後の権限、帳票、連携、履歴を確かめ、年度替わりや成績確定前の障害に備えます。

ポイント

閲覧範囲は職務ごとに分け、認証とログをセットで設計するのが目安です。漏えいや障害に備えて、復旧手順は実際に訓練しておくことが大切です。

導入効果を高めるKPIと失敗しやすいポイント

導入の目的を効率化だけに絞らず、変える対象と期限をKPIとして決めます。そのうえで、入力時間と復旧時間を測ります。年度更新や帳票の業務では、負担の変化を数字で追っておきます。

年度更新・成績締め：かかる日数
帳票：訂正が必要になった件数
問い合わせ：受けた件数
紙・郵送：使われる量
研修後：操作の完了率

数値を取れない場合は、先に対象業務と測定方法を決めておきます。

機能を増やす前に決める業務とデータの責任者

要件整理や移行を後回しにせず、関係者とデータの責任を明確にします。

導入体制：教務、事務、養護、情報、管理職、教育委員会による要件の検討。
データ運用：項目ごとの責任者と確定時期、マスタの更新者、権限の承認者。
AI・分析：目的、対象、保存期間、第三者提供、誤判定の訂正、教員による最終確認を決め、出力だけを評価や指導の根拠にしないルールを設けます。

自動採点や指導候補を使う場合は、説明責任を担保できるかどうかも確認の対象になります。

稼働後の改善会議でのKPIと問い合わせの見直し

年度替わりや学期の節目に、導入効果と運用上の課題を見直します。

効果確認：初年度の問い合わせを、操作、権限、マスタ、移行、帳票、連携、障害に分類します。
改善状況：手順書で解決できたかどうか、教員が教育活動へ時間を戻せたかどうかの確認。
定期点検：KPI、重大障害、変更要求、権限、復元テスト、研修を見直し、制度・帳票変更の影響範囲とテストを洗い出します。

よくある質問（FAQ）

導入の検討では、費用、校種、既存データ、セキュリティ、稼働時期についての質問が集まりやすいです。検討の初期に出やすい疑問を取り上げます。

教務システムの導入費用はいくらかかりますか？

標準機能中心の1校クラウドは、初期0万〜30万円程度、月額2万〜5万円程度が目安です。

移行、帳票、連携、研修を含む複数校の導入は、500万〜3,000万円程度です。独自開発では、1,500万〜5,000万円以上になる場合があります。

学校数やデータ件数によって変わるため、初期費用だけでなく5年TCOで比べます。

教務システムはクラウドとオンプレミスのどちらがよいですか？

標準業務を短期間で始めて、サーバー運用を抑えたい場合は、クラウドが向いています。

閉域網、高度な統制、独自運用を優先する場合は、オンプレミスや専用環境も候補になります。比べる観点は、回線障害、認証、返却、バックアップ、復旧、人員です。

Excelや旧システムのデータは移行できますか？

移行できるかどうかは、旧データの項目、形式、重複、欠損、保存期間、対象年度によって決まります。

氏名・学籍番号の名寄せ、科目コード、年度、旧帳票を確認したうえで、複数回のリハーサルと件数の照合を行います。

契約の前に、移行の範囲、整形の費用、照合の責任、移行後に旧システムを参照する方法を明確にしておきます。

教務システムで最低限確認すべきセキュリティは何ですか？

最小権限と強固な認証、暗号化、操作ログを確認します。さらに、バックアップと復元テスト、脆弱性と委託先の管理、事故連絡体制も確かめます。

成績、健康、指導、家庭情報は、職務ごとに閲覧範囲を定めます。あわせて、文部科学省の最新ガイドラインと設置者規程を照らし合わせます。

システムだけでなく、端末や帳票、誤送信への運用も評価します。

まとめ

導入前の学校種別・業務・データ・費用の整理

教務システムは、学籍を原本にして、出欠、成績、履修をつなぎます。これにより、紙やExcelへの転記、属人化、年度更新の負担を減らせます。同じ流れに乗せられる業務は、ほかにもあります。

時間割：科目・講座、担当教員、教室・施設予約
進路：進路希望や面談・指導記録
保健：健康診断や保健室記録
帳票：通知表、指導要録、調査書、成績証明書
連絡：保護者への欠席連絡や校内連絡

小中高校の校務支援と、大学・専門学校の学務では、必要な機能が異なります。だからこそ、校種、規模、制度、利用者、既存システムを先に定めておくことが大切です。

小さな検証と、稼働後のKPIによる改善

方式は、初期費用だけでなく、5年TCOや移行、帳票の条件で比べます。運用の負担は数字に表れにくいため、比べる条件を広げます。

連携：CSVの手動取込かAPI自動連携か、エラー時に再送できるか
研修：役割別の演習や稼働直後の伴走支援まで含むか
保守：稼働後のサポート担当と障害時の連絡先
データ返却：契約終了時のデータ形式と返却期間

進め方は、現状把握から始めて、MUSTとWANTを分けます。

年度更新や転入、成績訂正をデモで確かめたうえで、代表校での検証を経て全体展開へ進みます。さらに、最小権限、認証、ログ、復旧訓練を整えたうえで、KPIと問い合わせをもとに毎年改善します。

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