「モデルが開けない！」を解消。「マスターデータ」を強く推奨する理由
こんにちは！エンジニアの和田です。
普段はグルージェントフローの保守・運用を担当しているのですが、その中で、時々「タスクの新規作成時に見かけないエラーが表示される」という意見を聞きます。
時々、お問い合わせがあるくらいの認識でいたのですが、私も実際に申請書を上げようとしたときに遭遇してしまったのです。
「普段なら問題なく表示される値が表示されず、代わりにエラーが表示される」という事象に・・・。
その際に、「この選択肢、絶対に更新頻度低いはずだし、マスターデータにしたらいいじゃん！」って思ったんですよね。
なので、マスターデータを使用するようにして、無駄なエラーを出さない運用方法のご紹介をしたく、本編を始めていきたいと思います！
何が起こっているの？
何が起こっているのか確認すると、以下のような内容でした
選択肢を要するリストやボタン系の入力フォームの選択肢にスプレッドシートを利用していて、タスク新規作成時にスプレッドシートに情報を取りに行くことが出来ずにエラー
このエラーの原因はいろいろありますが、主な原因は以下のものになります
- 権限的にスプレッドシートにアクセスすることが出来ずにエラー
- 権限は問題ないけど、時間上限・アクセス頻度などGoogle APIの制限に引っかかりエラー
前者については、モデルの編集からファイルの再設定やドライブファイルの委譲設定などで回避をすることが出来ます。
→ メンテナンス③退職の場合(ユーザーの削除) > モデルを作成したユーザーの削除
→ メンテナンス③退職の場合(ユーザーの削除) > ドライブへのアクセスの委譲設定
しかし、厄介なのは後者です。
グルージェントフローはGoogleの機能と強力に連携していますが、Google APIをはじめとするクラウドサービスには、「システム全体の安定稼働を維持するための共通の利用ルール」が存在します(この共通ルールには、一定時間内の通信回数の上限や1リクエスト当たりの通信時間などがあります)。
ユーザーがタスクを作成しようとするたびにリアルタイムでスプレッドシートの最新情報を取得しに行くため、タスクの作成が多くなる月末・月初では特に本事象が発生する可能性があります。
マスターデータのススメ
これまでの章で、API制限はグルージェントフローの設定見直しでは防げないという事が伝わっていると嬉しいです。
ただ、そもそもスプレッドシートへの情報アクセスの回数を減らせる方法があるんです。
そう！題名にもある「マスターデータ」です。 （基本の活用方法はこちら）
マスターデータの場合、マスターデータの作成時や更新時にのみGoogle APIを利用してスプレッドシートの情報を取得します。
つまり、「利用者がタスクを新規作成する度に」ではないのです！
そのため、先ほど挙げた「権限は問題ないけど、時間上限・アクセス頻度などGoogle APIの制限に引っかかりエラー」はアクセス頻度が少なくなる分、発生しにくくなります。
また、今回はエラーについて取り上げましたが、他にもユーザーのアプリ利用時の体感速度にもいい影響があります。
なぜなら、Google APIを使ってスプレッドシートの情報を取って来るよりも、マスターデータの場合は近い場所にデータが存在するからです。
つまり、「タスク作成→Google API がスプレッドシートの情報を取ってくる」よりも「タスク作成→マスターデータのある場所から情報を取ってくる」のほうが断然早く完了します。
上記の内容は、時間にしてみるとごく小さな差かもしれませんが、そういった小さな差こそユーザー体験(UX)に大きな影響を与えると、私は思います。
マスターデータへの移行時の注意点(注意点ではない?)
これまで、スプレッドシートからマスターデータへの利用変更を進めてきたわけですが、運用上、気を付けるべき点があります。
それは、「マスターデータは即時反映されない」という点です。
スプレッドシートを選択肢に利用している場合は、タスク新規作成時に毎回Google APIを用いてスプレッドシートの情報を取得するという処理上、最新の情報を取ってきます。
一方でマスターデータは元データであるスプレッドシートに手が入った場合に、マスターデータを手動更新・定期更新を行う必要があります。
「スプレッドシートの修正をしたうえで、グルージェントフローにアクセスしてマスターデータの更新もしないといけないのは、二度手間」と感じる方もいるかもしれません。
ただ、これも見方を変えればメリットに変わります。
それは、「データ元の修正中であっても、利用者には影響を与えない」という事です。
スプレッドシートを直接指定している場合、例えば年度替わりの組織変更などで大がかりなデータの入れ替え作業をしている最中にユーザーが申請画面を開くと、作業途中の崩れた選択肢がそのまま画面に表示されてしまいます。
一方、マスターデータであれば、管理者が裏でゆっくりスプレッドシートの編集作業を行い、「よし、データが完成したぞ」というタイミングで手動リフレッシュボタンを押すことで、完成したデータだけを安全にユーザーに公開することが出来るのです。
「編集中に誰かアクセスしてこないか…」というヒヤヒヤしながら急いでスプレッドシートを書き換えるストレスから解放されるのは、運用者にとって非常にありがたいポイントですよね！
※ちなみにマスターデータ化する際の「本当の注意点」として、システム上の仕様制限がいくつかあります。マスターデータを作成する際は少しだけ気に留めておいてもらえると嬉しいです。
・スプレッドシートの1行目(ヘッダー行)に「関数」は使えない
・取り込めるデータサイズに上限がある
まとめ：安定したワークフロー環境のために
いかがだったでしょうか？
今回は、私が実際に遭遇した「タスク新規作成時のエラー」をきっかけに、マスターデータの絶大なメリットについてご紹介しました。
スプレッドシートを選択肢として設定するほうが手軽で便利ですが、利用頻度が高いモデルや運用においては、気づかない内にAPI制限という大きな問題を抱えてしまうこともしばしばです。
もし、現在、スプレッドシートを選択肢として直接指定しているモデルがあれば、安定運用とユーザー体験向上のためにも、是非この機会にマスターデータ機能への移行を検討してみてください！
保守運用を担当するうえで、グルージェントフローの管理者も一般利用者も全員が「いつでも・快適に」ワークフローを利用してもらうことが、励みになります！
