アールスリーがkintone SIGNPOSTを勝手に解説していくシリーズ！
本文は、kintone SIGNPOSTを読んでいただくとして、kintone SIGNPOSTの各項目についてアールスリーが感じていることや、遭遇したケースなどを紹介します。
STEP.2 2-18「守るべきデータ」
データ損失にはいくつか種類があります。
- インフラトラブルによる損失
- システム運用ミスによる損失
- 業務ミスによる損失
このうちcybozu.comで担保されているのは最初の「インフラトラブルによる損失」だけです。残り2つは自分で担保する必要があります。
また、データ損失に対する対応はそのアプリで扱うデータによって異なります。
システム運用ミスによる損失
kintoneの場合、システム管理者が行えるデータ操作に限界があるのでシステム運用上の損失は起きにくいのですが、以下のような損失が起きる可能性があります。
- データ量を抑えるために古いデータを消そうとして全部消してしまう
- 使っていないアプリを消そうとして似た名前の現役アプリを消してしまう
このような場合、バックアップがないと復旧は不可能です。作業前にkintoneのデータをファイルに書き出しておいたり、アールスリーが提供しているgusuku Deploitのようなサービスでバックアップを取得していないと復旧できません。
gusuku Deploitでのバックアップ・リストアもkintoneの仕様の制限により完全に戻せるわけではないので、このような作業は慎重に行う必要があります。
また、やみくもにすべてをバックアップしようとすると料金がかさみますので、何をバックアップするかの精査が大切です。
業務ミスによる損失
もっとも頻繁に起こるのがこの業務ミスによる損失です。
- 操作を間違って消してしまった
- 関係のないデータを書き換えてしまった
など起こりうることはいろいろあります。業務ミスによる損失を防ぐには、
- 意図しない編集に対応するため変更履歴を活用する
- 必要のない削除権限は剥奪する
- みたくないデータは削除ではなく、削除フラグをつけるようにしてレコードのアクセス権で削除フラグのついているレコードを見せないようにする
というような工夫が必要です。
ちなみに、アールスリーが提供しているgusuku Customineにはレコードを削除する機能をあえていれていません。これは、これはこのような意図しない削除を防ぐためです。削除したいというご要望はよくいただくのですが「削除フラグ」での対応をオススメしています。
kintoneでの業務改善・システム開発で困った場合は、弊社で実施している「kintoneよろず相談会」でご相談いただけますので参加してみてください。
