アプリ構成のアイデア募集
現在使用中アプリの当初の利用目的から、要素がどんどん増えてしまって、あれもこれも入ったアプリになってしまいました。
漠然と「このままではマズイのでは」と不安になっており、アプリを再構築すべきではと考えています。
皆様ならどんなアプリに再構築するか、アイデアをいただきたいです。
弊社は小さな製造業です。製造そのものは海外の自社工場で行われています。
kintoneは海外自社工場でも使っていますが、アプリ構築はほとんど日本です。
私の自己紹介はこちら
利用コース:スタンダード
導入済プラグイン:ATTAZoo+、レポトンExcel(買い切り)、TiSさんなどの無料プラグイン
カスタマイズ補足:JavaScriptは不可
有料サービス(プラグイン、連携サービス、伴奏支援)導入はかなりハードル高いです(これまでも、濁されてうやむやになりました…)
○問題となっているアプリの当初の目的(アプリBとします)
製品を作るために必要な図面(画像)や、製造工程がかかれた複数の資料(Excel)を、完成品レコードごとにファイル添付して、ちゃんと図面や資料があるかの確認をしてました。
○その後のアプリBの状況
1つの製品を作るのにどんな材料が必要?社内ではどんな工程がある?外注に出す工程は?
これらが添付ファイルのExcel内にしか情報がなかったので、
アプリB内にテーブルを3つ設置し、材料、社内工程、外注工程をテーブルに入力するようになりました。
○アプリBから別アプリへ連携が増えた
日本から海外自社工場へ「完成品商品コード○○を△△個製造してほしい」と指示を出します。
海外自社工場は、完成品商品コードから使用材料や製造工程内容を特定し、製造予定を立てます。
以前はExcelや紙、長年の経験で行っていましたが、kintoneアプリ化しました。
現在のアプリ構成はこちら↓
アプリA:マスタアプリ。完成品、材料、製造工程など「商品コード」のマスタが全て入っています。他アプリへのルックアップは、基本このアプリの「商品コード」で紐付けてます。
アプリB:前述の通り、図面・資料の管理だけでなく、完成品を作るのに必要な情報がテーブルに入り、マスタっぽくなってきました。
アプリC:日本から海外自社工場へ指示した完成品商品コードと製造数に対し、どの材料・工程がどれだけ必要か換算するアプリです。
アプリCに、TiS ルックアップ内サブテーブルコピープラグインを設定して、アプリBにある材料や工程テーブル情報を丸ごと転記しています。
製造に必要な数は、計算フィールドで計算しています。
アプリCから先も、予定データを入れるアプリや、製造実績や検査結果を入れるアプリに繋がっていきます。
○私の考え
アプリBに、図面・資料管理と、マスタっぽくなっている必要材料・工程情報を一緒にしておくのは、アプリ構成が綺麗じゃないと思っています。
分けるべきでしょう。
マスタっぽい情報は別アプリにしたとして、
1レコードの情報を、アプリBのテーブル構成のままにするのは本当に良いのか?悩んでいます。
アプリBのテーブル構成と同じメリットは、アプリ名が変わるだけで根本の設定は既存とほぼ同じ点です。
デメリットは、無料プラグインなので性能的に注意点があったり、将来的に使えなくなってしまったら?があります。
1レコードに、1完成品商品コード、1材料商品コードor1工程商品コード の方が、テーブルを使わずにすむ(TiS ルックアップ内サブテーブルコピープラグインを使わない)けれど、
アプリCにどうやってデータを持ってくる?問題が出てきます。
krewDataなどを使えばできるのでしょうか…?
長文になってしまい申し訳ありません。
本当なら伴奏支援企業様に依頼すべき内容かもしれません。
しかし、前述の通り、現状では依頼ができない状況でして……
小さな情報でも、いやこれは有料サービス使うべきだよ!でも、どんなことでも大丈夫ですので、皆様からのアイデアをいただきたいです。
どうぞよろしくお願いいたします。
ミュートしたユーザーの投稿です。
投稿を表示こんにちは。
と書かれている通り、私もわけた方が良いかと考えますが、
現在のアプリBとアプリAの切り分け方をもう少し詳しく教えてもらえませんか?
現在の構成
アプリA:マスタアプリ。完成品、材料、製造工程など「商品コード」のマスタ
アプリB:製品技術資料、材料構成(BOM)明細、工程構成(BOP)明細
疑問
完成品、材料、製造工程などはすべて「商品コード」を持たせており、
アプリBのそれぞれのテーブルからアプリAの商品コードをルックアップしている?
ミュートしたユーザーの投稿です。
投稿を表示理想を言えば商品マスター的なアプリを中心に「商品コード」のような核になるフィールドで関連付けて周りにアプリを作りたいところですが、kintoneはリレーショナルデータベースではないのでアプリの数が増えると操作が面倒になることが多いです。
ちょっと別の話になりますが、各アプリにあるテーブルのデータ量はどのくらいでしょうか。
テーブルには
「1つのテーブルにつき、10フィールドかつ100行までを目安としたご利用をおすすめします。
テーブルのフィールド数や行数が多くなると、画面の表示速度が遅くなり、レコード操作やカスタマイズに影響を与えることがあります。
また、登録されているデータ量が多くなるため、検索結果を表示するまでの処理時間にも影響を与えることがあります。」
という推奨値があります。
テーブルのフィールド数・行数が多過ぎる場合は、テーブル部分を別アプリにして関連レコードで紐づけることを検討した方がいいかもしれません。ただし、別アプリにするとテーブルのように同じ画面で編集できなくなって困るかもしれません。
kintone ヘルプシステム管理制限値制限値一覧
https://jp.kintone.help/k/ja/id/04044#limitation_limit_2070
ミュートしたユーザーの投稿です。
投稿を表示作成者の設計思想による部分が大きいと思います。
もし SQL データベースのような構造を求めるのであれば、分散化していく方が適しているのではないでしょうか。
ただ、kintone の標準機能には一括更新クエリが存在しないため、安易に分散させると逆に運用が煩雑になる可能性もあります。
そのため、現状の構成が最もバランスが取れているように感じます。
とはいえ、レコード件数が数万件を超える場合など、特定の条件下では再検討した方が良いケースもあると思います。