アールスリーがkintone SIGNPOSTを勝手に解説していくシリーズ！
本文は、kintone SIGNPOSTを読んでいただくとして、kintone SIGNPOSTの各項目についてアールスリーが感じていることや、遭遇したケースなどを紹介します。
STEP.5 5-39「トラブル対応フロー」
kintoneに限らずITシステムにはトラブルがつきものです。よくあるのは「何もしていないのに動きません」というやつですが、ほぼすべてのケースで「何かしています」
トラブル発生時に大切なのは問題の切り分けです。問題の切り分けを行うには、自分達が使っているkintoneを構成する要素を把握し、それらがどのように動いているのかを把握している必要があります。
とくにkintoneを活用すればするほど、プラグインや連携サービスを活用しますので構成する要素が増えてきます。
- kintone自体は動作しているか？
- プラグインは入れているか？
- 連携サービスを使っている？動いているか？
- 独自に作ったJavaScriptは入れているか？
と言うような要素を把握しておき、それぞれを外してみたりしながら問題を特定していく必要があります。
たとえば、独自につくったJavaScriptに問題があるのにkintoneの問題だと考えてサイボウズのサポートに問い合わせても問題の解決には時間がかかります。
では、現場の利用者がこの切り分けをできる必要があるかというと、それは大変なのでこのような切り分けができる担当を決めるということになります。
そして、トラブル発生時にその担当者に速やかに必要な情報が伝わるようにしておくことが大切です。
ここで重要で多くの場合うまく行われていないのが、トラブルを担当者に伝えるとき、できるだけ多くの情報を伝えることです。
よくあるのは、最初にあげたような
「何もしていないのに動きません」
や
「ボタンを押したらエラーがでました」
のような報告です。これだと情報量が少なすぎて担当者は何をみればいいのかがわかりません。
- どの画面で
- どのような操作をしたときに
- どういう現象が発生して
- 画面に何が表示されているか
を正確に伝える必要があります。トラブル対応フローとしてこのような報告を行うときに記載する項目を決めておくのはとてもオススメです。
この初期報告時の情報充実度によってそのあとの対応速度は大きく変わってきますので、みなさんの社内でもぜひルールを作ってください。
kintoneでの業務改善・システム開発で困った場合は、弊社で実施している「kintoneよろず相談会」でご相談いただけますので参加してみてください。
