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

HACARUSの製品

現在インダストリー事業部では大きな柱として2本の製品があります。HACARUS CheckとHACARUS Check AIソフトウェアです。HACARUS Check はDENSO Wave様のホームページで紹介されているこちらの動画をご覧いただくと一番わかりやすいと思いますが、カメラ付きロボットアームでワークの全面を撮像し、AIモデルで外観検査をするという装置です。通常AI外観検査システムを導入しようと思うと、撮像ハードウェア、ハードウェアの制御、システムを制御するソフトウェア、そしてAIとの連携と非常に多岐に渡る技術・知識が必要で、それをユーザーがまとめるのは至難の技です。AIベンダもAIのソフトウェアを提供するだけでその装置を制作するメーカーがすべてのことを理解して最適な装置を作れるかというとそれはそれで困難です。そこでHACARUSではそういったお悩みに対応するため、すべてをオールインワンパッケージとしてまとめあげ、お客様は検査したいワークさえ提供すれば、あとは使うだけというAI外観検査システム HACARUS Checkを開発し販売しています。既に2022年12月末に実際に複数の企業様に導入いただき、日々HACARUS Checkを使って検査をしていただいています。

とはいえ、お客様の方で既に外観検査装置をお持ちであったり、撮像設備は自分たちで手がけたいというお客様ももちろんいらっしゃいます。HACARUS Check AIソフトウェアはそういったお客様向けのソフトウェアで、3つのAIアルゴリズムを搭載しており、お客様のニーズにあったAIを選択していただいて使用いただくソフトウェアとなっています。

いずれもC#、C++、Pythonで開発をされており、先行して開発したHACARUS Checkの資産を活かしながら新しくAIソフトウェアの開発が行われたため、内部構造としてはAIソフトウェアの方が新しく、ソフトウェア単体ということもあって、テストのカバレッジもAIソフトウェアの方が高くなっています。HACARUS Checkの方はハードウェアが絡んでいることもあり、速度を優先するとテストには向かないコードになりがちであるということも関係していると思います。

SCRUM開発

インダストリー事業部では製品開発にSCRUMを取り入れています。SCRUMの詳細に関してはスクラムガイドを参照いただければと思います。

いわゆるアジャイルな開発が一番、今の会社の状態にはあっていると思ってかれこれ1年近くSCRUMっぽい感じで開発を進めてきました。（ちなみに私はプロダクトオーナーとして製品開発を進めてきた経験も持っています。）

現状のインダストリー事業部のSCRUM開発は2週間スプリントで開発を行っています。毎朝20分程度のデイリースクラムが実施されます。HACARUSでは英語ネイティブのメンバーや日本語と英語がハイブリッドでできるメンバー、日本語しか話せないメンバーがいるので、それぞれ補いあって、デイリースクラムはGitLabのIn progressになっているIssueを見ながら、昨日やったこと、今日やること、チームと共有したいことを話します。本来は15分が目標ですが、日本語・英語で2回同じことを話すためどうしても長くなりがちになっています。Retrospectiveで提起されるKPT（Keep Problem Try）で、問題点として提起されたりして、タイムボックスは守れるようになるべく簡潔に済ますように努力しています。

SCRUMの良いところは成果を感じながら開発が進んでいくことだと思っています。SCRUMの大原則として、そのスプリントが終わったらリリース可能であること、というものがありますが、機能が膨らんでくるといろいろと絡み合いが発生し、開発スピードに影響がでてきます。そのため迅速に開発を進めるためにCI/CDの仕組みやテストの徹底ということが重要になってきます。CI/CDに関しては別途また担当したものから別のトピックとして触れてもらうようにします。

テストについての思い

私が現役でコードを書いていた時代は（遠い目・・・）、自動テストといっても全く環境もなく、私がやっていた組み込み系の開発ではとてもではないですが、実現できるようなものではありませんでした。ただ、なんとかして開発を効率化したい、もっと品質の高いプログラムを書きたいといろいろ読んだ本の中で出会ったのがケント・ベック氏の「エクストリーム・プログラミング」でした。ユニットテストを書いて、確実に動くコードとしてリファクタリングをしていくということができたらどんなにいいだろうと思いました。ただ、とはいえテストを書く分、工数もその分かかってしまうよな・・・という考えも一方ではありました。

しかし、最近の様々な発表やポッドキャストを聞いていると、テストを書くから時間がかかって納期がかかってしまうというのは間違いではないかという疑問を持つようになりました。テストを書いた方が品質が高い状態が保たれて、設計変更に強いコードとなり、時間が経っても変化に強いコードとなり、結果としてアウトプットとして出てくるスループットが上がるのではないかと考えるようになってきました。私はプロダクト開発のトップでもありますので、メンバーにテストを書いて品質を上げてほしい、それが結果としてスループットの向上につながると思う、と粘り強く説いていますが、一方で必要な機能はこれ、納期はこれということも同時に依頼するため、結果としては、メンバーは実装しなければならない機能の実装を優先してしまい、テストの量は一向に増えないということが常態化してしまっていました。

テストのカバレッジを上げるために

このままではよくないと思い、最近ではPlanningの際に、テストを書くためにどれだけのIssueがあるのかを見える化するところから始めることにしました。さすがにメンバーも薄々はテストを書かないといけないという意識はあったものの、できていなかったという自覚はあったため、さっそくどうやって進めていけばよいかということをブレイクダウンして進めてくれています。

Amazonは1時間に最大1000回もデプロイしているといいます。また、上位の組織は週に30回以上デプロイしているというようなことも聞いたことがあります。ソフトウェアの世界だけでそうなのかといえばそうではなく、あの電気自動車を作っているテスラはリードタイムを2日まで縮めていると聞きます。設計、製造、テスト、リリースというサイクルを2日でやってしまうというのです。さすがに一足飛びにそこまではいけないですが、目指すべきところはそういうステージだと思っています。これはやはりメンバーではなく組織のトップである私がリードしないとそこまでは到達できないと思うので、これからも信念をもって実現していきたいと思います。

まとめ

HACARUSのインダストリー事業部ではHACARUS CheckとHACARUS Check AIソフトウェアという2製品を主に開発しています。そこでは主にC#とC++とPythonが使われており、SCRUMをベースとした開発が行われています。まだ自動化のレベルがCI/CDが回り始めた程度であり、テストのカバレッジを上げていく伸びしろはまだまだありますが、よりよい製品をより早くより高品質に作れるような体制をこれからも目指していきたいと思います。