こんにちは、インダストリー事業部事業部長兼CPO（チーフプロダクトオフィサー）改め2023年4月から取締役兼インダストリー事業部長となりました大西 理王（おおにし りおう）です。事業部長ではありますが、過去にはこちらのようにFusion360を使って電気回路の基板を作って、筐体と一緒に設計をしたりした経験をもっており、過去には組み込み系を中心にソフトウェアやFPGAの開発をしていたこともある元エンジニアです。詳しい経歴はこちらをご覧いただければと思います。HACARUSのSpotifyのポッドキャストでも私のことを紹介しているので興味がある方はお聞きください。

HACARUS Checkの紹介

AI外観検査システム『HACARUS Check』はインダストリー事業部のメインの商品になります。詳しく分けるとHACARUS CheckとHACARUS Check AIソフトウェアという二つの製品があります。HACARUS Check はDENSO Wave様のホームページで紹介されているこちらの動画をご覧いただくと一番わかりやすいと思いますが、カメラ付きロボットアームでワークの全面を撮像し、AIモデルで外観検査をするという装置です。　　　

HACARUS Check AIソフトウェアは、撮像ハードウェアはご自身で準備されるもしくはこれから独自の装置を開発されるというお客様向けのソフトウェアであり、3つのAIアルゴリズムを搭載しています。

いずれもC#、C++、Pythonで開発されています。

HACARUS Checkの実運用に至るまでの過程

HACARUS Checkの開発には、約3か月のMVP作成期間がありました。2021年11月から1月末までの期間に、MVPが作成されました。わずか3か月で垂直立ち上げした話はこちらのポッドキャストでも取り上げていますし、より詳しく知りたい方はこちらに以前発表した内容をスライドにまとめておりますのでその詳細を知ることができます。その後、こちらのサイトの公開と同時に2022年3月に製品がリリースされました。そして、その直後の2022年3月末には最初の顧客から受注がありました。しかし、電子部品の入荷遅れにより、2022年9月末に予定していたハードウェアが入荷しました。2022年10月からは受注先工場にまずは製品を1台設置し、現地PoCを開始し、2022年12月には追加の2台が納品されました。そして、2023年1月より運用を開始しました。HACARUS Checkの導入に関する動画もこちらにて公開しておりますので興味のある方はご参照ください。

スライド1枚の営業資料からスタートした製品開発

HACARUS Checkの開発は、基本的にはエリック・リース氏の著作『リーン・スタートアップ』の考え方に基づいて開発を進めました。まずはスライド1枚の営業資料を作成して、それを顧客に見せて反応を伺います。製品コンセプトはどうか、価格はどうか、なにより顧客の課題が解決できそうか、顧客の課題は同じものが横展開できそうか、そういったものを確認していきます。それである程度、こういうったコンセプトの製品であれば共通の顧客の課題解決ができて、かつある程度のビジネスにもなりそうだということになれば、ようやくそこで開発に着手します。最低限の機能を実現するMVP（Minimum Virable Product）を作成し、展示会等や直接顧客に提示することで得られたフィードバックに基づき次の仕様を検討し、実装、適用します。適用してみて実際に出てきた問題点に対して、課題解決に至るまで仕様検討、実装、適用を繰り返すという形で開発を進めていきました。振り返ってみるとだいたい3か月ごとに大きな開発を繰り返してきました。2022年3月のリリース以降も継続して開発は行っていたので、リリースまでの3月までの開発、展示会があった2022年4，5月を経て2022年6月までの開発、そして2022年7－9月の開発、2022年10月にも展示会に出展して、現地PoCが始まって2022年12月の納品が終わるまでの開発と大きく分けるとそのような単位でスコープを決めて開発を行っていきました。最もしんどかったのは12月の納品が終わるまでの開発で、メンバーと一緒にどうすれば予定通りの2022年12月中の納品完了ができるのかと知恵を絞りながら全員野球で開発に取り組みました。MVP以降の開発の具体的な進め方については前回の記事でもお伝えした通りSCRUMがベースとなった開発手法で進めていきました。

“確実にお客さまに喜んでいただける”HACARUS Checkの開発の進め方

正直にいうとこの開発の進め方は開発者にとってはやりにくい部分もあるのではないかと思っています。しかし、考えてもみてください。世の中にはせっかく開発した機能の中でいかに使われていないものが多いことか。それに対して上記のような開発の進め方は、開発者にとっては、お客様からの直接のフィードバックで、ある程度期限を決められた形で実装をせざるを得なくて好きに仕様を考えたり、自分の趣味趣向で実装の方針を決められるわけでもありません。しかし、そうやって実装された機能は確実にお客様のもとに届き、しかもお客様の役に立ちます。課題解決に向けて最短ルートを通っているわけで、スタートアップとしては望ましい開発の進め方だと思います。開発者にとっても直接目に見えているお客様に機能を提供することになるので、やらないといけないことが明確でモチベーション高く開発が進められていると思います。そして実際にお客様から反応を得られるという意味でも非常にやりがいのある開発の進め方だともいえると思います。

最後に

HACARUS Checkの開発の進め方について紹介させていただきました。
スタートアップらしいといえばスタートアップらしい開発の進め方ではないかと思います。私も元々は大企業やもう少し体裁の整った形での開発をしてきた経歴の方が長いので、これは本当にスタートアップらしい開発の進め方だなと思います。もちろん今後製品がもっと成熟してくれば、開発の仕方も変わってくるかとは思いますが、なにより顧客に価値を届けられるかどうかがはっきりと分かっていないスタートアップだからこそ取れる開発の進め方であると思っています。
このようにダイナミックに変化する環境の中で、お客様にダイレクトに届く開発をしてみたいという方がいらっしゃいましたら、是非、応募していただければと思います。