クラウド型コールセンターソリューションPureCloud誕生秘話

優れたアイデアというのは、何の変哲もない場所から生まれたりするものです。2012年、野心を燃やしたメンバーが当時一時的に使っていた仕事場に集まり、親会社が持つ負の側面を打開し、コールセンターの歴史を塗り替えていくための作戦を練っていました。さらに面白いのは、その親会社が彼らを雇うことによってその作戦の実行をサポートしていたということでしょうか。これにより、Genesys® PureCloud®プロダクトが生まれました。

 
従来の開発スタイルとPureCloudプロジェクト

従来のコールセンターソフトウェアの開発にあたっては、高度なカスタマイズ化およびコントロールの実行というパラダイムがベースとなっていました。そして、こうした発想は所有という概念に基づいていました。つまり、インストールベースの所有、フェイルオーバー機器の所有、有能な人材の所有、そしてこうしたものすべてを維持するのに必要な第三者とのコネクションの所有が不可欠であるという考え方に立脚したものでした。ここで、ホスト型クラウドモデルによって、各種通信オプションが進化すると同時に、より多くの新テクノロジーが統合されるようになりました。しかし、前述したような所有によるコントロールというマインドセットが依然として存在することで、従来からの複雑性も残っているというのが現状です。

本業界における20年以上の実績、および積極的に改革を行うという発想を基盤として、PureCloudアプリケーションは以下のような重要な点を抑えるべく、いわば密かなスタートアッププロダクトとして開発されることとなりました:

 

1. プロダクトスイートではなく、部分、すなわちマイクロサービスから始めること
2. オープンスタンダードを用いること
3. 完全にオートメーション化された運営が可能であること
4. これまでのやり方には全く関心がない世代に対して、上記を実行していくこと

 
ここで「密かなスタートアップ」と言ったのは、社内外を問わず少数グループの精選された人材が、なんと既存のGenesys本社から送り出されたという理由からです。彼らはノースカロライナ州のローリーで、特殊なつながりや技術的拘束、コールセンター業界における慣習などをまったく気にせずにプロジェクト開発を開始することになりました。実際、この取り組みについて知っていたのは幹部クラスの人間のみでした。なお、この動きは、サリム・イスマイル氏の著作「シンギュラリティ大学が教える飛躍する方法（原題: Exponential Organizations）」に着想を得たアプローチで、改革を成功させるにあたっては親組織から切り離された状態で活動する必要があるというアイデアに基づいていました。まあ実際のところ、このアプローチはその効果が十分証明されていたものであり、PureCloudのリーダーシップチーム内における多くの努力の現れでもあるといえます。

PureCloudのセキュアなAPIはそれから1年後に発表されることとなり、これは会社にとっては驚きでした。もちろん、新しく選抜された優秀な人材で、この取り組みについて把握している人々もいました。彼らは、この業界初コールセンターAPIプラットフォームを使ってプロダクトスイートを作成できるように、発表の1週間前にMacBook Proを支給されていたのです。実際、私自身のキャリアにおいて、このパブリックAPIのみから作成された最初のクラウド型ネイティブコンタクトセンターのプロダクトスイートは、重要な成果のうちの一つでした。

 
オープンな環境が生んだイノベーション

当時は私にとって非常に面白い時期でした。セックス、薬物、あるいはロックンロールに病みつきになってしまう人々の気持ちが理解できる気がしました。なお、私はセックスや薬物をやっていた訳ではありません（正直、そのための時間はありませんでした）。伝統的な企業内開発という馬鹿げた考えを投げ捨てた上で、オープン性と信頼に基づいた新世界を次々と構築していくことは、私にとって快感でした。私は当時、銀行・医療業界におけるソフトウェアエンジニアだったので、このあたりの事情はよく理解できていました。さらに私の同僚でも、より良いものを実現できないかと模索している人たちはいました。

当時の状況はまるで、既存コード形式の維持にエネルギーを注ぎ込むあまり、新たな機能を導入する際に自らがボトルネックになっているようなものでした。実際、エンジニアであれば従来から、自らが管理するコード形式に基づいて作業を行うというのが通常でした。そして、これによってイノベーションが遅れることになるのです。なぜなら、人々は自らが「大切にしているシマ」を荒らすことがないよう注意することに時間を取られることになるからです（なお、これは悪意によるものではありません。単に、エンジニアが開発を行うにあたって典型的に形成されるバイアスについて話しています）。このような発想は、顧客および従来からの顧客の期待に応えるにあたって、悪影響となるだけなのです。

ここで、社内で分散化された状態で活動することによる威力を目の当たりにし、私は大変驚くことになりました。そして、私たちは企業一体としてこの変化を受け入れていくことにしたのです。

 
猛スピードで進む開発

開発は非常に短いサイクルの中で展開され、新機能のデプロイに関しては四半期単位でなく、週単位で行うというゴールを掲げながら実行されました。作業は、小規模で独立した「まとまり」（グループ）内で行なっていきました。優れたコードについては社内すべてのグループ内で共有され、ブラックボックスとなるような部分はもはや存在しませんでした。ちょっとした機能（マイクロサービス）が必要となれば、すでに存在するものを活用するか、または新しいものを作ることで全員が確認し、話し合い、議論し、承認し、最終的に採用できるような形に持っていくという流れでした。

私が使用しているコードの中にバグが見つかった場合は、もともとそのコードを書いた人がバグを修正するのを待つことなく、私自らがその人に代わって修正を行い、修正内容について議論、承認を行なってもらえるように公開していました。誰でも技術的制約を気にせず完全に自由な形で、コードを「マスター」プロダクトベースへとあげることができるという状態だったのです。そのため、だれかがバグのあるコードをグローバルマスターコピーへと「プッシュ」してしまったことで、マスターコピーが台無しになりかけたこともあったものです。

PureCloud開発プロセスの非常に初期の段階においては、現在使用されているような自動テスト機能が充実していませんでした。現在では、週単位で実行する本番環境アップデートで新機能を導入するにあたっては、何千にもわたるテストを実行するのに丸1時間必要となります。「古き良き時代」ともいえる当時は、マスターコードベースへの変更のマージが3秒で済んでいました。誰かがマスター上の履歴をめちゃめちゃにするようなプッシュを行なったことがありましたが、特に私の記憶に残ったのが、その対処方法でした。

 
セキュアより自由がもたらす進化を

対処にあたっては当然のごとく、だれもが変更をプッシュできるという状態について適切に管理できるようにすべきだという意見もありました。実際、これには一理ありました。私たちは、特定の利害や立場に関係なくオープンにこれに関する議論を行い、その結果「誰でも好きな時に変更をプッシュできる」という方針を正式に採用することにしました。ここでは、誰も検閲を受けることがありません。必要なのは、ひたすらコードの質を向上させることであり、同じ失敗を繰り返さないということです（実際は数週間後に再び同じことが起きたのですが、この方針はそのまま継続されることになりました）。その決定の意図するところは、現在私の顧客の皆様方が体験している自由度に反映されており、PureCloud APIを使用して何か素晴らしいものを構築したり、単純にプロダクトスイートを最初に購入したりしたのちにこのAPIを基礎としてサービスを成長させていったりする際の自由度が高まったといえます。

 
未だかつてないクラウド型コールセンターソリューションを生み出して

PureCloudの生々しい誕生秘話は、今となっては良い思い出です。多くのスタートアップ企業が経験する波乱万丈を経た現在、私はPureCloudが大きく成長したことに誇りを持っています。私自身、消費者かつビジネスマンの立場として、希望の大きい2020年代に突入していくにあたってPureCloudアプリは非常に役立つと考えています。PureCloudプロダクトが私自身のキャリアの一部となったことに対し、私はこれからも感謝を忘れることはないでしょう。

 

PureCloudアプリケーションに関する詳細は、チュートリアル動画もしくはオンライン上でPureCloud簡易デモを実際に体験してみてください。