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

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

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

あなたが最初に機械学習に惹かれたのは何ですか？

アプリケーションが継続的に学習できるようにすることです。私は、SPSSを使用するシニアデータアナリストとしてキャリアを開始し、後にクライアントのためにビジネスルールエンジンのDroolsを使用したアプリケーションを構築しました。しかし、これらの作業の出力は基本的に静的でした。

後で、プロセス改善トレーニングを受けました。その際、インストラクターは、統計やその他の方法でビジネスプロセスを改善する方法を詳細に説明しました。しかし、ここでも出力は主に時点に焦点を当てたものでした。同僚と一緒にヘルスケア製品を構築した経験は、継続的な学習の必要性を示しましたが、その当時は必要なリソースが利用できませんでした。

興味深いことに、私の機械学習への関心は、全円に戻ってきました。私の大学院での指導教員は、私に当時「人工知能」と呼ばれていた分野に特化することを警告しました。その理由は、当時のAI冬のためでした。代わりに、私はMLという用語を使用することを選択しました。これは、AIよりも少ないニュアンスを持ち、AWSもAIサービス層が実際にはMLサービス層の上位に構築された抽象化であることを認識しています。MLの周りのいくつかのハイプは現実的ではありませんが、開発者の視点からすると、開発者がその価値を認識する限り、強力な機能を提供します。

あなたはオープンソースの強い擁護者です。オープンソースの重要性について説明できますか？

オープンソースの1つの側面は、エグゼクティブに説明しなければならなかったことですが、オープンソースの主な利点は、ソフトウェアの使用が金銭的なコストなしで提供されることではなく、ソースコードが自由に利用できることです。

さらに、開発者はこのソースコードを変更し、承認された変更を他の開発者と共有できます。実際、オープンソースソフトウェアの背後にある運動は、開発者が商業企業が製品を変更するのを待っている間、同じ機能を持つソフトウェアを書くために開始されました。

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

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

時間の経過とともに、私はオープンソース製品が進化し、必要な革新を提供し続けるのを見てきました。たとえば、私と同僚がヘルスケア製品を構築する際に直面した問題の多くは、後に私たちが使用し始めた革新的なオープンソースJava製品であるSpring Frameworkによって解決されました。このエコシステムは依然として強力であり、10年以上にわたって続いています。

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

最近のクライアントに提示したガイディングプリンシパルによると、データプラットフォームの構築は、必要に応じて時間の経過とともに反復的に行う必要があります。プラットフォームのコンポーネントは静的なものとして期待されるべきではなく、新しいコンポーネントと機能が時間の経過とともに利用可能になる可能性があります。

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

私たちが構築したMVPは、追加のユースケースを上に構築できるように設計されていましたが、単一のユースケースである支出の異常検出の実装が含まれていました。クライアントの幹部は、3年間も議論を続けていた製品について私を参加させた理由の1つは、私が会社が議論を進めるのを助けるために参加したためです。

私は、これらの縄張り争いは、クライアント、子会社、および外部顧客が所有するデータに関連していることを発見しました。したがって、この製品のバックログは、単一のユースケースのためにデータを取り込み、保存、保護、および分析する方法に焦点を当てていました。

私のキャリアの早い段階で、私は「使いやすさ」というアーキテクチャの品質が、エンドユーザーだけではなく、ソフトウェア開発者自身にも関係することを理解しました。開発者が何を成し遂げようとしているかを実証するために、概念実証が必要です。ただし、製品は時間の経過とともに進化する必要があります。私の見解では、MVPの基盤は、開発者が進化を続けることができるように、安定したプロトタイプに基づいて構築されるべきです。

あなたは「オープンソース製品、フレームワーク、言語を使用し、Agileアーキテクチャを組み合わせたオープンソースと商用コンポーネントのミックスは、多くの企業が必要とするがすぐには実現できない機敏性を提供する」と述べています。なぜそう思うのか、詳しく説明できますか？

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

強いコミュニティを持つオープンソースコンポーネントは、販売が簡単です。商業製品は、オープンソースコンポーネントを組み込んでいないか、または特定の商業製品でしか使用されていないオープンソースを使用している場合、トレーニングまたはライセンスが必要になることがあります。

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

また、Apache Sparkなどのコンポーネントは、業界標準のツールとして広く受け入れられているため、コードを商業的な実装間で簡単に移行できます。企業は独自の差別化要素を組み込もうとしますが、開発者は完全に新しい製品を使用することを望まないことが多く、強いコミュニティから切り離されることを望みません。

私の経験から、商用製品を使用することは、有能なサポートを得ることが難しいことがあります。実際、私はオープンソースプロジェクトにプルリクエストを送信し、同じ日にビルドに組み込まれたことがあります。しかし、商用プロジェクトではそうではありません。

あなたはオープンソースが「強力な開発者コミュニティへのアクセス」をもたらすと考えています。いくつかのコミュニティはどれくらい大きいですか？それらが効果的な理由は何ですか？

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

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

あなたは100冊以上の本をウェブサイトでレビューしました。読者に3冊の本を推薦できますか？

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

(1) 私が推奨するO’Reillyの本の1つは「In Search of Database Nirvana」です。著者は、データクエリエンジンがOLTPから分析までのワークロードをサポートするための課題について詳細に説明しています。この本は、データベースエンジンまたはクエリとストレージエンジンの組み合わせを、ワークロード要件に応じて評価するためのガイドとして使用できます。

(2) データスペースでは最近多くの変化が起こっています。新しいデータ分析製品が導入され続けています。「Disruptive Analytics」は、過去50年間の分析におけるイノベーションの歴史を他では見られないほどアプローチしやすく、簡潔にまとめています。スタートアップや分析の実践者にとって、業界を変革することで成功を収めることができます。分析を使用して製品を差別化することは、ビジネスモデルを変革する方法、または新しい市場を作成する方法です。

(3) 私が読んだ最も優れたテクノロジービジネス本の1つは、「The Limits of Strategy」です。著者は、コンピューティングの世界の発展と、企業がこれに適応する必要性について、多くのビジネスリーダーとの会話から詳細なノートを提示しています。私のレビューでは、この本が他の関連書籍と異なる2つの特徴、業界全体の幅と、直接的なやり取りのみで得られる親密さを称賛しています。

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

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

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

プリンシパルアーキテクトとして、私の主な責任は、クライアントのソリューションの提供を推進することです。プロジェクトのアーキテクチャと開発をリードし、製品オーナーとしての役割も担うことがあります。私は、専門知識が必要な場合に、潜在的なクライアントとの議論にも参加します。会社は最近、私にデータプラクティスの他のアーキテクトと定期的なセッションを開始するよう依頼しました。

私のキャリアのほとんどを通じて、私はJavaを使用したオープンソース開発に特化しています。さらに、データ関連の仕事も行っています。私の2つの専門分野に加えて、私は「実践的」または「実用的」と呼ばれるエンタープライズアーキテクチャも行っています。つまり、実際に構築しながらアーキテクチャタスクを実行するということです。

私の見解では、これらの3つの専門分野は相互に排他的ではなく、重なり合っています。私は、エグゼクティブに説明してきました。テクノロジー業界によって従来描かれていたソフトウェア開発とデータワークの間の線は、もうはっきりしていません。ツールが収束したこと、およびこの収束の結果、データワーク自体が主にソフトウェア開発の取り組みになったためです。伝統的なデータの実践者は通常、ソフトウェア開発の背景がないため、そしてその逆もまた然りです。私は、このギャップを埋めるのに役立ちます。

SPRで現在取り組んでいる興味深いプロジェクトについて教えてください。

最近、私は、チームと私は去年、シカゴを拠点とするグローバルコンサルティング会社のCIOのためにAWSからスクラッチで構築したデータプラットフォームについて、複数パートのケーススタディシリーズの最初の投稿を公開しました。このプラットフォームには、データパイプライン、データレイク、規範的なデータモデル、視覚化、および機械学習モデルが含まれており、企業の部門、プラクティス、およびエンドユーザーによって使用されるように設計されています。

コアプラットフォームは、CIOが運営する企業のIT組織によって構築される予定でしたが、目標は、企業全体でデータ資産とデータ分析を中央化し、共通のアーキテクチャを使用して、各組織のユースケースのニーズを満たすために構築できるようにすることでした。また、データ所有権の概念を実装し、組織間でデータを安全かつ一貫した方法で共有できるようにすることも目標でした。

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

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

最近、私は、Databricks Unified Analytics Platformの実装と、Azure HDInsight（Hadoopディストリビューション）から機械学習モデルの実行を移行するプロジェクトをリードしました。これらの移行されたモデルは、さまざまな保険製品に対する消費者の採用レベルの予測を目的としていました。最大の課題は、データ品質の低さでしたが、他の課題には、包括的なバージョニングの欠如、部族的知識と不完全なドキュメント、Databricksのドキュメントとサポートの未熟さ（Azureの実装はプロジェクト開始時点で一般提供されていなかった）がありました。

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

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