[フツパー 弓場氏]事業の進化とデータ構造で苦しんだ話 #データ負債解消

Connpass詳細はこちら

アーカイブはこちら

資料はこちら

本日は事業の進化とデータ構造で設計の反省の部分を紹介します。

我々フツパーは、「最新テクノロジーを確かな労働力に」をミッションに、 製造業向けにAIサービスの提供を行っている5期目のスタートアップ企業です。 本社を大阪の方に構えていまして、他にも関東と名古屋の3拠点体制で事業を進めています。

今は4つのプロダクトを出しています。今日メインで話そうと思っている外観検査の自動化AI「メキキバイト」と、振動データを取って異常検知を行うAIサービスの「振動大臣」、 そしてデータ分析AIサービスの「Hutzper-Insight」、工場内の人にフォーカスして人員配置の最適化を行う「スキルパズル」といったサービスがあります。

それぞれ製造業の人や工作機械、最終成果物に対してフォーカスしているサービスなんですが、その結果をクラウドサービスの方でまとめてあげて、その結果を分析して現場にフィードバックしていくところを事業として展開しています。

Offersエージェント」では、業界で活躍するプロフェッショナルがあなたの転職を徹底サポート。CxO経験者を含む現役エンジニア・デザイナー・プロダクトマネージャーが在籍し、職種に特化した専門的なアドバイスをご提供・非公開求人の紹介も可能です

【かんたん30秒】無料登録で転職相談する

製造現場を管理する「メキキバイト」のシステム

メキキバイトは工場内で動く部分のシステムとネットワーク上で動く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ヶ月単位で行いました。

――本日のイベントはこちらで終了とさせていただきます。 登壇者の皆さん、視聴者の皆さんありがとうございました。


Offersエージェント」では、業界で活躍するプロフェッショナルがあなたの転職を徹底サポート。CxO経験者を含む現役エンジニア・デザイナー・プロダクトマネージャーが在籍し、職種に特化した専門的なアドバイスをご提供・非公開求人の紹介も可能です


この記事をシェア

関連記事


副業・フリーランス

プログラミング

デザイン

インタビュー

お金

採用・組織

イベントレポート

転職