kintone本番環境からjavascriptのnode.js/gulp開発環境もkintone開発環境も作る
kintoneの本番環境が既にあり、開発環境の構築が必要な場合向けにまとめます。kintone独特な独自用語やルールもあり、想像よりも事前学習に時間を要します。複数アプリで連携させてjavascriptでチーム開発を行う場合、開発環境の構築や環境差、ソースコード差分管理などのルール決めや情報共有を確実に行う為のインフラ構築リーダーがいないとヤバいです。kintoneはいわゆるSaasなのでLinuxのssh接続やgithubやvimなどを簡単に使える様なサービスでもない為、javascriptソースコード開発としての使いやすさについて「良い」とは言えない。開発チーム全員で開発進捗や履歴の共有が出来ていないと、ロジックや変数名やアプリ設計などチームの誰かによって変えられた場合に気付けない。
開発履歴情報やソースコード差分管理の共有は、プロジェクトチーム全員で必須です。promiseの非同期で取り扱うレコードやアプリのデータ量が増えてくると、挙動がかなり遅くなるので開発効率やモチベーションに影響します。開発環境の挙動が遅い分、開発受託の料金を上げないと赤字になりやすくなる。
間違っている点などありましたら、ご指摘ください。明確な正答を添えてご指摘を頂けますと大変うれしいです。
kintoneについて知っておくべき大前提
1アプリにつき1データセット（1CSV）で、1アプリに対してレコード一覧(index)・1レコード表示(show)・1レコード作成(create)・1レコード編集(edit/delete)の4画面がセットになっている、それがkintoneアプリ1個となる。
CRUDにあたるDBテーブルの設計データ（スキーマ）は？
本番環境のkintoneが書き出す（エクスポートする）アプリテンプレート（zip）に含まれる。GUI操作で文字列1行や数値などのフィールドタイプのドラッグ&ドロップで1アプリ設計（データベースの1テーブルに相当）できる。フィールドが多いと、フィールドコードの確認が非常に手間でめんどくさい。Saasのkintoneならではの不便さ。javascriptでコンソールログにフィールド名/フィールドコードの一覧表を表示させたり、エクセルでフィールドコード/フィールド名の一覧表を持っておくことを強く推奨します。
window.cybozuオブジェクトで全確認出来ます
フィールド名、フィールドコード、フィールドタイプ、必須、Minlength、etcについて以下を使うと全部確認出来ます。getterです。setterとして使えるかどうか確認が必要です。
const AppFields = Object.values(cybozu.data.page.FORM_DATA.schema.table.fieldList)
console.log(‘AppFields’,AppFields);
「要素ID」や「フィールドタイプ」の間違い、抜け落ち調査がやりにくい
要素IDやフィールドタイプやフィールドコードは「アプリの設定」⇒「フォーム」には出力されない！フォームの見通しが悪いです。
フォームにドラッグ&ドロップでフィールドタイプを設定した後、フィールドが多い場合、フィールドコードの確認がkintone標準機能だけではやりにくい。数値と文字列1行のフィールドタイプを間違えていて、SQLクエリが失敗している！などのケースではconsole.logを見るまで原因がわからない。デバッグがやりにくいので、見積の際は気を付ける事。
無料の「JSEdit for kintoneプラグイン」や無料の「kintone フィールド情報/データ一括更新プラグイン」を使ったり、フィールド名とフィールドコードを合わせたものを簡単に作れないですか？ を使うと楽になる。
kintone開発環境を構築するのに必要なものたち
以下、本番環境から調達する。
- アプリCSVファイル
- アプリテンプレート（zip）
- プラグイン（zip）。プラグインの設定も本番環境を見てメモしておく。
- kintone全体に対するJS/CSSファイル
- kintone REST APIの認証のユーザーアカウントや各アプリのトークン、これらは開発環境で新規発行したものに置き換える必要が有る。kintoneの複数アプリ間やサードパーティと連携してレコードの追加、更新、削除などを行う等の場合が該当しやすい。AWSを使わない場合、Base64エンコード/デコードやjson取り扱うならBufferなど実装が必要、node.jsのrequireモジュールでいろいろやると便利。Bufferは脆弱性があるので、Buffer.from/Buffer.alloc/Buffer.allocUnsafeを使う。
※jsonファイルを扱う場合、keyの大文字に注意！小文字に統一。
アプリテンプレート(zip)はDBのスキーマの様なファイルで、フィールド構成は含んでいますが、横行のレコードや各フィールド内のvalueは含んでいない。横行のレコードや各フィールドのvalueは「アプリCSVファイル」となる。
その他、本番環境のユーザー、ユーザーの利用サービス、組織、ユーザーの所属組織、役職、グループ（ロール）、ユーザーの所属グループ（ロール）について『Cybozu.com共通管理』はCSVダウンロードできます。
また、「kintone全体に対するJS/CSSファイル」は、アプリテンプレート（zip）に含まれていないです。
開発環境の調達はkintoneディベロッパーアカウントでOKです。
gulpなどのタスクランナーを使っている場合、node.jsのjavascriptのビルド開発環境の構築が出来ることが最低条件、顧客から価格への理解を得にくい。
「アプリテンプレート(zip)」作り方
本番環境の「ポータル」⇒右上の「歯車マーク」⇒「kintoneシステム管理」⇒「アプリテンプレート」⇒「作成」にて既存アプリのアプリテンプレート(zip)を作る事ができます。大前提として、既に存在しているアプリでなければ出来ない。また、複数のアプリを選ぶ事でまとめてアプリテンプレートにする事も出来、kintone上で『パック』とアプリテンプレートに追記されます。kintoneではアプリテンプレートについて『エクスポート』『インポート』という言い方ではない。本番環境アプリの『javascriptファイル/URL』や『cssファイル/URL』や『各アプリに適用しているプラグイン名』も一緒にアプリテンプレートがzipで「書き出し」され、別ドメインのkintone開発環境にそのままzipを「読み込む」、という言い方になります。アプリテンプレートには、プラグインは含まれていますが、プラグイン設定は含んでいない事が要注意点です。
アプリに適用するjavascriptファイルは、kintoneは基本的にUTF-8(BOMなし)です。外部連携するAPIがshift-jisなどで文字コード食い違いが発生する場合に注意！
プラグイン（zip）調達でお金が発生するかも
『ポータル』⇒『kintoneシステム管理』⇒『
kintoneプラグインは本番環境で削除や新規追加（zip）は出来ますが、『zip書き出し（エクスポート）』が出来ません。kintone スプレッドシート や ガントチャートプラグインの様な無償公開プラグインもありますが、有償無償はバラバラ。有償プラグインのzipの元ファイルを発注者がkintone本番環境とは別にファイルとして送ってくれるかどうか？事前に確認しておく必要が有る。
ご参考までに、絞り込み検索プラグインは20万円~30万円くらいだった気がします。
ハッシュ値で同じプラグイン、別プラグインの識別が出来ますが、全く同じ名前のプラグインをどれだけでも作られるため、同じ様なプラグインを複数作る際には命名ルールを最初に徹底する必要が有る。ハッシュ値じゃないと異なるプラグインを識別できない！という状態は混乱を引き起こす。
アプリテンプレート（zip)の書き出し
「ポータル」⇒右上の「歯車マーク」⇒「kintoneシステム管理」⇒「アプリテンプレート』⇒「書き出す」⇒書き出すテンプレートを選択⇒「書き出す」。「書き出す」直前の画面で「文字コード」と「区切り文字」を変えられる。この操作の途中、縦列のカラムに相当する部分を選択して書き出す事も出来る。
アプリテンプレートの読み込み、アプリ作成
「ポータル」⇒右上の「歯車マーク」⇒「kintoneシステム管理」⇒「アプリテンプレート」⇒「読み込む」。アプリ作成は、「ポータル」⇒アプリの「+（アプリを作成する）」⇒（あたらしくアプリをつくる）テンプレートから作成⇒アプリテンプレートを選ぶ。jsやcssも同時に読み込まれるので、あとは全レコードのCSVファイルを食わせる。アプリ名は本番環境のものがそのまま使われるが、（アプリの）「歯車マーク」設定の画面で後から自由に変更できる。アプリIDは、アプリ名にも記載して露出させておいた方が複数アプリをまたぐjavascript開発などでは使いやすくなる。
アプリCSVファイルの書き出しと読み込み
該当のアプリの一覧（index）で「アプリの設定」⇒「一覧」の選択肢で「（すべて）」を選択⇒画面右上の（アプリの設定を変更するの歯車マークの右）「・・・（オプション）」⇒「ファイルに書き出す」⇒「書き出す」でCSV書き出し。尚、「ファイルに書き出す」の後に縦のカラムを自由にドラッグ&ドロップで調整できる。読み込みは、「・・・（オプション）」⇒「ファイルから読み込む」。「読み込み」の際、「一括更新のキー」は読み込むCSVファイルとアプリ側にある既存のレコードの重複確認用のキーの指定で上書きをする事になる。「書き出す」「読み込み」ともに結構遅い。
権限設定でファイルの「書き出し」「読み込み」を出来無い場合が結構出てきます！フィールド（縦カラム）が多い場合、作業時間消耗となります。見積から欠落しない様に気を付けましょう。開発用にアプリCSVファイルのデモデータを発注元からもらえるかどうか？確認しておかないと、フィールドもアプリも数が多いkintone開発の場合、検証の前にデータを作る事から始まる・・・。開発準備のためのコストや時間が必要になる。kintone本番の各アプリのレコードをマスキングしてCSVファイルとして発注者から送ってもらえるかどうか？重要。
cli-kintoneで本番環境からCSVを得る事もできますが、本番環境がスタンダードライセンス以上でないとcli-kintoneを使えないので要注意。
アプリCSVファイルの読み込み、レコードの一括登録／更新に失敗するケース
アプリ側で一番上のフィールドを「一括更新のキー」にしている場合もレコードの一括登録／更新に失敗しやすい。また、アプリ側で既に「自動入力」にしているフィールドを「一括更新のキー」にするとエラーが出るので注意！
アプリ側のフィールドで「必須項目にする」に該当する部分がアプリCSVで空白などの場合も失敗する。アプリ側で「必須項目にする」のチェックを読み込み（インポート）の際は外して対応することになる。
GUIのアプリCSV「読み込み」処理は遅い。別作業に移って後から確認したら、読み込み（インポート）が失敗している！ということが起こりうる。
その他に、グローバル変数としてJSファイル内で定義したアプリIDやその他プレースホルダなどの書き換え手作業やプラグインの手作業設定が必要になる場合も有ります。※グローバルな定数などの定義を行うconfigファイルだけ分割しておくことが管理上、望ましいです。
アプリテンプレート作成に含まれない設定がやたらと細かい
アプリテンプレート作成に含まれない設定がこちらから確認出来ます。見積の際にどのくらい作業が複雑になるか、APIやjavascriptで他のアプリと連携してたりしていると、仕様変更の場合など、じっくり考えないと赤字ポイントになります。事前にアプリ1つ1つに対して「アプリテンプレート作成に含まれない設定」の表を作って全部チェックするなどもありかも。
また、「アプリコード」は、「アプリID」や「アプリ名」とは別物で、該当アプリの右上にある「歯車マーク（アプリの設定をする）」⇒「高度な設定」で設定できます。デフォルトでは設定されていない、空欄です。
ユーザー選択、組織選択、グループ選択とかも超めんどくさくなる。これらに紐づく設定は、アプリテンプレートには含まれない。手作業となる。まだ、ケース想定がパッと浮かばないですが、ドキュメントを見る限り、意外と注意しなければならない事が多く、めんどくさい。
kintone全体に対するJS/CSSファイル
「kintoneシステム管理」⇒「JavaScript / CSSでカスタマイズ」にある。忘れやすい。
アプリレコードのフォームとレコード一覧表示について
アプリのトップ画面で表示されるレコード一覧は、該当アプリの右上にある「歯車マーク（アプリの設定を変更する）」⇒「一覧」で表示/非表示するカラム（フィールド）を調整できる。フォームで構築されている縦列のカラムが画面上で全て表示されているとは限らない。
アプリ名の重複チェック機能がkintoneには無い！
同じアプリテンプレートからアプリを作ると、まったく同じ名前のアプリが2つ出来てしまいます。kintoneは、URLやkintone.app.getId();で確認できるアプリIDが主キーとなる識別であり、アプリ名の重複エラー告知はkintoneには実装されていない。アプリIDさえ異なれば、全部同じアプリ名で別のアプリを作る事ができ、ダッシュボードに全部同じアプリ名が並んでしまう事も可能となっている。kintoneはアプリのリソース管理がやりにくい。また、ログインしてから目的のアプリまでたどり着く導線がメンドクサイ。
アプリ名の命名ルール（参考）
本番環境：『接頭辞_アプリID_アプリ名』
開発環境：『接頭辞_アプリID_アプリ名_本番環境のアプリID』
接頭辞は、1000番台は営業履歴アプリ、2000番台は顧客管理アプリ、3000番台は社員管理アプリ、4000番台は進捗管理アプリなどの番号識別やDev01などの名称識別で紐づくアプリをまとめるなどをお勧めします。スペースの名称ンにしてもいいかも。
アプリ名の変え方は次の通りだが、GUIのフィーリングではわかりにくくて（気付けない）、挙動が遅い（我慢するしかない・・・）部分だったりするので要注意。該当のアプリの一覧トップページ⇒画面右上の「アプリの設定を変更する」⇒左上のアプリ名そのものをクリックすると変更できる（わかりにくい）。
kintoneはリソース管理（アプリのグループ分けなどの管理）がカオスになりやすいので、運用前にアプリの命名規則を必ず決めておくことを強くお勧めします。
ユーザーやアカウントなどの管理について
cybozu.com共通管理で行う。
cli-kintoneでCSVを扱う時の注意
『kintone コマンドラインツールの使い方』で確認でき、以下の通り。
GUIでは、xlsxとcsvが可能と書いてあり、『Excelブック形式：最大1MB、1,000行×50列まで CSV形式：最大100 MB、10万行×50列まで。』とのこと。Excel 2007、2010、2013のみ対応。2003は不可。
CSVインポートでアプリを作る事が出来る。先頭行のフィールド名、文字コード（shift-jis,utf-8）、区切り文字（カンマ、セミコロン、タブ、スペース）、アプリ側のフィールド名とCSVのフィールド名の結び付け、の設定が出来る、CSVのインポートが失敗する事がある。そして、データが大きいと読み込み（インポート）の待ち時間が長い。javascriptでSQLクエリも使える。
kintoneのjavascript開発、弱点
cli-kintoneでは『大量のデータ操作はkintoneに負荷がかかり、パフォーマンスに影響が出ることがありますのでご注意ください。』という定番の落とし穴がある。パフォーマンスのデッドラインが不明でスケーリング出来ない。一度に取得できるレコードは 500件まで。一度に更新できるレコードは 100 件まで。複数アプリをまたぎ、1アプリに大量のフィールドがあるアプリ連携開発など、1アプリ内で完結しない開発の場合、kintoneのjavascript開発は、その他の外部API連携も多くなるケースが予測され、学習量も多くなりがち。初回は赤字になりやすい。発注主から学習/検証コストへの理解を引き出しにくい。「バックアップ」の手間や精度、差分などの開発履歴管理にはgithubやsourcetreeがやはり便利。しかし、kintoneとgihubはgitbashで繋いでpageant鍵管理で一元操作できない。ファイルの取り回しが非常に面倒。「有料プラグインのライセンスコスト」、開発環境構築に時間がかかる。kintoneは5名以上から、gusukuCustomine、有料プラグインの価格は高い。kintoneはクライアントに請求したくなるコストが結構高い。買い叩かれるのは開発費・・・。
開発に途中参加する場合、アプリER図やjsのオブジェクトのリレーション図が無く、さらに、アプリ側の設計変更まで途中でされていると、設計を把握できない。1アプリ完結の小規模開発ならいいが、複数アプリをまたぐ開発の場合、アプリER図やjsのオブジェクトのリレーション図を書いた方が無難。後から楽になる。
フィールドコードについてはジョイゾーさんの「フィールド情報取得プラグイン」が便利ですが、1アプリのフィールド数が多すぎて使えない場合、kintone-fieldcodes.jsなどを使う。
開発履歴の差分管理も無く、ソースコード全解読が必要になった。アプリER図、jsオブジェクトリレーション図などは、途中でジョインする場合、無かったら書いた方がいい。『kintoneだから要らない！』と周囲から言われる可能性もあるが、最初からプロジェクトに携わっている人が要らないというのは当たり前。でも、書かないと途中参加の自分が困る。発注主のプロジェクト管理責任でもある。GUI操作レベルのkintone開発についてはとても簡単お手軽ですが、GUI開発とjavascript開発の境目は、開発経験があるエンジニアしかわからないです。GUI開発だけでは対応できないかどうか？について、結論として、やってみないとわかりません。
kintone開発途中参加の見積ポイント
自身のソースコード解読速度、導入されるAPIドキュメントの量と数、APIドキュメントの初学の速度やコスト、その他を考慮して以下をよく考えるといいかも。複数人数のチーム開発の場合、コンフリクトによって関係ない領域のソースコードやアプリの開発履歴を追う必要も出てくる可能性が高い、契約領域だけに対する見積では赤字になる可能性がある。発注側は理解できないかもしれないですが、不意打ちコンフリクトを考慮して全領域を把握するつもりで見積を出す。それを了承できないのは発注側のスキル不足でもある。業務に対する価値を理解するスキルに欠ける発注主から受注すると、受注側の首を絞める結果になり、良い事が無いので避けた方が無難かも。開発受託が減るのは自然の流れだと思う。
- javascriptソースコードの文字数
- javascriptソースコードの行数
- javascriptソースコードファイル数
- 有償プラグインはもらえるか
- node.jsを使っているかどうか
- functionの時系列タイプのベーシックなjavascriptの開発かどうか
- モジュール化されたオブジェクト指向開発か
- テーブル（アプリ）の数
- 1テーブルのフィールド項目数
- （外部）APIの数
- （外部）APIドキュメントのボリューム
- （外部）APIドキュメントの日本語化具合
- Qiita等参考文献の量
- 各テーブル（アプリ）のレコードボリューム
- 同プロジェクトの開発チーム人数、チームメイトの協調性
- 今までの開発履歴やソースコードの差分管理は出来ているか
- AWS LambdaやDataspiderなどの予算はあるか
kintoneは良いSaas製品だとは思いますが、javascript開発の視点では、使いにくい。IaasのLinuxなどに比べて開発の便利さが劣る。ジョイゾーさんの1週間20万円は、複雑な開発案件であれば妥当だと思う。
発注主に求められるレベル
javascriptカスタマイズで求められる人材レベルは、strictモードを含めて高くなりやすい。javascriptの中ででSQLクエリを出す経験を持つ日本人フロントエンドエンジニアはおそらく少ない。kintoneの複数アプリ横断javascript開発を自由度高く出来る人材の人数は限られると思う。kintoneのアプリ横断javascript開発の場合、PMの立場の人間が、node.jsやEcmaScript、npm（node package manager）、などを考慮して、人材予算計画できる技術レベルを持っていないと、何も知らずに受注するjsを書くコーダー側が泣きをみる可能性がある。発注側が技術価値を理解していないと、相応な価格への納得を得にくい。kintoneに対する世間一般的な「開発簡単！速い！」という見られ方と大きく矛盾しています。良クライアントを探すか、作るか、が開発継続と品質管理面で重要になってくる。javascriptのnode.jsのタスクランナーを使う開発環境を使えて、githubを使えて、モジュール化オブジェクト指向が出来る人材の対価を理解できる発注主かどうか？
簡単kintoneという世間イメージとjavascript開発の矛盾・・・。ジョイゾーさんのKintoneのjavascript開発1週間20万円の見積りは正しい。
kintone複数アプリ横断開発やクラウド連携のエンジニアを探す
kintone複数アプリやクラウド連携しながら開発する場合、エンジニアの探し方としては、DBやLinuxサーバーやネットワーク（クラウド）寄りなインフラエンジニアでもなく、jQueryやHTML5やCSS3を扱うフロントエンドエンジニアでもなく、HTTPメソッド、Rest API、非同期を理解できるエンジニアが求められます。gruntやgulpのビルド開発の経験者枠で人材を探すと、おそらく大手のWEBやスマホアプリの開発会社に提示金額で負ける。フロントエンドのLinuxバーチャルホストhttpd.confやniginx.confなどが苦手な人には難しい。経験者でない場合、どちらかと言えばインフラの人材がRest APIを即理解して使えるはずなので、その中からWEB系の企画ではなく開発のフルスタックエンジニアを目指したい人材を探す方がいいかも。phpフレームワークのsymfonyでHTTPメソッドとの距離が近い開発の経験者なども向いている。日本国内の位置としては、WEB系フルスタックの希少人材で関東では月40万円~月80万円と考えると時給2,500円～時給5,000円でも全く妥当。交通費等は別で、時給3,500円スタートくらいが妥当。1日8hで2万円~4万円くらいが目安。
クラウド連携など、サードパーティの他の外部サービスとの連携も行う場合、APIのドキュメントの数やリーディングボリュームも多くなるため、ドキュメント1文字につき30円など、ドキュメントリーディングの費用と時間をしっかり予測して見積に盛り込まないと赤字になる。APIの数が多くなるほど専門書リーディング必須量が増えるというイメージで見積をするべき。
cli-kintoneのインストールはGo（言語）のインストールが必要？
Go言語に加えて、Git か Mercurialもほぼ必要とのこと。開発用のホストOSマシンの中に余分な言語をインストールしたくないエンジニアって結構多いのではないかと思います。更新などのセキュリティ管理を煩雑にしたくない、ホストOSを汚したくない方々です。商談時、クライアントに対してリスク料金等の項目の説明がより難儀になるし、はっきり言ってマジ厄介。結論としては、Golangのインストール不要でした。ホストOSのWindows10にhttps://github.com/kintone/cli-kintone/releasesからダウンロードしてzipを展開するだけで使えました。C\Program Filesの中にCli-kintoneのフォルダを作ってダウンロードしてzipを展開するだけで、パスを汚さず同階層フォルダ内で使えます。アンインストールでごみが残ることも無さそうです。
下記のゲストOSとなるScotchboxでホストOSと共有されるpublicディレクトリでcli-kintoneを使えばOKです。
node.jsなどkintoneのjavascript開発環境
node.jsやGulpのjavascript向けにゲストOSを用意して、その中でjs開発をした方が賢明かと思います。Virtualbox/VagranrtのUbuntu環境のScotch Box ♥ A Vagrant LAMP/LEMP Stack for Beginners That Just Worksがローカルホストを汚さずに済みます。プロビジョニングも数分で速めでお勧め。vagrant upが終わったらhttp://192.168.33.10/で各種バージョン確認画面を見られれば仮想マシン起動成功です。ご参考に、Scotch BoxのUbuntu 14.04.5 LTS (Trusty Tahr)のルートディレクトリは/var/www/publicです。Windows10のHost OS上で作ったVMのフォルダ内のpublicがvagrant up後に共有ディレクトリとなっています。
Scotch Box（無料版）では、gccは入っていますが、treeコマンドが入っていないのでsudo apt-get install treeでtreeをインストール。npm,bower,Gulpは最初から入っている。npm -vとbower -vとgulp -vで全部バージョン出せます。さらにGulpのローカルインストール向けに、npm install gulp --save-dev。ちなみに–save-devは、package.json に登録するために使う。尚、node.js界隈はグローバルインストールか、ローカルインストールかという選択肢が付きまといます。サーバーサイドjavascriptをさらに超越した言語、みたいな解釈で問題無いかと思います。npm とか bower とか一体何なんだよ！Javascript 界隈の文脈を理解しようやGulp.js Build System #2 – Setupがおすすめです。
browserifyはnpm install -g --no-bin-links browserifyでいけます。-gでScotchboxゲストOSのグローバルに入れました。browserifyはnode.js製の便利ツールらしいです。ブラウザ向けのビルドなどが出来る。
Scotch Boxダメかも・・・
npm5.0.x系とUbuntuで結構海外でも上手くいかない人が多いみたい。gulpを走らせる前段階でダメ。ということで、ubuntu/trusty64を使ったcilindrox/node-vagrantでテスト中。開発環境構築、ぶっちゃけウザい。技術不足とはいえ、時間泥棒かつ、発注元クライアントの理解を得にくい工程・・・。受託やっちゃだめ。融資入れて、腰を据えて自社プロダクトを開発したほうがいい気が日に日に増していく。node.jsがことごとく失敗する問題は、windowsのPath長260文字制限とvagrantの仮想マシンとの共有フォルダのPath長でnode_modulesのPath長が長過ぎることが原因でした。そのため、フォルダ共有を辞めて、VNC利用をおススメします。
kintoneは「テーブル」の言葉の定義が普通じゃない
『MySQLのDBがあり、DBの中にテーブルがある』という概念ではない。1つのkintoneアプリで右上の「歯車マーク（アプリの設定を変更する）」⇒「フォーム」の画面でkintoneの1アプリを作る時、繰り返しフィールドにする項目をいくつか横一行に並べる、その繰り返しフィールドのひとかたまりの横1行が「テーブル」と名付けられていて、テーブルという言葉の定義がRDBMSとは全く異なる。極めて紛らわしい。複数名でkintone開発の打ち合わせをする時、テーブルという言葉の定義ズレする可能性がある。
発注クライアント（エンドのユーザー）、開発チーム全体でテーブルという言葉の定義を最初に確認して共通化しておかないと会話が合わない。繰り返しフィールドという命名ではダメなのだろうか。
kintoneのサブテーブルとは？
そのうち調べて、更新します。
kintoneの読み込み順序（JS/CSSファイルやプラグイン）
ディベロッパーツールでdownload.doで検索してみてください。
CSSはヘッドタグ<head>の中で読み込まれています。
javascriptはページ最後尾で読み込まれており、kitnone全体用のJS/CSSが先に読み込まれ、次にアプリ単体の読み込み。
どちらもdownload.doに対してパラメータが付与されていますが、ファイル名がハッシュされていて非常にわかりにくい。基本的にhashは不可逆です。JSやCSSのファイル名とハッシュ値の対応表を作る事を強くお勧めします。
kintoneの「アプリの設定」⇒「JavaScript / CSSでカスタマイズ」にて指定した順番に読み込まれているが、クロームのデイベロッパーツールのsourcesのツリー表示は、node.jsのrequireファイル順などに変化する。1アプリに対してファイルやプラグインが増えすぎるとデバッグ作業が超やりにくくなる。要注意。kintoneでは、基本的に、ブラウザデバッグだけでなく、ソースコード目視によるデバッグスキルも高いほうがいい。
パラメータ
app・・・アプリID
contentId・・・JSやCSSファイルをkintoneにアップした時に自動採番されている
jsType・・・DESKTOPなど、パソコンかスマホか識別
hash・・・ファイル名のハッシュ値
