任せるな、つくれ。

開発で終わらない。つくる力を、
一緒につくる kintone伴走支援。

開発自走する力を身に着けろ

最初から自社開発だけで成果を出せる会社は、ほんの一握りです。
一方で、開発をすべて外部に任せると、改修のたびに外部へ頼り続けることになります。

「任せるな、つくれ」は、最初から自分でつくれという意味ではありません。
最初の土台はプロがつくり、開発と教育を同時に進めながら、
kintoneの主導権を少しずつ御社へ移していく。
魚を渡しながら、釣り方もお伝えします。

ペパコミのkintone伴走支援で御社が手にするのは以下です。

ペパコミがつくる

業務に合う、
kintoneの土台

業務とデータの流れを整理
後から変更できる構造で設計・開発

定例MTGで身につける

自分たちで、
直して育てる力

設計の意図を理解する
改修の影響と優先順位を判断する
日常の改修を自社で行う

その結果

変化に強い、
つくれる会社

業務が変わっても、自社の判断と速度でkintoneを変えられる

なぜペパコミは、
“つくれるようにする”へ
こだわり続けるのか。

代表小川が、この考え方に至った理由、
他のkintoneパートナーとの違い、支援による変化を、
3分の動画にまとめてお伝えします。

YouTubeチャンネルへ

ペパコミを初めて知った方、
kintoneをこれから
検討する方へ

ペパコミの考え方と支援の進め方、費用、ご相談から支援開始までの流れをまとめています。

初めての方へ

kintoneを導入したのに、
こうなっていませんか？

開発会社に依頼した場合

簡単な相談でも日程調整・MTG・実装と時間が掛かる
形としては出来てるが、意味を理解出来ない
こっちの思っていた通りの実装が出来ていない
業務が変わるたびに、改修費用がかかる

自社で構築した場合

つくった担当者しか直せず、辞めたら誰も直せない
アプリは出来ているが、ただ並んでいるだけで連携しておらず、kintoneの良さが実感出来ていない
新しく作る際も都度調べながら作るため時間が掛かる上、作ったものが最適解か分からない。
結局、現場が良さを実感出来ずにExcelに戻っている

当てはまるものがあれば、原因はほとんど同じです。

原因は自社に理解の深い
kintone担当者がいないことです。

開発をすべて
任せたkintoneは、
ブラックボックス化する。

kintoneの設計意図が
分からないまま運用が始まる
業務が変わるたび、
kintoneの改修を外注する
社内に知識が残らず、改善の
たびに費用と待ち時間が生まれる

プロと共につくることで、
自走する強い組織
に変える。

最初のkintone設計と土台開発は、
プロがリードする
実際のkintone開発と教育を、
同時に進める
アプリ改修の判断と操作を、
少しずつ自社へ移す

kintone改善の主導権を、
開発会社から自社へ。

必要な時だけプロに頼み、コスパ良く長期運用へ。
主導権がどちらにあるかで、改修1回にかかる時間はこれだけ変わります。

kintone改修の主導権が、
開発会社にある場合

開発会社へ外注

合計リードタイム

約20時間

合計リードタイム（イメージ）

約20時間

01問題・
要望発生
02改修内容
把握
03日程調整して
状況共有
04見積・
契約
05開発
06テスト・
確認
07納品・
リリース

改善速度は、完全に外部依存。

kintone改修の主導権が、
自社にある場合

自社で対応(内製化)

合計リードタイム

約4時間

合計リードタイム（イメージ）

約4時間

01問題・
要望発生
02改修内容
把握
03改修実施
04不明な点・
実現可否は
プロに相談

改善速度は、
すべて自社主導。

では、どうやって主導権を移していくのか。

それは、kintoneを深く理解した
担当者を育成することです。

ペパコミは、kintone開発と
内製化まで支援します。

1週次で定例MTGを実施。開発・教育を同時に行う
定例MTGで認識のズレをなくすことと、kintoneの教育を同時に行います。kintoneの理解度が上がると、より質の高い要望・質問が出てくるようになり、結果的に教育だけじゃなくレベルの高いkintoneが出来上がります。
2開発・改修方法を実践的に学んでいく
実際のアプリ開発・改修を共に行うことで、現場で即役立つ設計・開発・改修の実践で使えるノウハウを身につけていきます。
3主導権を移し、日々の改修を内製化
社内の理解度に合わせ改修範囲を自社へと移行し、日常的な業務変更も自社のスピード感でタイムリーに対応。
4外部依存を脱却し、自走を完成
最終的には開発会社の役割は開発・改修をお願いするのではなく、何かあった時に相談する立場を目指しましょう。

「頼んだのに、思ったものにならない」
その原因は、営業と開発の分断です。

開発会社の多くは、営業と開発が分かれています。

営業と開発が分かれている場合	場面	ペパコミ
kintoneの知識が浅いため、深い部分で実装可否についての話が出来ない。出来ないことも出来ると言われる。	商談	開発ができる人が同席し、できる・できないをその場で答える。
営業には出来ると言われていたことが、エンジニアに出来ないと言われる。	要件定義	商談段階から開発者が入るため、商談時からの認識のズレが起こらない。
仕様を満たせば完了。使われるかは見ない。	納品	定例で、現場で使われるまで一緒に直す。