AI時代のデータアーキテクト

🌐 ほかに 28 言語で読めます

English · Español · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

AI で生成した画像

このページはAIで翻訳されています。コミュニティによるレビューはまだ行われていません。 英語で読む

モジュール7／7：Data Architectコース第1章「データアーキテクトのように考える」。各モジュールは単独でも読めます。 前へ：ツールを知る：9つの問い · 次へ：次の章：データモデリング

このモジュールが答える問い： AIはデータアーキテクトにとって何を変え、何を変えないのか？

AIはアーキテクチャを変えます。ただし、多くの人が最初に考えるような形ではないかもしれません。

この章の出発点を思い出してください。私はキャリアの大半をビルダーとして過ごしてきました。その間ずっと、ソフトウェアを作るのは高くつくことでした。専門的なスキルを持つ人が必要で、コードを書くのも、連携を作るのも、アプリケーションを作るのも、テストするのも時間がかかりました。アイデアを試すだけでも、それなりの投資でした。AIはその方程式を変えつつあります。今では、ほしいものを説明すれば、AIがデータモデル、Apex、フロー、Lightningコンポーネント、連携、テスト、ドキュメントを驚くほど速く生成してくれます。そして明日には、さらに多くのことをするでしょう。

ですから、こう問うのはもっともです。構築の多くをAIができるなら、アーキテクトはどうなるのか？　私の答えは、アーキテクチャの重要性は下がるのではなく、上がるということです。

AIはロケットブースターである

講演でこのたとえを使ってきました。

AIはロケットブースター。アーキテクチャは誘導システム。

AIは並外れた加速をもたらします。アプリケーション、データモデル、連携、テスト、ドキュメントを、かつてないほど速く生成できます。しかしロケットブースターは、ロケットがどこへ向かうべきかを決めません。推力を与えるだけです。進路を決め、途中で修正するのは誘導システムです。

しっかりした誘導がなければ、推力が増えても役に立ちません。間違った目的地に早く着くだけです。アーキテクトの仕事は、すべてを遅くすることではありません。正しい方向に加速していることを確かめることです。

画像はAIで生成しました。

以前の10倍の速さでアプリケーションを作るAIツールを想像してください。それが正しいアプリケーションなら、すばらしいことです。しかし、データモデルが間違っていたら？　間違った標準オブジェクトを選んでいたら、マスターデータの置き場所を誤解していたら、あるいは設計が今日のボリュームでは動くのに、ゼロが一つ増えると崩れるとしたら？　AIは間違いを取り除いていません。間違いを速く作り、誰かが気づく前に、その上にずっと多くのものを積み上げる手助けをしたのです。

安い実装は価値の場所を移す

実装が高くつくとき、注意は自然と実装に向かいます。誰が作れるのか、どれくらいかかるのか、そもそも動かせるのか。実装が安くなるにつれて、別の問いがより重要になります。何を作るべきか？　それはアーキテクチャの問いです。

AIは20個のオブジェクトを生成できます。5個にすべきかどうかを決めるのはデータアーキテクトです。AIは連携を生成できます。そもそもデータをコピーすべきかを決めるのはアーキテクトです。AIは数秒で項目を作れます。その項目に明確な意味、所有者、存在する理由があるかを問うのはアーキテクトです。AIは頼まれたものを作るので、何を頼むかの質がかつてないほど重要になっています。

生成は判断ではない

AIは選択肢を生み出すのがとても得意で、それはこのうえなく役に立ちます。私はAIに、何かをモデリングする3つの方法を尋ね、トレードオフを尋ね、アーキテクチャに異を唱えさせ、1億レコードになったら何が起きるか、設計がどこで失敗し得るかを教えてもらい、Salesforceが記録システムではない別案を出してもらいます。アーキテクトにはぜひこうしてほしいと思います。

しかし、選択肢を生み出すことと、それを判断することは別のことです。AIは、選択肢Aと選択肢Bがそれぞれ何をもたらすかを教えてくれます。それでも誰かが、どの利点が重要か、どの制約が本物か、どのリスクなら受け入れられるか、そして技術的にはもっともらしくてもこの組織には間違っている答えはどれかがわかるほど、ビジネスを理解していなければなりません。それが判断であり、それがアーキテクチャです。

私自身の仕事では、それがこう現れています。この1年で、私はほとんど自分でコードを書かなくなりました。AIに詳細を伝え、画面とバックエンドのコードを生成してもらいます。AIはそれが驚くほど上手です。

しかし、AIは一歩引いて、より深く分析的に見ることはしません。データモデルや設計に欠陥があっても、それを問いません。すでにあるものを前提として扱い、その上に素早く、手際よく積み上げていきます。「これを追加する前に、今のモデルを変えたほうがいいかもしれません」と立ち止まることは、めったにありません。今あるものを見て、次のものをその上に作れるかだけでなく、それが正しいのかを問うのは、今でもアーキテクトの仕事です。AIに前提を疑ってほしいなら、そう頼まなければなりません。

可逆性テストは今も当てはまる

モジュール3の問いに戻りましょう。この判断を元に戻すのはどれくらい難しいか？　AIはソフトウェアを生成し変更するコストを変えます。しかし、現実を変えるコストは変えません。1億レコードがロードされれば、それは存在します。12のシステムが識別子に依存すれば、その依存関係は存在します。顧客があるプロセスを使い、分析が項目の意味に依存すれば、それを変えることには結果が伴います。そして、データが共有されるべきでない場所に一度共有されてしまえば、どれだけ新しいコードを書いても元には戻りません。

元に戻せないものは、やはり元に戻せないのです。

エージェントは新しい種類のデータ利用者である

以前、私たちは2種類の利用者に向けてデータを設計していました。人間とソフトウェアです。人がレコードを読み、レポートや連携やアプリケーションがデータを読みます。今では3つ目があります。エージェントです。エージェントはデータを取得し、解釈し、ほかの情報と組み合わせ、判断し、行動します。ときには間に人間がいないこともあります。

これは賭け金を引き上げます。項目が何を意味するか、誰が所有しているか、どれくらい新しく信頼できるか、機密かどうか、エージェントがそれを見られるか、見るべきか、2つのソースが食い違ったら何が起きるか。これらは以前はドキュメントの話でした。今では、インテリジェントなシステムがビジネスを理解する手段そのものです。

そして、悪いデータはAIが読んだからといって賢くはなりません。ゴミを入れればゴミが出る、は今も変わりません。重複した顧客、不明確な所有者、一貫しない識別子、食い違う記録システムは、エージェントをつないでもなくなりません。結果がより目に見えるようになるだけです。人は項目を見て、3年間誰も更新していないことを知っています。エージェントにはそうした組織の暗黙知がなく、みんなが信頼しないほうがいいと内心わかっていたデータに基づいて、自信満々に行動するかもしれません。データアーキテクチャは、AIアーキテクチャの一部になるのです。

スキーマの無秩序な膨張に注意する

AIは、ものを作ることを信じられないほど簡単にもします。オブジェクトがもう一つ、項目があと6つ、自動化がもう一つ必要？　生成すればいいのです。一つひとつの判断は安く見えますが、モジュール3のアーキテクチャの重力を思い出してください。そうしたオブジェクトや項目には依存関係（自動化、連携、レポート、エージェント）が集まり、やがて誰も設計していないデータモデルができあがります。ただ育っただけのモデルです。

アーキテクトは、「本当にこれが必要か？」と問う覚悟を持たなければなりません。最も価値ある判断が、何かを作らないことである場合もあります。よいアーキテクチャは、何を入れるかと同じくらい、何を入れないかにかかっています。

人間によるレビューは儀式ではない

AIが生成したデータモデルを人間のアーキテクトがレビューすべきだと言うとき、それは「AIが作り、スティーブが5分間図を眺めて承認した」という意味ではありません。それは監督ではありません。アーキテクトはモデルを理解しなければなりません。なぜこのオブジェクトなのか、なぜこのリレーションなのか、どんな選択肢を検討したのか、キーとマスターデータはどこにあるのか、ボリュームが増えたら何が起きるのか、アクセスにどんな影響があるのか、どんなトレードオフをしたのか。それに答えられないなら、私はアーキテクチャに責任を持っているのではなく、ただ判を押しただけです。AIはアーキテクチャに貢献し、異を唱え、文書化できます。しかし人間のアーキテクトは、それを弁護できなければなりません。

事実についても同じです。私は学習や調査にいつもAIを使っていて、ルールは信頼しつつ検証するです。質問し、説明を求め、別の選択肢を求め、自分の答えに異を唱えさせます。そして、アーキテクチャにとって重要なことは何であれ、リンクをたどり、ドキュメントを読み、制限を確認し、ライセンスを確かめ、振る舞いをテストします。AIは間違っているときにもとても説得力があります。事実と前提を見分けることは、今では仕事のさらに大きな部分になっています。

AIは道のりを短くしない

アーキテクトになることについて話すとき、私が使う言葉があります。

AIは道のりを短くはしない。一歩一歩をより価値あるものにできる。

データ、セキュリティ、連携、プラットフォーム、そしてビジネスを理解する必要は変わりません。判断を下し、その結果と付き合っていく経験も、やはり必要です。AIは学びを速め、出会ったことのないシナリオを見せ、説明し、あなたに異を唱え、構築を手伝い、もう一組の目になってくれます。すべて活用しましょう。ただ、答えを知っているAIと、答えを理解しているあなたとを混同しないでください。

アーキテクトが指揮する

この章は、設計図を手にしている人から始めました。AIはその人に、並外れた新しい道具を与えます。設計図の一部を描き、資材を調べ、別案を提案し、荷重を計算し、ドキュメントを書き、見落とした問題を見つけることさえできるアシスタントです。使いましょう。しかしそれでも誰かが、建物全体を理解し、それが正しい建物なのかを問い、要件が変わったら何が起きるか、どの判断が元に戻すのに高くつくかを知り、結果に責任を持たなければなりません。

だから、このコースの最後のレベルは**Direct（指揮する）**と呼ばれています。あなたはすべてのコードを書き、すべてのフローを作り、すべてのオブジェクトを構築するわけではないかもしれません。それでも誰かが解決策を指揮しなければならず、それがアーキテクトです。AIはアーキテクチャをなくしているのではありません。アーキテクトが価値を生む場所を変えているのです。アーキテクトになるには、またとない時代です。

ここでアーキテクトが決めること

• 作ることが安くなった今、そもそも何を作るべきか：どのオブジェクト、項目、連携がその場所に値するか。
• AIが生成した選択肢のうち、どれがこのビジネスに合い、どれがもっともらしいが間違っているか。
• 元に戻すのが高くつく判断のうち、AIが猛スピードで通り過ぎているのはどれか。
• エージェントが何を読み、何に基づいて行動してよいか。そして、データがそのために十分に質がよく、十分に説明されているか。
• AIから得た事実のうち、設計に反映させる前に検証が必要なのはどれか。

それが、AI時代にアーキテクトのように考えるということです。