kintone(キントーン)構築・伴走会社のペパコミ株式会社で、kintone(キントーン)活用ちゃんねるのハルクです！
今日の動画は「ペパコミのkintone(キントーン)構築スタイル」について語っていきます。
kintone(キントーン)導入しようと思っている人には特に見てもらいたい動画です。
過去この手の動画も色々上げていますが、じゃあお前のところはどうやねん！となると思うので、うちはこういうスタンスですということをお伝えします。過去動画と併せて是非ご確認下さい
実際にペパコミの実績としては、CybozuAWARD2022を受賞させて頂いたり、サイボウズ評価制度で評価頂いたりと導入実績数は多くあります。
多くあるということはその分だけ経験値もありますし、うまくいくパターン・いかないパターンも分かってきています。新たな発見があったりしたらブラッシュアップしながらやっています。
そのため、常にペパコミの構築スタイルは時代背景に合わせて変わっていく可能性はありますが、2023年時点だとこんなんですよ～という内容となります。
宣伝を挟んでから内容にいきます
このチャンネルは、kintone(キントーン)の構築・運用コンサル会社であるペパコミが運営しております。kintone(キントーン)に関する情報を幅広く発信しておりますので是非チャンネル登録をお待ちしています
また概要欄にプラグインリストをプレゼントしています！フォームに入力すると自動返信で配っていますので是非お申込み下さい！それでは内容へいきます！
①伴走しながら構築をする
ペパコミでは
①kinoneを0から要件定義して構築する構築サービス
②定期的なMTGで毎月少しずつ改修・教育を行う運用サポートコンサル
③kintone(キントーン)社内教育研修
大きくこの３つをサービスとして提供していますが、どのサービスも共通なのが「伴走支援」です
伴走 つまり一緒に走りながらサービス提供ということです。
例えば一番多い初期構築サービスですと、一般的には要件を最初に全て定義して、その通りにシステム会社が構築をして納品が基本です。しかしペパコミではこういう構築はしません。
①kintone(キントーン)の柔軟性・拡張性の高さを活かせないから
②認識がズレてトラブルになるから
③延々とベンダー依存になってしまうから
１つずつ解説していきます
①-1.kintoneの柔軟性・拡張性の高さを活かせないから
仮に納品が終わって改修フェーズになったとしても要望通りに作るということは、作ったことに対してのフィードバッグしか発生しません。本来kintone(キントーン)の改修は型にとらわれずベンダーと導入企業双方が自由にアイディアを出しながら改修をしていくことが大事だと考えています
しかしそれを伴走しないで依頼したらベンダーが作って納品みたいな一方通行な構図にしてしまうと、お互いが協力的に同じ目線を向いての改善ではなくなってしまいます。
本来kintone(キントーン)はそのような改善が得意な領域なのに、お互いが同じ目線を向かないことでkintone(キントーン)の特性を活かせないのは非常にもったいないです。
〇〇と言ったじゃないか！みたいな責任の押し付け合いではなくベンダーと導入企業が同じ目線・目標に向かって進めることが大切です。
①-2.認識がズレてトラブルになるから
さっきの話に通じますが、伴走的に構築をしないと導入したお客様がkintone(キントーン)の理解をしないまま構築が進んでいきます。
そうなると要望の粒度は延々と荒いまま要望を出したりして、結果ベンダー側も苦労します。
これが後々トラブルに発展するので、そういう意味でも伴走は大事です。
①-3. 延々とベンダー依存になってしまうから
これも同じですが、結局導入企業側がkintone(キントーン)についての知識がいつまでも深まらないので、改修はベンダーに依頼するしか手段がなくなってしまいます。
kintone(キントーン)は本来自分達で改修が出来るのに、そういう関係値・理解度でないがために延々とベンダーにお金を払って頼らなければいけない構造となってしまいます
②言われた通りに作らない
続いて相手の言われた要望通りに作らないということを意識しています。
え？と思うかもしれませんが、相手の言っている要望が正しくないことがよくあります。
「その通りに作ればいけるけど、こういうリスクあるよ？大丈夫？こっちのほうがよくないですか？」とか、時には「絶対それじゃうまくいかないのでこうしましょう」と言い切ることもよくあります。
なので、言い方悪いですが僕は常に相手の言っていることを疑っています。目的は相手の要望を実現することではなく、相手の課題解決をすることなんです。これは似て非なることなんですよね。
だから「これはkintone(キントーン)でやらないほうがいい」なども平気で言います。恋は盲目じゃないですが、全部kintone(キントーン)でやったほうがいいと思ってしまう人結構いるんですが、違うんですよね。
課題の本質的な解決のためには、もっと広い視野を持つ必要があるんです。でも実際目の前の業務に忙殺されて且つその業務をずっと行っていると他の選択肢が見えなくなってしまうことがよくあります。
だからこそペパコミのようなkintone(キントーン)のプロが冷静に第三者目線を持ちながら相手にしっかりと伝えるという姿勢がめちゃくちゃ大事だと思っています。この姿勢はkintone(キントーン)ベンダーには特に必要だと思っています。
kintone(キントーン)は少しいじれば色々と出来てしまうのでkintone(キントーン)で無理やりやってしまう会社も少なくありません。何度も言いますが本質は相手の課題解決。
その課題解決のためには冷静な目線で言い切る・汲み取るというのもとても重要です。そのためにはベンダーに求められるのはいつも言っていますが「相手の業務理解能力」です。
業務理解能力がない相手の言ってる意見（要望）に対してそれをやるべきか・やらないべきかという判断ができないから言われた通りにやるしかなくなります。
何回も言いますが言われた通りにやることは相手にとっての課題解決とは限らないです。
その為には相手の業務理解能力はとても大事です。
③とりあえず作ってみる
続いてペパコミが意識しているのはココ。とりあえず作って見せてみるところです。
導入企業からするとkintone(キントーン)で課題解決出来るのが分かっても、具体的にどういう運用になるのか？分からないですよね。
イメージつかないですよね？そうなると「こういうパターンの時はどうなるんだ」「こういうパターンの時もあるので・・」みたいな要望がよく出てくるのですが、ハッキリ言って不毛なやり取りです
この手の要望は意味がないです。その要望に対していくら分かりやすく回答したとしても導入企業側はkintone(キントーン)でどうなるか？どんなことが出来るか？が全くイメージ出来ていないからただの机上の空論になります。
そのためには簡単です。まずは作って一旦見せて、kintone(キントーン)というものを理解してもらいます。
実物を見ることでkintone(キントーン)に対するイメージが沸いて、そうなるとkintone(キントーン)で出来ること・出来ないことが分かってくるんです。出来ることが分かった状態での質問と分からない状態の質問では天地の差があります。
またkintone(キントーン)のことが分かってくるとベンダーと自然と協力体制になってくるんです。
なのでペパコミでは、言い方は悪いかもしれませんがとにかく荒くてもいいから作って見せるということを意識しています。
相手のkintone(キントーン)レベルを置き去りにしない。構築しながら一緒にレベル上げをしていくとkintone(キントーン)の精度は遥かに上がります。だからこそこの視点がなく、理解しようとしなく協力的じゃない会社の案件はお断りしています。
まず出来ることが分かってから色々要望を出すのが一番スムーズにいくのでまず作ってみるというところを意識しています。
④技術的に出来るか？ではなく運用的に出来るか？を考える
要件定義をしていく際に
①kintone(キントーン)の技術的に可能
②相手の会社でも運用が可能
常にこの2軸を念頭に置いて設計しています。
技術的に作れても運用できなければシステムは無意味。また同じ設計でも相手の会社のレベル・リテラシーによっても変わってくるのでそのあたりも冷静に見極めています
で、更に難しいのが相手の会社、特に社長は「いやウチなら大丈夫！リテラシー高いし、若い子多いから」とか言うんですよ
これも信じてませんｗそうやって言って運用出来ない会社をたくさん見てきました。
そのくらい運用面はシビアに考えてちょうどいいくらいだと思っています。なのでkintone(キントーン)で難しいことを無理にやらないようにしています。
さっきから言っているようにkintone(キントーン)で課題解決するのが目的ではなく、（お客様の）課題解決することが目的です。kintone(キントーン)にこだわる必要はないんです。
だからkintone(キントーン)で難しい場合は少し軸を変えてどうやったら出来るか？を提案し続けることもペパコミは意識しています
⑤標準機能＞プラグイン＞開発
基本的にはまず標準機能で出来るかどうか？
難しければプラグインで出来るかどうか？
それでも難しくて、どうしてもどーーーしてもやりたい場合にJavascript開発などを行います。
ペパコミとしてはkintone(キントーン)の改修を出来れば内製化してもらいたいんです。
そのためにはプラグインや開発が入るほど内製化の難易度が上がるので、この優先順位を意識しています。
⑥相手のスタンスに合わせる
とは言え、kintone(キントーン)改修を内製化しようと思っていない会社もいます。社内のリソースもありますからね。
将来的に内製化したくて勉強意欲があるなら教育しながら開発するし、単純に外注先としてお願いしたいならペパコミが改修に全振りで巻き取って構築します。
相手のニーズがあるものなので、kintone(キントーン)だから内製化！みたいな凝り固まった考え方は持たないようにしています。
何度も言うように目的はお客様の課題解決です！ただ出来れば時間と費用が掛かっても内製化のためにkintone(キントーン)をペパコミと一緒に伴走してもらえると嬉しいなと思っております！
まとめ
今回はペパコミがkintone(キントーン)構築する上で意識しているポイントを中途半端ですが６点まとめました！
まとめると
①伴走しながら構築をする
②言われた通りに作らない
③とりあえず作ってみる
④技術的に出来るか？ではなく運用的に出来るか？を考える
⑤標準機能＞プラグイン＞開発
⑥相手のスタンスに合わせる
別動画でペパコミの構築責任者から伴走構築とはなんぞや？について対談動画をアップする予定ですので、そちらも是非ご覧ください！
伴走という言葉を今日使いましたが、より深堀りした形でお届け出来るかと思います！
ということで以上になります！
これからもkintone(キントーン)に関する情報を発信していきますのでチャンネル登録お待ちしております。
本日もどうもありがとうございました。
コメント