みんなの投稿

アプリ構成のアイデア募集

現在使用中アプリの当初の利用目的から、要素がどんどん増えてしまって、あれもこれも入ったアプリになってしまいました。

漠然と「このままではマズイのでは」と不安になっており、アプリを再構築すべきではと考えています。

皆様ならどんなアプリに再構築するか、アイデアをいただきたいです。





弊社は小さな製造業です。製造そのものは海外の自社工場で行われています。

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などを使えばできるのでしょうか…?



長文になってしまい申し訳ありません。

本当なら伴奏支援企業様に依頼すべき内容かもしれません。

しかし、前述の通り、現状では依頼ができない状況でして……

小さな情報でも、いやこれは有料サービス使うべきだよ!でも、どんなことでも大丈夫ですので、皆様からのアイデアをいただきたいです。

どうぞよろしくお願いいたします。

3件のコメント (新着順)

こんにちは。

アプリBに、図面・資料管理と、マスタっぽくなっている必要材料・工程情報を
一緒にしておくのは、アプリ構成が綺麗じゃないと思っています。

と書かれている通り、私もわけた方が良いかと考えますが、
現在のアプリBとアプリAの切り分け方をもう少し詳しく教えてもらえませんか?



現在の構成
アプリA:マスタアプリ。完成品、材料、製造工程など「商品コード」のマスタ
アプリB:製品技術資料、材料構成(BOM)明細、工程構成(BOP)明細

疑問
完成品、材料、製造工程などはすべて「商品コード」を持たせており、
アプリBのそれぞれのテーブルからアプリAの商品コードをルックアップしている?


コメントありがとうございます!
まさにご記載いただいた通りです。
例題をあげますと、

完成品商品情報
商品コード:0001
商品名:完成品①

材料情報
商品コード:1000
商品名:鉄板

工程情報
商品コード:1111
商品名:切断

上記のような情報は全てアプリAの「商品コード」「商品名」に1レコードごと登録されています。
アプリBのテーブルにはルックアップフィールドがあり、アプリAから「商品コード」でルックアップしています。

返答ありがとうございます。

ということは、アプリBで管理されているレコードも、アプリAで
完成品商品情報として所持しているという事ですね。

アプリの分割案として、製品技術資料を随時参照する必要が無ければ
アプリB内の製品技術資料を別アプリにしてみてはどうでしょうか。
関連レコード表示やリンク等での参照で良いかと考えます。

ちなみにアプリコード機能は使い方によっては非常に刺さります。
ご参考までに。
https://jp.kintone.help/k/ja/app/manage/appcode



以降の設計ですが、材料構成(BOM)明細、工程構成(BOP)明細の
分離でしょうが、変更にはなかなかの工数がかかる想定です。
いま使える手段で考えると複数レコードサブテーブル化プラグインを使って
いい感じでレコードデータを集めてくる、ということになるかとは思いますが。

ですので、現在の運用・管理に問題が無ければ、いったん資料のみ分離したうえで
様子見、経験値をためたうえでリプレイスでも良いのかな、と考えます。

以上です。

おっしゃる通りです。
アプリBのテーブル外にあるルックアップフィールドもアプリAと紐付いて、完成品商品コードをルックアップしています。
アプリBには完成品商品数分のレコードがある形ですね。
資料を別アプリにする案、ありがとうございます!
アプリコード機能は実際に使ったことがないので、参考にさせていただきます。

複数レコードサブテーブル化プラグインは利用したことがないプラグインでした。
これなら、1レコードに、1完成品商品コード、1材料商品コードor1工程商品コードで登録されていても、アプリC側でテーブルにまとめて表記できそうです。
ただ、sujiさんのおっしゃる通り、アプリ変更は一筋縄ではいかなそうです。
前述の資料別アプリ化と合わせて検討させていただきます。
ありがとうございます!

理想を言えば商品マスター的なアプリを中心に「商品コード」のような核になるフィールドで関連付けて周りにアプリを作りたいところですが、kintoneはリレーショナルデータベースではないのでアプリの数が増えると操作が面倒になることが多いです。

ちょっと別の話になりますが、各アプリにあるテーブルのデータ量はどのくらいでしょうか。

テーブルには
「1つのテーブルにつき、10フィールドかつ100行までを目安としたご利用をおすすめします。
テーブルのフィールド数や行数が多くなると、画面の表示速度が遅くなり、レコード操作やカスタマイズに影響を与えることがあります。
また、登録されているデータ量が多くなるため、検索結果を表示するまでの処理時間にも影響を与えることがあります。」
という推奨値があります。

テーブルのフィールド数・行数が多過ぎる場合は、テーブル部分を別アプリにして関連レコードで紐づけることを検討した方がいいかもしれません。ただし、別アプリにするとテーブルのように同じ画面で編集できなくなって困るかもしれません。

kintone ヘルプシステム管理制限値制限値一覧
https://jp.kintone.help/k/ja/id/04044#limitation_limit_2070


コメントありがとうございます!
テーブルについて、質問ありがとうございます。
アプリB内にあるテーブル数:本文記載の3個と、別で2個
テーブルフィールド数:約5~10個
テーブル行数:完成品によって変わり、1テーブルに5行程度から数十行まで様々です。100行はいかないと思っています。

別アプリにして、1レコードに
1完成品商品コードと、1材料商品コードor1工程商品コード
を登録すれば、関連レコード一覧でアプリBに表示できますよね!
kintone的に理想で私もこの方法いいなと思っていますが
「一画面で編集できない」は現場から言われそうです……

マスタっぽい情報は別アプリにしたとして、
1レコードの情報を、アプリBのテーブル構成のままにするのは本当に良いのか?悩んでいます。

作成者の設計思想による部分が大きいと思います。
もし SQL データベースのような構造を求めるのであれば、分散化していく方が適しているのではないでしょうか。

ただ、kintone の標準機能には一括更新クエリが存在しないため、安易に分散させると逆に運用が煩雑になる可能性もあります。
そのため、現状の構成が最もバランスが取れているように感じます。

とはいえ、レコード件数が数万件を超える場合など、特定の条件下では再検討した方が良いケースもあると思います。


コメントありがとうございます!
現状の構成に対しバランスがとれている、とおっしゃっていただき、
過去にアプリ設定したときのやり方も間違いではなかった、と安堵しています。
現在のアプリBのレコード件数は、ざっくりと数百件くらいです。良く製造している製品数とほぼ同数で、時々増える形です。
レコード件数の目線で見たら、今の運用方法でアプリだけ分割する案もありですね。