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

山本祐己/エンジニア

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

現在の「Hutzper Insight」の開発状況について

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

そうですね。Hutzper Insightの仕様については、基本的に僕と鈴木さんとで進めていました。

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

前回の対談についてはこちら

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

あれからかなり内製化が進みました。それに伴って自分たちでできることが増えて、Hutzper Insightの開発はもっと面白くなっていると感じています。

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

山本さんにとって「面白い」とはどういうことですか？

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

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

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

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

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

そうですね。

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

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

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

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

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

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

だからといって、期間限定商品が出るたびにエンジニアがAIモデルを１から作っていたら時間も費用もかかってしまうので、AI作成ツールでお客さん自身でAIモデルが作れる機能を追加したんです。

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

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

例えば、使い勝手の良さとかですね。

自分にとって、つまり開発しているエンジニアの感覚で使えるものであるだけでは十分でなくて、あの現場でははこれを使えるだろうかとか、お客様は本当にこれを必要としているだろうかっていうのを、リアルに想像できるようになったと思います。

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

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

社内に、プロダクトへの要望シートっていうのを作っていて、現場から出た要望はそこにずっと蓄積されていきます。

そこで似た要望がいくつも出てきたりすると、書き込んだ人に詳しく話を聞いて改修の優先度を検討していくという感じです。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

社内の他のエンジニアとは進め方や環境が違ったりするのでしょうか？

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

個別のお客様の案件を担当する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 退社