製造現場を管理する「メキキバイト」のシステム
メキキバイトは工場内で動く部分のシステムとネットワーク上で動くAWSで構築しているクラウドのシステムがあります。
製造現場で受入や加工・プロセス、出荷においてメキキバイトで検査を行い、検査結果の画像データや検査結果の数値をインターネット上の管理アプリケーション「Hutzper-Insight」に送って結果を分析していく形になります。
画像データに関しては、 AIをノーコードで開発できるシステムがあるのでそちらでAIモデルを作成して、現場のデバイスにデプロイする関係のシステムになっています。
「メキキバイト」を支えるHutzper-Insightのデータベース選定の経緯
創業当初のHutzper-Insightの設計思想としては、AIに重きを置いていた部分がありました。
従来の画像処理検査機で検査が難しいものに対してエッジAIは判断できます。しかし、創業した2020年の場合だと、エッジAIは未熟な部分があって、クラウドベースでAI推論をさせた結果を工場に返す形が多かったです。
製造業の検査領域をエッジAIで解決するために、データベースの設計で重要視したポイントは大きく3つあります。
1つ目はスケールのしやすさです。 基本的にデバイスごとに結果を送る段階でデバイスが増えていくと、今後のスケールの部分を考えて設計しなきゃいけないと考えていました。 2つ目は、検査スピードに対応できる読み書きに対するレスポンスの速さです。3つ目はコストの部分です。
以上の点を満たすものを考えて、最初はAmazon DynamoDBで構築しました。
データベース周りの構成項目については、工場内のデバイスからそれぞれのテキストデータがMQTT通信でIoT Coreに入ってDBへ入る形です。画像データに関してはそのままS3に入れてあげて、 そこからAIモデルをうまく作ってもらう構成でサービスを進めました。
定量的品質評価を行う機能開発の検討
ありがたいことに、外観検査で今まで見れなかったものがしっかり見れるところに価値を感じていただいて、 数多くのお客さんに導入いただいています。
市場に受け入れられるのは非常に嬉しいですが、 その上でどんどんプロダクトを改善してさらなる価値をお客さんに届けてもっと喜んでもらおうと思っています。
そんな時にお客さんの要望や我々が現地に行って感じたことから、検査結果を活用した定量的な品質の評価機能の開発を進めていく話になりました。
想像がつきにくいと思うので、暑さと熱中症の関係のデータを例に説明します。左側の表は日付・真夏日か否か・熱中症の緊急搬送が発生したか否かがYESまたはNOで埋まっています。こちらを結果のグラフにすると右側の形になります。真夏日の方が熱中症が発生していそうとしか分かりません。
そこで定量データを取得するようにします。日付はそのままで、気温と熱中症での緊急搬送数に置き換えました。 グラフにすると、30度を超えると熱中症の発生率が高そうというのが見えてくると思います。このように具体的な数値が原因として分かるので、品質の改善ができるようになります。
外観検査は目視でやっている場合が多くて、検査員が目で見てOK・NGという定性的な判断が検査の結果として使われています。その判断にAIを用いると検査結果のスコアを数値として出せるので、数値データで暑さと熱中症の例のように具体的な品質の改善策が打てるようになることを期待して開発しようとしました。
Amazon DynamoDBの問題とTimestreamへの移行
この時に1個問題が出てきまして、 DynamoDBは検索性が良くなかったんです。
当時のHutzper-Insightは日毎にバッチ処理を行って検査結果を画面に表示していたので、先ほどのOKやNGといった判断に関する任意の列の絞り込みが難しい状態でした。
ただ、2022年の夏ぐらいにAWSの方からTimestreamという時系列のデータベースが東京リージョンで使用可能になりました。DynamoDBで創業初期からあった設定のメリットに加えて、検索の柔軟性が使えるようになったので、Timestreamへの移行を行いました。
結果的には先ほど言った品質管理の機能を以下のように実装できました。
現在もTimestreamを使っているのですが、テストがしにくくてローカル環境を作れなかったり、テーブル構造が今までのDBとは違って特殊でSQLクエリを書きづらかったり、テーブル構造の変更が結構大変だったりします。
そのため、求めていた機能の実装ができる状態を作れたことはラッキーでしたが、それで満足はしたくありません。
反省点としては、IoTのデバイスを使ったサービスをネットで調べると基本的にはIoTコアとDynamoDBを使うというのがユースケースとして書かれていたので、それを信じて反射的に選んでしまったことがまずあります。
リレーショナルデータベースでできるかと言われたら、スケールの量にもよりますができると思います。現在はリレーショナルデータベースの方でもオートスケールに対応しているものもあって、こちらの方が書き慣れてるメンバーもいたりしたので、そういった部分を最初にもう少し検討しても良かったなと思っています。
ただ、Timestreamが最初から使えたわけではなかったんですが、設計の深堀りはこれからしっかりやっていく必要があると感じました。
視聴者からの質問に答える質疑応答タイムへ
――ここからは、視聴者の方からの質問に回答していきます。まず1つ目は、「データ構造の負債を解消するために専用のメンバーを配置しているのでしょうか、それとも開発メンバーが機能アップデートと並行して進めているのでしょうか」という質問です。陳さんからご共有いただけますか。
陳：我々は全て同じメンバーがやっています。なぜなら、ここを分けると背景がわからないメンバーも入ってきてしまうからですね。 基本的に解消する際は短期間で皆で一緒にやり切るという形で進めています。
――続いてtocknさん、お願いします。
tockn：弊社も同じで、特に負債解消の専門チームは置いていません。プロダクトを開発するメンバーが解消しています。クォーターの最初の2週間は非機能系の改善に当てるといった改善ウィークも設けたりして、色んな方法でプロダクト開発と共に並行できる施策を練っている感じですね。
――続いて大島さん、お願いします。
大島：Nayose Groupは歴史が長く大きいチームになっていて、その結果システムとしても大きくなってしまいました。そのため、チームを分割してより改善しやすくなる構造にしています。
――続いて森山さん、お願いします。
森山：弊社も機能アップデートと並行してやっていますね。 開発を進めるか、負債を解消するかを天秤にかけていて、場合によっては負債の解消を優先しています。
――最後に弓場さんはお願いします。
弓場：フツパーもチームを分けてはいなくて、開発メンバーが担う体制で今はやっています。
――続けて、「どれぐらいの時間をかけて負債を解消してきましたか」とのことですが、陳さんからお願いできますか？
陳：基本的には2〜3週間でやりきることを徹底しています。 何か行動的に問題が発覚した場合は一旦開発を止めて2〜3週間で全部やりきって、無理にその先に進まないという判断をしてきました。 短期間で細かく、問題があるところだけ集中的にアタックする形ですね。
――続いてtocknさん、お願いします。
tockn：先ほどの回答と被りますが、改善ウィークみたいな形で1週間〜2週間を改善の期間に当てていますね。あとは、クォーター単位でプロダクトや非機能系の開発も含めて何をやるのかを整理する段階で期間を当てはめたりしています。
――続いて大島さん、お願いします。
大島：細かいところは2週間くらいの短期間でやって、 どうしても歴史的経緯で大規模改修が必要なタイミングであれば半年〜1年ぐらいかけて、現在動いているものをリプレイスする形です。
――続いて森山さん、お願いします。
森山：大体メンバーは複数人いるので、一人が負債回収して、もう一人は機能開発という感じでやっていましたね。負債回収をやると大体1ヶ月ぐらいかかります。それぐらいで今回の課題などは対応していました。
――続いて弓場さん、お願いします。
弓場：今回発表したデータベースの移行に関してはいきなり全部を変えるのではなくて、ステップを区切って1ヶ月単位で行いました。
――本日のイベントはこちらで終了とさせていただきます。 登壇者の皆さん、視聴者の皆さんありがとうございました。
