見出し画像

ApexクラスをGUIで可視化するエディターを作ってみた

Shogo Kataoka

～Apexを“読める人だけのもの”にしないために、
ApexクラスをGUI化するエディターを作ってみた～


はじめに

こんにちは、片岡です。
普段はSalesforceを中心としたシステム基盤の開発・運用を担当しています。
Salesforce開発に関わっていると、こんな場面に出会うことがあります。

「このApexクラス、結局何をしているんだっけ？」
「この条件分岐、どこにつながっているんだっけ？」
「この処理を変更すると、どこに影響が出るんだろう？」

開発者であれば、コードを読めばある程度は追えます。
ただし、Salesforceの運用・保守に関わる人が、全員Apexやコードに慣れているとは限りません。特にApexは、Flowと違って画面上で処理の流れを見られるわけではありません。
そのため、処理の中身を正確に理解するには、コードそのものや処理構造を確認する必要があります。AIに説明してもらうこともできますが、処理の流れや影響範囲を判断するには、構造をチームで確認できる状態が必要です。

一方で、最近はAIによってコードを書くハードルが大きく下がりました。Apexも例外ではなく、AIに相談しながら実装を進めることが以前よりかなり現実的になっています。

ただ、ここで1つ課題があります。

コードを書くことが簡単になっても、コードを理解することや、チームで安全に保守することまで自動的に簡単になるわけではありません。

むしろ、AIによってコードがどんどん生成されるようになるほど、次のようなことを確認する仕組みが重要になるのではないかと感じています。

  • そのコードが何をしているのか

  • チームで理解できる状態になっているのか

  • 長期的に保守しやすい構造になっているのか

そこで今回は、ApexクラスをGUIで可視化・編集できる Apex Editor というアプリを作ってみました。

課題は「Apexが悪い」ことではない

最初に書いておきたいのですが、Apexを使うこと自体が悪いとはまったく思っていません。むしろ、以下のような観点ではApexで実装した方が良い場面も多くあります。

  • 複雑なロジックを整理しやすい

  • 再利用性を高めやすい

  • テストコードで品質を担保しやすい

  • パフォーマンスを考慮した実装がしやすい

SalesforceにはFlow Builderという強力なGUIベースの自動化ツールがありますが、すべてをFlowで表現するのが最適とは限りません。ある程度複雑な処理になってくると、Apexで書いた方がシンプルに整理できることもあります。
今回のきっかけも、Salesforce組織の自動化構成を見直そうとしていたことでした。
現在の環境では、保守のしやすさを重視してFlowで実装している処理が多くあります。
ただ、処理が複雑になってくると、Flow上の分岐や要素数が増え、かえって全体像を把握しづらくなる場面もあります。
そのため、以前から複雑な処理や再利用したい処理はApexに寄せたいと考えていました。

一方で、気になっていたことがあります。

運用・保守に関わるチームメンバーの中には、Apexやコードに慣れていないメンバーもいます。その状態で、自動化構成の多くをApex中心にしていくと、処理の意図や流れが共有されにくくなり、結果としてブラックボックス化しやすくなります。

たとえば、次のような状態です。

  • 開発者はコードから処理を追いやすい

  • 運用する人もAIを使えば概要は把握しやすい

  • ただし、処理の流れや影響範囲をチームで同じ目線で確認するには、まだハードルがある

こうなると、Apexのメリットを活かしながらも、チーム全体としては扱いづらい構成になってしまう可能性があります。

つまり課題は、Apexそのものではありません。
Apexで書かれた処理を、チーム全体で理解しやすい形にできていないことです。

人にコードを覚えさせるのではなく、構造を見えるようにする

もちろん、全員がApexを書けるようになるのが理想かもしれません。
ただ、現実的にはメンバーごとに役割もスキルセットも違います。

チームには、それぞれ違う強みがあります。

  • 運用設計が得意な人

  • 業務理解が深い人

  • ユーザーとの調整が得意な人

  • 実装が得意な人

であれば、全員が同じレベルでコードを読めることだけを前提にするのではなく、コードの構造をもっと共有しやすくする方法があっても良いのではないかと考えました。

そこで思いついたのが、ApexクラスのGUI化です。
GUI化といっても、Apexを完全にノーコード化したいわけではありません。コードを隠したいわけでもありません。

AIの説明を補助として使いつつ、チームで同じ画面を見ながら処理構造を確認できる状態を作りたいと考えました。

いわば、Apexとチームメンバーの間に置く「翻訳レイヤー」のようなものです。
以下のような状態を作れないかと考えました。

  • コードを書ける人はコードを見る

  • コードに慣れていない人もGUIで流れを確認できる

  • AIの説明も参考にしながら、チームで同じ画面を見て構造を確認できる

  • 必要に応じて、コードとGUIを行き来できる


作ったもの

今回作ったApex Editorは、ApexクラスをGUIで可視化・編集するためのアプリです。

イメージとしてはFlow Builderに近いですが、ApexにはFlowとは違う構造があります。そのため、すべてを無理やりノードで表現するのではなく、Apexクラスの特徴に合わせて画面を分けました。

画面は大きく2つに分けています。

  • Apexクラス全体の構造を管理する画面

  • メソッド単位で処理の流れをノードとして確認する画面


1つ目は、Apexクラス全体の構造を管理する画面です。

ここでは、クラス名、フィールド、プロパティ、コンストラクタ、メソッド、内部クラスなど、Apexクラスを構成する要素を一覧で確認できるようにしています。

Apexクラスには、単純な処理フローだけではなく、クラスとしての構造があります。

  • どのフィールドを持っているのか

  • どのメソッドが定義されているのか

  • 内部クラスがあるのか

  • どのメンバーが処理の中心なのか

こうした情報をまず俯瞰できるようにしました。

すべてをFlow Builderのようなノードで表現しようとすると、かえって見づらくなると感じたため、クラス全体の構造は一覧形式にしています。

①まずはクラスの全体像を見る。②必要に応じて各メソッドの中身に入っていく。そんな導線にしました。


2つ目は、メソッド単位で処理の流れをノードとして確認する画面です。

こちらでは、if / else、loop、try / catch、return、throw、メソッド呼び出しなどを、Flow Builderのようなノード表現で確認できるようにしました。
メソッド内の処理は、コードに慣れていない人にとって流れを追いづらくなりやすい部分です。

  • 条件分岐

  • 繰り返し

  • 例外処理

  • 途中でのreturn

  • 別メソッドの呼び出し

こうした処理が増えてくると、上から順番にコードを読むだけでは、全体の流れを掴みにくくなります。
そこで、メソッド内の処理をノードとして可視化し、以下の3つを見やすくしました。

  • どの条件でどこに進むのか

  • どこで処理が終わるのか

  • どこで別の処理を呼び出しているのか

これにより、Apexクラス特有の「クラス構造」と、メソッド内の「処理フロー」を、それぞれGUIとして確認できるようにしています。

使ってみて感じたこと

実際に作ってみると、ApexをGUI化することには一定の意味があると感じました。特に良かったのは、コードを読む前に全体像を把握しやすくなることです。

Apexクラスをいきなりコードとして読むと、慣れている人でも最初に構造を頭の中で整理する必要があります。Apexやコードに慣れていないメンバーにとっては、特に負荷が高くなります。

一方で、クラスの構成要素やメソッド内の処理フローが視覚的に見えると、以下の2点が掴みやすくなります。

  • このクラスは何をするものなのか

  • このメソッドはどのような流れで処理しているのか

また、AIが生成したコードの確認にも相性が良いと感じました。
AIにコードを書かせると、実装自体はかなり速く進みます。

一方で、AIが生成したコードをそのまま信じるのではなく、そのコードが意図どおりなのか、処理の流れが複雑になりすぎていないか、レビューしづらい構造になっていないかは、人間が確認する必要があります。

そのときに、コードだけでなくGUIでも構造を確認できると、レビューの観点が増えます。

  • この分岐は本当に必要か。

  • 例外処理の位置は適切か。

  • このメソッドは処理を詰め込みすぎていないか。

  • 呼び出し関係は分かりやすいか。

こうした確認を、コードを書ける人だけでなく、運用側のメンバーとも一緒に行いやすくなる可能性があります。

Reactで作ってみた理由

今回、せっかくなのでSalesforce Multi-Framework Reactを使って実装してみました。
Reactを使ってみて一番良かったのは、UIまわりの選択肢がとても豊富だったことです。Apex Editorでは、単純な入力フォームだけではなく、少し複雑な画面が必要でした。

具体的には、次のようなUIです。

  • ノード表示

  • 接続線の描画

  • 選択状態の管理

  • 編集パネル

  • 複雑な状態管理

Reactの世界には、こうしたUIを作るためのライブラリやナレッジが多くあります。そのため、思っていたよりもスムーズに形にできました。また、ReactはAIとの相性も良いと感じました。
私はReactの開発経験がほとんどありませんでしたが、実装方針やコンポーネント設計をAIに相談しながら進めることで、開発のスピードをかなり上げられました。
Salesforce上のUI開発というと、これまではLightning Web Componentsを中心に考えることが多かったです。もちろんLWCは非常に重要な選択肢です。

ただ、用途によってはReactを使うことで、よりリッチで複雑なUIを作りやすくなる場面もありそうだと感じました。

バイブコーディングで進めてみて感じたこと

今回の開発は、いわゆるバイブコーディングに近いやり方で進めました。
最初から細かい設計をすべて固めたわけではありません。
最初にあったのは、次のような大きなイメージだけでした。

「ApexをGUIで見たい」
「Flow Builderのように処理を可視化したい」

そこから、AIと対話しながら少しずつ形にしていきました。
もちろん、AIに任せるだけで自然に良いものができるわけではありません。

  • Apexの構造をどう分解するか

  • クラス構造とメソッド内処理をどう分けるか

  • GUI上でどこまで編集できるようにするか

  • どの体験を優先するか

こうした部分は、作り手側で判断する必要があります。
AIは実装を加速してくれますが、何を作るべきか、どこまで作るべきか、何を大事にするかは、作り手側で考える部分だと感じました。

今回改めて感じたのは、AIによって「作れるもの」の範囲が広がったということです。

以前であれば、ApexクラスをGUI化するエディターを作るとなると、需要と工数が見合わず、構想だけで終わっていたと思います。しかし今は、AIと対話しながら試作し、動くものを短期間で作ることができます。

「いつか作りたいけど、工数的に無理そう」と思っていたものを、まずプロトタイプとして作ってみる。

そういう動き方が現実的になってきたのは、大きな変化だと感じています。

さいごに

今回は、バイブコーディングでApexクラスをGUI化するApex Editorを作ってみました。
今回作ったものは、Apexを完全にノーコード化するためのものではありません。むしろ、Apexをチームでより扱いやすくするための補助ツールです。

  • コードを書く人だけでなく、運用・保守に関わるメンバーも処理の構造を理解しやすくする。

  • AIが生成したコードを、より安全にレビューしやすくする。

  • Apexを“読める人だけのもの”にしない。

そうした目的に対して、GUI化には可能性があると感じています。

まだコードが整理できていないため現時点では公開できませんが、反応があればオープンソース化も検討してみようと思います。

ApexをGUIで見たいと思ったことがある方や、AI時代のSalesforce開発に興味がある方にとって、何か発見のある話になっていれば嬉しいです。

参考


いいなと思ったら応援しよう！