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

Shell Scriptのシステム開発を発注するなら、Shellだけを書いてもらうのではなく、データ連携・ジョブ管理・エラー通知・再実行・引き継ぎまで含む運用単位で委託範囲を定義することが重要です。

本記事では、Shell Scriptのシステムを外注・委託するときの発注形態、RFPと要件の整理、請負・準委任などの契約形態、費用相場、委託先の選び方、見積書の比較方法を、発注者の実務に沿って解説します。既存のbash資産を引き継ぎたい場合や、Excel・FTP・夜間バッチを一つの業務フローへつなげたい場合にも使える判断軸をまとめます。

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

Shell Scriptのシステム発注・外注の全体像

Shell Scriptのシステムは、単独のスクリプトを納品して終わるものではありません。LinuxやUnixのシェル、標準コマンド、データベース、API、SFTP、ジョブスケジューラなどを組み合わせ、入力を受け取り、変換・登録し、結果を通知する業務処理全体を指すことが多いです。発注時は「何本のスクリプトを作るか」よりも、「どの業務を、どの時間帯に、どのデータを使って、誰が安全に運用できる状態にするか」を決める必要があります。

発注対象は、単一サーバーで動く定型処理、CSV・DB・APIをつなぐ部門内バッチ、複数部門をまたぐ連携基盤、レガシーシステムの刷新・移行という4段階に分けると整理しやすいです。ファイルを所定のディレクトリへ移動して圧縮する程度なら小規模なShell開発で済みますが、取引データを複数システムへ配信し、失敗時に安全に再実行し、担当者へ通知する場合は、ジョブ設計やデータマッピングまで含むシステム開発になります。

この切り分けをしないまま「Shellで安く作ってください」と依頼すると、あとから監視、権限、例外処理、受入テストが追加されます。結果として、コードの本数は少ないのに設計・試験・運用費が大きくなります。見積依頼書では、スクリプト単体の作成なのか、業務処理を止めずに運用できる仕組みまで含むのかを明記します。

Shellは、ファイル操作、OS上のコマンド実行、ログの抽出、定時バッチ、既存ツールの呼び出し、サーバー設定やデプロイの自動化と相性がよいです。一方で、複雑なデータ構造を扱う処理、画面・細かな権限管理、長時間のトランザクション、大量データの高度な変換、複雑な業務ルールは、Python、Java、SQL、ETL製品、業務パッケージの方が保守しやすい場合があります。

発注者が技術を指定しすぎる必要はありません。「Shellを使うこと」ではなく、「既存Linux環境を活用し、毎朝9時までに正しい在庫データを連携すること」のように業務成果を示します。そのうえで、Shellに残す範囲とAPIやアプリケーションへ切り出す範囲を提案してもらうと、短期の開発費だけでなく、数年後の保守性も比較できます。

要件整理から開発、テスト、移行、保守までを一社へ任せる一括外注は、社内にLinuxや業務連携の知見が少ない場合に向いています。ただし、発注者側で業務の正解を決める責任まで手放せるわけではありません。現場の締め時間、例外処理、マスタの管理者、障害時の判断者は、発注者が明確にする必要があります。

既存Shellの棚卸しだけ、ShellCheck導入だけ、夜間バッチの監視だけを専門会社へ依頼する部分委託も選択肢です。すでに社内にアプリ開発者がいる場合は、外部会社に現行調査と設計レビューを依頼し、実装は内製する方法もあります。対象業務と社内体制を先に整理してから、発注方式を決めます。

発注前に整理する要件とRFPの作り方

RFPは、提案依頼先に同じ前提で提案・見積を出してもらうための資料です。完成した仕様書である必要はありませんが、現状の業務、対象データ、接続先、納期、運用制約を同じ粒度で示すことが大切です。Shell案件では、既存スクリプトの有無や実行環境の違いが見積に直結するため、分かる範囲で具体的に記載します。

最初に、担当者が手作業で行っている順番を時系列に並べます。たとえば「販売システムからCSVを出力する」「SFTPで連携する」「Shellで文字コードと日付形式を変換する」「在庫DBへ登録する」「件数とエラーを担当者へ通知する」という流れです。各工程について、入力元、ファイル名、文字コード、改行コード、項目定義、最大件数、実行時刻、締め時間を整理します。

正常系だけでなく、ファイルが届かない、同じファイルが二度届く、途中でDB接続が切れる、1行だけ不正な値がある、処理中に再実行されるといった例外も洗い出します。現場担当者しか知らない例外をRFPへ出せると、開発後の仕様変更と追加費用を抑えやすくなります。マスタデータの整備や重複データの整理が発注者側の作業になる場合も、役割分担として明記します。

Shellのコード量が少なくても、業務を止めないための非機能要件が大きな工数になります。RFPには、処理を完了すべき時刻、許容できる処理時間、月次・日次の実行頻度、同時実行の可否、障害時の連絡先、ログの保存期間、バックアップ、アクセス権限、個人情報や決済情報の有無を記載します。たとえば「朝8時までに完了」だけでなく、「通常件数とピーク件数」「失敗を何分以内に検知するか」まで決めます。

再実行の要件も重要です。同じ売上ファイルを再処理して二重計上しない冪等性、処理済みファイルの保管場所、途中で止まった場合にどの工程から再開するか、オペレーターが確認する手順を設計対象にします。cronの登録だけを納品条件にすると、失敗に気づけず、担当者がサーバーへログインして手探りで復旧する運用になりやすいです。

RFPには、対象業務と対象外の業務、現行環境、希望する構成、納期、予算の考え方、提案期限、質問期限、評価基準を入れます。成果物はShellファイルだけでなく、基本設計書、処理フロー、入出力項目定義、ジョブ一覧、テスト仕様書・結果、障害時手順、運用マニュアル、ソースコード、設定値一覧、秘密情報を含めない納品用サンプルまで列挙します。

また、サーバーやクラウドのアカウントを誰が用意するか、接続先の申請を誰が行うか、テストデータを誰が準備するか、現場の受入担当者は誰か、リリース承認者は誰かを決めます。発注者が提供するものと委託先が用意するものを分けるだけで、待ち時間や「そこまで含まれていると思っていた」という認識違いを減らせます。

発注形態と契約形態の選び方

Shell Scriptのシステム開発では、発注者が達成したい成果を固定できるか、要件を一緒に詰めながら進める必要があるかによって、契約形態の向き不向きが変わります。契約名だけで判断せず、作業範囲、成果物、検収条件、変更時の扱い、責任分界を契約書や個別発注書に落とし込みます。契約の最終判断は、社内の法務担当者や専門家にも確認します。

請負契約は、合意した成果物を完成させ、発注者が検収する形に向いています。処理フロー、入出力仕様、スクリプト、ジョブ設定、テスト結果などの納品物と、どの条件を満たせば検収するかを具体化できる場合に適しています。要件が曖昧なまま請負で始めると、仕様変更が追加費用になったり、委託先が検収可能な最低限の実装に寄せたりするため、RFPと受入基準を先に整えます。

「エラー通知を実装する」という表現だけでなく、「処理失敗から5分以内に指定チャネルへ通知され、通知文にジョブ名、実行日時、終了コード、ログの参照先が含まれる」と書くと、完成状態を確認しやすくなります。検収後の瑕疵対応、軽微な修正の範囲、環境差異による追加作業もあらかじめ確認します。

準委任契約は、専門家が一定期間、要件整理、現行調査、設計、開発支援、運用改善などの業務を行う形に向いています。現行Shellの読み解きや担当者へのヒアリングをしながら、段階的に仕様を決める案件では使いやすい契約形態です。一方で、準委任だから成果物が不要になるわけではありません。月次の作業報告、設計書、レビュー記録、課題一覧、更新したソースコードなど、何を残すかを合意します。

要件定義を準委任で行い、仕様が固まった後の開発を請負にする二段階の発注もあります。最初から全工程を固定価格にするより、ブラックボックス化した夜間バッチや古いUnix環境の調査に適した進め方です。ただし、段階の切り替え条件と、調査で判明した追加リスクの扱いを曖昧にしないことが重要です。

Shellのソースコードには、接続先、ファイルパス、ユーザー名、処理ルールが含まれることがあります。パスワードやAPIキーをソースへ直書きせず、秘密情報管理サービスや環境変数などの運用を委託先から提案してもらいます。開発環境・検証環境・本番環境のアクセス範囲、ログへの個人情報の出力可否、アカウントの返却・削除時期も決めます。

再委託の可否、障害や情報漏えい時の報告期限、監査への協力、契約終了時のデータ消去、ソースコードとドキュメントの利用権も確認します。個人データを扱う場合は、個人情報保護委員会のガイドラインにある安全管理や委託先監督の考え方を踏まえ、アクセス制御やログ管理を要件化します。税務・会計データを扱う場合も、電子帳簿保存法やインボイス制度に関わる保存要件を業務担当者と確認します。

Shell Scriptのシステム開発にかかる費用相場

Shell Script単体の全国統一価格表はありません。費用はコード量よりも、接続先の数、データ品質、失敗時の復旧、セキュリティ、テスト、運用体制によって変わります。以下は、2026年時点で公開されている業務自動化・業務システム開発の相場情報と、Shell案件の作業範囲を組み合わせた記事用の推定レンジです。特定の会社が提示する確定見積ではないため、発注前の予算検討に使い、最終的には同じRFPで見積を取得します。

単一サーバーの定型処理を1本から数本作り、単体テスト、cron設定、簡易手順書までを含める場合は、20万〜80万円程度が一つの検討レンジです。CSV・DB・APIをつなぐ部門内バッチで、文字コード変換、エラー通知、リトライ、受入テストまで含める場合は、80万〜300万円程度が目安になります。いずれも案件固有の推定であり、実行環境の調査や既存資産の読み解きが多い場合は上振れします。

複数部門・複数システムをつなぐ連携基盤では、データマッピング、ジョブ制御、監視、権限、移行、教育、運用設計まで必要になり、300万〜800万円程度のレンジで検討されることがあります。基幹系の刷新やレガシー移行を含む場合は、現行調査、並行稼働、性能試験、段階移行が加わるため、1,000万円〜数億円規模になる可能性があります。ノートにあるこのレンジはShell専用の公開価格ではなく、業務システムの規模別相場から組み立てた推定です。

公開相場の補強材料として、2026年版の業務システム開発費の相場を扱う公開情報では、業務自動化や小規模なシステム化を数十万円から数百万円の範囲で示す例があります（出典: 株式会社FrameScript「2026年版 業務システム開発費の相場」）。Shell案件にそのまま適用できる統計ではないため、本記事では上記を「業務範囲から算出した予算レンジ」として扱います。

同じ10本のShellでも、ローカルファイルだけを扱うのか、複数のDBや外部APIへ接続するのかで工数は変わります。API認証、証明書、SFTP、個人情報、取引データ、複数OS、24時間運用、監査ログ、障害時の一次対応が入るほど、コードを書く時間より設計・試験・レビュー・運用設計の比率が大きくなります。

データの品質も見積の重要な要素です。実際のサンプルに想定外の文字、空欄、重複、桁あふれ、日付の揺れがあると、単純な区切り文字処理では対応できません。発注者が事前に匿名化したサンプルデータとエラー例を提供すれば、委託先は例外処理を見積に反映できます。サンプルを出せない場合は、その調査費用を別工程として見積に分けます。

年間保守は、一般的な業務システムの目安として初期開発費の10〜20％程度が示されることがあります（出典: NotebookLMリサーチノート内の業務システム全般の費用整理）。Shell案件でも、OS更新、依存コマンドの変更、証明書更新、障害時の再実行、脆弱性対応、ログ容量の監視、担当者からの問い合わせを含むかで保守費は変わります。休日や夜間の障害対応を求める場合は、通常時間の保守と分けて条件を確認します。

クラウド上でジョブを実行する場合は、実行基盤、ログ保存、通知、ネットワーク、暗号鍵、監視の料金も考えます。AWS Systems Manager Automationについては、2025年8月14日以降の新規利用者にはAutomationの無料利用枠がなく、既存利用者も2025年12月31日で無料枠が終了すると公式ドキュメントに記載されています（出典: AWS Systems Manager Automation公式ドキュメント）。利用回数やログ保存期間を含めた月額見積を取り、開発費と運用費を分けて比較します。

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

委託先は「Shellが書ける会社」という条件だけで選びません。Linux・Unixの運用、DB・API連携、クラウド、ジョブ管理、監視、セキュリティ、既存資産の読解、テスト自動化、障害対応、ドキュメント納品まで確認します。Shell専業の市場は大きくないため、Shell・Unix資産を扱えるSI会社や、クラウド運用に強い会社も比較対象に含めます。

提案会社には、Shellを使った業務連携、夜間バッチ、Linux運用、レガシー移行の事例を確認します。その際、「Shellを使った経験があります」という説明だけでなく、どのOS・シェルを使ったか、DBやAPIとどう接続したか、何件程度のデータを扱ったか、失敗時にどう復旧したか、納品後の保守を誰が担っているかまで質問します。守秘義務で社名や詳細を出せない場合でも、匿名化した構成図や成果物サンプルを確認できる場合があります。

担当予定者との面談も重要です。営業担当の説明だけではなく、現行調査を行うエンジニア、設計レビュー担当、運用責任者に参加してもらいます。質問に対して「とりあえずShellで作れます」と答える会社よりも、Shellで作らない方がよい範囲、既存資産を捨てずに移行する範囲、監視と再実行の設計を具体的に話せる会社の方が、発注後の認識違いを減らしやすいです。

見積比較では、要件定義、現行調査、基本設計、Shell実装、ジョブ設定、単体テスト、連携テスト、受入支援、リリース、教育、保守を分けてもらいます。作業時間や人数が示されていなくても、工程ごとの金額と成果物が分かれば比較しやすくなります。特に「テスト一式」「移行一式」「運用設計一式」に何が含まれるかを確認します。

安い見積が必ずしも有利とは限りません。監視、ログ、リトライ、障害時手順、匿名化されたテストデータの作成、受入支援、ドキュメント、リリース後の保証が抜けていると、発注後に追加費用が発生します。各社の見積を、同じRFPの前提、同じ接続先、同じデータ量、同じ稼働時間で揃え、含むもの・含まないもの・追加単価を表にして比較します。

Shellのソースコードが納品されても、実行ユーザー、環境変数、ジョブの依存関係、入力ファイルの配置、終了コードの意味が分からなければ保守できません。ソースコード、設計書、ジョブ一覧、入出力定義、設定値一覧、テスト結果、障害時手順、リリース手順、運用引き継ぎ会、録画や議事録の有無を見積条件に含めます。

さらに、ShellCheckをCIへ組み込むか、対象シェルをshebangで固定するか、コードレビューを何回行うか、第三者が修正できる命名規約・ディレクトリ構成にするかも確認します。ShellCheckの公式Wikiは、対象シェルを明示しないスクリプトでは解析結果が不正確になり得るため、shebangの指定を案内しています（出典: ShellCheck公式Wiki SC2148）。ツール導入の有無だけでなく、納品後に社内で再現できるかを評価します。

発注から開発・受入・運用引き継ぎまでの進め方

発注先が決まったら、いきなり本番用のShellを作り始めません。まず現行業務と環境を調査し、対象範囲と成功条件を確認します。その後、最小の処理でPoCを行い、データの文字コード、接続、処理時間、失敗時の挙動を検証してから、設計・開発へ進めると手戻りを抑えやすいです。

PoCでは、全業務を自動化するのではなく、代表的な入力ファイルを一つ受け取り、変換し、テスト用DBや保存先へ出力するところまで確認します。実データを匿名化したサンプルで、文字コード、改行、日付、桁、NULL、重複、通信エラーを試します。PoCの成果物に、分かったこと、未解決の課題、本開発で必要な追加調査を残します。

PoCを無償の試作品として曖昧に進めると、結果が本開発の仕様へ反映されないことがあります。対象範囲、期間、成果物、検証環境、評価基準を小さな契約や発注書で定めます。PoC後にShellではなくPythonやETL基盤の方が適していると分かった場合も、それは失敗ではなく、将来の手戻りを減らす判断材料です。

単体テストでは、各スクリプトが期待した終了コードを返すか、入力が空でも安全に終了するか、ログに必要な情報が出るかを確認します。連携テストでは、実際のファイル受け渡し、DB登録、APIの認証、通知、ジョブの依存関係を確かめます。受入テストでは、現場担当者が業務の結果を見て「これなら翌朝の作業を任せられる」と判断できるシナリオを用意します。

異常系では、入力ファイルの欠落、不正な項目、通信タイムアウト、DB停止、容量不足、同一ファイルの再投入を試します。途中で止めてから再実行し、二重登録や二重送信が起きないことを確認します。Shell案件の受入条件は「エラーにならない」ではなく、「異常を検知し、原因を追跡でき、安全に復旧できる」ことまで含めます。

運用引き継ぎでは、日次確認、月次作業、ログの見方、通知を受けたときの一次切り分け、再実行の判断、エスカレーション先、バックアップからの復旧を確認します。ジョブの一覧表には、実行順、依存関係、実行ユーザー、入力・出力、標準終了コード、異常終了コード、ログ保存先、連絡先を記載します。

引き継ぎ会は一度の説明で終わらせず、社内担当者が実際にテスト環境で再実行する演習を行います。委託先の担当者がいないと復旧できない状態は、ベンダーロックインと属人化を残します。保守契約を継続する場合でも、発注者が状況を把握し、別会社へ移管できる粒度のドキュメントを納品条件にします。

Shell Script特有のセキュリティと運用リスクを防ぐ方法

ShellはOSのコマンドを直接扱えるため、便利である一方、外部入力や権限の設計を誤ると影響範囲が大きくなります。特に、ファイル名、URL、検索条件、取引先コードなどをコマンド文字列へ連結する処理は、コマンドインジェクションや引数インジェクションの原因になります。発注時にセキュリティレビューとテストを作業範囲へ含めます。

対策の基本は、外部入力をOSコマンドへ直接渡さないことです。どうしても渡す場合は、コマンドを固定し、引数を構造化して渡し、文字種・長さ・形式の許可リストで検証します。禁止文字をいくつか探すだけのブラックリストに頼ると、想定外の記法を見逃す可能性があります。実行ユーザーも、処理に必要な最小権限へ絞ります。

OWASPのOS Command Injection Defense Cheat Sheetは、OSコマンドを直接呼び出さず、避けられない場合はパラメータ化と入力検証を組み合わせ、コマンドや引数を許可リストで管理する方法を推奨しています（出典: OWASP OS Command Injection Defense Cheat Sheet）。発注先へ、コードレビューでの確認項目、静的解析、異常入力テスト、最小権限の設定を提案書へ含めてもらいます。

同じジョブが同時に動かないロック、処理済みデータを二重登録しない識別子、タイムアウト、リトライ回数、失敗時の中断位置を設計します。リトライを無制限にすると、障害中に接続先へ負荷をかけ続けたり、重複処理を起こしたりします。成功・警告・失敗を終了コードで区別し、監視側が判定できるようにします。

ログには、ジョブ名、実行日時、対象ファイルやデータの識別子、処理件数、処理時間、終了コード、エラー原因、次の対応を残します。ただし、パスワード、APIキー、個人情報、決済情報をログへ出さないマスキングも必要です。保存期間、改ざん防止、閲覧権限、容量上限、アラート条件までを運用設計書へ書きます。

開発会社へ本番アクセスを与える場合は、期限付きアカウント、踏み台、承認記録、多要素認証、操作ログを用意します。秘密情報はソースコードやGitの履歴へ残さず、Secret Managerなどから実行時に取得する設計を検討します。委託先の開発者が本番データを直接持ち出せないよう、匿名化データでテストできる環境を整えます。

請求・会計データ、個人情報、従業員情報、医療情報などを扱う場合、Shellそのものではなくデータと業務に応じた法令・社内規程への対応が必要です。保存期間、改ざん防止、アクセス権、事故報告、再委託、契約終了時の消去を、法務・情報システム・業務部門と確認します。2026年の企業IT調査でも、システム開発では内製と外部委託を使い分ける論点が示されており（出典: 一般社団法人日本情報システム・ユーザー協会「企業IT動向調査2026」）、丸投げせず、社内の判断者を残すことが大切です。

Shell Scriptのシステム発注・外注に関するよくある質問

最後に、発注前に特に相談の多い疑問へ回答します。Shellを採用するかどうかは、既存環境、処理の複雑さ、運用体制、セキュリティ要件を合わせて判断します。

単純なファイル処理だけなら、20万〜80万円程度の小規模レンジで収まる可能性があります。ただし、これは記事用の推定レンジであり、Shell専用の固定価格ではありません。DB・API連携、監視、再実行、個人情報、24時間運用が入ると、設計・試験・保守の費用が増えるため、コード本数だけで安さを判断しないことが大切です。

必ずしもShell専業会社である必要はありません。Shell・Unixの既存資産を読めることに加え、Linux運用、DB・API連携、ジョブ監視、セキュリティ、業務要件整理、引き継ぎまで対応できる会社を選びます。Shellで作らない方がよい処理を正直に説明し、必要ならPythonやETL、クラウド基盤へ分けて提案できることも評価します。

そのまま渡す前に、ソースコード内のパスワードやAPIキーを削除し、契約上の秘密保持、アクセス範囲、再委託、返却・消去条件を確認します。現行スクリプトだけでなく、実行環境、cronやジョブ管理の設定、入力ファイルの例、障害時の運用をまとめて共有すると、調査の精度が上がります。まず現行調査を準委任で依頼し、移行範囲を決めてから本開発へ進む方法もあります。

処理仕様、成果物、検収条件を固められるなら請負、現行調査や要件整理を伴い、専門家と相談しながら進めるなら準委任が向いています。実務では、現行調査・要件定義を準委任で行い、仕様が固まった後の開発・納品を請負にする段階発注も選べます。契約形態よりも、成果物、作業範囲、変更管理、責任分界を明文化することが重要です。

まとめ

Shell Scriptのシステムを発注・外注するときは、Shellのコード本数ではなく、業務処理が安全に継続できる範囲を定義します。単発の自動化、部門内バッチ、全社連携、レガシー刷新を切り分け、Shellに向く処理とPython・Java・ETL・パッケージへ任せる処理を整理します。

RFPには、現行フロー、入出力データ、接続先、処理時間、締め時刻、異常系、再実行、監視、権限、ログ、成果物、責任分界を記載します。費用は単一処理なら20万〜80万円程度、部門内連携なら80万〜300万円程度、複数部門の基盤なら300万〜800万円程度という推定レンジを起点にし、作業範囲と前提を揃えて複数社へ見積を依頼します。これらはShell専用の確定価格ではないため、具体的な要件と環境に基づく提案で更新します。

委託先は、Shellを書けるかだけでなく、Linux・Unix運用、データ連携、監視、セキュリティ、テスト、障害対応、ドキュメントと引き継ぎまで確認します。ShellCheck、許可リスト検証、最小権限、秘密情報管理、冪等性、ロック、ログ、再実行を設計と受入条件に含め、納品後に社内や別会社でも保守できる状態を目指します。小さくPoCを行い、実データに近いサンプルで成立性を確認してから、本開発と長期保守を判断してください。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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