事例紹介
inaho
Company profile企業概要
製品・サービス概要

選択収穫野菜向けの自動収穫ロボットを開発。ロボットは畑を自立走行しながら、AIで成熟度を判断し、ロボットアームで収穫を行う。
ロボットを農家へ貸し出し、収穫高に応じてサービス利用料を徴収するRaaS型のビジネスモデルで、2019年9月にサービス提供を開始(ロボットはレンタルであるため、製品開発は継続)。
農家を対象にした導入説明会の参加者のうち、9割超が導入意向を示しており、早期の量産化を目指している。
ビジネスモデル

ハードウェアの役割/機能

安定的に畑を走行できる移動体と、野菜を傷つけることなく収穫ができるアームで構成されたロボット
case1先の見えない共同研究を継続しモチベーションと効率が低下
ものづくり:原理試作
創業当初、エンジニアが不在だったinaho。「AIで対象を判断し、アームで摘み取り、移動するロボット」の開発を目指し、最初に取り組んだのが、専門家からの助言を乞うことだった。CEOの菱木氏とCOOの大山氏は、インターネットで検索し、手あたり次第に、大学の研究室を訪問。人脈が数珠繋ぎで広がり、開発に向けての知見を深めていった。
そんななか、ロボットアームの製作に携わるA大学の研究者が、 inahoのコンセプトに共感してくれたことで、2016年、アームの開発に向けた連携が始まった。
1年目は奨学寄附金、2年目は共同研究費で大学での開発を進めたが、開発途中に、大学製作のアームはコンプレッサーを使用するため電力のない畑では実用性に欠けることが判明する。また、早期開発を目指すinahoにとっては、大学の開発スピードとリリースに向けたスケジュールに不安を抱えていた。
2018年、新たに加入したエンジニアが共同開発の方向性に疑問を抱き、inaho独自での、ロボットアームの開発に乗り出した。しかし、独自開発が成功する確信が持てなかったために、共同開発の中止を決断できず、共同研究と独自開発を同時に進めることになった。どちらか一方のアームは使用しないことが分かっていながら、両方の製作を行う必要があり、結果として開発スタッフのモチベーションと開発効率の低下を招いた。

スタートアップが得た学び
- 大学との共同研究においては、前提条件の共有が必要
-
大学の研究者は特定分野の専門家であって、個別のユースケースについては詳しくない。協働する場合には、開発の前提条件となる、製品のニーズ、使用環境についてスタートアップ側が十分に理解したうえで伝える必要がある。
また、大学の開発体制、開発スピードは、スピード重視のスタートアップの期待とは異なる可能性もある。共同研究を行う前に、双方で認識を合わせることが重要だろう。
- 自分たちで解決策を考え、開発方針の取捨選択を行う
-
inahoは、開発を外部資源に依存していたため、いざというときに、開発リソースの選択と集中を行うことができなかった。
ハードウェア開発のノウハウがないスタートアップは、外部に開発を“丸投げ”しがちであるが、製品が必要とされる社会的背景、ターゲットユーザー、実現すべきソリューションを最も理解しているのは、発注側のスタートアップに他ならない。少なくとも、どのような製品が必要かという「思考」部分は内部で行い、必要な作業を部分的に外注することが重要である。
case2アグリテック特有の収穫サイクルの長さや圃場の変化への対応
ものづくり:原理試作
inahoでは、ロボットを動かす“収穫時の環境”に合わせた開発に苦労をした。
アスパラガスは、苗を植えてから3~15年程の期間で収穫が可能であり、比較的、栽培サイクルが長い作物である。また、株植えからの年数に応じて、生えてくる位置が離れていくという特徴を持つため、2~3年目の高密度での収穫と15年目の低密度での収穫の両方に対応できなければならない。年単位で株の植え替えを行うトマトのような作物であれば、収穫サイクルが短いのでPDCAを回しやすく、また、生育環境をロボット側に寄せていくことが可能である。しかし、アスパラガスは1つの株で15年間栽培を行うため、AIを環境に合わせる方法で開発を進めざるをえなかった。
また、農作物を育てる圃場は、天候一つで環境が変化してしまう。雨天後の畑では、ぬかるみで走行ルートを示した白線が消えてしまうなど、野外ならではの考慮すべき状況が多様であった。開発拠点のある関東と協力農家のある佐賀では物理的な距離があり、圃場の変化をつかみきれなかった。
これらの“収穫時の環境把握の重要性”を認識できていなかったことで、別の課題も生じた。短期間でのスタッフ増員によって、アスパラガスの収穫期を経験したことのない人が増えたのだ。1年前は、収穫期を体験することの重要性を認識していなかったため、圃場の状況やアスパラガスの生育状況を記録しておらず、肝心の収穫環境について共通認識が持てない状態に陥った。

スタートアップが得た学び
- アグリテック分野でも工夫次第でPDCAサイクルの高速化が可能
-
開発のPDCAを回せる回数は、農作物の収穫サイクルによって変わる。inahoのようにサイクルが長い品種をターゲットとする場合は、データを蓄積し、シミュレーションによって収穫期の状況を再現することが重要である。これらのデータは、組織が拡大する際の教育や知見の共有にも活用可能である。
また、農作物を相手にする場合、開発拠点の近くに圃場を設けることもポイントだ。天候や屋外ならではの環境変化を物理的に確認できることで、スムーズに課題抽出と改良を行えるようになる。
case3立て続けのデモが開発リソースを圧迫
ものづくり:量産化設計・試作
アスパラの収穫時期である10月に合わせて、inahoの営業担当が、試作機デモのスケジュールを立案。協力農家のある佐賀県で、 10日間に4回のデモを行うことになった。
デモの約2週間前にパーツが納品されるという状況で、佐賀県に移動した後も開発を継続。デモの合間を縫って、画像処理の調整や自律走行の開発を進めた。アームの故障や充電ができないといったトラブルも乗り切り、最終日のメディア向けのデモでは成功を収めた。
このままの勢いで開発を進めたいと思ったが、デモの成功を受けて営業活動が次第に忙しくなり、そのことが開発にも影響し始めた。
メディア対応やアクセラレータプログラム参加によるデモの実施が急増したほか、営業担当3名を新規雇用し、佐賀県に営業所を開設。事業推進のために、デモに参加した農家に導入意向書を書いてもらうなどの取組を進めた。その結果、デモの実施のために開発スタッフが駆り出され、試作機の開発が遅延。画像処理、アーム、移動体のいずれも改良の必要があるものの、“デモを成功させるための開発”が優先され、長期的な開発が行えなくなった。
後に一連のスケジュールを振り返ったところ、営業担当と開発担当の情報共有が不足しており、営業担当が上記問題を十分に認識できていなかったこと、そして、アスパラの収穫時期に無理に合わせなくとも、疑似的な収穫環境を作ることで、開発の進捗状況に応じたデモが可能であったことなどが反省点として挙げられた。

スタートアップが得た学び
- 営業サイドと開発サイドが目線を合わせることで、資金調達と開発のバランスをとる
-
資金調達と開発を両輪で回すことで、スタートアップは成長していくが、そのバランスの取り方は難しい。
営業スタッフは、量産や販路拡大に向けて資金調達や営業活動を進めるが、先行しすぎると開発に良くない影響を与えることがある。その典型的な事例が、上記のinahoの事例である。
最小限の人員で構成されるスタートアップと言えど、営業サイドと開発サイドでは、見ている世界が違う。両者が定期的に、製品の完成度、課題などを共有し、短期的、中長期的な目標に向けて、一体となって舵を切ることが重要である。
case4会社の拡大に伴いスタッフの情報共有や連携にほころびが…
人材・組織
inahoは、サービス開始に向けて、エンジニア、営業、広報、人事など、スタッフを増やした結果、組織的な課題が散見されるようになった。
例えば、少人数のころは“阿吽の呼吸”でできていたことが、開発担当、広報担当など役割が分かれたことで、タスクが落ちてしまうようになった。
また、開発担当のなかでも、ソフトウェアとハードウェア、ソフトウェアのなかでも画像処理担当とアプリケーション担当など業務が細分化され、業務の属人化や担当間の情報共有で課題が生じた。
inahoでは、このような課題は組織的なリスクと認識しており、定期的なスタッフの振り返りのもと組織体系を変更し続けている。
2019年の夏頃は、役割と機能のマトリクス型の組織体系としたが、進捗とクオリティ管理が十分でないと判断し、秋頃からは、優先順位付けしたタスクに対して、社員全員がコミットする“スクラム”を実践している。スクラムはソフトウェア開発のための手法であり、ロボット開発には適さない部分も多い。しかし、属人化とタスク漏れを避けるために部分的にでも行えれば良いと考え、 inaho流にアレンジして取り組んでいる。
メンバー全員で打ち合わせを行い、次の開発目標と優先順位、タスクを可視化したことで各人の業務の位置づけが明確になり、組織としての一体感も増すようになった。

スタートアップが得た学び
- 組織のあるべき姿は、その時々で変わる
-
スタートアップは、試作、量産と進むなかで、その体制が大きく変化する。組織が急成長するため、通常の企業よりも、コミュニケーション不足や、進捗管理・クオリティ管理のミスなどが生じやすい。
inahoでは、組織の成長とともに、作業が属人化することでスタッフ退職時に開発ノウハウが損失することや、コミュニケーション不足による人間関係の悪化が懸念されていた。
組織形態も開発と同じであり、試行錯誤が重要である。成長を継続していくには、阿吽の呼吸ではうまくいかなくなったとき、ケアレスミスが頻出したときに、組織形態の変更、定期的なミーティングの実施、情報共有のルールの設定などの検討が必要である。