"何を作るか "を任される エンジニアは、どう育つのか BTC一体のクライアントワークから設計する、 AI時代のエンジニア組織 株式会社Sun Asterisk Yuta Okafuji * エンジニアの役割の変化への向き合い⽅ Sun* 

Profile 法人営業を経験後、受託開発企業にてエンジニアとしてのキャリアをスタート。 バックエンドからフロントエンド、モバイル、インフラ構築、CMS構築などを担当、コーポ レートサイトやECサイト、モバイルアプリケーションの構築を経験する。お客様と直接やり とりをしつつ、見積や設計、実装、レビュー、テストを担当。 Sun＊に入社後、フロントエンド領域のテックリードとして案件に参画し、Frontendチームの マネージャーに就任。その後バックエンドチームのマネージャーに就任。2024年のベストマ ネージャー賞を受賞。現在は、Division Managerとして、エンジニア組織を統括する。 Works 自社開発チームのリードとして、新機能の要件 定義・見積もり・設計・開発・テスト設計、負 債の解消やコーディング規約の作成等を担当。 HR系サービス開発支援 モダンなアプリケーション開発における技術アド バイザーとして参画。業務アプリを開発するため の共通プラットフォームの開発を支援。 社内開発プラットフォーム開発支援 大手印刷会社 人材紹介サービス 岡藤 裕太 Yuta Okafuji Enginner / Division Manager Creative & Engineering エンジニア ID: @ofuji_engineer 

AIはエンジニアの仕事をどう変えたか コードを書く仕事は劇的に変わった 主要な開発AI: Cursor Claude Code GitHub Copilot Devin BEFORE ⼈が書く 設計‧仕様の検討から、1⾏1⾏のロジックの実装、エラー解消、テストコー ドまですべて⼈間が⼿動で記述していた時代。 AFTER AIが書く → ⼈がレビューする ⼈間が指⽰し、AIが秒速でコードベースを⽣成。エンジニアは、⽣成された コードのアーキテクチャやセキュリティ品質をレビューする側にシフト。 変わったのは 実装速度だけではない エンジニアの責任範囲そのものが、本質的に変わり始めている AI & Engineering 03 / 18 エンジニアの役割の変化への向き合い⽅ Sun* 

私たちが受ける相談も変わった 昔の相談 RESOURCE FOCUS エンジニアを増やしたい 「とにかく急ぎで開発の⼿が⾜りない。優秀な技術者をアサインしてほしい」 開発リソースが欲しい 「仕様書通りにきれいでスピーディーな実装ができる体制がほしい」 今の相談 VALUE FOCUS ① 戦略‧プロダクト設計 何を作るべきか どこから着⼿すべきか ② AI活⽤‧プロセス AIをどう組み込むべきか 開発プロセスをどう設計すべきか クライアントが求めるのは、単なる実装の「量」ではなく、事業に コミットしたプロセスの「設計能⼒」と「価値の最⼤化」へ。 「開発してほしい」から「成功させてほしい」へ AIによって「作る」スピードが極限まで上がったからこそ、 その前段にある「何を作り、どう成功させるか」の⽐重が圧倒的 に⼤きくなっています。 Market Shift 04 / 18 エンジニアの役割の変化への向き合い⽅ Sun* 

AI時代に価値が上がる仕事 AIが得意なこと How どう作るか ロジックのコーディング、テストの作成、最適化、バグ発⾒など、定義された⼿順 の超⾼速実⾏ ⼈が担うこと What 何を作るか Why なぜ作るか 価値が⾼まる4つの領域 01 問題設定 解くべき本質的な課題は何かを突き⽌める 02 意思決定 不確実な状況下で、進むべき⽅向性を決め る 03 トレードオフ判断 品質、時間、コスト、技術的負債を天秤に かける 04 プロセス設計 AI開発を組み込んだ最適なチームフローを 作る AI Era Value 05 / 18 エンジニアの役割の変化への向き合い⽅ Sun* 

* TODAY'S MAIN THEME 「何を作るか」を任されるエンジニアは、 どう育つのか Sun*が実践してきた「BTC⼀体」の組織設計と、現場のリアルから紐解く Sun Asterisk Developer Conference Session Theme 06 / 18 エンジニアの役割の変化への向き合い⽅ Sun* 

私たちが育てたいのはエンジニアではなく価値創造者 VISION 誰もが価値創造に 夢中になれる世界 MISSION 本気で課題に挑む⼈たちと、事業を通して社会にポジティブなアップデートを仕 掛けていくこと CORE VALUE 顧客と共に価値を創り、 プロダクト開発を牽引する エンジニアリングを追求する ビジネス、デザイン、テクノロジーの壁を越え、顧客の事業成功に向けた真のエンジニアリン グを実⾏します。 Our Belief 「単にコードを書く」エンジニアを育てたいのではない。⾃ら課題を⾒つけ、解決し、価 値を⽣み出す「価値創造の当事者」を増やしたいのです。 エンジニアを育てたいのではない。価値創造の当事者を増やした い。 Identity & Philosophy 07 / 18 エンジニアの役割の変化への向き合い⽅ Sun* 

BTC一体という組織設計 ⼀般的な開発組織の構造 Business (ビジネス要件決定) ↓ PM / Spec (要件定義‧設計の伝達) ↓ Engineer (渡された設計の実装) Sun* の「BTC⼀体型」構造 B Business + C Creative + T Technology 3つの専⾨性が最初から同じチームとして共創する なぜBTCなのか 価値創造に必要な専⾨性を分断しないため。 コンサル、デザイナー、エンジニアが上流から下流まで⼀体と なることで、意志を持ったプロダクト開発が⽣まれます。 Organizational Design 08 / 18 エンジニアの役割の変化への向き合い⽅ Sun* 

BTC一体で起きること CORE PRINCIPLE エンジニアは 事業に染み出す 同じチームで動くからこそ、エンジニアは早い段階から技 術の外側へ。⾃ずと事業の現場に⽴ち「何を作るか」に関 わるようになります。 具体的な染み出しの現場 ユーザー/クライアントの理解 顧客ヒアリングに同席し、直接ユーザーの声を聞 き、解決すべき課題にアプローチする 事業インパクトの検討 KPI議論、要件整理に主体的に関わり、技術投資が ビジネス価値に直結するかを検証する 意思決定への寄与 優先順位判断やロードマップ議論にエンジニアの⽴ 場から積極的に提⾔し、プロセスを作る 要件定義のリード 仕様書を受け取るのを待つのではなく、何を優先し て作るべきかを⾃ら切り出す BTC構造が染み出しのトリガーになる 研修や知識インプットといった「育成施策」も、組織の成⻑において⾮常に重要です。 その学びを⽇常で実践し、他領域へ「染み出す」最初の⼀歩を容易にするのが、この「BTC⼀体の現場構造」と いう環境 Team Reality 09 / 18 エンジニアの役割の変化への向き合い⽅ Sun* 

オーナーシップは「提案」に現れる 1on1 DIALOGUE あるメンバー 「クライアントに優先順位を確認してきました」 マネージャーの問いかけ 「なぜ（そのまま相⼿の⾔う通りに）聞いたの？」 ⼀⾒「要件確認」をしっかり⾏ったように⾒える対話。しかし、ここには主体性の重要な分岐 点が隠されています。 クライアントが共有してくれていた前提情報 今取り組んでいる事業の状況 エンドユーザー/現場からのフィードバック 今後の市場需要と戦略の⽅向性 チームとして⽬指したいロードマップ 私からのフィードバック 「それだけ情報があるなら、提案できたはず」 技術の観点から優先順位を「提案」できたはず 実現可能性に基づいた実装計画を「提案」できたはず 事業成功を最速化するロードマップを「提案」できたはず Dialogue Case Study 10 / 18 エンジニアの役割の変化への向き合い⽅ Sun* 

「聞く側」から「提案する側」へ BEFORE 優先順位を聞く 「何をいつまでに作ればよいですか？」とクライアントに指⽰を仰ぐ ↓ 開発する 指⽰された仕様書、スケジュールに沿って開発を実⾏する AFTER STEP 1 事業を理解する STEP 2 優先順位を考える STEP 3 ロードマップを描く GOAL 提案する エンジニアが事業に染み出す最初の⼀ 歩 「提案する責任」を持つこと。 情報をただ「受け取る側」から、当事者として「提案する側」に移⾏することが、すべての成⻑のトリガーになります。 Mindset Shift 11 / 18 エンジニアの役割の変化への向き合い⽅ Sun* 

オーナーシップが成長を生む EXPANSION OF RESPONSIBILITY STAGE 01 担当タスクの遂⾏ ↓ STAGE 02 担当機能のクオリティ担保 ↓ STAGE 03 担当プロダクトの価値最⼤化 ↓ STAGE 04 顧客の事業成功 (Success) 責任範囲が広がる＝成⻑⾓度が跳ね上がる 優れたエンジニアの共通点、それは「⾃分の役割を⾃分で規定せず、はみ出 していく」点にあります。 技術的なタスクの完了をゴールとするのではなく、「この機能、このプロダ クトがどう顧客のビジネス成⻑に繋がるか」に責任を持つことで、視座が⼀ 段⾼く変わり、結果として⾮連続なスキル成⻑が⽣まれます。 責任範囲の拡張が成⻑を⽣む スキルを覚えてから範囲を広げるのではありません。責任範囲を先に広げる（＝染み出す）か らこそ、必要なスキルがドライブされるのです。 Growth Engine 12 / 18 エンジニアの役割の変化への向き合い⽅ Sun* 

私たちは何にポテンシャルを感じるのか AI時代だからこそ本質的な価値が輝く、「3つの⼒」のポテンシャル CAPABILITY 01 エンジニア基礎⼒ AIがコード⽣成を⾏うからこそ、その「正しさ」や 「アーキテクチャの妥当性」を⾒極める確かな技術 的⼟台が求められます。 → 詳細は次のスライドで解説 CAPABILITY 02 意志⼒‧オーナーシップ 指⽰待ちではなく、顧客やプロダクトの成功を⾃分 事として捉え、⾃らはみ出して「提案」し推進する 主体的な姿勢。 → 詳細はスライド15で解説 CAPABILITY 03 実⾏計画⼒ 単なるアイデアに留めず、優先順位を決め、プロセ スを設計し、開発計画やロードマップに落とし込ん でやり切る⼒。 → 詳細はスライド16で解説 Capabilities Evaluation 13 / 18 エンジニアの役割の変化への向き合い⽅ Sun* 

エンジニア基礎力 THE FOUNDATION AI時代でも 技術の⼟台は変わらない 「AIがコードを書く」ということは、開発に技術的判断が不要に なるわけではありません。むしろ、⽣成された成果物の品質を評 価‧保証する能⼒こそが問われます。 「AIを使う時代だからこそ、エンジニアとしての基礎的な思考技 術が不可⽋」 求められる具体的な技術思考 技術的な本質理解 システムアーキテクチャの妥当性設計、デー タベース設計、セキュリティ品質の⾒極め能 ⼒ コード品質の担保 AIが秒速で⽣成したコードを鵜呑みにせず、 パフォーマンス、可読性、耐久性をレビュー する視点 意思決定能⼒ どの⾔語‧フレームワーク、ミドルウェアを 採⽤すべきか、全体のライフサイクルを⾒越 した選定 トレードオフ判断 スピード、コスト、技術的負債のバランスを 取り、事業フェーズに最適なアプローチを選 択する コードが⾃動⽣成される時代だからこそ、「⽣成されたロジックを読み解き、価値をジャッジできる基礎的な技術理解」が重要になります Three Potentials — 01 14 / 18 エンジニアの役割の変化への向き合い⽅ Sun* 

意志力・オーナーシップ OWNERSHIP MINDSET 顧客の成功を 「⾃分事」として捉える エンジニアが技術の枠を越え、プロダクトのユーザーやビジネス 状況に⾃ら関⼼を持ち、コミットする。これがSun*の育むオー ナーシップです。 「情報や仕様が⾜りないのではない。⾃分事として捉え、考え抜 くかどうかが境界線」 意志を体現する4⼤スタンス 主体性 (Proactivity) ⾔われたタスクをこなすだけでなく、「今 チームとして何を解決すべきか」を⾃発的に 探る姿勢 当事者意識 (Responsibility) 「これはビジネス側の問題だ」と線を引か ず、プロダクトのあらゆるバグや価値に責任 を持つ 越境する姿勢 (Cross-boundary) プログラミングに留まらず、UIデザインのUX や、マーケティング‧事業戦略にまで関⼼を 広げる 提案する姿勢 (Proposal-mind) 状況を確認するだけでなく、得られた情報を インプットに「こうすればもっと良くなる」 を打ち出す 私たちがメンバーに期待したいのは、単に仕様を実現することにとどまらず、「意志を持って顧客のビジネスロードマップを前進させること」 にあります。 Three Potentials — 02 15 / 18 エンジニアの役割の変化への向き合い⽅ Sun* 

実行計画力 DELIVERY & PLANNING アイデアを 「価値」に変える⼒ どんなに優れたビジョンやアイデアがあっても、それを現実の開 発プロセス、スケジュール、体制に分解し、チームを推進してデ リバリーできなければ価値はありません。 「実⾏可能なロードマップに落とし込み、プロジェクトをドライ ブする推進⼒」 計画を成功に導くプロセス設計 優先順位設計 事業KPI、MVP設計、デリバリースピードを 総合評価し、最速で価値が出る順番をマッピ ングする 開発プロセス設計 AI⽣成開発の利点を最適にプロセスへ組み込 み、⼿戻りの少ないモダンな推進モデルを構 築する リスクマネジメント 技術的不確実性、要件変更リスクを予測し、 早期のプロトタイピングによる検証計画を設 計する ロードマップ策定 顧客の事業マイルストーンに整合したマイル ストーンを定義し、期待値をコントロールし ながら牽引する 今期⽅針 AIを活⽤したプロダクト開発プロセスを進化させ、プロセス設計で開発を牽引できるSun*エンジニア像を確⽴する Three Potentials — 03 16 / 18 エンジニアの役割の変化への向き合い⽅ Sun* 

AI時代のエンジニア組織 CAREER PATH IN AI ERA STAGE 01 実装者 (Coder / Developer) ↓ STAGE 02 プロジェクトリード (Project Lead) ↓ STAGE 03 助っ⼈CTO ↓ STAGE 04 価値創造を牽引する⼈材 (Value Creator) 求められる本質的な役割のシフト コードを書くスピードだけでは差別化できないAI駆動開発時代において、エ ンジニアの新しいキャリア像として「助っ⼈CTO」を定義。 クライアントと同じ視点に⽴ち、技術⼒をもって事業計画とプロダクト設計 を往復しながら、最速で価値創造プロセスを伴⾛‧牽引するコアメンバーを 組織しています。 「単にプログラミングする⼈」ではなく、「テクノロジーをもって事業価値創造 を実働推進する当事者」への進化。 求められるのは コードを書く⼈ではなく、価値創造を前進させる⼈。 Sun*のエンジニア組織責任者として、この進化を推進し、AI時代における市場唯⼀無⼆のエンジニア像を設計し続けます。 Career & Roles 17 / 18 エンジニアの役割の変化への向き合い⽅ Sun* 

まとめ 01 AIは実装を変えた 「作る」スピードは極限まで⾼まり、実装は⼈の⼿からAI レビューの時代へと移⾏した。 02 オーナーシップが意思決定を⽣む 指⽰を仰ぐ「聞く側」を脱却し、事業を理解して主体的に 「提案する責任」を持つことが成⻑の起点。 03 価値創造への責任が⼈を育てる 「何を作るか」の判断とデリバリーへの深いコミットが、 AI時代に輝く3つの⼒を圧倒的に成⻑させる。 「何を作るか」を任されるエンジニアは、研修で育つのではない。 顧客価値創造に責任を持つ現場で育つ。 私たちはAI時代だから組織を変えたのではありません。顧客と共に価値を創り、プロダクト開発を牽引するために組織を作ってきました。その結果として、AI時代に求めら れる⼈材像と重なったのです。 AI時代に価値が⾼まるのは、コードを書く能⼒ではなく、顧客の成功を⾃分事として捉え、「何を作るか」の意思決定に責任を持てる能⼒です。 Session Summary 18 / 18 エンジニアの役割の変化への向き合い⽅ Sun*