紙のワークフローをDX化する際に行った 多階層データ処理の高速化について 株式会社カミナシ アプリケーションエンジニア 　　　 　　　　浦岡 祥平

サービス 現場改善プラットフォーム カミナシ 『カミナシ』は、現場のルーティンワークや事務作業を自動化 する現場管理アプリです。 手書き情報のデータから集計、報告など、これまで紙やエクセルで行ってい た作業をデジタル化し、 食品、小売、製造などのあらゆる現場のノンデスクワーカーの 働き方をスマートにしています。

1.製造現場のDXとは？ 2.製造現場を変えるための、カミナシのアプローチ 3. 外的/内的の制約 4.開発エピソード 　（帳票の記録部分で速度低下に対して、解決に至ったまでのストーリー ） まとめ 本日、話すこと

1.製造現場のDXとは

出典：経済産業省　「IT システム「2025 年の崖」の克服と DX の本格的な展開」 https://www.meti.go.jp/shingikai/mono_info_service/digital_transformation/pdf/20180907_03.pdf 　そもそもDXって何？

✨ ✨ ✨ 　では、「製造現場のDX」って何をイメージしますか？

まだまだ紙が主役 　製造現場のリアルはどうなってる？

　なぜ、自動化/高度化できない？ ・設備、人材への投資が必要 ・特に少量/多品種での製造では、自動化が難しい etc

2.カミナシのアプローチ

◯×チェック表 紙のチェックリスト（ワークフロー） カミナシでデジタル化 ノーコードで現場管理アプリを作ることができる 　業務フローをデジタル化する

条件分岐 繰り返し 多様なデータ型 　ノーコードだけど、痒い所に手が届く

繰り返し１ 繰り返し２ 繰り返し３ 親ノード 回答 YESの場合 Noの場合 木構造で表現 　内部のデータは木構造で定義している

３.外的/内的の制約

カミナシのユーザーは、「ノンデスクワーカー」と呼ばれます 対デスクワーカー向けのサービスとは違う制約がある ・現場では、iPadだけ見ている訳ではない ・時には移動しながら記録（入力）する ライン① 　製造現場における制約 ライン② ライン③ 少なくとも、紙に書いていた時の体験に負けてはいけない！！

サービスリリース後の 半年で、 DB定義変更（alter ~）を実施した回数 回 サービス開始後も頻繁なデータ構造の変更を行う必要があった →キャッシュ戦略は一旦、採用を見送り、 　愚直にRDB一本で勝負した 　スタートアップとしての制約

４.開発エピソード

（クライアント側） ②描画での性能低下 （サーバー側） ① RDBでの性能低下 RDB 　ぶち当たった課題 サーバー側、クライアント側のそれぞれで性能低下の課題あり

　①RDBでの性能低下 ・多階層かつロジカルな構造のデータをRDBで管理するために、関連テーブルが増大した ・関連テーブルが増大したことによって、アプリケーション⇄RDB間の通信回数が増えた ・アプリケーション⇄RDB間の通信速度がボトルネックのため、性能低下に直結した RDB 木構造JSON table ①階層構造（親子関係）を表現するためのテーブル ②データの型ごとにテーブル 　（例えば、数値型と日付型はテーブル定義が異なる） 　　etc...

　①RDBでの性能低下 ・多階層かつロジカルな構造のデータをRDBで管理するために、関連テーブルが増大した ・関連テーブルが増大したことによって、アプリケーション⇄RDB間の通信回数が増えた ・アプリケーション⇄RDB間の通信速度がボトルネックのため、性能低下に直結した gtx. Preload("Rel-A"). Preload("Rel-B"). Preload("Rel-C"). Find(s.ctx, &mainTable).Error; ORMを使ったコード select ~~~ select ~~~ select ~~~ 実クエリ ① ORMで使用して実装を行う場合、 　 ORM側で大量にクエリを発行してしまう ②再帰処理内でDBアクセス処理を書いてしまい、 　大量にクエリ発行していた

・多階層かつロジカルな構造のデータをRDBで管理するために、関連テーブルが増大した ・関連テーブルが増大したことによって、アプリケーション⇄RDB間の通信回数が増えた ・アプリケーション⇄RDB間の通信速度がボトルネックのため、性能低下に直結した 　①RDBでの性能低下 golangでのループ 処理のスピード 大量のDBクエリの 処理スピード 個々は数十ミリ秒のクエリーでも積み重なると。。

　①対応 「アプリケーション側での最適化」と「DB側で行えるチューニング」の両軸で対応した アプリケーション側 ①クエリ発行処理と再帰処理のようなアプリ側の処理を分離 ②ORMの使用 -> 生クエリ（テーブル結合を行うような）に変更した 　→ボトルネックとなるDBクエリの発行回数を抑えることができた DB側 ③テーブル結合で使用される外部キーに対する index付与 　　→クリエ単体の性能を改善

　①これからの課題 まだまだ小手先の対応しかできていない！ →ユーザー増加、機能拡張に耐えうる抜本的な改善が必要 機能拡張に伴い増える関連テーブル サービスの成長に伴い増えるユーザー数 課題

　②クライアント描画での性能低下 ・ロジカルなUIを実現するために、UIコンポーネントでの状態監視の範囲が大きくなる ・状態監視の範囲が大きくなることで、UIコンポーネントの再レンダリングの回数が増えた ・クライアントにとって、レンダリングコストがボトルネックのため、性能低下に直結した Reducer （状態） component1の回答 component1 component2 component2の回答 UI ・例えば、条件分岐を実現する上で、 　component2はcomponent1の回答によって、再描画を行わないといけない 　　 =>他コンポーネントの回答の状態を監視する必要がありました 👀 👀 はい いいえ 原因の記入

　②クライアント描画での性能低下 ・ロジカルなUIを実現するために、UIコンポーネントでの状態監視の範囲が大きくなる ・状態監視の範囲が大きくなることで、UIコンポーネントの再レンダリングの回数が増えた ・クライアントにとって、レンダリングコストがボトルネックのため、性能低下に直結した component1 component2 component3 Reducer （状態） ・・・ component 100個 component 3個 component1 component2 component100 Reducer （状態） ・・・ 再描画 再描画

　②クライアント描画での性能低下 ・ロジカルなUIを実現するために、UIコンポーネントでの状態監視の範囲が大きくなる ・状態監視の範囲が大きくなることで、UIコンポーネントの再レンダリングの回数が増えた ・クライアントにとって、レンダリングコストがボトルネックのため、性能低下に直結した JSでの内部処理 画面レンダリングの処理

　②対策 ①不要なレンダリング箇所の特定 why-did-you-render ②memo化でのレンダリングの抑止 参考： https://kaminashi-developer.hatenablog.jp/entry/2020/11/25/093000 何が起因で再 Rendering が 起こったのかを確認 const memoizedValue = useMemo(() => computeExpensiveValue(a, b), [a, b]); コンポーネントが再レンダリングされるプロパティを必要最低限 にする

　②これからの課題 ・開発スピード優先だったので、まだまだ壊れやすいアプリ 　→テストの強化含め、安定したアプリを提供したい ・と同時に、ユーザーの熱狂度合いを高めたい 課題

まとめ

・製造業のDXでは人が主役 ・カミナシは、ノーコードで作成できる現場管理アプリにより、 　現場のDXを加速させようとしている ・その実現にはサーバー、クライアントそれぞれで継続的な改善が必要 　まとめ

EM/アプリエンジニア/SRE 積極採用中