穢れた技術選定について

Developers Summit 2026 summerで話した内容です。
https://event.shoeisha.jp/devsumi/20260716/session/6900

Transcript

1. 穢 れ た 技 術 選 定 に つ い て
2. About Me 渡邉 洋平(watany) • 所属：NTTテクノクロス株式会社 • AWS Ambassadors(2024〜) • JAWS-UG東京(AWSコミュニティ) 運営 • 寄稿：CodeZine ◦ 仕様駆動開発への期待と誤解 2 2026年5月2日（土）発売 https://www.sbcr.jp/product/4815636593/
3. モキュメンタリー 出典: フリー百科事典『ウィキペディア（Wikipedia）』 > モキュメンタリー（英: mockumentary）は、映画やテレビ番組の ジャンルの1つで、フィクションを、ドキュメンタリー映像のように ⾒せかけて演出する表現⼿法である。 > 虚構の物語を、あくまでも事実を伝えるドキュメンタリーとして 構成する映像⼿法である。 3
4. 本講演とモキュメンタリー - 本講演タイトルの元ネタにちなんで、 フィクションのスライドから始める https://www.kadokawa.co.jp/product/322404000598/ https://event.shoeisha.jp/devsumi/20260716/session/6900 4
5. ここで⼩話をひとつ 5
6. ⼿打ち麺への切替失敗と TDDが採⽤できない理由
7. 登場⼈物 顧客 店主 職⼈ 7
8. ⼿打ち麺を始めよう 顧客 店主 職⼈ 8 もっと麺の道を極めたいッス！ ⼿打ち麺追加していいっすか！ 俺やるッス！ おう、いいぞ！ (うーんどうなるんだ ろう)
9. Take1：賃上げ交渉 9
10. Take1：賃上げ交渉 顧客 店主 職⼈ 10 ‧‧‧最⾼の⼿打ち麺が できたッス！ でも仕込みの負担が⼤きくて、 今の給料だと厳しいッス！ お前がやりたいって ⾔ったんじゃねえか！ 給料はそのままだ！
11. スキルに対する満⾜のいく 待遇が得られず 職⼈は辞めていきました Take1：賃上げ交渉 11
12. Take1：賃上げ交渉(決裂) Take2：賃上げ交渉 12
13. Take2：賃上げ交渉 顧客 店主 職⼈ 13 今⽉から同額で⼿打ち 麺に代わりました！ (職⼈の昇給分が…) 美味しくなったな。 (通う頻度を上げる ほどじゃないけど)
14. - 職⼈の⽉給を5万円上げるには売上を15万円伸ばす必要 がありました。(粗利率約33%と仮定) - 15万円の売上を追加するというのは850円/杯の ラーメンを180杯販売したのと同じ⾦額です。 - これは毎⽉の販売数(2000杯)の10%ほどの数字でした。 - ラーメン屋はダメになってしまいました。 Take2：賃上げ交渉 14
15. Take1：賃上げ交渉(決裂) Take2：賃上げ交渉(受容) Take3：コスト転嫁 15
16. Take3：コスト転嫁 顧客 店主 職⼈ 16 今⽉から⼿打ち麺に 代わりました！ +80円になりますが ご容赦ください 美味しくなったけど 850円→930円か... トッピングなしで これだと⾼いなあ。 ⾏く頻度下げよう
17. - 職⼈の⽉給を5万円上げるには売上を15万円伸ばす 必要がありました。 - 2000杯/⽉でそれを売るには約80円/杯を値上げする 必要がありました。 - 値上げに伴い、常連の来店頻度が下がり、 利益が下がった結果、⾚字に転落してしまいました。 Take3：コスト転嫁 17
18. Take1：賃上げ交渉(決裂) Take2：賃上げ交渉(受容) Take3：コスト転嫁(失敗) Take4：導⼊⾒送り 18
19. Take4：導⼊⾒送り 顧客 店主 職⼈ 19 もっと麺の道を極めたいッス！ ⼿打ち麺追加していいですか！ 俺やるッス！ ⼿打ち麺に変えても 儲からないから そのままだ！
20. キャリアを積むことができる 待遇が得られず 職⼈は辞めていきました Take4：導⼊⾒送り 20
21. 登場⼈物 顧客 プロマネ エンジニア 21
22. テスト駆動開発(TDD)をはじめよう 顧客 プロマネ エンジニア 22 もっと技術⼒を⾼めたいッス！ チームにTDDを取り⼊れて いいっすか！俺やるッス！ おう、いいぞ！ (うーんどうなるんだ ろう)
23. Take1：賃上げ交渉 顧客 プロマネ エンジニア 23 ‧‧‧TDDを定着させて、チー ムの開発速度を上げたッス！ でもテストの負担が増えて、 今の給料だと厳しいッス！ お前がやりたいって ⾔ったんじゃねえ か！給料はそのまま だ！
24. Take2：賃上げ交渉 顧客 プロマネ エンジニア 24 ‧‧‧TDDを定着させて、チー ムの開発速度を上げたッス！ でもテストの負担が増えて、 今の給料だと厳しいッス！ そうだな！⽉給5万円 アップだ！
25. Take2：賃上げ交渉 顧客 プロマネ エンジニア 25 今⽉から同額でTDD による品質担保をして います！(エンジニア の昇給分が…) 良くなったのかな。 (リリース頻度は 少ないし追加で払う ほどではないけど)
26. Take3：コスト転嫁 顧客 プロマネ エンジニア 26 今⽉からエンジニア の契約単価が+15万円/ ⼈⽉になりますが ご容赦ください 品質は良くなった けど100万/⼈⽉ →115万/⼈⽉か... これだと⾼いなあ。 ⼈数を調整しよう
27. Take4：導⼊⾒送り 顧客 プロマネ エンジニア 27 もっと技術⼒を⾼めたいッス！ チームにTDDを取り⼊れて いいですか！俺やるッス！ TDDを採⽤しても 儲からないから そのままだ！
28. キャリアを積むことができる 待遇が得られず エンジニアは辞めていきました Take4：導⼊⾒送り 28
29. つまりそういうことなので
30. ⼩話(フィクション)のまとめ - エンジニアとしては良い技術選定をして開発を良くしたい - 良い技術選定の例：テスト駆動開発(TDD) - 技術的に良い⽅向が全ての関係者に利益をもたらすとは限らない - 良い技術を採⽤しても待遇が良くなるとは限らない(Take1) - 組織に利益をもたらすとは限らない(Take2) - 組織外に利益をもたらすとは限らない(Take3) - 短期的には現状維持が「マシ」な場合がある(Take4) 30
31. ⼩話の意図 - あまり公開事例で聞かない切り⼝を意図した - 技術選定とステークホルダーとの関係 - 技術以外の点でうまくいかなかった - なぜこういった話は公開されないのだろう - ⼤⼈の事情‧他⼈に迷惑の掛かる内容は普通は話されない - 技術選定とは本当に技術を選定するだけなのだろうか - 外部に出てくる『綺麗な』技術選定と現場との距離 31
32. 〇〇〇技術選定について 32
33. ”積極的な技術選定と消極的な技術選定” 2023年に公開された、鈴⽊僚太⽒(uhyo)のエッセイ https://blog.uhy.ooo/entry/2023-02-13/technology-selection/ 33
34. エッセイの要約(1/4) 技術選定は2種類に分けられる 34
35. エッセイの要約(2/4) 例1：使いたい3rd Partyライブラリが揃っている⾔語を選定する - 積極的選定：エコシステムの状況を考慮した - 消極的選定：ライブラリ代替の実装を避ける 例2：”Rustは難しいので採⽤しない” - 積極的選定：所有権システムが解決しようとする問題を取り扱わ ないので、(複雑さを持ち込まないために)採⽤しませんでした - 消極的選定：Rustの所有権システムをチームメンバが理解するの は難しく、採⽤しませんでした 35
36. エッセイの要約(3/4) 例3：2種類の技術選定が混在し、適切でない例 - メリット：コンパイラのチェックが厳格で、エラーも親切 - ⇒積極的選定 - デメリット：チェックが厳しい分だけ学習コストが⾼い - ⇒消極的選定 36
37. エッセイの要約(4/4) 「積極的」「消極的」：⻑期的利益に対する積極性/消極性 - 積極的な技術選定： - 技術を最⼤限に活⽤して開発効率を⾼める＝⻑期的な利益 - 消極的な技術選定： - 投資より迅速にカネを⽣み出す必要性＝短期的な利益 37
38. 〇〇〇技術選定について 38
39. 積極的技術選定について or 消極的技術選定について 39
40. ”最強の技術”を採⽤するケース 40 “選定してすぐにダメになった ”を防ぐには？特定の言語にフル ベットしない、一休の技術戦略 https://levtech.jp/media/article/interview/detail_626/
41. ⽊こりのジレンマ - 消極的選定の要因を放置することは「⽊こりのジレンマ」 ◦ 斧の⼿⼊れより⽬の前の仕事を優先してしまう - 学習コストはO(1)であり、2回⽬以降は踏み倒せる ◦ 「知識は荷物にならない」 - 個々の学習から法則や汎⽤的な知識を得ることで、学習コスト すら削減できる ◦ 斧の研ぎ⽅に熟練すると、斧を研ぐ時間⾃体が短くなる ▪ 2つ⽬のプログラミング⾔語は、最初より早く習得できる 41
42. ⽊こりが定着しないケース 42
43. ⼈が次々に⼊れ替わる状況で ”最強の技術”を選定できるのか 43
44. 学習コストO(1)を前提に置けないケース - 「エンジニア」は⼊れ替わってしまう - 退職‧転職‧昇給‧昇格 - 労務費の転嫁は交渉の余地がある - 受託‧外注：公正取引委員会の周知 - 予算は「⽩紙の⼩切⼿」ではない 以上、あくまでビジネスとしての 範囲内での調整 - 学習コストの⼤きさで起こる問題 - 教育にかかるコスト - ⼈材の「⽴ち上がり」待ち時間 始めませんか？　労務費を反映した価格交渉 https://www.gov-online.go.jp/tokusyu/romuhitenka/ 44
45. 教育をしない前提の技術選定 受注案件の「教育をしない」プロフェッショナリズム - 教育期間を⽤意しなくても能⼒を発揮できる - 担当者交代に耐えうる仕組み作り - キャッチアップしづらい「複雑さ」を採⽤しない 45
46. 注) ”べき論”としての教育 引⽤：ジュニアを採⽤しない連中はシニアに値しない https://portalshit.net/2018/10/02/we-should-hire-junior-engineers 46
47. ⼈材プールを考慮した技術選定 - マイルストーンが決まっており、採⽤に時間をかけられないケース - 準委任契約など、そもそも個⼈の能⼒を選んで採⽤できないケース こういうチーム なら集まる かもなあ 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
48. 注) 消極的選定による技術スタック変更の受け取られ⽅ https://x.com/suthio_/status/2017056348442415318 解約率0%のシステムを、作り直すことにしました。〜エージェントからfindさんに紹介できません、と⾔われたあの⽇〜 https://note.com/find_info/n/n9a0da3fffd9f 48
49. 消極的技術選定について？ 49
50. ⼆分法的思考 - 最強の技術を”過酷な状況”で貫き通せるか - 過酷な状況での『消極的選定』を知ると、技術選定を⼆元論と して扱いたくなる(⼆分法的思考) - 理想：現実 - 技術：政治 - 純粋：打算 - 対⽴軸が⾒つかるとスッキリするが、単純な⼆項対⽴に落とし 込んで良いのだろうか？ 50
51. 消極的選定は公開されにくい https://www.jspt.or.jp/ebpt_glossary/publicationbias.html 51
52. 積極的選定に書かれない動機 https://yong-ju.blog/posts/what-is-cdd 52
53. 公開事例の限界 情報を公開する経験が増えるほど『公開しない理由』が理解できる - 外部に出る『綺麗な』技術選定と、現場との距離 - 消極的選定を書かない理由がある - 公開が躊躇われる事案、出版バイアス - 積極的選定にも書かれない裏側がある - ⼿段の⽬的化、履歴書(CV)駆動開発 - 裏の裏まで考えて、真実に近づくのは本当に⾯倒くさい - ⾒栄‧政治‧打算‧妥協 - ⼈間が介在するから純粋に技術を選定できないのでは？ 53
54. ”エージェントにやらせればいいじゃん” 54
55. ⼈間が技術選定をしない世界 https://x.com/yusukebe/status/2058354533517185389 55
56. ”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
57. LLMの「教育コスト」を考慮する例 - LLMはテキストに強いので、設計書にMarkdownを採⽤する - Next.jsやReactなど利⽤者の多いフレームワークを採⽤する - 後⽅互換性が⾼く、安定して動作させやすいGo⾔語を採⽤する - 新進気鋭のビルドツールではなくMakefileを採⽤する 57
58. 積極的？消極的？ エージェントフレンドリーな技術選定はどちらに分類されるか？ - 「積極的」 - AIエージェントのスループットを最⼤化するため - 「消極的」 - 追加知識を与えず扱える、標準的で単純な技術を選ぶため - AIエージェントの学習コストを最⼩化するため 58
59. いつしかエージェントのために技術選定をしている 顧客 エンジニア エージェント 59
60. つまりそういうことなので 60
61. 最強の技術が次々に⼊れ替わる過酷な状況 • 「AIエージェント」は数か⽉で⼊れ替わってしまう ◦ 新モデル‧新ハーネス‧新LLMプロバイダ ◦ モデルの退役‧コスト変更に伴う⾒直し • AIエージェントの学習コストの⼤きさで起こる問題 ◦ エージェントのハーネス設計にかかるコスト ◦ モデル×ハーネスの「⽴ち上がり」待ち時間 • 研いだ斧(Skills)は⽊こり(LLM)が⼊れ替わると役に⽴たなくなっ てしまう ◦ 形骸化したSkillsは、知識の制約や過剰なコンテキストとして 負債になり得る 61
62. AIエージェントという「定着しない⽊こり」 • 「後進の育成」VS「AIエージェント採⽤」 ◦ どちらも積極的技術選定だが、利益が相反している ◦ ”ジュニアを採⽤しない連中はシニアに値しない”が、 AIエージェントを採⽤しない理由はなんだろうか • エージェント採⽤が全てを良くするとは限らない ◦ ハーネス設計が上⼿でも待遇が良くなるとは限らない ◦ エージェントに最適化させた環境が利益を⽣むとは限らない ◦ 短期的には現状維持がマシな場合がある • エージェント⾃体の「⼈件費」について ◦ GitHub Copilotの完全従量課⾦化 ◦ TokenMaxxingの⾒直し 62
63. 公開事例にかかるバイアス • 公開事例では「⼈間が価値を加えた物語」が選ばれやすい ◦ エージェントが⼈間より優秀という話は公開されない ◦ ⼈間のための儀式(レビュー)の⾃⼰⽬的化 • エージェントの出⼒にブレーキをかけて品質を⾼めたという、 新しいスキルセットをアピールしたい ◦ 「積極的」LLMの能⼒を超える判断、知識 ◦ 「消極的」LLMの能⼒に合わせた判断、今あるモデル‧ ハーネスへの最適化 63
64. エージェント以後の現在地 • エージェント以前 ◦ 積極的な技術選定に注⼒したいが、様々な理由でのすり合わせが必要 ◦ 消極的な技術選定はキャリアを損ねて恥ずかしい。様々な理由で公開したくない ◦ 消極的な技術選定が公開されないので、公開された積極的な技術選定だけを 参考にしても実際の世界に適⽤できない • エージェント以後 ◦ ⼿数が⾜りないという⾔い訳がなくなり、積極的な技術選定を⾏いやすくなった ◦ 意思決定や責任は⼈間に残ったため「分からないが技術的に最強」は選定し難い ◦ AIネイティブ‧エンジニアファーストでのポジションを取らざるを得ない状況が あり、様々な理由で公開できない内容がある 64
65. 公開されない(なかった)部分 • エージェント以前 ◦ 積極的な技術選定に注⼒したいが、様々な理由でのすり合わせが必要 ◦ 消極的な技術選定はキャリアを損ねて恥ずかしい。様々な理由で公開したくない ◦ 消極的な技術選定が公開されないので、公開された積極的な技術選定だけを 参考にしても実際の世界に適⽤できない • エージェント以後 ◦ ⼿数が⾜りないという⾔い訳がなくなり、積極的な技術選定を⾏いやすくなった ◦ 意思決定や責任は⼈間に残ったため「分からないが技術的に最強」は選定し難い ◦ AIネイティブ‧エンジニアファーストでのポジションを取らざるを得ない状況が あり、様々な理由で公開できない内容がある 65
66. 穢れた技術選定について • エージェントは「究極の定着しない⽊こり」 • 「様々な理由」を穢れとして恥じ、これまで公開されなかった 消極的選定の中にエージェント利⽤の重要なノウハウがあるか もしれない • 公開され難い「穢れた技術選定」について語る⽅法はあるか ◦ ⾮公開‧会員制イベント ◦ フィクション(モキュメンタリー) ◦ 新たなアウトプット⼿法の確⽴ 66
67. 本講演の整理 • 最強の技術選定を採⽤できず、妥協せざるを得ない場合は存在 するが、それらが正しく⽋損なく外部公開されるとは限らない • エージェントによって積極的技術選定を妨げる学習コストや ⼯数は⼤幅に削減され、時間的なハードルは下がった • 反⾯、新たな学習コストとの闘い‧⼈材育成とのトレードオフ ‧情報公開へのバイアスが発⽣し、未だ解決していない 67
68. その選定理由を、どこにプロットできますか？ 68