前回の記事でKintoneって結局なんなの？というところを考察してきました。
今回はKintone化する意義のあるパターンはどのような場合なのか、逆にKintone化する必要がないのはどういうものか、考えてみたいと思います。
まずざっくりした基準ですが「現状Excelなどで管理できていて、運用上特段不満等が生じていないもの」については、Kintone化する必要はありません。
何でもKintone化すれば良い訳じゃないことは前回記事に書いた通りです。Excelに入力していたものをKintoneに変えるための作業習熟やメンテナンスなど、かえってややこしくなることもあるので、本当にKintone化する必要性があるか、意味があるかというところの見極め材料として、「現状のExcel運用で不満が有るか否か」は結構有力だと思います。
ただ、この不満が有るか否かの見極めが難しい。実際に入力作業をしている社員レベルでは特段不満はなくても、それを定期的に取りまとめている社員は例えば入力漏れや不明確な記述を、入力担当者に連絡して修正依頼をかけないといけないとか、あるいはそのExcelデータをもとに報告を受ける社員は、現在は集計の手間との兼ね合いから月1回報告となっているが、出来れば集1回報告がもらいたい、あるいはここを見てくれれば大体わかるという状態にしたいとかいう不満や要望がある場合があります。
上記の場合、データを作っている現場だけの判断だとKintone導入は見送りということになるでしょう。現場だけでなく、そのデータを使っている先のフェーズまでを俯瞰で捉えて、導入効果を見極める「冷静さ」と、導入を決めたあとは見送りたがっている現場を説得してKintoneを作り込んでいく「熱さ」が求められます。
Kintoneはローコードツールなので、システム外注のように発注先にやりたいことを伝えておしまいではありません。むしろ導入を決めてからが一番大事なフェーズとなります。ここで取りまとめ社員や報告をもらいたい社員が「Kintone導入したから、あとは現場でうまいことやって」では絶対に失敗します。現場としては現状のExcel入力で不満を感じていないし、取りまとめや報告を受ける社員側の不満や要望を理解できません。表面上は「わかりました」と言ったとしても、実際に取りまとめや報告を受けることをしていないので、不満や要望の細部、ニュアンスまで現場に腹落ちさせることは不可能です。
上記の例の場合であれば、私はKintoneのひな型は取りまとめ社員、あるいは報告を受ける社員がまず作ることをおすすめします。その上でどのレベルまでなら現場で対応できるか調整するのが結局手戻りがなくて早いと思います。逆にそのレベルの負担を取りまとめや報告を受ける社員が厭うようであれば、その程度の不満や要望だったということで現場に負担をかけることなく採用を見送れば良いと思います。
長くなってきたので、次回記事でKintone化する意義のあるパターン例を提示して考察したいと思います。
