Financial APIs Workshop の紹介

2018 年 7 月 24 日(火)、東京金融ビレッジにおいて『Financial APIs Workshop』が開催される。これは、二日間にわたって開催される『Japan/UK Open Banking and APIs Summit 2018』の一日目にあたり、エンジニア向けのイベントである。

 

1. 英国オープンバンキングの仕様スタック

近年、金融業界では『銀行 API』の実装が進められている。そのセキュリティーのため、OAuth(オーオース)という技術に注目が集まっている。銀行のシステムが OAuth をサポートしていれば、サードパーティー製アプリケーションが銀行システムと連携する際、ユーザーは、(1)自分の銀行アカウントの ID とパスワードをアプリケーションに渡すことなく、(2)必要最小限の権限のみを(3)限られた期間だけアプリケーションに与える、という承認処理を、自らの判断でおこなえるようになる。一度与えた承認を後から取り消すこともできる。OAuth のこれらの特徴により、万が一当該アプリケーションが悪意のあるアプリケーションであったとしても、被害を最小限におさえることができる。(参考:『一番分かりやすい OAuth の説明』)

銀行 API については、英国金融業界が世界の最先端を走っている。英国では、政府主導のもと、英国上位9行を中心とする Open Banking Implementation EntityOBIE)という団体が設立された。当団体は銀行 API通化の議論をおこない、OAuth 2.0 の採用を決定した。

さらに OBIE は、より高いセキュリティーを求め、OAuth 2.0 に加えて、Financial-grade API、通称 FAPI(ファピ)、の採用も決定した。FAPI は、OpenID FoundationFAPI ワーキンググループが策定作業を進めている仕様で、OAuth 2.0 / OpenID Connect という基盤の上に、金融業界による使用にも耐えうる高いセキュリティー要求事項を定義している。

そして、OBIE は、OAuth 2.0、OpenID Connect、FAPI という仕様スタックの上に、英国オープンバンキングの独自仕様である Open Banking ProfileOBP)を策定した。

ここまでに登場した組織名と仕様名の関係を下図にまとめる。

f:id:TakahikoKawasaki:20180717023328p:plain

 

2. FAPI の汎用性と名称変更

当初、金融業界への適用を想定して仕様策定作業が進められていた FAPI であるが、5 つのパートで構成される仕様のうち、高度なセキュリティー要件を定める Part 1Part 2 は、業界を問わず利用可能であることに皆が気付き始めた。実際に金融業界以外からの問い合わせも増えてきたことから、仕様の名称を変更することになった。

幾つかの案が提示されたが、最終的には、Financial API(旧名称)から Financial-grade API(新名称)への変更に落ち着いた。工藤達雄氏による『Financial-grade Access Protection Interoperability』という案が元になっている。(参考:Renaming FAPI

 

3. FAPI & OBP コンフォーマンステストスイート

共通仕様を策定しても、解釈ミスや実装ミスにより互換性が損なわれていては意味がない。OBIE は、FAPI および OBP のコンフォーマンステストスイートを必要としていた。

当初、ある企業がコンフォーマンステストスイートを受託開発していた。しかし、諸般の事情で当企業は開発を完了させることができず、開発中断を OBIE に申し出ることとなった。この事態に対処するため、新たに設立された会社が FinTechLabs.io 社(企業番号:10907533、代表:アリ・アドナン)である。

この FinTechLabs 社が、今回のイベント『Japan/UK Open Banking and APIs Summit 2018』の主催者である。

FAPI & OBP コンフォーマンステストスイートを開発するにあたり、既存の OpenID Certification テストのソースコードをベースにするべきだと、業界関係者の一部から強い意見が出された。しかし、既存コードのアーキテクチャーは良くなく、基盤とするには適さなかったため、丁寧な説得により合意を得た上で、コンフォーマンステストはゼロから実装されることになった。

この再設計が功を奏し、現在では、当該テストは、米国 ONC(Office of the National Coordinator for Health Information Technology)の支援を受け、HEART プロファイル用のテストも組み込まれるに至っている。 

将来的には、既存の OpenID Certification テストは、FAPI & OBP コンフォーマンステストスイートによって置き換えられることになるだろう。なお、関連するアナウンス『OpenID Certification Expanding to FAPI Specs』が、2018 年 6 月 27 日に OpenID Foundation から出されている。 

Financial APIs Workshop では、FAPI & OBP コンフォーマンステストスイート開発プロジェクトをリードしたジョセフ・ヒーナン氏(FinTechLabs 社 CTO)の講演のほか、FAPI 対応した Authlete 2.0 を用いたコンフォーマンステストスイートの実演も予定されている。

 

4. 全ての立場から

今回の Financial APIs Workshop が特別な理由は、FAPI に関して、仕様策定者、公式テスト開発者、サーバー実装者、クライアント実装者、制度構築・運用者が一堂に会するからだ。

(敬称略)

仕様策定者

公式テスト開発者

サーバー実装者

クライアント実装者

制度構築・運用者

上記の登壇者のうち、崎村夏彦氏、ジョセフ・ヒーナン氏、ジャスティン・リッチャー氏、ラルフ・ブラッグ氏は、2018年6月末に米国ボストンで開催された Identiverse のスピーカーでもある。同イベントの参加費が $1695(18 万円以上)であることを考えれば、彼らの話を日本国内で聴くことができる機会は、かなり貴重であると言える。(英語→日本語への同時通訳あり)

FAPI に関してはどんなに深い話でも対応できる専門家が揃っているので、質疑応答時間やネットワーキングタイムを活用して突っ込んだ話を彼らにぶつけることも可能だ。特に、エンジニアであれば、OAuth や OpenID Connect を中心に様々な標準仕様の策定に携わり、『OAuth 2 in Action』の著者として、また、『MITREid Connect』の実装者としても知られる著名エンジニアのジャスティン・リッチャー氏に注目したい。

 

5. 注目の Fintech スタートアップ企業によるトークセッション

イベントの後半には、500 Startups Japan ファミリーである Fintech 企業 3 社によるトークセッションも行われる。

保険業界や融資業界の API 対応はまだまだこれからであるが、ちょうど数年前の銀行 API 議論開始時と状況が似ており、API 化の波は避けることはできないだろう。これらの業界にも、API起爆剤とする大きな変化が起こるものと期待される。勝負をかける新進気鋭のスタートアップ 3 社が、500 Startups Japan のマネージングパートナー澤山陽平氏をモデレーターとするトークセッションを行う。今後の業界の行く末を占うトークに注目したい。

 

6. 後援

今回のイベントは、幾つかの団体から後援を得ている。特徴的なのは、駐日英国大使館東京都からの後援だ。

昨年の 2017 年 12 月、東京都と City of London は金融分野で連携をおこなうことについて覚書を交わした(『City of London との MoU 署名式』)。この覚書の交換は、『国際金融都市・東京』構想の取組の一環としておこなわれたものである。そして東京都は、今回の Japan/UK Open Banking and APIs Summit も、同構想の一環と位置付け、後援に名を連ねている。

一方の駐日英国大使館だが、その役割の一つに、日本企業の英国への進出・英国企業の日本への進出の支援がある。英国の Open Banking の取組を日本と共有することは、両国共通のエコシステム構築に資するものであり、双方の産業界にとって有益であることから、駐日英国大使館も後援に名を連ねている。

そのほか、Fintech 協会電子決済等代行事業者協会500 Startups JapanLevel 39OpenID FoundationOpen Identity Exchange からも後援をいただいている。

 

7. 協賛

国内外から専門家を招いて二日間にわたっておこなわれる本イベントは、スポンサー企業の皆様の協賛によって支えられている。感謝申し上げたい。 

プラチナスポンサー

ゴールドスポンサー

シルバースポンサー

ブロンズスポンサー

 

まとめ

国内外の専門家を招き、2018 年 7 月 24 日と 25 日の二日間にわたって開催される『Japan/UK OpenBanking and APIs Summit 2018』。その一日目がエンジニアを対象とした『Financial APIs Workshop』である。銀行 API の世界最新事例や Financial-grade API(FAPI)の詳細を知りたいエンジニアの方々は、同イベントに是非注目していただきたい。

 

2018 年 7 月 17 日

株式会社 Authlete 代表 川崎 貴彦

 

 

CTO 不在の弊害を抱えるスタートアップ

私が代表を務める株式会社 Authlete(オースリート)(東京都千代田区大手町)では、CTO(Chief Technology Officer;最高技術責任者)不在による弊害が顕在化しております。従業員および株主の皆様にはご迷惑とご心配をおかけしており、誠に申し訳ありません。ここに、当弊害に関する状況整理をおこない、今後の対応策についてご報告致します。

 

1. 弊害内容

『CTO Night』と名のつくイベントへの参加資格が無く、技術系スタートアップであるにも関わらず、技術系イベントでの露出機会を逸している。

 

2. CTO 不在の経緯

2015年9月の法人登記の時点で既に主要製品の開発は済んでいたが、メイン開発者である創業者(会社代表)が CTO を名乗りたがらず、CTO 不在のまま現在に至る。

 

3. CTO を名乗らない理由

優秀な技術者をチームに引き込むため。

自分よりも能力・実績に劣る者が CTO を名乗る会社に、世界レベルの技術者は参画したがらない。

この意図的な CTO 不在作戦が功を奏し、Joseph Heenan 氏(英国)や Justin Richer 氏(米国)など、創業者よりもはるかに優れた技術者が Authlete 社に参画している。

 

4. そもそも CxO が一人もいない

CTO だけではなく、CEO や CFO などの CxO 系の肩書きを持つ者が誰もいない。

「CEO は誰ですか」と質問され、誰かの名前を挙げなければならない状況に追い込まれた場合のみ、書類上の代表取締役が CEO であると返答している。

 

5. CxO がいない理由

創業チームよりも有能なメンバーを新 CxO として迎え入れたいとき、創業チームメンバーがその時点で CxO を名乗っていると、役職交代が政治的に難しくなる。これについては、『起業家はどこで選択を誤るのか――スタートアップが必ず陥る9つのジレンマ』の「第5章 役割のジレンマ」や「第10章 ファウンダーCEO交代のジレンマ」が詳しい。

想像してほしい。IPO 準備のために財務のプロフェッショナルを CFO として外部から迎える必要がでてきたが、創業時に経費精算を担当していただけの者が CFO の肩書きを譲りたくないと言い出した場合のことを。こうなると、無能な CFO に対して、財務のプロフェッショナルがいちいち説明をおこない、承認を得なければならなくなる。無駄も甚だしい。

CxO という役職は、プロフェッショナルな CxO が必要となるステージに進んだときに、もしくは次のステージに進むためにプロフェッショナルな CxO を立てる必要があると判断したときに、設ければよい。スタートアップ創業初期から CxO の肩書きを乱発して逆ピラミッド型の組織をつくるのは、賢明とは言えない。

 

6. 組織の成長方向

創業チームの CxO が CxO を辞めたがらない場合、組織は下方向に成長する。これを図にすると、次のようになる。

f:id:TakahikoKawasaki:20180618170147p:plain

稀に、スタートアップの創業時から IPO 後まで、全てのステージにおいて凄まじい能力を発揮するスーパー起業家がいて、Microsoft 社のビル・ゲイツ氏や Facebook 社のマーク・ザッカーバーグ氏がこれに相当するが、そのような創業者を持つスタートアップは、組織の成長方向が下方向でもかまわない。

しかし通常は、創業チームのメンバーが全てのステージにおいて最適であることはないので、ステージの変化に合わせ、トップを交代させながら、次の図のように組織を上方向に成長させるのがよい。

f:id:TakahikoKawasaki:20180618170723p:plain

 

7. 対策

自らが大企業の CEO の器ではないことを自覚しているため、次のステージに進むためにプロフェッショナル CEO を迎え入れたいと思っているが、そのためには、下記のマイルストーンを達成することが必要と考えている。

  • MRR(Monthly Recurring Revenue)のみでの単月黒字化
  • 新 CEO に対する十分に魅力的な報酬を賄えるだけの利益もしくは資金調達

Authlete 社はスタートアップであるが、上場企業の平均年収をはるかに上回る報酬をメンバーに支払っており、新 CEO に対する報酬も妥協するつもりはないので(=「ストックオプションをあげるから低い報酬で我慢してね」と言うつもりがないので)、財務上の余裕が必要であり、上記のようなマイルストーン設定を考えている。

CEO のみならず、本題である CTO 、およびその他の CxO を迎えるためにも、財務上の余裕が必要である。

 

 

 

以上を以って報告と代えさせていただきます。

 

株式会社 Authlete 代表

川崎 貴彦

 

 

事案発生を招いたスタートアップの勤務体制

このたび、私が代表をつとめる株式会社 Authlete(オースリート)(東京都千代田区大手町)において、その特殊な勤務体制を起因とする事案が発生しました。当該社員の方、および御家族の皆様に深くお詫び申し上げます。当該事案の調査結果・考察・対策をここに公表し、再発防止につとめます。

 

1. 事案内容

転職後1ヶ月ほど過ぎた頃、社員が「社会人としてちゃんと会社に行きなさい」と奥様から叱られる事案が発生。当該社員による「雨降ってるからみんな会社に行かずに自宅で作業してると思う」という、弊社の日常風景の説明も奥様の理解を得られるには至らず、「そんな会社他にない」と、会社の行く末について心配を抱かせることになってしまった。

 

2. 直接の原因

コアタイムも強制出社日も無い自由過ぎる勤務体制。オフィスに用事が無ければ出社する必要がないため、在宅勤務を誘発してしまう。

 

3. 実態調査

事案報告を受けた翌日(天気=雨)、会社代表が午後2時頃出社したところ、出社していたメンバーは全体の半数に達していなかった。当該社員も出社していなかった。出社していないどのメンバーからも、「今日は出社しません」という旨の連絡は一切なかった。

 

4. 原因(自由勤務体制)の成立要件

4.1. コミュニケーション手段の充実

Slack や WhatsApp、Facebook メッセンジャー、電子メールなどのツールにより、場所と時間を選ばずに、社内外のコミュニケーションが取れるようになっている。

 

4.2. 開発場所を選ばない製品

主要製品がソフトウェアであるため、ノートパソコンさえあれば作業場所を選ばずに製品開発をおこなうことができる。

 

4.3. マイクロマネージメント不要

何も指示を出されなくてもやるべき仕事を自分で考えて自主的に取り組むタイプのプロフェッショナルのみで会社が構成されており、マイクロマネージメントが不要なため、出退勤時刻や労働時間を管理・監視する必要性がない。

 

5. マイクロマネージメントに関する考察

原因(自由勤務体制)の成立要件のうち、「マイクロマネージメント不要」が最も成立しにくいと思われるので、この要件ついて考察をおこなう。

 

5.1. 製品の特性

少数精鋭で開発に取り組んだほうがよい製品もあれば、人員を多く投入したほうがよい製品もある。

後者の場合、新卒などの未経験者でも、数週間〜数ヶ月程度の教育を施すことにより、十分に開発現場の戦力となりうる。しかし、代わりに、教育や作業指示、進捗管理などのマイクロマネージメントが必要になる。

製品の機能数が多かったり、UI/UX の細かい調整が重要だったりする場合、人員を投入したほうが有効である。概して、toC サービス(to Consumer:一般消費者を対象とするサービス)ではこの傾向が高い。

弊社の場合

弊社の製品は toB サービス(to Business:企業を対象とするサービス)であり、機能は少ないものの技術的に難易度が高いため、少数のプロフェッショナルによる開発が適している。プロフェッショナルに対してマイクロマネージメントは不要である。

 

5.2. 失敗に対する叱責

業務上の失敗に対する叱責を強くすれば、マイクロマネージメントと意思決定速度低下は一気に進む。部下は叱責を恐れ、何をするにも逐一上司に承認を求めてくるようになり、自主的に考えて勝手に動くようなことはしなくなる。これが極端になると、言われたこと以外しなくなる。

弊社の場合

自主的に考えて実行したことについては、例え失敗しても、一切叱責しない。失敗を自覚して次に活かすことができるプロフェッショナルに対して、一々叱責する必要はない。

 

5.3. 管理のための規則

作業指示を出さないと働かない(うまいことサボる)メンバーの扱いをどうするか。対策として、定期的な作業報告書の提出など、管理のための規則を新たに導入することが考えられる。しかし、サボらせないようにするための管理規則は、他のサボらない人達にとっては不要であり、管理者側の負担も大きい。

問題行動を起こすメンバーに合わせて管理規則を次々と導入していくか否かは、マイクロマネージメントに突き進むか否かの岐路となる。

弊社の場合

かなり悩んだが、週報提出制度の導入を見送り、代わりに、該当メンバーに退場してもらうことにした。

 

注1:奥様に叱られた方とは別のメンバーです。

注2:法人対法人の契約下でプロジェクトに参加されていたメンバーなので、「Authlete 社の社員を解雇した」という話ではなく、「法人間契約を延長しなかった」という話です。大きな単位の独立した仕事をお願いし、指示系統下に入ってもらうことなく独立して半年以上動いてもらっていましたが(つまり偽装請負の類ではありません)、期間に比べて余りにも成果物が乏しく、「マイクロマネージメントがないのをいいことにうまいことサボっていた」と解釈しないと説明がつかないと判断したので、契約を延長しませんでした。返金請求もできなくはない話でしたが、人を見る目がなかった不明と、適切なタイミングでの進捗確認を怠った責が自分にありますので、勉強料と考え、円満に契約終了としました。伝え聞くところでは、先方は私に謝りたいと思っているとのことですが、私自身は気にしていないです。ビジネスを進めていく過程で、無駄やミスマッチは少なからず発生するので、そのための金銭的・時間的・心理的バッファーは用意してあり、許容範囲内だったからです。

 

6. 自由勤務体制の実績

自由勤務体制に加え、開発拠点も日本・英国・米国と物理的に分散する中、高度な技術力を要する Financial API(FAPI)の開発を完了させてしまった。

 

f:id:TakahikoKawasaki:20180618022938p:plain

 

7. 対策

社員および御家族の皆さまに下記を丁寧に説明し、会社の現状に問題が無いこと、むしろ上手くいっていること、をご理解していただく。

 

 

 

以上を以って報告と代えさせていただきます。

 

株式会社 Authlete 代表

川崎 貴彦