勝手にkintone SIGNPOST解説 STEP.3 3-31「性能への気遣い」

アールスリーが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よろず相談会」でご相談いただけますので参加してみてください。