今回の記事では、プロダクト開発担当の山本に、フツパーの AIの運用を管理する専用アプリケーション「Hutzper Insight」の今後の展望や、フツパーならではの開発環境について、詳しく深堀していきます！

山本祐己/エンジニア

大阪府四條畷市出身。神戸大学卒業。大学在学中からNPO法人での活動やインドでの長期インターンシップを経験、その後スタートアップ複数社でリードエンジニアとしてWebサービス立ち上げを経て、フリーランスエンジニアとして独立し、AI開発案件に従事。2022年2月よりフツパーに参画。

以前、「Hutzper Insight」の特徴や開発環境について深堀りする対談を行った際は、フツパーで仕様書を書いて、外部委託先の鈴木さんが機能を実装していっていましたよね。

そうですね、Hutzper Insightの仕様については基本的に僕と鈴木さんとで進めていました。鈴木さんに仕様書のフォーマットを貰って、自分で考えて埋めて鈴木さんに見せて、鈴木さんからここをもっと詰めてくださいとか質問が来たりして、そういう感じでキャッチボールしながら進めていました。

前回の対談についてはこちらをご覧ください

対談記事を出してから半年が立ちましたが、現在はどのような状況なのでしょうか

当時は外注という形を取っていたので、フツパーでは仕様書だけ作って、実際に作るところは鈴木さんにお願いしていましたが、あれからかなり内製化が進みました。それに伴って自分たちでできることが増えて、Hutzper Insightの開発はもっと面白くなっていると感じています。やっぱり外注だと気軽にコミュニケーションをとるのが難しいので、細かい改善や、認識のすり合わせにどうしても時間がかかってしまうんですよね。

内製化ができてからは、仕様を決めてから作るまでを全部自分でやる分、スピードも上がったし、細かい改善もすぐ行えるのでサービスの質も高まってきていると感じています。

山本さんにとって面白いとはどういうことなのでしょうか

やっぱりエンジニア自らが課題を発見し、解決に取り組むことができる環境ですね。

具体的なところだと、Hutzper Insight上でAIを作れる機能をつけたり、それをリニューアルさせたりすることですね。

前回の対談で今後のHutzper Insightの展望として話していた部分ですね

そのとき話していた「物体検出」の機能は未実装ですが、「良品のみ学習」に加えて、「詳細分類」という分類よりもっと細かい違いを見分けられるアルゴリズムを導入したりしています。今は物体検出ともう一つ、当時は使っていなかった「セグメンテーション」のモデルを入れているところです。

どんどん改善が進んでいっているんですね！

そうですね。

プロダクト開発部は部長の山田さんと私の2人だけですが、個別のお客様の案件も担当しているので、案件が増えてきたことによってより現場のニーズが掴みやすくなっています。それもプロダクトをどんどん改善できるようになった要因の一つですね。

プロダクト開発でもありながら、案件もやっているんですね。

はい。さっき話した「良品のみ学習のモデル」は、まさに山田さんが担当している案件でも鍵となっている機能なんです。

食品系の案件なのですが、食品は期間限定の商品が多いのでAIで見る対象がどんどん変わっていってしまうのでその都度AIを作り直さないといけないんです。

AIを学習させるときは不良品を覚えさせることが多いのですが、不良品はふつう出ないようにしているので集めるのに時間がかかってしまって、期間限定商品を検品するAIを作るのには向いてないんですよね。

そこで「良品のみ学習」というものの必要性が出てくるんです。期間限定商品のAIを作るときは、テスト生産の時に良品をあつめて学習させて、本生産が始まる前にモデルをつくれるようになっています。

でも期間限定商品が出るたびにエンジニアがつくっていたら大変なので、AI作成ツールでお客さん自身でAIモデルが作れる機能になっています。

自分も案件を担当することで、お客さんにとって必要なモノをすごく高い解像度で理解できるというのは、いまの体制の良いところだと思います。

高い解像度とはどういうことでしょうか。

例えば使い勝手の良さとかですね。自分にとって使えるものであるだけでなくて、あのお客さんはこれ使えるだろうかとか、必要としているだろうかっていうのをリアルに想像できるようになったと思います。

あとは作るものの優先順位も決めやすくなったと思います。新たに実装したいものやリニューアルさせたいところはたくさんありますが、実際に必要としているお客さんがいると「まずはこの時までにこれを作ろう」という風に決めていけます。お客さんが定着するまでは、想像で「こういう機能が求められるんじゃないかな」と考えて作っていました。ですが今は実際に欲しいと言われたものや、一緒に案件を進める中で必要だと思ったものを実装しているので、優先度の解像度はどんどん上がっていると感じています。

自分が担当する案件以外のニーズはどのようにあがってくるのですか？

社内に、プロダクトへの要望シートっていうのを作っていて、現場から出た要望はそこにずっと蓄積されていきます。それを見ると似た要望がいくつも出てきたりするので、書き込んだ人に詳しく話を聞くという感じです。

開発の際、部署内でどのように役割分担を行っているのですか？

機能単位で1人の担当を決めていますね。アジャイル開発と呼ばれる、『計画→設計→実装→テスト』の素早い繰り返しを基本的に1人で進めていきます。

要望シートはその名の通り要望だけが書かれていますし、プロダクト開発を担当していないエンジニアや営業担当など誰でも書き込めるものなので、それを実際にどう解決していくのかはプロダクト開発側で考えていています。そして、そこから１つの要望ごとに１人の担当をつけて実装していきます。

担当をお願いするときは、このコード作ってとかではなく、この要望の担当よろしくみたいな感じで割り振っています。

最近はインターン生に対してもそういう割り振り方をしています。元々は、仕様書をこっちで作ってタスクを振って行こうと思っていたんですけど、それだとやる側は面白くないかなという話になりました。

インターン生も優秀なので、お客さんの生の声だけ見せて、これよろしくっていうお願いの仕方をしています。もちろん現場の情報や経験はインターン生はまだ少ないので、分からないことがあればその都度社員がフォローするというやり方で進めています。

フツパーのアジャイル開発について詳しく教えてください

他社の開発環境を詳しく知らないのですが、フツパーの環境について詳しく話すと、さっきも話したように１つの機能を１人で担当できるというのが特徴だと思います。

アジャイル開発の特徴として、『工程ごとの専任担当者を作らずに、すべての開発作業を全員が担当する』というものがありますが、通常は数人のチームで行うので、厳密には分担があると思うんです。でもフツパーは本当に全工程を自分が担当できます。要件定義も、デザインも、設計も、コードを書くのも全部ひとりのエンジニアなんです。

もちろん、チームのメンバーはそれぞれ得意分野があるので、そのスキルが活かされるように担当を決めたり、相談し合いながらチームとして開発を進めています。

本当に1人で機能の実装まで行うんですね！

そうですね。そこがやっぱり面白いところだと思います。元々仕様が決まっている状態だと、エンジニアはただそこに向けて作ることになりますが、フツパーではどんな課題があって、解決するためにどうすればいいかまで自分で考えられるんです。自分で課題を見つけて、解決策も自分で考えていけるっていうのが面白いです。

エンジニアって、解決策を考えることが好きな人が多いと思うんです。仕様を決められている場合はそれを作るための方法を考えるけど、それは解決策を考えるとはまた違うと思います。カチッと決められたものではなく、ふわっとしたところから自分で考えて固めていけるのが楽しいです。

そこがフツパーの開発環境の面白さなんですね！

AIエンジニアとプロダクト開発では進め方や環境が違ったりするのでしょうか？

お客さんの要望に応えるという点では同じですが、違う点としては、プロダクト開発はプロダクトに軸足があるので個別最適化しないというのが重要だと思います。そこが一番違うポイントですね。

個別のお客様の案件を担当するAIエンジニアは要望に対して最適化したものを提供できればいいので、外観検査のAIだと、対象物を撮るカメラの選定とか光の当て方とか技術的な課題のほうが多いと思います。一方でプロダクト開発の場合はその要望をどうやってプロダクトに取り入れて進化させていくかということを考えないといけないんです。プロダクトに対して要望はたくさん上がってくるんですけど、ある要望に個別最適化したせいで後々他の場所で足かせにならないように、他のお客さんにとっても価値になるような形に昇華して作っていかないといけないので、そこが非常に難しいポイントですね。

なるほど、どの会社に入れても問題なく使える、より良い機能と思うと難しそうです。個別最適化とぶつかることは多いですか？

そうですね、そことの闘いです。

そういう時はどうやって落としどころを見つけるのでしょうか？

自分でもひたすら考えますし、その要望が出た案件を担当しているエンジニアとプロダクト開発チームで話し合います。

似た要望を出している人にも話を聞いて、その時点で聞ける要望は全部吸い上げます。それを聞いてまるっと対応できるような汎用性を持った機能を作ります。

でも未来の要望は聞けないので、もし後でその機能からはみ出るものがでたら気合で修正することになりますが(笑)

最近、データベースに新たな項目を追加する必要が出てきたのでその修正を行ったのですが、その修正はかなり大規模なものだったので、実施するかかなり迷いました。

もとのデータベースは創業当初に作ったもので、その時点ではそれで十分と考えられていたのですが、実際に案件をこなしていく中で新しい項目を追加する必要性がどんどん高まってきたので、やっぱり思い切って変えたほうが良いという結論に至りました。

新しいデータベースを作って、そこにこれまで貯めた全部のデータを移行して、現場の機器から保存する先も全部切り替えて、全部移動させたんです。web側で表示させる内容も新しいデータベースの方からにしたので、これは結構気合がいる作業でした。

新しく機能を追加するより、今まで使ってきたものを変更する方が大変なんですね。

そうですね、本当に大変なのでできればやりたくないです。だから新しい機能を追加するときはその時点で分かっている要求はできる限り集めて、できるだけ未来の要求に答えられるような、最初に作った仕様でできるだけ長くやっていけるものを作りたいと思っています。

それでも、一年後くらいになってその機能だけでは破綻するということも起こります。そうなったらまた気合で修正していきます(笑)

他の会社のプロダクトだと、目指す姿とか世界観が先にあってトップダウン的に作っていくみたいなのもあると思うんです。その場合はその世界観に合わせてお客さんがつくので後々修正の必要が出ることは少ないけど、リリースするまではまったく利益が出ないまま数年かけて開発と準備をしていくみたいなやり方になると思います。

一方でフツパーは、全体像をあえて作っていないということもあって、理想のプロダクトに向かって機能を付け足していくというよりは、確実にニーズがあって使ってくれるお客さんがいるところから作っていくという感じなので、足りないところが後々でてくることはあるけど絶対に無駄な機能は生まれないですね。そこがフツパーならではの良さだとも思います。

新規事業担当の染谷さんに新サービスの振動大臣の開発秘話を聞いたときも、現場のニーズが第一とおっしゃっていました。

振動大臣の開発秘話についてはこちらをご覧ください

そうですね。フツパーの体質的なものだと思います。フツパーはエンジニアもビジネス志向が強いので実際にお金を払ってくれているお客さんが満足してくれるものがどうかにはシビアかなと思います。

エンジニアもビジネス志向でいられるのはどうしてなのでしょうか

上場を目指すっていう目標があったからっていうのはあると思います。会社全体の業績を振り返る機会も多いので、自分がどれくらい貢献できているかを頭に置いている人は多いかなと思います。

なので自分がつくっているプロダクトが売上に貢献できていなかったら焦りますね。

自分のプロダクトでどのくらいお金がもらえているか分かるんですか？

数字で見ている訳ではないですが、自分も案件を担当していてるし他の人の案件の状況も聞くので、作ったものが実際にどのくらい現場で使われているかはなんとなく把握しています。

あと、Hutzper Insightはお客さんだけじゃなくて社内でもAIを作ったりするときに使うツールなので、そこでも反応を見ています。

自分にとって良いと思うものができても、そこで満足して終わるんじゃなくて、実際使われているかまで自分で把握できるからこそ焦ることはありますね。

でもその逆に使ってもらえている場合もわかるのでそれは嬉しいです。

では次にSaaS開発についても聞かせてください

一般的にSaaS開発はtoC向けのサービスが多いなか、フツパーでは製造業向けのtoBのSaaS開発をしていますが、どのような特徴があるのでしょうか？

フツパーの場合はお客様が法人で製造業が多いので、どんな価値を提供をしたらどの程度予算をもらえるかとか、どの部分の予算をもらえるのかとかを具体的に計算しやすい分、ビジネス的な観点が強いというか、シビアかなと思います。

例えばメキキバイトは検品する人の人件費の代わりにAIを入れてもらえるように作っていますよね。

toCでも映画館行く代わりにNetflixを見たりするので似た考え方ではあるけど、toCに比べてtoBのほうがシンプルだと思います。toCの場合はそのお金を払ってくる人をすごくたくさん想定できるし、何にお金をつかうかも人それぞれですよね。だからペルソナみたいなのをじっくり考えたり、見た目のきれいさとか、使っていてテンションが上がるかとかの世界観を作りこんだりするんだと思います。

一方でtoBはすぐ見えるところに実際に使ってくれる人がいるので、その人や会社に向けて合理的に進めていける面白さがあります。

面白さとかおしゃれさとかの情緒的な観点は二の次で、その機能がいかに便利で使いやすいか、役立つかという、ツールとして有用かどうかみたいな観点が一番大事になってくると思います。

実際にその機能を使う相手が見えているというのはHutzper Insightならではかもしれないですね

そうですね。あとは、自分が作り手でもありユーザーでもあるっていうのは面白いポイントかもしれないです。社内のエンジニアも使うし自分も使うからこそ、想像で使いやすいものを作るんじゃなくて、自分にとっての使いやすさを追求したらお客さんにとってももちろん使いやすいものになります。

一般的なプロダクト作りは、自分にとっての使いやすさでつくるんじゃなくて、ユーザーにとっての使いやすさを追求しろとか、ユーザーの声を聞けっていう声が強いのですが、そもそも自分がユーザーでもあるので使いやすさの理解度も深まっている気がします。

普通は、新機能を作るときにはモックアップをつくったりユーザー検証をじっくり行うんですけど、フツパーの場合は社内に製造業や生産管理の経験者が多いからリアルな声が直接聞けるし、自分たちがユーザーでもあるからそこの時間をかなり短縮できるのは強みかなと思います。

あとは新しい機能を作ったときに、自分が最初にユーザーとして使ってみることができるので、社員やお客さんに運用してもらう前に使い方のコツとか改善点を見つけられますし、社内で自分以外の人にもテストしてもらうことで、すぐに使いづらいところや新機能の評判が分かるのは良いところだと思います。

今後Hutzper Insightはどういう方向に進んでいくんでしょうか

大まかな方向性としては、検品だけに特化していくのではなく、検品の前後の工程や生産管理・品質管理の方向にも機能を広げていきたいですね。

収集するデータを工場全体に広げて蓄積していって、例えば機械の不調をいち早く察知したり、不良品が出た時はその要因まで分かるようなデータを貯めていけるものを作りたいです。

あと、検品の部分でも改善したい箇所はまだたくさんあります。

今までは現場にAIを導入して運用するための機能を揃えていたのですが、ようやく各機能がスムーズに連動するようになってきたので、ここからは一個一個の精度を高めていく作業に入っていくという感じですね。

例えば、使えるモデルの種類を増やすとか、解像度の高い画像でもサクサクつかえるようにしたりとかということを、どんどん実施していきたいです。

今後が楽しみですね！

一日のスケジュールについて教えてください

私の場合、お客様のいる工場に行くこともありますが、基本的にはオフィスにいることが多く、主にHutzper Insightの開発を行っています。

9:00 出社

9:30 エンジニア定例

10:00 担当案件の開発

12:00 昼食

13:00 Hutzper Insightの開発

18:00 新規案件の相談など

20:00 退社