日報管理システム開発の開発期間・スケジュール・納期について

日報管理システムとは、営業担当者や現場スタッフが「今日はどの顧客を訪問し、どんな活動を行い、何に時間を使ったのか」という1日の業務内容・行動記録を日次で報告し、上長がそれにコメント・フィードバックを返したり承認したりする、日次コミュニケーションの仕組みです。同じ「営業・現場系のシステム」でも、個別の商談（案件）1件ごとの進捗を受注まで追いかける商談管理システムや、出退勤の打刻から労働時間そのものを集計する勤怠管理システムとは立ち位置が異なります。日報管理システムが扱うのは、あくまで「その日1日、誰が何をしたのか」という業務内容の報告と、それを上長・チームで共有してフィードバックし合うコミュニケーションのプロセスです。具体的には、日報テンプレート・入力フォームの作成、訪問先・活動内容・所要時間の記録、上長からのコメント・フィードバック機能、日報データの集計・分析（担当者別の訪問件数推移など）、そして外出先のスマートフォンからの入力といった機能が中心になります。

導入を検討し始めると、「日報管理システムの構築・導入はどのくらいの期間がかかるのか」「SaaS型ツールの設定・カスタマイズとスクラッチ開発では納期がどう違うのか」「自社独自の日報フォーマットや承認フローを再現しようとすると、どれだけスケジュールが延びるのか」といった疑問に直面する担当者は少なくありません。本記事では、日報管理システム開発の開発期間・スケジュール・納期に焦点を当て、規模別・方式別の期間目安、要件定義から現場定着までの各工程に要する期間配分、SaaS型導入とスクラッチ開発における納期の違い、納期を左右する固有の変数、納期を短縮する具体的な手法、そして導入が遅延・形骸化する典型要因とその対策までを、具体的な数値とともに体系的に解説します。これから日報管理システムの導入を検討している方はもちろん、社内でスケジュールを策定する立場の方にとっても、現実的な計画を立てるための判断軸が身に付く内容です。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

▼全体ガイドの記事
・日報管理システム開発の完全ガイド

日報管理システム開発の開発期間の全体像

日報管理システム開発の開発期間は、「SaaS型の日報・グループウェア／SFAツールを設定・カスタマイズして導入するのか」「自社独自にスクラッチで構築するのか」という選択によって大きく変わります。SaaS型の場合、アカウントを発行して入力フォームの基本設定を行うだけなら、最短で即日から数日で利用を開始できます。ただし、自社の業務に合わせた日報テンプレートの設定や、現場への操作説明会を経て、全社で実際に使いこなせる状態にするまでには1か月から3か月程度を見込むのが一般的です。一方、自社独自の日報項目・承認フロー・基幹システム連携を作り込むオーダーメイド開発や、パッケージを自社サーバーで運用するオンプレミス型、SaaSでは対応できない要件を満たすためのフルスクラッチ開発になると、要件定義・設計・開発・インストールが必要になるため、本格稼働までに半年から1年以上を要するケースも珍しくありません。日報管理システムは、勤怠管理システムのように打刻や労働時間集計の精緻なロジックを扱うわけではなく、「その日の業務内容をいかに手早く報告し、上長がいかにスムーズにフィードバックを返せるか」という運用のしやすさが期間を左右する点が特徴です。

もう一つ重要なのは、日報管理システムの開発期間には「システムを作る期間」と「現場スタッフが毎日欠かさず日報を入力し、上長がコメントを返し続ける習慣として定着する期間」という2つの時間軸が存在する点です。どれだけ短期間でシステムを構築できても、現場が日報を書いてくれなければ、訪問件数推移の集計や活動量の分析、上長からのフィードバックといった日報管理システム本来の価値は発揮されません。日報は「売上に直結しない事務作業」と受け止められやすく、入力の負荷が現場にとってのメリットを上回った瞬間に入力が滞り、データが古くなってマネジメントも機能しなくなるという悪循環に陥りがちです。だからこそ、システムの「リリース日」と「日報が日次コミュニケーションとして本当に回り始める日」にはタイムラグがあると理解し、発注側はこの両方を見据えたスケジュールを組む必要があります。本記事では、この前提を踏まえた現実的な期間の考え方を解説していきます。

期間の見積もりに入る前に、日報管理システムが何を管理するシステムなのかを整理しておきましょう。ここを曖昧にしたまま要件を固めると、「結局グループウェアやSFAと同じものを作ろうとして機能が膨らみ、期間が延びる」という典型的な失敗に陥ります。日報管理システムの核は、現場スタッフが1日の業務内容・行動履歴・訪問先を報告し、それを上長やチームで共有してコメント・承認をやり取りする「日次の報告と蓄積」にあります。全社の情報共有基盤としてスケジュール・掲示板・ファイル管理・ワークフローまで幅広く備えるグループウェアと比べると、日報管理システムは現場の業務行動の報告と蓄積に特化しています。また、案件管理・受注管理・顧客分析など売上向上に特化したSFAでは、日報はあくまで行動管理機能の一部という位置づけですが、日報管理システムはその報告・共有・フィードバックのプロセスそのものを主役に据えます。そして、出退勤時間や休暇・労働時間を客観的に記録する勤怠管理システムが「何時間働いたか」を扱うのに対し、日報管理システムは「その時間内で具体的にどのような業務・活動を行ったのか」という定性的な内容を管理する点で決定的に異なります。この違いを要件定義の最初に関係者間で共有しておくことが、機能の肥大化を防ぎ、期間を予定内に収める第一歩になります。

規模・方式別にもう少し具体的に見ていきましょう。小規模導入は、SaaS型の日報ツールやグループウェアを標準機能のまま、あるいは軽微な入力フォーム設定のみで使い始めるケースで、「まずは日報の作成と上長コメントだけ」といった機能に絞ったスモールスタートであれば、利用開始まで数日から2週間程度、現場への定着まで含めても1〜3か月が目安です。中規模導入は、自社独自の日報テンプレート（訪問先・活動内容・所要時間・気づきといった項目）の設計、多段階の承認フローのカスタマイズ、SFAやカレンダー・チャットツールとの連携を伴うもので、SaaS型のカスタマイズであれば2〜4か月、独自の集計・分析ロジックを組み込むオーダーメイド開発であれば4〜7か月程度を見込みます。大規模導入は、複数拠点・複数部門にまたがる展開や、基幹システム・勤怠・経費精算とのリアルタイム連携、独自の複雑な承認ワークフローを伴うスクラッチ開発が該当し、7〜12か月以上かかることも珍しくありません。日報管理システムは、扱うデータの構造が「1日1件の報告」という比較的シンプルなものである分、画面数の多さよりも「日報項目・承認フローの複雑さ」と「連携先システムの数」が期間を左右する点に注意が必要です。

同じ「中規模導入」でも、実際の期間が2か月で終わるプロジェクトと6か月かかるプロジェクトがあります。この差を生む日報管理システム固有の変数を理解しておくことが、現実的なスケジュール策定の鍵です。第一の変数は、日報テンプレート・入力項目設計の複雑さです。「日付・訪問先・活動内容・所感」といったシンプルな構成であれば短期間で済みますが、部署ごと・職種ごとに異なる報告フォーマットを何種類も用意し、条件によって入力項目が変わるような設計を求めると、要件定義に想定以上の時間がかかります。第二の変数は上長コメント・承認フローの複雑さです。日報を「提出→課長確認→部長承認」といった多段階でルーティングする必要がある場合、そのワークフローをシステム化するには相応の設計・実装工数がかかります。第三の変数は連携先システムの数です。日報管理システムはSFA・グループウェア・カレンダー・チャット・勤怠・経費精算などとつながる「ハブ」として機能することが多く、連携先が増えるほど仕様確認・データ同期テスト・例外処理の工数が膨らみます。第四の変数は、日報データの集計・分析（訪問件数推移や活動量レポート）をどこまで作り込むかで、担当者別・チーム別のクロス集計やグラフ化、活動量と成果の相関分析まで求めると実装工数が増える点に注意が必要です。第五の変数として、モバイルからの外出先入力を専用アプリで実現するのか、スマホブラウザで済ませるのかによっても、実装・検証の工数が変わります。

工程別スケジュールと期間配分

日報管理システム導入の期間を正しく見積もるには、プロジェクト全体をいくつかの工程に分解し、それぞれにどれだけの期間が必要かを把握することが不可欠です。ここでは、中規模導入（約4か月＝16週）を例に、要件定義・日報フォーマットの棚卸し、設計・実装、データ移行・連携・現場定着化の各工程の標準的な期間配分を見ていきます。一般的なシステム開発と異なり、日報管理システムは「現場が実際にどんな報告をしているかのヒアリング」と「日報の運用定着」という工程の比重が大きい点が特徴です。目安としては、要件定義・日報フォーマットの棚卸しが全体の約20%、設計・実装が約40%、データ移行・連携構築が約20%、テスト・現場定着化が約20%です。この比率を頭に入れておくと、開発会社から提示されたスケジュールが妥当かどうかを判断しやすくなります。「現場スタッフへのヒアリングをほとんど行わずに日報項目や入力フォームを固める」見積もりは、後になって「実際の業務報告の流れと違う」という手戻りが発生するリスクが高いと推測できます。

要件定義フェーズは、16週のプロジェクトであれば約3週を割り当てます。この期間で最も重要なのが、自社の日報フォーマットの棚卸しです。具体的には、「現場スタッフは今どんな項目を、どのタイミングで報告しているのか」「訪問先・活動内容・所要時間のうち、どこまでを必須にするのか」「上長はどの段階でコメント・承認を行うのか」「日報データを最終的にどう集計・活用したいのか」を洗い出し、日報テンプレートと入力項目に落とし込みます。日報管理システム導入でよくある失敗は、マネジメント層だけで「部下の行動を漏れなく把握したい」という管理目線で要件を決め、実際に毎日入力する現場スタッフの意見を後回しにしてしまうことです。現場の業務実態を反映しない日報項目は、リリース後に「入力が面倒で意味を感じない」という反発を招き、結局定着しません。要件定義書には、入力必須項目を「訪問先・活動内容・ネクストアクションなど、報告と振り返りに直結する必要最小限の項目」に絞る方針を明記し、後から仕様が変わった場合の変更管理プロセスを契約に組み込んでおくことが、納期遵守の最大の予防策になります。

設計・実装フェーズには全体の約4割、6〜7週程度を割り当てます。SaaS型ツールをベースにする場合、この工程は「日報テンプレート（入力フォーム）のカスタムフィールド設計」「訪問先・活動内容・所要時間を入力するUIの設定」「上長コメント・承認フロー・自動通知の構築」「担当者別・チーム別の訪問件数推移を集計するダッシュボードの設定」「SFAやカレンダー・チャットツールとの連携API実装」が中心になります。ここで日報管理システムに特有なのが、外出先のスマートフォンから素早く入力できるモバイルUIの設計です。営業担当者が直行直帰する場面を想定し、移動中でもストレスなく日報を書けるかどうかが、後の定着率を大きく左右します。ノーコードで柔軟に構築できるkintoneのようなツールを使う場合は、プログラミングを伴わずに自社の業務に合わせた日報フォームを組み立てられるため、実装フェーズを短縮しやすくなります。一方、スクラッチ開発の場合は、データベース設計、入力画面実装、承認ワークフローエンジン、集計エンジン、モバイルアプリをゼロから作るため、通常のWebアプリケーション開発と同様の工数がかかります。いずれの場合も、過度な入力項目の作り込みは実装期間を延ばすだけでなく現場の入力負荷を増大させるため、独自開発が必要な部分を日報テンプレートと承認フローまわりに絞り込む設計方針が、期間短縮の鍵になります。

データ移行・連携構築には約3週、テスト・現場定着化には約3週を割り当てます。データ移行フェーズでは、既存のExcel日報や紙の報告書、旧システムから過去の日報データを取り込み、部署ごとにバラバラだった項目名の統一や記入形式の整理を行います。日報は自由記述が多いため、過去データをそのまま移行するよりも「新システム稼働日以降の日報から蓄積を始める」割り切りが有効なケースも多く、この方針を早期に決めておくことが遅延回避の鍵になります。あわせて、SFA・カレンダー・チャット・勤怠・経費精算といった周辺システムとの連携をこの工程で構築します。日報管理システムはこれらをつなぐハブとして機能するため、連携テストに一定の期間を確保しておく必要があります。テストフェーズでは、日報の作成から上長コメント、承認申請、訪問件数推移レポートの出力までの一連の業務フローが問題なく動くかを検証します。現場定着化フェーズでは、実際に現場スタッフに一定期間使ってもらいながら、日報の入力ルールの浸透度やモバイル入力の使い勝手を確認します。前述のとおり、日報が日次コミュニケーションとして根付くまでには、全社一斉ではなくパイロット部署から段階的に広げる進め方が推奨されており、「システムのリリース」と「現場での定着」を同じ日と考えないことが、現実的なスケジュール策定の重要なポイントです。

導入方式による納期の違い

同じ規模の日報管理システム導入でも、採用する方式によってスケジュールの組み方と「利用開始までの期間」は大きく変わります。日報管理システムで主に検討されるのは、SaaS型の日報・グループウェア／SFAツールをそのまま／軽微カスタマイズで使う方式、ノーコードツールで自社の日報フォーマットに組み立てる方式、そして独自にスクラッチで構築する方式です。それぞれの特徴を理解し、プロジェクトの性質に合った方式を選ぶことが、納期最適化の出発点になります。

最も短納期で立ち上げられるのが、SaaS型の日報・グループウェア／SFAツールをそのまま、あるいは標準機能の設定変更のみで使い始める方式です。サイボウズ Office、desknet’s NEO、Google Workspace、Mazrica Sales、GENIEE SFA/CRM、kintoneといったクラウドサービスは、日報の作成・共有・コメントを標準機能として備えており、専門的なプログラミング知識がなくても運用を開始できます。アカウント発行と入力フォームの基本設定だけなら最短で即日から数日、全社での定着を含めても1〜3か月程度というスピード感が実現できるのは、この方式ならではの強みです。本導入前には、2〜3つの候補ツールの無料トライアルに申し込み、実際の現場スタッフに日報の作成・上長コメントを1〜2週間程度使ってもらって現場テストを行うことが推奨されます。特に日報管理システムでは、外出先のスマホからストレスなく入力できるか、上長のコメントが返しやすいかといった「日々の使い勝手」がトライアル段階で見極めるべき最重要ポイントです。海外製の高機能なツールは魅力的な機能を数多く備えている一方、日本企業特有の複雑な組織構造や独自の承認フローに適合しないケースもあるため、トライアル期間中に自社の業務にフィットするかを見極めることが、後の手戻りを防ぐポイントです。

納期の観点で特に有効なのが、スモールスタートという考え方です。最初から日報作成・上長コメント・多段階承認・訪問件数の集計分析・他システム連携のすべてを一度に導入するのではなく、「まずは日報の作成と上長コメントだけ」といったコア機能に絞って運用を開始し、現場が使いこなせるようになった段階で機能を追加していくアプローチです。日報管理システムでは、この段階的導入を「パイロット導入（1〜2か月・1部署で試験運用し入力フォームの使い勝手の問題を収集）→評価・改善（2〜3か月・ログ分析やヒアリングをもとに必須項目を減らすなど入力ルールを改定）→段階展開（3〜6か月・成功事例をもとに部署を順次拡大）→全社定着（6か月〜・利用率のモニタリングと継続教育）」というPDCAサイクルで回すことが、形骸化を防ぐ定石とされています。フル機能版を全社一斉に導入しようとすると、要件が膨らみ、承認プロセスも重くなり、結果的に稼働開始が数か月単位で遅れるうえ、現場が使いこなせずに日報が入力されなくなるリスクも高まります。これに対しスモールスタートであれば、日報の作成と共有だけを数週間で立ち上げ、その後段階的にコメント・承認・集計分析へ拡張していけるため、ビジネス上の「初回価値提供」までの期間を大幅に短縮でき、早期に現場のフィードバックを得ながら育てていけます。

納期を短縮する具体的な方法

日報管理システム導入の納期短縮は、単にエンジニアを増やせば実現できるものではありません。むしろ日報管理システムの場合は「現場スタッフが毎日日報を入力し、上長がコメントを返し続けてくれるか」という定着面の工夫こそが、実質的な導入完了までの期間を左右します。ここでは、品質と定着率を犠牲にせずに導入期間を短縮するための実践的な手法を紹介します。

第一の手法は、本格導入前に無料トライアルを活用して日報テンプレートを早期に固めることです。複数のツールを実際の現場で1〜2週間ほど試すことで、「自社の日報は実際どの項目で管理するのが現実的か」「訪問先・活動内容・所要時間のうちどこまでを必須にするか」が明確になり、要件定義フェーズの手戻りを大幅に減らせます。日報テンプレートの定義は日報管理システムの背骨にあたる部分であり、ここが揺れると設計・実装のすべてに影響が波及するため、早期確定が最大の期間短縮策と言っても過言ではありません。第二の手法は、入力項目を必要最小限に絞り込むことです。あれもこれもと日報の入力項目を増やすと、実装工数が増えるだけでなく、現場にとって「売上に直結しない事務作業」とみなされ、リリース後に日報が入力されなくなるリスクも高まります。訪問先・活動内容・所要時間・ネクストアクションなど、報告と振り返りに直結する項目に絞り、自由記述はチェックボックスやプルダウンで選択式に置き換えることで、設計・実装の工数を圧縮しながら定着率も同時に高められます。近年はスマホに話しかけるだけでAIが活動内容を要約して日報に自動登録する音声入力機能も登場しており、こうした機能を活用すれば、入力ルールの検討にかける期間もさらに短縮できます。

第三の手法は、標準機能を最大限に活用し、独自開発・カスタマイズを必要最低限にとどめることです。自社の細かな日報運用にシステムを合わせようと過剰にカスタム開発を行うと、実装期間が延びるだけでなく、標準保守の対象外となり、後の保守運用フェーズでも負担が増大します。第四の手法は、kintoneのようにプログラミング知識がなくても直感的に構築できるノーコードツールを選定することです。専門知識を持つエンジニアの調達を待たずに、営業企画部門や情報システム部門の担当者自身が日報フォームや入力項目、集計ビューを組み立てられるため、要件変更への対応スピードが飛躍的に上がります。第五の手法は、連携を段階化することです。日報管理システムはSFA・カレンダー・チャット・勤怠・経費精算をつなぐハブになりますが、これらすべてを初期リリースで一度に連携しようとすると、テスト工数が膨らみ納期が延びます。まずは日報の作成・共有単体で立ち上げ、運用が安定してから優先度の高い連携（たとえばカレンダー連携による訪問予定の自動取り込みや、チャットへの日報通知）から順に追加していくことで、初回リリースまでの期間を圧縮できます。これらの手法を組み合わせることで、日報管理システム導入プロジェクト全体の期間を大きく圧縮しながら、現場に根付くシステムを実現できます。

納期遅延の典型要因と対策

どれだけ綿密に計画しても、日報管理システム導入には固有の遅延リスクが存在します。重要なのは、システム開発が完了した後の「現場への定着」までを納期の一部として捉え、遅延の典型要因を事前に把握して対策を進捗管理の仕組みに組み込んでおくことです。ここでは、日報管理システム導入でよく見られる遅延要因と、それぞれの具体的な対策を解説します。

第一の遅延要因は、部署ごと・職種ごとの細かな報告要望や多段階の承認フローをそのままシステムに再現しようとして、想定以上のカスタム開発が発生することです。特に、海外製の高機能なグループウェアやSFAツールを日本の複雑な組織構造や独自の承認フローに無理に適合させようとすると、柔軟なカスタマイズができなかったり、多額の追加費用と時間がかかったりして、結果的にExcelや紙の日報との併用に逆戻りしてしまうケースがあります。対策としては、要件定義の段階で「どこまでシステムに合わせ、どこから日報の運用ルール側を見直すか」を早期に議論し、過剰なカスタマイズに走らないようスコープを明確にすることが重要です。日本の商習慣に合致した国産ツールを選定するか、ノーコードツールで自社の承認ワークフローを構築するアプローチも、この遅延を避ける有効な手段です。また、訪問件数推移や活動量レポートといった集計・分析機能を最初から作り込みすぎることも遅延要因になりやすいため、まずは標準的な日報の作成・共有・コメントから始め、高度な分析機能はフェーズ2以降に回す判断が有効です。

第二の遅延要因は、システムは完成しているのに現場で日報が入力されず、実質的な稼働開始が先延ばしになることです。原因の多くは、日報の入力項目が多すぎて「売上に直結しない事務作業」と現場に受け止められること、あるいは「部下の行動を監視したい」というマネジメント側の意向が前面に出すぎて、現場の反発を招くことにあります。また、なぜこのツールを導入するのかという目的が現場に共有されていないことや、「誰が・いつ・どのタイミングで・何を入力するのか」という運用ルールが定まっていないことも、定着を妨げ、分析に使えないゴミデータが溜まる大きな要因です。対策としては、要件定義の段階で現場の要望をヒアリングし、日報テンプレートや運用ルールに反映させること、入力項目を報告と振り返りに直結する必要最小限のものに絞ること、そして導入の目的とメリット（日報を書けば上長が的確な助言をくれる、成功事例がチームで共有される、外出先からスマホで数分で報告が終わり帰社が不要になるなど）を現場に丁寧に説明し、当事者意識を持ってもらうことが有効です。さらに、社内で推進役となる担当者を育成し、現場からの質問やトラブルに迅速に対応できる体制を整えることも、定着までの期間を短縮する重要な打ち手です。加えて、上長が日報にコメントを返す運用を仕組みとして定着させること、そして全体工数の10〜15%程度をバッファ（予備）期間として確保しておくことを強く推奨します。

まとめ

本記事では、日報管理システム開発の開発期間・スケジュール・納期について、規模別・方式別の期間目安、工程別の期間配分、導入方式による違い、納期短縮の手法、そして遅延要因と対策までを体系的に解説しました。開発期間の目安はSaaS型のスモールスタートで即日〜数日で利用開始・全社定着まで1〜3か月、中規模のカスタマイズ・オーダーメイドで2〜7か月、大規模なスクラッチ・オンプレミス開発で半年〜1年以上であり、要件定義・日報フォーマットの棚卸し20%、設計・実装40%、データ移行・連携構築20%、テスト・現場定着化20%という工程配分を押さえておくことが、見積もりの妥当性を判断する基準になります。日報管理システムは「システムが完成した日」と「現場スタッフが毎日日報を入力し、上長がコメントを返す日次コミュニケーションとして定着した日」が異なるという特徴を持つため、パイロット導入から段階展開・全社定着へと進めるPDCAサイクルを織り込み、定着までを含めたスケジュールを組むことが不可欠です。なお、日報管理システムはグループウェアやSFAと同じSaaS製品で提供されることが多いものの、全社の情報共有基盤であるグループウェアや売上向上に特化したSFA、労働時間を集計する勤怠管理システムとは異なり、「その日の業務内容を報告し合い、上長がフィードバックする日次コミュニケーション」に焦点を絞って要件を組み立てることが、無駄のないスケジュール設計につながります。納期を守るためには、無料トライアルによる日報テンプレートの早期確定、入力項目の絞り込み、標準機能・ノーコードの活用と連携の段階化、そして現場の声を反映した運用設計と10〜15%のバッファ確保が欠かせません。無理のない納期設定と、導入後に使われ続けるための定着施策を両立させることが、日報管理システムプロジェクト成功の鍵となります。具体的なスケジュールの相談は、複数の開発会社・ベンダーに要件概要を提示して見積もりを取ることから始めることをお勧めします。

▼全体ガイドの記事
・日報管理システム開発の完全ガイド

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

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

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

株式会社riplaの会社HPはこちら

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

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。