V0に魅せられて。ワークフローツールとしての進化を図る
現行のjinbaflow(2025年1月時点)は、ユーザー体験と機能の大幅な見直しを行っている。現段階では、以下の三つについて検討を進めている。
非エンジニアが何となくで作って、エンジニアがガッツリ使える、コラボレーション可能なツール （*今回の深堀）
AI エージェントがAIワークフローを自由に扱うことが出来るツールを作れるツール
ヒューマンインザループを自然な形で設計出来るツール
その中の非エンジニアとエンジニアのコラボレーションについて考えたい。
ただ、タイトルに書いてある通り、結論としてはまずは、V0みたいな要素が必要だよねという話である。
ワークフローツールは
「最終成果物に短し、デモに長し」
我々の経験からも言えることは何か、ワークフローツールは「物足りない」という事である。
Carnot社は、アカデミア、ITスタートアップ、GAFA、戦略コンサルと経歴は違えど何かしらの形でワークフローツールに向き合ってきたメンバーで構成されている。そのメンバーの議論の中で出てくるのは、「ワークフローツール」は楽しいけど、結局のところ最終成果物につながらないという議論である。
いくつかの本格的な状況について考えてみよう。要は
コンサルで分析を行った際に使う場合
コンサル「クライアントから貰ったＰＯＳデータの解析、エクセルだとすごく重くなってしまって出来ないのでBIツール使わないと、PowerQueryとかAlterix使おう」
－いい感じにAd hocの分析が終了－
クライアント「すごい、いい分析だから普段の業務のダッシュボードに入れたい」
コンサル「一発の分析だけやるつもりだったから、データフロー作りきってないよ….ここからシステム開発するのはな。クライアント側でメンテンナンスも難しいかもしれないけど、しょうがないので無理やりコピペの位置とか教えよう。」
スタートアップ・事業会社でワークフローツールを使った場合
営業（non engineer) 「お、Zapier使って営業mailの作成を完全自動化できるんじゃないか… mailとAIを繋いでいい感じになってきたぞ。問い合わせのところもslackに繋いで。動く！」
- 社内で「いい感じ」と広まり、全体で導入することに -
システム「Zapierで作った試作品を全体でPOCしてみたいから、ちょっちょとみんなが使えるようにかつ、社内のコンプラに引っかからないように設定してと言われたけど。これ裏側のコードがどうなっているか分からないからちょっとした分岐処理とか入れたいだけなのにめっちゃ大変じゃん。あー普通にコード書いて作るか」
要は、非エンジニアが
① そもそも軽い気持ちでPOCを始めたもの
② そもそもAd hocの分析だったもの
いずれも、システム化を想定していないことばかりだ。デモレベルでは十分だが、POCレベルですら後からやや後悔をしてしまうことがある。
こうなってしまうのは、致し方がない。そもそもシステム会社でもなければ大量に社内エンジニアに在籍していることはほぼない、一方で、各部署が率先してノーコードツールを利用して何かしらのカスタマイズを業務に対して行うことは多いにあるし、そういう動きは競争力を高めていくには必須である。
では、これまでのツールのどこに問題があったのか。それは、
① デモを超えた、POCとして作成するには安定性が欠けていたり、グループやバージョン管理の機構が存在していない
② システム化を行うためには、エンジニアが調整しやすい形になっていない。要はプログラムレベルで制御できない問題が存在している。
これを解決するのがV０での体験である。
V0の快進撃
一方で、フロントエンドの世界では本当に革新的なことが起きた。
それがV０である。
全くコーディングをしたことがない人が、本当にそれっぽいウェブサイトをコード付きで作成することが可能になったのである。
よって、こんなことが起きている。
非エンジニア「次のシステムなんだけど、欲しい機能のイメージが言葉だけだとずれると思ったから、コード書けないけど、Ｖ０で軽く動くイメージを作ったわ」
エンジニア「figmaよりもさらに分かりやすい。。。実際にはコード変更する部分は沢山あるが、それは些末なこと。コードですべて書かれているから編集可能。これは助かるぞ。」
両者「なんか、いつもよりも圧倒的にコミュニティーコスト下がったわ」
この体験は、まさにワークフローツールでも起きていることではないだろうか。非エンジニアが作ったシステム化を考えていないプロトタイプであったとしても、そこからエンジニアがシステムを作ることが出来る。
また、もっと重要なことは言語ベースのコーディングだからこそ、プログラミングを意識せずにさっと行えることに優位性が存在している。
これは非エンジニアもエンジニアも関係なく、簡単に何かを作ろうと思ったときには非常に便利な機能である。
ではなぜ、ワークフローツールの分野でこのようなものがあまり出てきていないのか。理由はムズイからだと考えられる。これまでMagic loopというプロダクトが存在しており、これはまさにこの動きをしている。
作るのが難しいというよりも動きが安定するのが難しい。これは、生成ＡＩがあくまでも確立モデルであるということに起因する。
例えば、犬の絵を作るというタスクには無数の正解が存在しているが、slackとGmailを連携してくれというのは、ある意味決まったコードが正確に動くかというもっと世界観がかっちりしてしまったものを取り扱っているからだ。
完全にこの問題は解決させることは出来ていないが、この一つの解決策になりうるのが、エージェントの存在である。いくつのアプリケーション作成用のアプリでは実践されている手法であるが、試行を行いながら必要な情報をユーザーから聞き出し挙動を確認して作り上げていくのである。
これはある意味で、普通のプログラミングに近い行為かもしれない。一部を作り上げて実行を行いもし何かエラーが生じてしまうのであれば、そこから修正を加える。
レイヤーを設けて協業を行う
自然言語での指示とコードベースでの設計書、そしてワークフローＵＩによる編集という3つの要素それぞれがうまくスムーズに連携することにより、先に挙げていた問題を解決しうる
copilotの採用により、完全にワークフローツールを触ったことがない初級者が始めるというコストを下げることが出来る
ワークフローのドラッグandドロップ形式のUIが中級者レベルのクリエイティブを助けることが出来る
そしてYaml形式での設計書の記述と詳細なコードの開示によりエンジニアによる調整が出来る
ただ、今後問題になってくるのはYaml形式での記述とは言え、新しい記法をユーザーに提供することになる点である。
極力、他サービスで採用されているYaml形式など基準とすることで学習コストを下げる試みを行っているが、例えばPythonコードを普段から使っている人からすると、すべてをPythonコードで記述してほしいという意見も出てくる。
非エンジニアとセミエンジニアとエンジニアを繋ぐ役目をAIを利用することに担わせるために、本当に必要となっていく機能を今後模索し続けていく必要がある。
この壁を超えることが出来れば、デモからPOCからプロダクションまでを一気通貫でサポートすることができる。