AppSuiteの使い方 部品編4
自動計算
いわゆる関数で書式はexcelとほぼ変わらない。ノーコードにおいて使用が想定されるようなexcelの基礎的な関数は網羅されていると思うが、関数式が長くなると保守がしづらくなるので適宜改行しよう。
excelの関数との大きな違いは自動更新が無いこと。各レコードの編集画面を開く等の再計算手続きを明示的に行う必要がある。今日を示すtoday関数であっても、再計算しなければそのレコードの過去の最終編集日が保持され続ける。
とりあえずはアプリを作って試しにどのような挙動を示すのか確認して欲しい。まずはifを使いこなすことができれば表現の幅は大いに広がるだろう。具体的な使い方は説明できないくらい多岐にわたるので、アプリ作成の記事の際に随時説明したい。参考までにみなとデスクネッツの自動計算タグの記事へのリンクを貼っておく。
リッチテキスト
文字(複数行)のデザイン性を強化した部品だが、社内向け業務アプリでデザイン性の高い入力は不要だし、入力する側にもリテラシーを求めるものなので、ユーザーエクスペリエンスは逆に悪化する。使わないので存在自体忘れていい。
ユーザー選択、組織選択
報告書などに使われることが多いが、この部品の真骨頂はアクセス制御部品としての使い道だと思う。詳しくはアクセス権の設定の説明で紹介したい。オフィシャル動画でも説明されているのでリンクを貼っておく。
表部品
連携が難しい
様々な部品を入れることができる枠の部品で、ユーザー側からする使い勝手が良いが、データ連携の設計側から見ると使い勝手の難しい部品になる。
例えば、上記の様にデータ変更時の処理を設定したとする。
下のデータはどのように自動処理されると考えられるだろうか。
一回考えてみてほしい。
この結果は下のようになる。
表として判定
処理対象の絞り込みで、両方の部品に値があるものを処理するとなっているが、実際は4番目の何も入っていないものもデータが作られている。
これは表として、縦の列のどこかにデータが含まれれば処理対象と判定されている。
この絞り込みの想定は行の両方に値が入力されているものと考えるのは自分も含めてそれなりにいると思うが、あくまで表として判定されて、表全体として処理されるので、想定外のデータが作られる。
これを回避するには表の中身の部品について入力必須にする方法があるが、柔軟な入力を許さない運用が可能か否かというところに帰着する。
追加処理が難しい
例えば見積もり書の作成に当たって、後日訂正が入るといったことが想定されるが、表として編集がかかると、再度データ変更時の処理が反応する。表部品については処理タイプとして更新を選ぶことができないため、再度同じデータが作られることになる。現実的には入力時の1回だけの処理しかできないと考えてもらったほうがよい。
もちろん表を自動処理判定の対象とはせず、別の部品、例えばラジオボタンで確定としたときに1回だけ処理をすることはできるだろうが、どちらにしてもデータの作成しかできないので、実質的に更新を行うには前に登録したデータを削除する処理が必要になり、難しい判定が求められるので、運用でカバーするほうが現実的だろう。
入力の行数の最大値が事前に確定できるような運用が可能であれば、表部品ではなく、各種部品を表のように並べてユーザーインターフェースを設計するほうが、楽にデータ連携できると思う。
データの取り出しが難しい(できない)
表部品に対する関数としては統計関数の分類にあるもので、操作としては限られたものしかできず、任意の値を取り出すことが現実的にできないことが多い。先のバージョンアップで限定的なVlookupのような関数VALUE_OF_MAXとVALUE_OF_MINが実装されたが、それで対処できない場合はデータの自動処理後のアプリで作られたデータに対して操作を行うことになる。
なお、表部品についてはキーワード検索も対応していないので、例えば見積書で、A商品が売れた見積書のピックアップすることができないのも注意したい。もちろん部品の絞り込みによる抽出はできるが、一手間かかるので意外に使われていないのではないかと思う。
構築 VS 運用
今回は運用に関して言及することが多かった。システム構築においてはフールプルーフな設計が必要なのは事実であるが、技術・知識・期限・コストなどの観点からそういった設計ができない場面もある。それゆえ運用でカバーする仕組みを考えるのもシステム構築側の役割の一部である。
とはいえ、人手によるカバーの不確実性は、特に継続性の観点から問題であると認識して、理想は運用に頼らないフールプルーフな設計であるというのは、構築側の態度として間違ってはいないと思う。