はじめに

34 歳のとき、勤めていた会社の経営が傾き早期退職を促されたのを契機に独立しました。その後、41 歳で Authleteオースリート社を設立しました。諸般の事情で現在も Authlete 社の代表取締役という肩書きを持っていますが、経営者的な仕事は他の人に任せ (参照: シリコンバレーのプロフェッショナル CEO を迎えて米国市場に挑戦する日本のスタートアップの話)、50 歳目前の現在もプログラマとしてコードを書き続けています。

Authlete 社設立 (2015 年 9 月) から 8 年半弱経過したものの、まだまだ小さな会社で道半ばであるため、起業家として何か語るのは時期尚早ではあるものの、軽い体調不良が長引く中、『自分のエンジニアとしてキャリアを振り返ろう！』という記事投稿キャンペーンを見かけ、生きているうちに子供世代のエンジニアの方々に何か書き残しておこうと思い、文章を書くことにしました。

過去にどこかで話したことを集めただけなのですが、思いのほかいろいろ話していたようで、長文になってしまいました。

起業にも種類がある

起業と言っても、人によって想像するものが異なります。例えば、次のようなものを起業と呼ぶことがあります。

副業をはじめる
フリーランサーとして独立する
枯れたビジネスモデルで個人会社を設立する
新規性のあるビジネスモデルや商材を武器に大きな成長を目指す会社を設立する

日本政策金融公庫総合研究所の『起業と起業意識に関する調査』(2023 年度調査) によれば、起業の動機は様々なので (下図参照)、どの起業形態が最適なのかは起業家によって異なります。例えば、被雇用者として安定収入を確保しつつ毎月数万円程度の副収入を得たい場合は副業を始めるのが最適解でしょうし、時間や場所、仕事の内容・量を調整しながら自由に働きたければフリーランサーとして独立するのが最適解となるでしょう。


日本政策金融公庫総合研究所の『2023年度起業と起業意識に関する調査』より抜粋

新規性ゆえにスタートアップ起業は難しい

個人的に興味があり、現在実際に取り組んでいるのが、「新規性のあるビジネスモデルや商材を武器に大きな成長を目指す会社を設立する」という形態の起業です。人によって定義は千差万別ですが、個人的には、この起業形態で設立された企業のことをスタートアップと呼んでいます。

スタートアップの難しい点は、その新規性ゆえ、次の事項が起業時点で不明なことです。

商材に十分な需要があるか
採算の取れる事業として成立するか
大きな市場があるか

そのため、ある程度『賭け』の要素があります。起業家本人はその賭けに勝算があると思って起業します。しかし、スタートアップに投資をおこなう投資家達の発言を聞けば、その賭けに勝つ確率はかなり低いことが分かります。

実際、私の周りにも志半ばで撤退したスタートアップの事例が幾つもあります。彼らが上手くいかなかった理由は様々ですが、論理的に考えれば回避可能であった失敗要因もあります。

この記事では、将来スタートアップを起業したいエンジニアの方々のために、私自身の経験を踏まえ、回避可能な失敗や、スタートアップが経験することになる出来事について、情報を共有したいと思います。

会社設立はできるだけ遅らせたほうがよい

「事業案を考え、資金を調達し、製品を開発し、顧客を獲得し、売上を得る」、という流れが、スタートアップの始め方だと世の中では思われています。しかし、ここに最初の罠が潜んでいると私は考えています。「資金を調達してから製品開発に着手する」というのが罠です。

売上があろうがなかろうが、人件費やオフィス賃料等の諸経費のせいで資金はどんどん減っていきます。そのため、次のように、事業が軌道に乗る前に資金が枯渇する恐れがあります。

製品完成前に資金枯渇
顧客獲得前に資金枯渇
黒字化前に資金枯渇

大学卒初任給の平均額に届かない月給 20 万円で労働者を確保できたとしても、5 人いれば、一年分の人件費だけで 1,200 万円かかります (20万 x 5人 x 12ヶ月) 。年収 1,000 万円のエンジニアを 10 人雇っていたら、一年分の人件費で 1 億円かかります。若い人からすれば千万円単位の資金は大金に見えるかもしれませんが、その程度のお金はあっという間に無くなってしまいます。

安定した事業を持つ企業で働いた経験しかないと、労働時間の対価として報酬が支払われるのは当然という感覚になってしまい、企業にとって人件費がどれだけ大きなコスト要因なのか、人件費を賄うための売上を作るのがどれだけ大変なのか、について想いを馳せることはないかもしれません。しかし、スタートアップ起業家はこれらを認識していなければなりません。

労働時間の対価として報酬支払いが可能なのは、労務提供を収益に変えることのできるビジネスモデルが確立されているからこそです。

例えば、レジ打ちバイトで労働時間に比例して報酬を得られるのは、既に店舗・商品・顧客が揃っているからです。一方、自宅の一室に個人用レジスターを用意してどれだけ高速・正確にレジ打ちしようが、一銭の報酬も得られません。

学生時代に会社を二つ起業した友人が私にくれた教訓は、「会社設立はできるだけ遅らせるべき。会社を設立すると、その時点からお金がどんどん減っていくから」というものでした。その本質は「資金を消費する活動を開始するのは可能な限り遅らせるべき」ということです。これにより、創業期に財務問題を抱えずに済みます。

このアドバイスに従い、私を含む Authlete 社共同創業者達は、会社設立と自分達への報酬支払い開始をできるだけ遅らせました。Authlete 社を法人登記したのは、最初の見込顧客から「契約したいので法人登記してください。決済の都合上、なるべく早く」と依頼されたタイミングでした。Authlete 社の設立日が 2015 年 9 月 18 日という中途半端な日になっているのはそのためです。また、自分達に報酬を払い始め、共同創業者以外の人達に作業をお願いし始めたのは、最初の資金調達 (1.4 億円; 2017 年 5 月に公表) が確定した後でした。実に、Authlete の活動を開始してから 3 年後のことです。

報酬支払い開始前まで、Authlete 社の共同創業者達は、昼間は本職で生活費を稼ぎながら夜中に製品開発をするという日々を過ごしていました。ダブルワーク状態で大変でしたが、おかげで Authlete 社は創業以来これまで、大きな財務問題を抱えたことがありません。

上記の方法により創業期の生存確率を上げることができます。しかし、これが唯一の正解というわけではありません。

起業家によっては、ビジネスモデルを考えるのを後回しにして、流行りのキーワード関連の事業に取り組む旨だけ宣言して太っ腹な投資家から数十億円の資金を調達し、その資金が枯渇する前に高速で幾つものビジネスモデルを考案して仮説検証を繰り返し、どれか一つでも大ヒットしたらラッキー、という考えで起業することがあります。短期間で大成功をおさめるのはそういうタイプの起業家かもしれません。

資金繰りの問題を抱え込むと、精神的に大きな負担となり、事業に集中できなくなってしまいます。創業前のダブルワーク状態は体力的にきついですが、創業後の資金繰り悪化による精神的苦痛よりはマシですので、製品開発前に小額の資金調達をするのではなく、製品開発後に資金調達をすることをお勧めします。製品があり、顧客もいるとなれば、企業評価額も上がるので、より良い条件で資金を調達することができます。

「良い事業案を思いついた。他の人が似たような事業を始める前に早く起業しないと！」と焦る人もいますが、その焦りは、その事業案に競争優位性がないことの裏返しでもあります。他の人よりも早く会社を設立したとしても、競争優位性がなければ後発の競合他社に負けてしまいます。事業を短期間で大きくする能力に特別に長けているのでもない限り、焦って起業しないほうがよいです。

資金調達の方法はいろいろある

スタートアップの活動資金を得る方法は幾つかあります。自己資金、金融機関からの借入れ、株式と交換での資金調達、といった方法です。

私の父 (故人) が 50 年ほど前に自分の会社を作ったときは、銀行からの融資 (借金) が主な資金調達方法でした。銀行がお金を貸す理由は、利子収入を得るためです。貸したお金は最終的に全て回収します。株式会社に貸し付ける場合でも、回収不能にならないよう、株式会社の代表者個人の財産を担保としておさえます。本来、株式会社の金銭的責任と代表者個人の金銭的責任は切り離されるべきと思いますが、当時の銀行融資の運用実態は個人財産を担保にとっていました。(現在の運用実態は知りません)

おかげさまで、40 年ほど元本返済と利子払いを続けたあと、死の数年前に負債を抱えた会社を父が清算したときには、父個人の土地と建物は全て持っていかれ、父は住む場所を失いました。「こんなに長い間頑張ってきた起業家の最後がこれなのかよ」とやるせない気持ちになりました。（不幸中の幸で、土地家屋売却後に少しお金が残ったので自己破産は免れることはできました)

上記のようなリスクがあると知れば、良い事業案を持っている人でも起業をためらってしまうでしょう。しかし、時代はかわり、現在はスタートアップエコシステムが出来上がっています。起業家は自社株と引き換えに、投資家から資金を得ることができます。会社がうまくいかず、清算することになったとしても、代表者が個人の財産を担保として差し出す必要はありません。

自己資金で必要なお金を全て賄えるならそれで良し。そうでなけば株式交換による資金調達がお勧めです。ただし、一時的に大きなお金が必要なもののすぐに返済できる見込みがあれば、株式交換よりも借金のほうが良いです。なぜなら、株式を手放さなくて済むからです。

Atlassian 社は自己資金だけで成長した企業の例として有名です。初めて外部資金を受け入れたときには ("Atlassian Closes $60 Million Investment from Accel Partners")、既に 225 名の従業員を抱える規模の企業で、利益も出していました。

誰から資金調達するか

株式交換で資金調達をおこなう場合、誰にお金を出してもらうかは重要です。

投資業を生業とする投資家にお金を出してもらうためには、自分の事業がいかに魅力的で将来性があるかを投資家にアピールしなければなりません。アピールがうまくいかなければ、投資家はお金を出してくれません。

一回目の資金調達時、私も十社前後投資家巡りをしました。投資家に Authlete の事業案を説明しましたが、なかなか理解してもらえませんでした。Authlete のアーキテクチャはエンジニアにとっても難解なので、無理もありません。

それでも何とか投資家に Authlete を理解してもらおうと説明手順を工夫しているうちに、世界で一番分かりやすい OAuth の説明手順が爆誕しました。同手順を説明した記事は 2017 年に Qiita に投稿された記事の中でランキング 1 位になっています。英語版の『The Simplest Guide To OAuth 2.0』も人気記事となっており、この記事を含めた英語ブログは海外顧客獲得にとって重要な役割を担っています。

投資家からお金を調達できない場合、親族・友人・知人から資金調達をしたいと思うかもしれません。彼らは起業家を応援したい気持ちがあり、事業案の良し悪しを判断する力もプロの投資家ほどにはないので、彼らからお金を引き出すことはそれほど難しくないかもしれません。

俗に、起業家本人 (Founder)、家族 (Family)、友人 (Friends) からの資金調達は 3F と言われます。しかし、親族・友人・知人から資金調達するのは下策であり、避けるべきです。というのは、起業が失敗に終わったとき、親族・友人・知人は拠出したお金を全て失うことになり、それが原因で彼らとの人間関係が壊れてしまうからです。彼らも資金拠出時にはリスクがあることを頭では理解していますが、いざ実際に拠出した資金が無に帰すと大きなショックを受けるからです。

プロの投資家は、投資先スタートアップが失敗するリスクも織り込み済みです。投資先スタートアップが失敗に終わっても「しかたないね」と割り切れます。また、起業家がベストを尽くしていたことを知っていれば、その起業家が再挑戦しようとしたときに再び投資をしてくれる可能性すらあります。

どの投資家からも投資をしてもらえない場合は、安易に親族・友人・知人から資金調達を試みず、かわりに事業案を練り直しましょう。

「誰もが上手くいかないと思っている事業案は、むしろそれだからこそ (挑戦しようと思う人が少ないからこそ) 成功する」と、まことしなやかに語られることがありますが、それが真となるのは極めて稀です。(Airbnb 社はその稀な例として有名です)

しかし現実は、誰もが上手くいかないと思った事業案は、案の定上手くいかないです。誰もが上手くいくと思った事業案でも、ほとんどは失敗し、成功するのはわずかです。

起業が上手くいかなかったとき、プロの投資家からのみの資金調達であれば、会社を清算し、再起を図ることができます。一方、親族・友人・知人から資金調達をしていた場合、会社を簡単に清算できません。なぜなら、会社清算は、彼らが拠出したお金が無に帰すことを確定させることになるからです。彼らとの人間関係を壊したくなければ、成功の望みが実質的に絶たれていても会社を存続させておく必要があり、この存続会社が再起の足枷になる恐れがあります。

いろいろな投資家がいる

悪徳投資家

世の中を知らない若い起業家を騙して、投資金と引き換えにスタートアップ企業の株式の大半を手に入れる悪徳投資家がいます。例えば、「あなた (起業家) のスタートアップの企業価値は現在 1,000 万円くらいだと思います。900 万円を投資しますので、株式の 90% は私、10% はあなたのものです。社長はあなたです。頑張ってください！」という具合に騙します。

悪徳投資家が一番悪いは間違いないのですが、株式の大半を初期投資で持っていかれてしまうことに疑問を感じない起業家にも問題があります。スタートアップ起業に関する下調べが余りにも足りないから騙されるわけで、自業自得とも言えます。

コーラルキャピタルという投資会社が毎月シードファイナンス勉強会を開催してくれているので、資金調達について学びたい方は参加してみるとよいでしょう。

コーラルキャピタル (旧 500 Startups Japan) は Authlete 社に投資しています。

アーリーステージの投資家

主に初期段階 (Early Stage) のスタートアップ企業に対して投資を行う投資家がいます。初期段階のスタートアップは、まともな売上がたっておらず、製品すら完成していない場合もあり、将来成功するのか失敗するのかを判断する材料に乏しいものです。そのため、この段階のスタートアップに投資する投資家には目利き力が必要です。投資をする側ではありますが、スタートアップ起業家と似た感覚の事業創出センスを同時に持ち合わせて、世の中のトレンドを把握し、事業案や創業チームの良し悪しを見極める力が求められます。

なお、資金調達活動時に起業家が出会う投資家全員が優れた投資家というわけではなく、次のような方々もいるので注意してください。(詳細を書くと投資家が特定されて物議を醸しかねないのでオブラートに包む)

【投資家１】スタートアップの EXIT 時 (上場か売却) の企業評価額にそれほど大きな金額を想定していない投資家は、低い企業評価額を提示してきます。大きな企業評価額にすると、「EXIT 時に得られるリターン $\div$ 投資金額」の倍率が低くなってしまうからです。そのため、シリコンバレーのスタートアップのような大きな EXIT を目指している起業家とは話が噛み合いません。お前らの夢、小っさ過ぎるな。
【投資家２】巨大企業が後ろ盾になっている投資会社の中には、スタートアップを自分で評価する能力が乏しいため、「似たような立場にある他の投資家が投資するなら同額を投資する」という行動をとる投資会社があります。そういう投資会社 A と話をすると「投資会社 B と C とは接触しましたか？彼らの判断はどうなっていますか？」と尋ねてきます。投資会社 B に行くと「投資会社 C と A の判断はどうなっていますか？」と質問されます。投資会社 C に行っても同様の質問をされます。お前ら、投資家気取りやめろ。
【投資家３】金融機関の融資部門出身者がスタートアップ投資を担当していると、初期段階のスタートアップに、何十何百もの質問を列挙したスプレッドシートを送りつけてきて回答を求めます。まだ売上もまともに立ってないスタートアップに、向こう 5 年間の成長予測 (詳細財務データ) の提出を求めます。零細企業・中小企業への融資の焦げつきを避けるための調査手法をスタートアップへの投資にも適用しようとしているのです。お前ら、融資部門に帰れ。
【投資家４】「製品は完成したものの資金が枯渇しそう」というタイミング、いわゆる死の谷にいるスタートアップに好んで投資をする投資家もいます。彼らは社会的意義があると思って誇りを持ってやっているようですが、起業家目線ですと、起業家の足元が見えるタイミングで (企業評価額を低く抑えられるタイミングで) 投資したいだけの投資家にしか見えません。お前ら、「そんな高い企業評価額で投資する人はいない」と上から目線で言ってくれたな。

お金に困ってから資金調達を始めると調達条件が悪くなるので、資金調達をする予定なのであれば早めに調達活動にとりかかりましょう。

Authlete 社の共同創業者の一人であるアリ・アドナンが豊富な資金調達経験を持っていたため (過去累計で 100 億円ほどの資金調達経験があったため)、Authlete 社の資金調達活動は冷静にできました。

レイターステージの投資家

主にある程度成長した段階 (Later Stage) のスタートアップを対象として投資をおこなう投資家もいます。

この段階のスタートアップには、製品があり、顧客がいて、売上があり、成長率等の数値データが累積されています。初期段階のスタートアップに比べると、将来成功するか失敗するかの判断材料が多く得られます。そのため、投資家には、目利き力よりも数値データを解釈する能力のほうが有用です。極論、目利き力がそれほどなくても、経営学関連の知識があれば投資判断はできます。(個人の感想です)

初期段階での投資に比べ、投資リスクは小さくなるものの、「リターン $\div$ 投資額」の倍率は小さくなります。そのため、かわりに大きな金額を投資します。

大きな金額を扱うせいか、自身の目利き力が高いと勘違いして、スタートアップ起業家に上から目線で「スタートアップのあるべき姿とは」などを得意気に語るレイターステージ投資家もいます。彼らは、「オフィスのレイアウトを見れば成功するスタートアップか失敗するスタートアップか判断できる。見るべきポイントは観葉植物の配置だ！」などといった相関関係皆無の話を真面目にします (実際に話した内容を書くと投資家が特定される恐れがあるのでこの発言は創作したものです)。もしもそういう投資家の熱弁を聞かなければならない状況になったら、適当に相槌を打ちながら聞き流しておいてください。反論して投資家と言い争う必要はありません。なぜなら、あなたのスタートアップは将来その投資家に投資をお願いすることになるかもしれないからです。

8 年ほど前、有名なレイターステージ投資家と雑談する機会がありました。Authlete のビジネスモデルを話したところ、「うまくいかなさそう」という反応でした。Stripe 社や Twillio 社を例に出し、開発者向け API を SaaS で提供するビジネスモデルは有望であると説明しましたが、「今、API、API と騒いでいる企業は全部失敗するだろう」と鰾膠(にべ)もありませんでした。Authlete のビジネスは、API エコノミーが今後日本にもやってくることを大前提としていたので、その投資家とは分かり合えないと思いました。

この会話の数ヶ月後、Twillio 社は株式上場し、取引初日に株価は約 2 倍になり、企業価値は約 24 億ドルに達しました。その後、API エコノミーが日本にもやってきたことは皆さんもご存知の通りです。

スタートアップの成長を助ける投資家

シリコンバレーでは昔からアクセラレーションプログラム (Acceleration Program) と称して、スタートアップ企業育成と初期投資をセットでおこなうエコシステムが構築されていました。Y Combinator (参考書籍:『Yコンビネーターシリコンバレー最強のスタートアップ養成スクール』) や 500 Global (旧 500 Startups) などが有名です。

シリコンバレーの 500 Startups (現 500 Global) の日本版としてスタートした 500 Startups Japan (現 Coral Capital) は、Authlete 社の一回目の資金調達ラウンドに参加してくれました。500 Startups Japan の共同設立者の澤山さんはエンジニアのバックグラウンドを持っているため、Authlete のビジネスモデルをすぐに理解してくれました。そして、「API エコノミーで Authlete は重要な役割を担うだろう」という判断の元、投資を即決してくれました。当時の 500 Startups Japan がおこなった投資判断の中でも最速かそれに近い判断だったと聞いています。

500 Startups Japan、現 Coral Capital は、シリコンバレーのスタートアップ・エコシステムをよく理解しており、それに倣っているので、投資先スタートアップに対して、資金面だけにとどまらない様々な支援を惜しまずおこなっています。日本最大のスタートアップキャリアフェアへと成長した『Startup Aquariam』も、彼らの支援活動の一環です。

今でこそ「ベンチャーキャピタルが投資先スタートアップ企業を様々な形で支援するのは当然」という雰囲気ができつつありますが、Coral Capital 登場以前は日本にそのような雰囲気はありませんでした。今後は、資金面以外の支援をしてくれない勝ち馬に乗りたいだけの投資家は淘汰されていくでしょう。というか、淘汰されろ。

起業家はどこで選択を誤るのか

自分自身の経験から学べる量には限りがあります。ですので、スタートアップ起業の先輩達の経験から学びましょう。

是非『起業家はどこで選択を誤るのか――スタートアップが必ず陥る9つのジレンマ』という書籍を一度読んでください。この本の内容を知っていれば、スタートアップ起業における既知の失敗パターンの多くを回避することができます。

たとえば、あなたが学生で、同級生の友達二人を誘って起業し、三人がそれぞれ CEO (最高経営責任者)、CTO (最高技術責任者)、CFO (最高財務責任者) という役職を持ち、株式は三人で均等に分ける (それぞれが約 33.3% の株を持つ) ことに決めたとしましょう。この場合、事業案の如何にかかわらず、あなたの起業は高い確率で失敗するでしょう。なぜなら、この時点であなたのスタートアップは既知の失敗パターンを幾つも抱えているからです。

Authlete 社のキックオフミーティングで、私は他の二人の共同創業者にこの本をプレゼントし、「この本に載っている既知の落とし穴は避けたい」と伝えました。『シリコンバレーのプロフェッショナル CEO を迎えて米国市場に挑戦する日本のスタートアップの話』の「CEO を空席にしていた理由」もご覧ください。

製品開発よりビジネスモデル考案の方が難しい

有能な人々でもスタートアップ起業に難儀している事例を見ると、製品やサービスを作ることよりも、事業として持続可能なビジネスモデルを考案することの方がよほど難易度が高いようです。持続可能なビジネスモデルを考案できない人は次のような問題を抱えているように見受けられます。

1. わずかでも価値があるものを提供できればビジネスになると思っている

「卵を割った時に殻が入らなくなる魔法」(『葬送のフリーレン』より) は、無価値ではないですが、事業化するには余りに価値が小さ過ぎます。「その価値に誰が幾ら払うのか」を思考実験すれば、事業化が無理なことはすぐに分かりそうなものですが、実際にかなりの年月を費やして試して失敗するまで分からない人もいます。

また、人々は善意や正義感、自己顕示欲や趣味の一環など、様々な理由で、良いものを無償で提供することがあります。自社製品の価値がそれらを下回ったり、大差なければ、ビジネスとして成立しません。

2. 売上が少しでも立てばビジネスになると思っている

原価を上回る販売価格で購入してくれる客がいても、単価が安過ぎるか販売数が少な過ぎると、経費 (特に人件費) を賄えず、ビジネスとして成立しません。

3. ミクロ経済学を学んでいないか完全に忘れている

人々の消費行動に関する基礎的な知識が欠けています。たとえば、直接の競合ではなくても、Good Enough な代替財 (つまり Best ではなくとも価格や入手容易性等を考慮すれば『十分に良い』代替財) が自社製品の競合になることを考慮できていません。

世の中には、傍(はた)から見ればすぐに「ビジネスとして成立しない」と分かる事業案ばかり思いついては、試して上手くいかず、やむなくピボット (事業変更) する、という繰り返しから抜け出せない人もいます。このような人は、個々の事業案ではなく、事業案を考える思考手順を見直す必要があります。

ソフトウェアライブラリは事業として成立しない

例えばあなたが、使い勝手の良いソフトウェアライブラリを世界最高レベルの品質で書きあげたとしましょう。そのライブラリに価値があることは間違いありません。しかし、そのライブラリのライセンス販売は、次のような理由から事業として成り立たないでしょう。

見込み顧客 (開発者) は、品質は良くないが無償のオープンソース実装を代替品として使うかもしれないし、自作を試みるかもしれない。
安ければ買う人もいるだろうが、事業として成立させるほどの継続的大量販売を見込めそうもない。

代替の効かない特許を含んでいるのであれば話は変わってきますが、そうでもない限り、一般的に、一度インストールしてしまえば用が済んでしまう (初回購入時しか売上の立たない) ソフトウェアライブラリは事業として成立しません。20 年前ならいざしらず、サブスクリプション型 (定期購入型) のビジネスモデルが隆盛の今となってはなおさらです。

私が Authlete 本体のソースコードは非公開としている一方で、SD-JWT 用の Java ライブラリ (authlete/sd-jwt) や CBOR/COSE 用の Java ライブラリ (authlete/cbor) をオープンソースで無償公開しているのは、これらのライセンス販売は事業として成立しないと分かっているからです。当該 CBOR ライブラリは、世界最高レベルの品質で、使い勝手も良く、ドキュメントも整備されていますが、それでも事業としては成立しません。

なお、これらのライブラリは Authlete 本体で利用することを主目的として開発しました。考え方によっては、Authlete のソースコードの一部を無償公開しているとも言えます。

この CBOR ライブラリの最初のコミット (78 ファイル、合計 9,952 行) の設計・実装は 6 日間で仕上げました。

CBOR (Concise Binary Object Representation; RFC 8949)、完全に理解した！https://t.co/Yv8Csui4uo

諸般の事情(OpenID for Verfiable Credential IssuanceのCWT Proof)のため、6日間という短期間でCBORライブラリの設計・実装・リリースを一人で敢行...(吐血)
— Taka@Authlete, BaaS for OAuth 2.0 & OpenID Connect (@darutk) May 21, 2023

オープンソース化は銀の弾丸ではない

オープンソースとすることで巨大なエコシステムの構築に成功している事例が存在するため (例: Linux)、自社製品をオープンソースにすることを戦略の核に据えるスタートアップもいますが、オープンソース化は銀の弾丸ではありません。いろいろ条件が揃わない限り、かえって悪手となります。

5 年ほど前、無償のオープンソースソフトウェアを実行するサーバを有償のマネージドサービスとして提供するクラウドベンダーに、オープンソース開発元が反発するというニュースが話題になりました。

オープンソースの開発元は、(無償利用可能としているので) ソフトウェア自体の対価は得られませんが、次のようなサービスを提供することでビジネスをおこなっていました。

導入支援や不具合修正などのサポート
新規機能の受託開発
当該ソフトウェアを実行するサーバの運用

しかし、巨大クラウドベンダーがマネージドサービス (サーバの運用) を大々的に提供しはじめたせいで、開発元のビジネスが大きく侵食されるようになってしまいました。

「製品を開発しているのは我々なのに利益を得ているのはクラウドベンダー」という状況に開発元が納得いかない気持ちは分かります。しかしながら、「自分たちだって、オープンソース開発者達をやりがい搾取で無償労働させてきたではないか」と私は思うわけです。また、当該オープンソースソフトウェアの開発に携わっている開発者のほとんどが自社社員だとしても (= 実質的にその企業が自費で開発をおこなっているのだとしても)、「ビジネスモデルも考えずに安易にオープンソース化して無償利用を許した判断が愚かだった」という感想しかないわけです。

私のいる業界内でも、オープンソース化が事業にとってプラスになっていない事例は幾つもあります。

【事例１】OpenID プロバイダの実装として良い品質のオープンソース実装がありました。主要開発者達はしばらくして、その実装のサポートとマネージドサービスを提供する会社を立ち上げました。しかし最近では、増え続ける関連標準仕様群に追随する気力を失ってしまいました。製品自体が良くても、ビジネスモデルが良くなければ、労力と専門性に見合う収益を得られず、事業を継続する気力を失ってしまいます。
【事例２】製品自体はかなり良いものの、業績が伸び悩んでいた企業が自社製品をオープンソース化しました。しかし、オープンソース化は起爆剤とはならず、自社製品の最大の競合製品は無償版の自社製品という (わりとありがちな) 難しい状況を生み出しただけでした。その後、企業転売を生業とするプライベートエクイティ (Private Equity) に株式の大半を握られ、独立を失いました。
【事例３】オープンソースとして提供していたものの、タダ乗りでビジネスをしている他社の活動が気に食わなくなり、途中でクローズドソースに変更した企業があります。この決定に反発したオープンソース開発者達は、ライセンス変更前のソースコードから分岐をおこない、当該企業が提供する製品とは異なるオープンソース版の開発を始めました。

ビジネスモデル考案時の考慮事項

ここでは、ビジネスモデル考案時の考慮事項を幾つか取り上げたいと思います。なお、ここに書かれたことが必ずしも正しいとは限りません。成功の定義は人それぞれで、成功に到達する手法も幾つもあり、それらの手法が相反することもよくあるからです。

一般消費者向け事業か法人向け事業か

一般消費者 (Consumer) を相手に事業をおこなうか、法人 (Business) を相手に事業をおこなうか、という選択があります。前者は BtoC (Business to Consumer)、後者は BtoB (Business to Business) と呼ばれます。下記の表は、私が考えるそれぞれのメリットとデメリットです。

項目	一般消費者向け事業	法人向け事業
企業成長速度	当たれば急成長	ゆっくり
顧客単価	低い	高い
顧客獲得速度	バズれば一瞬	ゆっくり
事業の安定性	流行り廃りに左右される	堅実
顧客サポート	問い合わせが多い。クレーマー対応がつらい。	祝祭日・深夜の緊急対応を求められることがある。

短期間での爆発的急成長に挑戦したければ一般消費者向け事業、堅実にやりたければ法人向け事業、というのが私の見立てで、堅実な選択肢を選びがちな私は法人向け事業を選択しました。

ただし、法人向け事業で急成長しているスタートアップも実在しており (SmartHR 社など)、こうなると本当に強いです。急速に顧客を獲得できる法人向け事業を考案できれば一番いいのかもしれません。

一般的に、お金儲けをしたい人はそのために必要なモノ・サービスには対価を払うので、このような人達を対象とした商売ではビジネスモデルが素直で、売上を立てやすいです。株取引で儲けようとしている人は手数料を払ってくれますし、営利企業も必要経費を払ってくれます。これが、法人向け事業が手堅い理由です。

一方、一般消費者は、必ずしもモノ・サービスに対価を喜んで払ってくれるわけではありません。そのため、運営コストがかかっているにも関わらずサービスの対価を利用者に求めることができないことも多く、こういう場合、広告の仕組みを作りこんで広告主から広告掲載料を取るというビジネスモデルを構築することになります。広告主を集めるためには、十分な数の利用者を獲得する必要があります。

個人的には、YouTube や Instagram のように大量の利用者を獲得する野心と計画がない限り、初めから広告前提のビジネスモデルを志向するのは下策だと思っています。大量の利用者から直接対価を得られるビジネスモデルを考案できるのであれば、それに越したことはありません。

複製販売かサブスクリプションか

十数年ほど前まで、ソフトウェアの販売は、元となるソフトウェアの複製を個々の購入者に届ける形で行っていました。購入者は、複製入手時に代金を一度だけ支払っていました。

近年では、サーバ側に Web アプリケーションの形でソフトウェアを置いておき、利用者にサーバにアクセスしてもらう SaaS (Software as a Service) という形態が主流となっています。利用者はソフトウェアを利用している期間中は継続して利用料金を支払います。このような販売形態はサブスクリプション型 (定期購入型) と呼ばれます。

次のようなメリットがあるので、これからの時代、スケールする (規模拡大しやすい) ビジネスモデルを考案したければサブスクリプション型一択です。

ソフトウェアの複製を個々の購入者に届ける手間とコストが不要である。
不具合修正や機能追加などためのソフトウェア更新をすぐに反映できる。
売上予測を立てやすい。
利用状況を把握できる。
利用者とのコミュニケーションを継続的にとりやすい。

開発者向け事業

BtoB のビジネスモデルの中でも、開発者 (Developer) を対象にサービスを提供するものは BtoD (Business to Developer) と呼ばれます。また、BtoD と SaaS を組み合わせたビジネスモデルは BtoD SaaS と呼ばれます。

BtoD、特に BtoD SaaS は、一つの成功パターンと言っても良いでしょう。Stripe 社は BtoD SaaS の大成功事例です。

シリコンバレーには BtoD スタートアップへの投資に特化している Heavybit というファンドがあります。

私が初めて Heavybit を訪問したのは 2015 年 11 月頃でした。「BtoD であれば、開発者コミュニティ内のインフルエンサーに認知してもらい、好意的なコメントを発信してもらうことが重要。まずはそれを目指すこと」というアドバイスをもらいました。

しかしながら、BtoD には注意すべき点があります。それは、開発者の方々に「この程度のものは自作できる」と思われてしまうとビジネスにならない、ということです。そのため、提供するサービスは技術的にかなり高度であったり、作るのにかなりの労力がかかったり、資本集約的だったりする必要があります。

BtoD 事業を始めるには技術力に自信が必要です。

自信を持つキッカケはエンジニアそれぞれだと思います。私の場合、Java で書かれたオープンソースの WebSocket クライアントライブラリが (GitHub で Star がたくさんついているのに) どれも○ソで、しかたなく自作したところ、営利企業が書いたものより良いものができて、「世界はこの程度か」と思ったことがキッカケです。

RFC 7692 (Compression Extensions for WebSocket) サポートのために DEFLATE (RFC 1951) 圧縮を解凍するコードも書きましたが (DeflateDecompressor.java, DeflateUtil.java)、これなんか、いつか見た C# で書かれた GNU ライブラリのコードより読みやすくて美しいんですよ (自賛)。

余談ですが、GitHub の Star の数の多さはコード品質の高さを保証しません。「オープンソースで多くの人に使ってもらっているならコード品質も高いはず」という幻想は、(30 年ほど前の) 学生時代に画像ビューワ xv のソースコード (xv.c) を見て、早々に崩れ去りました。「こんなに長い main 関数、よく書けるな (褒めてない)」、と。

イノベーションのジレンマ

『イノベーションのジレンマ』という書籍をご存知でしょうか。経営学を学ぶ人は避けて通れない名著です。

この本は「優良大企業はすぐれた経営をするがゆえに破壊的技術の登場で新興企業に負ける」ということを解き明かしています。逆に言えば、この本には新規事業を考える際のヒントが書かれていると言えます。

この本は、破壊的技術には次の五つの原則があると述べています。

【原則１】企業は顧客と投資家に資源を依存している。→ 優良大企業は、顕在していない顧客ニーズに投資しない。
【原則２】小規模な市場では大企業の成長ニーズを解決できない。→ 優良大企業は、小さい市場に参入してこない。
【原則３】存在しない市場は分析できない。→ 優良大企業は、未知の市場に参入してこない。
【原則４】組織の能力は無能力の決定的要因になる。→ 既存事業に最適化された優良大企業の組織構造は新規事業の障害となる。
【原則５】技術の供給は市場の需要と等しいとは限らない。→ 優良大企業は、既存製品を過剰改良し、低位市場を失う。

これらを踏まえると、新規事業を考案するときは、「顕在化していない顧客ニーズ、大企業が参入してこない (今はまだ) 小さな市場、成長予測が難しい市場」が狙い目と言えます。

大企業で新規事業開発を担当することになった方へのアドバイスです。

所属企業のプロジェクト承認プロセスは、すぐれているがゆえに、上記のようなプロジェクトを却下するようにできていることに注意してください。
将来の市場規模や売上予想を尋ねられたら「分かりません(ｷﾘｯ」と答えておけばよいです。そうしないと話が進みません。

自社が世界一になれるのは何か？

『ビジョナリー・カンパニー 2 - 飛躍の法則』という書籍も必読です。私もこの本は何度も読み返しています。

この本は、良い企業から偉大な企業へと変貌 (Good to Great) を成し遂げることができた企業と、その変貌を成し遂げられずに凡庸にとどまった企業とを比較し、その変貌に何が決定的に重要だったのかを明らかにしています。

この本に書かれている、「情熱をもって取り組めるもの、自社が世界一になれる部分、経済的原動力になるもの、が重なるところに集中して取り組むべき」という話は、事業案を考案する際も重要です。

好きなことでも得意でなければ事業化できず、得意なことでもマネタイズ (収益化) する方法がなければ事業化できず、マネタイズ方法を考案できても興味がなければ事業を始めたり続けたりすることはできません。いや、事業化は可能でしょう。しかしそれは凡百の事業となるでしょう。

何の競争優位性もないのに、後発でレッドオーシャンに飛び込むべきではありません。それをやるのは「成長市場の分け前にあずかる」というつまらないビジネスモデルを追求するつまらない者達だけです。

決済サービス『○○Pay』の事業案に対してコメントを求められたことがあったので、「競争優位性は何ですか？」と質問したところ、「手数料が安い」との回答だったので、この事業は失敗するだろうと思いました。案の定、その事業は数年後に畳まれました。既存製品の $ 1/100 $ の価格、のような劇的な低価格でもない限り、価格勝負ありきの事業案は始める前から失敗が約束されています。

大企業で新規事業開発を担当することになった方へのアドバイスです。

所属企業の現在の中核事業が、世界一になれる部分であるとは限りません。逆に、世界一になれる部分は、その時点で従事していない事業かもしれません。
そのため、所属企業の中核事業とシナジーのある新規事業が正解とは限りません。むしろ、中核事業と競合する破壊的技術にこそヒントがあります。

「世界一になれる部分はどこか（同様に重要な点として、世界一になれない部分はどこか）」という問いに対する答えは、それほど自明ではありません。自分を見つめ直す必要があります。

Authlete 社は OAuth 2.0 や OpenID Connect に関連する仕様群の実装を SaaS として提供しています。現在では「最新の世界標準仕様を最も早く実装する企業」として業界でも有名になっています。では、『OAuth 2.0 / OpenID Connect の専門知識』が、自分たちが世界一になれる部分だと思って Authlete 社を起業したのかというと、そうではありません。我々が「これは世界で戦えるレベルにある」と自覚した部分は、「再利用可能なソフトウェアを高品質に設計・実装する能力」です。加えて「実装する速度が驚異的に速い」という自覚もありました。OAuth 2.0 と OpenID Connect は適度に複雑で、また、仕様で詳細が決められておらず実装者任せになっている部分が多いため、設計・実装で勝負する者にとっては良い題材でした。

2022 年末に開催した Authlete Customer and Partner Meetup 2022 のデジタルコンストラクションセッションに登壇してくださった EARTHBRAIN 社様は、Authlete 社に JWT 認可グラントの実装を依頼したところ 5 日間で実装完了し驚いた、とおっしゃっていました。(参照: Authlete 社と機能追加を議論)

2023 年末に開催した Authlete Customer and Partner Meetup 2023 の際に日経新聞社からご要望いただいた機能は、2 日後に実装完了しました。

日本経済新聞社様 (@nikkeideveloper) から、イベント当日に壇上でご要望いただいた「/auth/authorization APIから発行されるチケットに任意のデータを紐付ける機能」ですが、実装完了しました。既存APIにパラメータを追加したほか、/auth/authorization/ticket/{info|update} APIを新設しました。 https://t.co/elqC4XKSvG
— Taka@Authlete, BaaS for OAuth 2.0 & OpenID Connect (@darutk) December 14, 2023

Authlete のアーキテクチャは、後に業界の専門家であるジャスティン・リッチャーにより『Semi-Hosted Service Pattern』と名付けられました (参考: Deployment and Hosting Patterns in OAuth)。このアーキテクチャは Authlete の大きな差別化要因となっており、ユースケースによっては唯一の解となります。実際に Authlete 社の顧客である DPG Media 社 (ベルギー) を 2018 年に訪問したとき、先方のエンジニアの方々は「Authlete 以外に選択肢がなかった」とおっしゃっていました。(参考: ケーススタディ, EIC 2023 パネルディスカッション)

オランダ語圏最大のメディアグループ De Persgroep (現 DPG Media) の開発拠点を訪問したのが 2018 年 10 月。先方の技術チームに「世界中探したけど我々の要件を満たす製品は Authlete しかなかった」と言ってもらえたのは自信になりましたね。それ以降、今も #Authlete を愛用してくださっています。 https://t.co/MJs5IqOZT4 pic.twitter.com/Ste5HceP7k
— Taka@Authlete, BaaS for OAuth 2.0 & OpenID Connect (@darutk) June 11, 2021

OAuth 2.0 と OpenID Connect の関連仕様は公開されており、実装するのにライセンス料金を払う必要もないので、誰でも自由に実装できます。そのため、これらの仕様を実装したオープンソースの認可サーバ / OpenID プロバイダは幾つも存在します。しかしながら、漠然と実装したところで、事業にはなりません。

「仕様が決まっているのなら誰が実装しても同じ」と発言する人に何度か会ったことがありますが、彼らとは一生分かり合えそうもありません。こういう認識の人が社内の重要なポジションに就いている会社で働くエンジニアの方々には同情します。

映画『マトリックス』(1999) の名言に「道を知っていることと実際に歩くことは違う (there's a difference between knowing the path and walking the path)」とあります。それと同じで「仕様を知っていることと実際に実装することは違う」のです。

過去に、とあるオープンソース実装の品質が悪いと注意を促す投稿をしたところ、反論されたことがありますが、あのコードを見て品質の悪さが分からないようでは、エンジニアとして（以下自粛

とはいえ、かくいう私も、プログラミングを学びたての頃は、コンパイルを通したり、期待した動作をさせることで精一杯で、コードの良し悪しは分かりませんでした。データ構造とアルゴリズム、デザインパターンを学び、良い設計・実装のコードを読む (重要) ことで、どういうコードが良いコードなのか分かってきます。

自分を振り返り、他者は上手くできないが自分は簡単にできること、を探してみてください。それが、あなたが世界一になれる部分かもしれません。

Authlete ビジネスモデル考案に至るまでの思考過程

「(一見事業化が難しそうな) Authlete のビジネスモデルでよく起業しようと思いましたね」と、今でも言われることがあります。ここでは、参考として Authlete ビジネスモデル考案に至るまでに私が何を考えたかを順に振り返りたいと思います。

	考えたこと
1	成功パターンの BtoD SaaS でビジネスしよう。
2	フロントエンドを作るのは面倒なので、Web API だけを提供したい。
3	Web API を保護するのに OAuth 2.0 を実装したほうがよさそう。
4	つまり、OAuth 2.0 に準拠する認可サーバを用意しなければならない。
5	認可サーバのオープンソース実装を探したが、どれもイマイチ。
6	しょうがないので認可サーバを自作するか。
7	まずは、OAuth 2.0 ライブラリをオープンソースで作ろう。
8	むむ。このライブラリ、薄いラッパーにしかならず、認可サーバの実装はたいして楽にならない。
9	認可サーバの実装を楽にするには、どういう仕組みがあればいいのだろうか？
10	(しばらく思考実験)
11	結論:「ライブラリは、プロトコル処理のロジックを内包すべきであり (部品だけ提供してロジックは開発者に書かせるというアプローチにはほとんど価値がない)、認可サーバとクライアントアプリの設定情報や生成したトークン群を保持する永続記憶領域を持つべきである」
12	しかし、永続記憶領域にはコストがかかる。使用するときにコストがかかるオープンソースライブラリなど、誰が使うというのか？
13	(設計は良いが、コストがなぁ... としばらく悩む)
14	見方を変えると、永続記憶領域のコストは開発者が料金を払う正当な理由となるので、これはビジネスになるのでは？
15	元々考えていた事業案よりも良さそうだから、こちらの案の事業化を検討しよう。

上表のように思考を進めた結果、「OAuth 2.0 / OpenID Connect のプロトコルの処理とトークン管理の機能を全て Web API として提供するサービス」である Authlete が生まれました。

競合 (無償のオープンソースの実装を含む) が認可サーバの実装を提供しているのに対し、Authlete 社は、認可サーバの実装そのものではなく、認可サーバの実装に必要な機能を Web API として提供しています。そのため、Authlete の顧客は自ら認可サーバを実装しなければなりません。顧客に開発負担がかかるのですが、それでも Authlete が選ばれるのは、次のようなメリットがあるからです。

	メリット
1	顧客が好きな技術スタックを使える。たとえば次の技術要素は顧客が自由に選べます。ユーザ認証ユーザ管理 API 管理開発言語 Web フレームワーククラウドサービス
2	ユーザデータを完全に制御下に置ける。ベンダーのサーバにユーザデータをアップロードする必要がない。ユーザデータ保護に関する各種の法規制に準拠しやすい。
3	エンドユーザとやりとりするサーバ群を完全に制御下に置ける。ユーザ認証の際に OAuth 2.0 / OpenID Connect のベンダーのウェブサイトに飛ばなくてよい。結果、企業ブランドの一貫性を保てる。
4	良いシステム設計が強制される。

典型的な OAuth 2.0 / OpenID Connect の実装は、ユーザ認証機能やユーザ管理機能を抱え込みます。一方、Authlete は慎重な設計の結果、これらを OAuth 2.0 / OpenID Connect の実装から完全に切り離すことに成功しました。先ほど言及した Semi-Hosted Service Pattern に加え、ユーザ認証/ユーザ管理を切り離していることも大きな差別化要因となっています。

周辺事業進出が悪手になる場合もある

数年前に日本円換算で十数億円の資金調達をし、勢いがあるように見えていた競合企業が、昨年末にかなりの人員を解雇し、今年に入り他企業に買収されて独立を失いました。解雇された人の話によると、製品に新機能を追加した結果、大企業と競合関係になってしまい、製品を売るのが難しくなり、事業が行き詰まってしまったそうです。

「ユーザ認証/ユーザ管理の機能も追加してはどうか？」と過去に何度か社内で提案されたことがありましたが、私は都度拒否してきました。理由は、(1) ユーザ認証/ユーザ管理の分野で競争力のある製品を提供できる見込みがなく、また、(2) ユーザ認証/ユーザ管理のソリューションを提供する企業と競合関係になりたくない、からです。

Authlete よりも多くの機能を含むトータルパッケージソリューションが、逆に Authlete よりも単価が安くなる、という不思議な現象も市場では観察されています。

トータルパッケージソリューションを求める顧客層は二極化しているのではないか、というのが私の見立てです。予算が豊富で金に糸目をつけない大企業と、予算も限られ自社の技術チームも貧弱な企業です。後者は、「箱から出したらすぐ動き、全部入りで、とにかく安い」ソリューションを求めています。後者の層の企業群に対して薄利多売をしていると、顧客対応コストの高さに体力を奪われてしまいます。

Verifiable Credential (検証可能な資格情報) の分野で Authlete 社が発行者の機能を提供する一方で、敢えてウォレットの実装に踏み込まないのは、ウォレット提供によるビジネスモデルが描けないという理由もありますが、ウォレットベンダーと協業したいという考えもあります。実際、海外のウォレットベンダーを通じて、自力では到達できない事業機会を紹介してもらっています。

エンジニアとして起業に備えよう

再利用可能なソフトウェアを書けるかどうかはプログラマの人生を大きく左右します。

あるウェブサイトのために決済システムを構築する必要があったとしましょう。再利用可能なソフトウェアを書くスキルを持たないソフトウェアエンジニアであれば、その決済システム構築を単発の受託開発案件として請け負い、数百万円の売上を手にするかもしれません。一方、再利用可能なソフトウェアを書くスキルを持つ野心的なソフトウェアエンジニアは、起業し、決済システムを再利用可能な Web サービスとして構築し、莫大な富を得るかもしれません。

オンライン決済の仕組みを SaaS として構築することに成功した Stripe 社は、2023 年 3 月 15 日、「500 億ドル (470 億ユーロ) の評価額で、65 億ドル (61 億 5,000 万ユーロ) を超えるシリーズ I の資金調達契約を締結」したことを公表しました。500 億ドルというと、当時の為替レート (1 ドル = 133 円) 換算で 6 兆 6 千 5 百億円に達します。Stripe 社は、世の中の役に立つサービスを提供し、8 千人の雇用を生み出すという、社会的に意義のある活動をした上で、創業者は大きな富を得ています。このように、再利用可能なソフトウェアを書くスキルは、プログラマの働き方や収入を左右します。

アプリやシステムなどの一品物のソフトウェアを書くスキルと、ライブラリやフレームワークなどの再利用可能なソフトウェアを書くスキルは、かなり異なることに注意してください。前者が得意でも、必ずしも後者が得意とは限りません。

実際の失敗事例を近くで見る機会がありました。人の目を魅く UI/UX を開発する稀有な能力を武器にスケールするビジネスを夢見て起業したソフトウェアエンジニアがいましたが、再利用可能なソフトウェアを書く能力が絶望的に欠落していたため、単発のプロトタイプ受託開発を続けることでしか売上を得ることができず、最終的に彼のチームは解散しました。それなりに長いプログラミング経験を持つそのエンジニアにアドバイスをしましたが、「昔からこの書き方でソフトウェアを書いている（今更変えられない）」という返答でした。経験年数が長いからといって、再利用可能なソフトウェアを書くスキルが自然と身に付くわけではないのです。

データ構造とアルゴリズム、デザインパターンを学び、良い設計・実装のコードを読む (重要) ことで、再利用可能なソフトウェアを書くスキルを身につけ、将来の起業に備えましょう。

個人的には、次の三つから再利用可能なソフトウェアの設計・実装について多くのことを学ぶことができました。

Unix 仮想ファイルシステム
Linux カーネルドライバ
Java 仮想マシン (CDC/PBP のリファレンス実装)

おわりに

5 年ほど前に『FINOLAB イノベータ養成プログラム 2019』に講師として招かれ、『テクノロジー・ドリブンのビジネス開発』という題目で講義をおこないました。講義の内容は本記事の内容と近いので、ご興味があればご覧ください。

長文を読んでくださり、ありがとうございました。

	メリット
1	顧客が好きな技術スタックを使える。たとえば次の技術要素は顧客が自由に選べます。ユーザ認証ユーザ管理 API 管理開発言語 Web フレームワーククラウドサービス
2	ユーザデータを完全に制御下に置ける。ベンダーのサーバにユーザデータをアップロードする必要がない。ユーザデータ保護に関する各種の法規制に準拠しやすい。
3	エンドユーザとやりとりするサーバ群を完全に制御下に置ける。ユーザ認証の際に OAuth 2.0 / OpenID Connect のベンダーのウェブサイトに飛ばなくてよい。結果、企業ブランドの一貫性を保てる。
4	良いシステム設計が強制される。