QAからマネジメントへ──「仕組みで解決する」延長線上にあったキャリア
小田中育生氏（以下、小田中）：本日はよろしくお願いします。miisanとはこうしてじっくりお話しするのは初めてですね。以前から、miisanが「1人目QA」として組織を作り上げてきたストーリーには非常に興味を持っていました。
昨今はエンジニアリングマネージャー（以下、EM）への注目度が高まり、コミュニティも盛り上がっていますが、QAエンジニア出身のEMというのはまだ珍しいキャリアパスだと感じています。まずは、これまでのキャリアの歩みと、現在のお仕事について教えていただけますか。
miisan氏（以下、miisan）：よろしくお願いします。私は今年で社会人10年目になります。キャリアのスタートはERPパッケージの開発会社で、開発やコンサルティング、評価業務などを経験しました。その中で「評価業務」に深く関わる機会があり、品質保証の面白さに目覚めました。
その後、2社目の株式会社メルペイにQAエンジニアとして参画し、サービスのコアローンチに携わりました。そこからQA Leadを経て、エンジニアリングマネージャーとしてのキャリアが始まり、2022年に旅行アプリ「NEWT（ニュート）」ローンチ前の株式会社令和トラベルへジョインしました。
現在は、Head of Engineering Officeとしてプロダクト開発組織全体のマネジメントをリードしつつ、エンジニアが所属するユニットの統括や、全社のAI活用を推進するAX（AI Transformation）室、さらには全社のリスクマネジメントまで担っています。いろいろな帽子を被りすぎて、自分でも今どの役割なのかわからなくなることがあります（笑）。
小田中：「品質」に向き合う中で、必然的にプロセスや組織のマネジメントに領域が広がっていったのだと想像しますが、QAからマネジメントへ移行する際、ご自身の中でどのような心境の変化があったのでしょうか？
miisan：実は、最初はマネージャーになる打診を何度も断っていたんです。「自分はQAエンジニアというロール（役割）を深めていきたい、現場でモノづくりをしていたい」という志向が強かったので。マネージャーになりたくて今の仕事に行き着いたわけではないんです。
ただ、品質改善活動を続けていると、個別のバグ修正だけでは限界がきます。「そもそも仕様が決まっていない状態で走り出しているのが問題では？」「チーム間の連携不足が原因では？」といった構造的な課題にぶつかるんですね。これらを解決するには、一人のエンジニアとして動くよりも、仕組みやプロセス、あるいは人の考え方自体を変えていく必要があります。
現場で「どうやったらこのチームは良くなるかな」と試行錯誤していたことの延長線上に、たまたま「マネジメント」という役割があった。周りの人からそれがマネジメントだと教えてもらい、後になって気づきました。
小田中：現場の課題を解決しようと動いていたら、それが結果的にマネジメントの役割と重なっていた、と。非常に興味深いです。エンジニアの中には「マネジメントには興味がない」「コードだけ書いていたい」という人も多いですが、miisanのように課題解決の手段としてその道を見出すケースは、多くの若手にとってヒントになりそうです。
70名組織の急拡大と葛藤──「見えない仕事」と「メンバーの人生」を背負う重み
小田中：実際に「エンジニアリングマネージャー」という肩書きがついたのは、前職でのことだったと伺いました。自分から手を挙げたのでしょうか？ それとも任命されたのでしょうか？
miisan：どちらかと言えば「あなたがやっていることはマネージャーの仕事だから、やりませんか？」と背中を押された形です。当時、QA組織初期は10名程度からスタートしましたが、事業拡大もあり業務委託の方も含めて70名規模まで急拡大していました。
実はQA組織の急拡大を推進したのは私で……。とあるプロジェクトを成功させるためにリリースデッドラインと必要要件を整理したところ、当時の組織のままでは実現が難しく、なんとかプロジェクトを軌道にのせるためのチームの組閣が必要だと主張して、人員を増やしてもらいました。その結果、上司から「これだけ組織が大きくなったら、もう見きれないですよね？」と言われて（笑）。「確かに、自分が蒔いた種なのだから、責任を持って引き受けよう」と覚悟を決めました。
小田中：70名規模の組織マネジメントは相当なプレッシャーだったと思います。実際にマネージャーになってみて、プレイヤー時代とのギャップはありましたか？
miisan：ありましたね。私がチームリーダーとして担っていた責務の一部にはマネージャーの仕事もありましたが、「マネージャーの仕事は、メンバーからは見えない部分が圧倒的に多い」ということを痛感しました。プレイヤー時代は目の前の問題解決に集中していればよかったのですが、マネージャーになると、予算管理や採用計画、評価制度の設計など、未来を作る仕事にシフトします。
その中でも一番苦労したのが、「メンバーの人生を担う」という重みです。特に当時は、自分よりも経験豊富な年上のメンバーに対して、「どういうキャリアを歩みたいですか？」「今のあなたにはここが足りていませんよ」とフィードバックし続ける必要がありました。これは精神的な負荷が非常に高かったです。
小田中：わかります。雑談一つとっても、その裏側にあるメンバーの志向やコンディションを汲み取る必要があるので、マネージャーという帽子を被っていると認知負荷が高いですよね。
miisan：そうなんです。一人のメンバーとして接していた時は楽しく話していただけだったのに、マネージャーになった途端、「この発言の裏には何があるんだろう」と考えるようになりました。そこには高度なスキルセットが求められるのだと、自分がその立場になって初めて理解しました。
小田中：miisanは元々サーバーサイドエンジニアだったと伺っています。「QAに向いているんじゃない？」と言われて転身されたそうですが、職種を変えることに抵抗はありませんでしたか？
miisan：元々、大きなキャリアビジョンを持っていたわけではないんです。「モノづくりがしたい」という軸はありましたが、周囲の人を信じている部分が大きくて。自分の意思や自己認知よりも他者評価のほうが正しいんじゃないか、と思っていたんです。「開発も好きだろうけど、QAで本気出してみない？」と言われた時に、それでチームや会社により貢献できるなら試してみよう、というスタンスでした。
小田中：その柔軟性は素晴らしいですね。そして、QAとして成果を出す中で「一人では限界がある」と気づき、周囲を巻き込んでいった。その「巻き込み力」の源泉は何だったのでしょうか。
miisan：やはり「自分を主語にしない」ことへのシフトだったと思います。最初は「自分が担当した機能がどうなればいいか」でしか物事を捉えていませんでしたが、視座を上げると「機能単体が100点でも、サービス全体として届けたい価値を提供できなければ意味がない」と気づくんです。
問題の原因を探ると、仕様の不備だったり、チーム間のコミュニケーション不足だったりする。これは一人では解決できません。そこで「今、大変そうだけど大丈夫ですか？」「これ、どうすれば良くなると思いますか？」と声をかけて、小さな共感者を作っていく。そうやって少しずつ仲間を増やしていった結果が、今のマネジメントスタイルにつながっている気がします。
