見出し画像

コード不要論からコード表現への回帰 - デベロッパーツールの現在


皆様、ChatGPTでCode Interpreterの機能がリリースされましたがお使いになりましたか?
僕は大変有りがたーく日常使いさせて頂いており、活用方法について各方面のご意見を伺いたいですが、その話はさておき…
こうした劇的な開発体験の変化が予感されると、度々繰り返される議題の1つが「エンジニアやコードの不要論」かと思います。

私自身がローコードツールを提供している会社の経営者なのですが(ヒューマンエラーを減らせる管理画面構築SaaS「ベースマキナ」をよろしくお願いします!)、この類の議論の盛り上がりと日頃情報を追っている最新のツール群との間を照らすと、ギャップを感じます。

端的に言うと、少なくともここ1年くらいで新しく登場するデベロッパー向けのツールを見ていると、コードが不要になる場面が増えると思いきや、逆にコードをしっかり書くツールが増えてきたな、という印象を持っています。


DXとノーコード・ローコードの潮流

前ほど過熱した潮流ではないものの、DXというバズワードの中でノーコードやローコードのツールには一定の注目が集まりました。
ソフトウェアの開発需要を満たすべく、1から開発しなければならない量を減らしつつ開発できる人間を増やせるツール群に注目が集まるのは必然かと思います。

プログラミングは民主化したか?

開発工数の削減というメリット以外に、これらのツールには大義が伴います。よくこの分野のツール群が標榜するのは「プログラミングの民主化」です。

ソフトウェア開発を非エンジニアの人にも開かれた活動にして、アイデアを持った人が直接モノの造り手になれることを指すフレーズだと認識しています。

ただ、このフレーズが指すような民主化が”完了”したかといえば、程遠いでしょう。民主化はいきなり完了することなく、少しずつ作業を抽象化レイヤーでラップし続ける歴史を辿っているように思えます。

民主化は歓迎されたか?

”民主化”をそのまま受け入れるケースとそうでないケースがあると思います。これには組織の人員構成と用途が密に関係します。

ソフトウェアエンジニアがほぼいない組織、あるいは集計・分析用のDBが分かれていてそこからデータを読み取る用途(レコードの更新によってエンドユーザーに対して甚大な影響を及ぼす危険性がない場合)に限定して言えば、基本誰でも触って良いケースが多いです。
誤ってスロークエリを発火させない限りは強力な業務効率化が望めるため”民主化”が概ね歓迎されると言えます。

逆に、ソフトウェアエンジニアが大きな割合を占める組織や、データを更新・作成する用途だと、誰でも開発を分担できてしまうと統制面で問題になることもあります。

民主化の責任

統制面で問題になるのは、具体的には成果物のメンテナンス責任とアクセス権限の管理責任の2つの観点です。

非エンジニアがノーコード・ローコードによってUI上で設定をしても、運用に乗ってからメンテする責任がエンジニア側に寄ってしまう場合、ブラックボックス化されたシステムの面倒を見ることになります
当然、初期のレビューを誰も通さず、今後も中身がわからない(あるいは大してhuman-readableではないJSONなどの中間表現でしか出力できない)ツールだった場合、メンテ責任がエンジニアによってしまうケースだと途中から体験が悪化してしまうでしょう。

また、アクセス権限の管理責任にも問題が生じます。誰でもシステムのたたき台を作れて良いとしても、誰でも好きなデータにアクセス、更新して良いわけではありません
やはり通常は権限体系を整理した上でないと、ソーシャルエンジニアリングや人為的なミスを誘発するおそれがあります。
そうした事象の回避のためにも、権限体系の設計やミスが少ない画面遷移の設計に技術的に知見のある人間が責任を持たないと、不安が生じます。

と、ネガティブな側面を書きましたが、弊社のサービスは特に2つ目の権限の管理責任の細やかさには注意を払っており、ご好評いただく要因になっているからこそ、お客様から既存ツールの懸念点を耳にすることが少なくありません。

これは海外のデベロッパーツール界隈でも同様に起きている事象ですが、私見でいうと彼らはこの問題を、想定利用者を非エンジニアではなくエンジニアに全振りすることで解決しようとしているように見受けられます。

コード表現への回帰

例えば以下は最近パブリックリリースされたツールですが、JavaScriptのSDKを経由してJenkins的な機構が呼び出せるサービスです。

しばらくLPを読むとわかりますが、初期設定やデプロイはCLIを通じて行いますし、ジョブの定義はガッツリJavaScriptで書きます。他にもこういったツールがありますが、初期リリース時点ではJavaScriptかPythonがサポート対象言語なのが多いです。
SDKが提供されていて、ジョブのエラー時の挙動や連携可能なAPIの呼び出しなどが抽象化されています。

既存のローコードのツールのように「非エンジニア主体でも開発が進められ、カスタマイズが必要になったらコードも書ける」ような体験ではなく、「エンジニアが自らの開発・運用工数をひたすらにショートカットする」ために作られています

こうしたSDK提供により利用者が自ら記述しなければいけないコード量を減らし、その動作環境を提供するサービスは他にもここ1,2年で増えてきました
逆に非エンジニアでも作れるのを売りにした開発ツールの熱は落ち着いた印象があります(マーケティング分析系のツールの界隈とかは別です)。
自分はこれを「コード表現への回帰」と捉えています。

お客様側がノーコード・ローコードが魔法の杖ではないという経験値を積んだ今、どうしてもエンジニアにメンテ責任が寄るところは下手に非エンジニア側に寄せず、エンジニアの体験に注目して彼らの工数を削減する手段・インターフェースを提供するのが良いという判断になるのは当然だと思います。
また、たとえ出力されても読めない中間表現を用意するのではなく、コードをそのまま設定として使うことで、設定の読み解きコストを下げ、レビューや学習可能な状態を作ることができます

これはすべてのツールで起こる現象ではないと思います。
しかし、選択肢がないまま見切り発車で要件を満たさないコード不要のツールに依存するのではなく、責任範囲によってツール選定が細かくできるようになったのは間違いなく良いことです。

拙作の宣伝

実はちょうどベースマキナでもここを意識した機能をリリースしました。

「ビュー機能」という機能でして、カスタマイズされた画面を、コードベースですが比較的かんたんに作り上げられる機能です。
ベースマキナが用意したコンポーネント群や、予めベースマキナ上で設定したAPI・DBの呼び出しができる関数が独自パッケージ経由で呼び出せるJSXの動作環境を提供しています。

まだまだ荒削りな機能ですが、今後はこうしたコードの管理機構やエンジニアの方向けにもできる機能を増やしつつ、非エンジニアの方で完結できる部分は画面上でも設定できるようにしていくなど、改善を続けていきます。

どうしてもエンジニアがやらないといけない作業は、しっかりと他の機能との間に境界線を引いて、コードで機能提供をする、という手段も良いのではと考えています。

Framework-Defined Infrastructureの潮流

さて、自社の宣伝はさておき話をデベロッパーツールのトレンドに戻すと、私がコード表現への回帰と呼んでいる潮流は、元をたどるとVercelが強い影響を及ぼしているのではないかと思います。

Vercelが提唱した「Framework-defined Infrastructure」という概念があり、フレームワークを利用して書かれたソースコードをもとに、その動作に必要なインフラを自動的に用意する機構のことだと認識しています。

Vercel だけでなく、デベロッパーツールの市場のプレイヤーはいかにこれまでのIaaSと呼ばれた巨大プラットフォーマーのインフラを解体し、個別に最適化するか、そして個々がいかに相互連携するかを意識しています。

私個人としては、Framework-defined Infrastructureの概念自体が割とVercelのブランディング目的のポジショントークだなと思っている部分も正直ありますが、「余計な中間表現を用意せずコードとその動作環境を提供する」という流れだけを切り取ると、それは暫く続く不可避なトレンドだな、と感じています。

とはいえ、既存のAWSやGCPが持つサービス群を解体したとして、Vercelほどのパワーで最適化できる分野もそう多くは無いとは思います。
あと、正直コスト削減効果とパフォーマンスチューニングが同時かつ大幅に達成できない場合、オレオレ最強フレームワーク提供に終止してしまう気がして、既存サービスを目の敵にしたようなインフラの解体に対しては、自分は悲観的な立場を持っています。

ですが、ここ数年のデベロッパーツールの未来にはSDKの提供とコード表現への回帰、独自の動作環境の提供がデファクトになっていくとは思っているので、日本からにはなりますが、この未来を探索していこうと思います。

最後になりますが、こうしたツール群の未来に興味があってちょっと喋りたい、ベースマキナというチームの力を使って自社の開発・運用プロセスを変えてみたいという方、あるいは昼時に東京の茅場町・日本橋周辺でご飯を食べましょう、という方がいれば、是非Twitterなどでお声がけください。

Twitterはこちら 👉 https://twitter.com/__timakin__


この記事が気に入ったらサポートをしてみませんか?