AIがコードを書く時代、エンジニアの責任範囲が本質的に変わる

岡藤：皆さん、AIを使っていますよね。AI駆動開発も、弊社ではたくさん行っています。コードを書く部分は、今や人が書くというより、AIが書くことが本当に増えてきました。

以前は設計・仕様の検討から1行1行のロジックの実装、エラー解消、テストコードまで、すべてを人間が手動で記述していました。今は人間が指示を出し、AIが秒速でコードベースを生成します。Cursor、Claude Code、GitHub Copilot、Devinといったツールが主要な開発AIとして定着し、エンジニアは生成されたコードのアーキテクチャやセキュリティ品質をレビューする側にシフトしています。



ただ、変わったのは実装速度だけではありません。AIに実装を任せるとはいえ、設計やアーキテクチャを組むところは人間がちゃんと責任を持つべきです。そして実装されたものを人間がレビューするという流れの中で、エンジニアの責任範囲そのものが、本質的に変わり始めています。AIが実装してきたものをレビューする際、どれだけ早く済ませられるかは、自分自身の知識を持ってある程度正解を持ちながらレビューできるかどうかに大きく影響します。AIはコードを書く助けをしてくれますが、その出力の正しさを判断する知識と目は、依然として人間が持ち続ける必要があります。

「開発してほしい」から「成功させてほしい」へ。相談の内容が変わった

私たちはクライアントワークの事業をしています。エンジニアとしてはお客様から仕事をいただき、プロダクト開発をしたり、エンジニアリングリソースを提供したりすることが中心です。以前よくあったのは「エンジニアを増やしたい」「開発リソースが欲しい」という相談でした。とにかく急ぎで開発の手が足りないので優秀な技術者をアサインしてほしい、仕様書通りにきれいでスピーディーな実装ができる体制がほしい、という内容です。

直近では、AIが入ってきたことによって相談の内容が変わってきています。今の相談は大きく2種類あります。

1つ目は戦略・プロダクト設計から入ってほしいというもので、何を作るべきか、どこから着手すべきか、というところから一緒に考えてほしいという依頼です。こちらは以前からよくご相談はあったものの、引き続きあるというイメージです。

2つ目はAI活用・プロセスについてで、こちらが特に増えている印象です。AI駆動開発を取り入れたいが効率が出るようなプロセス設計のところから入ってくれないか、というものです。



一言で言い表すと、「開発してほしい」から「成功させてほしい」への変化です。
AIによって「作る」スピードが極限まで上がったからこそ、その前段にある「何を作り、どう成功させるか」の比重が圧倒的に大きくなっています。クライアントが求めるのは、単なる実装の「量」ではなく、事業にコミットしたプロセスの「設計能力」と「価値の最大化」へとシフトしているのです。

AI時代に価値が上がる4つの領域

AIが得意なのは「どう作るか（How）」です。ロジックのコーディング、テストの作成、最適化、バグ発見など、定義された手順の超高速実行はAIが担うようになりました。一方で、人が担うべきは「何を作るか（What）」と「なぜ作るか（Why）」の領域です。

特に今の時代に価値が高まってくる4つの領域として、問題設定、意思決定、トレードオフ判断、プロセス設計を挙げています。問題設定は、そのプロジェクト・プロダクトにおける根本的な課題は何かを突き止めることです。意思決定は、不確実な状況の中でも進むべき方向性を決める力。トレードオフ判断は、品質・時間・コスト・技術的負債のバランスを天秤にかける力。そしてプロセス設計は、AI開発を組み込んだ最適なチームフローを作る力です。




これらの領域は、AIがどれだけ進化しても人間が責任を持つべきものです。技術的な意思決定やトレードオフ判断においても、知識として持っておかなければならないことはたくさんあります。インフラ的なトレードオフも、フレームワーク選定もそうで、そこをAIに完全に委ねることはできません。タスクレベルでも意思決定と判断の連続であり、自分の中にある知識と技術的な確信が、作業スピードと品質の両方を支えています。

「価値創造の当事者」を育てる。Sun Asteriskのビジョンとコアバリュー

こうした状況の中で、私たちSun Asteriskは今年、エンジニアとして目指すべき方向とコアバリューを改めて定義しました。方向を決めることで初めて、どういう方向に育成していくか、どういう人を採用していくかが決まるからです。

我々Sun AsteriskのVisionは「誰もが価値創造に夢中になれる世界」、Missionは「本気で課題に挑む人たちと、事業を通して社会にポジティブなアップデートを仕掛けていくこと」。そしてCore Valueとして定義したのが、「顧客と共に価値を創り、プロダクト開発を牽引するエンジニアリングを追求する」というものです。




単にコードを書けるエンジニアを育てたいわけではありません。自ら課題を見つけ、解決し、価値を生み出す「価値創造の当事者」を増やしたいのです。こうすることで、ただ実装をするだけにとどまるのではなく、もっと広い領域でプロダクトに対してのプロフェッショナルとして伴走できる、そういうキャリアの幅を増やしていけると考えています。

BTC一体型設計。専門性を分断しないチーム構造

このコアバリューが生まれた背景には、Sun Asteriskが持つBTC（Business/Technology/Creative）という組織設計があります。Bがビジネス（事業コンサル・戦略コンサル・ビジネスデザイン）、Tがテクノロジー（エンジニアリング）、Cがクリエイティブ（UI/UXデザイン）を指し、この3つの専門性を持つ人材が同じ会社に存在しています。

Sun Asteriskの「BTC一体型」構造では、コンサル・デザイナー・エンジニアが上流から下流まで最初から同じチームとして共創します。




なぜBTCなのか。価値創造に必要な専門性を分断しないためです。3つの専門性が最初から同じチームとして動くからこそ、意志を持ったプロダクト開発が生まれます。エンジニアにとっては、エンジニアリング以外の事業領域に染み出しやすい環境下に置かれることになります。ビジネスデザイナーやデザイナーと上流から一緒に動くことで、自然と事業目線が身につくのです。

エンジニアが事業に「染み出す」。BTC一体で起きること

BTC一体で動くことによって、エンジニアは早い段階から技術の外側へ、自ずと事業の現場に「染み出す」ようになります。具体的には4つの現場があります。「ユーザー/クライアントの理解」として顧客へのヒアリングに同席し、解決すべき課題にアプローチする。「事業インパクトの検討」としてKPI議論や要件管理に主体的に関わる。「意思決定への寄与」として優先順位判断やロードマップ議論に提言する。そして「要件定義のリード」として、仕様書を受け取る立場ではなく、何を優先して作るべきかを自ら切り出します。




研修や知識インプットといった「育成施策」も、組織の成長において非常に重要です。ただ、毎日の学びを日常で実践し、他領域へ「染み出す」最初の一歩を容易にするのが、この「BTC一体の現場構造」という環境です。構造そのものが染み出しのトリガーになる。これが私たちSun Asterisk らしさの根幹にあります。

オーナーシップは「提案」に現れる。現場のリアルなケーススタディ

具体的に現場でどういった最初の一歩が踏めるのかを、実際の事例をもとにお話しします。

あるメンバーとのやり取りです。スプリントプランニングの後に「クライアントに優先順位を確認してきました」という報告がありました。一見、要件確認をきちんと行ったように見える対話ですが、私はここで「なぜ（そのまま相手の言う通りに）聞いたの？」という問いかけをしました。そのとき、クライアントはすでに多くの前提情報を共有してくれていました。今取り組んでいる事業の状況、エンドユーザー・現場からのフィードバック、今後の市場需要と戦略の方向性、チームとして目指したいロードマップ。これだけの情報があるのであれば、「提案できたはず」というのが私からのフィードバックです。




技術の観点から優先順位を「提案」できたはず。実現可能性に基づいた実装計画を「提案」できたはず。事業成功を最速にするロードマップを「提案」できたはず。この対話は、一見「要件確認」をしっかり行ったように見えますが、主体性の重要な分岐点が隠されているのです。

多くのエンジニアの動き方は、優先順位を聞いて、指示された仕様書・スケジュールに沿って開発を実行するというものでした。これをステップ1で事業を理解し、ステップ2で優先順位を自分で考え、ステップ3でロードマップを描いた上で、ゴールとして「提案する」という動き方に変えていく。情報をただ「受け取る側」から、当事者として「提案する側」に移行することが、すべての成長のトリガーになります。




エンジニアが事業に染み出す最初の一歩は、「提案する責任」を持つことから始まります。自分ごとにプロジェクト・プロダクトのことを考えられれば、そういった提案もできるようになっていく。まず、そこが私たちの考えるエンジニアが事業に染み出していくオーナーシップを持っていく最初の一歩です。

オーナーシップが成長を生む。責任範囲の拡張がスキルをドライブする

私が見てきた優れたエンジニアの共通点には、「自分の役割を自分で規定せず、はみ出していく」というものがあります。

責任範囲の拡張には4つのステージがあります。STAGE1は担当タスクの遂行。STAGE2は担当機能のクオリティ担保。STAGE3は担当プロダクトの価値最大化。そしてSTAGE4が顧客の事業成功です。技術的なタスクの完了をゴールとするのではなく、「この機能、このプロダクトがどう顧客のビジネス成長に繋がるか」に責任を持つことで、視座が一段高くなり、結果として非連続なスキル成長が生まれます。




スキルを覚えてから範囲を広げるのではありません。責任範囲を先に広げる（＝染み出す）からこそ、必要なスキルがドライブされるのです。お客様から「あの人と一緒であれば、このプロジェクトを一緒にやりたい」と直接言ってもらえるようなエンジニアは、こういったオーナーシップを持って動いているメンバーです。

AI時代に輝く3つのポテンシャル

では、こうしたエンジニアを育てるために、私たちが採用・評価においてポテンシャルを感じる力はどこにあるのか。AI時代だからこそ本質的な価値が輝く「3つの力」として整理しています。




1つ目は「エンジニア基礎力」です。
AIがコード生成を行うからこそ、その「正しさ」や「アーキテクチャの妥当性」を見極める確かな技術的土台が求められます。システムアーキテクチャの妥当性設計、データベース設計、セキュリティ品質の見極め能力といった技術的な本質理解と、AIが秒速で生成したコードをレビューする力、言語・フレームワークの採用判断やトレードオフを取る能力が必要です。設計の概念を先に理解していることで、初めて触れる技術スタックでもコードをたどることができ、品質を担保する視点が生まれます。

2つ目は「意志力・オーナーシップ」です。
指示待ちではなく、顧客やプロダクトの成功を自分事として捉え、自らはみ出して「提案」し推進する主体的な姿勢です。意志を体現する4つのスタンスとして、主体性、当事者意識、越境する姿勢、提案する姿勢を定義しています。

「情報や仕様が足りないのではない。自分事として捉え、考え抜くかどうかが境界線」。私たちがメンバーに期待したいのは、単に仕様を実現することにとどまらず、意志を持って顧客のビジネスロードマップを前進させることにあります。

3つ目は「実行計画力」です。
アイデアを「価値」に変える力と位置付けています。どんなに優れたビジョンやアイデアがあっても、それを現実の開発プロセス・スケジュール・体制に分解し、チームを推進してデリバリーできなければ価値につながりません。。優先順位設計、開発プロセス設計、リスクマネジメント、顧客の事業マイルストーンに整合したロードマップ策定が含まれます。完成するまでのイメージを自分の中で引けるかどうか、その計画からリスクを見つけて優先順位を設計できるかどうかが、この力の根幹です。

「助っ人CTO」へ。AI時代のエンジニア組織とキャリア像

これらの方向性をまとめると、AI時代のエンジニア組織が目指すキャリアパスが見えてきます。STAGE1は実装者（Coder/Developer）としてコードを書く段階。STAGE2はプロジェクトリード（Project Lead）として、クライアントと同じ視点に立ち、技術力をもって事業計画とプロダクト設計を往復しながら最速で価値創造プロセスを伴走・牽引します。STAGE3は「助っ人CTO」と呼んでいる動き方で、プロダクトの範囲にとどまらず、エンジニアリング組織や事業の方向性からアドバイスとして入ります。STAGE4が「価値創造を牽引する人材」です。




コードを書くスピードだけでは差別化できないAI駆動開発時代において、「単にプログラミングする人」ではなく「テクノロジーをもって事業価値創造を実働推進する当事者」への進化を目指しています。求められるのは、コードを書く人ではなく、価値創造を前進させる人です。

「何を作るか」を任されるエンジニアは、研修で育つのではありません。私たちはAI時代だから組織を変えたのではなく、顧客と共に価値を創り、プロダクト開発を牽引するために組織を作ってきました。その結果として、AI時代に求められる人材像と重なったのです。AI時代に価値が高まるのは、コードをただ書ける能力ではなく、顧客の成功を自分事として捉え、「何を作るか」の意思決定に責任を持てる能力です。顧客価値創造に責任を持つ現場でこそそういった方は育つと考えています。

アーカイブ動画・発表資料

イベント本編は、アーカイブ動画を公開しています。また、当日の発表資料も掲載しています。あわせてご覧ください。

▼動画・資料はこちら
エンジニアの役割の変化に向き合うConference

※動画の視聴にはFindyへのログインが必要です。