SEリーダーがつらくて辞めたい｜責任・板挟み・技術離れの対処法

SEリーダーがつらくて辞めたいなら、適性を疑う前に「仕事内容・責任・権限・支援」のズレを切り分けるべきです。

顧客には納期を求められ、上司には進捗を詰められ、メンバーには判断を求められる。「もうリーダーを降りたい」と思いながら、自分の能力不足なのではないかと責めている人へ。

同じSEでも、会社や担当範囲が変わるだけでリーダー業務への負担感が変わった事例があります。辞めるか残るかを決める前に、「SEそのものを辞めたいのか」「今のリーダー業務だけを辞めたいのか」まで分解して考えることが重要です。

SEリーダーがつらくて辞めたいのはなぜ？

SEリーダーがつらくなりやすい理由は、単純に仕事量が増えるからだけではありません。

担当SEからリーダーになると、仕事の対象が「自分の成果物」から「プロジェクトやチーム全体」へ広がり、それまでとは種類の異なる責任を持つようになるからです。

厚生労働省の職業情報提供サイト「job tag」では、システムエンジニア（受託開発）の仕事として、顧客へのヒアリング、要件定義、基本設計、詳細設計などが示されています。

一方、プロジェクトマネージャ（IT）については、プロジェクト実行計画の作成に加え、予算・要員・進捗などの管理を行う職種として整理されています。

つまり、開発者からリーダー側へ役割が移ることは、単純な「SE業務の上級版」ではありません。

設計や開発を行う仕事に、見積もり・進捗管理・要員調整・顧客折衝・説明責任という別系統の仕事が追加されると考えた方が、実態に近いでしょう。

責任の対象が自分からチーム全体へ広がる

担当SEであれば、自分が受け持つ設計書、プログラム、テスト結果などを期限までに仕上げることが仕事の中心になります。

しかしリーダーになると、自分の作業が終わっているだけではプロジェクトを完了できません。

メンバーの進捗が遅れていれば原因を確認し、障害が発生すれば対応方針を整理し、仕様変更があれば納期や工数への影響を判断する必要があります。

顧客や上司から状況説明を求められる立場にもなります。本人が直接起こした問題ではなくても、チームの問題として説明を求められるため、責任の感じ方は大きく変わります。

ここで注意したいのは、「リーダー」という肩書だけでは実際の責任範囲が分からないことです。

会社によって、数人の進捗確認だけを担当するリーダーもいれば、顧客との金額交渉、協力会社の管理、予算、人事評価まで任される人もいます。

IPAのITスキル標準でも、「プロジェクトマネジメント」と「ITスペシャリスト」は異なる職種として整理されています。

IT人材を単純に「SE」「プログラマ」と括るのではなく、職種や専門分野を分けて評価する考え方です。

そのため、SEリーダーがつらいと感じたときは肩書ではなく、実際に何を任されているのかを見る必要があります。

顧客・上司・メンバーの板挟みになる

SEリーダーの仕事では、複数の立場から異なる要求を受ける場面があります。

顧客は「機能を追加したい」「予定どおりリリースしてほしい」と求め、会社側は採算や要員を考え、開発メンバーは現実的な作業量や品質を考えます。

• 追加要望には対応してほしいが、納期は変えられない
• 残業は減らしたいが、人員追加も難しい
• 品質は落とせないが、リリース日は動かせない

こうした条件の間で着地点を探すこと自体は、プロジェクト管理では珍しい仕事ではありません。

問題になりやすいのは、結果への責任だけを負い、条件を変更する権限を持っていない状態です。

納期責任を負っているのに納期を交渉できない。進捗責任を負っているのに増員を相談できない。品質責任を負っているのに追加要求の優先順位を変えられない。

この状態を個人のコミュニケーション能力だけで解決するのは難しくなります。

私はSEリーダーの負担を見るとき、「責任が重いか」以上に、責任と権限が釣り合っているかを見るべきだと考えています。

技術者なのに実装できなくなることもある

プログラミングや設計そのものが好きでSEになった人にとっては、リーダー昇格によって技術から離れることも大きな負担になります。

会議、レビュー、進捗確認、課題管理、顧客対応、メンバーへの説明が増えれば、自分で実装する時間は減ります。

これは単なる経験不足とは別の問題です。

「管理業務ができるようになれば解決する」とは限らず、本人が仕事のどこに面白さを感じるのかというキャリア上の価値観に関係するからです。

管理能力がある人でも技術を続けたい場合はあります。反対に、高度な技術力がある人が必ずしも予算管理や人事評価を得意とするわけでもありません。

昇進できることと、その仕事を長く続けたいことは別です。

---

「リーダーに向いていない」と感じたSEに何があった？

SEリーダーのつらさを具体的に考える材料になるのが、みやもと氏がQiitaへ2023年12月13日に投稿した「私の『リーダー向いてない』はどこから来たのだろう」です。

「TECH WOMAN KANSAI Advent Calendar 2023」の14日目の記事として公開されたもので、投稿者自身が過去のリーダー・マネージャー系業務を振り返っています。

前提として、これは統計調査ではなく個人の経験談です。そのため、この体験をそのまま「SEリーダーは全員こうなる」と一般化することはできません。

ただし、同じ本人がA社、B社、C社という異なる環境で管理系の仕事を経験し、それぞれ負担の感じ方が変わっています。

そのため、本人の適性だけでなく、仕事内容や職場環境がリーダー業務の負担をどう変えるのかを見る事例として参考になります。

また、投稿者自身も、後から振り返ると経験した仕事は単純なリーダーというより、マネージャー業務に近かったと整理しています。

A社ではプロジェクト管理が退職につながった

みやもと氏は、10年以上前に比較的大きなSIerであるA社へ勤務していました。

中途入社後、しばらく客先常駐で開発を担当していましたが、その後社内へ戻り、プロジェクトのスケジュール作成、協力会社への指示、社外との調整などを担当することになります。

それまでの現場では、期限までに自分の成果物を完成させることが中心でした。

ところが管理側へ移ると、作業ごとの工数だけではなく、担当者の力量まで考慮してプロジェクト全体の計画を作る必要がありました。

本人は、このプロジェクト全体の作業見積もりに苦戦したと振り返っています。

さらに、ユーザー企業のシステム部門との打ち合わせでは、システム要件だけではなく、金額やスケジュールについても話す必要がありました。

上司は最初の打ち合わせには同席していた可能性があるものの、その後は基本的に同席していなかったとしています。

もう一つ大きな負担になったのが、メンバーへの作業割り振りでした。

作業内容を対面で説明し、複数のメンバーから質問を受けることに強い苦手意識があり、小さな修正であれば自分で作業した方が楽だと考えるようになります。

その結果、上司から製造・テストをしないよう指示されました。

しかし、みやもと氏がSEを選んだ理由の一つは、自分で手を動かしてプログラムを作ることでした。

管理業務に苦戦する中で、楽しみだったプログラミングまでできなくなったことが、A社を退職する決定打になったと振り返っています。

このA社だけを見れば、「プロジェクト管理に向いていなかった」という結論にも見えます。

しかし、その後のB社とC社を見ると、話はそれほど単純ではありません。

B社ではリーダー業務が退職理由にはならなかった

A社を退職したみやもと氏は、職種変更を試みた後、再びSEとしてB社へ入社します。

B社でもリーダーと呼ばれる立場になりましたが、客先常駐の開発要員であり、プロジェクト全体の管理は上位会社が担当していました。

本人の役割は、協力会社から現場へ入る人への説明や必要書類の回収、配下メンバーの管理などが中心でした。

すでに決まっている現場ルールや案件状況を説明する仕事については、自分の考えを組み立てて指示する仕事より比較的対応しやすかったとしています。

配属される人数が少なかったこともあり、質問が集中して対応が滞るような状態になりにくかった点もA社との違いです。

一方、管理職になった後の人事評価には難しさを感じていました。

評価対象となるメンバーは本人と同じ現場におらず、月1回のミーティング、提出書類、報告書など限られた材料から評価する必要があったためです。

それでも、B社を退職した理由については「リーダーにされたから」ではなかったと明記しています。

同じ本人でも、担当する管理業務が変われば結果も変わったわけです。

さらにB社では、A社と違って製造やテストを続けられました。

上司も、本人がリーダー業務へ苦手意識を持っていることを踏まえ、担当人数を少人数から始め、不安を確認しながら任せていたと振り返っています。

C社では教育と上位会社との調整も行えた

その後のC社ではサブリーダーとなり、後輩教育や上位会社との調整を経験しました。

新人や若手へチーム内のルール、開発上の注意点、技術やノウハウなどを伝え、成果物を確認する仕事です。

教育については、本人自身もうまく説明できない場面があり、時間がかかったと振り返っています。

それでもA社時代と比べればコミュニケーションへの苦手意識はやや薄れ、自分以外にも作業できる人を増やす必要性を理解したうえで教育しようとしていました。

上位会社との調整についてもA社とは状況が違いました。

C社の現場では会議が少人数で、相手と顔なじみになる中で、作業内容や納期について相談できていたとしています。

次の案件に向けた要員追加の話が出た際には営業担当へ連携するなど、調整役として一定の役割を担っていました。

さらにB社とC社では、リーダー系業務を担当しながら製造やテストも続けています。

A社では退職につながったのに、B社・C社では管理系の仕事を一定程度続けられた。

この差は、本人の性格だけでは説明できません。

仕事内容、担当人数、実装できる時間、上司からの支援、仕事の範囲、調整相手との関係など、複数の条件が変わっていました。

ここで見るべきなのは、「リーダー向きか、向いていないか」という二択ではありません。同じ人でも役割設計が変われば、仕事への適応の仕方も変わり得るという点です。

---

SEリーダーがつらいときは何を切り分けるべき？

SEリーダーを辞めたいほどつらいときに、「自分はリーダーに向いていない」という一文だけで結論を出すと、転職先でも同じ問題を繰り返す可能性があります。

私は、少なくとも「仕事内容・責任・権限・支援」の4項目へ分解する方法が実務的だと考えています。

確認する軸	確認したい内容	問題がある状態の例
仕事内容	進捗管理、見積もり、顧客折衝、教育、人事評価、実装など	苦手な業務が大半を占めている
責任	納期、品質、利益、障害、メンバー成果のどこまで負うか	問題の最終責任だけ集中する
権限	増員、納期変更、優先順位、顧客要求への回答を決められるか	責任はあるが条件を変更できない
支援	上司同席、PM・PMO、レビュー、教育、相談先があるか	初めての業務でも単独で任される

この4つを分けると、「リーダー適性がない」という曖昧な自己評価から離れやすくなります。

たとえば、進捗管理には対応できても、予算交渉が強いストレスになる人はいます。

後輩教育はできても、自分が日常的に仕事を見ていない社員の人事評価には抵抗を感じる人もいます。

顧客との技術的な仕様調整は問題なくても、契約金額と納期を単独で背負うと負荷が急増することもあります。

特に見落としやすいのが「権限」です。

納期を守る責任があるのに納期を交渉できない。チームの進捗に責任を負うのに人員追加を相談できない。品質に責任を負うのに追加要求を断ったり優先順位を変更したりできない。

こうした状態では、本人が努力して仕事を高速化しても限界があります。

ここは会社名や雇用形態だけでは判断できない部分です。

責任だけが増え、権限と支援が増えていない状態を、自分の努力不足だけで解決しようとする必要はありません。環境を変えることまで含めて検討すべきです。

今の市場価値を確認するなら：客先常駐エンジニアにおすすめの転職エージェント5選

「できない」と「やりたくない」は別に考える

もう一つ重要なのが、経験不足と価値観の違いです。

初めてリーダーになり、タスク分解や進捗管理がうまくできないのであれば、経験不足の可能性があります。

上司からレビューを受けたり、小規模なチームから担当したりすることで改善する余地があります。

一方、「設計やプログラミングを深めたいので、人事評価を主業務にはしたくない」という希望は別です。

これは能力不足ではなく、キャリアで何を主戦場にしたいかという選択です。

IPAのITスキル標準では、IT技術者を「SE」「プログラマ」といった名称だけで包括せず、プロジェクトマネジメント、ITスペシャリストなど複数の職種へ分類しています。

そのため、「管理職へ進まないとエンジニアとして成長できない」と考える必要はありません。

「何が残れば続けられるか」も確認する

A社とB社・C社の違いから、とくに注目したい点があります。

負担を減らすことだけでなく、自分が仕事を続ける理由になる業務が残っているかも確認することです。

みやもと氏の場合、B社とC社ではリーダー系業務を担当しながら、製造やテストも続けられました。

A社では管理業務への負担に加え、プログラミングという本人にとって重要な仕事まで失われています。

これは「嫌な業務が何個あるか」という足し算だけでは捉えにくい部分です。

多少苦手な管理業務があっても、設計や開発など、自分が価値を感じる仕事が一定割合残っていれば続けられる人もいます。

逆に、負担そのものが極端に大きくなくても、仕事の面白さを感じる部分が完全になくなれば退職を考えることがあります。

そのため私は、4項目に加えて「残したい仕事は何か」まで言語化することを勧めます。

「リーダー業務を避けたい」だけではなく、「実装を週の半分程度は続けたい」「人事評価は持ちたくない」「技術仕様の調整なら担当できる」と具体化すると、異動先や転職先を比較しやすくなります。

---

SEリーダーを辞める前・転職前に何をすればいい？

SEリーダーがつらいからといって、最初から「SEを辞める」「IT業界を離れる」まで話を広げる必要はありません。

まず現在の会社で、役割のどこまで変更できるのか確認すると判断材料が増えます。そのうえで改善が難しければ、転職先の仕事内容を同じ軸で比較します。

上司には負荷を業務単位で伝える

上司へ相談するとき、「リーダーがつらいです」「辞めたいです」だけでは、会社側も何を変更すればいいのか分かりません。

まず、次の中に自分に当てはまるものがないか見てください。

• 進捗管理と顧客対応が増え、設計・実装時間をほとんど確保できない
• 納期責任を負っている一方、増員や納期変更を自分では判断できない
• 複数案件を同時に担当し、課題管理まで追いつかない
• 人事評価を担当しているが、対象者の日常業務を直接確認できない
• 初めて予算や納期を顧客と調整するのに、上位者の同席やレビューがない
• リーダー業務と実装業務が両方フルに積まれている

当てはまるものがあれば、「何を減らしてほしいか」まで言うと話が進みます。たとえば、こんな言い方です。

• 進捗管理と顧客対応で一日が終わる場合：「進捗管理と顧客対応で一日が終わり、設計の時間が取れません。顧客との定例だけ、どなたかに出てもらえませんか」
• 納期責任だけある場合：「納期を負っているのに、増員や納期の変更を決める権限がありません。判断が要るときに相談できる人を決めてください」
• 複数案件を持っている場合：「2つの案件を同時に持っていて、課題の管理が追いつきません。どちらかを外してもらえませんか」

ほかの負荷も、同じ形で「何が起きているか」と「どうしてほしいか」をセットにすれば伝わります。

ここまで具体化すれば、会社側も担当人数を減らす、上司が顧客会議へ同席する、実装工数を確保する、管理業務の一部を別担当へ移すといった対応を検討しやすくなります。

相談した結果、役割を調整できる会社なら、退職せず改善する可能性があります。

反対に、責任範囲や優先順位を確認しても明確にならず、「リーダーなのだから全部やるべき」と処理される場合は、その対応自体が今後を判断する材料になります。

プレイングリーダーが合う場合もある

A社とB社・C社の違いの一つは、製造やテストを続けられたかどうかでした。

そのため、管理業務そのものをすべて避けたいわけではなく、「技術から完全に離れるのが嫌」という人には、プレイングリーダーが合う可能性があります。

ただし、「プレイングリーダーなら技術も管理も経験できて理想的」と単純には言えません。

管理責任を持ったまま通常の実装工数まで割り当てられれば、二つの仕事を同時に抱えるだけになるからです。

求人や異動先では「実装できるか」だけではなく、実装と管理の想定割合、担当人数、障害時の責任範囲まで確認した方がよいでしょう。

技術スペシャリストへ進める会社か確認する

管理職以外のキャリアが用意されている企業なら、技術を軸に働き続ける選択肢もあります。

IPAのITスキル標準でも、プロジェクトマネジメントとITスペシャリストは異なる職種として扱われています。

したがって、管理職にならないことと、エンジニアとして成長しないことは同義ではありません。

ただし、会社に「スペシャリスト職」という名前があるだけでは十分ではありません。

技術職のまま等級や報酬を上げられるのか。評価項目が明文化されているのか。実際にそのキャリアを歩んでいる社員がいるのか。

ここまで確認したいところです。

制度上は専門職コースが存在しても、実際には管理職にならなければ待遇が上がりにくい企業であれば、数年後に同じ問題へ戻る可能性があります。

転職すればSEリーダーのつらさは解決する？

転職によって改善する可能性はあります。

ただし、「SESから社内SEへ」「SIerから自社開発へ」と職種名や企業形態を変えるだけでは、同じ負担を避けられるとは限りません。

私は「社内SEなら調整業務が少なくて楽」と一括りにするのは適切ではないと考えています。

社内SEでも、利用部門との要件調整、経営層への説明、外部ベンダーの管理、予算管理、システム刷新プロジェクトの推進などを担当することがあります。

SIerやSESで「顧客・上司・開発メンバー」の間にいた人が、事業会社へ移った後は「利用部門・経営層・ベンダー」の間に立つこともあります。

調整の相手が変わっただけで、仕事の構造がほとんど変わらないケースもあるわけです。

そのため転職先を見るときは、会社名や「社内SE」「自社開発」といった求人タイトルだけではなく、実際の役割を確認する必要があります。

具体的には、プロジェクト管理の割合、見積もり・予算責任、人事評価の有無、実装時間、PMや上位管理者の存在、納期や要員に対する裁量などです。

フリーランスも同じです。

開発担当として参画する案件もあれば、チームリーダー、PM、PMO、顧客調整まで求められる案件もあります。

雇用形態を変えるだけで、自動的にマネジメントから離れられるわけではありません。

転職で同じ問題を繰り返さないためには、「どこへ移るか」より「次は何を担当し、何を担当しないのか」を確認する方が重要です。

---

考察｜SEリーダーのつらさは「適性」より役割設計を見るべき

ここからは私見です。

SEリーダーがつらいという話になると、「コミュニケーション能力が低い」「人を動かすのが苦手」「リーダーの器ではない」と、原因を本人側へ集めすぎることがあります。

もちろん、見積もり、説明、交渉、教育、タスク管理にはそれぞれスキルが必要です。経験を積めば改善できる部分もあります。

しかし、みやもと氏のA社・B社・C社の比較を見ると、「本人にリーダー適性があるか」という二択だけでは説明できません。

A社では管理業務が退職の大きな要因になった一方、B社ではリーダーになったこと自体は退職理由ではありませんでした。

C社では後輩教育や上位会社との調整まで担当しています。

本人の性格だけでなく、仕事内容、担当人数、実装の有無、上司からの支援、担当範囲、調整相手との関係が変わっています。

私は、SEリーダー問題で最初に疑うべきなのは本人の人間性ではないと思います。「個人の適性」と「役割の設計不良」を混同しないことが重要です。

納期責任を負わせるなら、優先順位やスケジュールについて相談・調整できる余地が必要です。

メンバーの成果へ責任を持たせるなら、作業を割り振る権限や、人員について相談できる仕組みが必要です。

初めて顧客との金額・納期交渉を任せるなら、上司の同席やレビューなど、段階的に経験できる支援がある方が合理的です。

後輩教育を任せるなら、教育に使う時間も工数として考えなければ、通常業務へ仕事を単純に上乗せすることになります。

責任だけを追加し、裁量も支援も増やさないのであれば、経験のあるSEでも疲弊する可能性があります。

これは「厳しい仕事だから成長できる」という話とは分けて考える必要があります。

もう一つ、私が重要だと考えるのは、技術が得意な人の次のキャリアを自動的に管理職へ接続しないことです。

開発者として成果を出す能力と、複数人の仕事を設計して動かす能力では、重なる部分もあれば異なる部分もあります。

プロジェクトを動かす人、特定技術を深める人、顧客と技術者をつなぐ人、事業部門とITをつなぐ人、後輩育成を得意とする人。

ITの仕事で価値を出す方法は一つではありません。

その意味でも、「リーダーがつらい＝SEとして先がない」と考えるのは早すぎます。

そして今回の事例から、もう一段踏み込んで見るべきポイントがあります。

キャリア判断では、苦手を減らすだけではなく、自分が仕事を続ける理由になっている業務を残せるかまで確認することです。

A社では管理業務への負担だけでなく、本人が好きだったプログラミングまでできなくなりました。

B社・C社では苦手な管理業務が残っていても、製造やテストを続けられています。

負担をゼロにできなくても、自分が価値を感じる仕事が残れば継続できる場合があります。

反対に、苦手な仕事がそれほど多くなくても、自分が面白いと感じる仕事が完全になくなれば、働き続ける意味を見失うことがあります。

だから私は、SEリーダーが辞めたいと感じたときは、「何が嫌か」だけでなく「何なら残したいか」まで書き出すべきだと考えます。

SEを辞めたいのではなく、予算管理を担当したくないのかもしれません。

リーダーそのものが嫌なのではなく、人事評価を持ちたくないのかもしれません。

顧客対応が嫌なのではなく、決裁権がないまま納期交渉だけ任されることが苦しいのかもしれません。

マネジメントそのものが嫌なのではなく、プログラミングを完全にやめることが嫌なのかもしれません。

ここまで分解できれば、選択肢は「耐える」か「退職する」だけではなくなります。

担当人数を減らす、顧客交渉に上司へ同席してもらう、別プロジェクトへ異動する、プレイングリーダーへ移る、技術スペシャリストを目指す、別企業で開発職を続ける、事業会社側へ移る。

どの選択肢が適切かは、人によって異なります。

SESから別の働き方へ移る場合も同じです。

重要なのは「SESだからつらい」「社内SEなら解決する」と会社形態だけで判断することではありません。

誰が顧客と話すのか。誰が納期を決めるのか。誰が要員を決めるのか。問題が起きたときに誰へ相談できるのか。技術者として手を動かす時間は残るのか。

こうした役割分担を確認する方が、次の環境を選ぶ判断には再現性があります。

まとめ｜SEリーダーがつらいなら「役職」ではなく中身を確認する

SEリーダーがつらくて辞めたい背景には、工数見積もり、進捗管理、顧客折衝、メンバー教育、人事評価、責任の増加、そして技術から離れることへの葛藤があります。

ただし、つらいからといって「リーダーに向いていない」「SEそのものに向いていない」と即断する必要はありません。

みやもと氏の事例では、A社ではプロジェクト管理、顧客との金額・納期調整、作業割り振り、製造・テストの禁止などが重なり、退職につながりました。

一方、B社では担当範囲が比較的明確で、少人数から仕事を任され、製造・テストも継続できました。C社では後輩教育や上位会社との調整も経験しています。

同じ人物でも環境によって結果が違う以上、見るべきなのは適性だけではありません。

まず「仕事内容・責任・権限・支援」を分け、そのうえで「自分が残したい仕事」も明確にすることが重要です。

経験を積めば改善できそうな業務なのか。今後も主業務にはしたくない仕事なのか。現在の会社で調整できる問題なのか。会社を変えなければ構造的に変わらない問題なのか。

ここまで整理すれば、異動、担当変更、プレイングリーダー、技術スペシャリスト、別企業の開発職、社内SEなどを比較できます。

辞めるか残るかを急いで決める前に、「SEを辞めたいのか、それとも今のリーダー業務を辞めたいのか」まで分解することが最初の判断です。

---

よくある質問

SEリーダーがつらいのは能力不足だからですか？

能力不足だけが原因とは限りません。

SEとして必要な設計・開発能力と、見積もり、工数管理、顧客折衝、人材育成、人事評価などで必要な能力は異なります。

さらに、担当人数、責任範囲、裁量、上司からの支援によっても仕事の難易度は変わります。

「自分は能力がない」とまとめる前に、どの業務で負荷が発生しているかを分けて確認した方がよいでしょう。

リーダーを辞めたらSEとしてのキャリアは終わりますか？

リーダー職を外れるだけで、SEとしてのキャリアが終わるとは言えません。

IPAのITスキル標準でも、プロジェクトマネジメントとITスペシャリストは異なる職種として整理されています。

管理職以外で評価を上げられる制度が自社にあるか、転職先に専門職コースがあるか、その制度を利用している社員が実際にいるかを確認すると判断しやすくなります。

SEリーダーが嫌なら社内SEへ転職すれば解決しますか？

社内SEへの転職で改善する人はいますが、「社内SE」という職種名だけでは判断できません。

事業会社でも、利用部門との調整、予算管理、ベンダー管理、プロジェクト推進などを担当する場合があります。

転職先では、管理業務の割合、人事評価の有無、実装できる時間、上位管理者の有無、納期や要員に対する裁量まで確認した方がミスマッチを防ぎやすくなります。

執筆：新海 智也