さいき

2026年6月回 指名


まだ何もありません

あなたを気にしている企業

  • TRUSTDOCKがさいきのレジュメを見ています。
    2026.06.26
  • グロービスがさいきのレジュメを見ています。
    2026.06.26
  • エス・エム・エスがさいきのレジュメを見ています。
    2026.06.26
  • SODAがさいきのレジュメを見ています。
    2026.06.26
  • ログラスがさいきのレジュメを見ています。
    2026.06.26
  • movがさいきのレジュメを見ています。
    2026.06.25
  • enechainがさいきのレジュメを見ています。
    2026.06.25
  • BuySell Technologiesがさいきのレジュメを見ています。
    2026.06.25
  • Works Human Intelligenceがさいきのレジュメを見ています。
    2026.06.25
  • ポピンズシッターがさいきのレジュメを見ています。
    2026.06.25

キャリアビジョン


品質保証を越えて、品質が低いものが生まれる前に消し去りたい

良いものを世に出すために、強くてしなやかな組織を作りたい。仕組みから改良、改善していく存在なりたいです。 プロジェクトや組織に課題があると品質低下がしやすくなると考えています。メンバーと同じ方向を見て、良いモノづくりができるように、全体を支援していける存在になりたいと考えています。

プロジェクト経験

2025年/1年以内

新規プロダクトビザスクdirect開発

## **プロジェクト概要** ビザスクdirectの新規開発および既存ビザスクLiteのリプレイスで、市場拡大を目指した自社プロダクトのクオリティマネジメントを担当しました。 ## **役割・体制** ### 自身のポジションと役割 - メインQAエンジニアとして、プロジェクトキックオフからリリース後の運用まで品質管理とプロジェクト管理を一貫して担当しました。 - 品質方針の策定、機能ごとのレビュー、要求仕様書およびデザインレビューの実施、テスト項目書の作成とレビュー、不具合管理および起票、テスト実施者のキックオフミーティング主催、テスト実行スケジュール管理を実施しました。 - QAチームの拡充に伴い、メンバー教育やテスト実施者との連携強化にも注力しました。』 ### チーム規模と構成 - プロジェクト全体ではPM4名、新規プロダクトチーム2名、既存プロダクトが大きく分けると2つあり改修チーム各1名が参画し、エンジニアは各チーム3名から10名程度在籍していました。 - QAは当初1名体制で開始し、最終的に3名体制に拡大し、テスト実施者として他部署から約10名が参加しました。 ## **背景・課題** - ビザスクdirectの新規市場開拓を目指し、既存のビザスクLiteからのリプレイスを実施する中で、品質を確保しつつ開発を進める必要がありました。 - スケジュール設定が初めから不適切で、納期が先に決まっていたため、作りたいプロダクトの要件が明確化されていませんでした。 - 工数不足とプロダクト横断的なスケジュール調整を行える上級PM不在のため、プロジェクト全体のコントロールが困難な状況でした。 - 品質方針が開始時に個人に委ねられていたため、統一的な品質管理体制の欠如が課題でした。 ## **実際の取り組み** ### 開発環境 - ウォーターフォール開発手法を採用し、段階的に要件定義、設計、テスト計画と実施を進めました。 - ドキュメント自体やテスト設計標準化を図り、品質管理の属人化を防止しました。 - 専門職ではないテスト実施者が質の高いテストを安定して実施し、バリューを発揮できるよう、密なコミュニケーションを促進するため、キックオフミーティングや判断に迷ったら即相談できる環境を構築しました。 ### 設計・改善内容 - 曖昧な作業指示やスケジュールの不明確さを解消するため、実際に作業した時間や成果物を根拠に工数見直しを実施しました。 - プロジェクト責任者と連携し、現実的なスケジュール進行と品質目標の設定を行い、着地点を明確化しました。 - 不具合管理プロセスを整備し、起票から解決までの流れを可視化して迅速な対応を実現しました。 - テスト項目書の綿密な作成とレビュー体制を確立し、結合テストの品質を向上させました。 ### その他アピールポイント - 開発チームやPM関係する他部署との橋渡し役として、法務的な問題やプロジェクト進行に影響する品質に関する課題、リスクを早期に発見し、関係者間の合意形成を支援しました。 ## **成果・価値** - スケジュール通りにビザスクdirectをリリースし、お客様への影響を最小限に抑えつつ、プロダクト品質を確保しました。 - 品質方針の統一とプロジェクト管理の強化により、テスト工程の効率化と品質向上を実現しました。 - リリース後のクリティカルな不具合発生率の低減と運用フェーズでの安定稼働に寄与しました。 - 企画~リリース以降継続して、属人下の抑止、メンバーへのナレッジ共有に寄与しました。

2025年/1年以内

テスト管理ツールの導入

## **プロジェクト概要** 開発組織のテスト管理課題を解決するため、SHIFT社のCAT+TDツールの導入と運用によりテスト再利用とナレッジ共有基盤を構築しました。 ## **役割・体制** ### 自身のポジションと役割 - QAチームメンバーとして、CAT+TDツール導入に伴う意思決定、運用方針策定、アカウント管理、情シスへの管理移管、および運用中の問い合わせ対応とナレッジ共有を主導しました。 - 稟議や企業との直接連絡を除くすべての導入準備と運用体制の構築を担当し、円滑なツール活用を実現しました。 ### チーム規模と構成 - QAチーム3名体制で、協調しながらテスト管理ツール導入・運用に取り組みました。 - プロジェクト関係者にはQA以外に開発者や運用担当者も含まれ、多職種が連携する環境でした。 ## **背景・課題** - テスト再利用が困難でナレッジ蓄積がされず、自動化に必要な安定テストケースが不足している問題を抱えていました。 - テストケースのフォーマットが統一されておらず、記載内容が不足し、誰がどのように実施・作成したかの可視化も不十分でした。 - こうした状況がプロジェクト間の連携もできず情報がサイロ化され、過去に実施していても参考にされず、入社した方のオンボーディングや仕様を理解することの負荷を高めており、改善が急務でした。 ## **実際の取り組み** ### 環境 - 社内で1プロジェクトから他チームへ、そのチーム特性に合わせた柔軟な対応を行いました。 - テスト管理ツールを選定し、既存のテスト運用に適応可能な形で導入計画を策定しました。 ### 設計・改善内容 - 導入初期に稟議と企業との直接連絡以外のタスクを一手に引き受け、情報システム部門への移管を前提としたスケジュールで運用方針の策定と文書化、アカウント管理の設計・運用を実施しました。 - 情報システム部門へアカウント管理を円滑に移管するためのルール検討と手順確立を行い、移管完了までリードしました。 - 運用開始後に発生した質問や問い合わせに迅速に対応し、対応内容をナレッジとして共有する仕組みを構築しました。 - テストケースのフォーマット統一や記載ガイドライン作成により、テスト品質の標準化を促進しました。 ### その他アピールポイント - 不確実性を受け入れつつ最速で意思決定を行い、無料トライアル期間中にチームで合意形成を図ることで導入を迅速化しました。 - 移行のしやすさを重視し、利用開始時期の問い合わせや組織運用方針のカスタマイズにも柔軟に対応しました。 ## **成果・価値** - テストケースの集約により再利用が促進され、リグレッションテストにおけるテストケースの一部流用が可能となりました。 - 新規プロジェクト開始時に、テスト量や期間などの情報をチーム全員が同一のデータとして参照できる環境になりました。 - 各工程間の不具合や仕様不備の検出状況を明確に記録可能となり、振り返りや品質分析に活用されるようになりました。 - プロジェクト全体のテスト効率が向上し、規模の大きいプロジェクトにおける品質トラブルの早期検知と対応が可能となりました。』

2024年/3ヶ月以内

オンボーディング最新化

オンボーディングの既存部分アップデート ドメイン知識補足資料作成、エンジニアのオンボーディングへも活用されてきます。 オンボーディング用プロダクト横断ケース新規作成 オンボーディング進捗可視化シート作成 QAチームオンボーディングプロセス改善 QAチームオンボーディング更新仕組み化

2024年/1年以内

PR分析とチーム共有

ルール決め 初回実施を主導 QAチームの誰でも実施できるマニュアル作成 不具合分析ではなく、QAチームに来たタスク分析を実施 1年間の全プルリクをランク、理由などを決める 緊急度の高いもの、誤報であったもの、理由が解消されればランクが落ちるものなど、QAチームで簡単別に仕分け 分析結果を資料化し、期末に開発チームへ共有 期初から運用を変更 以降継続報告

2026年/3ヶ月以内

プロジェクトのコミュニケーションそのものをAIに分析させてみるプロジェクト

## **プロジェクト概要** Claudeを活用した品質可視化のためのデータ分析を推進し、成果を社内外に発信したプロジェクト。 ## **役割・体制** ### 自身のポジションと役割 - QAチームの主要メンバーとして、品質可視化に関するデータ分析の方針設計とプロンプト調整を主導。 - 生成AI技術であるClaudeやDevinを活用し、分析フレームワークの構築を担当。 ### チーム規模と構成 - QAチーム4名で構成され、構想から3か月程度で社内&社外公開するAI活用プロジェクトを推進しました。 ## **背景・課題** - 品質の低下にコミュニケーションの課題があると考えられ、隠れた貢献や成果を可視化することが求められた。 - データの指標選定やプロジェクトの適切な選定が難しく、十分なデータ量とログの存在が前提条件となった。 - 外部発信における情報の受け取り方や伝わり方に配慮し、社内外の関係者の理解を得る必要があった。 ## **実際の取り組み** ### 開発環境 - 生成AI技術のClaudeとDevinを利用してデータ分析を実施し、分析結果の精度向上に向けたプロンプトの継続的な調整を行った。 - アジャイル開発手法を採用し、短期間でのフィードバックループを確立しながら分析精度の向上に取り組んだ。 ### 設計・改善内容 - 分析フレームワークを他のチームでも活用可能な形で設計し、汎用性の高い指標体系の構築を目指した。 - 恐怖感を与えない可視化を心掛け、データの意味合いや結果の受け取り方に配慮しながら社内外への発信を行った。 - プロジェクトメンバーへドキュメントを共有し、感想や意見を収集。誰もが同様の指標で分析し、検討していける仕組みを構築した。 ### その他アピールポイント - テックブログで成果を公開し、社内外に貢献や見えていない行動の可視化の可能性を広く伝えたことにより、他チームでの振り返りやチーム分析の参考指標として活用される基盤を築いた。 ## **成果・価値** - 好悪や雰囲気に寄らないコミュニケーションの可視化により、定量的に分析可能な対象とする新たな指標を提示。 - プロジェクトメンバー以外の他チームでも振り返りや品質分析の場で参考にされるなど、組織横断的な品質改善活動への貢献を実現。 - 今後の標準的な品質分析手法として定着する可能性を示し、品質改善に向けた意識改革を促進した。

マネージメント能力

QAチーム5-15名をマネジメントしていました。
QAチーム自体を2.3人からビルディングする QAチームとして、情報共有がされそれが社内の価値となる QAでミッションビジョンを共有し、共感できるメンバーを採用する 社内プロダクトに対して、安定した品質保証体制を提供できるような基盤を整える 属人化をなるべく減らし、長く走り続けることが可能な状態にする 品質の考え方を開発組織に広げ、組織全体で品質向上をできる環境にQAチーム全体で取り組む 1on1を行い、チームの仕事がしやすい心理的安全性がある環境を維持する
チームメンバーと会話をし、些細な悩み、気になることを話してもらうことで問題にいち早く気がつけました。 1人が悩むことは他でも発生するのではないか?と考えチームで課題を解決していくよう後押ししました。 会社の空気が変化する中で、QAチームに求められる要望のコントロールは課題でした。 対話して着地点を擦り合わせることで進めていきました。

アピール項目


アウトプット

GitHub アカウント
未入力です
Qiita アカウント
あり
Zenn アカウント
未入力です
Speaker Deck アカウント
未入力です
SlideShare アカウント
未入力です
特にアピールしたいアウトプット
未入力です

今後、身につけなければいけないと思っている技術は何ですか?

交渉力 AIオーケストレーション

あなたが一番パフォーマンスを出せるのはどんな環境ですか?

これから新しく変化し、ルールも何もかも決めてとりあえず動いていける オフィスだと人と目が合わない、ざわつかない、背後に人の通らない集中力を維持しやすい静かな場所、自宅仕事部屋

生成AIの活用状況

日常的な情報収集・業務活用
ChatGPTやGeminiなどのチャットツールを、情報収集、ドキュメント作成、翻訳に日常的に活用
業務でコード生成、コーディングエージェント系の生成AIを利用
コードレビュー、テストコード生成、デバッグに生成AIを活用

キャラクター

直近で一番やりたいこと
サービスを作りたい
好きなスタイル
一人で黙々
どちらかといえば一人で黙々
どちらともいえない
どちらかといえばみんなでワイワイ
みんなでワイワイ
好きな規模
小さい会社
どちらかといえば小さい会社
どちらともいえない
どちらかといえば大きい会社
大きい会社
自信を持って人より秀でていると言える点
問題解決力 / 巻き込み力 / 人を集める力
スキルのタイプ
ゼネラリスト
どちらかといえばゼネラリスト
どちらともいえない
どちらかといえばスペシャリスト
スペシャリスト
得意なフェーズ
0 → 1
どちらかといえば0 → 1
どちらともいえない
どちらかといえば10 → 100
10 → 100
会社を選ぶ一番の基準
風通しの良さや意思決定ライン
やりたくない分野
SI
その他の特徴
新しい技術はとりあえず試す / 勉強会でLTをよくする / 趣味は仕事 / 多職種のバックグラウンドがある
その他のやりたいこと・やりたくないこと

変化が乏しい組織
フラットではない、心理的安全性が低い環境
気軽にディスカッション・ブレストが発生して欲しい
言われた範囲をこなすだけではなく、良いもの、どんな背景でどんなものを作っていくかを考えて動いていきたい

やりたい事

手を動かして設計してコードを書きたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
価値あるプロダクトを作り成長させたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
学び続けて技術力でプロダクトに貢献したい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
意義があることや社会に貢献できる仕事がしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
人や計画の調整・マネジメントをしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
レガシーなシステムの保守・運用・改善をしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
企画や仕様を考えるところから関わりたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
業務効率を改善して一緒に働く人のためになりたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
全社横断的な共通基盤作りや強化をしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
組織や文化を作る・成長させる仕事をしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい

基本プロフィール

年齢
今年で30代中盤
好きなテキストエディタ
サクラエディタ
希望勤務地
東京都 / リモート勤務
集まる必要性がない場合は基本リモートが許可される環境が必要
希望年収
1000万円
ご意見箱

要望、不具合報告、使いづらい点や感想など、お気軽にお寄せください。
いただいたご意見は、今後のサービス向上に活用させていただきます。

なお、このフォームは受付専用のため、返信を行っておりません。
返信を希望する場合はお問い合わせよりご連絡ください。

  • {{error}}
転職ドラフトを友人や同僚に薦める可能性はどのくらいありますか?