B/43 サービス立ち上げ時の技術選定について（サーバサイド編）
今回は自分たちが作っている B/43 というプロダクトの立ち上げ時においてどんな形で技術選定を行なってリリースに至ったかについて記載しようと思います。 Fintech サービスの裏側の話は意外と世に出ていないことが多く、また採用の機会において候補者の方に聞かれることも多いので改めてエントリーとしてまとめておこうと思います。
前置き
B/43 は事業の着想を経て準備をしつつ、何だかんだでリリースまでを含めると約2年掛かっています。現在はローンチして数ヶ月経過し、PMF しているかどうかをユーザーの動向を確認しつつ、さらなる機能追加や UI /UX の見直しを行なっています。
開発メンバーは創業者含めると8名で下記のような構成になっています。
- PM & デザイナー: 1名
- エンジニア: 7名
- インフラ: 1名
- サーバサイド: 5名
- クライアントサイド: 1名
メンバーの増加は段階的に進んでいったので、最初は3名から始まり徐々にメンバーが増えていった形になります。
提供しているサービスは現在は iOS アプリのみで、Android 版は絶賛開発中です。
リリース時点の求められる要件
事業サイドやプロダクトサイドとリリース時点の機能を整理して、必要になってきた開発要件としては大体下記のようなものでした。
Visa の決済ネットワークである VisaNet と接続して、カード決済ができること
- 決済電文をオンタイムで処理する必要があり、高いパフォーマンスが求められる
- 部分的に Windows 環境で動かす必要あり
物理プリペイドカードの発行 / 管理 ができること
- PCI DSS に準拠する必要があり、 インフラ / アプリ両方で高いセキュリティ要件を満たす必要あり
サービス内で法律 / ガイドラインに準拠した本人確認（eKYC）を実施できること
- 身分証画像を預かって、社内で管理 / 閲覧できること
- 本人画像と身分証画像の一致度を判定し、本人と特定できるような仕組みの構築
ユーザーのお金を預かって残高管理ができること
- シンプルに高い信用性が求められるのとトランザクションに気をつけて実装する必要あり
外部サービスと連携して入金 / 出金 ができること
- 入金 / 出金の方法ごとに外部ベンダー数社とのシステム連携が必要
その他
- パスワード無しで、安全な方法で会員登録 / ログインできること
- 会員登録時や決済時等、必要なタイミングでユーザーにプッシュ通知が送れること
- AML / ASF 対策として、会員情報の定期的なスクリーニングができること
- 各オペレーションに沿った操作が可能な社内用管理画面の作成
正直なところ、決済やカードにまつわる部分の開発は、仕様がクリアになるまで時間がかかったこともあり、開発の流れとしては、勘定系や会員登録周りなどから着手し始めて、その後決済やカード部分の開発を行うといった形で進めていくことになりました。
技術選定
各コンポーネント毎の技術を話す前にシステムの構成を説明しておきます。 現在は下記のように、モバイルアプリが使用する業務ロジックを扱う API 群と PCI DSS に準拠し、VisaNetとの繋ぎ込みやカード情報の管理を司るシステムと大きく2つのコンポーネントに分かれています。
※ PCI DSS （クレジットカード業界の国際セキュリティ基準。カードを発行するために必要で審査機関による認定を受ける必要有り）
当初は全てのサービスが単一のリポジトリに収まるモノリシックなシステムを想定していましたが、仕様の全体像や PCI DSS に準拠するための制約が明らかになるにつれて、設計を見直してコンポーネントを大きく2つに分けました。
PCI DSS への準拠対象を全てにすると、今後の開発スピードに著しく関わってくるので、そこだけは避けて限定的にしつつ、決済やカード発行という境界が分かりやすく分離できそうな箇所を切り出した形です。
決済API / カード発行基盤
開発言語は Golang を採用しています。以下のような点が採用したポイントでした。
- Windows 環境向けにクロスコンパイルができる
- VisaNet の電文仕様や、カード発行における印刷会社との連携データフォーマットは事前にステークホルダーと詳細を詰めて開発を進めたため、連携項目ごとにデータを定義でき型安全な開発ができる
- 以前開発していた、Golang 製 API でパフォーマンス面での信頼性もあったので採用もしやすかった
シンプルに net/http を使って API サーバを構築しており、ルーティング部分に Echo を使っています。
カード発行基盤はカード情報を操作する API と複数のバッチ群で構成されています。 バッチは urfave/cli を使って、CLI を使って呼び出せる様になっており、カード発行用のコマンド、決済調査用のコマンドなど用途に分けて実装されています。
モバイル向け API
開発言語は Ruby を採用しています。 業務ロジックを扱う API が集約されており、最も機能追加、修正の機会が多いのでライブラリが豊富で手慣れた開発スピードの出る言語、フレームワーク（Ruby on Rails）で開発しています。
認証や入出金、タイムラインなどの各情報の閲覧 / 更新を司る API 群が Rails の API モードを使って実装されています。
認証
SMS認証部分に Vonage API （旧Nexmo）を使っています。 Vonage の優れている所は gem でシュッと導入できる所もそうですが、課金体系が認証時のみなので、ユーザーが実際に SMS 認証を完了するまでは SMS を何度送っても料金がかからない所かなと思います。
また、日本法人のサポートも手厚く、依頼すればきちんと国内ルートでの配信設定をお願いできたり、送信元の電話番号も管理画面経由でサクッと入手できるのも良い所です。
本人確認（eKYC）
B/43 の eKYC はユーザーに身分証画像やライブネスチェック用の本人画像を複数枚送ってもらい、画像の顔検出や身分証画像との一致、ドキュメントと入力情報の一致などいくつかのチェックポイントを設けて確認を行なっています。
目視確認もオペレーターが行っていますが、画像の顔判定や身分証画像との一致は AWS Rekognition を使い、判定したスコアリングを評価の参考にするなど、サービスをうまく使ってオペレーションコストを減らすようにしています。
プッシュ通知
プッシュ通知は専用の通知を送る API として切り出して実装されています。 各API サーバやバッチサーバでプッシュ通知を送らずにサービスとして切り出したのは以下の理由からです。
- 複数のサービスからプッシュ通知を送りたい
- 特定の処理後（決済後、会員登録後、カード発行後、etc...）任意の箇所から呼ばることが想定される
- 一斉多量配信など、決まった日時に多量の通知を送りたいシーンがある
- 通知の配信タイミングをコントロールしたい
以前もプッシュ通知を大量に送るサービスを運用していたのですが、バッチサーバ単体で動かすとネットワークレイテンシの問題で配信に時間がかかる、また一斉配信後にユーザーからの大量アクセスがあり、DBが高負荷になるなどの経験をしてきたので、プッシュAPI自体は別サービスとして切り出しつつメッセージキューとジョブワーカーを内包したHTTPサーバとして実装されています。
実装としてはシンプルで決済APIと同等の構成で通知処理には firebase を、キューイングの仕組みとして goworker を利用して実装されています。
通知のリクエストを受け取ったプッシュAPIは一度配信用データとして、データをDBに保存、非同期キューにエンキューし、即座に結果をクライアントに返します。 その後、goworker がデキューし、プッシュを配信、結果はクライアント側に webhook として通知されるようになっています。
まとめ
B / 43 で行ってきた主だった技術選定について、紹介しました。 改めて見てみると、割と手堅くチームの使い慣れた技術で技術選定をしてきたように思います。
管理画面や AML / ASF、バッチ処理のタスクスケジュールなど紹介しきれていない部分があるので、各コンポーネント毎にどういった技術を採用して開発を進めているかは、また別のエントリーにして情報発信していきたいと思います。
簡単な技術スタックは、それぞれの求人職種欄にのせているので、参考にしてください。
このエントリーが何かの役に立つと幸いです。
SmartBank, Inc. を創業し B/43 というサービスをはじめました
前置き
こちらのエントリーを書いてから約3年が経ちましたが、また新しいチャレンジを始めています。
少し自己紹介すると、元々フリマアプリ（フリル → 現ラクマ）を作る Fablic社を共同創業（CTO）し、同社は後に楽天へM&A、退任してからはプロダクト開発やコードを書く仕事から少し遠ざかっていたのもあり、ANGEL PORT という起業家とエンジェル投資家のマッチングサービスを作っていました。
ローンチ後は、下記のエントリーにもあるように次のフリマアプリを超えうる起業テーマ、ユーザー課題を探してロンドンやドイツなど Fintech 先進国へユーザーインタビューなどにも行っていました。
初めて起業し、フリマアプリを作った時は確か25歳でした。そこから10年後、また同じメンバーで今度はスマートバンクという社名で起業し、お金の管理に対する課題に向けてプロダクトを作っています。
smartbank.co.jp ドメインが空いていたので、取得できたのはラッキーでしたね。
改めて振り返ると自分はものづくりが好きで、作ったプロダクトから得られるフィードバックを生きる糧にしている所もあり、今回もチャレンジしがいのあるテーマを選べたなと思っています。
このエントリーでは 0 → 1 のプロダクト開発、まだアイディアの状態からどのようにして 最初のリリースを迎えていったかを技術的な視点も交えて綴っていこうと思います。
B/43 というプロダクトについて
B/43は「家計簿アプリ」と「Visaプリペイドカード」がセットになった「家計簿プリカ」という新しいサービスです。毎月の予算をカードにチャージして日々の支払いをすることで、自動で記録され、見える化されるので、支出管理を簡単に継続することができます。
なぜこのプロダクトを作ろうと思ったかは @shota の記事に、どんなプロダクトなのかは @takejune の記事にもっと詳しく書かれていますので良かったらそっちも見てもらえると嬉しいです。簡潔にいうとフリマアプリを運営する中で感じた多くの人が支出を正しく把握できていないという課題をこのプロダクトで解決したいと思っています。
初期の開発について
フリマプリの企画からリリースまでは半年でしたが、B/43 は約2年リリースにかかっています。 お金を預かってカードを発行し決済させる、お金は自由に出金もできるという銀行と同等の機能が必要で、プロダクトを成立させるまでのミニマム要件が下記のような感じでした。
- 会員 / 認証基盤
- eKYC
- AML / ASF（マネーロンダリングや反社チェックの仕組み）
- 物理カード発行 / 管理基盤
- Visa 決済システム
- 入出金システム
- 勘定系、残高管理システム
- Push 通知配信基盤
- 上述の機能を横断的に取り扱う管理画面
書き出してみると、一つの機能が大きく、それなりに大変そうですね 😌（実際大変でした）
海外では Marqeta や Stripe といった Banking as a Service（BaaS）事業者が上記の機能を部分的にサービスとして提供しており、彼らのサービスを使うことで、工数を圧縮できる余地がありますが、日本の現状だとBaaSプレイヤーは少なく、大部分は自社で開発する必要があるでしょう。
技術的なハードルについて
今回はただ作るという面以外に、実は下記の2つの要件をクリアする必要がありました。
- PCI DSS（クレジットカード業界の国際セキュリティ基準。カードを発行するために必要で、審査機関による認定を受ける必要有り）
- 資金移動業者登録（預かったお金を現金として出金できるようにするために必要）
どちらも、高いセキュリティ基準、及びそれを執行する体制、膨大な量の書類の提出が必要で、資金移動業者として登録完了までにちょうど1年程度かかりました。
振り返って考察すると、フリマアプリはプロダクトとして最低限成立させるための要素はそれほど多くなく、サービス自体をローンチさせるのはそれほど難しくなかったでしょう。事実我々がサービスインした1年後には、レッドオーシャン化し大手IT企業、メルカリのようなベンチャー企業が続々と参入してきました。（ビジネスとして勝ち切るのはまた別の話ですが）
しかし、今回のサービスは開発難易度、クリアするべき規制や法令、開発・運用にかかる莫大なコスト等々、非常にハードルが高いので、プロダクトを作れること自体がある程度の参入障壁になっているとも言えます。ベリーチャレンジングですね。ここから少し技術的な取り組みを振り返っていきましょう。
1. 技術的な取り組み - eKYC -
ユーザーが物理カードを発行する前に eKYC（本人確認手続き）を行っていますが、システム自体は内製しています。実は開発前に外部のベンダーを使うことも考えて、何社かお話を伺ったのですが、ユーザー体験を担保しつつアプリに組み込める良いサービスが無く、色々検討した末に自前で作ることに決めました。
正直、既存のサービスを組み込めば、早く簡単に導入はできるでしょう。ただ、弊社では大切なユーザー体験の一部を妥協して作るということはまずありません。よーし、自分たちで作るかー、とすんなり決まって、数日後にはアプリエンジニアがこんなかんじでどうです？とプロトタイプをあげてくれました。
eKYC はプロセスの大変さもあって高い確率でユーザーが離脱してしまうので、アプリエンジニアが注力したポイントの1つです。外部サービスに飛んだりせず、あくまでもアプリ内だけでスムーズに終えられることを念頭に作り込んでいます。
特に顔認識（ライブネスチェック、事前に予め用意した画像ではないか）するための首振りやウィンクなど動作検出部分は中々苦労しました。
開発はユーザーに試しに触ってもらいながら、この場合は検出できないなーなど、試行錯誤しながら進めていき、離脱ポイントになりやすい点を観察しながら仕上げていきました。 自分たちは昔からユーザーインタビューをたくさんやる会社で今回も150人ぐらいにはしています。こうやって手触り感を持ってプロダクトを作り込んでいくスタイルは今後もブレずにやってきたいなと思います。
2. 技術的な取り組み - PCI DSS -
PCI DSS の取得まではQSA（PCI DSSの審査機関）の選定を含めて実質半年ほどかかり、初めてだったことと、予算を節約したかったのもあり、準拠対応はそれなりに大変でした。
やってみて分かったのですが、PCI DSS はいかに準拠対象のシステムスコープをミニマムにし、範囲を狭められるかによって作業量が全然変わってきます。 社内体制によっては外部のコンサル等に監修をお願いすることもあるかと思いますが、それだとコストが掛かってしまうので、ここまでは自分達でやるといった線引きも大事です。
- PCI DSS 準拠 / 非準拠環境の境界を見極めてシステムの分離を行い、準拠スコープを局所化する
- ペネトレーションテストはツールを自社で導入、実施し外部委託コストを減らす
- ツールで対応できないテストだけを外部業者にお願いする
- 準拠資料はQSAや外部業者から雛形を調達し、必要箇所だけカスタムして記述量を減らす
上記は学んだことの一部ですが、PCI DSS は取得して終わりではなく定期的に監査があり、あと半年後には PCI DSS ver4.0 もリリースされていると思うので、次回に学びを生かしていきたいですね。
インフラ的に面白いのはコンテナをフル活用して、PCI を取得した所にあります、現行の PCI DSS ver3.2.1 が現在のクラウド技術を前提にしていない部分もあるので、QSAと相談しつつ進めたのですが、AWS Fargate を使うので、そもそも ssh させない前提でクリアにした要件もあります。
また、PCI DSS 非準拠環境（通常のアプリが使うAPI群）とインフラの管理や運用フローは統一させたかったので、AWS は使うもののアカウントは分ける、Terraform、Github Actions を使って管理やデプロイフローは統一させるなどの工夫も行っています。
3. 技術的な取り組み - Visa Network 決済 -
一番苦労した部分はどこかと聞かれたら、やはり決済システムの構築でしょう。実際のシステム稼働まで1年は掛かっていると思います。 弊社は モバイルアプリを提供するスタートアップという側面の他に、今回はカード発行会社（イシュア）という面もあります。
大きく2つの処理があり、1つはオーソリといわれている、ユーザーが加盟店でカードを使った際に決済が可能かどうか確認する処理です。 加盟店 → アクワイアラ → 国際ブランド（Visa）のネットワーク → イシュアのシステムと電文が届きます。決済システムは電文をパースしユーザーの残高と照会、購入可能かどうかを返答します。
もう一つは、クリアリングと呼ばれている売上の確定処理です。オーソリで確認した決済は、数日後に加盟店側で確定され、そのデータがイシュアへやってきます。イシュアはデータを確認し、問題なければユーザー残高を確定させます。
文字にすると簡単そうですが、VisaNet へ接続するのがそもそも難しく、また電文のパターンは多岐に渡り、Visa の膨大な資料を読みつつ仕様把握、決済処理を構築していく必要がありました。
開発していて面白かったのは、決済電文で送られてくる加盟店の情報ってかなりカオスなんですよね。 みなさんもカードの明細を見て思ったことがあるかもしれませんが、加盟店の表記がマチマチだったり（大文字、小文字、英語）支店名があったりなかったり、モールの中の特定のショップで買ったのに明細の加盟店名はモール名になってたり。
ですので、我々は家計管理において、電文の情報をただ表示するというのは、あまり良くない体験だと思っています。電文情報もきちんと蓄積、解析し、最終的には統一された見やすいフォーマットでどの店舗で決済したのかまで表示できるように取り組んで行こうと思っています。
タイムラインはスクロールに合わせてトップのグラフも連動して動きます。日や月が変わった際にも、キチンとグラフが追従し、見た目にも分かりやすく支出を把握できるようにしている所がこだわりポイントです。
今は決済されてくる電文を観察しながら、中にはプリペイドカードに適さない決済や、拒否した方がいい加盟店などもあるので、ロジックのチューニングを行っています。イシュアとして事業をやっていないと手に入らない生の決済情報を集めながらシステムをアップデートしていくのはエンジニアリング的にかなり面白いですね。
例えば、セブンイレブンとローソンはどの店舗で決済しても加盟店名は同じですが、ファミリーマートは支店名が末尾につきます。なので決済店舗を特定することが可能で、将来的には決済した場所をアプリで地図表示できるんじゃない？みたいなのを日々ウォッチしては実装しています。 サブスク系サービスの電文も個々に特徴があり、電文を眺めては将来的に Netflix や Hulu などのサービスの課金をアプリで管理できないかなーと妄想しています。
最後に
少々長くなりました。いくつかの技術的なハードルを超えて、やっとプロダクトをリリースし、今は日々数字やユーザーの反応を見ながら改善を加えていっています。
プロダクトを作ってみて、改めて簡単ではなく、ユーザーの課題を解決しつつビジネスとして成立させることの難しさも感じています。
いくつかトピックを上げたように、モバイルアプリ / インフラ / サーバサイド、どのレイヤーを切り取っても開発が難しいコンポーネントがあり技術的なチャレンジは今後も続いていくでしょう。
大変なテーマを選んだなという実感もありますが、なんだかんだいって自分はこの 0 からプロダクトを生み出していく瞬間が最高に好きです。技術力を注ぎ込んで作ったプロダクトが課題を解決するシーンを見るのが最高に楽しく、そこにエンジニアを目指した原点があると思っています。
また、チームも最高にいい状態です、スピード感があり、阿吽の呼吸で開発が進んでおり、もう数ヶ月すればまた目玉となる機能をリリースできそうです。
つらつらと書いてきましたが、入金方法拡充や送金など基本的な主機能の追加の他に、電文情報の蓄積 / マイニング、カードの非接触決済の対応やデジタルマネーの給与受取など、まだまだ対応しないといけないことがあります。Android 版もまだない...!
例によって一緒に開発してくれるメンバーを大募集中です。 このエントリーや他のエントリーを見て、ちょっとでもプロダクトに興味が湧いた人は是非カジュアルにお話させてください。とりあえず、緩く話を聞いてみたいといったレベルでも全然OKです！いつでもご連絡お待ちしております！
長文お読みいただきありがとうございました。 それでは！
Fablic, inc のCTOを退任しました。
実は、2012年に創業した Fablic, inc を楽天社への合併のタイミング（6月30日）で退任しておりました。
25歳から約7年間、会社を創業し、フリマアプリを開発、フリマ戦争の真っ只中を過ごし楽天へExit、そして退任と人生の中でもっとも濃い日々を過ごしました。
いろんな方に支えていただきながらの7年間でしたが、折角なので、少し自分がやってきたことを振り返っていけたらと思います。
創業
まず、自分の仕事は考えていた課題の検証、そしてそれを解決するプロダクトを創ることでした。 フリマアプリをなぜ創ろうとしたかは弟の 僕がフリマアプリを創った理由 のエントリーがよくまとまっています。
創業1〜2年目はフリマアプリを開発し、軌道に乗せるまでの開発が主でした。
当時はCtoCのプロダクトに決済の仕組みをいれるのが難しく（サービスベンダーさんからNGが出る）リリースまでやきもきしたのを覚えています。
※ 創業時は共同創業者全員でガレージ付きの1家屋で一緒に暮らしていました。
この頃は開発しつつもアプリを使ってもらえるかの検証やプロモーションで大学のサークルを周ったりとエンジニアリング以外のことも忙しくしていました。
フリマアプリのPMFはとても早く、1年ぐらいは創業メンバーだけでやっていましたが、とても開発の手が足りなかったので、2年目からエンジニア採用も同時に行っていきました。
この時の教訓
- PMFが最優先、人が欲しがるものを創れているかの検証を素早く繰り返すこと。
- あれが足りない、これが足りないと機能追加するのでは無く、検証課題がクリアになる開発のみ優先的に行うこと。
- サービスが当たるかは分からん、時に技術的負債を生みつつも前に進む。
- iOSは当時はスピード優先でネイティブでは無く、Titaniumで開発をしていました。
- 2年後に負債の返済を行いました。
フリマアプリ勃興期
フリマアプリは驚くほどのスピードで成長していき、メルカリのようなスタートアップからサイバーエージェント、Yahoo、LINEなど大手のIT企業が続々と市場に参入してきます。
当時はサービスをスケールすることが大きな課題で、主にデータベースへの高負荷が悩みの種でした。
ボトルネックであったタイムラインの仕様を変えて再実装したり、AWSをVPC環境に移行させ、Amazon Aurora を導入したりなどインフラよりの仕事が多かったと記憶しています。
この間、iOSやAndroidの大きなリニューアルを何度か行ったり、テレビCMに向けたインフラ強化、ボルネック箇所のチューニング、RIDE という車両に特化したフリマアプリの新規事業開発など、新しいサービスの立ち上げなどもやっていました。
この時の教訓
- スタートアップの利点を活かして、開発スピードで絶対に大企業に負けないこと。
- 最も怖いのは大手では無く、同じように死に物狂いでやってくる他のスタートアップである。
- 目の前の小さいことでは無く、N倍スケールした時にどうなるかという視点で、開発も組織創りも行う。
- この時は女性限定サービスから男性向けにサービス解放、テレビCMの放映などを実施
- 採用（それもBigなHiring）や良い開発文化、組織のモメンタムを創り続けるのは創業者の仕事。それをやるためにもっと、権限委譲を早く適切に行うべきであった。
楽天へのExit
2016年に楽天グループ入りした後は、さらなるサービスの強化に向けて、 ログ基盤を整備したり、テレビCMの対策などが主でした。
この頃から、開発の仕事から徐々に離れて、全社採用や、評価制度の再設計、バックオフィス部門のマネジメントなど裏方の仕事が増えてきました。
開発はFablicには本当に優秀なメンバーが沢山いたので、安心して任せることができました。
後半は、新潟に新しくCSの拠点を立ち上げるため、新潟に出張し、オフィスビルの選定から、助成金の兼ね合いで県や市との折衝、オフィスインフラの整備など創業時は思いもしなかった仕事もすることになり、バリエーションも増えていきました。
そして、2018年に会社が楽天と合併し、新体制になったタイミングで、創業者としての役目を終わりにし、退任する決意をしました。 これからもラクマ（旧フリル）は楽天経済圏の力を活かしながら大きな資本力を背景に、もっと大きくなっていくでしょう。
この時の教訓
- 社員旅行はとても良かった。余裕があれば、全社員でいくことをオススメする。
- 子会社化した後も会社の文化を拠り所にして、採用を加速させることができた。
- 本質的でユーザーにとってより良い開発を行おうとする文化、透明度が高く、率直なコミュニケーションが行われる社風を創れたのは非常によかった。
- 楽天社は数字の達成意識が尋常じゃないほと高かった。開発組織が中心だと、売上などの数字感に弱くなりがちなので売上目標を達成するためのコミットは学ぶことが多かった。
総じて
たくさんのサービスが生まれては消えていく中、フリマアプリという沢山のユーザーに使ってもらえるサービスを創れたことは、1人のエンジニアとして嬉しくもあり、自信にもなりました。
フリマアプリ戦争という過渡期を過ごしたことは起業家として貴重な経験であり、 あのひり付くような、焼け焦げるような混沌と狂乱の中、サービスと会社を大きくするために情熱を傾けた日々を一生忘れないでしょう。
また、本当に自分達は良い仲間に恵まれたなと思います、プロダクトや会社について深く理解し、支えてくれた社員の皆には感謝してもしきれないです。
一方で、正直この7年で自分自身に至らないことも多く、様々な課題が見つかりました。
これから
また Fablic, inc の共同創業者である @shota @takejune と一緒にフリマアプリを超えるようなサービス、課題解決をしていこうと考えています。
今は ANGEL PORT というサービスを開発しています。 起業家でもあり、エンジェル投資家でもある、自分たちから見えた課題の解決と 若い起業家やスタートアップ業界に、自分たちがお世話になり、学んだことを少しでも返していけたらと思っています。
開発の経緯などはリリースノート に綴っていますので、興味があれば是非見てみて下さい。
また、ランチや飲みのお誘い、開発周りの相談等あればTwitterやFacebookまでお気軽にご連絡ください！
最後まで、長文にお付き合いいただきありがとうございました。
エンジェル投資家 リスクを大胆に取り巨額のリターンを得る人は何を見抜くのか
エンジェル投資家ジェイソン・カラカニスがエンジェル投資について記した著書
エンジェル投資について、書いた本はあんまりないのとジェイソン・カラカニスの人柄が分かるような、文体、構成がとても良かった。
ただ、日本とシリコンバレーでは環境が違う部分もあるので、これを読んだ人が、本にあるような実践をいきなりできるかでいうと難しいと思う。
- 投資資産が1億円以上ある
- 10件のシンジケート投資を行う
- etc...
具体的なエンジェル投資家としての活動内容、起業家とのミーティングにおける振る舞い
下記はカラカニスがメンタリング時に聞く質問
創業者に必ず聞く、4つの質問
- あなたは今どんな仕事をしていますか？
- あなたはなぜこれをやっているのですか？
- なぜ今なのか？
- あなたの不当なまでの優位性は何か？
シンジケートやプロラタなど、専門的な内容から、ブリッジラウンドを申し込んで来た起業家への接し方（評価額がなぜあがるのか？）
など、具体的かつ、エピソードも交えて書いてあるので、非常に面白かった。
※ エンジェル投資は高いリスクを伴うと随所に書いてあるが
特にTwitter の投資を見送って後悔したところなど、確かに140文字のテキストコミュニケーションプラットフォームが、あそこまで巨大になるとは思わなかっただろうなと思った。
だからこそ、カラカニスが記しているように、プロダクトや市場ではなく創業者に投資するというのは、自分もとても Agree でハングリーさに溢れた実践的な起業家に投資したいなと思う。
まだ、聞いてないですが、ジェイソン・カラカニスがPodcastもやってるようなので、聞いてみたいと思う。
自分が起業した時よりも、日本でもスタートアップをとりまく環境は変わって来ていて、エンジェル投資家と呼ばれる人たちの増加や、スタートアップを支援する環境が整って来たように思うし、これからも加速していると思うとそこにビジネスになるようなチャンスもあるのではと思う。
後日
縁あって、出版した本のイベントで来日していた、ジェイソンとランチする機会に恵まれた。 これはその時の2ショット（逆光...）、とてもエネルギッシュでユーモアに溢れた方でした。 日本の市場にもとても興味を持たれていたので、またお会いできると嬉しい。
構造化面接のススメ
以下は2017-12-22に会社（Fablic, inc.）の技術ブログinFablicに投稿した記事（http://in.fablic.co.jp/entry/2017/12/22/172546）になります。
inFablicが閉鎖され閲覧ができなくなってしまったため、会社の了承を取った上で転載しております。
元記事にリンクを貼っていただいていた方に対しては大変お手数ですが、こちらにリンクし直していただければ幸いです。
これは Fablic Advent Calendar 22日目の記事です。
こんにちは Fablic でCTOをしている @yutadayo です。
ここ1年程は採用や福利厚生、会社の制度設計に関わることが多く、エンジニアとしての人権は失いつつあるこの頃です。
みなさんの会社では面接はどのように行われているでしょうか？
面接の目的は 候補者の方がチームに加わった時に、どのぐらい力を発揮できるか予想すること にあると思います。
しかし、限られた時間の中で、候補者の方の人となりや能力を正しく測ることは困難を極めます。
あなたの会社では面接の担当者は決まっていますか？
候補者の方に質問する内容は同じですか？バラバラですか？
候補者の方々を全て同じ基準で判定していますか？
面接に仕組みがあれば、候補者と面接者双方にとって、よい体験になると思います。
今回は 採用 をテーマに Fablic が取り組んでいる構造化面接の紹介をしたいと思います。
Codenize.tools を使ったインフラ管理について
以下は2016-12-19に会社（Fablic, inc.）の技術ブログinFablicに投稿した記事（http://in.fablic.co.jp/entry/2016/12/19/123807）になります。
inFablicが閉鎖され閲覧ができなくなってしまったため、会社の了承を取った上で転載しております。
元記事にリンクを貼っていただいていた方に対しては大変お手数ですが、こちらにリンクし直していただければ幸いです。
この記事は Fablic Advent Calendar 19日目の記事です。
こんにちは、Fablicでサーバーサイドエンジニアをやっている yutadayo です。
今回は AWS の環境設定をコードで管理できる Codenize.tools の紹介と弊社での運用事例についてご紹介しようと思います。
続きを読むAmazon Auroraへの移行
以下は2016-04-27に会社（Fablic, inc.）の技術ブログinFablicに投稿した記事（http://in.fablic.co.jp/entry/2016/04/27/182453）になります。
inFablicが閉鎖され閲覧ができなくなってしまったため、会社の了承を取った上で転載しております。
元記事にリンクを貼っていただいていた方に対しては大変お手数ですが、こちらにリンクし直していただければ幸いです。
こんにちは、エンジニアの@yutadayoです。 Fablic が運営するフリルでは先日インフラをEC2-Classic環境からVPC環境に全面移行し、同時にリリース当時から使っていた Amazon RDS for MySQL から Amazon Aurora へと移行しました。
まず、移行して2ヶ月程度Auroraを運用した上での、良かった点と改善が必要な点を紹介します。
続きを読む