シリーズB調達後の転換期に挑む。VPoE×テクニカルリード対談：技術組織の今とこれから - シェルパ・アンド・カンパニー株式会社　エンジニアブログ

なぜ今、この対談なのか

こんにちは。採用担当の多田です。シリーズB・ファーストクローズの資金調達を終えたシェルパは、事業の急成長を支える技術組織も、いま大きな転換点を迎えています。

「組織のフェーズも、事業のフェーズも、これまでとはまったく違うステージに入ってきた」と話すのは、共同創業者VPoEの小川。一般的にシリーズB以降は、プロダクトマーケットフィットをある程度達成したうえで、再現性ある成長が強く求められるフェーズ。シェルパも例外ではなく、T2D3（2年で3倍成長を2回、その後3年で2倍成長を3回）という高い成長目標に向けて、技術組織の役割がますます重要になってきています。

今回は、このタイミングで技術組織として何を考えているのか、どこに向かおうとしているのか。小川とテクニカルリードの上野に、率直に語ってもらいました。

現在の技術チームの姿：スクラムをあえて選ばない理由

――現在のチーム体制について教えてください。

小川：我々はチームトポロジーに基づいてチーム体制を組んでいます。開発工程はアジャイル開発を採用していますが、一つの特徴として、スクラムをやっていません。今の時代としては珍しいかもしれませんね。

上野：新規サービスを継続的に磨く文脈だと、スクラムの型に入りきらない場面に直面することが多いです。僕らは「ステークホルダーにコミットメントをもらって次のスプリントに進む」より、こちらから提案して価値を実装していくことが多い。そういう文化だと、スクラムを“あえて回す”必然性があまりないと感じています。

一方で、承認ゲートが明確な受託開発や大規模案件では、スクラムがとても機能しやすいです。大きなウォーターフォールで失敗しがちなところを、小さな合意の連続で進められるのが強みです。だからこそ、“状況依存で手法を選ぶ”のが正しいと思っています。

小川：わかります。僕の整理では結論はシンプルで、今の事業フェーズにおいてスクラムは必要条件ではないと考えています。もちろんスクラムはルールが明確で、不確実性の低減や見積り（ベロシティ管理）に効くフレームワークです。ただ、僕らは意図的に“計画されたカオス”を許容しています。

なぜか。日々お客様と強く接しているので、外部環境や要望で優先度が数日単位で大きく入れ替わるんですよ。2週間スプリントの3日目により優先度の高い要望が来ても柔軟に対応したい。このスピード感では、ルールが強すぎる運用は逆に摩擦になります。

現状の多くのチームでは、短サイクルでの方針転換に強い、裁量の大きい進め方を選んでいます。重要なのは手法そのものより、「今、本質的に何をやるのが最もレバレッジが高いか」を各自が考え、主体的に動くこと。そのために、各チームにリードエンジニアを配置し、意思決定と進行の軸を作っています。

直近の大きなチャレンジ：組織化とカルチャー形成

――組織的な取り組みについて聞かせてください。

小川：シリーズB以降、プロダクトもメンバーも一気に拡大します。今はまさに“成長の痛み”が出やすい局面。だからこそ、他チームの前進を阻む摩擦をいかに減らすかを最優先に置いています。Enablingチームは、その摩擦を取り除き、スケールしても速度を落とさない土台をつくることがミッションだと考えています。

上野：小さなチームと小さなソフトウェアで成立していた成功パターンは、規模が大きくなるとそのままでは破綻する箇所が必ず出る。私たちの役割は、その“成長の痛み”を先回りで緩和し、スケーラビリティを設計で担保すること。プロセス整備やプラットフォームの標準化、ナレッジの見える化など、速度と品質を両立させる仕組みを入れていきます。

小川：もう一つの大きなテーマが、「組織化」と「カルチャー」です。これまでのシェルパを振り返ると、良くも悪くも“強い個の集まり”だった時期があったと感じています。各メンバーが高い専門性を持ち、それぞれのプロダクトを力強く牽引していたため、事業は順調に進み、大きな問題も表面化しづらかった。しかし、組織の規模が一段階上がった今のフェーズでは、そのやり方だけでは限界が見えはじめています。

上野：個の強さはシェルパの資産ですが、今後は「チームが単位」です。所属する意義や誇りが感じられる共通言語・共通作法をつくり、個の強さをチームの再現性に変換する。カルチャーは自然発生を待つものではなく、意図を持って設計し、仕掛ける対象だと考えています。

小川：実際、採用は積極的に進めています。人こそ最大のレバレッジだと考えています。併せて、カルチャー醸成のために“フックや仕掛け”を増やすつもりです。具体の形式はチームごとに最適化しますが、ねらいは共通で、

自律性を支える共通基盤（決めごとの最小集合）
学習の循環（知の共有・フィードバックの標準動線）
意思決定の透明性（判断軸の明文化）を整えること。

個の裁量を削らずに、組織としての一貫性を上げるのが狙いです。

上野：その延長に、今期の大きな山として「基盤更改」※（プラットフォームを次の段階へ押し上げる節目の取り組み）があります。これは単なる技術案件ではなく、文化の器を拡張する組織的チャレンジ。共通基盤を通じて、各チームの標準が自然と揃い、スピード・品質・安全性の土台が一段上がるはずです。

小川：要するに、文化＝日々の選択の積層です。仕組みと採用、そして現場の意思決定を通じて、スピードを落とさずにスケールする文化へ移行する。個の強さを土台に、“チームとしての強さ”を設計していくのが、今のフェーズの本質だと思っています。

技術的チャレンジ：基盤更改への挑戦

――基盤更改について教えてください。

小川：「摩擦を減らす」の延長に、今期の大きな山として基盤更改があります。まさに全社横断のチャレンジですが、上野さんは今のタイミングや進め方をどう見ていますか？

上野：踏み切るタイミングとしては最高だと考えています。規模がここまで大きくなり、複雑さも増した今、いちばん難しい領域に正面から手を入れる決断は評価すべき点です。しかも、各チームに抵抗感がない。「複雑なものがシンプルになるなら乗りたい」と全員が前を向いている。これは大きな推進力です。

小川：大枠の方向性やレールは私が提示し、技術詳細は上野さんが詰める。そのうえで各ストリーム（機能横断チーム）にレビューしてもらい、フィードバックを回しながら滑らせるのが基本の動きです。みんな素直に前向きで、議論が建設的に進むのがありがたいですね。

上野：技術面の不安はほとんどありません。直感や慣習に頼らず、アルゴリズムと数理論理（述語論理）に基づく設計で進めているからです。正しさと性能の根拠が用意できるので、自信を持って意思決定できます。データベース基盤の刷新チームを率いるリーダーも、前向きで誠実、わからないことは「わからない」と明言できる方。コミュニケーションが透明で、仕事が進めやすいですね。

小川：我々はエンタープライズ領域で戦っています。だから開発しやすさとスケーラビリティはもちろん、信頼性・保守性・顧客要件の充足までを見据えてミドルウェアやアーキテクチャを選定しています。

一方で、難しさもはっきりしていて、事業の成長速度を落とさずに、既存の機能開発と改善を回しながら基盤を刷新する。これは非常に難易度が高い。それでもシリーズB前後の今こそが再構築の最適機会だと判断し、人と時間の投資を強くコミットしました。

上野：現場の温度感もいいですね。新しい技術要素のキャッチアップに前向きなメンバーが多く、ワクワクしている空気がある。標準化と単純化で日々の開発負荷が下がる未来像が共有できているのが大きいです。

小川：要は、スピードを落とさずに器を広げる取り組みです。日々の価値提供を止めず、中長期の競争力を底上げする「二兎」を同時に取りにいく。そのための仕組み・人・時間への投資を、今、着実に進めています。現場の前向きさには本当に感謝しています。

上野：この刷新を通じて、複雑さを管理可能な単位に分解し、再現性のある開発速度をつくる。結果として、品質・安全性・拡張性の土台が一段上がるはずです。ここからが、本当の意味でのスケールのフェーズですね。

経営層と現場の距離感

――エンジニアから見て経営レイヤーはどう見えていますか？

小川：組織・カルチャーや基盤更改に加えて、経営と現場の距離についても率直に聞いてみたいですね。エンジニアから見て、我々経営レイヤーはどう映っていますか？

上野：まず、シリーズB到達は素直に驚きと納得がありました。基盤更改には相応の投資が必要ですが、実際に人材採用と基盤への大胆な投資に踏み切っています。

もしこの規模で「採用も基盤更改もしない」だったら現場は不安になりますが、いまは成長戦略に沿って資金を使っているのが見えます。むしろ「そんなに採用して大丈夫？」と現場側が心配になるくらい前のめりで、ポジティブに受け止めています。

小川：ありがたいです。とはいえ今はまだトップダウンの意思決定も多いフェーズです。現場の裁量や自由度はどの程度あると感じていますか？

上野：十分にあります。具体的には、

採用委員会を通じた現場参加：候補者との対話や評価に現場が関与するので、入社後のズレが少ない。
意思決定の透明性：知らない経路で突然人が増える、ということがない。プロセスが見える化されています。
負荷分散の前提設計：サブシステム化とチーム編成で、リードの負荷を構造的に減らす方向に舵が切られている。

この3点が距離を縮める“実装”になっていると感じます。

小川：トップで方向性と資源配分を決めつつ、現場には裁量と自律性が残る構造にしたい。基盤更改も同じで、方針は経営が握り、技術詳細は現場が設計してレビューで擦り合わせる。その結果、スピードを落とさずに前へ進めている実感があります。

上野：ええ。現場の空気は前向きですし、投資の意図が伝わっているから納得して動ける。採用・基盤・組成の三位一体で、「距離」をコストではなく競争力に変換できているのが今の状態だと思います。

小川：最終的には、距離＝信頼と情報の密度だと考えています。意思決定のスピードを保ちながら、現場の判断を尊重し、透明なプロセスで往復運動を増やす。
このリズムをもっと太くしていきたいですね。

上野：同意です。このリズムが続けば、採用の質とオンボーディング、そして日々の意思決定までが一本の線でつながる。結果として、経営目線の“Why”と現場の“How”が近い状態が維持できます。

オンオフを意識した働き方

小川：直近の課題感や「ここはもっと良くできる」という点、どう見えていますか？

上野：いまはどうしてもリーダーに負荷が集中しがちです。採用を進めて各ストリームにメンバーを増やし、責務を段階的に委譲できれば、全体のスピードはさらに上がるはずです。極端な例ですが、“200%の生産性の個人1名”より、“70%×5名＝350%”のチームの方が持続的に強い。リーダーに余裕が生まれれば、組織はもっと回ります。

小川：実務面では、夜間にSlackが大きく動くことはほぼない印象です。リリースはB2B/エンタープライズの事情で夜間運用が多いですが、それ以外はメリハリを重視しています。

上野：そこは良い文化だと思います。人間の集中は50〜90分程度で切れるという研究もあり、時間を区切って休憩を挟む前提で8〜9時間に集中する方が健全だと思います。期限が明確なものは責任を持って残業対応する一方、そうでなければきっぱり終える——このメリハリは現場でも定着しています。

小川：就業時間のベースはフレックスとはいえ多くが10時〜19時。19時以降、特に20時以降はSlackでメンションして仕事を振らないという空気感が自然にできているかと思います。平均年齢がやや高めという事情もあり、サステナビリティや個々の生活・関心へのリスペクトが根づいていると感じます。

上野：同意です。採用が進めばリードの負荷分散が進み、オン・オフの切り替えもさらに良くなる。結果としてチームの総量と継続力が上がるはずです。

小川：まとめると、オン＝集中の密度、オフ＝回復と生活の質。この両輪を守りながら、権限移譲と採用で負荷を平準化していく。これが今のフェーズでの“強い働き方”ですね。

今後の採用方針：多様性と柔軟性を重視

――どのような人材を採用していきたいですか？

上野：挑戦することに対して柔軟な姿勢を持っている方とご一緒したいと思っています。特に、成長意欲の高い若手や、これまで異なる環境で経験を積んできた方々と働くことで、チームとしても新しい刺激や学びを得られると感じています。技術的な変化に前向きに対応できる方が、シェルパのような変化の激しい環境にはとてもフィットすると思います。

小川：これまでは即戦力中心でしたが、今後はより柔軟に、若手からミドルの方も積極的に採用したいと考えています。各チームにリードクラスのエンジニアがいるので、実践しながら学べる環境は整っています。ベテランだけだとバイアスが入りがちなので、若い方のフレッシュな発想や成長意欲はチームに刺激を与えてくれると思います。

AI活用への積極的な取り組み

――AI活用についてはどのような状況ですか？

小川：いま外せないトピックはやはりAI活用。現状、開発現場での使い方や手応えをフラットに教えてください。

上野：とても前向きにフル活用しています。開発では、

PRのレビューをAIで多層チェック（コード提案／説明補足／論点指摘）。
PR差分からのテスト観点提案（どこをどの程度テストすべきかのヒント出し）。
多言語対応はドメイン日本語→各言語へ一括変換して下訳を作成（約30言語規模）。

AIは、使うほど指摘の質が上がっており、“AIに任せられる所は任せる”が基本姿勢です。シェルパでは生成AIの業務利用ライセンスも付与され、日常的に支援ツールとして浸透しています。

小川：会社としても継続投資をコミットしていますし、現場もキャッチアップ→試行→定着のサイクルを回しています。必要な支援は組織として用意します。

加えて、AI活用はエンジニアリングだけに閉じず、オペレーションやバックオフィスの生産性にも広げていきたいと考えています。エンジニアが全社横断のAIリード役になるイメージです。

上野：実務面ではAIの得手不得手もはっきりしています。コードや文書の生成・校正は強い一方、業務を正しくモデル化する設計（データモデル、述語論理に基づく抽象化）はまだ弱い。だからこそ、モデル化は人間の役割として残り、AIは作業の自動化・補助に徹する——この役割分担が現状の最適解だと考えています。

小川：まさに人×AIのハイブリッドですね。短期の生産性はAIで引き上げ、中長期の競争力はモデルと設計で担保しています。

上野：それと、AI活用は学習コストの先払いが効きます。標準プロンプトやレビュールール、翻訳の用語集などを共通資産化しておくと、再現性のある効率化になります。
結果としてレビューの深さは維持したまま、スループットが上がります。

小川：グローバル展開も視野に、多言語・多リージョンでの作り分けが今後の論点になります。AIはその運用とローカライズに効く一方、各地域の要件差をどうモデルに折り込むかは人間の設計領域。そこは丁寧に詰めていきたいですね。

上野：最終的には、AIを“現場の当たり前”にすること。作業はAI、意味づけと設計は人。この分業を前提に、標準化・用語集・プロンプト資産・レビューチェックリストを整えて、全社でのAIリテラシーを底上げしていきます。

小川：採用・基盤・文化に続く第四のレバーがAIですね。スピードと質を同時に引き上げる仕組みとして、これからも投資と展開を進めていきます。興味のある方は、ぜひ全社横断のAI推進にジョインしてほしいですね。

Enablingチームの拡張戦略

――Enablingチームの今後の拡張についてはいかがですか？

上野：数学的・論理的な基盤を共有できる人材が欲しいですね。概念／論理／物理までモデル議論が破綻せずに成立するレベルで会話できることが重要です。そういう方が入ると、単に「手を動かす」以上に知のレバレッジが効き、設計の再現性が一気に上がります。

小川：前提として、Enablingチームは積極的に拡張します。役割は二層で、

現場の下支え（摩擦の除去・標準化・プラットフォーム化）
知の抽出と社内インストール（ナレッジを形式知化し横展開）

特に我々はサステナビリティ/ESGのプラットフォーマーを目指す以上、将来的にはデータプロダクトが中核になります。よって、

データモデリングのスペシャリスト
データベース／データレイク／大規模処理のスペシャリスト
AI適用（生成/評価/運用）のスペシャリスト

など、専門性の異なる“セル”を束ねる複数ユニット型での拡張をイメージしています。
一本の巨大チームに“縦積み”するより、小さく強いEnablingセルを複数配置し、各ストリームに刺さる専門性を提供する形が合うと考えています。

小川：まず大前提として、サステナビリティ/ESGへの関心と基礎知識は全社員の評価項目に入れています（会社の方針として明確化）。その上でEnablingは、各ストリームのドメインと密接に関わるので、必要な領域は自らキャッチアップして体得していく前提です。ドメインを理解しないとより良いモデリングや助言ができません。つまり、技術×ドメインの“バイリンガル”が理想像。最初から100点でなくても、関わるチームに合わせて迅速に学習する習慣は必須です。

まとめると、拡張の方向は複数ユニット化したEnablingセルで、専門性とドメイン理解を兼ね備えた人材を核に据える。知を形式化して全社にインストールし、ストリームに最短経路で価値を届ける。これが次フェーズのEnablingのあるべき姿だと考えています。

今ジョインする意味：転換点だからこその機会

――なぜ今シェルパに入ると良いのでしょうか？

上野：正直に言うと、ストックオプションの期待値がすごく高まっています（笑）。技術的に楽しいと思って入ったのですが、まさかここまで大きく成長するとは思っていませんでした。まさにシェルパに入るのであれば「今が絶好のチャンス」という感じですね。

小川：シェルパは全株式の15%をストックオプションのプールとして設定しており、これは一般的なスタートアップより多い設定です。また、持ち出し可能という従業員フレンドリーな設計にしています。

技術的な面白さで言うと、今のフェーズは0→1のプロダクトも1→100の既存プロダクト拡大も両方経験できる。基盤刷新もがっつり進めているので、プロダクトエンジニアとして、お客様にとって何が価値があるかを考え、フロントからバックエンドまで一気通貫して開発に関われる裁量の大きさがあります。

当社のSO制度について（参照：https://cierpa.co.jp/recruit )

サステナビリティ × テックカンパニーとしてストックオプションに込めた思い｜シェルパ・アンド・カンパニー株式会社

AIが進歩しても変わらない価値

――AI技術が進歩して組織はどうなると思いますか？

上野：私自身、Codexなどを利用しPRを挙げる作業までAIに任せる事も多々あります。体感としては“AIが書き、人が通す”フローが当たり前になりつつあります。そのとき人間に必須なのはファクトチェック力です。

AIの出力は強力ですが100%の保証はできないし、ハルシネーションも起こりうるので、コードもモデル設計も、検証できるかどうかが要です。AIで自動化→人が検証・責任を取るという役割分担が決定的に重要です。

小川：AI時代に入り「エンジニアは減っていくのでは？」という声もありますが、私たちはむしろ必要なエンジニアの数は増えていくと考えています。

OpenAIのサム・アルトマン氏も、「私たちは、世の中に必要とされるソフトウェアの量を過小評価していた」と語っています。AIの進化によって、コーディングという作業自体は効率化されていきますが、その分、ソフトウェアが生まれるスピードや量が飛躍的に増える。結果として、それらを構想し、形にするエンジニアの役割はこれまで以上に重要になっていくはずです。

私たちのような企業規模では、まだまだ作るべきものが山ほどあります。プロダクト開発だけでなく、社内業務を支える仕組みや他職種を支援するソフトウェアなど、AIを活用しながら生産性を高め、「攻める開発」ができるチームを目指しています。