データサイエンスノートブックを本番環境に投入しないでください

まず、計算ノートブックとは何かを説明しましょう。ノートブックはWolfram Mathematica言語で始まり、現在はデータサイエンスコミュニティ、特にPythonとRのユーザーの間で非常に人気があります。基本的には、コマンドで構成されるスクリプトと、視覚化およびドキュメントを組み合わせたものです。実行されたコードと結果（テキスト、適切にフォーマットされたテーブル、またはグラフィカルな図）が表示されます。ドキュメントでは何が起こっているのかを説明できるため、チュートリアルに役立ちます。ノートブックは基本的に、より優れたインタラクティブシェルであり、コマンドを保存して変更を加えて簡単に再実行できます。グラフィックや出力は1つのウィンドウに表示され、ファイルに保存したり、他のウィンドウにポップアップしたりすることはありません。インタラクティブセッションは1つのファイルに保存して共有できるため、他の誰もが（特定の条件下で）同じ結果で実行できます。

ノートブックは基本的に2つのことに優れています。インタラクティブな探索作業を行うデータサイエンティストにとって、優れたインタラクティブシェルとなります。また、デモにも適しています。データサイエンスを行うための重要なツールではなく、多くのデータサイエンティストはまったく使用していません。

ノートブックはスプレッドシートの多くの特性を共有し、同じ長所と短所の多くを持っています。まず、長所です。プログラミングスキルがあまりない人でも、有用な定量作業を行うことができます。ノートブックは本質的にスクリプトであり、スクリプトは一般的なプログラミングの最初のステップです。たとえば、Excelでは、数式を使用するなど、スクリプトを使用できます。また、ドラッグアンドドロップ操作だけで、非常に多くの有用な作業を行うことができます。どちらも、ストレージ（コードとデータの両方）、視覚化、およびビジネスロジックの懸念事項を1つのアプリケーションに組み合わせたツールです。

1つのツールで複数の懸念事項をワンストップで処理できることには、長所と短所の両方があります。利点は、単純なことであれば簡単になることです。スタートアップで雇用している12人の従業員の給与を計算するためだけに、データベース、Javaアプリケーション、Javascriptフロントエンドを使用するのはなぜでしょうか？スプレッドシートはまさにそのためにあるのです。しかし、それは、主要な国際銀行の給与処理にスプレッドシートを使用する必要があるという意味ではありません。そして、正当な理由から、それらには使用されていません。それらの状況はより複雑です。変数がはるかに多くなります。監査要件があります。データが非常に大きい場合があります。

人々のチームは、複雑な問題を解決するための大規模なアプリケーションの構築に成功できますが、その複雑さを制御できる場合に限ります。そして、それを行うためのツールはほとんどありません。最も重要なのは、それをより小さく、疎結合の問題に分割することです。プレゼンテーションドメインデータレイヤリングパターンでは、UI、ドメインロジック、およびストレージを分離しています。どのように表示されるか、またはデータにどのようにアクセスされるかに気を取られることなく、計算がどのように実行されるかに焦点を当てることができます。

ノートブックを本番パイプラインに配置すると、事実上すべての実験コードが本番コードベースに配置されます。そのコードの多くは本番環境の動作とは無関係であるため、将来変更を加える人々を混乱させるでしょう。ノートブックは、本番システムに含めるのが危険な、フルパワーのシェルでもあります。安全な操作には再現性と監査可能性が必要であり、一般に本番環境での手動による調整は避けられます。善意のある人でもミスを犯して意図しない害を引き起こす可能性があります。

本番環境に投入する必要があるのは、最終的なドメインロジックと（場合によっては）視覚化です。ほとんどの場合、これは難しくありません。ほとんどのノートブックはそれほど複雑ではないためです。ノートブックは線形スクリプトのみを推奨しており、通常は小さく、簡単に抽出 Gierthして完全なコードベースに配置できます。より複雑な場合、それが機能することをどのようにして知るのでしょうか？これらのスクリプトは数行のコードには適していますが、数十行のコードには適していません。通常は、それをより小さく、モジュール化され、テスト可能な部分に分割して、実際に機能することを確認し、おそらく後で重複することなく他の目的でコードを再利用できるようにする必要があります。

そのため、本番環境でノートブックを直接実行することは、通常はそれほど役に立たず、安全でもないことを主張してきました。構造化コードベースに組み込むことも難しくありません。では、なぜ誰もがノートブックを本番環境に移行する方法について話しているのでしょうか？ 問題の本質は、データサイエンティストとソフトウェア開発者が常によくコミュニケーションをとっているわけではなく、相手が何をする必要があるかを理解しているわけではないということです。多くのデータサイエンティストは、自動化、再現性、監査可能なビルド、徹底的なテストの必要性とプロセス、優れた設計がコードベースのサポートと柔軟性を高める上での重要性など、プロのソフトウェア開発者の懸念事項を本当に理解していません。同様に、多くのソフトウェア開発者は、データサイエンティストが何をしているのかを本当に理解していません。

2種類の 人々は、相手がしていることの 詳細を理解していなくても、うまく協力できることがよくありますが、これは一般的にはそのような状況ではありません。データサイエンティストと開発者が知識を共有し、相手が何をしているのか、なぜそのようにしているのかについてもう少し学ぶことができれば、大きなメリットがあります。 つまり、データサイエンティストはソフトウェア開発を学び、本番ソフトウェアの配信を担当する配信チームに完全に組み込まれるように努めるべきです。この点で完全な能力に達する必要はありませんが、基本を完全に理解し、チームでの作業に最も関連する分野で学び続ける必要があります。

ソフトウェア開発の多くの手法を使用することで、データサイエンティストとしての生産性が実際に向上することがわかります。コードを適切に構造化することで、より複雑なタスクを処理でき、デバッグに費やす時間がはるかに短縮されることがわかります。開発者は、実際に何が起こっているのかについてもう少し理解する時間を取れば、データサイエンスモデルとメソッドをはるかにうまく活用できることに気付くでしょう。どちらも相手の分野で完全に熟練する必要はありませんが、少なくとも基本を理解している必要があります。

ノートブックは、新しいプロジェクトの初期段階で作業しているデータサイエンティストや新しい手法を模索しているデータサイエンティストの主要なアクティビティであるインタラクティブなデータ探索に役立つツールです。ただし、アプローチが決定したら、実験する能力をある程度維持しながら、このアプローチを中心に構造化コードベースを構築することに焦点を移す必要があります。重要なのは、パイプライン自体に実験する機能を組み込むことです。たとえば、実行時またはビルド時にパラメータを変更し、パフォーマンスメトリクスなどの結果をデータストアに格納できる機械学習モデルレジストリを含めることができます。これには、実験はバージョン管理されたコードで実行されるため常に繰り返すことができ、結果が比較のために、また進捗状況を示すマーカーとして保持されるという利点があります。これにより、効果の違いは意図された原因から生じることを示すことができ、これは優れた実験のすべての特徴です。結局のところ、目標は、本番ソフトウェアへのどのような変更がより多くのビジネス価値を生み出すかを学ぶことです。実験環境と実際の実装との間のギャップが小さいほど、変更が実際に価値を生み出すと確信できます。もう1つの重要なアイデアは、データサイエンスパイプラインを構築して、複数の環境、たとえば、本番サーバー、ビルドサーバー、ラップトップなどのローカル環境で実行できるようにすることです。これにより、本番環境で発生していることを妨げることなく、さらに多くの実験の可能性が得られます。

結論として、データサイエンスノートブックを本番環境に移行する方法についての議論は的外れだと考えています。目標は、データサイエンティストとその配信チーム全体が協力して、必要なビジネス機能を提供するソフトウェアを構築しながら、実験と改善の能力を維持できるようにすることです。これには、初期の探索フェーズの後、ノートブックスタイルの開発から脱却し、継続的な統合サポートを必要とする継続的な作業パターンにしないことが必要です。この作業方法は、データサイエンティストが作業中のソフトウェアを継続的に改善できるようにするだけでなく、作業中のソフトウェアを配信し、ビジネス関係者に実際の価値を提供するという責任を負わせるものです。

---