AppSuiteの使い方 設定編 1
前回までで、部品の紹介が終わったので、今回からは設定の説明をしていく。
設定は運用方法や連携方法によって大きく左右されるため、各社、各アプリを取り巻く環境が異なるので部品以上にパターンが作りにくい。
これから紹介するのも、私がこれまで数年に渡って運用してきた経験から、感じたことをまとめて紹介するものであり、運用方法によっては書いてあることと正反対が正解になることもある。
例えば今の開発方針としては弊社総務部内では申請書アプリケーションを使わない方向にあるが、申請書アプリケーションは定型化がしやすいことに加えワークフローも運用しやすいので総務部以外のレコード登録はワークフローを使うことも多い。また弊社では使っていないが自由書式でChatツールでの簡易的なワークフローを回して、それを最終的に基幹システムへ連携なり手入力するということも組織によっては正解であろう。
条件付きスタイル
excelの条件付き書式に近いが、条件設定対象が自分自身の値だけなので、他のセルの値や関数式が使えるexcelと比較して機能は弱い。解決方法としては自動計算を使って別のデータを参照する方法になるが、それでも限界がある。
下ではテスト1と成績に条件付きスタイルを設定してみたが、例えば3番目の様に一つでも個別成績で赤がある場合は総合が「良」であったとしても赤くするというのはできない。excelでは他のセルの値が参照できるが、AppSuiteではそれ自体の自動計算の結果だけで判定してしまうため「良」はあくまで「良」で判定される。
入力チェック
部品単体の入力制限の設定をカバーするために使われる。非常に使い勝手がよく、使いこなすことでレコードの入力品質が格段に増すことから、データの利活用を進めるための第1歩になる。部品をまたいだ条件設定ができるのが魅力で、より広い表現が可能になる。
例えば下の様に、売上代金の回収方法を指定する際に振込を選んだ時だけ銀行名を選択させたいという状況を考える。振込銀行名を入力必須にしてしまうと現金や引落の場合であっても銀行を選択しなくてはならないので利用者間での認識の相違のずれが生じると、後に入力の仕様変更になった場合や別のアプリとの不一致などユーザー側に混乱をもたらす原因にもなりかねない。逆に振込以外のときは選ばせたくないという運用ができなくなる。
(そもそもラジオボタンは選択無しに戻せないので、後から現金等に変わる可能性がある場面ではプルダウンを選ぶべきでラジオボタンは不適当)
複雑な入力制限を設定することもできる
判定条件
AppSuiteをワークフロー的に使うにあたって非常に役立つので、是非とも使いこなして欲しい。
下図は、左上で「回収方法が振込の場合」という判定条件を作り、それを振込銀行名部品に対して設定することで、振込を選んだ時だけ銀行を選択できるという状態を作り出すことができる。
入力チェックと同じようなことができているが、判定条件は入力自体をできなくする(厳密には編集できなくする)という点で、入力可否の判断を明示的に統一できるため、入力チェックよりも優れていると言えるかもしれない。
なお、入力チェックは別の機能なので併用可能であり、さらに入力品質を高めることができる。
データ登録後の編集に弱い
データを登録した後編集することは度々ある。レコードを工程に従って複数人で順次入力していくということも考えられる。
例の回収方法で言えば、最初は振込になっていたが後から引落になったという場合で、せっかく振込銀行名に「振込」でない場合に選択する「振込以外」を作ったとしても、先に引落へ選択を変えてしまうと振込銀行は編集することができなくなる。
こうなってしまえば、入力者はわざわざ「振込」→「振込以外」→「引落」という3ステップかかる面倒なことはやらないだろう。その後の運用としては問題ないデータ入力であるかもしれないが、データの利活用を考える場面になった場合には入力品質が安定しなくなる原因にもなる。
その部品自身絡む判定条件が作りにくい
管理者チェックのラジオボタンに自身が絡む判定条件を設定したとしよう。初期選択は未確認なので編集可能だが、「確認」に編集した場合、編集ができなくなるため、admin権限であっても「未確認」に戻すことができない。このボタン単体であればよいが、その前段階の入力として、金額や担当者のような部品にも当てはめると、完全に一方通行になり、データの削除(又は不可視化)と作成が必要になる。
さらに、自動計算部品を絡めると更新時間の差異から想定した結果にはならないこともある。
下図では管理者チェック判定という自動計算部品を用いた条件判定を行っている。この場合は自動計算の引数が一つしかないが、複数、例えば「課長チェック」と「部長チェック」のどちらか一方で「確定」の様な運用を行う場合に自動計算を使わないと表現はできない。(AND条件ならば判定条件の設定で対応可能)
自動計算は編集画面で値が更新されるため、”確認”に変更すると自動計算は”0”になる。すると判定条件から外れ想定通り編集ができなくなる。
しかし、この後保存してみると管理者チェックが未確認に戻っている。
この理由は管理者チェック判定が0になったことで、管理者チェックの編集ができなくなる。すなわち”未確認”→”確認”の編集もできなくなるため、保存時には元の未確認に戻されてしまう。
ワークフロー的に利用する際は、なんらかのチェックを行うと編集できなくなるようにする運用が一般的だろうが、desknetsのワークフローの様にルートを変えたりするような難しいものは、条件判定だけでは作りにくいこともある。
もちろんアクセス権設定も利用することである程度カバーできるが、細かいアクセス制御を行う場合はしっかり判定条件を考える必要があり、もしかすると実現不可能な場合もあるかもしれない。
入力品質がデータ利用の質を左右する
今回は少し入力品質について言及した。
AppSuiteはどの組織においても情報共有の場であることは間違いないだろうが、データが集まる場所でもあるので単なるデジタル化を越えて、デジタライゼーション、デジタルトランスフォーメーション(DX)へと発展的につなげるためには、データの質が問われることになる。
DXへの道で一番時間がかかるのはデータの電子化・蓄積工程と言われる。自社特有のデータは外から持ってくるわけにはいかないので、3年、5年、10年を見据えて蓄積していく必要がある。
弊社でもAppSuiteを使い始めて3年を超え、ようやく使えるデータが2年分以上集まりだしたので、これからデータを使った経営の仕組みづくりに取り掛かっていきたい。
この記事が参加している募集
この記事が気に入ったらサポートをしてみませんか？