kintoneはaPaaS(Application Platform as a Service)と呼ばれる分野に属するサービスで、情報システムを構築する基盤として利用されるサービスです。基盤ですので、その上には自由に自社に必要なものを作っていけるのですが、基盤として提供される機能は有限ですので、自ずと限界があります。
kintoneの導入を検討されている方、もしくは導入ずみでこれからもっと適用範囲を広げたいという方に向けて、どういうことに注意が必要か、いくつかの例をご紹介したいと思います。
別に「kintone(キントーン)は使えない？向いてるものと向いてないものって？」と言う記事も公開していますのでこちらも参考にしてください。この記事と重複する部分もありますが、少し視点を変えて技術的な要素も入れながらご紹介します。
なお、この記事ではプラグインや連携サービスの利用も含めてkintoneの基盤としての可能性を考えていきます。
たくさんの一般ユーザーが利用するサイトのバックエンドとしての利用
たとえば何かの予約サイトのような、一般のユーザーがたくさんアクセスして情報を入力し、その情報を貯めるデータベースとしてkintoneを使いたいと言うケースはよくあります。
予約システムは予約して終わりではなく、その予約から始まる社内業務があるはずですので、kintoneで管理するとスムーズになります。そのため、予約データをkintoneに入れるというのは妥当な選択だと思います。（予約だけに限らず、データを集めるということはその後の業務が必ず存在するはずです）
しかし、kintone自体は、各ユーザーがログインして使う仕組みですのでこういう用途にはそのままでは利用できません。こういうケースは、トヨクモさんのフォームブリッジ等の外部連携サービスを利用することになります。
単純なフォームならフォームブリッジでも良いのですが、よくご相談いただくのが、お客さんが利用するマイページのような仕組みを作りたいというご要望です。さらに、お客さんが使うのでデザインにもこだわりたいというケースが多いです。
これもkintoneでやるとデザインに凝るのが難しいのと、全員にkintoneのライセンスを発行する必要が出てきますので費用的に現実的ではありません。
フォームブリッジとkViewerでもマイページを作れるのですが、ユーザー数が多い場合や、デザインを自由に行いたい場合には色々制約が多く難しいケースがあります。
こういう時弊社は、主にAWS上にマイページを構築して適宜kintoneと連携させるような仕組みを構築することが多く、その辺りのノウハウも豊富に持っています。
このようなkintoneとの連携は慎重に構築する必要があります。というのも、kintoneに負荷をかけすぎてはいけないためです。kintoneにはAPI同時呼び出し100本までや1アプリあたり1日10000回のAPI呼び出し制限などがありますので、これに引っかからないように構築する必要があります。
kintoneのメンテナンス時間の扱いや、エラー時の処理など技術的に回避しないといけない問題は多く、このようなケースは弊社のようなプロにご依頼いただくのが無難です。
在庫管理システムの土台としての利用
kintoneで在庫管理したいというご相談もよくいただきます。在庫管理はかなり幅の広い業務で、業務内容によって処理の複雑さが全然違ってきます。
単品管理なのか、ロケーション管理まで行うのかなど必要なレベルによって大きく違ってくるのですが、よほど単純でない限り、kintoneはトランザクション処理が弱いので、あまり在庫管理には向いていません。
在庫管理をする場合は、多くのケースでカスタマイズが必要になり、REST API呼び出しによってデータを書き換えることになりますが、トランザクション量の多い場合、上でも紹介した呼び出し制限に引っ掛かることがあります。
また、インターネットを経由してREST APIを呼び出す以上どうしても時間がかかるため、トランザクション量が多い場合は、在庫引き当ての競合の可能性が高まります。
競合はエラーとすることになりますが、業務上論理在庫と実在庫が合わないという状況が生まれやすくなりますので、棚卸しの重要性が高まります。ですので、棚卸しのタイミングが方法まで含めて業務設計しておく必要があります。
スクラッチで作られた複数の社内システムを統合先としての利用
長い時間をかけて、社内や外部ベンダーで作ってきた社内システムが色々あって、それをkintoneに統合したいというご相談もよくあります。
ケースバイケースになるので、一概にできるできないとは言えないのですが、複数のシステムを統合しながらkintoneに移行する場合、マスター類を統一したくなると思います。バラバラに作られたシステムの場合マスターの持ち方に大きな差異があることも多く、複雑なデータ移行をしないと統合できない場合がよくあります。
また、業務の流れそのものを見直さないとうまく統合できないこともよくありますので、統合を目論む場合は統合の順番やスケジュール、統合中のデータの扱いなど慎重に検討していく必要があります。
そして、多数の業務を統合する形でkintone化すると、恐らくkintoneアプリが複雑に関連し合うことになると思います。kintoneはルックアップや関連レコードでアプリを関連づけることができますが、これが増えれば増えるほど、アプリ変更の制限が増えていきます。そのあたりも要注意ポイントになります。
IoTバックエンドとしての利用
IoT(Internet of Things)のバックエンドとしてのkintoneの利用もよく行われています。規模が小さいうちはなんの問題ありませんし、簡単に構築できて、集計やグラフ化も簡単にできるのでkintoneはうってつけです。
問題は、IoTはすぐにデータ量が膨大になることです。センサーのデータをkintoneに蓄積するというようなケースですが、たとえば、1つのセンサーが10分に1回データを送ってくるとします。そうすると、1時間に6回データが来ます。1日で144回、1年で52560回データが来ます。
センサー1つならいいですが、センサーが10個あると1年で525600レコードできることになります。kintoneの集計・グラフ機能は一定量のレコードまでしか対象として扱われません。ですので、こうなると1年分のデータを集計することはできないということになります。
中間データを集計して別アプリに保存しておくなど、工夫をしないと望んだ集計ができないことになります。
また、センサーの数が増えたりデータ送信の頻度が上がるとREST APIの呼び出し回数の制限が問題なるため、kintoneへのデータ送信方法も考える必要が出てきます。
まとめ
スペースの都合もあり、いくつかの例しかご紹介できませんでしたが、kintoneに限らずSaaSを利用する場合は、その特性や限界をよく知って利用する必要があります。
これは構築をパートナー企業に頼むとしても必要なことで、特性や限界を知って話をしないと、実現できない要望をベンダーに出してしまい、時間のムダになります。
弊社のようなパートナーはkintoneの特性を熟知しており、さまざまなケースにおいてkintoneだけにこだわることなく適切な構成をご提案できますのでぜひ困った時はご相談ください。