エリック・ゲフェッサー、SPRのデータプラクティス担当プリンシパルアーキテクト – インタビューシリーズ

エリックは、2018年にSPRのエマージングテクノロジーグループのデータプラクティスにプリンシパルアーキテクトとして参加しました。

エリックは、データ、Javaを使用したオープンソース開発、およびPoC、プロトタイプ、MVPの構築を含む実践的なエンタープライズアーキテクチャを専門としています。

あなたが最初にマシンラーニングに惹かれたのは何ですか?

マシンラーニングの魅力は、継続的に学習するアプリケーションを可能にすることです。私は、SPSSを使用するシニアデータアナリストとしてキャリアを始めましたが、それは後にグローバルマーケットリサーチ会社になりました。さらに、私はDroolsというビジネスルールエンジンをアプリケーションに組み込んだことがありますが、その出力は基本的に静的でした。

私は、プロセス改善トレーニングを受けたとき、インストラクターが詳細に説明したように、統計やその他の方法でビジネスプロセスを改善する方法を見ましたが、そこでも出力は主に時系列に焦点を当てていました。同僚と一緒にヘルスケア製品を改善するために行った経験は、継続的な学習が必要な理由を示しましたが、その当時は必要なリソースが存在しませんでした。

興味深いことに、私のマシンラーニングへの関心は、全円なものとなりました。私の大学院での指導教員は、私に当時「人工知能」と呼ばれていた専門分野に従事しないように警告しました。なぜなら、その当時はAIの冬の時代だったからです。私は、代わりに「ML」という用語を使用することを選択しました。なぜなら、これらの用語には、AIほどのニュアンスがないからです。さらに、AWSは、AIサービスレイヤーが実際にはMLサービスレイヤー上に構築されたより高い抽象化レベルであることを認識しています。マシンラーニングの周りの一部のハイプは非現実的ですが、開発者の視点から見ると、強力な機能を提供します。ただし、これらの実践者が、マシンラーニングによって提供される価値は、処理されるデータと同じだけであるという事実を認識する限りです。

あなたはオープンソースの強い支持者です。オープンソースが重要な理由について説明できますか?

オープンソースについて、私がこれまでに経営陣に説明する必要があったのは、オープンソースの主な利点は、ソフトウェアの使用が無料で提供されることではなく、ソースコードが自由に利用できることであるという点です。

さらに、開発者はこのソースコードを使用して変更を加えることができ、変更が承認されれば、これらの変更を他の開発者に提供できます。実際、オープンソースソフトウェアの運動は、開発者が商業企業から製品の変更を待っている間に始まりました。開発者は自分で同じ機能を持つソフトウェアを書き、他の開発者が改善できるようにしました。

商業化されたオープンソースは、これらの利点を活用しています。現実は、多くの現代の製品が表面下でオープンソースを使用していることです。商業的なオープンソースのバリアントは通常、オープンソースリリースの一部として利用できない追加コンポーネントを提供し、差別化要素とサポートを提供します。

私の最初のオープンソース経験は、Apache AntやHudson（のちにJenkinsになった）などのツールを使用してヘルスケア製品を構築していたときでした。私たちがこれらのオープンソース製品を使用することを選択した主な理由は、これらが商業的な代替案よりも優れた解決策を提供していたか、商業的なエンティティでは提供されていなかった革新的な解決策を提供していたことです。さらに、商業的な製品のライセンスは制限が厳しすぎて、コストの問題で新しいライセンスを取得する際に大きな問題になっていました。

時間の経過とともに、私はオープンソース製品が進化し続け、必要な革新を提供するのを見てきました。例えば、私と同僚が製品を構築する際に直面した多くの問題は、後に私たちが使用し始めたSpring FrameworkというオープンソースJava製品によって解決されました。このエコシステムは、依存性の注入などの初期の革新を超えて、10年以上にわたって存続しています。

あなたはPoC、プロトタイプ、MVPの構築にオープンソースを使用しました。いくつかの製品についてのあなたの旅を共有できますか?

最近のクライアントに提示したガイドラインの1つとして、私は、データプラットフォームの構築は、必要に応じて時間の経過とともに反復的に行われるべきであると述べました。構築されるコンポーネントは静的であると想定すべきではなく、ニーズが変化し、新しいコンポーネントとコンポーネント機能が利用可能になるにつれて、必要に応じて追加されていくべきです。

プラットフォームの機能を構築する際には、不要なベルやホイッスルを追加する前に、まず最小限の実用的なものから始めます。機能的なものから始め、理解を深め、次に進化させます。使用される可能性が低いものを構築するのに時間とお金を浪費しないでください。ただし、将来のニーズに先んじて努力することを心がけます。

私たちが構築したMVPは、追加のユースケースを上に構築できるように設計されていました。ただし、最初のユースケースである支出の異常検出の実装が含まれていました。以前の製品とは異なり、私が参加する前に3年間議論されていた製品がありました。クライアントの幹部は、私を参加させることで、これらの内部の議論を超越するのに役立つと説明しました。特に、製品は関与する組織の階層を満たす必要があったためです。

私は、これらの縄張り争いは、クライアント、子会社、および外部顧客が所有するデータに関連していることを発見しました。したがって、製品のバックログはすべて、データの取り込み、保存、セキュリティ、およびコスト分析のためのヘルスケア提供者のネットワークを生成する単一のユースケースのために使用される方法についてでした。

キャリアの初期に、私は「使いやすさ」というアーキテクチャの品質が、エンドユーザーだけでなく、ソフトウェア開発者自身にも関係することを理解しました。開発者が何を成し遂げようとしているか、特に技術選択に関して、実現可能かどうかを示すために、概念実証が必要です。ただし、概念実証は始まりにすぎません。製品は、時間の経過とともに進化することで最も優れています。私の見解では、MVPの基盤は、開発者が進化できるように、ある程度の安定性を示すプロトタイプの上に構築されるべきです。

あなたは『Machine Learning at Enterprise Scale』という本をレビューしたときに、「オープンソース製品、フレームワーク、言語を使用し、オープンソースと商用コンポーネントの混合で構成されるアジャイルアーキテクチャは、多くの企業が必要とするがすぐには実現できない機敏性を提供する」と述べました。オープンソースを使用する企業が機敏性の高い理由について詳細に説明できますか?

多くの商用データ製品は、表面下で重要なオープンソースコンポーネントを使用しています。Pythonなどの人気のあるプログラミング言語を使用する開発者を可能にします。オープンソースコンポーネントを組み込んだ企業は、これらのコンポーネントがコミュニティによってすでに広く使用されていることを知っています。

強いコミュニティを持つオープンソースコンポーネントは、コミュニティによって提供される既存の知識と経験により、販売が容易になります。商業的に利用可能な製品は、主にクローズドソースで構成されており、または商業製品にのみ使用されるオープンソースで構成されていますが、通常、ベンダーのトレーニングまたはライセンスが必要です。

さらに、ドキュメントは公開されていないため、開発者はこれらの企業に依存し続ける必要があります。Apache Sparkなどの広く受け入れられたオープンソースコンポーネントが中心である製品、たとえばDatabricks Unified Analytics Platformの場合、多くのアイテムはすでにコミュニティで利用可能であり、開発チームが商業エンティティに依存する必要はありません。

さらに、Apache Sparkなどのコンポーネントは、業界のデファクトスタンダードツールと見なされているため、コードを商業製品の実装間で簡単に移行できます。企業は独自の差別化要素を組み込もうとしますが、開発者は完全に新しい製品を使用することを望まないことが多く、コミュニティから切り離され、移行が困難になる可能性があります。

私自身の経験から、商業製品を使用したことがありますが、有能なサポートを得ることが難しいことがあります。これは、企業が製品をサポート付きで販売することを期待しているにもかかわらず、皮肉です。私はオープンソースプロジェクトにプルリクエストを提出し、修正が同日のビルドに組み込まれたことがありますが、商業プロジェクトでは同様のことがありません。

あなたはオープンソースについてもう1つの信念を持っています。つまり、強力な開発者コミュニティへのアクセスを提供することです。これらのコミュニティはどのくらい大きいのでしょうか? それらが効果的な理由は何ですか?

オープンソース製品を取り巻く開発者コミュニティは、数十万人に及ぶことがあります。採用率はコミュニティの強さを直接示すものではありませんが、強いコミュニティを示す良い指標となります。コミュニティが強いと考えられるのは、健全な議論と効果的なドキュメントを生み出し、活発な開発が行われている場合です。

アーキテクトやシニア開発者が、組み込むオープンソース製品を選択する際には、多くの要素が考慮されることがあります。製品自体、コミュニティ、開発チーム、エコシステム、ロードマップ、場合によっては商用サポートの可用性などです。ただし、これらの多くの側面は、強力な開発者コミュニティが存在しない場合に失われます。

あなたは100冊以上の本をレビューしました。あなたが読者に推薦する3冊の本がありますか?

最近、私はほとんどのプログラミング本を読んでいません。例外はありますが、現実はこれらの本がすぐに古くなることです。開発者コミュニティは通常、ディスカッションフォーラムやドキュメントを通じてより良い代替案を提供します。私が現在読んでいる本は、技術ニュースレター、著者や出版社から送られてくるもの、またはAmazonから送られてくるものです。例えば、Amazonは私に「The Lean Startup」の出版前の未校正証をレビュー依頼で送ってきました。最近では、「Julia for Beginners」のコピーを送ってきました。

(1) 私が推奨するO’Reillyの本の1つは「In Search of Database Nirvana」です。著者は、OLTPから分析まで、ワークロードのスペクトル全体をサポートするデータベースエンジンの課題について詳細に説明しています。運用およびビジネスインテリジェンスワークロードの中間点です。この本は、データベースエンジンまたはクエリエンジンとストレージエンジンの組み合わせを、ワークロード要件に合わせて評価するためのガイドとして使用できます。著者は最近の「データベースの振れ戻し」のカバレッジも特に優れています。

(2) データスペースでは最近多くの変化があり、新しいデータ分析製品が導入され続けていますが、「Disruptive Analytics」は、分析の革新の最後の50年について、他の場所では見られないアプローチャブルで短い歴史を提示しています。さらに、2種類の妨害について論じています。分析価値チェーン内の妨害革新と、分析の革新による業界の妨害です。スタートアップや分析の実践者にとって、成功は業界を妨害することによって可能になります。分析を使用して製品を差別化することは、妨害的なビジネスモデルを作成したり、新しい市場を作成したりする方法です。分析テクノロジーに投資する組織にとって、待ってみるアプローチは妥当です。なぜなら、リスクのある投資は、有用なライフタイムが短いため、妨害されるテクノロジーです。

(3) 私が読んだ最も優れたテクノロジービジネス本の1つは、「The Limits of Strategy」です。Research Board（Gartnerに買収）の共同創設者によって書かれています。Research Boardは、コンピューティングの世界の開発と、企業がそれに適応する方法について調査する国際的なシンクタンクです。著者は、ビジネスリーダーとの会話から詳細なノートを提示し、全体を通じて洞察的な分析を提供しています。コンピューティングの世界をメッシュする必要がある主要クライアントのグループを構築する（妻と一緒に）ことについてです。この本を他の関連書籍と区別する2つの特徴があります。業界全体の幅と、直接の対話だけが可能な親密さです。

あなたはSPRのデータプラクティスのプリンシパルアーキテクトです。SPRについて説明できますか?

SPRは、シカゴを拠点とするデジタルテクノロジーコンサルティング会社で、フォーチュン1000企業から地元のスタートアップまで、幅広いクライアントのテクノロジープロジェクトを提供しています。カスタムソフトウェア開発、ユーザーエクスペリエンス、データ、クラウドインフラストラクチャ、DevOpsコーチング、ソフトウェアテスト、プロジェクト管理など、さまざまなテクノロジーキャパビリティを使用して、エンドツーエンドのデジタルエクスペリエンスを構築しています。

SPRでのあなたの責任は何ですか?

プリンシパルアーキテクトとして、私の主な責任は、クライアントのソリューションの提供を推進することです。アーキテクチャと開発をリードすることです。これは、製品所有者としての役割を含むこともあります。なぜなら、製品がどのように構築されるかを理解することは、優先順位を決定する上で重要だからです。特に、スクラッチから構築する場合です。私は、専門知識が必要な場合、潜在的なクライアントとの議論にも参加しています。会社は最近、私にデータプラクティスのアーキテクトとの継続的なセッションシリーズを開始するよう依頼しました。クライアントプロジェクト、サイドプロジェクト、同僚がテクノロジーを追跡するために何をしているかについて議論するというものです。

私のキャリアの大部分で、私はJavaを使用したオープンソース開発と実践的なエンタープライズアーキテクチャを専門としてきました。データワークも増えてきました。私の同僚と私は「実践的」または「実用的」と呼ぶアーキテクチャタスクを実行しています。つまり、構築するもののコンテキストで実際に構築しながらアーキテクチャタスクを実行するということです。ただし、話したり、図を描いたりするだけでなく、実際に構築します。

私の見解では、これらの3つの専門分野は相互に排他的ではなく、重複しています。私は、テクノロジー業界が従来、ソフトウェア開発とデータワークの間に引いていた線は、現在は明確ではありません。ツールが収束したことと、結果としてデータワーク自体が主にソフトウェア開発の取り組みになったことが理由です。ただし、従来のデータ専門家は通常、ソフトウェア開発の背景がないため、そしてその逆もまた然りです。私は、このギャップを埋めるのに役立ちます。

SPRで現在取り組んでいる興味深いプロジェクトは何ですか?

最近、私は、チームと一緒に去年AWSで構築したデータプラットフォームについて、複数パートのケーススタディシリーズの最初の投稿を公開しました。このプラットフォームは、データパイプライン、データレイク、規範データモデル、視覚化、マシンラーニングモデルで構成され、企業の部門、プラクティス、エンドカスタマーによって使用されます。コアプラットフォームは、企業IT部門によって構築される予定でしたが、目標は、共通のアーキテクチャを使用して企業全体のデータ資産とデータ分析を集中化し、各組織のユースケースのニーズを満たすために上に構築できるようにすることでした。

多くの確立された企業と同様に、Microsoft Excelの使用は一般的でした。スプレッドシートは、組織内および組織間、企業と外部クライアント間で共有されていました。さらに、ビジネスユニットとコンサルティングプラクティスは、シロ化され、各自が異なるプロセスとツールを使用していました。したがって、データ資産とデータ分析を集中化することに加えて、もう1つの目標は、データ所有権の概念を実装し、組織間で安全かつ一貫した方法でデータを共有できるようにすることでした。

オープンソース、SPR、または現在取り組んでいる他のプロジェクトについて何か追加で共有したいことはありますか?

最近、私がリードした別のプロジェクト（こちらとこちらを参照）では、大手保険会社のデータエンジニアリング部門のディレクターのために、Databricks Unified Analytics Platformの実装に成功し、Azure HDInsight（Hadoopの配布）からマシンラーニングモデルの実行を移行しました。

これらの移行されたモデルはすべて、さまざまな保険製品に対する消費者の採用レベルの予測を目的としていました。いくつかは、HDInsightに移行する前にSASで構築されていました。最大の課題は、データ品質の低さでしたが、他の課題には、包括的なバージョニングの欠如、部族的知識と不完全なドキュメント、Databricksのドキュメントとサポートの未熟さ（当時、AzureでのDatabricksの一般提供が開始されたばかりでした）が含まれました。

これらの主要な課題に対処するために、私は自動化、構成とバージョニング、データの懸念の分離、ドキュメント、およびデータ、プラットフォーム、モデリングチーム間の必要な調整についての推奨事項を出しました。私たちの作業により、当初非常に懐疑的だったチーフデータサイエンティストが、Databricksは行くべき道であると確信するようになりました。私たちが去った後の目標は、残りのモデルをできるだけ早くDatabricksに移行することです。

これは、オープンソースについて多くを学んだ、面白いインタビューでした。さらに詳しく知りたい読者は、SPRの企業サイトまたはエリック・ゲフェッサーのサイトを訪問できます。