作るコストが小さくなった時代 幸せに働くために改めて考えたいこと 〜エンジニアとして価値を出し続けるために注視している二分野〜

Transcript

1. 作るコストが小さくなった時代 幸せに働くために改めて考えたいこと 〜エンジニアとして価値を出し続けるために注視している二分野〜 中村 友多朗 KDDIアジャイル開発センター株式会社
2. 中村友多朗(@yuppe0328) 自己紹介 所属 ビジネスイノベーション開発1部 趣味 音楽鑑賞、ギター、DJ よくお世話になった技術遍歴 AWS CDK, Terraform, ECS, Remix(React Router), Django 今は数多の制約に心折れかけながらサーバレスアーキテクチャと仲良くなろうとしている
3. このLTの対象者 AIを使って速くたくさん作れるようになったが ... ・自分で何かを作っているという感覚？やりがい？がない ・プロジェクトが楽しくない !! ・AIがほとんどのことをやってくれる時代に自分の 　エンジニアとしての価値ってなんだろう ... と日々考えているあなた
4. ✅ 今日話すこと ・「速く作れる」だけではプロジェクト諸関係者(特に私)の幸せにつながらない ❌ 今日話さない /意図しないこと ・「作れる凄さ」を感じづらい時代に自己肯定感を救う鍵の一つは「センスある意　思決定」 ・エンジニアがプロダクトに関する意思決定に積極的に関わるために勉強するとい　いかも しれない二つの分野 ・AI関連のTipsや技術的な話 ・エンジニアは等しく皆〜すべき！！ということ(それぞれの想いや使命がある) ・二つの分野の詳細な知識や掘り下げ(本当に軽く紹介)
5. 「AIで速くつくって偉いねの時代は終わり」を実感 https://speakerdeck.com/mosa_siru/don-t-build-features-dot-don-t-take -the-easy-way-out (@mosa_siru 榎本 悠介(2026.6.15 LayerX社内資料) 「機能を作るな。楽して作るな。」 ) 強烈だが納得感あるメッセージ ・点として速く作る、アウトプットの誘　惑に 打ち勝たないといけない ・価値を提供し続けるのがプロダクト → 「速く」作れること、もっというと「作れると いうことそのもの」に価値を感じづらい(感じ てもらいづらい)
6. 過去の経験からエンジニアとしてのやりがいを探す① プロジェクトA ・やるべきこととしてタスクが落ちてきて、機能レベルで意見する余　地はほ ぼない (ex.この機能をこういう要件でつくって） ・プロダクトそのものの意思決定に関わる余地はほぼない ・誰がこのサービスを使って喜んでいるのか想像ができない ・設計/技術選定に関する意思決定の自由度はある →プロダクトの直接的な方向性にはあまり関与できないが、エンジニアとしての楽しさは 残されている。ただこの辺りチームに価値が伝わりにくい部分でもある。そして、そもそ も使われない機能の設計を完璧にできても喜ぶ人は少ない
7. 過去の経験からエンジニアとしてのやりがいを探す② プロジェクトB ・良いプロダクトを作ろうと本気になっている人がチームの中にいる ・プロダクトそのものの意思決定に関わる余地がある。(これはなぜ作るのか？　を気 軽に聞ける) ・お客さんの声をチームに届けてくれるPOがいる →もちろん楽しい。これを実現したいならこれぐらいの工数で作れるこうい う機能の方が良いのでは？という提案ができたとき、つくった機能が実 際に使われ、顧客から良いフィードバックを得られる瞬間は特に嬉しい。
8. 今の自分はエンジニアという職業の どこに価値を感じるか
9. お客さんの喜ぶものを作って 喜んでもらった時
10. 喜ぶものを作るには？ →お客さんがどういう体験をしたら、どういうサービス、機能を作ったら喜んでくれるか を知って、それを充足するものを作る。 →今開発して(しようとして)いるこの機能、もしかしたら使われないかも...?誰も嬉しくな いかも...?と感じるセンスを養う？ →センスという目に見えないものではなく、良いプロダクトにはどういう「責務」が必要 かを学ぶ →Product Management /Product Ops
11. ProductOpsとは？(Melissa Perri『Product Operations』より) プロダクトマネジメント機能がうまくスケール（拡張）するのを助けるための規律 戦略の策定、優先順位付け、働き方の効率化に必要な『すべての不可欠なインプット』でチームを囲むこと。 スケールする組織が直面する課題を解決するため、以下の 3つの領域(3本の柱)にフォーカスする。  ビジネスデータとインサイ ト 定量データによる戦略的意思決定 の支援  顧客と市場のインサイト 定性データ・ユーザーリサーチの集 約と効率化  プロセスと実践 ツールの標準化と、サイロ化を防ぐ ガバナンス構築 ※本スライドの内容は、メリッサ・ペリ (Melissa Perri)著 『Product Operations』に基づきます
12. なぜProduct Opsか？ →拡大する組織において、PM(プロダクトマネージャー)が本当に集中すべき業務(戦略立 案、顧客との対話等)に時間を割けるように、プロダクトの価値創出のためにのしかかる 様々な業務を巻き取るために生まれた役割 →拡大していない組織でも、客観的なデータをもとにプロダクトの方向性を決めること ができているチームは少ないのではないか？ →多忙なPMに対して、システムから得られる客観的なデータを使った仮説の提示、 日々のユーザー調査の仕組みの効率化 等にアプローチができれば、チームは正し い価値検証のサイクルを高速化でき、その結果より良いプロダクト/機能/体験を作る ことにつながる。そしてお客さんにも、PMにも感謝されたい。
13. 喜ぶものを作り 続けるには？ →常にお客さんが喜ぶサービスにし続ける、PMの戦略を実現し続けるためには、それ らの活動に時間を割けるのが望ましい。ただ運用が始まるとそうも言っていられな い... →運用が始まると現れる一番の邪魔は何か？ →システムの障害、インシデント対応、運用作業 →SRE(Site Reliability Engineering)
14. SRE(Site Reliability Engineering)とは？ → Googleが提唱した、サービスの可用性、レイテンシ、パフォーマンス、効率性、変更管 理、モニタリング、緊急対応、キャパシティプランニングに責任を負い、これらを主にエンジ ニアリングでスマートに解決しようとする取り組みのこと → 上記責務を持ちながら、100%の信頼性を担保しようとするのではなく、お客さんが 満足する可用性の目標を適切に設定して、日々の変更の速度の最大化を目指す。 → システムの健康状態を正しく把握し、許容できるラインとそうでないラインを見極め て、お客さんの満足度(欲しい機能が追加できる。既存機能が満足に使える)を最大化 する役割。
15. 目指す姿：価値創出のサイクルを最大化するプロフェッショナル として歩むことがチームも自分も幸せにする (のでは？) Product Ops と SRE の力を掛け合わせ、持続可能なプロダクトの「価値創出」を実現する 価値あるものを作る力（ Product Ops）と、それを安定して届ける盤石な土台（ SRE）を兼ね備えたエキスパートを目指す。  Product Ops 「正しい価値を作る力」 • 客観的なデータ（定量・定性）に基づく確かな仮説検証の提示 • ユーザー調査やリサーチ仕組み化による検証サイクルの高速 化 • 開発プロセスやツールの標準化、他職種間連携のハブとなる 役割 【狙う効果】 PMが顧客との対話や戦略に完全集中できる環境 作り  SRE 「価値を作り続けるための土台」 • サービスの可用性・信頼性を担保する堅牢なインフラと運用自 動化 • システムの健康状態を見極め、適切なSLO（可用性目標）を策 定 • 障害などの不確実性をコントロールし、日々のデプロイ速度を 最大化 【狙う効果】 運用負荷を最小限に抑え、挑戦的な改善を止めて しまわない土台
16. 各分野始めの一歩になりそうな本 SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支える エンジニアリングチーム (2017 編: Besty Beyer 訳: 玉川竜司） プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける (2020 著: Melissa Perri 訳: 吉羽龍太郎)
17. ご清聴ありがとうございました Have a great engineering life!