株式会社CLUEと株式会社Senyouが共催したトークイベント「ドローン × AI プロダクトの未来」のレポート後編をお届けします。

▼前編はこちら

https://pro-dx-studio.senyou.dev/works/20260305

前編では、CLUEが目指す「テクノロジーの社会実装」という事業視点の話を中心に、ドローン産業の現在についてお届けしました。

後編となる今回は、「開発の裏側」にフォーカスします。 単なる受発注の関係を超えた「開発スピード3〜5倍」を実現するチームビルディングの秘訣や、エンジニアが本当に解くべき「イシュー（課題）」の見つけ方について、CLUE柴山氏とSenyouテが語ります。

真の「イシュー」特定と、不安を解消する「価値提供」

さしみ：実は1年ほど前にもインタビューさせていただいたのですが、その際も「プロダクト企画・開発におけるポイント」が話題に上がりました。これからの時代、どのエンジニアにとっても「どこにイシュー（課題）を見出すか」という視点はますます重要になってくるはずです。

問いをどう設計し、それをAIへの指示や実際のコードにどう落とし込んでいくのか。CLUE社、そして柴山さんが企画・開発において大切にされている点について伺えますか？

柴山： そうですね。私たちは大きく分けて2つの側面、「何を課題とするか」という点と、「それに対してどんな価値を提供するか」という両面を非常に重視しています。

プロダクト開発において、ユーザーの要望をそのまま形にすることが正解とは限りません。ユーザーが自分の抱える課題を、常に的確な言葉で伝えてくれるわけではないからです。

例えば… iPadの画面で文字が見えにくいとき、ユーザーから「虫眼鏡機能がほしい」という要望をいただくことがあります。しかし、そこで立ち止まって考えます。本当に必要なのは虫眼鏡機能なのか？ 単に文字サイズを大きくしたり、拡大表示をしやすくしたりすれば解決するのではないか？

このように、表面的なリクエストの裏側にある「本当は何に困っているのか」を深掘りし、イシューとして正しく捉え直すことを何より大切にしています。

もう一つは、ユーザー体験の細部にまでこだわる価値提供のあり方です。私たちは、単に情報を提示するだけでなく、ユーザーを迷わせない設計を意識しています。

• 情報の提示だけで終わらせない ドローンを飛行させている最中に「電波が弱いです」というアラートだけが表示されたら、ユーザーはただ不安になってしまいます。
• 次のアクションを促す 「不安にさせること」は私たちの目的ではありません。「電波が弱いので、このように機体を操作してください」といった、具体的なアクションまでを提示して「安全な飛行」という価値を提供する。

こうした一つひとつの細かな配慮こそが、プロダクトとしての真の価値に繋がると考えています。

さしみ： なるほど。ユーザーの声をそのまま受け取るのではなく、その裏にある真のイシューを特定する。そして、プロダクトのビジョンと現場のニーズを天秤にかけながら、事業状況に合わせて優先順位をつけ、実装へと落とし込んでいく……。まさに「社会実装」を体現するプロセスですね。

これからプロダクト開発において、エンジニアが「どこに問いを立てるか」という視点は、ますます重要になってくると感じます。開発パートナーとして数多くの現場を見てこられた井上さんから見て、このようなエンジニアの在り方についてはどう思われますか？

井上： 柴山さんがおっしゃったような「課題の特定から実装まで」というプロセスは、本来であれば非常に難易度が高く、現場では役割分担をされるのが一般的です。エンジニアが一人でイシューを見つけ出し、解決までやり切るというのは、かなり大変なことだという印象がありました。

しかし、AIの登場によって実装の難易度が劇的に下がっている今、状況は大きく変わりつつあります。これからは、イシューの特定から具体的な機能への落とし込みまでを一気通貫で担える人材のニーズが、これまで以上に高まっていくはずです。

CLUEさんの現場でも、柴山さんが掲げるイシューに対し、ビジネスサイドの目線を持って「手段としての技術」をどう組み合わせていくか。技術を単なる作業としてではなく、解決の手段として扱えるエンジニアの存在が、以前にも増して重要になっていると強く感じますね。

開発スピードが「3〜5倍」に。その裏にあるのは“的確な指示”と“自走する力

さしみ：インタビューの中では他にも、「Senyouがチームに参画したことで開発スピードが予想の3倍から5倍と非常に早く驚きました」という箇所がありましたね。記事ということもあって少し盛っているかもしれませんが（笑）。実際にはどのような経緯で参画し、どのようにしてその3倍から5倍というスピードを実現したのでしょうか？

テ： この3倍から5倍というのは、おそらく柴山さんが感じられている実体験によるものだと思いますね。私たちとしては開発スピードをあげることを目指していたわけではなく、単にできることを全力で投下して実行するという姿勢で取り組んだ結果かなと。 また柴山さんが非常に聡明であるというのも影響していると思っています。的確でない「変な」指示を出されることがないというか（笑）。

「このようなことを実現したいので、あとは任せます、やってみてください」という的確な指示をいただけることで、エンジニアが自らの頭で考え、とりあえず実装してみるといったことが全て可能になります。 

この指示のおかげもあって、開発が遅い現場にありがちな議論を省き、すぐにプロトタイプ作成に入れるので、開発スピードが格段に上がるんです。

またCLUEさんの思想として、業務委託か社員かという切り分けが基本的には存在しません。私たちは業務委託という立場ではありますが、同じ開発メンバー、一つの開発チームとして扱っていただけるため、非常に仕事がしやすい環境です。 こうした環境が、スピードをさらに加速させる要因になっていると感じています。

柴山：いやいや、3倍から5倍という数字は本当に感じているところです（笑）。私は以前、銀行のシステムなど厳格に要件定義を行った上で開発をしていたこともあり早く感じるのかもしれませんが……。テさんがおっしゃった通り、背景や実現したいことの目的、そして時には技術的な選択肢といった点をお伝えした上で、あとは試行錯誤しながら進めてくださいというような依頼の仕方を普段から心がけていますね。それが一つの要因として、かなりのスピードが出ているのではないかと感じています。

「発注・受注」の壁を超えて。コンテキストの共有が「当事者意識」を生む

さしみ： ありがとうございます。そうした素晴らしいパートナーシップを築くための「連携のコツ」のようなものはありますか？

柴山： 一つは、目的や背景、いわゆるコンテキストをしっかりと共有しておくことです。 また、依頼する際には「ハウスメーカー様がこういう業務で困っている」といったように、具体的なお客様の例や状況まで伝えています。作り手が「それを使うとお客様がどうなるか」を解像度高くイメージできれば、結果として手戻りも少なくなりますから。

さしみ： なるほど。背景や目的の共有は大事ですね。一方で、発注側と受注側という壁を作らず、「ワンチーム」として信頼し合う関係性も重要だと感じます。信頼がないと確認コストばかり増えてしまいますしね。テさん、そのあたりエンジニアとしての実感はいかがですか？

テ： そうですね。私たちが普段やるWeb開発は仕様が決まっているものを「開発する」ところだけを担当することも多いですが、CLUEさんの場合は「自分たちが作ったものが社会にどう影響するか」が非常にリアルに感じられます。 こうした経験は開発だけを切り分けて担当していると得られるものではありません。

井上： 「目的や背景を整理して、開発側が作業しやすいように整える」というのは、どのクライアント様も理想としては持っているはずです。しかし現実には、整理しきれる前に「丸投げ」になってしまったり、あるいは楽をしようとして曖昧なまま任せてしまったりするケースも少なくありません。

そうした中で、なぜ柴山さんはそこまで解像度高く落とし込んでから依頼ができるのでしょうか？ それを実現できている背景には、どのような要因があるのでしょうか。

柴山： そうですね、これまでの自分の経験が生きている部分は大きいと思います。 元々SIerでSEとしてコードを書いていましたし、その後は新しいテクノロジーを使ったプロトタイピング業務といいますか、企画から実装、提供までを自分一人で完結させる仕事をしていました。

その経験があるため、「これをやりたい」と考えた時に、「技術的にどう実現するか」という視点と、「業務的に何が必要か」という視点の両方を頭に入れた上で構成できているのかなと思います。

「無理」を「できる」に変える着眼点。エンジニアが「夢中になる」開発現場の魅力

さしみ： 契約上は「業務委託」という形ではありますが、テさんはその枠組みを感じさせないほど、プロジェクトに深く入り込んでいますよね。 立場に関係なく、そこまで前のめりに成功させようと思えるやりがいや熱量は、一体どこから湧いてくるのでしょうか？

テ： 一番の理由は、柴山さんのプロダクトに対する「着眼点」がすごく面白いことです。「ドローンでこういうことをやろう」という発想を聞いて、その意図を理解した瞬間に「私が実現してみせるぞ」というエネルギーが湧いてくるんです。

例えば、以前「壁の広さを写真の画像解析で測る」という機能開発がありました。通常のWeb開発の常識では「そんなの無理だろう」と思い込んでしまうようなことでも、柴山さんから「こういう技術を使えばできるんじゃないか」と的確な指示やアドバイスが飛んでくるんです。実際にやってみると、本当に実測値に近い解析ができてしまう。「自分たちにもこんなことができるんだ」という発見がありますし、エンジニアとしてのステップアップも実感できます。「次はどんな発想が出てくるんだろう」と期待しながら動けるので、モチベーションは常に高いですね。もう5年ほど一緒にやっていますが、飽きたことは一度もありません。

技術領域ごとのチーム編成と、インフラ点検という新たな「不」への挑戦

さしみ： 柴山さん、ありがとうございます！ 最後に会場の皆さんからも、感想や質問をいただければと思います。ここまでのお話で気になる点はありますでしょうか。

質問者： 組織体制についてお伺いします。現在の開発現場では、プロダクト単位でスクラムチームを組むことが多いと思いますが、御社は技術領域でチームを分けているとのことでした。プロダクトごとのチーム感とのバランスはどう取られているのでしょうか？

柴山： そうですね。弊社のサービスは「ドローン」という共通軸があるのが特徴です。日々の開発はタスクカンバンで管理していますが、バックログ自体はプロダクト横断で混ざっています。 モバイル用、Web用といった技術領域ごとのバックログがあり、そこからタスクを取っていく形です。「ドローン運用の全体像を実現したい」といったストーリーがあり、それを複数のプロダクトで実現するためにバックログを横断させています。

質問者： そうなるとドメイン知識がかなり広くなると思いますが、エンジニアの方は対応できているのでしょうか？

柴山： そこは本当に恵まれていますね。長く関わってくださっているエンジニアが多く、私より古株の業務委託の方もいます。「元々はiOSエンジニアだがAndroidもやる」「Webもやる」といったように、スキルチェンジしながら柔軟に対応していただける方が多いので、うまく回っています。

質問者： 最後に「未来」というテーマでお聞きしたいのですが、現在は屋根や外壁の解析が中心かと思います。今後、ドローンを使って新しく挑戦したいことや、事業の展望について教えていただけますか？

柴山： 今後の展開としては、現在の住宅向け点検や大規模建設向けサービスに加え、「インフラ点検」の領域にも興味を持っています。 橋梁などのインフラ点検ではドローン活用が始まっていますが、まだ実運用には課題があります。そこを解決できるサービスも考えていきたいです。

質問者： その際の「ハードル」とは具体的にどのようなものでしょうか？

柴山： 一番分かりやすいのは、大量の画像データの整理です。 橋梁などの大きな対象物を撮影すると、写真は200〜300枚になります。事務所に戻ってチェックする際、壁面などは見た目が似ているため、「ひび割れを見つけたが、これがどこの場所かわからない」という事態が発生します。 これを解決するために、撮影時に位置情報などを埋め込み、最終的に報告書まで自動作成できる仕組みは十分に可能だと考えています。現状、手作業だと報告書作成だけで2〜3週間かかると言われていますから。 私自身、実際にヘルメットを被ってドローンで橋梁点検を行った経験があるのですが、その後の作業が本当に大変でした（笑）。その「地獄」をどうにかしたいというのがモチベーションになっています。

質問者： 技術的なハードルをクリアしたとして、業界的なハードルについてはどうでしょうか？

柴山： そうですね。点検対象によっては、法律で定められた報告書の様式や、過去データとの比較方法などが細かく決まっています。 それらにしっかり対応していくことは、開発に時間はかかりますが必要不可欠です。逆に言えば、そこまで対応しきれば業界のデファクトスタンダードになれる可能性もあります。

「発注者と受注者」という垣根を超え、同じゴールを見据えて走るCLUEとSenyou。

今回のイベントを通じ、単なる技術力の提供だけではない、「互いにリスペクトし、高め合う関係」こそが、テクノロジーの社会実装を加速させるのだと改めて感じるところとなりました。

ドローンやAIという新たなテクノロジーの力で、既存産業の「不」を解消し、社会をアップデートしようとするCLUEの挑戦。Senyouは今後もそのビジョンの実現に伴走し、共に新しい価値を創り上げていきたいと考えています。