技術の先にいる人へ、価値を届ける。Spectee CTOが語る、24時間365日動き続けるサービスと自律する開発組織

株式会社Spectee

必要な情報を、必要な人に届ける

──　Specteeの事業内容と、その原点を教えてください。

私たちは、AIリアルタイム防災・危機管理サービス「Spectee Pro」と、製造業向けのサプライチェーン・リスク管理サービス「Spectee SCR」を提供しています。

事業の原点は、2011年の東日本大震災です。当時、代表の村上は1年以上ボランティアに行っていました。

SNSでは「あれが必要だ」「これが足りない」といった情報が飛び交う一方、マスメディアでは主に大きな災害現場が取り上げられていました。小さな市や町では人手や物資が足りず、大きく取り上げられた現場では、それ以上受け入れられない。村上は、そうした情報の格差を強く感じたと話しています。

情報をきちんと整理し、必要な人に届けることができれば、もっと多くの命や、その地域の経済活動、生活を守れるのではないか。その思いが、ビジネスの出発点です。

当初は、自分のいる地域で何が起きているかを把握できる個人向けのサービスを考えていました。2014年にアプリをリリースし、SNSの膨大な投稿から災害や事故の情報を自動で選び出して届ける仕組みは注目を集めましたが、個人向けでは継続的に収益を上げる形を描きにくいという課題がありました。

そんな中、関心を示してくれたのが報道機関です。ちょうどSNSから報道のきっかけを探す取り組みを始めていた放送局があり、私たちのツールがそのニーズに合っていました。そこから、報道機関向けのBtoBサービスへと少しずつ形を変えていきました。

その後、自治体や企業の防災担当者へとお客様が広がり、現在の事業へと発展しています。形は変わっても、必要な情報を必要な人に届けるという原点は変わっていません。

ものづくりからビジネスへ。「世界を変えたい」という思いに惹かれて

──　エンジニアを目指した原点と、ヤフーに入社するまでの歩みを教えてください。

小さい頃から、ものを作ったり、仕組みを考えたりすることが好きで、家電を分解してしまうこともありました。小学校の高学年でプログラミングにも少し触れましたが、本格的に学んだのは大学に入ってからです。

大学では情報工学を専攻し、1996年頃に初めてインターネットに触れました。ウェブを通じて人々がつながるコミュニティが生まれ、世界がより身近になっていく。その感覚に惹かれて、ウェブサービスの分野に進もうと決めました。

新卒で入社した富士ソフトでは、ウェブ関連の開発に携わりました。お客様の仕様に沿って作る仕事を続ける中で、3年目くらいから「自社のサービスを自分たちで育てたい」という思いが強くなり、ヤフー（現LINEヤフー）に転職しました。

──　ヤフーでは、どのような経験が転機になりましたか。

2005年頃に入社し、Yahoo!オークションに携わりました。当時から非常に大きなサービスで、24時間動き続けるシステムをどう安定させるか、大量のトランザクションをどう処理するかを学べたことは、大きな経験でした。

途中でエンジニアからディレクターに変わり、パートナー企業と話す機会も増えました。ところが、使われる言葉や話の内容がなかなか理解できない。それまでの私は、とにかくいいものを作ればいいと思っていて、ビジネスのことをまったく知らなかったんです。「このままビジネスを知らずに、エンジニアを続けていていいのだろうか」と考えるようになりました。

それで、仕事をしながら通える大学院を探し、ヤフーを辞める少し前からグロービス経営大学院に通い始めました。

──　退職後は、どのようなことに取り組まれたのでしょうか。

自分で起業し、Instagramのような個人向けサービスを作ろうとしました。ただ、なかなか人を集められず、マーケティングや資金力の影響の大きさを感じました。

その後、ヤフー時代のメンバーが関わっていたガラポンという会社で、スマートフォンから番組を見るための録画機の開発に携わりました。ハードウェアの制御は、ソフトウェアだけの開発と比べて想像以上に難しく、そこでさまざまな経験を積みました。

──　村上さんとの出会いから、Specteeへの参画までを教えてください。

私がグロービスに通っていた時期に、村上も早稲田大学ビジネススクールでMBAを学んでいました。村上が主催した学生交流会の勉強会を手伝ったのが、最初の出会いです。

その後、私が先に起業し、村上も起業した際に、秋葉原のコワーキングスペースへ誘いました。同じ場所でそれぞれの事業を進めるうちに相談を受けるようになり、副業でシステムの作り直しや改修を手伝っていました。

会うたびに参画を誘われていましたが、私はまだ自分の事業やハードウェアの開発に取り組みたいと思っていました。それでも何度も声をかけてもらい、資金調達を機にフルタイムでの参画を誘われ、2013年に正式に入りました。

村上には「世界を変えたい」という強い思いがありました。手伝う中で、その思いが少しずつ形になり、「これは可能性がありそうだ」と感じたんです。「より広く、世の中のためになるものを作りたい」という熱意に惹かれ、参画を決めました。

顧客への対応スピードと、技術的負債の解消を両立する

──　参画当時から、プロダクトと開発組織はどう変化しましたか。

当時の開発メンバーは3人ほどでした。外部に委託した開発の調整や、システムの作り直しも含めて、少人数ですべてを担っていました。現在は業務委託の方も含めてエンジニアが約50人、全社では約110人の体制になっています。

プロダクトも大きく変わりました。当初は、報道機関の方がSNSから現場の情報をいち早く見つけ、ニュースにするまでの業務を支えるサービスが中心でした。

その後、自治体での利用が広がり、集めた情報を地図と連動させたり、河川や道路のカメラ映像、気象データを重ねたりと、防災担当者が必要な情報を一つの画面で把握できるよう機能を広げてきました。

──　初期のお客様の声には、どのように応えていたのでしょうか。

私もできるだけお客様のところへ行き、「こういう機能があるといい」という声を素早く反映していました。それが、初期のお客様から信頼を得られた理由の一つだと思います。

そのために、システムを最初から固めすぎず、柔軟に対応できるアーキテクチャを採用していました。ただ、要望に応えて機能を重ねていった分、保守の面では見直しが必要な部分も生まれてきました。

──　そこで生まれた技術的負債には、現在どのように向き合っていますか。

何年かに一度は大きく見直す必要があり、かなりのコストがかかります。長く安定してサービスをお使いいただくために欠かせない投資ですが、それ自体が直接売上を生むわけではないので、売上を伸ばす取り組みとどう両立するかは、今でも難しいところです。

技術的負債の解消は、お客様からは見えにくい取り組みです。新しい機能がすぐに出てこない期間もあるため、どこにどれだけ投資するかの優先順位づけは私が責任を持って判断し、なぜ必要なのか、なぜこれだけ時間がかかるのかを、社内に丁寧に説明するようにしています。

技術的負債の解消は長い期間をかけて進めるため、その間に会社として注力すべきことが出てきたら、チームを分けて対応する必要があります。サービスは24時間動いていて止められませんし、突発的なお客様の要望にも応えなければなりません。そのバランスを取りながら進めることが、今も大きなテーマです。

フラットな組織で、チームが自ら意思決定する

──　現在、CTOとしてどのような役割を担っていますか。

今年の4月まではプロダクト本部のトップを務めていましたが、別の本部長に任せ、現在はテクノロジー、セキュリティ、プラットフォームなど、共通部分のアーキテクチャに責任を持っています。

今も開発にはかなりの時間を使っています。チームごとに役割と責任を分けた分、チームの境界にある課題や、特定のチームが担当していないシステムへの対応は、私が拾うようにしています。今後はそうした部分もチームで担えるようにして、私自身はマネジメントや全体の設計により時間を使っていきたいと考えています。

──　フラットな組織を重視しているのは、なぜでしょうか。

できるだけ意思決定を早くしたいからです。EMはそれほど多くなく、チームが自律的に動き、チーム内で意思決定できるようにしています。報告や確認も、できるだけ一つのレポートラインで済むようにしています。

背景には、これまでのキャリアで、承認の段階が多い組織ほど物事が前に進みにくいと実感してきたことがあります。だからこそ、組織の仕組みが事業のスピードを妨げる状態は作りたくないんです。自分たちで意思決定できれば、それほど複雑な組織にする必要はないと考えています。

──　具体的には、どのようにチームを分けているのでしょうか。

複数のプロダクトに共通するのは、データを集め、分析し、お客様に届けるという価値の流れです。この流れに沿って、データ収集、分析、研究開発、プラットフォームなど各プロダクトに共通する土台を担うチームと、お客様が使うサービスそのものを担うチームを置いています。加えて、セキュリティにも専任のチームがあります。

この10年でシステムが非常に大きくなり、一人のエンジニアが全体を把握することが難しくなってきました。各チームの認知負荷を減らすことも、チームを分ける理由です。

──　今後も、フラットな組織を維持していく方針でしょうか。

メンバーが自分たちで意思決定できているうちは、そうしたいと考えています。ただ、チームを分けても、把握すべき市場の情報などは増えています。AIによって情報を整理しやすくなった一方で、カバーする範囲も広がっています。

どこまで自分たちで情報を集め、判断できるかは、今後も見ていく必要があります。誰かが全体を調整しなければうまく回らなくなったら、どのような役割やポジションを置くのか、新たな階層が必要なのかを考えなければならないと思っています。

24時間365日、「安心して眠れるシステム」を目指す

──　プロダクトを支える技術では、何を重視していますか。

以前は、AIでできるだけ自動化するためのモデル開発に注力していました。最近はLLMの汎用的なモデルでも十分な成果が出るようになり、既存のモデルを活用したり、一部をファインチューニングして防災領域に特化させたりする取り組みへと変わっています。それを、うまくサービスにつなげることが重要です。

もう一つはデータ設計です。私たちは災害に関する膨大な情報を世界中から集め、異なる形式の情報を扱いながら、お客様に届けています。設計に気をつけなければ、システムが破綻しやすくなったり、メンテナンスできなくなったりするので、限られた人数で運用できる仕組みづくりにも力を注いでいます。

──災害時の急激な負荷には、どのように対応していますか。

平常時の気象情報ではそれほど負荷がかからなくても、大きな災害が起きると急激に高まることがあります。その状況でも24時間安定して動かすために、負荷の変化に対応できる、スケーラブルな設計を重視しています。

当社ではAWSの各種サービスを使っています。エンジニアにもできるだけAWSの資格を取得してもらい、最適なアーキテクチャを選べるようにすることを意識しています。

──　サービスを止めずに運用するために、チームでどのような工夫をしていますか。

できるだけ人がメンテナンスしなくても済み、自動的に復旧できる仕組みを、設計や技術選定の段階から考えています。ただ、技術選定は難しいもので、選んだサービスがすぐに終了し、乗り換え先に悩んだこともあります。

こうした意識の背景には、初期の経験があります。長く関わっているメンバーには、夜中に起こされて障害対応をした経験がある。だからこそ、「安心して眠れるシステムにしよう」という思いが強いんです。

レビューでも、「ここは、こういう仕組みを使わないと、何かあったときに困る」と話しています。問題が起きたときも安全を保てる、フェイルセーフなシステムづくりは、みんなが意識していると思います。

AIで変わる仕事。エンジニアからPdMへ、PdMからPMMへ

──　AIの活用によって、エンジニアの仕事はどう変わっていますか。

人がコーディングする作業は徐々に減ってきています。その分、エンジニアが「どうお客様に価値を届けるか」に注力できるよう、特に今年は力を入れ始めています。

日頃から、課題をどう解くかを自分たちで考えるように伝えています。お客様の「こうなっているといい」という要望をそのまま実現するだけでなく、「本来、この問題を解決するには、どのようなサービスであるべきか」まで深く考えることを大切にしています。

──　エンジニアが直接、お客様の課題を聞く機会も増えていくのでしょうか。

多くの場合はビジネス側が情報を集め、業務要件をまとめてくれます。ただ、課題を深く理解するために、エンジニアがセールスと一緒にお客様のところへ行き、課題や業務の進め方を分析することもあります。今後、そうした機会はかなり増えると思います。

一方で、お客様の話を直接聞くと、その声に強く影響を受け、本来あるべき姿を考えるよりも、目の前の問題の解決に飛びつきやすくなるのではないか、という懸念もあります。

だからこそ、「本来、解決しなければならない課題は何だったのか」を振り返る必要があります。その振り返りを、仕組みにしていきたいと考えています。

──　AIを使った開発で、セキュリティや品質はどう担保していますか。

セキュリティでは、その分野の専門家が作ったサービスをシステムに取り入れることが重要だと考えています。例えば、認証にIDaaSのようなサービスを利用する方法があります。専門家が最新の情報に基づいてメンテナンスしてくれる仕組みを活用したいですね。特定の分野では、業務委託や採用でも専門家の力を借りています。

品質の面では、AIによってテストカバレッジを上げたり、アーキテクチャの抜け漏れを指摘してもらったりできるようになりました。一方、完全に任せると、大量に作られるコードのチェックが追いつかず、品質が下がる可能性もあります。

どこを人が確認し、どこにAIを二重、三重に組み込んで自動化するのか。そのバランスを考えながら、仕組みを作っています。

──　エンジニアには、どのような役割を担ってほしいと考えていますか。

仕様を考える仕事が増える中で、エンジニアも少しずつPdMに近い役割へ移っています。チームの境界にある課題にも自ら気づき、動けるエンジニアが増えれば、組織としてもっと強くなると思います。

現在のPdMには、仕様をコントロールするだけでなく、ビジネスをコントロールできるようになってほしいと考えています。PdMがPMMへ、エンジニアがPdMへと、少しずつ役割を広げていくことを求めています。

エンジニアには、お客様への理解を深め、自分で意思決定し、何を作るのかを正確に指示できるようになってほしいですね。

──　その変化に向けて、どのような育成をしていますか。

昨年の5月頃、AIを活用した開発が進むことで、コードを書いてものを作れること自体の価値は、少しずつ下がっていくのではないかと話しました。ただ、それはキャリアを悲観する話ではなく、自分たちが作りたいものを、より素早く作れる時代になるということです。

だからこそ、何を作るかを決めるための情報収集やコミュニケーションが重要になります。その変化に合わせて、自分たちも変わっていこうと伝えました。

ものを作ることに集中するあまり、ビジネスへの理解が十分でない場合もあります。そのため、自分の考えを相手に伝えるための論理構造や、やりたいことを実現するためのロジックの組み立て方を、昨年から教えています。私がMBAで学んだ論理的思考やマーケティングの知識も、エンジニアに学んでほしいと思っています。

自分の技術を、人のために。日本の防災の知見を世界へ

──　Specteeで活躍しているエンジニアには、どのような共通点がありますか。

防災の分野で、誰かのためにプロダクトを作りたいという人が多いですね。技術への興味だけでなく、その先にいる人たちにどう価値を提供し、どうすれば救えるかという思いが強い。それが組織の強みだと思います。

それまでの仕事で「自分が作っているものに、社会的な価値があるのだろうか」と悩み、Specteeを選んでくれた方もいます。一度当社を離れた後、家族を持ち、「何のために働くのか」を改めて考え、防災や人の役に立つサービスに取り組みたいと戻ってきてくれた方もいます。

──　Specteeで得られる経験と、採用で重視していることを教えてください。

インフラからフロントエンドまで、設計や運用管理も含めて自分たちで担うので、技術的な裁量は大きいと思います。若手でもベストプラクティスを調べ、アーキテクチャを提案し、それが採用されることがあります。

長く在籍するミドル層も多く、モノリシックな構成から分散システムへの変化に携わりながら、キャリアを築いてきました。サービスを止めずにメンテナンスや変更を進める経験も得られます。

採用では、課題をどう抽出し、どのような問いを立てるかに長けた方を重視しています。若い方でもその力を持つ人はいるので、年齢や経験だけでなく、思考の仕方や発想力を見ています。

──　今後、会社として目指していることを教えてください。

海外事業をもっと伸ばしていきたいですね。日本で得られた防災や災害対応のソリューションを海外へ展開し、より安全で、災害への対応力や回復力の高い社会を作りたいと考えています。

私自身のキャリアとしても、「世界をこう変えることができた」と言えることを成し遂げたい。その点は、会社としても非常に重視しています。

──　海外展開に向けて、開発体制はどう考えていますか。

現在、「Spectee SCR」と海外事業の開発は、インドの開発チームと連携して進めています。日本企業向けパッケージのテストや仕様書の読み込みに慣れたチームがあると紹介を受けたのがきっかけでした。日本との間には、ブリッジ役の方や英語が得意な社内メンバーなど3人ほどが入り、コミュニケーションを支えています。今後も、国内で作ってきたモデルを海外へ展開するため、国内のメンバーが多くを担うと思います。一方、国ごとに習慣や知見は異なるので、現場からのフィードバックを素早く反映するために、現地のエンジニアも重要になると考えています。

各地域にエンジニアを置くのか、対象地域に近く、文化的な背景も近い場所に拠点を置くのか。その点は、事業のバランスを見ながら検討していく必要があります。

──　最後に、読者へのメッセージをお願いします。

私たちは、世界を変えていくことを本気で実現したいと思っています。仲間と一緒に大きなことを成し遂げたい方や、自分の技術的な能力を世の中の人のために使いたい方に、集まってほしいですね。そうした仲間とともに、目指していることを実現していきたいと思っています。