この記事でわかること
-
AIが苦手な「予算・旧システム・移行」の難題を解く、人間ならではの調整・判断力
-
トラブルの真因を特定するエンジニアの基礎体力
-
単なる「仕様通りの検証」から「要件の妥当性」を問う上流工程への転換
生成AIによるコード生成が一般化する中、エンジニアの役割は「書くこと」から「判断すること」へと急速にシフトしています。技術のコモディティ化も進む中で、中堅以上のエンジニア（PL/PM層）はどのような「強み」を身につけるべきなのでしょうか。
かつてGyaoやU-NEXTといった国内最大級の映像プラットフォームを牽引してきた関守氏は、現在、株式会社AGESTのCTOとして、品質とセキュリティの観点からエンジニアの新たな生存戦略を提示しています。一見すると「作る側」から一歩引いたように見えるかもしれませんが、関氏が見出したのは、特定のプロダクトに縛られず、圧倒的なスピードで「良いサービスの本質」を見抜き、スキルを磨き続ける道でした。
激変する時代に、替えの効かないエンジニアであり続けるための具体的なキャリアのヒントを伺いました。
関 守
株式会社AGEST CTO
株式会社USEN（現：株式会社USEN-NEXT HOLDINGS）にてIP電話や「Gyao/Gyao-NEXT」の開発責任者を務める。U-NEXT分社後は執行役員開発本部長兼CTOとして「U-NEXT」等の開発を牽引。2018年にデジタルハーツホールディングス入社、現在は事業会社である株式会社AGESTのCTOとして、QA事業やサイバーセキュリティ事業の技術戦略を統括している。
株式会社AGEST
ソフトウェアテスト、品質コンサルティング、サイバーセキュリティまで幅広いサービスをワンストップで提供するQA専門企業。国際資格を持つ多数のスペシャリストが在籍し、開発初期段階から品質向上を支援する。
AIを活用した独自のテスト管理ツール「TFACT(ティファクト)」による作業効率の改善に加え、独自のSBOM管理ツール「SBOM Archi（エスボム アーキ）」を活用したソフトウェア部品管理と脆弱性検知により、サプライチェーンの安全性も徹底。最先端の品質テクノロジーを探求する研究・教育機関も運営し、顧客の事業成長に貢献する最高品質のソリューションを追求している。
目次
大規模開発のトップランナーが「守り」の領域を選んだ理由
関さんは、Gyaoの立ち上げやU-NEXTのCTOなど、国内映像配信サービスの最前線を歩んでこられました。まさに「作る」エンジニアの象徴的な存在ですが、そこからAGESTという「品質・セキュリティ」を主軸とする場を選ばれたのは、どのような背景があったのでしょうか。
エンジニアとしての純粋な探究心を刺激し続けられる場を求めたかった、それが最大の動機です。GyaoやU-NEXTの立ち上げ当時は、世の中にないものをゼロから作る非常にエキサイティングな時代でした。当時はお金も時間もありませんでしたから、既存のソリューションを吟味するよりも、自分たちでゼロから作る方が早かったのです。
映像エンコードのパイプラインや、視聴者に配信する仕組み、コンテンツのメタデータベース、CRM、CMSに至るまで、文字通り全方位で自前開発を行っていました。
しかし、プラットフォームが完成して拡張・更新のフェーズに入ると、次第にビジネスの主戦場は「エンジニアリングの力」から「コンテンツの調達力」へと移っていきます。未知の課題を次々と解決していくような、かつての「熱量」が失われていくジレンマを感じるようになったんです。そんな折、デジタルハーツに誘われ、これまでのキャリアを活かしつつ、新たな領域へチャレンジすることを決めました。
映像プラットフォーム開発の第一人者という立場を離れてでも、飛び込む価値があると感じられたのですね。実際に「作る側」から、QAやセキュリティといった「品質を守る側」へ移ることで、エンジニアとしての視座はどう変わりましたか？
「1年間で触れられるプロジェクトの数」が劇的に増え、知見が蓄積されるスピードが加速しました。というのも、自社サービス開発では一つのプロダクトに長く向き合いますが、AGESTではお客様が1年かけて作ったプロダクトを、わずか数週間から数ヶ月で診断・テストします。
つまり、1年で数十ものプロジェクトの「全容」に触れることができるのです。多種多様なサービスの最後のプロセスをこれほど多く経験し続けると、良いサービスとそうでないものの境界線や、品質効果の本質が「感覚」として磨かれていきます。こうした圧倒的な経験の密度が、エンジニアとしての私の視座を一段引き上げてくれたと感じています。
その磨かれた『感覚』を、単なる経験則に留めず確かな専門性へと昇華させるために、かなりストイックに研鑽を積まれたと伺っています。
QAやセキュリティといった領域の専門性を客観的に担保するため、JSTQBの勉強や受験、登録セキュリティスペシャリストの合格とCTFチャレンジ、さらにはクラウドのプロフェッショナル認定試験のパスなど、基礎を磨き直しました。
現在は経産省の産業サイバーセキュリティ研究会の委員なども務めていますが、ランサムウェアやフィッシングといったサイバー攻撃に対する「被害の軽減」に強い使命感を感じるとともに、サイバーセキュリティ製品の国産化に力を注いでいます。こうした公共性の高い課題にエンジニアリングの知見で挑めるのは、非常にやりがいがあります。
AIに代替されない「オーケストレーション能力」の拡張
現場のリーダーであるPLやPM層のエンジニアの中には、技術から離れて「管理業務」が増えることに不安を感じている人も多いです。AI時代において、彼らはどのような方向に役割を拡張すべきでしょうか。
ただ単に「コードを書く人」から、AIや人を統括する「オーケストレーター（指揮者）」へと進化すべきです。ジュニア層がAIと生産性を競わされている今、ミドル層以上の主戦場はコーディングではありません。「ビジネス要件を技術要件に翻訳すること」や「エンジニアと非エンジニアの間での合意形成」といった、対人スキルと統合スキルが主戦場になります。
プロジェクト全体の「舵取り」をする立場ですね。
ミドル層になっても「自分でコードを書いたほうが早い」と言ってコーディングに執着している人は、その仕事をAIに任せるべきです。アーキテクチャの選定や、技術的負債をどのタイミングで返済するかのトレードオフ判断にこそ、人間の時間を使うべきです。これらは「正解」が一つではないため、AIには決断できません。
AIが得意な「部分的なコード生成」と、人間が担う「全体最適」の切り分けが重要になるわけですね。
AIは部分的な効率化は得意ですが、「そのシステムで本当にビジネスの目的を達成できるか」という高次のレイヤーでの妥当性判断はできません。
また、エンジニアのキャリアを総合的に捉えると、そのレイヤーによって求められるものは明確に異なります。
このように役割を拡張していくことこそが、エンジニアにとっての市場価値の源泉になります。
「エンジニアの基礎力」を再定義する。トラブルを論理的に解決する“思考の基盤”
関さんは、トレンドが変わっても陳腐化しないための基礎が重要だとおっしゃっています。それは具体的に何を指しているのでしょうか。
CPU、メモリ、ディスク、ネットワークといった物理的基盤の仕組みや、OSI参照モデルのような階層概念、プロトコルの深い理解です。昨今、プロンプト一つでコードが書け、何かが「作れた」という感覚になりがちですが、根本的な仕組みを理解しないままでは、ツールは作れても大規模な「システム」は作れません。
表面的なプログラミングスキルではなく、その下にある「動く原理」を掴んでおく必要があるのですね。
はい、最も差が出るのはトラブル対処における「切り分けスキル」です。例えば不具合が起きた際、下位プロトコルレベルの仕組みを理解していれば、ログを解析して「APIの送受信で問題があるのか、そもそもネットワークの階層で通信が届いていないのか」を論理的に切り分けられます。開発環境で問題が発現しなくても、Proxyなど顧客固有環境で問題が発生する場合もあります。
この「下位レイヤーから順に問題を切り分け特定していく」基礎力こそが、エンジニアにとって一生モノの財産になります。
技術知識以外にも、実務で重要になる思考法はありますか？
加えて重要なのが、ドメイン知識（業務理解）と「イメージ力」です。例えばECサイトならユーザーとしての経験で補完できますが、複雑な会計システムや他社連携プロトコルなどは、そのドメイン知識がなければ仕様の背景すら理解できません。
確かに、BtoCサービスなら肌感覚で分かっても、専門性の高いBtoB領域となると「なぜこの仕様が必要なのか」という意図を汲み取るのが格段に難しくなりますね。
残念ながら、こうしたドメイン知識は業界の人にとって「当たり前」すぎて明文化されないことが多いのですが、ここを自ら取りに行く姿勢が価値を分けます。
自ら踏み込んで、明文化されていない「暗黙知」をキャッチしに行く。それがエンジニアとしての希少性に繋がるわけですね。もう一つの「イメージ力」については、具体的にどのような場面で活きてくるのでしょうか。
システムがどう動くべきかという「全体像を具体的に描く力」があれば、運用の際に「挙動がおかしい」という違和感にいち早く気づくことができます。 そして、エンジニアとしての最深部にあるOS、あるいはBIOSとも言えるのが「知的好奇心」です。
新しい技術を積極的に試して「こうしたら楽ができる」「面白くなる」と考えるマインドセットさえ忘れなければ、エンジニアとして長く活躍できるはずです。
カオスな状況から着地点を見出す「調整力」が、AI時代に求められる
開発現場でのAI活用について伺いたいのですが、関さんは現状、どこまでをAIに任せ、どこを人間が担うべきだとお考えですか？
コーディングや単体テスト、自動テストのセットアップなどはAIに任せ、人間は「将来像の設計」や「非定型なトラブルへの対処」に注力すべきです。私自身もGitHub CopilotやClaude Codeなどを使っていますが、書き始めたら「次はこれを使いたいのでは？」とAIが次々提案してくれる時代に、わざわざ一からコードを書くのは非効率だと思います。また、GoogleのAntigravityなどバイブコーディングも実際に使ったら面白いですね。
AIをパートナーとして使いこなす上で、AIには到達できない人間の領域とはどこでしょうか。
「カオスな状況から落としどころを作る総合的な判断力」です。 AIは学習ソースに基づいて確率的に高い成果を返しますが、それはあくまで現状の最適解に過ぎません。対して人間は、周辺システムとの連携や、旧システムからの複雑なマイグレーション計画といった、未来を見据えた複雑な要件を定義しなければなりません。
ベストプラクティスが通用しない現場の事情を、どう着地させるかということですね。
例えば、ベストプラクティスは「何もないところから作る最短の道筋」ですが、現実は「旧システムを止められない中でどうマイグレーションするか」といった制約だらけです。AIは「答えがあるのになぜ直接行かないのか」という非効率を許容しませんが、予算や時間の矛盾がある中で「あえてこのステップ（過渡期）を挟む」という判断は、人間にしかできません。
また、未知の事象への対処や、トラブルシューティングにおける複雑な原因特定、さらには組織マネジメントや育成といった領域も、再現性のない「カオス」な世界であり、人の手や判断が不可欠です。部分最適ではなく、全体最適を見据えて「矛盾の中でどう着地させるか」を考えること。この調整力こそが、AI時代におけるエンジニアの真の生存戦略になります。
サプライチェーンセキュリティ評価制度を見据えた生存戦略
最後に、これからのエンジニアの市場価値を決定づける「品質・セキュリティ」の提案力とマインドセットについて伺わせてください。
非常に重要なのは、AIは「要件にないこと」は実装してくれない、という事実を理解することです。 例えば、パスワードを何度も間違えた際にアカウントをロックする、あるいは不審なログインを検知して二段階認証を求めるといった仕組みは、エンジニアが知見を持って「要件」として定義しなければ、AIは作れません。
エンジニアがその知見を持っていないと、AIに正しい指示が出せず「機能は動くが危険なシステム」が量産されてしまうということですね。
それに加えて、2026年10月以降に「サプライチェーンセキュリティ評価制度（※1）」が動き出し、セキュリティ対策が不十分な企業は外部評価で不利になる見込みです。 そのためエンジニアは、「このシステムは個人の財産を扱うから、これだけの多層防御が必要だ」とビジネス側に伝え、仕様通りかだけでなく「要件そのものが妥当か」を検証できなければなりません。
また、スナップショットのセキュリティチェックは翌日には新たな脆弱性の発見によって陳腐化されるかもしれません。今後はSBOM管理による継続的な脆弱性管理と保守、OSSコンプライアンス管理がより強く求められます。
※1 サプライチェーンセキュリティ評価制度（サプライチェーン強化に向けたセキュリティ対策評価制度）…… 経済産業省が導入を進めている、サイバー攻撃の脅威からサプライチェーン全体を保護することを目的とした評価制度。取引先や委託先を含めたセキュリティレベルを★3〜★5の段階で可視化する。対策が未整備な企業は取引上の機会損失を招く可能性があるため、経営層・エンジニア双方による戦略的な準備が求められている。
2026年10月から始まるこの制度は、取引の可否にも直結する非常にインパクトの大きいものですね。
また、エンジニアが担うべき「品質管理」の範囲も、リリースの瞬間だけでは収まらなくなってきています。というのも、品質保証という概念自体がリリースで完結するものではないからです。サービスは契約時の性能・機能を継続して提供し続ける、また機能強化し競争力を上げる活動を期待されます。これも品質保証の一面です。
リリース後もログ解析やAPIレスポンスの悪化などの振る舞い監視を行い、継続的にシステムの健全性をチェックし続ける。その一連のフローが、現代の品質管理に不可欠になっているのです。
「システムの健全さ」をリリース後も証明し続ける必要があるのですね。
その際にマインドセットとして大切なのは、エンジニアとしての「価値証明」です。今のAIは、単にコードを書くだけではありません。自らテストデータを作成して「全てのテストをパスしました」というエビデンスを添えてアウトプットを出してきます。いわば、自分の仕事の正しさを自分で証明し、後工程へ渡しているわけです。
それに対して人間が「とりあえず書いたので、あとはテストチームでバグを見つけてください」という丸投げの態度では、もはやAI以下の価値しか提供できません。後工程で欠陥が見つかれば、実装のやり直しや他への影響分析など、膨大な手戻りが発生します。結果として、プロジェクト全体のリリース日程を遅らせる最大の原因になってしまうのです。
AIが自律的に「自己証明」を行う以上、人間側にもそれと同等、あるいはそれ以上の根拠が求められるということですね。単なる作業者としてではなく、自分の判断と成果に責任を持って次へ渡す。そのプロフェッショナルとしての自覚が、AIとの差別化の第一歩になると。
後工程へ手戻りを発生させないよう、自分のアウトプットの正しさを自らの言葉とデータで証明し切る。そして、その根底には「コンピュータへ適切に仕事を任せ、より高次な課題解決に挑む」という探究心があるべきです。
とにかく基本に立ち返り、楽しくシステムを作っていくためにはどうしたらいいのか。それを考え、勉強し続けることが、AI時代を生き抜く一番の近道ではないでしょうか。
ライター
