フルスタック文化のエンジニア組織にフィット。派遣社員でありながらチームの改善活動にも主体的に貢献

——まず御社の事業内容について、教えていただけますか？

藤田氏：スペクティでは、防災やBCP、リスクに関する情報を世界中から収集し、企業や自治体の皆様にお届けするサービス「Spectee Pro（防災・BCP向け）」「Spectee SCR（サプライチェーン向け）」を提供しています。私たちのミッションは、「“危機”を可視化する」ことです。今どこで何が起きているのかをリアルタイムで把握できるようにすることで、災害や事故などが発生した際に、社会が元の状態に戻るスピード、つまり、「社会のレジリエンスを高めていくこと」を目指しています。

——非常に社会的意義の高いプロダクトだと感じましたが、サービス立ち上げにはどのような背景があったのでしょうか？

藤田氏：きっかけは、東日本大震災です。弊社代表の村上が起業する直前に、震災（2011年3月11日）がありまして、彼は当時勤めていた会社を休職して、現地へボランティア活動に行きました。その時、彼が訪れたのはあまり報道されていない比較的小さな町で、現地では人手も物資も全然足りていなかったのですが、隣町はテレビによく取り上げられていて、人も物資も足りてるという状態がありました。テレビの報道上では、あたかも「災害現場全体が物資も人手も足りている」かのように伝わってしまい、テレビを見ているだけでは「どのエリアがどれだけ困っているか」という実態がまったく可視化できていませんでした。

そんな中、SNS上では「水が足りない」「これが届いてない」といった現場の声が各所であがっている状況を目にして、「必要な情報が、必要な人に届いてない」と村上は痛感し、この”情報格差”を埋める必要があるのではないかと考えました。その経験から現在のSpecteeのサービスが立ち上げられたという背景があります。

——実際に現地を訪れて感じた「情報の格差」という問題意識が、御社のサービスの原点だったのですね。

はい。最初はtoC向けに、「自分の周りで何が起きているかがわかる」ようなサービスを提供していました。ただ、toCでの収益化が難しかったため、途中からtoB向けにピボットしました。当初は、報道機関向けのサービスとしてスタートし、ニュース素材として使っていただくようなビジネスモデルでした。そこから徐々に自治体やインフラ系企業などにも広がり、今では行政のお客様へも数多くご利用いただいています。

自走力と主体性を重視した、開発チームのカルチャー

——藤田さんはCTOとして、プロダクトの中でどんな役割を担っていらっしゃるのでしょうか？

私はプロダクト全体の責任者を務めていて、企画と開発の両方を担当しています。代表の村上は、もともとセールスまわりを担当していて、今でも全体的な方針については彼がコントロールしている部分もありますが、私は主に開発体制の構築や技術面を全般見ています。

——藤田さんがマネジメントされているエンジニア組織についてお伺いしてもよろしいでしょうか？

はい。人数でいうと、国内が40名ぐらいで、あとはインドに10名ほどの開発チームがあり、全体で約50名体制でプロダクト開発を進めています。国内の40名のうち、正社員と業務委託の比率はおおよそ8:2で、時期によっては業務委託の割合がもう少し少なくなることもあります。

チーム編成としてはプロダクトごとに、防災・BCP向けの「Spectee Pro」と、サプライチェーン向けの「Spectee SCR」の2チームに分かれています。さらにその中で弊社のサービスの特性上、「情報を収集して、可視化する」というプロセスがありますので、情報を処理する部分を担当するチームや、研究開発に特化したチームなど、いくつかのユニットに分かれて開発を行っています。

——開発環境、技術の面ではどういったものを使用されていますか？

データ処理、情報の収集系ではPython。ただ最近はTypeScriptに移行している部分も多いです。サービス側もTypeScriptがメインになってきています。

——そこには技術選定の背景もあるのでしょうか？

あります。弊社は構造としてサーバレスで、スポットでタスクが動くような仕組みにしていて、環境依存がなるべく少なくなるように意識しています。たとえばAWSのLambdaで、Python3.8のサポートが年内で終わるとなると、それに全部対応しなきゃいけない。そういうのをTypeScriptにすることで、ビルドの時点で変換できて、ランタイムを気にせず動かせるようになるんです。

——なるほど。合理的な判断に基づいているのですね。関連して、エンジニア組織づくりの中で大事にされていることはありますか？

そうですね、弊社のエンジニア組織はとてもフラットな文化が特徴で、業務委託の方であっても関係なく、一人ひとりが開発の深い部分に関わっています。

私も直接チームを持っていて、比較的現場に近いポジションで動いているんですけど、そうはいっても私一人では到底全体を見きれないので、チーム単位で「今どんな課題があるか」「どうすれば解決できるか」を考えて、自分たちで改善していけるような組織づくりを意識しています。

——指示を待って動くというより、自分から当事者意識をもって動いていくスタイルなんですね。

そうですね。もともとはどちらかというと、アジャイルよりのウォーターフォール的な開発の進め方が多かったのですが、今後エンジニア個人の市場価値を高めていくには、自分たちで課題を見つけて、解決していく力が必要だと感じていました。

AIがコードを書くような時代になってきていますので、そういった視点や姿勢がないと生き残っていけないという危機感もあります。弊社の事業もそうですが、エンジニアとしても成功してほしいと願っていますので、今は各チーム主導の開発体制へと切り替えていきました。

未経験からでも活躍できる環境づくりと、ラクスパートナーズ活用の意義

——正社員採用も滞りなく進んでいらっしゃるという記事を拝見しまして、その中でビジネスパートナーを活用しようと思われたのはどういった経緯だったのでしょうか？

ビジネス環境の変化が激しい中で、急ぎ対応しなければならないことも多くあります。しかし、正社員の採用となると半年から1年ほどかけてじっくり進める必要があります。そういったときに、すぐ手を打てる手段としてビジネスパートナーの方に参画いただけるのは、とてもありがたい存在だと感じています。

——数あるパートナー企業の中で、ラクスパートナーズを選んでいただいた理由はありますか？

一つは人材をご紹介いただけるリードタイムが短いという点です。困ったときに、すぐに課題に合わせた人材を提案してもらえるというのは本当に助かりました。業務委託人材の方も活用させていただいておりますが、ご紹介いただく方のスキルや意識のばらつきがあり、マッチングが難しいと感じることも多いんです。

その点、御社から来てくださるエンジニアの方々は、皆さん意識がとても高いです。どうすればもっと良くなるか、今どんなスキルが求められているか、ということに対して貪欲にキャッチアップして取り組まれているという印象があります。単なるリソースの補充ではなく、チームの一員として、プロダクト改善にも主体的に関わってくれるというのは大きな魅力だと感じています。

——ありがとうございます。長くご一緒させていただいているフロントエンドエンジニアのTさんも、そういった形で関わらせていただいていますね。

そうですね。Tさんには現在、「情報を収集して分析する」プロセスを担当するチームに入っていただいています。最初は正直、「こんなことまでお願いして大丈夫かな？」と思うくらい、幅広く業務をお任せしていたんですが（笑）、非常に柔軟に対応していただいています。

特にありがたいのが、チームの改善活動にもしっかり向きあっていただけている点ですね。業務委託という立場だと、どうしてもチーム内で意見を言い出しづらい場面もあると思いますが、Tさんは「こうあるべきだ」という考えを発信してくれています。その業務への取り組む姿勢もあって、チームの改善活動にもすごく貢献してもらっています。Tさんに限らず、これまで参画してくださった他の方々も、同じレベルでチームに貢献していただいていると感じています。

——そう言っていただけて嬉しいです。Tさんは、TypeScriptやAWSなど、実務未経験でキャッチアップが必要な領域もあったと思いますが、スキル的な部分ではいかがでしたか？

TypeScriptについては、たぶんTさんが入った当初はそこまで経験がなかったと思います。弊社のAWS構成はサーバレスが中心で、さまざまな仕組みが複雑に絡んでいるのですが、その中でもしっかりとキャッチアップしていただき、早い段階で戦力になっていただけました。弊社の社員でも最初は戸惑うような環境なのですが、Tさんは粘り強く対応してくれて、スムーズに業務を進めることが出来ました。

——Tさん以外に、QAエンジニアも参画させていただきましたが、どのようにご活用いただけましたか？

メインプロダクトのリニューアルを進めていた時期がありまして、長年積み上げてきた分、機能数も多く、テストの工数が非常に多くなっていました。PMがひとりで対応しきれる量ではなかったので、スポット的にQAエンジニアの方を入れていただきました。テスト戦略から一緒に考えて、自立的に動いていただけたので、PMからも「本当に助かった」と聞いています。

——こうした実務未経験のエンジニアを受け入れることへの不安はありませんでしたか？

最初は、正直不安でしたね。Tさんも、前職が不動産業界というまったく違う畑の出身の方だったので、ほんとに大丈夫かなって（笑）。でも、やっぱりスキル以上に大事なのは「姿勢」だなと思っています。ビジネスの状況もどんどん変わっていく中で、それにどう適応していくか。そういう意味では、御社の方は皆さん気持ちの面が強く、キャッチアップ力も高くて、自走できる方が多いと感じています。

——社内でも通用する水準だという評価をいただけるのは弊社としても、とても嬉しいです。

そうですね。細かい作業をお願いすることもありますが、そういった部分もきっちり対応してくださっているのがありがたいです。たぶん、社内での育成がとても丁寧なんだろうなと思います。正直、どうやって育てているのか、こちらが知りたいくらいです（笑）。

これからのエンジニアに求められるのは“技術＋ビジネス”の視点

——今後のエンジニア組織づくりにおいては、どのような課題があるとお感じですか？

プロダクトが成長するにつれて、人手が足りていないところが各所で出てきていまして、情報収集の分野でも「もっとこういうデータもほしい」といった要望が増えてきています。それに応じてチームも拡大している状況ですが、それを管理するマネジャー層は不足しています。

——現在はどのような方針でマネージャー層の確保に取り組んでいるのでしょうか？

できる限り、社内で育成する方針をとっています。現場で活躍しているメンバーをマネージャーに引き上げていくというかたちですね。もちろん、外部から採用することも選択肢のひとつですが、そればかりになると社内のキャリアパスが閉ざされてしまう可能性がありますので、内部育成を軸に考えています。

——育成が進む一方で、現場のリソース不足にはどう対応されているのでしょうか？

そこは、まさにパートナーの方々に頼らせていただいている部分です。
マネージャーに引き上げる人材が現場を離れることになるので、その分のポジションをカバーできる人が必要になります。現場の層を厚くするという意味でも、御社のようなパートナーさんに支えていただいているのは非常にありがたいですね。

——この先、どのようなエンジニアが求められていくとお考えですか？

これからは“技術力”だけでなく、“ビジネス視点”を持ったエンジニアがより重宝されると思っています。ものを作るだけでなく、「この機能はなぜ必要なのか」「誰のどんな課題を解決するのか」といった付加価値や課題解決にフォーカスして、セールスともちゃんとコミュニケーションをとれる人材が、これからのエンジニアリングの中心になっていくと思います。

昨今のAIエージェントは、今はまだ簡単なコード修正レベルですが、いずれアーキテクチャ設計から実装まで、すべて自動でできる時代が来ると思っていて、そのときに人間に求められるのは、「お客様が何に困っているかを把握し、それをどうAIに伝えれば解決できるのか」を判断する力になります。なので、ソフトウェアエンジニアリングの技術力はもちろん大切ではありますが、今後はビジネス視点をもって課題を解決できる力のほうが重要になってくると思います。

——最後に、一言いただけますか？

昔はエンジニアというと、情報工学を専攻してた人が多かったんですけど、今は全然違う業界から転向してくる人も多くて、実際に、前職が不動産業界だったり、旅行業界の方もいます。大事なのは、論理的に物事を考え、建設的に取り組む力です。技術力ももちろん必要ですが、それ以上にビジネスやチームの課題に対して前向きに取り組める人が、これからのエンジニアとしてより活躍できると感じています。