「この要望は標準機能でできますか？それともカスタマイズが必要ですか？」——kintoneの導入や改善の相談で、最初に出てくる質問の一つです。

答えを急ぐあまり、標準機能で足りるのに開発を依頼してしまう、あるいは無理に標準機能で運用して現場が疲弊するといったミスマッチが起きがちです。本記事ではkintone開発を担当するHさん（エンジニア・PM）の解説をもとに、標準機能で足りるか、カスタマイズが必要かを見極める判断軸を整理します。

最初に「やりたいこと」を業務の言葉で書き出す

よくある失敗パターン：機能名から入って、目的が曖昧なまま話が進む

「ルックアップを使いたい」「プラグインで何とかしたい」のように、手段から相談が始まるケースは少なくありません。しかし、手段が先に決まると、本当に必要な要件が見えなくなります。

Hさんは、相談の最初に「誰が・いつ・何のために・どんなデータを扱うのか」を業務の言葉で書き出してもらうようにしているそうです。「月末に営業部の事務担当者が、案件ごとの請求額を確認して経理に渡す」といった粒度まで言葉にすると、必要な機能と、そうでない機能が自然と分かれてきます。

対策

• 手段（機能名・プラグイン名）ではなく、業務の流れと困りごとから書き出す
• 「必須の要件」と「あれば嬉しい要件」を分けて整理する
• 現状の業務フローを図や表にして、関係者で認識をそろえる

標準機能で対応しやすい領域を知る

よくある失敗パターン：標準機能の守備範囲を知らないまま、開発前提で話を進める

kintoneは、データの入力・一覧表示・絞り込み・集計・通知・承認といった業務アプリの基本機能が、ノーコードで一通りそろっています。入力項目の追加や並び替え、閲覧・編集の権限設定、条件に応じた通知、一覧やグラフでの見える化などは、多くの場合、標準機能の設定で対応できます。

要望を聞いたときに「開発が必要そうですね」と早合点せず、まず標準機能での実現方法を一通り検証することが、結果的にコストを抑える近道になります。

カスタマイズを検討すべき「サイン」

よくある失敗パターン：標準機能の範囲外なのに、運用でカバーし続ける

一方で、標準機能だけで無理に運用し続けると、現場の負担が積み上がっていくケースもあります。次のような状況が見えてきたら、プラグインやカスタマイズを検討するタイミングです。

ここで大切なのは、「不便だから開発」ではなく、「その不便が、どのくらいの手間やミスにつながっているか」で判断することです。毎日全員が手作業で行っているものと、月に一度だけ誰かがやる作業では、かけてよいコストが変わります。

「標準 → プラグイン → 開発」の順で検討する

よくある失敗パターン：いきなりJavaScript開発から入って、保守負担が膨らむ

要望の実現手段は、おおまかに次の3段階に分けて考えると整理しやすくなります。

• 標準機能：設定だけで実現できる。保守の手間がもっとも小さい
• プラグイン：既製品を追加して実現する。導入が早い反面、提供元の更新状況や相性の確認が必要
• 開発（JavaScript・API連携など）：自由度は高いが、初期費用に加えて、kintone本体の更新への追従など保守の負担が続く

基本の考え方は、上から順に検討し、足りない部分にだけ次の手段を使うことです。開発は強力ですが、そのぶん「作って終わり」にならない点に注意が必要です。

判断に迷ったときのチェックポイント

最終的な判断に迷うときは、次の観点で整理してみてください。

相談前に用意しておくと話が早い情報

開発会社やパートナーに相談する際、次の情報があると、標準機能で足りるか、どこにカスタマイズが必要かを短時間で整理できます。

• 現在の業務の流れ（誰が・何を・どの順で行っているか）
• 今使っているExcelや帳票、システムのサンプル
• 困っていること（ミスや手間が発生している場面）
• 使う人数・部署と、社外の人が関わるかどうか
• 連携したい他のシステムがあるか

完璧な要件定義が固まっていなくても問題ありません。「困っていること」が具体的に伝わるほど、標準機能で解決できる範囲と、カスタマイズが必要な範囲を切り分けやすくなります。

まとめ

標準機能で足りるのか、カスタマイズが必要なのかは、kintoneの知識だけでなく、業務を理解したうえでの見極めが求められます。アクロネットでは、kintoneの導入支援からカスタマイズ・保守まで一貫して対応しています。「これは標準機能でできる？」という段階からでも、お気軽にご相談ください。

アクロネットへのご相談・お問い合わせはこちら