穢れた技術選定について

by watany

Embed

Start on current slide

Slide 1

Slide 1 text

つ技穢い術れて選た定に

Slide 2

Slide 2 text

About Me 渡邉洋平(watany) ● 所属：NTTテクノクロス株式会社 ● AWS Ambassadors(2024〜) ● JAWS-UG東京(AWSコミュニティ) 運営 ● 寄稿：CodeZine ○ 仕様駆動開発への期待と誤解 2026年5月2日（土）発売 https://www.sbcr.jp/product/4815636593/ 2

Slide 3

Slide 3 text

モキュメンタリー出典: フリー百科事典『ウィキペディア（Wikipedia）』 > モキュメンタリー（英: mockumentary）は、映画やテレビ番組のジャンルの1つで、フィクションを、ドキュメンタリー映像のように⾒せかけて演出する表現⼿法である。 > 虚構の物語を、あくまでも事実を伝えるドキュメンタリーとして構成する映像⼿法である。 3

Slide 4

Slide 4 text

本講演とモキュメンタリー - 本講演タイトルの元ネタにちなんで、フィクションのスライドから始める https://www.kadokawa.co.jp/product/322404000598/ https://event.shoeisha.jp/devsumi/20260716/session/6900 4

Slide 5

Slide 5 text

ここで⼩話をひとつ 5

Slide 6

Slide 6 text

⼿打ち麺への切替失敗と TDDが採⽤できない理由

Slide 7

Slide 7 text

登場⼈物顧客職⼈店主 7

Slide 8

Slide 8 text

⼿打ち麺を始めようもっと麺の道を極めたいッス！⼿打ち麺追加していいっすか！俺やるッス！顧客職⼈おう、いいぞ！ (うーんどうなるんだろう) 店主 8

Slide 9

Slide 9 text

Take1：賃上げ交渉 9

Slide 10

Slide 10 text

Take1：賃上げ交渉 ‧‧‧最⾼の⼿打ち麺ができたッス！でも仕込みの負担が⼤きくて、今の給料だと厳しいッス！顧客職⼈お前がやりたいって⾔ったんじゃねえか！給料はそのままだ！店主 10

Slide 11

Slide 11 text

Take1：賃上げ交渉スキルに対する満⾜のいく待遇が得られず職⼈は辞めていきました 11

Slide 12

Slide 12 text

Take1：賃上げ交渉(決裂) Take2：賃上げ交渉 12

Slide 13

Slide 13 text

Take2：賃上げ交渉顧客職⼈美味しくなったな。 (通う頻度を上げるほどじゃないけど) 今⽉から同額で⼿打ち麺に代わりました！ (職⼈の昇給分が…) 店主 13

Slide 14

Slide 14 text

Take2：賃上げ交渉 - 職⼈の⽉給を5万円上げるには売上を15万円伸ばす必要がありました。(粗利率約33%と仮定) - 15万円の売上を追加するというのは850円/杯のラーメンを180杯販売したのと同じ⾦額です。 - これは毎⽉の販売数(2000杯)の10%ほどの数字でした。 - ラーメン屋はダメになってしまいました。 14

Slide 15

Slide 15 text

Take1：賃上げ交渉(決裂) Take2：賃上げ交渉(受容) Take3：コスト転嫁 15

Slide 16

Slide 16 text

Take3：コスト転嫁顧客職⼈美味しくなったけど 850円→930円か... トッピングなしでこれだと⾼いなあ。⾏く頻度下げよう店主今⽉から⼿打ち麺に代わりました！ +80円になりますがご容赦ください 16

Slide 17

Slide 17 text

Take3：コスト転嫁 - 職⼈の⽉給を5万円上げるには売上を15万円伸ばす必要がありました。 - 2000杯/⽉でそれを売るには約80円/杯を値上げする必要がありました。 - 値上げに伴い、常連の来店頻度が下がり、利益が下がった結果、⾚字に転落してしまいました。 17

Slide 18

Slide 18 text

Take1：賃上げ交渉(決裂) Take2：賃上げ交渉(受容) Take3：コスト転嫁(失敗) Take4：導⼊⾒送り 18

Slide 19

Slide 19 text

Take4：導⼊⾒送りもっと麺の道を極めたいッス！⼿打ち麺追加していいですか！俺やるッス！顧客職⼈⼿打ち麺に変えても儲からないからそのままだ！店主 19

Slide 20

Slide 20 text

Take4：導⼊⾒送りキャリアを積むことができる待遇が得られず職⼈は辞めていきました 20

Slide 21

Slide 21 text

登場⼈物顧客エンジニアプロマネ 21

Slide 22

Slide 22 text

テスト駆動開発(TDD)をはじめようもっと技術⼒を⾼めたいッス！チームにTDDを取り⼊れていいっすか！俺やるッス！顧客エンジニアおう、いいぞ！ (うーんどうなるんだろう) プロマネ 22

Slide 23

Slide 23 text

Take1：賃上げ交渉 ‧‧‧TDDを定着させて、チームの開発速度を上げたッス！でもテストの負担が増えて、今の給料だと厳しいッス！顧客エンジニアお前がやりたいって⾔ったんじゃねえか！給料はそのままだ！プロマネ 23

Slide 24

Slide 24 text

Take2：賃上げ交渉 ‧‧‧TDDを定着させて、チームの開発速度を上げたッス！でもテストの負担が増えて、今の給料だと厳しいッス！顧客エンジニアそうだな！⽉給5万円アップだ！プロマネ 24

Slide 25

Slide 25 text

Take2：賃上げ交渉顧客エンジニア良くなったのかな。 (リリース頻度は少ないし追加で払うほどではないけど) 今⽉から同額でTDD による品質担保をしています！(エンジニアの昇給分が…) プロマネ 25

Slide 26

Slide 26 text

Take3：コスト転嫁顧客エンジニア品質は良くなったけど100万/⼈⽉ →115万/⼈⽉か... これだと⾼いなあ。⼈数を調整しよう今⽉からエンジニアの契約単価が+15万円/ ⼈⽉になりますがご容赦くださいプロマネ 26

Slide 27

Slide 27 text

Take4：導⼊⾒送りもっと技術⼒を⾼めたいッス！チームにTDDを取り⼊れていいですか！俺やるッス！顧客エンジニア TDDを採⽤しても儲からないからそのままだ！プロマネ 27

Slide 28

Slide 28 text

Take4：導⼊⾒送りキャリアを積むことができる待遇が得られずエンジニアは辞めていきました 28

Slide 29

Slide 29 text

つまりそういうことなので

Slide 30

Slide 30 text

⼩話(フィクション)のまとめ - エンジニアとしては良い技術選定をして開発を良くしたい - 良い技術選定の例：テスト駆動開発(TDD) - 技術的に良い⽅向が全ての関係者に利益をもたらすとは限らない - 良い技術を採⽤しても待遇が良くなるとは限らない(Take1) - 組織に利益をもたらすとは限らない(Take2) - 組織外に利益をもたらすとは限らない(Take3) - 短期的には現状維持が「マシ」な場合がある(Take4) 30

Slide 31

Slide 31 text

⼩話の意図 - あまり公開事例で聞かない切り⼝を意図した - 技術選定とステークホルダーとの関係 - 技術以外の点でうまくいかなかった - なぜこういった話は公開されないのだろう - ⼤⼈の事情‧他⼈に迷惑の掛かる内容は普通は話されない - 技術選定とは本当に技術を選定するだけなのだろうか - 外部に出てくる『綺麗な』技術選定と現場との距離 31

Slide 32

Slide 32 text

〇〇〇技術選定について 32

Slide 33

Slide 33 text

”積極的な技術選定と消極的な技術選定” 2023年に公開された、鈴⽊僚太⽒(uhyo)のエッセイ https://blog.uhy.ooo/entry/2023-02-13/technology-selection/ 33

Slide 34

Slide 34 text

エッセイの要約(1/4) 技術選定は2種類に分けられる 34

Slide 35

Slide 35 text

エッセイの要約(2/4) 例1：使いたい3rd Partyライブラリが揃っている⾔語を選定する - 積極的選定：エコシステムの状況を考慮した - 消極的選定：ライブラリ代替の実装を避ける例2：”Rustは難しいので採⽤しない” - 積極的選定：所有権システムが解決しようとする問題を取り扱わないので、(複雑さを持ち込まないために)採⽤しませんでした - 消極的選定：Rustの所有権システムをチームメンバが理解するのは難しく、採⽤しませんでした 35

Slide 36

Slide 36 text

エッセイの要約(3/4) 例3：2種類の技術選定が混在し、適切でない例 - メリット：コンパイラのチェックが厳格で、エラーも親切 - ⇒積極的選定 - デメリット：チェックが厳しい分だけ学習コストが⾼い - ⇒消極的選定 36

Slide 37

Slide 37 text

エッセイの要約(4/4) 「積極的」「消極的」：⻑期的利益に対する積極性/消極性 - 積極的な技術選定： - 技術を最⼤限に活⽤して開発効率を⾼める＝⻑期的な利益 - 消極的な技術選定： - 投資より迅速にカネを⽣み出す必要性＝短期的な利益 37

Slide 38

Slide 38 text

〇〇〇技術選定について 38

Slide 39

Slide 39 text

積極的技術選定について or 消極的技術選定について 39

Slide 40

Slide 40 text

”最強の技術”を採⽤するケース “選定してすぐにダメになった ”を防ぐには？特定の言語にフルベットしない、一休の技術戦略 https://levtech.jp/media/article/interview/detail_626/ 40

Slide 41

Slide 41 text

⽊こりのジレンマ - 消極的選定の要因を放置することは「⽊こりのジレンマ」 ○ 斧の⼿⼊れより⽬の前の仕事を優先してしまう - 学習コストはO(1)であり、2回⽬以降は踏み倒せる ○ 「知識は荷物にならない」 - 個々の学習から法則や汎⽤的な知識を得ることで、学習コストすら削減できる ○ 斧の研ぎ⽅に熟練すると、斧を研ぐ時間⾃体が短くなる ■ 2つ⽬のプログラミング⾔語は、最初より早く習得できる 41

Slide 42

Slide 42 text

⽊こりが定着しないケース 42

Slide 43

Slide 43 text

⼈が次々に⼊れ替わる状況で ”最強の技術”を選定できるのか 43

Slide 44

Slide 44 text

学習コストO(1)を前提に置けないケース - 「エンジニア」は⼊れ替わってしまう - 退職‧転職‧昇給‧昇格 - 労務費の転嫁は交渉の余地がある - 受託‧外注：公正取引委員会の周知 - 予算は「⽩紙の⼩切⼿」ではない以上、あくまでビジネスとしての範囲内での調整 - 学習コストの⼤きさで起こる問題 - 教育にかかるコスト - ⼈材の「⽴ち上がり」待ち時間始めませんか？労務費を反映した価格交渉 https://www.gov-online.go.jp/tokusyu/romuhitenka/ 44

Slide 45

Slide 45 text

教育をしない前提の技術選定受注案件の「教育をしない」プロフェッショナリズム - 教育期間を⽤意しなくても能⼒を発揮できる - 担当者交代に耐えうる仕組み作り - キャッチアップしづらい「複雑さ」を採⽤しない 45

Slide 46

Slide 46 text

注) ”べき論”としての教育引⽤：ジュニアを採⽤しない連中はシニアに値しない https://portalshit.net/2018/10/02/we-should-hire-junior-engineers 46

Slide 47

Slide 47 text

⼈材プールを考慮した技術選定 - マイルストーンが決まっており、採⽤に時間をかけられないケース - 準委任契約など、そもそも個⼈の能⼒を選んで採⽤できないケースこういうチームなら集まるかもなあ AWS:× IaC:△ TypeScript:〇 Python:△ AWS:△ IaC:〇 TypeScript:× Python:× AWS:〇 IaC:× TypeScript:× Python:〇 https://www.irasutoya.com/2020/11/blog-post_82.html https://www.irasutoya.com/2017/02/blog-post_18.html 47

Slide 48

Slide 48 text

注) 消極的選定による技術スタック変更の受け取られ⽅解約率0%のシステムを、作り直すことにしました。〜エージェントからfindさんに紹介できません、と⾔われたあの⽇〜 https://note.com/find_info/n/n9a0da3fffd9f https://x.com/suthio_/status/2017056348442415318 48

Slide 49

Slide 49 text

消極的技術選定について？ 49

Slide 50

Slide 50 text

⼆分法的思考 - 最強の技術を”過酷な状況”で貫き通せるか - 過酷な状況での『消極的選定』を知ると、技術選定を⼆元論として扱いたくなる(⼆分法的思考) - 理想：現実 - 技術：政治 - 純粋：打算 - 対⽴軸が⾒つかるとスッキリするが、単純な⼆項対⽴に落とし込んで良いのだろうか？ 50

Slide 51

Slide 51 text

消極的選定は公開されにくい https://www.jspt.or.jp/ebpt_glossary/publicationbias.html 51

Slide 52

Slide 52 text

積極的選定に書かれない動機 https://yong-ju.blog/posts/what-is-cdd 52

Slide 53

Slide 53 text

公開事例の限界情報を公開する経験が増えるほど『公開しない理由』が理解できる - 外部に出る『綺麗な』技術選定と、現場との距離 - 消極的選定を書かない理由がある - 公開が躊躇われる事案、出版バイアス - 積極的選定にも書かれない裏側がある - ⼿段の⽬的化、履歴書(CV)駆動開発 - 裏の裏まで考えて、真実に近づくのは本当に⾯倒くさい - ⾒栄‧政治‧打算‧妥協 - ⼈間が介在するから純粋に技術を選定できないのでは？ 53

Slide 54

Slide 54 text

”エージェントにやらせればいいじゃん” 54

Slide 55

Slide 55 text

⼈間が技術選定をしない世界 https://x.com/yusukebe/status/2058354533517185389 55

Slide 56

Slide 56 text

”on distribution” - Claude Codeの開発者インタビューで話された「モデルが学習済であり、追加説明なしでも安定して扱える技術領域」 >(私訳) 標準から外れた技術スタックであっても、モデルは学習が可能です。しかし、それにはモデルに⼿順を教え込み、多⼤な労⼒を費やす必要があります。私たちが求めていたのは、教える必要のない技術スタック、つまりClaude Codeが⾃⾝で使えるスタックです。そして、それは⾮常にうまくいっています。現在、Claude Codeのコードの約90%は、 Claude Code⾃⾝によって書かれています。 - 語源は”in-distribution”の拡張と想定される ※in-distribution：機械学習の⽤語。モデルがトレーニング中に遭遇するデータであり、モデルの既知ドメイン内の知識になる How Claude Code is built https://newsletter.pragmaticengineer.com/p/how-claude-code-is-built 56

Slide 57

Slide 57 text

LLMの「教育コスト」を考慮する例 - LLMはテキストに強いので、設計書にMarkdownを採⽤する Next.jsやReactなど利⽤者の多いフレームワークを採⽤する後⽅互換性が⾼く、安定して動作させやすいGo⾔語を採⽤する新進気鋭のビルドツールではなくMakeﬁleを採⽤する 57

Slide 58

Slide 58 text

積極的？消極的？エージェントフレンドリーな技術選定はどちらに分類されるか？ - 「積極的」 - AIエージェントのスループットを最⼤化するため - 「消極的」 - 追加知識を与えず扱える、標準的で単純な技術を選ぶため - AIエージェントの学習コストを最⼩化するため 58

Slide 59

Slide 59 text

いつしかエージェントのために技術選定をしている顧客エージェントエンジニア 59

Slide 60

Slide 60 text

つまりそういうことなので 60

Slide 61

Slide 61 text

最強の技術が次々に⼊れ替わる過酷な状況 ● 「AIエージェント」は数か⽉で⼊れ替わってしまう ○ 新モデル‧新ハーネス‧新LLMプロバイダ ○ モデルの退役‧コスト変更に伴う⾒直し ● AIエージェントの学習コストの⼤きさで起こる問題 ○ エージェントのハーネス設計にかかるコスト ○ モデル×ハーネスの「⽴ち上がり」待ち時間 ● 研いだ斧(Skills)は⽊こり(LLM)が⼊れ替わると役に⽴たなくなってしまう ○ 形骸化したSkillsは、知識の制約や過剰なコンテキストとして負債になり得る 61

Slide 62

Slide 62 text

AIエージェントという「定着しない⽊こり」 ● 「後進の育成」VS「AIエージェント採⽤」 ○ どちらも積極的技術選定だが、利益が相反している ○ ”ジュニアを採⽤しない連中はシニアに値しない”が、 AIエージェントを採⽤しない理由はなんだろうか ● エージェント採⽤が全てを良くするとは限らない ○ ハーネス設計が上⼿でも待遇が良くなるとは限らない ○ エージェントに最適化させた環境が利益を⽣むとは限らない ○ 短期的には現状維持がマシな場合がある ● エージェント⾃体の「⼈件費」について ○ GitHub Copilotの完全従量課⾦化 ○ TokenMaxxingの⾒直し 62

Slide 63

Slide 63 text

公開事例にかかるバイアス ● 公開事例では「⼈間が価値を加えた物語」が選ばれやすい ○ エージェントが⼈間より優秀という話は公開されない ○ ⼈間のための儀式(レビュー)の⾃⼰⽬的化 ● エージェントの出⼒にブレーキをかけて品質を⾼めたという、新しいスキルセットをアピールしたい ○ 「積極的」LLMの能⼒を超える判断、知識 ○ 「消極的」LLMの能⼒に合わせた判断、今あるモデル‧ ハーネスへの最適化 63

Slide 64

Slide 64 text

エージェント以後の現在地 ● エージェント以前 ○ ○ ○ ● 積極的な技術選定に注⼒したいが、様々な理由でのすり合わせが必要消極的な技術選定はキャリアを損ねて恥ずかしい。様々な理由で公開したくない消極的な技術選定が公開されないので、公開された積極的な技術選定だけを参考にしても実際の世界に適⽤できないエージェント以後 ○ ○ ○ ⼿数が⾜りないという⾔い訳がなくなり、積極的な技術選定を⾏いやすくなった意思決定や責任は⼈間に残ったため「分からないが技術的に最強」は選定し難い AIネイティブ‧エンジニアファーストでのポジションを取らざるを得ない状況があり、様々な理由で公開できない内容がある 64

Slide 65

Slide 65 text

公開されない(なかった)部分 ● エージェント以前 ○ ○ ○ ● 積極的な技術選定に注⼒したいが、様々な理由でのすり合わせが必要消極的な技術選定はキャリアを損ねて恥ずかしい。様々な理由で公開したくない消極的な技術選定が公開されないので、公開された積極的な技術選定だけを参考にしても実際の世界に適⽤できないエージェント以後 ○ ○ ○ ⼿数が⾜りないという⾔い訳がなくなり、積極的な技術選定を⾏いやすくなった意思決定や責任は⼈間に残ったため「分からないが技術的に最強」は選定し難い AIネイティブ‧エンジニアファーストでのポジションを取らざるを得ない状況があり、様々な理由で公開できない内容がある 65

Slide 66

Slide 66 text

穢れた技術選定について ● エージェントは「究極の定着しない⽊こり」 ● 「様々な理由」を穢れとして恥じ、これまで公開されなかった消極的選定の中にエージェント利⽤の重要なノウハウがあるかもしれない ● 公開され難い「穢れた技術選定」について語る⽅法はあるか ○ ⾮公開‧会員制イベント ○ フィクション(モキュメンタリー) ○ 新たなアウトプット⼿法の確⽴ 66

Slide 67

Slide 67 text

本講演の整理 ● 最強の技術選定を採⽤できず、妥協せざるを得ない場合は存在するが、それらが正しく⽋損なく外部公開されるとは限らない ● エージェントによって積極的技術選定を妨げる学習コストや⼯数は⼤幅に削減され、時間的なハードルは下がった ● 反⾯、新たな学習コストとの闘い‧⼈材育成とのトレードオフ ‧情報公開へのバイアスが発⽣し、未だ解決していない 67

Slide 68

Slide 68 text

その選定理由を、どこにプロットできますか？ 68