よく「なぜ音声技術やAIの世界から銀行業界へ転身したのか」と聞かれます。その経緯をお話ししましょう。
テキスト読み上げ（Text-to-Speech）
私のこれまでのキャリアにおけるハイライトは、Googleのテキスト読み上げシステムの立ち上げと、その後の成功です。このシステムは2012年6月、新しい「Google Now」サービスの一部として公開されました。これにより、ユーザーは複雑な音声検索を行ったり、サービスに対して簡単な質問を投げかけたりできるようになりました。この立ち上げは成功を収め、現在ではGoogleのすべての音声出力（運転ルート案内、インタラクティブな音声検索、音声アシスタント技術など）にこのシステムが使用されています。このテキスト読み上げシステムはインターネット経由およびデバイス上で動作し、2015年時点で10億台以上のAndroidデバイスにインストールされています。
私たちのチームの主な貢献は、非常に自然で心地よい音声を提供することでした。ユーザーは不自然な音声合成を好みません。耳障りな音は不快感を与え、可能であればオフにされてしまいます。非常に高品質なものを開発して初めて、そのサービスは「使える」と判断されるのです。
では、どのように実現したのでしょうか。このテキスト読み上げシステムには、長年の歴史を持ち、世界クラスの研究所や研究者によって開発されてきた「ユニット選択フレームワーク」という技術が使われています。基本的には、一人の話者の音声をデータベースとして録音します。各文章を音素に分割し、これがアルゴリズム名の由来である「ユニット」となります。特定の音声ユニットの音パターンは文脈に大きく依存します。例えば、「top」の「t」の音には強い息の吐き出し（有気音）が含まれますが、「stop」の「t」は性質が全く異なり、50ミリ秒程度の短い無音に近いものになります。こうした文脈による影響があるため、一つの「t」を録音してどこにでも使い回すと、不自然で耳障りな音になってしまいます。実際には、必要な音の空間を適切にカバーするために、各音素を数千、時には数万回録音しなければなりません。
データベースを収集・分析したら、効率的な実行時フォーマットにコンパイルします。文章が入力されると、それが音素に変換され、データベースから「最適」なシーケンスが検索されます。つまり、最も適切なユニットの組み合わせであり、かつ繋ぎ目が最も目立たないシーケンスを探すのです。これを単純な方法で行うと、一つの文章を処理するのに何時間もかかってしまいます。しかし、動的計画法、巧妙なインデックス作成、カスタマイズされたデータモデル、キャッシュ、枝刈り、検索最適化を組み合わせることで、音声再生にかかる時間よりも約100倍速く文章を生成できるようになりました。
これらは一朝一夕で構築されたものではありません。実際、2012年にGoogleのシステムを立ち上げた時点で、私は1989年からこの問題に取り組んでいました。かつてインタビューで「ミケランジェロがシスティーナ礼拝堂の天井画を描くのに7年しかかからなかった」と冗談を言って（後に後悔しましたが）、自分の苦労を表現したこともあります。形成期はエディンバラ大学で過ごし、1992年に博士号を取得しました。その後8年間同大学に留まり、1999年には大学の音声技術研究センターの所長に就任しました。この期間のほとんどをテキスト読み上げの研究に費やし、 Festivalシステム は、アラン・ブラックやリチャード・ケイリーと共同開発したもので、現在も教育や研究のツールとして使われています。（私がかつてコードを書けたという証拠が必要なら、 GitHubのアーカイブをご覧ください）。
1990年代のエディンバラ大学は素晴らしい場所でした。AI、機械学習、音声技術、言語学、認知科学、コンピュータ科学のコミュニティが活気に満ちており、最高の学習環境でした。今日、AIがこれほど注目を集めているのを見ると、正直どう反応していいのか分かりません。1990年代、英国でこの分野に関わっていたのは数百人程度で、私たちは互いに顔見知りであり、自分たちの世界に閉じこもっていました。というのも、商業的な観点からは、実際に機能するものはほとんどなかったからです。それでも、非常に楽しい時代でした。「機械に道徳的規範を持たせるべきか？」「機械は危険になり得るか？」「人々の仕事はどうなるのか？」といった、当時議論していた概念的な問題は、今日のものと全く同じです。しかし、当時は内向的なコミュニティ内での議論に過ぎませんでした。毎日メディアでAIに関する記事を目にし、首相や大統領までが意見を述べている現状には、今でも驚かされます。
スタートアップの生活
私は2000年に最初のテック企業であるRhetorical Systemsを共同設立しました。その瞬間から、これこそが自分の生きる道だと確信しました。2004年から2006年までのケンブリッジでの期間を除き、私は学術の世界を離れました。
Rhetoricalでの生活は、テック系スタートアップにつきもののジェットコースターのような日々でした。その様子は何度も語り尽くされているのでここでは割愛しますが、当時はどうすべきかという指針がほとんどなかったことだけは伝えておきます。ビジネス書は大手企業向けのものばかりで、スタートアップ向けの本といえば、商店やレストラン、あるいは「普通の」ビジネスを開業するためのものばかりでした。今、会社を立ち上げる人は、少なくとも素晴らしいコミュニティや豊富な読書資料を頼りにすることができます。
Rhetorical社は、私が大学時代に発明したテキスト読み上げ技術を開発しました。品質面では大きな成功を収めましたが、商業的には今ひとつでした。その理由は、たとえ技術が受け入れられたとしても、より広い市場で販売するのは困難だったからです。人々は使いたいと思っても、対価を支払うことには消極的でした。この問題は、現在のAI市場全体にも根深く残っています。Alexa、Siri、Google HomeなどはAIや音声技術を多用していますが、これらは独立したスタートアップではなく、巨大テック企業によって提供されています。多くの場合、巨大テック企業が展開する技術はスタートアップで発明され、買収を通じて取り込まれたものです。つまり、両タイプの企業が互いを必要としているのは明らかです。必然的にRhetorical社は2004年に買収され、その後私はケンブリッジ大学工学部で2年間を過ごしました。
2006年、私はPhonetic Artsを共同設立し、CEOに就任しました。やっていることは前回とほぼ同じでしたが、今回はエンターテインメント業界をターゲットにしました。技術は今回も素晴らしかったのですが、対価を支払ってくれる顧客を見つけるのはやはり困難でした。2010年、歴史は繰り返されました。ある日Googleから電話があり、取引をしないかと持ちかけられたのです。その後の5ヶ月間にわたる骨の折れる交渉は本が一冊書けるほどの内容でしたが、結末はハッピーなものでした。2010年末にPhonetic Artsは買収され、チームはGoogleに加わり、Googleのテキスト読み上げチームとなりました。
Googleでの仕事は非常に楽しく、毎月の給与支払いを心配しなくて済むのは救いでした。Googleの文化は素晴らしいものでしたが、私が本当に魅了されたのは、無料のランチやマッサージといった福利厚生ではなく、Googleがいかにしてこれほどスケーラブルな企業を築き上げたかという点でした。現在のGoogleは非常に巨大ですが、最初からそうだったわけではありません。しかし、初期の段階から、数百人のエンジニアが数千万人に利用される製品を作り上げていました。私がAndroidチームに加わった当時、エンジニアはわずか300人でしたが、すでに5億台の端末に出荷されていました。
そこには多くの秘訣があります。第一に、優秀なエンジニアだけを採用し、彼らをテック企業の中心に据えることです。多くの企業がこれを理想としますが、実際に実行できているところはほとんどありません。せいぜい数人のスターを採用する程度で、「退屈」あるいは「平凡」なエンジニアリング業務にはスターは不要だと考えがちです。Googleのアプローチは、あらゆるレベルでスターを採用し、自動化コードを書くことで退屈な仕事を排除することでした。Googleには手作業によるプロセスがほとんど存在しません。
第二に、継続的インテグレーション、デプロイメント、モノレポシステムです。Googleが数十億行のコードを単一のリポジトリで管理し、すべてを自動的かつ継続的にビルド・テストしているのを見るのは驚異的でした。つまり、どのエンジニアも許可を求めることなく、あるいは特別な準備をすることなく、他人のコードを再利用できるのです。依存関係を設定するだけで、すべてがコンパイルされ実行されます。Googleのコードベースには「無駄」が一切ありません。すべてがコンパイルされ、実行され、文書化され、テストされています。コードは非常に高い基準で書かれており、読みやすく理解しやすいものです（銀行業界と比較してみてください。銀行では、何年も前に書かれたコンポーネントがどのように機能しているのか、誰にも理解されておらず、削除や置き換えの方法すらわからないシステムが一般的です）。
最後に、Googleで展開されている技術そのものは、必ずしも独創的ではないという点に注目すべきです。単に、スピード、安定性、可用性の面で非常にうまく実行されているだけなのです（Gmailを思い浮かべてください）。しかし、単純なことをうまくやるのは必ずしも簡単ではありません。Gmailのようなシステムは、世界中で膨大な量のメールを処理し、常に迅速かつ効果的に機能しなければなりません。Gmailをトランザクションシステム（各メールが1つのトランザクション）として捉えると、銀行業務との共通点が見えてきます。
Googleは素晴らしい環境でしたが、一度起業家としての道を歩めば、それは一生続くものです。私の「任期」が終わった2013年末に私は退職しました。偉大なレストランで修行したスーシェフのように、Googleを去る時には、偉大なテック企業を築くためのレシピを手にしていると感じていました。そしてその思いを胸に、私はThought Machineを設立しました。
チームの構築
私の最優先事項は、真に世界クラスのチームを作り上げ、そこにエンジニアリングの卓越性を追求する精神を吹き込むことでした。その鍵となるのは、人々が参加したくなるような会社のビジョンを持つことです。それは、素晴らしい職場環境、興味深い領域、巨大な市場、そしてIPOの可能性を組み合わせたものです。私は二度と、早期買収を目的とした会社を作るつもりはありませんでした。まず、エンジニアリングの卓越性を備え、私と同じ目標を共有できるかつての同僚たちに声をかけました。こうして、Google時代の仲間であるFabian、Pebers、Willを採用しました。
やがて知り合いの候補者は底をついたため、チーム構築に専念してもらう社内リクルーターのHung Leeを採用しました。彼が思いついたのは、候補者がチームと交流し、私が会社について語るイベントを開催するというアイデアでした。これは即座に成功を収め、それ以来私たちはこの方法で採用を続けています。過去4年間で1,000人以上の候補者がThought Machineの採用イベントに参加しました。
私は、具体的な課題を決める前に、まずは素晴らしいチームを作ることの方が重要だと考えていました……
課題の選定
大まかな領域を決めるのは簡単でした。ロンドンが急速に世界のフィンテックの中心地となりつつあったため、それが当然の選択でした。Thought Machineの最初の1年間は、消費者金融のさまざまな分野で銀行と協力しました。銀行側には新しいことに挑戦したいという意欲が明確にあり、選択肢に事欠くことはありませんでした。しかし、フィンテック企業のほとんどは周辺領域で活動しているのが明らかでした。なぜなら、中核となる「神話的なコアバンキングプラットフォーム」に触れることは不可能だと考えられていたからです。コアバンキングエンジンとのインターフェース構築は困難でした。それらは何十年も前にCOBOLで構築され、メインフレーム上で動作していたからです。クラウドホスト型のAPIマイクロサービスアーキテクチャとはかけ離れた存在でした。
チャレンジャーバンクと話をした際、ビジネスケースが明確に見えました。彼らが独自の銀行システムを構築するには何年もかかり、既存のサードパーティから購入しようにも、最新のアーキテクチャを採用しているところがなく、高額で困難でした。市場には明確なニーズ、あるいはギャップが存在していたのです。
ほとんどの人が、これには手を出すなと言いました。メインフレームのコアバンキングは不変であり、銀行は決して変わらず、問題はあまりにも難しく手に負えないというのです。最後の点（コアバンキングは難しいのか？）について、私は譲りませんでした。支払いと利息を計算し、その結果を記録することが、なぜそれほど難しいのでしょうか？ もちろん、多くの人に「それは難しい」と言われることこそ、野心的なエンジニアを奮い立たせるのです！
そこでWill Montgomeryと私は何度も長い話し合いを重ね、Willは後の Vault Coreとなるシステムの構築を開始しました。数ヶ月後には形になり、いくつかの銀行にデモを行いました。フィードバックはすぐに好意的なもので、それがきっかけとなり、2016年を通じて徐々に会社全体をこの製品に注力させることになりました。開発を進めるにつれ、商業的な関心は急速に高まりました。そして、当初考えていたよりもはるかに大きなチャンスがあることに気づきました。クラウド上のコアバンキングエンジンを構築するだけでなく、財務システム、財務報告、CRM、信用リスク判断、その他数十のコンポーネントを備えた、完全なリテールバンクを構築できるという可能性です。
批判的に見れば、私たちがやっていることに魔法や独創性は特にないと言えるかもしれません。私たちは単に、アジャイルなクラウドコンピューティングのベストプラクティスをリテールバンキングの問題に適用しているだけです。しかし、それこそが重要な点なのです。クラウドコンピューティングの考え方を前提とし、その手法を純粋に守りながら、ゼロから特定のシステムを構築しなければなりません。銀行業界が何十年も続けてきたやり方から進化させることはできないのです。
これが、私がテキスト読み上げ技術からクラウド型バンキングプラットフォームへと至った経緯です。
