中小企業失敗例～kintoneアプリ開発の進め方～
昨今、CMでもよく見かけるようになった「kintone」
うちの会社でも顧客管理システムの入れ換えで業者から提案を受け、その費用感や柔軟性を評価して導入されました。
kintoneがどんなソフトか、というのはこちらの記事をご確認ください。
しかし、安くて簡単なkintoneだからこそ、うちの会社はその進め方に戸惑っています。
その悩みの種の一つがアプリ開発の進め方です。
簡単に言うと、以下の二つです。
- 誰が作る
- 誰が承認する
ここの決め方が曖昧でうちの会社はスタートに失敗しました。。。
同じような失敗をされる方が一人でも減ることを願って、
恥をさらす気持ちでうちの会社の失敗談を交えて解説します！
この記事を読んでほしいのは、以下のような方々です！
- これからkintoneを導入される方
- Kintoneを導入したけど積極的には使えていない方々
Kintone開発権限の設定
大きく分けて2つの方法があります。
- 大勢で作る
- 少数精鋭で作る
結論から言うと、私は後者派です。
とはいえ、前者が間違えだ、とは思いません。
Kintoneアプリを大勢で作る方法
Kintoneはプログラマーでなくても簡単にアプリが作れる、というのが大きな特長です。
ノーコード開発といい、オブジェクトのドラッグ&ドロップでアプリを作ることができます。
そのため、情報システム部や社内SEに頼りすぎる必要もなく社内業務をシステム化していくことが出来ます。
営業なら営業、経理なら経理で各部署で現場担当者がお困りことをシステム化で解決することができるので現場目線のアプリを作ることが出来ます。
と、ここまではメリットのお話。
前述の通り、アプリ開発は少数精鋭はの私は次のような懸念をしています。
- 同じようなアプリが重複しない
- そもそも現場は本当に作るのか
１について、kintoneはクラウド型データベースという特長もあります。
各自がExcelなどでバラバラの書式で管理していたものなどをkintoneにまとめて一元管理できる、という利点があります。
例えば名刺管理。
人によっては名刺をファイリング、ある人はPDFにして保存、ある人はExcelに記載していたものを、kintoneで作ったアプリに入力すること！とすることで、自社のコネクションは一元管理できるので、過去の名刺を探す場合はkintoneを見ればいいのでアチコチ探す必要がありません。
しかし、複数拠点で別々で作ってしまうと、結局管理場所が複数になってしまいます。東京本社のもらった名刺はここ、大阪支店の名刺はあっち、技術部はそっち、なんて複数に分かれてしまうと結局複数箇所を探す必要があります。
実際にうちの会社でも顧客管理アプリを管理職３人がバラバラで作っていました。当事者たちはお互いに他の人が作っていたことを知らず、良かれと思って作業していたようです。
また、汎用性の高い情報である「商品一覧」のようなアプリは多くの部署で必要とする情報です。
見積作成アプリにも必要、在庫管理にも必要、売上管理にも必要なので複数部署が必要とする情報です。
こちらも複数部署が各自で作ってしまうと商品情報も多元管理されてしまうことになります。
たとえば新しい商品ができたとき、アプリが３つあれば３つ更新しなければいけないことになります。
つまり、誰が何を作るのか、事前に明確にできていれば良いのでしょうが、営業部が作った商品一覧アプリが技術部が使いたい形かどうかはわかりません。では事前に打合せしてから作りましょう、となっても誰が商品一覧アプリを欲しているかを把握して、各部署に声かけて、各自が言いたいことを言って、それをまとめてからアプリをつくって、とするのは「気軽にアプリが作れる」というkintoneの個性を潰す運用です。
つぎに、「２.そもそも現場は本当に作るのか」です。
Kintoneはあくまでもツールのひとつです。
Kintoneがなくても、業務効率化したい人はExcelやACCESSを使って業務の効率化を図っていたのではないでしょうか？
今までExcelしか使えるものがなかった人にとって新たな選択肢が増えるということは大きな前進となり得ます。
が、そんな人って何人いますか？営業で目先の営業のことだけでなく、「こうすれば見積を作るのが楽になる」なんて考えて上司に提案して、自分でExcelの書式を変えてくれる人は極めて優秀な人材ではないでしょうか。
また、現場は本当に困っているのでしょうか。慣れというのは恐ろしいもので、Excelで見積を作ることに慣れていれば別にそれを不便だとは思っていないケースも多々あります。
むしろ、慣れたものを変えられることを嫌がる人もいることでしょう。
私もSE時代に客先納品を実施したときに、導入担当者は「便利なソフトが入った」ということで喜んでくれていましたが、操作担当者の方操作方法を覚えないといけないことに途方にくれ、インストール作業中の私に愚痴を言ってくる、という経験が何回かあります。
なので、「使っていいぞ！」と現場に指示を出しても、現場は必要ないと思ってしまう可能性もあります。
実際にうちの会社では「作っていいぞ！」といわれて作り始めたのはプログラマー１人だけでした。号令の対象は３０人くらいなので、実際に動いたのは３％くらいで、それももともとプログラミングができる人だけでした。
これらを踏まえて、「少数精鋭開発」の特徴に移ります。
Kintoneアプリを少数で作る方法
上述の通り、大勢で作るとkintoneの中で同一情報の多元管理が発生してしまう恐れがあります。
少数精鋭だと、コミュニケーションをとる相手が限られているので、誰が何を作るのか、どのような項目を入れるのかなど打ち合わせもスムーズです。全体の設計を決めてから作り始めることができるので、開発行程もスムーズです。
また、作る人が明確なので「本当に作るのか」なんて心配は全くありません。
現場の声が活きないのではないか、という懸念もあるかもしれませんが、kintoneは修正も簡単なので、一度フィールドに出して、現場の声を聞いて、修正していくPDCAサイクルで十分対応できます。
私のもつ唯一の懸念は、「現場のIT教育にならない」ということです。
大勢にさわってもらうことで、ソフトウェアを身近なものに感じてもらい、ITリテラシーを自発的に養ってもらう可能性がない、ということは大勢開発派と比べて劣っていると言えるでしょう。
しかし、私はこうも思います。
「Kintoneはひとつのツールにすぎない。kintoneでのアプリ開発がうまくなる、ということはITリテラシーが高くなる、ということではない。要件に応じてExcelやACCESS、kintone、場合によってはパッケージソフトなどの選択肢の中からどれが最適か選べることが真のITリテラシーだ」
つまり、kintoneでアプリを作るのが上手な人を育てることはさして重要でなく、もっと全体像を見て考えることができる人を育てることが大切で、それはkintoneをさわらせる、くらいのことでは出来ないと思います。ワークマンがExcel経営で成功した事例もあるので、夢みたい気持ちもありますが、それは自由にさわらせるだけでなく研修の成果なので、大勢にさわらせるなら社内研修までがセットです。
Excelのようなすでに馴染みのあるツールと異なり、社内に精通した人がいない状態でワークマンがExcelで成し遂げたことと同じことをkintoneで再現することは難しいと思います。
ただし、その辺も見越してか、kintoneはヘルプも充実しており、ハウツー動画も充実しているので、勉強する環境は十分に揃っています。管理職側の持っていきかた次第で十分に現場にkintoneを覚えてもらう運用は可能だと思います。
まとめ
私はkintoneアプリは少数精鋭で進めるべきだと思います。
誰でもアプリを作れるのは魅力ですが、設計が上手とは限りません。料理がうまい人でもプロのシェフほどレシピのアイデアはなく、DIYが上手な人でも住宅の設計は設計士には敵わないと思います。
とはいえ、みんなに使ってもらいたい、という気持ちも十分理解できます。そこで、私の思うこの２策のハイブリッド案は以下の通りです。
まずは、少数で軌道に乗せる、社内での運用が浸透してきた頃に、修正案がある人には修正してもらう、あるいはそこから派生したアプリを思い付いたら作ってもらう、というものです。どんなソフトでも一番難しいのは導入だと思います。過去のデータの移管も必要です。それをITリテラシーに長けない人に丸投げしても進まないことはうちの会社が証明しています。。。
何回かレシピにしたがって料理を作っているうちに、もっと濃い方が好みだから調味料を足すとか、牛肉じゃなくて豚肉でやってみるというのは難しくなく、失敗のリスクも低いと思います。住宅が出来たあとに棚を増やしたりウッドデッキ作ったりすることも失敗しても生活に支障は出ません。それと同じように、大本は「プロ」が担当すべきだというのが私の意見です。
「そんなこといっても、うちにはITに詳しい人いないよ」って思われるかたもいるかもしれませんね。しかし、kintoneはCybozu社のパートナーが導入を支援してくれます。「やりたいこと」を伝えれば、アプリも作ってくれるので、その初期費用は惜しまないのが得策だと思います。
