[レポート] Infrastructure-as-Code and the Modern Data Experience (IaCとモダンデータエクスペリエンス) #futuredata

大阪オフィスの玉井です。

2021年10月13日 午前9時～午後3時（米国太平洋標準時）、Future Dataというデータ分析に関するオンラインカンファレンスが開催されました。

この記事では、このイベントの「Infrastructure-as-Code and the Modern Data Experience」というセッションのレポートをお届けします。

セッション情報

登壇者

Tristan Handy氏（Founder and CEO, dbt Labs）

概要

The devops movement transformed system administration--once manual, painstaking work--into scalable software. One of the key breakthroughs: developing a common way to "script" behaviors across a whole set of tools so as to create coherent end-to-end workflows for their users (software developers). In the modern data stack we haven't gotten there yet, and a proliferation of disconnected tools is one of the drags on the productivity of data professionals—even those with cutting-edge tooling. Is there a path towards changing this?

DevOpsムーブメントは、かつて手作業で行われていたシステム管理を、スケーラブルなソフトウェアに変えるものでした。それは、ユーザー（ソフトウェア開発者）にとって一貫したエンド・ツー・エンドのワークフローを作成するために、一連のツール全体で動作を「スクリプト」で動作する共通の方法を開発することでした。モダンデータスタックでは、まだそのような状況には至っておらず、最先端のツールを使っている人でも、バラバラのツールが蔓延していることが、データ分析の専門家の生産性を低下させています。この状況を打破する道はあるのでしょうか？

セッションレポート

※レポート文のみ、一人称は登壇者を指します。

前段（アジェンダ紹介含む）

去年のFuture Dataでは、モダンデータスタックの過去、現在、未来について発表することができて、とても楽しかったです。

そこで、今回は、あるアイデアを提案しました。私は、モダンデータエクスペリエンスにおけるDevOpsについて話そうと思いました。そうしたら、先ほどのBenn氏から、彼もモダンデータエクスペリエンスに関する講演をするという話を聞きました。そこで、彼に「あなたが先に発表するのか、私が先に発表するのか」と尋ねました。すると、彼は「自分が先にする」と言いました。私は、これは大きな問題だと思いました。そして、私はこのイベントを辞退しました。

いや、これは冗談ですよ。Benn氏が皆さんに落とした知恵に、私が付け加えることがあればいいのですが。

この話題に関して、私にはほとんど信頼性がないという事実をまず確認しておきたいと思います。

私は、DevOpsのワークフローを熟知しているわけではありません。私自身はDevOpsを実践しているわけではありませんし、ソフトウェアエンジニアでもありません。私はデータアナリストであり、今ではアナリティクスエンジニアと呼ばれているかもしれません。

にもかかわらず、このテーマが有益で関連性があると思う理由は、データ分析の専門家として、DevOpsから適応すべきプラクティスがたくさんあると思うからです。自分のワークフローに正確にコピー＆ペーストすることはできないかもしれませんが、多くの問題を解決するためにDevOpsが使用しているメンタリティや考え方を採用することは確かです。

そこでまず、問題を定義することから始めたいと思います。これまでにBenn氏が少しずつ話していると思いますが、私はモダンデータスタックの問題点を自分なりに把握したいと思っています。

今日は、DevOpsとは何かについて少し話し、ベストプラクティスのDevOpsワークフローの中で仕事をすることが、どのような感じなのかを伝え、その洞察を今日の仕事のやり方に取り入れてみたいと思います。

モダンデータスタックの問題点

これは、私たちdbt labs社のウェブサイトに掲載されているモダンデータスタックの新しいグラフィックです。しかし、弊社の優秀なマーケティングチームは残念がっていましたが、私は去年iPadで書いた画像を使いたいと思っています（次のスライドがそれ）。

去年の講演でもこの画像を使いましたが、シンプルでフラットな良い画像だと思います。

興味深いのは、多くのことが変わったということです。dbtのロゴが更新されただけでなく、スタックのさまざまなレイヤーに新しいロゴが入っています。さらには、1年前にエコシステムの意識の中に入ってきたばかりの新しいレイヤーもあると言っていいでしょう。これを何と呼ぶかは人それぞれですが、リバースETLと呼ぶこともできますし、オペレーショナルアナリティクスと呼ぶこともできます。

現在では、分析システムからの出力を業務システムに戻して、このループを完成させることができるようになっています。このような変化は今後も続くでしょう。このエコシステムに関わっている人なら誰でも知っているように、今は非常に大きな変化の時期で、常に新しいツールや新しい機能が登場しています。昨年、私はこれを「カンブリア紀」、「第二のカンブリア爆発」と呼びました。

そして、すべてのエコシステムが成立するためには、規格が必要です。ほとんどのソフトウェア会社は、実際にはエコシステムの中には存在しません。ほとんどのツールは孤立していて、他のツールとの統合も薄く、脆いものです。しかし、モダンデータスタックは、最初からSQLという標準規格に基づいて構築されています。これは素晴らしいハックです。つまり、膨大な量の統合作業をしなくても、多くのものを素早く連携させることができるのです。

dbtが誕生したのは、dbtと統合するように誰かを説得する必要がなかったからです。FivetranやStitch、ModeやLookerにdbtと統合するように説得する必要はありませんでした。まずRedshiftと統合し、その後BigQueryやSnowflakeなどと統合する方法を見つけ出しました。また、SQLテーブルの読み書き方法もわかりました。これは素晴らしいことで、スタック内のすべてのツールがSQLテーブルとビューの書き方を知っていれば、大量の統合を維持しなくても多くのことができるスタックができあがるということですが、これはほとんどの場合、実際には起こりません。

問題は、SQLのテーブルやビューを使って統合することは、あまりコンテキストがわかりやすい方法ではないということです。

dbtは上流に存在するデータを読むことができます。LookerやModeなどは、dbtが生成したテーブルにあるデータを読むことができますが。Lookerのユーザーとしては、実際には多くのことを知ることができません。このデータがどこから来たのかわかりませんし、最近更新されたかどうかもわかりません。質の良いデータかどうかもわかりません。

同様に、あなたがFivetranのユーザーであれば 、下流のLookerユーザーのことはあまり知らないでしょう。このデータを削除してもいいのかどうかもわかりません。なぜなら、そもそも誰が使っているのかもわからないからです。

このように、スタックの両端から、コンテキストが欠如していることがわかり、それが実際に仕事をする上での障害となっているのです。人々がスタック間でコラボレーションを行う方法は、非常にローテクで古風なものです。会議でコラボレーションしたり、Slackでコラボレーションしたり、JIRAのチケットでコラボレーションしたりしています。なぜなら、他の仕事をしている人たちの世界を理解する能力が限られているからです。

私よりもはるかに賢い人が、1つのツイートでこのことを指摘しました。私の10分間の問題点のまとめは、Erik氏にもっとよく要約してもらうことができました。

私たちがこれほど多くの役割を持ち、日々役割が増えているように見えるのは、実は良いことではありません。なぜなら、もしこれらの人々が一緒に仕事をする能力がなければ、実際にはコミュニケーションの壁を作っていることになるからです。

アナリティクスエンジニアであることを自称するのは好きだと最初に言いましたが、この講演の冒頭で、文字通り私のキャリア全体の中で初めて、自分の仕事や好きなことを定義する言葉があるような気がする、と言いました。

しかし、データをソースからターゲットにマッピングするために、このグラフィックに7つの異なる役割を持たせる必要があるという事実は、バリューチェーンに多くの人間が関わっていることを意味しています。もし私たちがここでやっていることが、組織のナレッジグラフを構築することであるならば、私たちは全員、そのナレッジグラフを読み書きできる必要があります。

この週末のメルマガでこのことを書いたのですが、私は話し手よりも書き手のほうがずっと上手です。だからこそ、このことをきちんと伝えたいと思ったのです。だから、これをそのまま読むことにします。

想像してみてください。あなたの会社が今、人間社会で、人口の半分しか文字を読むことができず、10人に1人が文字を書くことができ、6種類の言語が話されていて、図書館にあるほとんどの本には、かつては真実だったが、今では時代遅れになってしまったことが書かれているとします。そして、どれが生産性の高い情報エコシステムではないのか、わからないのです。しかし、それが今の世界なのです。

この10年間のプロジェクトが技術的なものであれば、大量のデータを保存して処理することができたと思います。次の10年のプロジェクトは、すべてのナレッジワーカー、つまり誰もがアクセスできる、知識の創造とキュレーションのシステムを構築することです。誰もが読み書きできるようにしなければなりません。すべての知識は整理され、発見可能で、信頼できるものでなければなりません。

今のところ、これまでDevOpsの話は全くしてきませんでしたね。今日は「DevOpsの話をする」と言ったので、いよいよDevOpsの話を始めたいと思います。

DevOpsとは？

DevOpsとは、「Software Development」と「IT Operations」を組み合わせた造語です。

私よりもさらに詳しくない人のために説明すると、そもそもDevOpsとは、2つのグループの人間を共通の業務に結びつけ、共通のツールと共通の作業方法を与えることです。DevOpsにはいくつかの基本的な考え方があります。

DevOpsは、人によってまとめ方が違うと思います。しかし、私が最も重要だと考えているのは「Infrastructure is code」です。すべてのインフラを、文字通りあらゆる設定を記述したファイルにまとめることができます。

他にも、メインブランチにコミットしているコードを検証したり、本番環境に自動的にデプロイしたりする「CI/CD」パイプラインや、ボタンをいくつもクリックしなくても済む「Automation」ツール、ソフトウェアエンジニアが、より高い抽象度で仕事ができるようにするための自動化された「Version Control」など、dbtユーザーなら誰でも知っていることばかりです。dbtユーザーであれば、すべての作業がバージョン管理されていることにどれだけ関心があることでしょう。「Idempotency（冪等性）」も重要ですが、これもまた、今回の講演では深く掘り下げられないような内容です。

しかし基本的には、何らかの処理を何回実行しても、同じ環境で同じ結果を得ることができる能力のことです。そして「Replicability」とは、同じプロセスを使って、同じように見える2つのものを確実に作ることができるということです。

以上、DevOpsの主要部分を最高レベルでまとめてみましたが、いかがでしたでしょうか。信頼性の高いシステムを作り始めましょう。

…いや、冗談ですよ。

私にとって重要なのは、DevOpsの実践方法の詳細よりも、この方法で仕事をする際の感覚があるか、ということです。そして、それを毎日やっているわけではない人たちに伝えられないかと考えています。

そこで今回は、「マイクロサービスを作りたい」というところからスタートして、最終的にそれをみんなにデプロイするまでのワークフローをご紹介します。

まず最初に、サービスを構築するためのインフラを用意しなければなりません。そのためには、インフラの担当者が必要です。そして、ソフトウェアエンジニアが一堂に会します。そして共同で作業を行い、すべてをコードで記述し、テストして、ロールアウトすると、チームの他のメンバーはそれにアクセスできるようになります。

一人のフルスタックのソフトウェアエンジニアが、そのマイクロサービスに必要なインフラ全体を立ち上げることができます。それは、8つの異なるコンポーネント…データベース、ウェブサーバー、もしかしたらネットワークを含むVPC全体かもしれませんが、とにかく、基盤となるインフラの複雑さは関係ありません。なぜなら、それはコードで完全に記述されており、ソフトウェアエンジニアがTerraformを適用するようにデプロイすることができるからです。そして、開発を開始するためにすべてを立ち上げます。他のメンバーは、その仕組みの詳細を知る必要はありません。

フルスタックのソフトウェアエンジニアだけがコードを書いているだけではありません。

フロントエンドのエンジニアは、デザイナーと協力してフロントエンドのコンポーネントを作るようになりました。これをコンポーネントライブラリで再利用可能な方法で行っています。これらは、現在、featureブランチに入っています。

こうなると、チームはすぐに走り出すことができます。チームが論理的な作業を行うたびに、ソースコントロールにコードをコミットしていきます。そして、CIパイプラインが自動でそれをテストし、書かれたコードにエラーがないことを確認します。

これで、ユーザーの皆様にサービスをお届けする準備が整いました。そして、リリース候補ができました。そこで、mainブランチにPull Requestを提出します。mainブランチにPull Requestが提出されたという動き1つで、ステージング環境が作成され、mainブランチのコードが本番環境のコピーである専用のハードウェアで実行されるようになりました。そしてユーザーは、完全に動作しているアプリケーションと対話し、その感触を確かめたり、遊んだり、壊してみたり、フィードバックを与えたりすることができるようになります。

ユーザーがステージング環境の仕様に満足した後、すべてはCI/CDを経てfeatureフラグを立ててリリースされます。このfeatureフラグは、最初は5％のユーザーがこの機能にアクセスできるようになっているかもしれません。この数値は計測され、順調に進んだ場合は1週間かけて全ユーザーに展開されます。

そして最後に、社内のソフトウェアエンジニアリングチームの他のメンバーは、このマイクロサービスが表示されただけで、その機能を使うことができるようになります。

さて、たくさんありましたね。これらを見ていると、今日の私たちの（データ分析の）ワークフローとの類似点が見えてくると思います。そして、先ほど私が説明したワークフローと照らし合わせてみると、私たちのワークフロー（データ分析）では落ちている点が本当にたくさんあるのです。それを次に紹介したいと思います。

DevOpsから学べること（データ分析にも適用できること）

まず、このアプローチを真似することはできないことを明確にしておきたいです。データ分析はソフトウェアエンジニアリングではありません。そうなんです。ソフトウェアエンジニアリングには似た特徴がたくさんあり、ソフトウェアエンジニアリングやDevOpsのワークフローから多くのことを学べると思います。しかし、それをそっくりそのままコピーすることはできません。

では、ここで行われている本当の「原則」は何なのかを考えてみましょう。そして、それを私たちがやっていることにどのように適用できるのでしょうか。

#1 build (and use) multi-persona tools

まず1つ目は、DevOpsとは「Software Development」と「IT Operations」を組み合わせたものであるという話をしたことです。私は、データ分析には、もっと多くのマルチなペルソナツールが必要だと思っています。さまざまな専門分野を持つユーザーが集まることで生まれる創造性は、本当に素晴らしいものです。

DevOpsは、1つのペルソナではなく、2つのペルソナを想定して設計することで問題を解決します。ソフトウェアエンジニアは、昔は、チケットを提出し、インフラエンジニアがステージング環境を構築したり、コードをデプロイしたりするのを待たなければなりませんでした。今では、ソフトウェアエンジニアとインフラエンジニアの両方が、共有ツールを使って協力してインフラを構築し、管理しています。ボトルネックや宗教的な争いはなく、共有された空間とコラボレーションだけがあります。

先ほどのシナリオで言うと、このプロセスには6人の異なる人間が参加しています。コードを書くソフトウェアエンジニア、インフラを整備するインフラエンジニア、コードがfeatureフラグとしてユーザーに提供されたときに、すべてがうまくいっているかどうかを確認するデータ担当者、製品が思ったとおりになっているかどうかを評価するプロダクトマネージャー、ステージング環境や開発環境をクリックして回っていたであろうデザイナー、フロントエンドのコンポーネントを設計するデザイナー、そして、「はい、これを使いたいです」「いいえ、使いたくありません」と言うエンドユーザーですね。

このワークフローは、ソフトウェア開発のライフサイクル全体の摩擦を最小限に抑えるように作られています。そして、すべてのペルソナができるだけ摩擦を少なくして、自分のやりたいことを実現できるようにしています。

良いニュースがあります。私たちが現在使用している最も成功しているツールのいくつかが、すでにマルチペルソナであるということです。ちなみに、このスライドは、それらをすべてを網羅したリストではないことに気をつけてください。

dbtの当初の目的は、データアナリストとデータエンジニアの仕事を組み合わせ、この2つのペルソナがそれぞれの領域を超えて協力し合えるようにすることでした。Modeでは、データアナリスト、データサイエンティスト、意思決定者の間でそのようなことが実現しています。Lookerも同様に、アナリティクスエンジニア、データアナリスト、意思決定者の3者が協力して作業を進めることができるようになっています。しかし、この分野で前進するために、私たちにできることはまだたくさんあります。

このテーマについて考えていたとき、そして講演の内容を考えていたとき、私はこの質問に夢中になっていました。「マルチペルソナのスプレッドシートを作るにはどうしたらいいだろう？」

スプレッドシートは、現存する最もポピュラーなデータツールであることは周知の事実であり、今後もそうであり続けるでしょう。そして、意思決定者のお気に入りのツールであることは確かです。では、複数のペルソナに対応し、アナリティクスエンジニアも使えるスプレッドシートを作ったらどうなるでしょうか。

まず最初にやるべきことは、データウェアハウスへの問い合わせのためのネイティブインターフェースを構築することだと思います。StackOverflowの投稿をたくさん読めばわかるような面倒なものではなく、SQLテーブルからデータを取得してシートにダンプするような方法です。そしてそれを最新の状態に保ちます。

さて、ここからが本番です。dbtにネイティブで参加できるようにしたらどうでしょう。スプレッドシートが上流のモデルを参照できたらどうでしょう。しかし、下流のオブジェクトノードも、他のモデルであれ、他のスプレッドシートであれ、参照できたらどうでしょう。それらもこのシートを参照できるとしたらどうでしょう。

そして、最後にファイルフォーマットです。スプレッドシートにはデータと計算の両方が含まれていることは周知の通りです。もし、データとは別に計算結果をまとめる方法があったらどうでしょうか。そして、それを人間が読みやすい方法で行い、スプレッドシート内のコードをPull Requestでレビューできるようにしたらどうでしょうか。このようなことを考え始めると、自分が使いたいスプレッドシートのように思えてきました。

しかし、もっと踏み込んで、データサイエンティストというペルソナを加えることもできると思います。どうすればいいのでしょうか。

とても簡単にできると思います。Excelスタイルの数式に加えて、RやPythonの関数を追加し、さらにSparkなどの分散コンピューティングフレームワークにネイティブでアクセスできるようにすることができると思います。

そして、スプレッドシートにデータエンジニアを追加したらどうでしょう。これはとても簡単なことだと思います。

すべてのスプレッドシートには入力セルがあり、大規模で複雑なモデルを実行して、その反対側で何かを考えます。その全てをRESTful APIとして提供したらどうでしょう。そうすれば、人間が行っていた作業が、サービス指向アーキテクチャの一部としてアクセスできるようになります。これこそが必要なことなのかもしれませんね。

しかし、もっと重要なことは、複数のペルソナを持つ人たちで問題を解決しようとすることは、非常に生産的であるということです。私は、このことについて時間をかけて考えたわけではありません。ただ、「Excelをマルチペルソナで再現するにはどうしたらいいでしょうか？」みたいな質問をする余地は、他の分野でも、たくさんあると思います。

#2 refuse to click buttons

さて、2つ目のポイントは、「ボタンをクリックしない」（ようにする）ことです。

これはInfrastructure as Codeのことで、これは、DevOpsの最も中心的なテナントです。何が起こっているのか見てみましょう。

スライドはTerraformの設定ファイルです。Terraformは、インフラをコードで記述し、それをクラウドアカウント内に明示する業界標準の方法となっています。

右側には、TerraformのConfigファイルのスニペットがあります。ここで何が起こっているのか、お分かりいただけると思います。どのリージョンでこのインフラを実行するかを記述し、一番下にはVPCのingressルールが表示されていて、異なるコンポーネントを記述しています。

すべてのインフラをコード化することには、実に素晴らしい特徴があります。まず、インフラに対するすべての変更を管理することができます。すべての変更を、誰が行ったか、ソースコントロールでチェックされているからです。また、環境を簡単に複製することができます。本番環境への適用が可能であれば、ステージング環境への適用も同様に簡単です。そして、本番環境とその他の環境との間には、これまでのような大きな乖離は見られず、信頼性の高い複製が可能になります。

しかし、モダンデータスタックでは、かなり矛盾しているのですが、このために必要なことは、プロセスに関わるすべてのツールが、APIを介して完全に制御可能でなければならないということです。

Terraformは多くのことを指揮します。しかし、Terraformに「簡単な仮想インスタンスを立ち上げてくれ」と言っても、TerraformはEC2インスタンスを立ち上げる方法を知りません。しかし、TerraformはAWS APIを呼び出し、AWSにEC2インスタンスを立ち上げてもらう方法は知っています。もしAWSがそのAPIを持っていなかったら、Terraformは完全にそのことができなくなってしまいます。ですから、エコシステムとしては、APIのカバー率は不安定です。うまくいくときもあれば、そうでないときもあります。これは、私が改善に力を入れている分野のひとつです。dbt Cloudに限って言えば、APIのカバー率は非常に高いのですが、ドキュメントの充実度はやや劣ると思います。また、存在するテラフォーム・プロバイダーはあまり使われておらず、おそらくあまり戦力になっていないと思います。

スライドに表示しているのは、FivetranのTerraform Providerですが、彼らは最近これに本格的に取り組み始めていて、たくさんインストールされています。他にもいろいろありますが、これはエコシステムとして急速に成熟するために必要な方法だと思っています。

スライドの一番下にリンクがありますが、Sarah氏は10月末にこのテーマで講演をする予定です。この件で難しいと思うことの1つは、ユーザーとして、私たちはある種、今日の物事の動き方に慣れているということです。そのため、インフラの構成を変えることでどのようなメリットがあるのか、想像するのが少し難しいのです。

ここで私が期待していることの一つは、Terraformの構成が、文字通り監視対象のデータスタック全体を端から端まで記述したものになっていて、「Terraformを適用」を押すだけで、モダンデータスタック全体を手に入れることができるとしたらどうだろうか、ということです。

ソフトウェアエンジニアリングでは、このようにしています。私たちの世界でも同じようにできないはずがありません。また、開発環境、ステージング環境、本番環境を一貫して構築できるという点でも、非常に優れています。

#3 kill your darlings

最後は「Kill your darlings」です。変な名前のテーマですね。

私はdeleteキーに恋をしています。

私はこれまでの人生で、たくさんの文章を書いてきました。そして、書くことが楽しいと感じるようになったのは、2003年にブロガーになったときでした。ブログを書くことが楽しくなったのは、何か気に入らないことがあれば、簡単に削除して、何でもコストをかけずに書き直すことができたからです。紙と鉛筆で書いていた時代からブログに移行すると、それでは面白くないし、何かを編集する必要があると気付いたときには大変な作業になっていました。不思議なことに、簡単に削除できる方が、よりクリエイティブな文章を書けるんです。

作家のスティーブン・キング氏はこのように言っています。

最愛の人（キャラクター）を殺しなさい。たとえそれがあたなの中に存在する自己中心的で小さな乱筆家の心を壊すとしても。最愛の人を殺しなさい。

今日の私たちのテクノロジー環境のおかしなところは、私たちが行うあらゆる小さなことを手作業で設定し、それに気を配っていることです。すべてが愛情を込めて設定されています。そして何が起こるかというと、すべてのものが壊れやすくなるのです。

DevOpsでは、実際にこのような言い方をしています。ペットファースト、ペットは愛すべきもの、大切なもの、かけがえのないもののようなものですが、牛は産業プロセスの一部なのです。

工業的農業をどう思うかは別にして、MITにはそのような世界に対する考え方のある種の効率性があると言えます。この世界では、サーバーが故障しても、別のサーバーと交換すればよいのです。そして、サーバーの名前を知り、愛情を持って世話をすることにあまりストレスを感じないのです。

これは、dbtとModeで実現しています。dbtはすべてがバージョン管理されているので、あるブランチをチェックアウトして、それを使って実験して、それがまったくの行き止まりだったことに気づいて、全体をゴミ箱に捨ててしまうことができます。

Modeでは、それが少し難しくなります。これはModeに限ったことではありません。これは、BIツールのエコシステム全体がこのように機能しているということです。実験の方法は、何かをコピーして、その中で遊びまくるというものです。そして、それが新しい良いものになるか、あるいは、それが実際にはうまくいかなかったことに気づくかのどちらかです。そして今、あなたの本番インスタンスを詰まらせているものがあるのです。もし私たちが削除することに真剣に取り組んでいたら、Modeアカウントに加えた変更をすべて含んだブランチをGitに隠しておく方法があったらいいと思います。本番環境ではないかもしれないけれど、完全にゴミ箱に入れてしまうのも嫌ですよね。

皆さんへのお願いですが、もしこの中に興味を引くようなものがあれば、実験して、今日、何が可能かを考えてみてください。私たちは、ここでは何が良いことなのか、実際にはわからないと思います。あなたが実験したことは、コミュティやTerraform Providerをサポートするのに役立ちます。ベンダーがあなたの必要とするものをサポートするのに十分なAPI機能を持っていない場合は、ベンダーに言いましょう。

そして最終的には、今回私が話したビジョンをサポートするベンダーを選んでください。

おわりに

Lookerというツールが出てきたあたりから、社内でも話題に上がったのですが、データ分析の領域でも「あらゆる作業のコード化」が進んできている気がしています。結局のところ、ITにおける柔軟な作業を行おうとすると、GUIでは限界があり、コードによる操作や管理の方が合っているのではないでしょうか。コードといっても、複雑なロジックをゴリゴリ組むわけではなく、各種設定や定義を文字として記述していくという形なので、データ分析に関わる方は、今のうちにコードで管理することに慣れておいた方がいいかもしれません（今後もそういうツールが出てくると思われる）。