🍊

ノーコードを目指すべき理由

2022/12/08に公開

nocode

pleasanter

idea

2022 個人アドベントカレンダーの記事です。

課題感

この記事が良くないと思ったこと
「ノーコード」を目指すべき

役に立たないのは間違っている、とは違うということ

私は株式会社無駄のファンだし、すごく技術力が高くて役に立つような記事を書いているわけではない。
役に立たないけれども間違っていないし、すぐ役に立つ必要はないと考えている。
例えば、シャノンの手とも知られる究極の機械(useless machine とも言われる)を Pleasanter で表現するとして、レコードを作成するとすぐ消すということを考えたりもする。

条件は「作成後」(デモサイト互換のサイトパッケージ)

try {
  items.Delete(model.ResultId);
} catch (e) {
  context.Log(e.stack);
}

このとき、何もしないのではなく、作成するとエラーページになるし、作ろうとしたレコードはゴミ箱に入る。

これ自身まさしく役に立たない、けれども下記のような検討を経ており、私の学びがないわけではない。

「作成前」だと、作成エラーにすることはできるが、作成の機能性が失われており、スイッチをオンにしたあとオフにするアクションにならないこと
「作成後」のスクリプトでは ID が生成して付与されていること(作成前では model.ResultId から値を取れないこと)
作成後にリダイレクトして一覧やゴミ箱、新規作成ページに移動できそうだと考えること

Pleasanter の特性

Pleasanter は機能的にはもちろん本体の内部コード的にも「人間が Web 画面を操作する」ことを前提としたシステムである。
ただ、これは弱点ではなく、「ローコード」ツールが生きる局面を考えると順当と言える。

「業務を分かる人」が、「漸進的」に「業務改善」して DX を達成するとき、プログラムアクセスを前提に作る必要なんてない。

逆に言えば、プログラムで何とかしようとしているのは、業務を改善せずに、現状をそのままシステムに載せようとしていることであり、いわば考えなしにコードに逃げている状況だと考える。

これは、特定の個人が作った Excel VBA マクロに依存しているような技術負債と構造的に同じであって「脱エクセル」を掲げている Plesanter の本筋から外れた対応と言える。

何が良くないのか

冒頭の記事には致命的な問題がある。

サイトのアクセス権限が正しく評価できないこと

問題 1:アクセス権限のないサイトの情報が見える

拡張 SQL を実行して取得される結果そのものに対しては、アクセス権限が評価されないため、親となるサイト ID 配下で画面上見えないサイトの名前やアドレスが見える。

問題 2:アクセス権限のあるサイトが見える

何を言っているのかわからねーと思うがアクセス権限があるサイトをユーザが見ているとは限らない。

もちろん、スクリプトで非表示にしているといった対応をしている場合もあるが、基本機能として「読取専用の場合は画面に表示しない」という重要だが活用されていないことも多い機能があります。

「サイト」の「読み取り権限」のみを有するユーザに対し、「サイトメニュー」「一覧画面」「エディタ」の使用を禁止する場合にオンにします。「リンク」機能からの参照など、マスタテーブルとしてのみの利用を許可する場合に使用できます。オンにした場合「サイト」が非表示となり、直接 URL を要求した場合でもアクセス不能となります。「読み取り権限」以外の権限を有するユーザはアクセス可能です。

もちろん、この機能は「アクセス制御」なので URL を知られたとしても表示はできないはずだが、見えないように設定しているサイトが見えるということの無意味さを考えるべき。

問題 3:アクセス権限のないフォルダの配下のアクセス権限があるサイトが見える

サイトのアクセス権限において、継承を利用せずに個別に設定した場合に次のような設定が可能。

- Top
  + フォルダ 1(User1 アクセス可)
    + フォルダ 2(User1 アクセス負荷)
      + テーブル 3(User1 アクセス可)

このようにしたとき、User1 が画面操作をする限り、テーブル 3 は事実上アクセスできないサイトとなる
しかし、リンクそのものを得るとすれば、閲覧可能。

先の読み取り権限のものは表示しない機能を利用すればこのような設定をする実用的な局面があるかは分からないし、設定ミスかもしれない。が、わざわざセキュリティホールを作っていることのリスクは考えるべき。

このときデータを読み取られないようにする対応としては、サーバスクリプトの view.Filter で、マッチしようのない条件を入れることで、特定のユーザ以外にデータレコードが表示されることを阻むことも可能ではある。

もしやるとしたら

拡張 SQL でやるなら、Permissios テーブルを解釈することは必須
- DB の構造を把握しないといけないなら Pleasanter 要らない
サイトのアクセス権の表現は、機能的にはレコードのアクセス権限と合致するので、レコードとして管理すべき
- データ指向アプリケーションでは、まず欲しいデータをいかに作るかを考える
- ただ、レコードはアクセス権限の親子継承を持たないので、手作業が介在し、サイト本体とレコードの二重メンテとなり、とてもやりたくない
  - テーブルの親子にするとレコードのアクセス権限の継承を代用できるのかもしれないが、サイトの親子を管理するために無段階にテーブルの親子を組まないといけなくなり矛盾感がある

結局何が問題なのか

業務改善していない

あのサイトどこだっけ？ってなりませんか？

に対して、前述のように機能によって隠蔽できているサイトがリストアップされるのは本末転倒。

サイトマップを作ろう、ということ自体が間違い。

Pleasanter は業務改善をするためのツールなので、言われたものをそのまま作る、ではなく、業務の統廃合によって"ためにする"業務をやめ、合理的な必要最小限のサイトを作るべき。
それでもサイトが増えた場合には、フォルダの仕組み、閲覧権限の仕組みで個々のユーザに見えるものを分離して、目的のページへの到達性を高めるべき。

まとめ

「Pleasanter のノウハウがある」というのは、これこれこういう業務をシステム化したときに、どういう合理的な改善をすると GUI で設定できるかを提案できる状態
- 「サーバスクリプトを書ける」「機能を知っている」ではない
- できる、は当たり前。スクリプティングによって改善課題から逃げてはならない
  - これこそが「パソコンの大先生」を DX 担当にしてはいけない理由でもある
それは、もし既存機能でできなかったときに、どういう機能があれば業務改善できるかの提案ができる状態
- スクリプトを書いて"できてしまう"と、容易に技術負債になる
  - 本体機能は開発が続く限りメンテナンスされるが、スクリプトが依存した仕様は開発が続く限り機能追加であれ変更の可能性が生まれ、スクリプトは自分でメンテナンスし続けないといけない
  - これは、ユーザの業務改善ではなく、問題のすげ換えでしかない
サイトを一覧取得できる API の実装に期待

この観点で「ノーコード推進協会」が、ローコードではなくノーコードにこだわっていることはとても支持できる(回し者ではない)

GitHubで編集を提案