はじめまして。2025年11月にエス・エム・エスへ入社した岡本です。入社後は、カイゴジョブエージェントの開発チームでエンジニアとして働いています。 この記事では、これまでやってきたことを少し振り返りつつ、入社してから見えてきたことを書いてみます。 あわせて、今チームで進めていることや、これから目指したいことにも触れます。 同じように新しくチームに入る方や、課題の多い環境でプロダクトやチームを少しずつ良くしていくことに面白さを感じる方に、読んでもらえたらうれしいです。 これまでの経験 前職では、EC領域でカートや決済まわりを担当するチームにいました。 扱うドメインは、今の人材紹介領域とはかなり違います。ただ、ユーザーがどんな課題を抱えていて、それを解消するにはどんな価値を届けるべきかを、職能に関係なく議論できる雰囲気がありました。 エンジニア、デザイナー、PdMがそれぞれの立場から意見を出し合いながら、どうすればプロダクトをもっとよくできるかを前向きに考えていく。自分にとっては、とてもいい環境だったし、エンジニアとしてだけでなく、人としても成長できた時間だったと思います。 自分自身も、ただ実装するだけでなく、チームで改善を積み重ねながら価値を届けていくことにずっと関心がありました。カイゴジョブエージェント開発チームに入ってからも、その延長線上にいる感覚があります。 エス・エム・エスを選んだ理由 エス・エム・エスへの入社を考えたとき、いちばん大きかったのは全社ミッションへの納得感でした。 高齢社会に適した情報インフラを構築することで人々の生活の質を向上し、社会に貢献し続ける。これは誰かが取り組むべき課題であり、しかも短期的に答えが出るものではありません。 だからこそ、仕事として腰を据えて長く向き合う意味があると思えました。解決する意義のある大きな社会課題に、プロダクト開発を通じて関われること。それが、エス・エム・エスに入りたいと思った一番の理由でした。 入社して感じたこと 入社してすぐに感じたのは、カイゴジョブエージェントが単なる機能開発ではなく、チームの進め方そのものを改善していくフェーズにあるということでした。 前職にも課題はありましたが、エス・エム・エスに入社した当初は、特に組織やチームの進め方に関する課題を強く感じました。担当するプロダクトが明確に分かれていないことで認知負荷が高くなっていたことに加えて、マーケティング部門と開発が、ユーザーへの価値提供を同じ目線で最速最大化していくための関係性や進め方にも、これから整えていく余地があるように見えていました。 ただ、それをネガティブには捉えていませんでした。課題が多いからこそ変えていける余地があるし、自分たちで少しずつ良くしていける面白さがあると思えたからです。 実際、エス・エム・エスには、良い変化なら前向きに取り入れていこうとするカルチャーがあると感じています。完成された仕組みに乗るというより、よりよい形を模索しながらチームで前に進んでいける感覚がありました。 チームの変化と、今感じている手応え この数か月で、カイゴジョブエージェント開発チームの体制や進め方にはいくつか変化がありました。 その中でも特に大きかったのが、担当するプロダクトごとにチームを分けたことです。将来的な統合を見据えて1チーム体制を取っていた一方で、実際にはアーキテクチャやフェーズの違いが大きく、認知負荷の高さが改善スピードに影響していました。 そこで、まずはプロダクトごとに集中しやすい状態をつくった方が良いと考え、自分から必要性を提案し、メンバーや上長と話しながら進めていきました。 分割後にいちばん変わったのは、やはり認知負荷の低さです。スイッチングコストが減って、「今どの課題に向き合うべきか」がかなりクリアになりました。技術的な負債や開発基盤の改善も、以前より進めやすくなったと感じています。 もうひとつ大きかったのが、マーケティング部門との関係です。もともとやりとりは多いチームですが、入社当初は開発とのあいだに少し距離があるようにも見えていました。 ただ、最近はユーザー起点で改善を考える流れが少しずつでき、そのための場も整ってきました。以前よりずっと前向きに議論しやすくなってきた印象があります。 入社後に自分が取り組んできたこと ここまではチーム全体に起きていた変化について書いてきました。ここからは、その変化の中で自分がどんな形で関わってきたかを振り返ってみます。 入社してから今までのあいだで、自分が関わってきたことは大きく3つあります。 開発を前に進めるためのキャッチアップ まずは、チームやプロダクトの状況を理解することから始めました。新しく入った立場だからこそ、どこに認知負荷があり、何が進みやすさを阻害しているのかを丁寧に掴もうとしていました。 特に最初は、外部サービスであるSalesforceに依存している部分の理解に苦労しました。自分にはSalesforceの経験がなかったので、前提知識のないところから全体像を掴む必要があったからです。 もうひとつ大きかったのは、チーム内のナレッジ共有がまだ十分ではなく、知識が属人化している部分があったことです。たとえば同じエラーに見えても、どれくらい緊急性があるのかを判断しづらく、最初のうちは感覚を掴むのに手間取りました。 ただ、チーム内のコミュニケーションが増えていく中で、そうした知識も少しずつ聞きやすくなっていきました。2025年12月上旬にはオフラインのチームビルディングも実施し、お互いの強みや価値観、理想のチーム像を共有する時間も持ちました。 この場をきっかけに、プロダクトをよりよくしていきたいという思いをチームであらためて共有できましたし、メンバー同士の距離も縮まったと感じています。少しずつですが、気軽に聞ける空気感もできてきたのだと思います。 2025年12月のチームビルディングで使用したボード 改善活動や開発プロセスへの関わり カイゴジョブエージェント開発チームでは、機能開発だけでなく、よりよく開発できる状態をつくることも重要なテーマでした。 その中で自分も、レビューしやすい粒度を意識したPRの出し方をしたり、AIを活用した開発の進め方を試したりしながら、技術的な負債の整理や開発基盤の改善に関わってきました。 特に印象に残っているのは、チーム分割で生まれた変化を一時的なものにせず、実際の運用や開発の進め方に落とし込んでいったことです。 入社してまだ間もないタイミングでも、いろいろ挑戦させてもらえる雰囲気があったのは印象的でした。上長やメンバーも提案を前向きに受け止めてくれて、どうすれば現実的に試せるかを一緒に考えてくれました。 また、レビュー文化づくりにも取り組んできました。デイリーでレビューを優先することのメリットを伝え、レビューしやすい粒度でPRを出すことをチームの共通認識にしていきました。 その結果、レビュー待ちで作業が止まりにくくなり、PRを小さく出す意識も浸透してきたと感じています。PRマージのリードタイムが改善してきたことも、その変化が少しずつ形になってきた表れだと思っています。 ユーザー理解を起点に考える動きへの参加 自分が入社後に特に面白さを感じているのが、マーケティングと開発が一緒にユーザー理解から優先順位を考える流れに参加できていることです。 今カイゴジョブエージェントで進めていることのひとつが、求職者像を具体化し、カスタマージャーニーを整理しながら、今どこに取り組むべきかを考えることです。 ユーザーストーリーマッピングのような形も使いながら、ユーザー起点でプロダクトについて考え、改善につなげていこうとしています。 特に、マーケティング部門と開発の合同で行っているプロダクト戦略会議を通じて、以前より同じ方向を向いて議論できる感覚が強くなってきました。入社当初に感じていた距離も、こうした場を重ねる中で少しずつ縮まってきているように思います。 戦略会議の中で面白いのは、エンジニア視点とは違うマーケティング部門の見方に触れられることです。ユーザーの感情や意思決定の流れ、ペルソナの解像度の高さには学ぶことが多く、同じプロダクトを見ていても着眼点がかなり違います。 開発チームが単に要件を受け取るだけでなく、ユーザーにどんな価値を届けたいのかまで踏み込んで考える。その大切さを、ここであらためて実感しました。こうしたコミュニケーションの積み重ねが、よりユーザー理解の解像度を上げながらプロダクト改善に向かっていける土壌をつくってくれているのだと思います。 これから目指したいこと カイゴジョブエージェントが目指しているのは、単に求人を紹介するサービスであり続けることではありません。 求職者にとって、 今の不満を整理する 本当に転職すべきかを考える 働く現場を高い解像度で理解する 納得して意思決定する 入社後も前向きに働き続けられる ところまで一貫して支えられるプロダクトに近づけていきたいと考えています。 そのためには、まず継続的に改善を広げていくための共通基盤の整備が必要ですし、求人紹介の前後も含めてユーザーを支えられる体験づくりも必要です。 自分自身も、引き続き開発を進めやすくするための改善にも関わっていきたいと思っています。 そのうえで、これから特に力を入れていきたいのは、ユーザー理解を起点にした開発です。チーム内の改善や技術的な負債の解消は、プロダクトをよくしていくための土台です。その土台の上で、ユーザーが本当に感じている課題に向き合い、よりよい体験として届けていきたいです。 おわりに 2025年11月に入社してからの数か月は、カイゴジョブエージェント開発チームの変化の中に飛び込みながら、プロダクトとチームの両方に向き合ってきた時間でした。 課題はまだたくさんあります。でも、それを悲観的には見ていません。課題があるからこそ変えていける余地があるし、その変化をチームでつくっていけることにやりがいを感じています。 エス・エム・エスには、良い変化に対して前向きに協力していけるカルチャーがあると思っています。だからこそこれからも、ユーザー理解を起点にしながら、プロダクトをもっと良くしていきたいです。 その先で、エス・エム・エスのプロダクトや事業が大きな社会課題の解決に寄与していくことに、大きな面白さを感じています。 こうした課題や向き合い方に少しでも興味を持ってもらえたら、うれしいです。いつか一緒に働けたら、なおうれしいです。

こんにちはVPoEの木村です。 会社として新年度を迎え少し経ちましたが、先月頭、エンジニア組織の今期以降の運営方針を社内向けに発表しました。今回はその方針について、ブログでもご紹介したいと思います。 テーマは 「AIの最大活用〜新開発フロー・体制へ移行〜」 と 「ベンチャー回帰〜ビジネス成果への直接貢献〜」 です。 先期の振り返り 　〜再確認した内製エンジニア組織としての存在意義とAIの力〜 先期を振り返る時に欠かせないトピックとしてまず挙げられるのが、大規模メンテナンスを実施し、BUYMAのインフラ基盤をオンプレからAWSへ移行したことです。 事前に最大限リスクを取り除く努力はしたものの、一定のリスクを伴うビッグバン方式での移行になりましたが、やり遂げた後としては、なんとか力技で捩じ伏せることができたようなベンチャー感を思い出す感覚がありました。 長年運営してきたサービスの癖やパターンを知り尽くし、何があってもサービスを動かし続けてきた内製エンジニア組織だからこそ採れたアプローチだと思います。 また、時間的・人員的なリソースも十分とは言えないなかでも、AIをカウントされないプロジェクトメンバーとして、移行日直前に「本当はやりたいけど時間がない」という追い込みの作業を実現したり、移設中・直後の不具合調査の高速化などに活用することができました。 AI活用についてはそれ以外にも業務面、プロダクト面にも進み、リリースできた様々な機能追加や改善を振り返ると、数年分の成果を１年に詰め込んだような実りの多い期だったと感じます。今期はそんな成功パターンを組織全体へスケールさせていくため、「AIの最大活用」と「ベンチャー回帰」をテーマに前年踏襲をやめ、ドラスティックな方針転換を図ります。 方針１：AIの最大活用 〜新開発フロー・体制へ移行〜 「AIに仕事を奪われるのでは？」という漠然とした不安を持つのではなく、「全員でAI武装し『アベンジャーズ』になろう」というのが私たちのスタンスです。AIをフル活用可能な開発フローと体制に移行していきます。 新開発フロー 単なる作業の効率化にとどまらず、再構築された価値提供のパイプラインを生み出すために、下図のとおり全く新しいAI駆動開発フローへの移行を進めます。 AI駆動開発フロー 新開発フローのステップ は以下の通りです。 設計（人間＋AI）： Notion上でドキュメント作成。Notion AIを活用してPRD、要件定義書、タスク分解・計画を生成します。 仮実装（AI単独）： ドキュメントをコンテキストとして、AIがIssueを立ててブランチ作成、実装、Pull Request作成までを完全自動化します。 本実装（人間＋AI）： 仮実装をチェックアウトし、Cursorを活用してローカルで動作確認・仕上げを実施します。 レビュー（AI→人間）： AIによる静的解析と事前レビューを通過したものだけを人間がレビューします。 本フローを構築していくにあたり、細かいツールや技術選定は詰めていく必要はあるものの、ナレッジ管理ツールとして利用していたesaと、プロジェクト管理ツールとして利用していたRedmine/JiraはNotionへ移行・統合していきます。また、コード管理・CI/CDの基盤としてセルフマネージドでGitLabを利用してきましたが、生成AIのエコシステムへの統合がより進んでいるGitHubへと移行します。 このフローでは2の仮実装という、AIにより完全自動化されたステップが組み込まれていることがポイントです。これにより下図のように実装時の調整やQAでの不具合はすべてドキュメントにフィードバックされ、ドキュメントの成熟とともにAIで完全自動化されたステップの精度が向上し、全体が省力化され続けるサイクルを構築します。 AI駆動開発成熟の仕組み 新開発体制へ また、AIの支援により、今後は誰もが「知識のフルスタック化」を実現できる時代です。1人のマネージャーが複数チームをマネジメントするのはもちろん、フロントエンドエンジニアがバックエンドも含めてリードするなど、単独でもユーザーに価値提供できる「PM兼アーキテクト」として振る舞える人材を増やしていきます。 フルスタックへの回帰・フルサイクルへの挑戦 これは これまで分業化や専門性特化のチームを作ってきた 流れからの方針転換となり、個人やチームのフルスタック化フルサイクル化を進めていきます。 方針２：ベンチャー回帰 〜ビジネス成果への直接貢献〜 AIによってデリバリー（実装）が超効率化されていく今後、エンジニアは浮いたリソースで何を目指すべきでしょうか？ その答えが「ベンチャー回帰」です（2000年代創業の弊社としては、スタートアップというよりベンチャーという言葉がしっくりきます）。 フィーチャーチームからミッションチームへ これまで、部としてはプロダクト開発のエンジニアを ドメインと呼ばれる３つのチーム に分けて運用してきており、それらは単に開発・運用する機能が割り振られた括りでしかありませんでした。　しかし今期からは、すべてのドメインがユーザーに直接届く「ビジネスミッション」を持つ体制へと方針転換します。 BUY： 購入者を強力に吸い上げ、集客とCVRを最大化する。 SELL： 世界中から商品を力強く吸い上げ、品揃えを最大化する。 SERVICE INFRA (SI)： 決済や安心補償などの機能を提供し、ユーザーへの提供付加価値を最大化する。 単なる機能開発ではなく、全員が事業のKPIに直結したミッションを追い求める。この構造こそが、私たちの目指す真のベンチャー回帰の姿です。 新キャリアラダーを設計 また、全員がビジネス成果にコミットする組織へ進化するため、エンジニアのキャリアラダー（評価軸）もアップデートしました。従来の「デリバリー」中心の評価から、以下の6つの軸による評価へと拡張しています。 アウトカム ：事業成果に接続した意思決定ができているか。 ディスカバリー ：ユーザーの課題を正しく再定義できるか。 デリバリー： 設計〜実装〜テスト〜リリースを安定して回せるか。 運用：SLO/障害/コスト/セキュリティを背負えるか。 コラボレーション（協働） ：チームビルディングや他職種との協働。 レバレッジ ： 仕組み化・標準化により、組織全体の生産性を引き上げる力。 実はこの6軸は、元々「AI時代に合わせよう」として作ったものではありません。先期の振り返りで再認識した「外部パートナーにはできない、内製エンジニア組織ならではの価値とは何か？」を徹底的に言語化した結果生まれたものです。 しかし興味深いことに、「内製組織の本質」を追求したこの6軸は、AI活用が進む時代にエンジニアに求められると思われるスキルセットとしてみても全く不自然ではありませんでした。 例えば、AIで簡単にモノが作れるようになったからこそ、「どこまでこだわるべきか」を事業成果から逆算するアウトカムや、本質的なユーザー課題を見極めるディスカバリーの重要性が増しています。また、AIには代替できない人間同士の高度なコラボレーションも不可欠です。 中でも 「レバレッジ」 は、次世代エンジニアのコアとなる概念です。日々の案件を無事にデリバリーするだけでなく、「AI駆動開発を実現し、価値提供のパイプライン自体を自分たちで構築・改善する（仕組みを創る）」ことが求められます。この仕組み作りは専任チームに任せるのではなく、各チーム自らが構築し、組織全体をブーストさせる姿勢を高く評価します。 まとめ 以上が、今期からのエンジニア組織の新しい運営方針です。 今のエニグモの環境で「事業にコミットし、AIで開発パイプライン自体を創り上げる」という経験は、 こちらの記事 でも語られているどこに行っても通用する非常に高い市場価値につながると確信しています。 この方針は決して理想を描いただけではありません。先期のAI活用の実績という裏付けがあり、NotionやGitHub、AIコーディングエージェントを全社で導入するための予算もしっかり確保してスタートしています。 「いつかできたら」ではなく「今年できる」。今期もこのスローガンを胸に、圧倒的な成果を生み出す1年に していきたいと思います。

今回は、 第5回の「営業」の回 に続き、再び「幕間」として、技術とは少し異なる、しかしQAエンジニアにとっては避けて通れないテーマについてお話しします。 そのテーマとは、「品質」です。 QAエンジニアと名乗る以上、「品質」という言葉は常に私たちの隣にあります。 私はこの言葉をなんとなく分かった気で使っていました。 そして、(今となっては幸いなことに)あるタイミングで、この言葉を明確に言語化する必要に迫られました。 その過程で出会ったのが、TQMという品質マネジメントに関わる包括的な方法論です。 私自身、TQMの専門家と呼べるほど成熟しているわけではありません。しかし、この考え方に触れたことが、私が「品質」をどう捉え、それをどう自分のキャリアの土台とするかに、決定的な影響を与えました。 今回は、このTQMという概念を通じて、私がどのように「品質」という言葉に向き合ってきたかをお話しします。 記事一覧：技術を土台にして自分なりのQAエンジニアを組み立てる -あるQAの場合 【第1回】専門性をつなげて、あなたらしいQAエンジニアの像をつくる 【第2回】テストを設計する専門性 【第3回】テストマネジメントはテストマネージャーだけの技術ではない 【第4回】テストプロセス改善：思考の補助線としての専門技術 【第5回】幕間：異業種経験を土台にする 【第6回】テスト自動化：「設計原則」を知り、当たり前の技術にする 【第7回】スクラムマスターの専門性を持ったQAエンジニアとして 【第8回】幕間：「品質」という言葉に向き合う “品質”という言葉を使うことの畏れ多さ 「品質」という言葉は開発現場でよく使われます。 一方で、「品質はなんもわからん」と口にするベテランのエンジニアや品質保証の専門家も多く見受けられます。 QAエンジニアとして「品質」という言葉を意識し始めた頃、私自身はこう思っていました。 「“品質”という言葉を軽々しく使ってしまうことは失礼に当たるし、本質を理解していないことになる」 今振り返ると、自分の虚栄心からそう思い込んでいたのかもしれません。 今でも「品質」という言葉を使う時には、多くの人が思い悩みながらも言語化を避けてきた恐ろしさ、そして先人達への畏れ多さを感じずにはいられません。 それでも、あえてその「魂」の部分に向き合い、自分なりに腹落ちさせるプロセスを経たことは、私のQAエンジニアとしてのスタンスを大きく変えるきっかけとなりました。 QAエンジニアという職能の捉え直し 現在の日本のソフトウェア開発現場において、『QAエンジニア』といえば、『テストをする人』や『テストの専門性を持っている人』を指しているのが実情です。私自身もその一人です。 しかし、TQMにおける「品質保証」という視点から捉え直すと、QAエンジニアの職能はもっと大きな範囲に広がるのではないか、と考えられるようになりました。 「顧客との間で明示的に約束しようがしまいが,徹底的に満足させてやろうとすること」 『 マネジメントシステムに魂を入れる 』p.54 TQMでの「品質保証」について学んだのはこの書籍ではないですが、私がこういった捉え方と出会ったとき、私はこの上なく自由さを感じました。私のQAとしての活動に、文字通り魂が宿ったと感じました。 そして、この目的を達成するためには、いわゆる「テスト」という活動だけでは不十分だと私は考えています。 私がSqriptsなどのプロフィールで、単なる「QAエンジニア」ではなく、あえて 「 テストに専門性を持つQAエンジニア 」 と書いているのには、実はそうした背景があります。 私はあくまで、「テストの専門性」を土台（強み）として持っているQAエンジニアに過ぎないと考えています。そう考えれば、世の中にはもっと多様な土台を持つQAエンジニアがいて良いはずだと思うのです。 プロダクトマネジメントに専門性を持つQAエンジニア SREに専門性を持つQAエンジニア カスタマーサクセスやマーケティングに専門性を持つQAエンジニア どのようなバックグラウンドであれ、「品質」という目的のためにその専門性を発揮するのであれば、それは胸を張って「QAエンジニア」と名乗ってよいのではないか。 TQMの思想に触れる中で、私はそう確信するようになりました。 品質保証を広義に捉えることの危うさ 「品質保証」をこういった広義に捉えることはある種の危うさをはらんでいます。 それは「品質保証の責務を押し付けられた」あるいは「QAが品質保証を放棄した」と捉えられることです。 現実との差分として、そういった捉え方をするのは自然なことだと思います。 だからこそ私は今まで語ってきたさまざまな専門性と接続して、建設的に、そして納得感を持ってチームに実装していく必要があると感じています。 専門性の組み合わせ 「品質」という概念を深掘りしたことによって、他の専門性との結びつきもより強固になりました。 スクラムマスター（アジャイル）との組み合わせ 「品質」という言葉の本質を捉えようとすると、「アジャイル」という概念がより鮮明に理解できるようになりました。 例えば「アジャイルソフトウェア開発宣言」で語られている価値観は、驚くほどTQMの思想と合致しています。 品質を単なる「仕様通りであるか（品質特性）」だけで理解するのではなく、「顧客にとっての価値」や「提供側としての在り方」という本質的なところから考えることなどです。 スクラムやアジャイルの実践は、単なるフレームワークの導入ではなく、「本質的な価値提供のために、我々はどう行動すべきか」という問いをより強固なものとします。品質への深い理解は、アジャイルなチームビルディングを行う上での強力な土台になると考えるのです。 テストマネジメントと品質マネジメント かつての私は、「テストマネジメント」と「品質マネジメント」をほぼ同一のものとして捉えていました。しかし今は、これらを明確に区別して考えています。 品質マネジメントという全体の中に、テストマネジメントが位置づけられる。 この視点を持つと、テストの役割がより柔軟に見えてきます。 品質を作り込むために、テストはどうあるべきか。 そう考えると、典型的には「シフトレフト」の必要性にまず気付けると思います。 あるいは、「シフトライト」や「運用でカバーする」という判断、さらには「オブザーバビリティ」を高めることや、マーケティングの視点からのフィードバックが必要になるかもしれません。 「テスト」という枠組みを超えて、様々なステークホルダーと「品質」を共通言語に会話ができるようになる。これが、品質マネジメントの視点を持つ最大のメリットだと感じています。 実務において、「品質」を脇に置くことも考える 正直なところ、実務の現場において、「品質とは何か？」といった哲学的な議論を頻繁に持ち出すべきではないと私は考えています。 定義論争は時に不毛なものになりえます。 特にQAエンジニアの実務において、個人の胸の内に留めておくということもチームを健全に前に進めるためには必要になるでしょう。 私自身、哲学的な議論が大好きです。 一方で 「私たちはどういった世界を実現したいのか」、 「そのために、お客様やステークホルダーにどういう状態になってほしいのか」、 そういったことを建設的に議論するほうが、プロジェクト、あるいは世界は前に進むことも多いでしょう。 大切なことは「顧客満足のために在りたいスタンスを取り続けられること」だと思っています。 そしてその議論の中で使われる言葉は、必ずしも「品質」という言葉でなくても構わないと思っています。 「品質」という言葉を使ってしまうと、今まで「品質」という言葉をつかってこなかったチームにとってマウントを取られた気分になりえます。 実際に私は「QAエンジニアとして品質について理解している」そういった気持ちでいたことがあります。 そんな時に、別の言葉で表現したり、脇に置いて前向きに対話していくことで、私は「いきいきとした」チームになっていく姿をたくさん見てきました。 そして、それこそが品質を扱う私の働き方の醍醐味だと思うようになったのです。 それでも品質を言語化すること 最後まで読んでいただきありがとうございます。 本稿を読まれた皆様は、「QAエンジニア」を名乗っている、あるいは目指しているのではないでしょうか。 皆さんのアイデンティティの核である「品質」、あるいは「品質保証」について、一度じっくりと考え、自分なりの言葉で向き合ってみてはいかがでしょうか。 ここであえて、私なりに品質について一言で表しましょう。「誰かがハッピーになること」です。 「品質」。 畏れ多い言葉です。 しかし、そこから逃げずに自分なりの答えを持てた時、それは「自分はなぜここにいるのか」「自分の専門性はどこで活かせるのか」という、QAエンジニアとしての揺るぎない土台になると、私は信じています。 参考文献 書籍『マネジメントシステムに魂を入れる』 ／飯塚悦功（著）、公益財団法人日本適合性認定協会（編集）日科技連出版社、2023年 やまずん、QAとしての自分の考えを表明するためのポジションペーパー https://55ymzn.com/me/positioning_paper_of_qa/ 【連載】技術を土台にして自分なりのQAエンジニアを組み立てる -あるQAの場合 【第1回】専門性をつなげて、あなたらしいQAエンジニアの像をつくる 【第2回】テストを設計する専門性 【第3回】テストマネジメントはテストマネージャーだけの技術ではない 【第4回】テストプロセス改善：思考の補助線としての専門技術 【第5回】幕間：異業種経験を土台にする 【第6回】テスト自動化：「設計原則」を知り、当たり前の技術にする 【第7回】スクラムマスターの専門性を持ったQAエンジニアとして 【第8回】幕間：「品質」という言葉に向き合う The post 【第8回】幕間：「品質」という言葉に向き合う first appeared on Sqripts .