Products
稼働しているもの
| 名称 | 内容 | 公開 |
|---|---|---|
| OptiLync | 店舗運営システム。予約・会員管理・サブスク課金・入退室・レッスン・法人契約・経営分析。直営店で先行運用し、外部店舗へ提供。 | optilync.jp |
| andMA | M&A・事業承継プラットフォーム。案件掲載、買い手審査、開示範囲の段階管理、秘密保持の取り交わし。 | andma.jp |
| tervex.jp | コーポレートサイト。共通部品からHTMLを生成する自作ビルド基盤で運用。構造化データ・sitemap・リンク切れ検査をビルド時に自動処理。 | 本サイト |
| tervexgolf.com | 直営スタジオのサイト。WordPress（自作テーマ）。料金改定・告知を日常的に更新。 | tervexgolf.com |
Architecture
システム構成
OptiLync の構成です。会員・スタッフ・本部が同じアプリを権限違いで使い、決済・入退室・通知・AIは外部サービスをサーバー側から呼び出しています。
図は横にスクロールすると全体が見られます →
※ 図は OptiLync の構成です。andMA も同系統の構成で、決済・入退室の連携はありません。
Stack
技術スタック
| 役割 | 使っているもの | 選んだ理由 |
|---|---|---|
| 画面・API | Next.js（App Router）／TypeScript／React | 画面とサーバー処理を1つのコードベースで扱えるため。型がある言語で、仕様変更時の壊れに気づける。 |
| データベース・認証 | Supabase（PostgreSQL／Auth）／東京リージョン | PostgreSQL の制約機能で、予約の重複や二重課金をデータベース側で防げる。 |
| ホスティング | Vercel／東京リージョン（hnd1） | 国内の利用者に近い場所で処理するため。git への push で自動デプロイ。 |
| 決済 | PAY.JP（トークン方式・カード情報非保持） | カード番号を自社で預からない構成にできるため。店舗ごとの個別課金にも対応。 |
| 入退室 | RemoteLOCK ／ ALLIGATE（API連携） | 無人運営で、予約した時間だけ解錠する必要があるため。 |
| 認証・通知 | LINE Login ／ LINE Messaging API ／ メール | 利用者にパスワードを作らせないため。通知の到達率が高い。 |
| AI | Anthropic Claude API | 売上・稼働・退会の数値から、読める日本語の分析と改善案を作るため。 |
| コーポレートサイト | 静的HTML＋自作ビルド基盤（Node.js） | CMSを置かないことで、改ざんと表示速度のリスクを下げるため。 |
| バージョン管理 | Git／GitHub（非公開） | 変更履歴を残し、前の状態に戻せるようにするため。 |
この構成で、御社の業務システムも作れます
自社の店舗・FC本部・M&Aプラットフォームを動かしている構成を、受託開発でもそのまま使っています。技術面のご質問だけでも承ります。
Development
AIを前提にした開発
当社は少人数です。そのぶん、実装をAIに担わせ、人は「何を作るか」と「できていると判断する基準」に集中する体制をとっています。実験ではなく、上記のプロダクトを実際にこの方法で作って運用しています。
01
先に動くものを出す
文字だけの仕様書で合意してから作り始めません。早い段階で動く画面を出し、実際に触って違和感を拾います。仕様の抜けは、文章を読んでいるときではなく操作しているときに見つかります。
02
決定の経緯をコードと同じ場所に残す
料金・ルール・運用上の判断とその理由を、リポジトリ内の文書に残しています。人が入れ替わっても、なぜこの仕様になっているかを追えるようにするためです。
03
ローカルに変更を残さない
作業のたびに git へ記録し、リモートへ反映します。データベースの変更は日付つきのマイグレーションとして残し、現在の構造をスナップショットとして保存します。「担当者のパソコンにしかない状態」を作りません。
04
通してからデプロイする
型チェック、ルールのユニットテスト、コード整形を通したうえで反映します。反映後は「保存できました」の表示を根拠にせず、公開URLを開いて現物を確認します。
05
引き継ぎ書を製品の一部として扱う
アカウント一覧、日常の運用手順、障害時の確認箇所を文書として維持しています。仕様を変えたら同時に更新します。
Security
セキュリティと運用
Payment
カード情報を持たない
- 決済はトークン方式。カード番号は当社のサーバーとデータベースを通りません
- 二重課金は、データベースの一意制約と冪等キーで防止
Data
データの置き場所
- データベース・アプリケーションともに東京リージョン
- 秘密鍵・接続情報はリポジトリに含めず、実行環境の環境変数で管理
Access
権限の設計
- 書き込みはすべてサーバー側の処理を経由。クライアントから直接データベースに書き込みません
- 店長・スタッフ・コーチは金額と会員数を閲覧できない設定
Integrity
データの整合性
- 同一打席・同一時間帯の予約重複を、データベースの排他制約で禁止
- 日付・時刻はすべて日本時間に変換する共通処理を経由（サーバーはUTCで動作するため）
Recovery
戻せるようにする
- コード・設定・データベース構造の変更履歴をすべて保持
- 反映前の状態に戻せる手順を引き継ぎ書に記載
※ 当社は少人数体制のため、24時間365日の即時障害対応はお約束していません。ミッションクリティカルな用途については 業務システム開発 のページに対応範囲を記載しています。
技術面のご相談だけでも承ります。
いまの見積りが妥当か、作るべきか既存サービスで足りるか。初回のご相談は無料です。