アールスリーがkintone SIGNPOSTを勝手に解説していくシリーズ！
本文は、kintone SIGNPOSTを読んでいただくとして、kintone SIGNPOSTの各項目についてアールスリーが感じていることや、遭遇したケースなどを紹介します。
STEP.3 3-31「性能への気遣い」
残念ならkintoneは魔法の箱ではなくクラウドだとはいえその先にはソフトウェアが動作しており、そしてそのソフトウェアは物理的なコンピューターの上で動作しています。
kintoneは画面上での制限は緩めに作られていますが、だからといって無理をするとパフォーマンスに影響を与えます。
アールスリーがkintoneをはじめて間もない頃、1つあたり8項目×70行くらいデータが入るテーブルを1つのレコードに8つ作ると画面を開くのが1分かかるようになったことがありました。
この例のようにkintoneでの設計は常にパフォーマンスを意識する必要があります。上記の例では、モノによっては別アプリにして関連レコードにしたり、そもそも管理する項目を見直したりすることでパフォーマンスを改善させました。
2-20 小さなリリース単位はパフォーマンスの観点からも有効です。小さくリリースしては現場で利用していく、そして更なる開発を続けていくわけですが、そうしていくうちにパフォーマンスに影響がでるかもしれません。
小さくリリースしていればこのような影響も小さく抑えられます。リリースしてみて問題が出れば1つ前にいったん戻って考え直すことができます。
gusuku Customineのサポートを通じて我々がよく見るパフォーマンスに影響を与えるケースは次のようなものです。
- テーブルに入れるデータが多すぎる
- カスタマイズして一覧で大量のレコードを一括処理をしようとしすぎる
kintoneはたくさんのデータを一度の処理するのが苦手です。そのためkintoneで開発するときに多くのデータを処理したいという要望がでてきたときは警戒するようにしてください。
kintoneでの業務改善・システム開発で困った場合は、弊社で実施している「kintoneよろず相談会」でご相談いただけますので参加してみてください。
