関連資料

• 会社紹介資料
• ビジネスグループ採用関連資料
• エンジニア向け会社紹介資料
• 新入社員オンボーディングに関する記事

※本ポジションは【2027年1月以降（または2027年度）の入社】を想定した先行採用枠です。 現在他社に就業中の方で、中長期的なキャリアチェンジをご検討中の方や、入社時期をご相談されたい方も歓迎いたします。

仕事概要

【会社・事業について】

私たちは、「“働く”にもっと『楽しい』を創造する。」をミッションに掲げ、建設業界のDXを推進しています。
建設業界では、需要拡大が続く一方で、人手不足や技能継承、長時間労働などの課題が深刻化しています。
私たちは、こうした社会課題に対して、テクノロジーによって現場業務の生産性向上を支えることを目指しています。
主力サービス「SPIDER+」は、施工管理領域において7万人以上のユーザーに利用されるプロダクトへと成長しました。
現在は、「SPIDER+ Workspace」構想のもと、施工管理にとどまらず、情報共有・労務安全・資機材管理など、現場業務全体を支える“現場の統合プラットフォーム”への進化を進めています。
また、「現場インフラ」として業務プロセスに深く浸透するプラットフォームを目指し、エンタープライズ企業への導入拡大や、AIを活用した開発プロセス改善など、次の成長フェーズに向けたプロダクト / プラットフォーム強化を推進しています。

【仕事概要】
担当プロダクトの品質責任者（Product Quality Manager）として、品質に責任を持っていただきます。
品質を何で測るかを決め、開発の成果物と過去の障害データから壊れやすさと品質を予測して、テストの範囲と厚みを配分する。予測が当たっていたかを実績で確かめて精度を上げる。この循環で、品質保証にかけるコストと時間、そして達成する品質水準をコントロールします。
テスト計画から設計、実行までの大部分はAIと自動化に移します。各工程の基準とそれを実現するロジックは社内の資産として保持し、外部に開くのはオペレーションに限っていきます。この境界の設計も担っていただきます。

【ミッション】
業務で使うプロダクトの品質を守り続けること。そのために、品質保証を出来上がったものを検査する仕事から、品質を予測してコストと時間まで制御する仕事へ変えること。

業務内容

■ 品質目標の設定と、予測にもとづくテスト配分
・担当プロダクトの品質目標と、それを測る指標の設計
・開発の成果物と過去の障害データを分析し、どこが壊れやすいか、壊れたら何に響くかの予測
・予測にもとづいてテストの範囲と厚みを配分する。肥大化したシステムテストを棚卸しし、単体・結合テストへの移行
・機能とテストケースの紐付けを整備し、テスト資産の管理

■ 予測精度の検証と改善
・領域ごとの不具合の出方を可視化し、変更履歴と突き合わせて、効いているテストと不要なテストを分ける
・厚みを削った領域を追跡し、予測を更新する
・品質ダッシュボードで可視化し、開発チームと経営に報告する

■ テスト業務のAI化と、社内資産と外部提供の境界設計
・テスト計画、設計、テスト生成、影響範囲分析、障害分析をAIエージェントに移す
・テスト技法を指定したAI生成の設計と、生成結果の品質を担保する
・各工程の基準とそれを実現するロジックを社内の資産として蓄積し、外部に開く範囲との境界を設計する
・外部パートナーが安全に運用できる形にする。権限の設計、安全ゲート、手順を標準化する

■ リリース判定と外部テストパートナー体制
・リリース判定基準の運用と、テスト密度や不具合密度のデータにもとづく合否判断
・AIと自動化のオペレーションを担う外部テストパートナー体制の立ち上げと、品質とコストと時間の管理
・開発チームへのシフトレフト支援。テストしやすい作りへのフィードバックと、単体・結合テストの整備支援

入社後まずお任せしたい業務・ミッション

■ 最初の3ヶ月：リリース判定を担いながら、判断の材料を揃える
・障害データ、テスト資産、これまでのリリース判定の実績を読み、担当プロダクトの品質リスクを把握する
・把握したリスクをもとに品質を予測し、実際に起きたことと突き合わせて、予測の当たり方を確かめる
・AIに移しているテスト業務の稼働データを取得し、生成AIがどこで使われ、どこで人が直しているかを可視化する

■ 3〜6ヶ月：揃えた材料で、中核の業務フロー1本に循環を通す
・確かめた予測をもとにテスト配分を運用に載せる。効いていないテストは削り、予測の精度が確かめられた領域からリスクを取る範囲を広げ、その結果に責任を持つ
・リリース判定の基準を、予測と実績にもとづくものへ作り替える
・可視化したAIの稼働をもとに改善を進め、適用を担当プロダクト全体へ広げる

■ 6ヶ月以降：実証した型を広げ、品質保証の形を変える
・予測と実績の循環を毎リリースで回し、目標の品質を保ったまま、品質保証にかけるコストと時間を実際に下げる
・どこまでAIに任せられるか、その限界を追求し、外部テストパートナーに委ねたオペレーションを無人へ近づける
・AIによる品質保証を開発プロセスへ溶かし込み、後工程で検査する仕事を減らしていく。（行き着く先は、独立した検査工程としての品質保証がいらなくなる状態）

必須スキル

• テストエンジニア、QAマネージャー、開発エンジニアの実務経験が合計10年以上。(テスト戦略とテスト計画の設計を主導した経験を含む)
• プロダクトやプロジェクトの品質に責任を持ち、品質水準とコストの判断をした経験
• リスクにもとづいてテストの範囲と優先度を決めた実務経験
• テスト技法にもとづくテスト設計の実務経験と、その品質を評価できる力。同値分割、境界値分析、デシジョンテーブル、状態遷移など
• JSTQB または ISTQB の Advanced Level テストマネージャ相当の知識。（資格の保有が望ましい）
• 生成AIを実務プロセスに組み込み、運用した経験。プロンプトやエージェントの設計、生成物の品質評価、業務への定着を主導していること
• データ分析を設計から意思決定まで自分で回した経験。分析の目的から指標を設計し、SQLやPythonでデータを取得・分析し、判断につなげた実績
• 統計の基礎知識。分布とばらつき、相関と因果の区別、検定や回帰をデータの読みに使えること
• BIツール※でのダッシュボード構築、運用経験。※Tableau、Looker Studio、Power BIなど
• 品質リスクを開発チームと経営層に説明し、合意を形成できるコミュニケーション力

歓迎スキル

• LLMを使ったアプリケーションやエージェントの開発、評価の経験
• セキュリティテストエンジニアとしての知見

求める人物像

• 品質を検査ではなく、コントロールの対象として捉えられる方
• 品質とコストと時間のトレードオフで判断し、その結果に責任を持てる方
• 予測を根拠に、何をテストしないかを決められる方
• 自分で手を動かすことより、AIと外部体制に実行を委ね、状況判断とプロセス・組織の設計に時間を使うことを選べる方
• データで品質を語り、勘でテストを増減させない方
• 開発チーム、外部パートナー、経営層と立場を超えて対話し、開発者が不安を正直に言える関係を築ける方
• 品質保証とAIの組み合わせという型がない領域で、自ら試して型をつくれる方

このポジションについて

魅力

■事業インパクトの大きさ

・建設業界はDXがまだ進んでおらず、市場としての伸び代が大きいです
・その中で建設現場のインフラへ成長している、7万人が日々の業務で使うプロダクトの品質に、自分の判断が直結します
・また品質保証のコスト構造を変えることが、そのまま事業の利益に効きます

■仕組みをつくる面白さ
・ 指標の設計から予測、AIへの移行、外部体制の設計までを自分で決められます
・品質判断をAIに載せる取り組みは方法論が確立していない領域で、その型をつくる側に立てる
・テスト業務をAIに移す取り組みはすでに動いている。ゼロからではなく、動いている土台の上で限界を攻められます
・Claude Code、GitHub Copilot等の有償AIツールを全社負担で利用できます

■高い裁量 ・OKRを自ら提案し、合意のもと、細部の判断は一任されます。立ち上がりはメンバーが伴走します。

身に付くスキル

■予測にもとづく品質の意思決定
何を測れば品質が分かるかを設計し、開発の成果物と障害データから壊れやすさを予測して、テストの範囲と厚みを決める力が身につきます。全件を均等にテストするのではなく、根拠を持って削る判断ができるようになります。

■テスト業務のAI化と、社内資産の設計
テスト計画から設計、実行までをAIに移す設計と、各工程の基準とそれを実現するロジックを社内の資産として残す設計の経験を積めます。何を外に開き、何を残すかを決める判断は、他社でも応用の効く経験になります。

■品質のコストと時間の管理
目標の品質を保ちながら、品質保証にかけるコストと時間をコントロールする実務が身につきます。

■外部体制のマネジメント
AIと自動化のオペレーションを外部パートナーに委ね、品質・コスト・時間を管理する経験を積めます。

雰囲気・特徴

■データと基準で議論する文化
品質の判断は、感覚や声の大きさではなく、データと基準で議論します。

■人は判断と設計に時間を使う
定型業務はAIと自動化に任せ、人はリスクの判断、設計、関係者との合意形成に時間を使います。

■失敗を責めない文化
予測が外れることも、テストを削った領域で不具合が出ることもあります。それを個人の責任にせず、予測と仕組みを直す材料にします。開発者が「ここが不安」と正直に言えるのも、この前提があるからです。

■検査ではなく、開発と一緒に潰す
品質部門が最後に検査するのではなく、開発と一緒に早い段階でリスクを潰します。

組織体制

■ 報告・連携関係
・直属上司：プロダクト品質部長
・開発チーム：品質目標とテストの配分をすり合わせ、リリース判定を運用する相手。テストしやすい作りへのフィードバックや単体・結合テストの整備など、シフトレフトを一緒に進める
・外部テストパートナー（オフショア）：AIと自動化のオペレーションを担う実行体制。テスト計画と設計を渡し、品質とコストと時間を管理する
・そのほか、SRE、CRE、CSと連携

■ チーム構成
・QAエンジニア4名（2026年8月時点）
・テスト実行を担う外部テストパートナー

■ 意思決定権限
・担当プロダクトの品質目標と、テストの範囲と厚みの決定
・リリース判定基準の運用と合否判断
・テスト業務のAI化の進め方と、外部に開く範囲の設計

キャリアステップ

・品質責任者( Quality Manager)
・品質部　部長
・CQO