ソフトウェア開発をよりよいものにしていくための取り組みのひとつとして Platform Engineering という考え方がある。
厳密な定義は存在しないようだが、概ね、社内の開発者向けにプラットフォームやツールを提供したり、それらに対するイネーブルメントを行ったりするような活動を指す。
Platform Engineering という考え方が生まれた背景には、ソフトウェア開発の高度化・複雑化がある。単に技術やツールが増えていくだけでなく、開発プロセスや運用に関しても様々なプラクティスが生まれ、開発者が「すべきこと」「やるとよいとされること」は飛躍的に増えた。ソフトウェア開発を成功させるためには狭義の「開発」だけを行っていてはいけないとされ、様々な領域に対して習熟し実践することが求められるようになった。その結果、開発者の認知負荷は高まり続け、疲弊を生んでしまっている。
Platform Engineering は、適切に抽象化されたプラットフォームを提供し複雑さを隠蔽することで、そのような状況の解決を目指す。プラットフォームの構築や運用を通して、開発者体験を向上させ、開発者がより価値のある取り組みにフォーカスできる状態を作り出していく。
私は現在データプラットフォームの構築や運用を行っているが、その名の通りデータプラットフォームもプラットフォームであり、Platform Engineering の考え方を適用できると考えている。
よりよいプラットフォームを提供し、データを利活用したい人がより安全かつ便利に利活用できるようになること、データ利活用体験が向上することを目指す。データチームの役割をそのように捉えることができる。
最近取り組んだ 2 つの施策も、プラットフォームの改善と解釈することができると思っている。
非開発者でも dbt を利用しやすくする
勤務先ではデータウェアハウスとして BigQuery を採用しており、 dbt でデータの加工を行っている。社内でのデータ集計や可視化には Metabase という BI ツールを利用している。
Metabase は職種問わず社内で広く利用されているが、 Metabase では完結せず dbt を使ってデータの加工を行いたいケースもある。そのようなときは dbt プロジェクトを管理しているリポジトリに Pull Request を出してもらい、それをデータチームがレビューするのだが、非開発者が Pull Request を出すのが難しいという問題があった。
まず、ローカルマシンに開発環境をセットアップするのが難しい。手順を記したドキュメントは社内に存在し、時間と手間をかければ非開発者でもできるが、簡便とは言い難いのが現状。
そして、git を覚えなければならない。全く馴染みのないところから git を理解するのはハードルが高い。commit して push する、くらいなら何とかなるかもしれないが、例えば「デフォルトブランチを rebase してから push し直して欲しい」みたいなケースも発生し、そうするとどんどん難易度が上がっていく。そもそも dbt による加工をやりたいのであって、git を操作したいわけではない。興味や意欲がある人が取り組むのはよいが、そうでない人も習得を強いられるのは望ましくない。それこそ認知負荷が無駄に高い状態だと言える。
弊社では、データチームがひたすら依頼を受けて集計や可視化のための作業をこなしていくのではなく、データ利活用のニーズを持っているチームが自分たちで対応していくことを志向している。そしてそれをかなり高いレベルで実現できてるチームも存在する。
しかし、チームによって状況にはバラツキがあるし、上手くいっているチーム内でも負荷の偏りなどがあるのではないかと思っている。当事者が自分たちでニーズを満たしていけるようなプラットフォームにしていくにあたり、上記の開発環境や git の問題がハードルのひとつになっていた。
AI エージェント、具体的には Devin によって、この状況を改善できる兆しが生まれた。具体的な作業は Devin にさせることで開発環境の構築は不要になるし、git も隠蔽できる。なお、Devin の導入はデータチームが主導したわけではなく、全社的な取り組みとして推進されている。Devin の導入やセットアップについてはこの記事では扱わない。いつか社内の誰かが書くかもしれない。
折よく dbt を触りたいというニーズが一部の非開発者に生まれたので、Devin を使って Pull Request を出してもらうことにした。
もちろん「Devin を使って Pull Request を出してください」と言うだけで上手くいくはずがない。この文脈で Devin を使うのは開発環境構築や git の習得をスキップするためであり、「どんな Pull Request を出せばいいか分からないから代わりにやってもらうため」ではない。「目的を達成するためにはどんなファイルを書けばよいか、どんな Pull Request を出せばよいか」は、Devin に指示を出す人間が分かっている必要がある。
そのため、これを機に社内ドキュメントの拡充を進めた。発生していたニーズに即したドキュメントも書いたが、それ以上に、データプラットフォームの全体像を理解しメンタルモデルを構築できるようになるための文書を書くことに力を入れた。それがなく細かい作業内容が書かれたドキュメントだけだと、自身が行う作業の全体像や意味を掴みづらく、何のために何をやるべきなのかイメージしづらい。
各種ドキュメントは全て Cosense（旧 Scrapbox ）に書いているのだが、LLM に渡すためのテキストファイルを出力する機能が Cosense にはあり、それで出力した内容を NotebookLM に渡して Notebook を作ってみたりもした。
ドキュメントを書いたり Notebook を作ったりする際は「文脈」を提供することを意識した。
個別の技術（dbt なり SQL なり BigQuery なり）については、ネット上にいくらでも資料があるし、今の時代は AI に聞いてもいい。特に AI は、何度しつこく質問を繰り返しても対応してくれる。
しかしネット上には存在せず、汎用的な AI チャット（ChatGPT, Claude, Gemini など）は教えてくれないことがある。
それは、文脈に応じた回答。汎用的な AI チャットは、「あなたの組織では」「あなたの環境では」という個別の文脈に応じた回答をすることが難しい。文脈に応じた回答を得るには、質問者側が文脈を制御する必要があるが、初学者が文脈を示すのは困難だと思う。
また、内容によっては汎用的な AI チャットには答えようがないものもある。どんな技術も、個人や組織によって、使い方・用途・設定内容・他の技術との依存関係、などは多かれ少なかれ異なるわけだが、質問者の勤務先ではどうなっているのかについて、汎用的な AI チャットは知る由もない。一般論で返すしかない。
だからこそ社内のドキュメントでは、自社では A という技術をこう使っている、この目的のために技術 B が必要、といった情報を提供するとよいのではないかと思っている。A や B そのものについて解説するのではなく、A や B をどう使っているのか、それらは全体のなかでどういう位置付けなのか、という文脈を提供する。そういった知識さえ提供できれば、あとは汎用的な AI チャットを使うなどして各自が学習や調査を進められるようになるのではないかと考えている。
ドキュメンテーションの他にも、開発環境を用意しなくても dbt-osmosis を使えるようにするなどの整備を進めた。
今日現在で既に複数の非開発者が Pull Request を出してマージされるに至っている。
ドキュメントや Notebook はもちろん開発者向けの資料としても役に立っている。
dbt を使った開発をフレンドリーなものにしていくことはデータ利活用を促進する上で重要であるため、引き続きやっていきたい。
AI に SQL クエリを作らせる仕組みを整備する
既述したように勤務先では Metabase という BI ツールを利用している。GUI で SQL クエリを構築できるので、SQL の知識が浅い人でも自分で集計やビジュアライズを行える。
しかし SQL クエリを書いたり GUI で BI ツールを弄ったりするのではなく自然言語（日本語）によって集計や分析を行えるなら、それに越したことはない。SQL クエリを書くこと自体は目的ではないので、それを隠蔽できるのならしてしまいたい。そして LLM なら、ある程度はそれができるはずである。以前バイブコーディングの文脈で SQL ファイルを書かせたことがあるが、かなり精度が高かった。
しかし業務で同様のことをやる場合、かなり慎重に進める必要がある。具体的には、データの取り扱いに注意を払わないといけない。我々が保持しているデータを漫然と LLM に渡すわけにはいかない。
そのため、「AI ツールがアクセスしてもよい領域」を用意して、問題のないデータのみをそこに投入、AI ツールにはその領域に対するアクセス権のみを渡す方針を考えた。
しかしこのアプローチだと、どうしても時間が掛かる。どのようなデータはどのような理由・判断で LLM に渡す（渡さない）のかを社内で整理・確認しながら進めていくことになるが、慎重さが求められるので、すぐに大きな進捗を出すのは難しい。そして、ごく一部の種類のデータが断片的に入っていても、実用性は乏しい。そもそものやりたいことである「日本語で集計や分析を行う」の実現には、時間が掛かりそうだった。
どうしたもんかなと思っていたところ、同僚から「メタデータだけを AI ツールに渡すようにするといいのでは」という趣旨の意見をもらった。確かにそれなら進めやすそうだと感じたので、まずはその方針で進めてみることにした。
まず、ダミーのテーブルやデータしか存在しない検証環境を用意して、やりたいことを実現できそうか検証した。メタデータ（どのようなテーブルやカラムが存在するのか、テーブルやカラムの description、など）だけを AI ツールに渡すこと、そしてその状態で AI ツールに日本語で要望を伝え SQL クエリを書かせること、いずれも問題なくできた。
その後、AI ツールにメタデータを渡す方針に問題がないことを社内で確認できたので、まずはデータプラットフォームの一部の領域を対象に施策を進めることにした。
これも折よく、自然言語でクエリを作らせたいというニーズを持っている人たちがいたので、検証に付き合ってもらった。
検証を行うための環境や状況、そして検証手順を書いたドキュメントを用意し、検証してもらった。
その結果、意図していることはできそうだった。精度の問題はあるが、メタデータの拡充や AI ツールの使い方（プロンプトなど）等で改善していけるのではないかと考えている。
社内でニーズを集めているが、この仕組みで解決できることは多いと考えているので、整備や普及を今後進めていく予定。
結び
以上、最近行った Platform Engineering 的な活動について述べた。
Platform Engineering という考え方を取り入れることで視座を得られ、これから何をやるべきか、今自分がやっていることはどのような位置付けなのか、といったことを考えやすくなると感じている。
今後も Platform Engineering 活動を進めていくと同時に、この記事ではあまり触れなかった、利活用者には見えない部分の品質や各種非機能要件といったものも「土台」として重要なので、そこの改善や投資も引き続き行っていきたい。
