AI時代のキャリアプラン「技術の引力」からの脱出と「問い」へのいざない / tech-gravity

こちらのイベントの登壇資料です

実装だけ考えればよい時代は終わった ── ミノ駆動さんが斬る！エンジニアの思考を止める技術の引力
https://techplay.jp/event/990059

Transcript

1. © DMM © DMM AI時代のキャリアプラン 「技術の引力」からの脱出と 「問い」へのいざない 2026/02/02 TECH PLAYまつり 合同会社DMM.com ミノ駆動
2. © DMM 自己紹介 ミノ駆動 ( @MinoDriven ) 合同会社DMM.com プラットフォーム開発本部 第3開発部 • コード品質チーム • PF-AX戦略グループ（兼務） 2
3. © DMM 3
4. © DMM 4 下記システムがDMMサービス全体の技術基盤となっています
5. © DMM コード品質チーム 正式名称： プラットフォーム開発本部／第3開発部／ Developer Productivity Group／コード品質チーム ソフトウェアの開発生産性向上に関する取り組みには、 開発プロセスの改善や自動化などがあります。 コード品質の改善によって開発生産性向上を図るのが 本チームのミッションです。 5
6. © DMM PF-AX戦略グループ 正式名称： プラットフォーム開発本部／第3開発部／ PF-AX戦略グループ プラットフォーム開発本部全体の 開発のAX（AI-Transformation）を担う組織です。 開発プロセスのAI化やAI技術検証、組織への展開などを行い、 AIによる組織的な開発生産性向上を狙います。 6
7. © DMM 著書紹介 『改訂新版 良いコード／悪いコードで学ぶ設計入門』 変更容易性の高い設計を学ぶ、 初級〜中級向け入門書 初版は12刷重版 初版：ITエンジニア本大賞2023大賞受賞 改訂版：ITエンジニア本大賞2026ベスト10入り 台湾版、韓国語版でも翻訳出版 7
8. © DMM ここからが本題
9. © DMM AI駆動開発の流れは止められない 2025年が「AI元年」と呼ばれるように、 AIエージェントの登場により開発の在り方が一気に変化しました。 AI駆動開発の波は避けられません。 AIを活用しないという選択は、 競合他社がAIで価値を高める中で、競争力の低下を招きます。 AI導入はソフトウェア開発において不可避な流れと言えます。 9
10. © DMM AIによる自動化と不安 ソフトウェア開発は「AIに実装させて人間がレビューする」 という方法にどんどんシフトしてきています。 こうしたAIへ仕事が置き換わっていく状況に 「AIに仕事を奪われるのでは」 「私たちの仕事はこれからどうなっていくのか」 「機械がオラたちの仕事を奪うだ！ネオラッダイト運動だあああ！！」 という不安を覚える人は少なくないと思います。 特に新卒や若年エンジニアにこうした不安が多いと聞きます。 10
11. © DMM エンジニアの役割変化 こうした流れにおいて、エンジニアの働き方や成果、 要求されるスキルは変化していくことが必至です。 ではどう変化していくのでしょうか。 どう変化するかを理解するには、 まずソフトウェア開発のプロセス全体を俯瞰する必要があります。 11
12. © DMM 12 要求定義 要件定義 設計 実装 よくある一般的な ソフトウェア開発プロセス
13. © DMM 13 要求定義 要件定義 設計 実装 設計、実装がAIに 置き換わりつつある
14. © DMM 14 要求定義 要件定義 設計 実装 顧客要求を定義し、AIの成果物が満 たすべき要件の定義へ人間の仕事は 必然的にシフトしていくことになる！
15. © DMM 15 要求定義 要件定義 設計 実装 「要求要件定義もAIに置き換わるの では？」という意見もある。 しかしそれは困難。 「ああしたい」「こうしたい」と要求す るのは誰？人間である。 目的や価値は天から降ってきたり AIが決められるものではない。 決められるのは人間だけ。
16. © DMM 16 要求定義 要件定義 設計 実装 【問題定義フェーズ】 人間 ： pilot(操縦士) AI : copilot(副操縦士) 顧客要求や提供したい価値を人間が 定義し、AIが並走しながら人間の考 えをサポートする。 【問題解決フェーズ】 AI ： pilot 人間 : copilot AIが設計実装して、その成果物を人 間がレビューする。
17. © DMM 17 AIの成果物が正しいかどうかレビューする 何をもって正しいとするか、要件を考える仕事になる 要件が妥当かどうか判断するために 顧客要求を理解する必要がある 定義した要求が本当に妥当か検証する必要がある
18. © DMM つまり、どうやっても問題定義フェーズへ 人間の仕事は遷移していきます 望む望まざるにかかわらず、 遅かれ早かれ
19. © DMM あなたならどうする！？！？？ 現状、日本企業のAI導入率は41%程度（他の先進国より低い）、 その中でもAIオールインは一握りだと言われています。 AI技術は日進月歩で、AI導入のハードルはどんどん下がってきています。 開発のAI化が業界的に当たり前になってきたとき、 「あなたはどうするか」という状況に 遅かれ早かれ直面することになります。 さあ、あなたならどうする！？！？？ （めっちゃ煽ります） 19
20. © DMM これからに向けて 将来のキャリアについて悩みや迷いがある人は多いと思います。 ソフトウェア開発のAI化がどんどん進んでいくことが予測される以上、 その未来に向けて備える、というのは、 選択肢のひとつとして考えておいて良いのではないでしょうか。 20
21. © DMM 今後必要になると考えられるスキルの紹介 「AI時代に必要になるスキルは何か」について、 社内外のさまざまな有識者と話し合う機会がありました。 結果、以下のスキルが共通して挙がりました。 • 論理的思考力 • アーキテクトとしてのスキル 以下、これらのスキルを解説していきます。 21
22. © DMM 論理的思考力 論理的思考力とは、複雑な事象を整理し、 筋道を立てて理解や結論を得る思考スキルです。 「そもそも解くべき問題が何であるか」、問題を定義する上で 論理的思考力は必要不可欠です。 22
23. © DMM エンジニアの皆さんは 普段の仕事で論理を扱っているので 論理的思考力があるように思えます
24. © DMM しかし
25. © DMM いざ問題定義しようとすると 上手くできない方が多く見受けられます
26. © DMM 技術観点に留まった考え方 「どんな問題を解決するためにその仕事をしていますか？」 と問われたとき、技術観点でしか回答できないケース。 • 「APIを正しく動作させるためです」 • 「パフォーマンス要件を満たすためです」 • 「そのカラムがNULLだと困るからです」 • 「仕様を満たすためです」 これはこれで正しいかも知れませんが、 それによって顧客のどんな問題が解決されるかまで言及していません。 26
27. © DMM 技術的な言葉による対話の弊害 顧客要求やビジネスの議論をしている際、 即座に技術用語に置き換えて話し始めるケース。 • 「ああ、それは◯◯テーブルの▲▲カラムのことですね」 • 「そういう問題であれば◯◯Infoにフラグ追加すればいけますよ」 エンジニア本人は問題解決の方法を提案しているつもりかも知れません。 しかし使っている言葉が違っているために、意思疎通が困難になります。 そもそも解きたい問題は何かについて目線が合わなくなります。 27
28. © DMM 28 要求定義 要件定義 設計 実装 具体化 抽象化 具体化は得意 抽象化の苦手な 人が多い印象
29. © DMM なぜ（傾向的に）具体化が得意で抽象化が苦手？ 機能要件や仕様を、ソースコードの形に具体化することが 主業務であるからでしょう。 具体的なコードに落とし込むのは素早くできます。 一方でその逆、実装から要件や要求に遡ることは、 具体化に比べて相対的にかなり少ないのではないでしょうか。 29
30. © DMM 30 スキーマ理論 自分が知っている知識や過去の経験に当てはめて 物事を解釈しようとする脳の性質。 「ジャングルの原住民を都会に連れて行ったらどんな反応をするか」という テレビ番組が昔ありました。原住民は電車を指して「なんて巨大なヘビなん だ」と言いました。電車を見たことがないのでヘビと解釈したのです。 エンジニアは技術のことで頭がいっぱいです。 そのため、顧客要求などビジネスサイドの話も、 技術という枠組み（スキーマ）で解釈しようとするクセが働きます。 無意識に。
31. © DMM こうした「弱点」を認知し対策しておかないと 自分の仕事をいざ問題定義フェーズへシフトさせようとしても 上手くいきません
32. © DMM エンジニアの皆さんは技術が好きです 技術の引力が働きます 技術の引力はとても強力で 頭から引き剥がすのは困難です 「技術の囚われ」というジレンマを生みます
33. © DMM 技術を否定しているわけではありません AIの成果物が正しいか判断するには 技術力が必要です、これは事実です 技術を大事にしつつ 技術から離れたものの考え方をしたり 物事を整理する力がこれから必要になってくるのです
34. © DMM 【論理的思考力　その１】 具体と抽象
35. © DMM 具体と抽象を行き来するスキル 抽象化の定義には諸説ありますが、システムは目的達成手段なので、 この定義に則った抽象化を考えを本資料では採用します。 この定義に基づくと、「目的」という切り口で具体と抽象を行き来し、 物事を整理する必要があります。 35 対象物に付随する様々な特徴のうち、 ある目的に合致した特徴のみを抜き出すこと。 (『「具体⇄抽象」トレーニング 思考力が飛躍的にアップする 29問』 著:細谷功, PHPビジネス新書, p.97)
36. © DMM 抽象化は「つまり」、具体化は「たとえば」 抽象化は「つまり」、具体化は「たとえば」で考える。 【抽象化】 「その技術（実装）は、つまりどういう目的のためのものですか？」 「つまりどういう顧客要求のためのものですか？」 【具体化】 「その顧客要求のために、たとえばどのような機能になりそうですか？」 36
37. © DMM 【論理的思考力　その２】 目的−目標−手段
38. © DMM 目的、目標、手段の定義 38 一般的な定義 目的 目指すべき状態、行動のねらい、目当て 目標 何をもって目的達成とみなすかを示す具体条件 手段 目的を達成するための方法や道具
39. © DMM 目的と手段 私たちの活動には、なんらかの目的があります。 そして目的を達成するための手段（行動や方法）を用います。 あらゆる活動が目的−手段の関係で成り立っています。 39 目的 手段 ダイエットしたい 有酸素運動 美味しいものを食べたい 寿司 髪を乾かしたい ドライヤー
40. © DMM 目的と目標 目的の達成について考えてみます。 たとえば「ダイエットしたい」という目的は、 どうしたら達成したと言えるでしょうか。自己満足して終わりですか？ そうではなく体重や体脂肪率について 具体的な条件や基準を定めるはずです。 この具体条件や基準が目標です。 40 目的 目標 ダイエットしたい ・体重を60kgまで減らすこと ・体脂肪率を17%まで減らすこと
41. © DMM 目的−目標−手段 そして目標を満たすために 適切な手段を用います。 目的、目標、手段の関係が右図となります。 目的、目標、手段の関係を適切に定義する ことで、確実に目的達成できます。 41 【目的】 ダイエットしたい 【目標】 ・体重60kgまで減らすこと ・体脂肪率を17%まで減らすこと 【手段】 ・有酸素運動 ・バランスの取れた食事
42. © DMM 目的、目標、手段は、 私たちが開発するソフトウェアでも同じことが言えます。 顧客の要求（目的）をかなえるための手段として、 私たちはソフトウェアを開発しているのです。 42 目的 手段 商品を売買したい ショッピングサイト 動画を視聴したい 動画投稿サイト 遊びたい ゲームソフト 効率良く勉強したい 学習サイト 私たちは「手段」を開発している
43. © DMM 「目標」は要件や仕様に相当する 43 【目的】 注文数を正しく表現したい 【目標】 注文数は1〜200であること 【手段】 目的を満たすソースコード システムを不具合なく的確に機能させるには、 仕様を決める必要があります。 例えば注文数が負数だと不具合になりますし、 5000兆個といった非現実的な数量も 問題があります。 注文数については 出荷業務の都合などを考慮し仕様を決めます。 こうした要件や仕様が目標に相当します。 目標を満たすようにコードを実装します。
44. © DMM 目的、目標、手段は、ソフトウェア開発では次の位置付けと言えます 44 一般的な定義 ソフトウェア開発における位置付け 目的 目指すべき状態、 行動のねらい （顧客の）要求 目標 目的達成の具体条件 機能要件、仕様、制約 手段 目的達成に用いる 方法や道具 ソースコード
45. © DMM 45 要求定義 要件定義 設計 実装 目的 目標 手段
46. © DMM 目的には上位と下位がある 46 商品を売買したい 在庫管理したい 注文したい 配送したい 注文明細の表現 決済したい 上位 下位
47. © DMM 47 自社サービスに 顧客をロックインしたい ショッピングポイントを 使いたい ポイント消費した事実を DBに永続化したい 上位 ポイント発行した事実を DBに永続化したい ショッピングポイントを 発行したい 下位の技術目的から 上位の顧客目的へ 遡る考え方が重要！
48. © DMM 【論理的思考力　その３】 認知バイアスを意識した事象解釈 （認知科学と哲学）
49. © DMM 認知バイアスを意識した正確な顧客要求の理解 認知バイアスに陥ると問題を正しく把握できなくなります。 認知バイアスを意識して正確な事象把握に努めましょう。 【スキーマ理論】 自分の知識や経験に当てはめて物事を解釈しようとする脳の性質。 枠組み（スキーマ）の違いを意識して意思疎通することが肝要。 【言語ゲーム】 言葉の意味は単独では決まらず、文脈によって決まるとする哲学の考え。 同じ「犬」でも「山田さんちの犬」「権力の犬」では意味がまるで違う。 文脈を意識し、顧客要求を正確に理解するよう努めることが肝要。 49
50. © DMM アーキテクトのスキル
51. © DMM 51 要求定義 要件定義 設計 実装 問題定義フェーズの成果物につ いてオーナーシップを持つ職種 ・プロダクトマネージャ ・アーキテクト プロダクト価値最大化を目的に、 プロダクトマネージャ：主に要求 定義に責任を持つ。 アーキテクト：主にアーキテクチャ 構造とシステム要件の定義に責任 を持つ。
52. © DMM アーキテクトの方が技術寄りの性格を帯びているので アーキテクトに関する説明をします
53. © DMM アーキテクチャとアーキテクトを知るには ソフトウェア品質特性について知る必要があります
54. © DMM ソフトウェア開発＝品質特性の作り込み 54 品質特性 説明 品質副特性 機能適合性 機能がニーズを満たす度合い 機能完全性、機能正確性、機能適切性 性能効率性 リソース効率や性能の度合い 時間効率性、資源効率性、容量満足性 互換性 他のシステムと情報共有、 交換できる度合い 共存性、相互運用性 使用性 利用者がシステムを満足に利用できる度合い 適切度認識性、習得性、運用操作性、ユーザーエラー防止性、ユー ザーインターフェイス快美性、アクセシビリティ 信頼性 必要なときに機能実行できる度合い 成熟性、可用性、障害許容性、回復性 セキュリティ 不正利用から保護する度合い 機密性、インテグリティ、否認防止性、責任追跡性、真正性 保守性 システムを修正する有効性や効率の度合い モジュール性、再利用性、解析性、修正性、試験性 移植性 他の実行環境に移植できる度合い 適応性、設置性、置換性
55. © DMM ソフトウェアアーキテクチャとは ソフトウェアとはただ作っても品質特性が向上するものではなく、 なんらかの品質特性を促進するために意図をもって アーキテクチャを設計する必要がある、ということですね。 55 望まれる品質特性やその他の性質を促進するためにソフトウェアをどう構 成するかに対する、重要な設計判断が集まったもの 『Design It!』著:Michael Keeling,訳:島田浩二,2019年刊行,オライリー・ジャパン,p.8より引用
56. © DMM アーキテクチャ代表例 56 アーキテクチャ 寄与する品質特性 クラウドネイティブアーキテクチャ 可用性、スケーラビリティ、拡張性など ゼロトラストアーキテクチャ セキュリティ パイプラインアーキテクチャ 再利用性、性能効率性など ヘキサゴナルアーキテクチャ 変更容易性、テスト容易性
57. © DMM アーキテクトの役割 アーキテクチャを設計する職種…… というのはザックリしすぎているので、私は以下のように定義します。 57 プロダクト価値最大化を目的に、 ソフトウェア品質特性の戦略的全体最適化を担う職種 そして最適化の成果物としてシステム全体の構造を設計したものが アーキテクチャとなります。 この職種定義について、詳しくは後述します。
58. © DMM 58 実装の仕事は人間からAIに移行する どのようなものをAIに作ってもらうのか 機能要件含め品質要件を定義する必要がある 顧客要求を満たすよう 人間が品質要件を定義する
59. © DMM つまり
60. © DMM AI駆動開発が進むほど エンジニアの仕事はアーキテクトの色を帯びてくる アーキテクトとしてのスキルが求められる！
61. © DMM 61 プロダクト価値最大化を目的に、 ソフトウェア品質特性の戦略的全体最適化を担う職種 開発リソースは有限。 全ての品質特性を最大にすることはできません。 また、品質特性どうしがトレードオフになるものもあります。 したがって、どの品質特性に対してコストをかけて向上させるか、 取捨選択する戦略的判断（何かを取り何かを捨てる）が必要になります。 そして、その戦略的判断の軸になるのがプロダクトの価値です。 プロダクト価値が最大化するように、重要な品質特性にはコストをかけ、 それ以外の品質特性にはコストをかけない、という判断をします。
62. © DMM 62 プロダクト価値最大化を目的に、 ソフトウェア品質特性の戦略的全体最適化を担う職種 品質特性には良し悪しがあります。 良し悪しを判断するには、判断可能な知識が必要です。 その知識とは、品質特性の理想状態です。 理想と比較して初めて良いか悪いかギャップを観測できます。 また、品質改善には改善するための技術知識が必要です。 例えば変更容易性については、 「変更容易性の高い構造とはどういう構造か」を知る必要があります。 また、変更容易性を高めるための技法やテクニック（DDD、リファクタリ ング、テストコードetc）を知る必要があります。
63. © DMM 技術知識？技法？テクニック？？ さっき「技術に囚われるな」 みたいなこと言ってませんでした？
64. © DMM 繰り返しになりますが AIの成果物が正しいか判断するには 技術力が必要です 大事なのは 現状の自分の技術力に囚われずに さらに技術力に磨きをかけること そして「そもそも問題の本質は何か」 を考える論理的思考力を身につけること
65. © DMM この発表は 特に何か新しいことは主張していません AIがない時代であっても 技術力を磨いたり 問いを立てる力は大事であったはずです
66. © DMM つまり
67. © DMM 基本こそ奥義
68. © DMM 「当たり前のことを当たり前にやりましょう」 という身も蓋もない話なのです 単にAIの登場によって 「あなた当たり前を当たり前にちゃんとやってきたの？」 が顕在化されただけなのです
69. © DMM 【本日の結論】 基本をすっ飛ばして 「AIで開発を爆速化しよう！！」 など 土台無理なのです 地道に、着実に スキルアップしていきましょう
70. © DMM 70 参考書籍紹介：論理的思考力 具体抽象 の学びに 目的−目標−手段 の学びに 認知バイアス の学びに 目的−目標−手段 で整理し言語化
71. © DMM 71 参考書籍紹介：アーキテクト アーキテクトの仕事の 全体像 アーキテクチャ戦略 全体から実装までの繋がり
72. © DMM ご清聴ありがとうございました