kintoneアンチパターン：従来の機能・やり方をそのまま移行

みなさんこんにちは。プロジェクト・アスノートの松田です。

kintone導入パターン

kintoneの導入は各社それぞれの、導入パターンがあると思います。
その多くのパターンは、次の２つ。

１．既存の業務システムをkintoneに置き換える
２．システム化されていない従来業務をkintone化する

どちらも、もとからあるもの（業務、システム）を、kintoneで置き換える。
ということが共通しています。

既存の業務をkintone化するときの注意ポイント

このときに注意すべきこと。それは、

既存のものをそのままkintone化しない

ということです。

kintoneの基本機能はかなり充実しています。業務システムを作るために必要な機能がたくさん揃っています。しかし、そこには「kintone流の」という前提があります。

実現したい業務の要件があるとき、それを実現するための手段は一つではありません。既存の業務システム、特にフルスクラッチで開発されたものは、その画面構成や使い勝手を、ユーザー側の要望に沿って作り込むことができます。一方、パッケージシステムも、そのシステム流のやり方で各機能を持っています。

kintoneのいいところは、「kintone流」を理解した上で、kintoneの持つさまざまな機能を組み合わせて、業務要件を実現できるというところだと思います。
とにかく多機能で難しいExcelとかと比べると、kintoneの機能を覚えることは簡単です。その代わりに機能を組み合わせるアイデアや工夫が必要となります。

これkintoneっぽさを理解したうえで、kintone的な業務要件の実現方法を使いこなすことが、kintoneを使いこなすために必要なスキルとなります。

やってはいけない考え方は次の２つです。

①いままでこうやっていた　をそのままkintoneで実現しようとする
②既存の使い勝手や見た目を　そのままkintoneで実現しようとする。

従来の機能を移行（再現）するのではなく、従来の機能要件すなわち、業務上必要なことを、kintoneの機能でどうやって実現するか？という考え方でアプリの設計を考えていく必要があります。

僕はよく、kintoneっぽくないことをムリヤリ作ろうとすることを、
「kintoneに無理をさせてる」
という言い方をします。

kintoneに無理をさせてこちらのやり方にムリヤリ合わせるのではなく、いいところ、得意なやり方を理解したうえで、それを活かすような使い方をする。ときにはこちらのやり方を変えることもある。
これが、正しいkintone化　のあり方なんだと思います。

kintone化のタイミングは業務見直しのチャンス

業務システムが変更になるタイミングというのは、数少ない業務そのものの見直しチャンスです。

しかし、多くの場合、従来あるものを丸ごと再現するだけという、単なる置き換えが行われています。これは非常に非常にもったいないことです。

特にkintoneは、システムの開発にかかる工数が非常に低く、プロトタイプのアプリを作ってみて、使い勝手を試してみることも割と楽にできます。このkintoneの強みを活かしながら、業務そのものの見直しを行うべきです。

その作業は本当に必要なのか？
そのプロセスは本当に必要か？最適なのか？
その承認は本当に必要か？

といった目で、これまでの業務のやり方を見直す機会にすることを、強く強くオススメします。