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

Google Bigtableのシステムを発注・外注するなら、Bigtableを採用する妥当性と、row key・QPS・レイテンシ・保持期間などの非機能要件を先に数値化することが成功の条件です。

本記事では、Google Bigtableのシステム開発を外部へ依頼する際の発注形態、RFPと要件整理、契約形態、費用相場、委託先の選び方、見積もり比較のポイントを、発注者側の実務に沿って解説します。既存のMySQL・HBase・Cassandraなどから移行する場合や、Pub/Sub・Dataflow・BigQueryと連携する場合にも使える進め方です。

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

Google Bigtableのシステムを発注する前に知るべき全体像

Google Bigtableは、Google Cloudが提供するフルマネージドのワイドカラム型NoSQLデータベースです。大量のキー・バリュー型データを低レイテンシで読み書きする用途に向きますが、一般的な業務システムのRDBをそのまま置き換える製品ではありません。発注前に適性を見極めないと、開発費だけでなく運用費や再設計費も膨らみます。

向いているのは、時系列データ、IoTセンサー、広告イベント、監視ログ、ユーザープロファイル、レコメンド用特徴量、金融取引履歴などです。単純な主キー検索、キー範囲のスキャン、継続的な追記と参照を大量に処理する場合は、アクセスパターンを事前に設計することで性能を出しやすくなります。Google Cloud公式ドキュメントでも、テーブルはrow keyでソートされたキー・バリューの集合として説明され、関連する行を近くに置く設計と、書き込みを分散させる設計の両立が重視されています（出典: Google Cloud「Bigtable overview」、2026年確認）。

一方で、複雑なJOIN、厳密なリレーショナル制約、自由度の高い集計、行・列・セル単位の細かな権限制御が中心なら、Cloud SQL、Spanner、BigQuery、Firestoreなども比較対象にします。発注先へ「Bigtableで作る前提」の相談をする場合でも、代替サービスを含めた適性診断を依頼すると、過剰設計や将来の作り直しを避けやすくなります。

Google Bigtableのシステム開発では、データベースの作成だけを頼んでも業務は動きません。アプリケーションやAPI、認証、Pub/Subによるイベント取り込み、Dataflowによる整形、BigQueryへの分析連携、監視、バックアップ、障害時の切り戻しまでが一つのサービスとして関係します。したがって、発注範囲は「Bigtable構築」ではなく、「どの業務データを、どの経路で、どの応答時間で提供するか」という単位で定義することが大切です。

Google Bigtableのシステム発注形態はどれを選ぶべきですか？

発注形態は、最初から全工程を一括で依頼する方法だけではありません。Bigtableの採用可否やrow key設計に不確実性がある場合は、PoCやアーキテクチャ設計を先行し、その結果をもとに本開発へ進む段階発注が適しています。既存環境や社内エンジニアの有無によって、請負、準委任、ラボ型、内製支援を組み合わせます。

Bigtableを初めて扱う場合や、既存RDBからの移行可否が不明な場合は、2〜6週間程度の技術検証を先に依頼します。検証では、候補となるrow keyを複数作成し、平常時とピーク時の読み書き、p95・p99レイテンシ、データ増加、TTL、バックアップ復元を測定します。Google Cloudには1ノード・最大500GBの無料トライアルインスタンスがあり、10日間、課金アカウントを有効にすれば90日間まで検証期間を延長できます。ただし、無料トライアルは本番用SLAや複数クラスタを前提にできないため、結果をそのまま本番性能の保証と扱わないことが必要です（出典: Google Cloud「Free trial instances overview」、2026年確認）。

PoCの納品物は、動くサンプルだけでは不十分です。row keyとスキーマの比較結果、負荷試験の条件、ボトルネック、推奨ノード数、代替サービスとの判断、継続する場合の概算費用、失敗した場合の撤退条件まで文書化してもらいます。

業務要件、データ量、接続先、受入条件、リリース時期が固まっている場合は、要件定義から設計・開発・テストまでを一括請負で発注する方法があります。成果物と検収条件を明確にしやすく、社内の管理負担を抑えやすいことが利点です。ただし、row keyや整合性要件が未確定のまま一括契約すると、途中の仕様変更が追加費用や納期延長になりやすくなります。

一括請負では、Bigtableのインスタンスを作ることだけでなく、APIの応答時間、ピークQPS、エラー率、移行後の件数一致、バックアップ復元、監視アラートの動作を受入条件に含めます。技術的な設計判断を受託側へ任せる場合でも、業務上の優先順位と許容範囲は発注者が決める必要があります。

自社にアプリ担当者がいて、外部にはBigtable設計や移行、性能検証などの専門性を求める場合は、準委任や内製支援が選択肢になります。作業時間や役割を定めて協働するため、仕様が変化するプロジェクトに対応しやすく、設計の考え方を社内へ移転しやすい方法です。反面、発注者側にも意思決定、レビュー、優先順位付け、受入確認の担当者が必要です。

運用開始後も、ノード調整、コスト監視、障害対応、スキーマ変更を社内で扱いたいなら、設計書やRunbookを一緒に作る契約にします。単に人員を確保するのではなく、3か月後、6か月後に自社が何をできる状態を目指すのかを発注条件へ入れることが重要です。

Google Bigtableのシステム発注・外注の進め方

発注を急ぐほど、最初の相談資料が重要になります。開発会社へ相談する前に、業務上の目的、既存データ、利用者、ピーク時の負荷、セキュリティ、移行制約を整理し、提案の前提を揃えます。次の流れで進めると、技術の説明だけで終わらず、複数社の提案を同じ条件で比較できます。

最初に「Bigtableを使うこと」ではなく、何を改善するシステムなのかを決めます。例えば、センサー情報を受信して異常を検知する、顧客行動を即時参照してレコメンドを返す、在庫の変化を複数拠点へ配信する、といった業務成果です。業務目的が明確なら、Bigtableに保存するオンライン参照データと、BigQueryなどで分析するデータを分けられます。

成果指標には、応答時間、処理件数、欠損率、切替後の業務停止時間、運用担当者の作業時間などを設定します。例えば「速いシステム」ではなく、「ピーク時でもp99レイテンシを何ミリ秒以内にする」「1分あたり何件のイベントを取り込む」と表現すると、提案と見積もりの前提が揃います。

相談先は、Google Cloudの販売やアカウント支援だけでなく、NoSQLのデータモデリング、API開発、Dataflowなどのパイプライン、監視、移行まで対応できる会社を選びます。Google Cloud公式のパートナー掲載は候補を探す入口になりますが、掲載されていることだけでBigtableの実績や日本語での運用体制が保証されるわけではありません。

相談時には、既存システムの構成図、データ項目、1日・1時間・ピーク時の件数、現行データベース、連携先、保存期間、想定利用者、希望時期、予算の上限感を共有します。個人情報を含む場合は、実データをそのまま渡さず、匿名化またはサンプルデータで検討を始めます。

提案を受けたら、いきなり本契約を結ばず、必要に応じてPoCを挟みます。PoCでrow key候補や読み書きの比率を検証し、要件定義でデータモデル、API、認証、保持期限、バックアップ、RTO・RPO、監視、移行、運用分担を確定します。その後に詳細設計・開発・テスト・リリースへ進むことで、曖昧な技術リスクを本番契約へ持ち込みにくくなります。

既存環境から移行する場合は、移行マスタ、項目変換ルール、欠損データの扱い、二重書きの期間、差分同期の方法、切替判定、切り戻し手順を発注者と委託先の共同課題にします。移行元データの正しさや業務上の優先順位まで委託先に丸投げすると、後から検証できないためです。

受入テストは、画面が表示されることだけで終わらせません。想定QPS、ピーク負荷、障害時の再試行、重複イベント、データ欠損、TTLによる削除、バックアップからの復元、権限エラー、監視通知、リージョン障害時の切り替えを確認します。負荷試験のデータ量と実施条件を記録し、結果を受入資料として残します。

納品物には、要件定義書、row key・Column Family設計、インフラ構成、IaC、ソースコード、テスト結果、運用Runbook、監視ダッシュボード、障害時の連絡先、復旧手順、データ取り出し手順を含めます。引き継ぎ後に自社担当者が一人で復元手順を実施できるか、演習で確認してから本番運用へ移行します。

RFP・要件整理でGoogle Bigtableのシステム発注を具体化する方法

RFPは、会社に提案を競わせるためだけの資料ではありません。発注者がシステムの目的と制約を整理し、委託先との認識差を早期に見つけるための共通言語です。Bigtableでは、業務要件だけを書いても見積もりが揃わないため、負荷、整合性、データ構造、セキュリティ、運用、移行を数値と条件で示します。

機能要件には、登録、更新、単一行取得、範囲検索、イベント取り込み、履歴参照、削除、再計算、分析連携などを記載します。それぞれについて、入力元、処理内容、出力先、失敗時の再実行、重複を許容するか、業務上の正となるデータを定義します。Bigtableのセルはタイムスタンプ付きで複数バージョンを持てるため、履歴を保持するか、ガベージコレクションで古いバージョンを削除するかも要件に含めます。

Pub/SubからDataflowを経由してBigtableへ書き込む場合は、イベントの順序性、再送、遅延、重複、スキーマ変更を決めます。BigQueryへ分析データを送る場合は、リアルタイム参照用のデータと、集計・JOIN用のデータを同一テーブルに詰め込まない方針を明記します。

非機能要件は、提案金額と構成を大きく左右します。平常時とピーク時の読み取り・書き込みQPS、1行の最大サイズ、1日あたりのデータ増加量、保持期間、p95・p99レイテンシ、同時利用者数、月間稼働時間、RTO、RPO、国内リージョンの要否を決めます。「大量」「高速」「高可用性」といった表現だけでは会社ごとの解釈が変わります。

例えば、注文・在庫・課金のように整合性が重要なデータでは、単一クラスタの強整合性を使うのか、複数クラスタで可用性を高めるのかを決めます。Google Cloud公式ドキュメントでは、単一クラスタは強整合性、複数クラスタは既定で結果整合性と説明されています。フェイルオーバー時には未複製データが古く見える可能性もあるため、業務で許容できるかをRFPに書きます（出典: Google Cloud「Bigtable overview」「Replication overview」、2026年確認）。

セキュリティ面では、IAMの最小権限、サービスアカウント、CMEK、VPC Service Controls、監査ログ、秘密情報管理、バックアップ、削除期限、ログの保存期間を確認します。Bigtableはプロジェクト、インスタンス、テーブル、Authorized Viewなどで制御できますが、行・列・セル単位のアクセス制御には対応しません。顧客ごとの論理分離が必要な場合は、テーブル設計やAPI側の認可で補えるかを設計段階で検証します。

移行については、データ抽出、変換、初回バックフィル、差分同期、二重書き、整合性検証、切替、切り戻しを工程に分けます。運用については、誰がノード数を変更するか、誰がアラートを受けるか、障害時の一次対応を何分以内に行うか、Google Cloudサポートへの連絡を誰が担当するかを決めます。責任分界が曖昧なまま契約すると、障害時に発注者と委託先の間で判断が止まります。

Google Bigtableのシステム開発で選ぶ契約形態

契約形態は、費用だけでなく、仕様変更の扱い、成果物の責任、プロジェクトの不確実性、社内の関与度に影響します。Bigtableはデータモデルや性能試験の結果によって設計が変わりやすいため、工程ごとに契約の考え方を変えることも有効です。

請負契約は、委託先が合意した成果物を完成させ、発注者が検収する形に向いています。詳細設計以降の開発や、API・移行ツール・監視設定など、成果物の内容と完成条件を説明できる工程で使いやすくなります。契約書には、納品物、検収期間、瑕疵への対応、仕様変更の手続き、第三者サービスの費用、ソースコードと設計書の権利関係を記載します。

Bigtableでは「ノードを作成した」「テーブルが存在する」だけでは完成とは言えません。負荷試験の条件と結果、データ件数の一致、エラー時の再実行、復元テスト、監視通知などを受入基準にします。性能を保証する場合は、テストデータ量、同時実行数、読み書き比率、測定環境を揃えます。

準委任契約は、委託先が専門知識を使って業務を遂行し、発注者と一緒に成果へ近づける形です。PoC、アーキテクチャ検討、row keyの比較、移行計画、運用改善など、途中で仮説を変える可能性が高い工程に適しています。稼働時間や体制を確認するだけでなく、週次レビューの内容、意思決定者、成果物の最低限の水準を決めます。

準委任では、作業した時間だけが報告され、判断材料となる設計資料が残らないことがあります。月次の報告書に、検証した仮説、試験結果、未解決リスク、次の意思決定、コスト予測を含める契約にすると、発注者が進捗と価値を評価しやすくなります。

Google Bigtableを使うシステムでは、アプリケーションのソースコードだけでなく、TerraformなどのIaC、データモデル、移行スクリプト、監視設定、テストデータ生成ツール、Runbookも将来の運用資産になります。納品物の範囲、利用許諾、第三者ライブラリ、契約終了後のデータ取り出し方法を契約書と別紙で確認します。

個人データを扱う場合は、再委託先の名称・業務範囲・データの取扱場所・アクセス権・事故時の報告・監査方法を契約に含めます。個人情報保護委員会のガイドラインでは、委託先の安全管理措置を事前に確認し、契約に合意した措置と取扱状況を把握する内容を盛り込むことが示されています（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年確認）。

Google Bigtableのシステム発注費用とクラウド料金の相場

費用は、Bigtableの利用料金と、システム開発・移行・保守の費用を分けて考えます。Bigtable単体の日本向けSI費用を横断比較できる公表相場は少ないため、以下は一般的な業務システム相場と、Bigtableに必要なデータ基盤・API・性能検証・移行工程を踏まえた推定レンジです。案件の規模、QPS、行数、保持期間、連携数、可用性によって変わるため、確定金額ではありません（出典: NotebookLMリサーチノート「Google・Bigtableのシステム」、2026年）。

技術検証や小規模PoCは、row key設計、負荷試験、SDK・API、少量移行を含めて100万〜300万円程度、期間は2〜6週間程度が一つの目安です。小規模な業務アプリへの組み込みは、API、認証、単一クラスタ、監視、運用手順まで含めて500万〜1,500万円程度、期間は2〜4か月程度が目安になります。いずれも、既存の認証やアプリを再利用できるかで変わります。

Pub/Sub・Dataflow・BigQuery連携、複数テーブル、権限設計、バックアップ、性能試験を含む中規模本番システムは、1,500万〜5,000万円程度、期間は4〜9か月程度が目安です。HBaseやCassandraからの移行、複数リージョン、二重書き、DR、24時間運用まで含む大規模データ基盤は、5,000万円〜2億円以上、9〜18か月以上になる可能性があります。これらはリサーチノートに基づく推定であり、提案書では作業項目ごとの内訳を確認します。

Google Cloud公式料金表の米国リージョン例では、Enterpriseのノード料金は1ノード・1時間あたり0.65米ドル、Enterprise Plusは0.85米ドルです。同じ公式例で、1クラスタ・1ノードを30日稼働し、SSDストレージ50GiBを使う場合のBigtable月額は476.50米ドルと示されています。1米ドル=160円で単純換算すると約7.6万円ですが、日本円の請求額はリージョン、為替、契約条件、割引で変わるため、参考値として扱います（出典: Google Cloud「Bigtable pricing」、2026年確認）。

複数クラスタにすると、クラスタごとのノードとストレージが増えます。別リージョンへ複製する場合は、複製された書き込み、リージョン間ネットワーク、バックアップ、Data Boost、Dataflow、Pub/Sub、Cloud Loggingなども見積もります。Google Cloud公式料金表の例では、2クラスタを同一リージョンに置いた月額例が31,663.80米ドル、異なるリージョンに置いた例が35,536.44米ドルとされており、冗長化を追加すると構成差がそのまま費用差になり得ます。

見積書では、要件定義、PoC、データモデル設計、アプリ・API、データ連携、移行、テスト、セキュリティ、監視、リリース、運用引き継ぎを分けます。別項目としてGoogle Cloudの利用料、保守・監視、サポート契約、障害対応、追加開発の単価を示してもらいます。初期費用が安くても、ノードを常時稼働させる構成や複数リージョンの複製で月額が高ければ、3年間の総額は逆転します。

発注時は、平常時、繁忙期、データ増加後の3パターンで月額を試算します。ノードのオートスケーリングを使う場合は、最低ノード数、上限、スケール条件、想定外の負荷が発生したときのアラートと停止判断を確認します。費用の上限を決めるなら、請求アラートだけでなく、アプリ側のレート制限や異常時の処理停止まで設計に含めます。

Google Bigtableの委託先選定と見積比較のポイント

委託先は、Google Cloudを扱えるかだけでなく、Bigtableを使ったシステムを業務として運用できるかで選びます。特に確認したいのは、row key設計、ホットスポット対策、性能試験、既存DBからの移行、複数クラスタの整合性、コスト監視、セキュリティ、障害対応です。提案書の見た目や会社規模だけでなく、技術上の判断理由を説明できる担当者がいるかを確認します。

面談では、「Bigtableの実績はありますか」と聞くだけでなく、「このrow keyではどの負荷が偏りますか」「時刻を先頭に置く場合の対策は何ですか」「単一クラスタと複数クラスタで整合性と費用はどう変わりますか」と質問します。回答が一般論だけでなく、アクセスパターン、テーブル設計、負荷試験、フェイルオーバーの条件に結び付いているかを見ます。

Bigtableだけでなく、Pub/Sub、Dataflow、BigQuery、Cloud RunまたはGKE、Cloud Monitoring、Cloud Loggingまで含めた構成を描ける会社は、データ基盤全体を見渡しやすくなります。反対に、Bigtableを導入すること自体を目的にし、Cloud SQLやSpannerなどの代替案を説明しない会社には、設計判断の根拠を追加で求めます。

見積金額を比較するときは、合計額の安さではなく、同じ作業を含んでいるかを確認します。要件定義、データモデリング、API、移行、テスト、セキュリティ、監視、運用教育がどの費目に入っているか、対象外なら誰が担当するかを表にします。特に移行費用、負荷試験費用、障害対応時間、クラウド利用料、ライセンス、休日作業は差が出やすい項目です。

見積もりの前提には、データ量、ピークQPS、読み書き比率、保持期間、クラスタ数、対象リージョン、外部連携数、利用者数、既存コードの再利用、納期を記載します。前提が違う見積もりを単純比較せず、同じ条件で再提出を依頼します。金額が低い会社には、削られている工程、想定外費用が発生する条件、追加要員の単価を確認します。

委託先を決めるときは、開発中の提案力だけでなく、契約終了後に自社や別会社へ引き継げるかを確認します。ソースコード、IaC、データモデル、移行ツール、監視設定、バックアップ、運用手順、アカウント権限を発注者の管理下に置き、特定担当者しか変更できない状態を避けます。

Bigtableの利用をやめる可能性も考え、データを標準的な形式でエクスポートする方法、別サービスへ移すときの変換、APIの抽象化、二重書きの可否を確認します。Google Cloudのサービスを使うこと自体が問題なのではなく、設計理由と移行手順を発注者が理解できないことがリスクです。

実績確認では、導入社数やGoogle Cloudの資格者数だけで判断しません。自社と近いデータ量、読み書き比率、レイテンシ、個人情報の有無、移行元、運用時間、障害対応体制を聞きます。守秘義務で社名や数値を開示できない場合でも、匿名化した構成、担当範囲、検証方法、納品物のサンプルを確認できることがあります。

Google Cloudの公式事例では、TVS Automotive Solutionsが20TBを超える取引履歴やリアルタイム在庫データをCloud Bigtableで分析し、Dataflowや監視サービスと組み合わせています。事例の数字を自社の性能保証と捉えるのではなく、どのデータをBigtableに置き、どの処理を別サービスへ分けるかという構成の参考にします（出典: Google Cloud「TVS Automotive Solutions Case Study」、2026年確認）。

Google Bigtableのシステム発注でよくある質問

Google Bigtableのシステム発注では、サービスの適性、費用、期間、既存データの移行、運用体制に関する質問が多くなります。ここでは、委託先へ相談する前に確認したい疑問へ、発注者の判断に直結する形で回答します。

発注はできますが、データ量や同時アクセス数が小さく、複雑なJOINや細かな権限制御が中心なら、Cloud SQLやFirestoreなどの方が適する場合があります。小規模案件でも将来の負荷増加が明確で、アクセスパターンが単純かつ高スループットが必要なら、まずPoCでBigtableと代替サービスを比較してから本開発を依頼します。

一律の最低金額はありませんが、技術検証だけなら100万〜300万円程度、小規模な業務アプリへの組み込みなら500万〜1,500万円程度が推定レンジです。Bigtableのノード、ストレージ、クラスタ、ネットワークの利用料は別に発生するため、初期開発費だけでなく、3年程度の運用総額で比較します。正式な金額はQPS、データ量、移行、連携、保守時間を提示して見積もります。

移行できますが、データをコピーするだけでは完了しません。RDBのJOINや制約をどの処理へ移すか、HBase・Cassandraのキー構造をBigtableのrow keyへどう変換するか、初回バックフィルと差分同期をどう行うかを設計します。停止時間、二重書き、件数と内容の検証、切替後の監視、切り戻し条件を含めた移行計画を委託先へ作成してもらいます。

外注できますが、クラウドの暗号化機能だけで安全管理が完了するわけではありません。IAM、CMEK、監査ログ、ネットワーク制御、バックアップ、削除期限、委託先と再委託先のアクセス管理、事故時の報告を契約と運用規程で定めます。個人情報保護委員会は、委託先の安全管理措置を事前に確認し、契約後も取扱状況を把握することを求めています。

まとめ：Google Bigtableのシステム発注は要件と費用を分解して進めます

Google Bigtableのシステム開発を発注・外注するときは、まずBigtableが業務に適しているかをCloud SQL、Spanner、Firestore、BigQueryなどと比較します。そのうえで、目的、アクセスパターン、row key、QPS、レイテンシ、整合性、RTO・RPO、保持期間、セキュリティ、移行範囲をRFPへ落とし込みます。曖昧な要件のまま安い見積もりを選ぶより、PoCで不確実性を減らしてから本開発へ進む方が、長期的な総費用を管理しやすくなります。

発注前は、第一にBigtableを選ばない場合も含めた適性、第二にピークQPSとp99レイテンシ、第三にrow key・Column Family・保持期限、第四に初期開発費とクラウド・保守費を分けた総額、第五に移行・運用・再委託の責任分界を確認します。委託先には、これらの前提と検証方法を見積書と提案書へ明記してもらいます。

row key、ピーク負荷、整合性、移行方法のいずれかが決まっていない場合は、先にPoCを発注します。小さな検証費用で設計の前提とクラウド実費を確かめ、成功条件と撤退条件を決めてから本開発を契約すると、後工程の大きな仕様変更を抑えやすくなります。

発注後も、受入テスト、バックアップ復元、障害対応演習、データ取り出し、運用引き継ぎまでを完了条件にします。Google Bigtableの技術力だけでなく、業務成果と運用継続性まで説明できるパートナーを選ぶことで、性能・費用・安全性のバランスが取れたシステムへ近づけます。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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