目次
kintoneを導入すると、必ず出てくるのが「これもできますか？」という現場からの要望です。そのとき問題になるのは、実現できるかどうかではありません。その要望が、標準機能の範囲なのか、開発が必要なのか——この線引きです。
ここを曖昧にしたまま業者に見積を依頼すると、標準でできることにまで開発費を払うことになります。逆に、開発が必要な要件を「設定でなんとかなるだろう」と甘く見て、途中で止まることもあります。
実案件（匿名）でkintoneを導入した際、私たちは出てきた要望を3つに仕分けしながら進めました。その判断軸を整理します。
この記事の結論
- 要望は「標準で組める」「設定で回避」「開発が必要」の3つに仕分ける
- 帳票の体裁・アプリ横断の集計・外部連携は開発側に寄る
- 見積依頼の前に、キー・権限・帳票・件数の4点を社内で決める
kintoneの要望を3つに仕分ける
まず、出てきた要望をそのまま業者に渡さないことです。社内で次の3分類に振り分けてから相談すると、話が早く、費用も抑えられます。
大事なのは順番です。いきなり「開発が必要か」を考えるのではなく、標準 → 設定の工夫 → 開発の順に落としていきます。この順番を守るだけで、外注する範囲はかなり小さくなります。
標準機能で足りることが多い要件
実案件で「これは標準でいけます」と判断したのは、次のようなものでした。
| 要望の例 | 対応 |
|---|---|
| 担当者ごとに見たい一覧が違う | 一覧の絞り込み条件を複数作る |
| 月次の状況をグラフで見たい | 標準のグラフ機能で集計・表示 |
| 顧客情報を案件アプリに引っ張りたい | アプリ間のルックアップ |
| 承認が必要なときに知らせたい | 条件通知・プロセス管理 |
一覧の絞り込み・グラフ・ルックアップ・通知。この4つは、kintoneが最初から持っている機能でかなりのところまで届きます。「一覧が見づらい」「集計が欲しい」「転記が面倒」という声の大半は、ここで解決します。
現場の要望は「〜という画面が欲しい」という形で上がってきますが、その裏にあるのは「必要な情報にすぐ辿り着きたい」という目的です。目的まで戻すと、標準機能の組み合わせで足りることが多くなります。
開発が必要になる要件の見分け方
一方、設定だけでは届かず開発側に寄るのは、次の3つです。
帳票の体裁を細かく指定したい
「いつもの請求書のレイアウトで出したい」「押印欄の位置はここ」——この手の要望は、標準の印刷機能では届きません。体裁を指定した帳票出力は、プラグインか開発の領域になります。
複数アプリをまたいで集計したい
kintoneの集計は、基本的に1アプリの中で完結します。案件アプリと請求アプリと原価アプリを横断して1枚の数字にまとめる、といった要件は、標準の枠を出ます。
外部システムと同期したい
会計ソフトや基幹システムとデータを行き来させる要件も、開発側です。なお、連携の可否は契約プランでAPIが使えるかどうかに左右されます。仕様やプラン体系は変わるため、最新の条件は必ず公式サイトで確認してください。
この3つに当てはまったら、素直に「開発が必要」と判断して構いません。逆に言えば、この3つに当てはまらない要望は、まず標準機能を疑うのが正しい順番です。
kintoneルックアップ設計の落とし穴
標準機能で足りると書いたルックアップですが、ここだけは設計を誤ると後から破綻します。自社で検証したときに、実際に起きたことを2つ紹介します。
キーに名称を使うと表記ゆれで一致しない
ルックアップは「何をキーにして相手のレコードを探すか」を決める機能です。ここで会社名や商品名といった名称をキーにすると、表記ゆれで一致しなくなります。株式会社の前後、全角半角、スペースの有無——人が入力する限り、表記は必ずぶれます。
キーには、コードや番号など変更されず、ぶれない値を使います。顧客コード、商品コードを先に整備しておくことが、ルックアップ設計の前提になります。
設計変更が既存レコードに反映されない
もう1つが、あとから設計を変えたときの挙動です。ルックアップの取得項目を変更しても、すでに登録済みのレコードには自動で反映されません。検証時には、金額の項目がゼロのまま残るという状態が発生しました。
新しく作ったレコードは正しく動くので、見た目には気づきにくいのが厄介です。過去分は一括更新をかけるなど、別の手当てが必要になります。
つまりルックアップは「標準機能だから簡単」ではなく、標準機能だからこそ最初の設計で決まるのです。ここを外すと、開発を外注する前の段階で土台が崩れます。
見積依頼の前に社内で決めておく4項目
業者に相談する前に、次の4点を社内で決めておいてください。ここが曖昧なまま見積を取ると、前提が揺れて金額も期間も当てになりません。
1. キー：何で紐づけるか 顧客・商品・案件を、どのコードで一意に識別するか。名称でなくコードを決めます。既存の台帳にコードが無ければ、ここを整備するのが最初の仕事です。
2. 権限：誰が何を見られるか 全員が全件見られるのか、担当者のレコードだけか、部門単位か。権限設計は後から変えると影響範囲が広く、アプリの構成そのものに関わります。
3. 帳票：何を何種類出すか 請求書だけなのか、見積書・納品書も含むのか。体裁をどこまで既存に合わせるのか。帳票の枚数は、開発ボリュームに直結します。
4. 件数：どう増えていくか 月あたり何件増え、何年分を保持するか。現在の件数ではなく増え方を見ます。将来の件数によって、一覧の設計や集計の方式が変わります。
この4点を書き出した紙が1枚あるだけで、見積の精度は大きく変わります。逆にこれが無い状態で出てきた見積は、「前提が決まっていないぶんの余裕」が乗った金額になっていると考えてください。
まとめ
- kintoneの要望は標準 → 設定の工夫 → 開発の順に落として仕分ける
- 一覧の絞り込み・グラフ・ルックアップ・通知は標準で足りることが多い
- 帳票の体裁指定・アプリ横断の集計・外部システム連携は開発側
- ルックアップはキーに名称を使わない。設計変更は既存レコードに反映されない
- 見積依頼の前にキー・権限・帳票・件数の4点を社内で決めておく
よくある質問
Q. kintoneのカスタマイズはどこから外注が必要ですか？ 帳票の体裁を細かく指定する、複数アプリをまたいで集計する、外部システムと同期する——この3つに当てはまると開発側に寄ります。一覧の絞り込みやグラフ、ルックアップ、通知は標準機能で足りることが多いです。
Q. kintoneのルックアップで注意すべき設計ポイントは何ですか？ キーの選び方です。会社名などの名称をキーにすると表記ゆれで一致しません。変更されないコードをキーにしてください。また設計を変更しても既存レコードには自動反映されず、金額がゼロのまま残ることがあります。
Q. kintoneの見積を依頼する前に社内で決めておくことは？ キー（何で紐づけるか）、権限（誰が何を見られるか）、帳票の種類と枚数、件数の増え方の4点です。これが曖昧だと見積の前提が揺れ、開発途中の手戻りで費用も期間も膨らみます。
RENOYでは、kintoneの要望リストを「標準で組める／設定で回避できる／開発が必要」に仕分けするところから、無料相談で承っています。「見積を取る前に、どこまで標準でできるか知りたい」という段階のご相談も歓迎です。まずはお気軽に無料個別相談（オンライン・60分）をご利用ください。サービス内容をまとめた資料は資料請求からご覧いただけます。