おはようニコ・ロビン
kintone事件が起きました！
kintone事件が起きました
そうおっしゃる人がいました。
。
別に事件だとか、騒ぐこととかではありませんが、
その真相はこのような内容でした。
kintone担当者が辞めてしまい、アプリがメンテナンスできず、
継続できなくなった・・・これは事件だ
そうおっしゃっていました。
。
kintoneで管理者を行っていると、
当たり前に見ているプロパティの画面は、、、
一般ユーザからすると、当たり前ではありません。
「見ればわかる」という設定は、
見ないとわからない
ということになり、ブラックボックスになりがち、
いや、間違いなく、ブラックボックスになります。
。
ITC埼玉での講話で
1/30に講話した、ITコーディネーター協会様向けの講話で取り上げました。
。
。
はやしの取り組みや、
受賞内容や取り込んでいる内容よりも、、、
業務改善や、DX推進の取り組みについて、話をしました。
。
その中でも、、kintoneがブラックボックスにならないように、
設計書を作成することをお勧めしました。
。
。
これが最適！
というわけではありませんが、出来る限り設定を外から見れるようにしました。
。
kintoneアプリの設計手順
大事なことは、
・アプリのブラックボックス化を避けること
・アプリの乱立を避けること
・アプリどこいったか
・アプリの設定がよくわからない
なんてことを極力避けるために、、、
外部公開するために、出来ること、すぐに取り組める方法を考えます。
。
そしてまた、設計書を作るのではなく、
その設計書を元に、担当者にレビューをし、業務フローや流れを確認することで、、、
より良いアプリが出来上がる、というわけです。
。
ここにノーコードの弱さがあります。
kitoneはTV-CMなどで、
シュシュっと作れます
と簡単に作れることをアピールしていますが、
簡単に作れてしまうデメリットがあるのです。
。
簡単に作ってはいけない、、、どうするか？
簡単に作れてしまうと、
・その人の思いだけで作れ
・全員が使えるアプリにならないケースもあり
・その人が不在になると運用できない
そんな場合があります。
。
まさに簡単に作ると、
簡単に使用を辞めてしまう。
。
だからこそ、入口は簡単に作ったアプリであったとしても、
自己満足で終わらせず、
その組織内、部門内での運用を進める
ような動き方をしていくことで、、
簡単に使用を辞めなくてすむような、、、
。
運用に切り替えていくのがベターでしょう。
。
あんしん村のように基幹システムをkintoneで作ってしまった例はなかなかないでしょうが、、、
基幹システムがあって、
周辺システムをkintoneで作るというケースは多々あります。
だからこそ、簡単なアプリで終わってしまうケースもありますが、
だからこそ、基幹システムと連携したり、
あって助かっている！
という声が出るような周辺業務をシュシュっと作ることで、
生きてくることでしょう。
。
コメントを残す