NoCodeと負の遺産

Excel VBAマクロは負の遺産になったわけだけど、いわゆるNoCodeやRPAの類が負の遺産にならないにはどういう条件が必要なのかなぁ

おそらくロジックがローカルファイル＋奥まったところにあってなかなか見えないからVBAは負の遺産化したのだと思うのだけど、サーバで管理すればそれが回避できるか？

VBAよりマシになったとはいえ、サーバに置いただけでは「奥まったところ」に置かれてることには変わりがない。

完成したプログラムにアクセスできても読み解くのが困難

完成形ではなく「それが作られる過程」が共有される必要がある。

で、そもそも現時点でもSIerに来る案件のいくつかは、素人開発のVBAとAccessで地獄めいたコードになっていて、担当者が消えてどうしようもなくなったものが持ち込まれている現実があるわけで、RPAやNoCodeがまだその段階のスパゲッティコードが生まれてないだけというような気もする

「素人開発は引継ぎを考慮していないので、引継ぎのタイミングで地獄が発生する」

RPAもNoCodeも、まだ引継ぎが発生していないから問題が顕在化していない

集団でメンテナンスできるNoCodeやRPAプラットフォームっていうのが一つの解になりそうではある

これに月額で相談できるアドバイザーを付けると割と何とかなりそう

少なくともExcel VBAやAccess VBAのような、ローカルでしか動かない状態よりは幾分かはマシになる

集団でメンテナンスできる、って部分を推し進めるには、コミュニケーションツールとどれだけ融合できるか、なのかなー

たとえばBigQueryのWebConsoleを「集団でメンテナンスできる」って言ってもそれはうーんって感じなので

普段の業務フローの延長線上に導線がないといけない

そうすると、サイボウズのkintoneのポジショニングの上手さが見えてきた気がする

普段の業務導線の脇に自動化が仕組みが置いてあるわけだ、そりゃ強いわ

現状のkintoneだとデータの横でコミュニケーションできてデータの更新ができて自動バージョン管理されるわけだが、理想はデータベースのスキーマやカスタマイズのJavaScriptに関しても同様の共同編集ができる状態なのだと思う。現状それは実現されてないが。

これはおそらく普通のプログラミング言語も一緒で、いかに「頑張らないとソースコードが見に行けない、テストできない、デプロイ出来ない」という問題を解決するのか、というところが今後のキモになってくるんだろうなぁ

ここのスキルハードルをいかに下げるか

RPAやNoCodeは「命名」のプロセスがプログラミングよりも少ないので、意味の読み取りができない、という仮説を思いついた

素人が書いたコードも、「命名」が腐っていて読み取れないことがよくあるわけだが、それ以上にRPAやNoCodeは「命名」が少なくなるので、意味の読み取りが困難になる

命名が「将来のメンテコスト」を下げるのはその通りで、コメントやコミットログも同様。でも使い始めの段階ではそれらの価値を感じられないので、それらを要求するデザインにはしづらい。kintoneはフィールドのIDを人間が理解できる名前に変えられるようになってるけど、どれくらいのユーザが使ってるかなーと。

なのでユーザが明示的な努力をしなくても読み時のためのデータが集まる仕組みが必要で「コミュニケーションしながら書き換えてそのコミュニケーションのログが変更差分と紐づく」はその一手法。でもそもそも社内に1人しかいじる人がいないとコミュニケーションも行われないよね、難題

社内に1人しかいじる人がいない時の、その彼に対する知識共有の場の提供は「開発コミュニティ作り」という形で進められているが、社内に1人しかいない人が辞める時の引き継ぎ先がいない問題は社外の人間がどうこうできるものではなさそうな…。彼が社内にフォロワーを作ることの手助けぐらいか？？

自分がサイボウズの立場なら、kintoneのユーザ勉強会みたいなのを開いて、そこで交流してもらいながら、社外に相談できる口を作ったり、社内の初心者をそこに連れ出したり、一人だと会社がヤバイからそこ経由で採用してもらう、みたいな活動をするかなーと思った

（引き抜かれるリスクが上がりそう）

まあメーカー企業主催でユーザの勉強会をやるってのはよくあるパターンだよね。

顧客企業にkintone(に限らずDX)のわかる人材の採用機会を作り出すってところまで手が届いてるかどうかは僕はちょっとわからないけど、顧客企業の事業継続を考えるとそういうのも顧客価値の提供の仕方の一つではあるのかもしれないなぁ

ユーザグループ経由での会社間での交換留学みたいなのはあってもいいんじゃないかなーと思った

hrjn: 普通に開発できる人でもdesign doc書いたりしてコードの目的や設計を残さないと中身わかんなくなるし、ドキュメント書いててもよくわかんなくなることある。

汎用的な部品の組み合わせから意図や背景を類推することは不可能なので、問題はいかに文脈を記録して更新し続けられるか。

TDDじゃなくてBDDだって昔言ってた人達はこの辺を理解していて、普通にテストコードを書くだけだと意味が分からなくなることをわかってた。「20を入れると22を返す」ってテスト書いてあっても意味わからんよね。なので「入力した金額に消費税を合わせた金額を返す」とか書く。

zapierのオバケをちょっと前に読解してたのだけど、主なつらみはプログラミングと代替同じだった。コメントがないロジックを解釈するのはものすごく難しい。

ステップ実行もできないし、printデバッグもできないし、下手するとプログラミングよりも困難。

負の遺産化を防ぐ機能

アプリ管理者用メモ

アプリの作成経緯や目的、設計や設定のポイント、注意事項などをアプリ管理者用メモに残しておくことで、継続的なアプリの改善を行いやすくする

アプリの管理者が複数人いる場合に、管理者間で共有しておきたい内容をメモに残しておくことで、複数人での設定作業を行いやすくする