未来の銀行決済を創造し、世の中にその価値を提供します。 2025年7月にプロダクトをローンチし、ファーストユーザーにご利用開始いただいております。

募集停止
未来の銀行決済を創造するフィンテック企業で、CTO候補としてプロダクトの価値を引き上げ、非連続な成長をリードするミッションを担いませんか?年収1,000〜1,300万円、フルリモート可能な柔軟な働き方を提供。小規模な開発チームで、TypeScript、Go、GCPなどの技術を駆使し、プロダクトの仮説検証フェーズを共に進めます。CEOと伴走し、未来の決済ソリューションを共に創り上げる挑戦を求めています。あなたの経験と情熱で、次世代の決済システムを共に築きましょう。
給与・報酬 | 年収 1,000万円 ~ 1,300万円 |
|---|---|
稼働時間 | 裁量労働制 |
雇用形態 | 正社員 |
出社頻度 | 相談の上決定する |
勤務地 | - |
未来の銀行決済を創造し、世の中にその価値を提供します。 2025年7月にプロダクトをローンチし、ファーストユーザーにご利用開始いただいております。
高い視座でプロダクトの価値を引き上げて頂きたい!
これまで、お客さまに価値を提供するMVP (Minimum Viable Product)の開発を進め、ようやく仮説検証フェーズに入ります。 早期の PMF (Product Market Fit) を目指し、技術面だけでなくビジネス・経営視点でプロダクト開発に関与しプロダクトの価値の底上げ、非連続な成長をリードして欲しいです。
CTO(候補)という立場でプロダクト開発を牽引し、世の中にない価値を創造していただきます。 また、チームビルディング、エンジニア採用についても貢献をいただきたいと考えております! 小規模な会社だからこそ立場やチームを問わず横断的に議論し、課題を解決することを最重要視しています。
いち従業員という枠から飛び出し、CEOと伴走しながら高い視座を持って会社経営の一端を担っていただきます。
開発チームは現在4〜5人規模です。 デザイン、フロントエンド、バックエンド、インフラの各領域を得意なメンバーが牽引しながら前に進めています。 チーム規模が小さいからこそ、1人1人のメンバーのプロダクトに対する責任と権限が広く、主体的にプロダクトに関わっていける環境になります。
開発イベントとしては、毎日朝会を実施し、金曜日に開発の振り返り会を実施しています。 ざっくばらんになんでも話し合える間柄を目指しています。 難しい仕事を「楽しむ」ことを大事にしていきたいです。
雇用形態 | 正社員 |
|---|---|
給与・報酬 | 年収 1,000万円 ~ 1,300万円 |
稼働時間 | 裁量労働制(出社推奨・リモートOK/ フレックスタイム制(コアタイムなし)/ 柔軟な勤務体系、副業可(ただし週5日以上の勤務必須)) |
出社頻度 | 相談の上決定する |
休日・休暇 | 完全週休2日制(銀行営業日に準じる)/ 年次有給休暇(最大年間20日) |
社内制度 | 社保完備(VCスタートアップ健康保険組合、厚生年金保険)/ 副業、兼業OK/ ストックオプション制度あり(※正社員対象)/ 書籍購入制度/ ディスプレイ:適宜相談の上支給(例:34型湾曲ワイドディスプレイ)/ ガジェット類:適宜相談の上支給(例:キーボード、マウス) |
Pay By Bank ・銀行口座間決済を活用した 代金回収DXソリューション を開発・提供しています。 ・個人から企業への支払いシーンではキャッシュレス決済が拡大し、 取引のデータ化により企業側の手間は軽減されています。 しかし、決済手数料の負担が大きく、手数料を避けるために現金払いや振込による 代金回収の手間が依然として課題となっています。 ・Pay By Bank は、ユーザーが普段利用している銀行口座から シームレスに支払いを完了できるソリューションです。 これにより、企業は代金回収の手間を大幅に削減しながら、圧倒的な低コストで 決済を実現できます。
※ポジションによってフローは異なる場合がございます。

給与・報酬:
月給 90万円 ~ 100万円
稼働時間:
70時間 ~ 80時間(週17.5 ~ 20時間)
雇用形態:
業務委託
出社頻度:
フルリモート

給与・報酬:
年収 1,000万円 ~ 1,800万円
稼働時間:
裁量労働制
雇用形態:
正社員
出社頻度:
週2-3日出社
給与・報酬:
年収 1,000万円 ~ 1,800万円
稼働時間:
09:00 ~ 18:00
雇用形態:
正社員
出社頻度:
月1日出社

開催前
AIコーディングエージェントの進化により、コードだけでなくUIデザインの領域でもAIに任せられる範囲が広がりつつあります。しかし、「AIが出力したデザインを人間のレビューなしでそのまま出せるか?」と問われると、まだ自信を持ってイエスと言える方は少ないのではないでしょうか。 そうした中、AIに「デザイナーの脳内」を型として渡し、デザインの実装だけでなく、評価や改善までを自動化していく「デザインハーネス」という考え方があります。AIにデザインをつくらせて終わりではなく、その出力を評価し、改善するサイクルをできるだけ自律的に回していくことで、AIに任せられる範囲をさらに広げていくアプローチです。しかし、デザインハーネスとは具体的に何を整備すればいいのか、実際にどこまでの品質が出せるのかを体系的に語れる事例はまだ多くありません。そこで本イベントでは、デザインシステムの構築やAIワークフローの実践に豊富な経験を持つこぎそ氏をお迎えし、デザインハーネスの基礎から、具体的な実践事例までを紐解きます。 前半のLTでは、こぎそ氏よりデザインハーネスの基礎的な考え方を整理いただいた上で、Design.mdやMCP連携、デザインシステムとの接続といった実際のワークフローに落とし込んだ実践事例、そして「デザイナーの脳内をどう型化していくか」という方法論をお話しいただきます。 後半のディスカッションでは、AIが出力するデザインの評価軸や、人間が介在すべき領域の見極め、実作業のメイン環境の選び方など、デザインエンジニアの現場目線でさらに深掘りしていきます。 AIを活用したデザインワークフローに関心がある方から、デザインハーネスの導入を検討されている方まで、幅広いデザインエンジニアのご参加をお待ちしています。

開催前
AIコーディングエージェントの進化により、コードを書くスピードはかつてないほど速くなりました。しかし、いくらAIで早くたくさん開発できたとしても、初手の要求・要件定義が十分にできていなければ、結局は使われない機能を量産してしまうのではないでしょうか。 AI時代において、設計や実装の多くはAIに置き換わりつつあります。だからこそ、人間の価値は「問題を定義し、発見する」ことにシフトしていく——そう考えると、要求・要件定義の重要度はこれまで以上に増してきています。しかし、普段の業務で要求・要件定義に本格的に取り組んだ経験がないエンジニアの方も多いのが現状です。 そこで本イベントでは、前回ご好評いただいた「AI時代×ドメイン駆動設計」に続く第2弾として、ミノ駆動氏を再びお迎えし、AI時代だからこそ向き合うべき要求・要件定義の考え方と実践を紐解きます。 前半のLTでは、ミノ駆動氏より、エンジニアに今後求められる「具体→抽象」の思考力、目的を起点とした設計の考え方、そして明日から始められる要求・要件定義の第一歩についてお話しいただきます。 後半のディスカッションでは、「Claude Codeに頼めばよしなにやってくれるのでは?」という率直な疑問から、要求・要件定義は誰が書くべきか、優秀なエンジニアの要求・要件定義は何が違うのかなど、現場目線でさらに深掘りしていきます。 「AIにコードは任せられるようになったけど、その前段階をどうすればいいかわからない」という方にこそ参加いただきたいイベントです。
.png)
開催前
AIの進化によってプロダクト開発のハードルが下がった今、企業の関心は「いかに良いものを作るか」から「どうやって市場に届け、ユーザーに使ってもらうか(Go-To-Market)」へとシフトしています。 こうした変化の中で、海外のAIスタートアップを中心に急速に注目を集めているのが「GTM(Go-To-Market)エンジニア」です。 営業でも、マーケターでも、単なる開発エンジニアでもない。 かつて10人のチームで回していた営業・マーケティング・オペレーションの設計からAIによる自動化までを、1人で主導する新たな役割です。 しかし、日本ではまだ認知が広まっておらず、「GTMエンジニアって具体的に何をしているのか」をイメージできている方はほとんどいないのが現状です。 そこで本イベントでは、GTMエンジニアリングの研究・発信を行う中村氏と、GTMエンジニアとして実践されているnumashi氏をお迎えし、海外での動向から日本での実態まで、GTMエンジニアという仕事の全体像を紐解きます。 前半のLTでは、お二人にそれぞれの視点からGTMエンジニアの役割や実際の業務内容、海外と日本での位置づけの違いについてお話しいただきます。 後半のディスカッションでは、どんな方がGTMエンジニアに向いているのか、単なる効率化で終わらせず売上に繋げるには、日本の組織での最初の一歩など、現場目線でさらに深掘りしていきます。 エンジニアとしての新たなキャリアの可能性を探している方から、GTMエンジニアリングに興味がある方まで、幅広いご参加をお待ちしています。

アーカイブ公開中
AIコーディングエージェントの活用が進み、多くの実装や技術選定をAIに委ねられる場面が増えてきました。そうしたなかでも、データベースを扱うORMの選定については「さすがにここだけは自分の手で決めておこう」と考えているエンジニアの方も多いのではないでしょうか。 しかし、従来の選定理由を振り返ってみると、その多くは「型補完がどこまで効くか」「どれだけ直感的にコードが書けるか」といった書き味(DX)や手厚い型サポートにあったのではないでしょうか。AIがコードを書くことが当たり前になった今、「人間にとっての書きやすさ」を軸にした技術選定のあり方には、少しずつ変化が生じ始めています。 では、もし仮にORMの選定すらもAIに任せてみようとしたとき、エンジニアとして最後まで人間が判断しなければいけない業務とは、一体どこにあるのでしょうか。 そこで本イベントでは、Drizzleを活用されているKenn Ejima氏と、Kyselyを使われている溝口(coji)氏をお迎えし、AI時代におけるORM選定の考え方と、「本当に考えなくていいこと」と「実はまだ考えるべきこと」の境界を紐解きます。 前半のLTでは、お二人にそれぞれのORM選定の背景や、AIとの付き合い方を含めた現在の開発スタイルについてお話しいただきます。 後半のディスカッションでは、DBスキーマをAIにどこまで任せるか、マイグレーションの管理、DB選定の重要性など、現場目線でさらに深掘りしていきます。 「ORMは自分が選ぶもの」と自然に思っていた方にこそ、これからの技術選定の軸を一度立ち止まって考えるきっかけになるイベントです。
開催日:
2026年9月9日(水)19:00~20:00

アーカイブ公開中
いま、AIを活用した業務効率化の文脈で「Claude Code」が大きな注目を集めています。しかし、いざ導入しようとすると、セキュリティ面の懸念や権限管理のハードルから、気軽に使えないケースも多いのではないでしょうか。 Coworkは、非エンジニアでも簡単に安全に扱えるよう作られた機能です。そして実は、日常の業務領域であれば「Coworkで十分にカバーできる」だけでなく、想像以上の範囲まで自動化できることは、まだあまり知られていません。 そこで本イベントでは、メルカリで生成AI推進を担当されているハヤカワ五味氏をお迎えし、Coworkを使った業務自動化の実際を、公開デモを交えてわかりやすくお伝えします。 前半のLTでは、ハヤカワ氏よりメルカリでの判断基準をもとに「なぜClaude CodeはNGになりがちで、なぜCoworkなら安全なのか」を解説いただいた上で、Coworkの基本的な機能をご紹介いただきます。 続く公開デモでは、実際にCoworkを使ってワークフローを構築する様子をお見せいただきます。数分でワークフローが完成する手軽さや、Gmail等の外部サービスとセキュアに連携できるポイントなど、実演を通じて具体的なイメージをお届けします。 後半のディスカッションでは、セキュリティの考え方や社内導入の進め方など、現場目線でさらに深掘りしていきます。 「自分の業務をAIで自動化してみたいけど、何から始めればいいかわからない」という方にこそ参加いただきたいイベントです。
開催日:
2026年8月26日(水)19:00~20:00