AI 時代のスタートアップエコシステ厶から考究する技術的負債との向き合い方

技術的負債に向き合うConference 2026

Transcript

1. AI 時代のスタートアップエコシステ厶から 考究する技術的負債との向き合い方 めもりー 1
2. めもりー m3m0r7 m3m0r7 m3m0r7 ソフトウェアエンジニアからキャリアが始 まり，スタートアップや上場企業で CTO として活動していました。 現在はフリーランスとして，複数社へ 技術戦略支援，開発支援などしておりま す。 2
4. SaaS is DEAD 4
5. 本当に？？？ 5
6. AI があれば SaaS を自作できる 6
7. AI があれば PoC が容易い 7
8. AI があればプロダクトを自作できる 8
9. AI に多くの投資家が関心を寄せている 9
10. 果たして AI で作ったプロダクトは スケールできるか 10
11. スケーラビリティ，セキュリティ， 堅牢性，変更容易性… 11
12. 私たちが向き合ってきた技術的負債が AI によって「高速」に積み上がる 12
13. それでも AI で事業を スケールさせ続けなければいけない 13
14. そんな戦火でどのようにして技術的負債に 向き合えばよいのか 14
15. 圧倒的成長を求められ続ける スタートアップとそのエコシステムをベースに 15
16. 本日はお話させていただきます 16
17. アジェンダ スタートアップの資金環境と競争条件 事業価値から考える技術投資の優先順位 技術戦略の実行と全体最適 技術的負債を引き受ける・返す判断 17
18. スタートアップの資金環境と競争条件 18
19. スタートアップの資金環境と競争条件 開発を続けるお金は，どこから来るのか - スタートアップのエコシステムでは，起業家・投資家・顧客・人材が関わり，事業をス ケールさせる。技術職の採用や開発予算も，この関係の中で決まる。 - エクイティは株式を渡して出資を受ける方法，デットは金融機関などからの借入など， 返済を前提に資金を調達する方法である（※1）。 - 資金調達は売上がない状況でも開発費を確保できる一方で，成長と回収の説明責任を負 う（※2）。 - スタートアップでは特に VC と呼ばれる事業者から資金調達するのが一般的である。 19 ※1 ベンチャーデットなどエクイティとデットの両方が組み合わさった資金調達の方法もある。 ※2 売上や利益があっても，より大きな投資をするために，あえて金融機関から借り入れる場合もある。
20. スタートアップの資金環境と競争条件 VC からのエクイティ調達 - VC（ベンチャーキャピタル）は，成長を期待する未上場企業へ投資する事業者である。 - ファンドは出資者のお金をまとめて運用する組織，LP は出資者，GP は運用者である。 - VC は株式の売却（イグジット）を目指してキャピタルゲインを得ることが目的である お金が循環する仕組み ③ 株式の売却等 ② 投資 ① 出資 M&A ④ 資金の回収 スタートアップ A LP (Limited Partner) お金を出す側 政府系機関，金融機関など GP (General Partner) 投資を決める側 VC の運用者など IPO 売却できれば資金を回収し 出資者へ分配する スタートアップ B VC には独立系と呼ばれる VC や 政府系 VC ・コーポレート VC (CVC) などがある 20 出典：ILPA・投資用語 ⑤ 回収した資金を分配する https://ilpa.org/resources-tools/private-equity-101/private-equity-glossary/
21. スタートアップの資金環境と競争条件 調達のラウンドと，開発の焦点（目安） 投資ラウンド 別名 エンジェル 投資金額 会社のフェーズ 数百万〜数千万 PoC (Proof of concept，仮説検証) の段階 シードステージ シード PMF （Product Market Fit，プロダクトの市場適合）の検証開始 シリーズ A アーリーステージ 数億円〜十数億円 PMF 検証真っ只中。収益化を目指すための試行錯誤を行う段階 シリーズ B ミドルステージ 十数億円〜数十億円 収益の安定化から，より事業をスケールさせようとする段階 シリーズ C 以降 21 数千万〜数億円 プロダクトの開発もしくは，ベータテスト期間。 レイターステージ 数十億〜数百億 事業のスケールからイグジットへ。場合によっては，更に資金調達を行って シリーズ D，シリーズ E... へ続く。
22. スタートアップの資金環境と競争条件 イグジット戦略（M&A または IPO） M&A エンジェル (ラウンド) シード シリーズA シリーズB シリーズC 以降 アーリー(ステージ) リリース（PoC）優先 ミドル PMF（Product Market Fit） 〜3年 22 レイター IPO 収益の安定化及び向上 5 年〜
23. スタートアップの資金環境と競争条件 AI への資金集中と，案件数の違い - 2025年の米国 VC 投資では，AI 分野が投資金額の 65.4%，案件数の 39.4% を占め る。 - 同年末のドライパウダー（後述）は 2,993 億ドルである。ドライパウダーがあるから といって資金調達できるとは限らない。 - なお日本での調達総額は 2024 年では 7,793 億円であって 2025 年では 7,613 億円 だったため，あまり変化はない。 - ただし政府も AI や半導体を含む戦略対象に 370 兆円ほど投資を行う方針を立てて おり，現時点では変化があまりないものの，今後は変化するかもしれない。 23 https://initial.inc/articles/japan-startup- nance-2025 出典：NVCA 2026 Yearbook, p12・20 https://nvca.org/wp-content/uploads/2026/04/NVCA-2026-Yearbook-4.9.26.pdf fi 出典：INITIAL (2026-01-19)
24. スタートアップの資金環境と競争条件 ドライパウダーとは？ ドライパウダーは，出資約束を指し現金とは限らない，まだ投資に使われていない 資金枠のことである。 出資を約束した金額が 100 億の場合: 投資済み 60 億円 未投資 40 億円 ドライパウダー GP は投資先の組み合わせ（ポートフォリオ）を運用し，新規投資と， 既存投資先への追加投資（フォローオン）へ資金枠を配分する。 出典：PitchBook・ドライパウダー 24 出典：ILPA・投資用語 https://pitchbook.com/blog/what-is-dry-powder https://ilpa.org/resources-tools/private-equity-101/private-equity-glossary/
25. ではなぜ国内では 市況感が悪いと言われているのか 25
26. スタートアップの資金環境と競争条件 AI によりハイバリュエーションがつけられない - AI の登場を皮切りとしてハイバリュエーションが狙いにくくなった。 - 従来まではエンジニアを採用してプロダクトや機能を作り続けるモデルでバリュエー ションをつけられた。 - 既存企業が AI を活用した生産性の圧倒的な向上，売上または利益を伸ばすための モデルへの変革に追いついていない。 - ビジネス上の課題としては，既存のビジネスモデルをどう変えるか，AI 活用をビ ジネスにどう組み込むか，AI でどういった社会課題を解決するのか…，など。 - システム上の課題は，その要件に対してかつスケーラビリティがあってセキュリ ティが高く，変更容易性が堅牢性のあるシステムを作りつづけられるかである。 26
27. スタートアップの資金環境と競争条件 AI によりハイバリュエーションがつけられない - 投資家からの期待に応えられずハイバリュエーションがつけられない。ダウンラウンド （前回の調達額よりも小さい調達額）になってしまうことを避けるために繋ぎの調達を している企業もチラホラ。 - ダウンラウンドでの調達を既存株主は避ける傾向にある。 - 例えば前回の調達で 10 億のバリュエーションがついたとして，次回が 5 億だとす ると，純粋にその会社の価値が半分になるわけである。 - つまり 10 億で出資した株主は半分の 5 億を損することになる。 - ゆえに，中々次のラウンドに進まないのである。 27
28. スタートアップの資金環境と競争条件 AI によりハイバリュエーションがつけられない - 実際に，イグジット戦略として M&A のケースが増えてきている。 IPO M&A 220 165 110 55 0 2022 28 2023 2024 2025
29. そこで更に追い打ちをかけているのが… 29
30. 上場維持基準が厳格に 30
31. スタートアップの資金環境と競争条件 上場後も成長が求められる 上場維持基準が見直されるということは，上場ゴールという逃げ道が狭くなるということ。 当たり前だが，上場を維持できなければ，その株は投資家にとっては無価値になるので 当然株価がつかなくなる。 上場まで動く仕組みだけではなく，成長を続けられる仕組みへ投資することが必要である 31 出典：日本取引所グループ https://www.jpx.co.jp/equities/listing/continue/details/04.html
32. 成長を続けられる仕組みへ投資すること… 32
33. これが技術投資である 33
34. では技術投資は何をもって優先順位を 判断すれば良いのか 34
35. 事業価値から考える技術投資の優先順位 35
36. 事業価値から考える技術投資の優先順位 ビジョン・ミッションを顧客の成果まで具体化する - 企業が掲げるビジョン・ミッションを叶える手段の一つとして，プロダクト・事業が存 在する。 - そして，顧客がそのプロダクトや事業に価値を見出し対価を払い，使い続けていただく ことが企業のスケールを支える。 - 一方で，価値を提供し続けられなければ顧客は離れていく。商品が売れれば売れるほど 多くの顧客に期待されているということ。 - ビジョン実現・ミッション達成のためには，多くの顧客にプロダクト・事業に価値を感 じてもらえるようにデリバリーし続ける必要がある。 36 そのためには，常に事業・プロダクトがスケールし続けられる技術投資が必要不可欠である
37. 事業・プロダクトがスケールし続けられる 技術投資の優先順位 37
38. 言い換えると 38
39. 「事業計画を達成し続けるための技術投資」 39
40. エンジニア・EM・TL プロダクト 予算・コスト 限られたヒト・モノ・カネを どうやってコスパよくコントロールするか 40
41. それが「技術戦略」である 41
42. 事業価値から考える技術投資の優先順位 技術戦略には何が必要なのか ヒト モノ カネ 人材 プロダクト 予算 - 会社の事業を成長・スケールさせら - 事業計画にもとづいてスケール・安 れる人材の定義，及びそれを評価す 定性を保てるように，必要なインフ （要員計画を含む）を算出し，事業 るための仕組み（モニタリング・人 ラの整備，オペレーションの改善， のスケールを経営レイヤーとともに 材開発） アプリケーションアーキテクチャの 描く。 - 事業計画に対して必要な技術投資 設計など - 随時調整可能なフリーランス人材や オフショアを用いたアウトプットの コントロール - 必要なバジェットを最小限に抑えつ - アウトカムを最大化するために， ユーザーにどういった機能要件を提 つ，踏むべきアクセルを踏む意思決 定を行う。 供すればよいのか これらをコスパよくコントロールするには事業計画を理解しなければならない 42
43. 事業価値から考える技術投資の優先順位 事業計画はどのように描かれるか - toB, toC によっても異なるが，複数のシナリオを想定する。シナリオはナマモノとし て変化するため開発の仕様が FIX されることは永遠にない。その前提で技術戦略を練 る必要がある。 - そして，新規プロダクトであれば，市場規模がどれくらいでニーズがどれほどあるの か，マーケティングでどれくらいの層にアプローチできるのか，マーケ・開発の回収見 込みはいつごろになるのか。 - そのために必要な人材は…機能は…などとドリルダウンしていく。これが無限に繰り返 される。 「技術投資」のための技術戦略は CTO やそれに準ずる技術責任者だけで完結することはない 43
44. 事業価値から考える技術投資の優先順位 市場規模の概念 - TAM （Total Addressable Market）は，サービ TAM SAM SOM ス全体の獲得できる市場規模。 - SAM (Serviceable Available Market) は，自社 で取りうる最大の市場規模。 - SOM (Serviceable Obtained Market) は，自社 で最大でアプローチ（契約など）できるであろ う市場規模。 44
45. 「技術戦略」に重要なのは「全体最適」である 45
46. 事業価値から考える技術投資の優先順位 全体最適のためのボトルネックの排除 カネ エクイティ調達 デット調達 自社売上 ヒトによるプロダクト・機能開発 PoC 相互関係を維持しながら 最適化する モノ 46 ヒト 自社応募・エージェント 業務委託採用 オフショア活用
47. 事業価値から考える技術投資の優先順位 全体最適のためのボトルネックの排除 カネ エクイティ調達 デット調達 自社売上 ヒトによるプロダクト・機能開発 PoC 何か一つがボトルネックになっている だけでも事業の成長は止まる モノ 47 ヒト 自社応募・エージェント 業務委託採用 オフショア活用
48. AI 時代ではヒト・モノ・カネの 循環が高速になったが… 48
49. 人間の意思決定が必要な物も まだ多く残っているがゆえボトルネックに 49
50. 例えばカネは自社売上でも 資金調達でもラグがある 50
51. 一つの物事が突き抜けて高速であっても 全体の足並みが揃わなければ デリバリーは早くならない 51
52. その前提の中で技術戦略はどのように 考えればよいのか 52
53. 技術戦略の実行と全体最適 53
54. 技術戦略の実行と全体最適 従来までは偶然ニーズが一致していた - 従来までは，偶然エンジニア採用と技術戦略のニーズが一致していた。 - フリーランスでも正社員でも，開発に関心が強いエンジニアが重宝されていたし， 評価もされていた。 - ジュニアでもミドルでもシニアでも，エンジニアが好きに書きたいコードを書けば，プ ロダクトが出来上がり，それがバリュエーション・企業価値に効いてきた - もちろん，スタートアップに限らず受託や SES であればエンジニアの数だけ，売上 も上がる - しかし，AI の登場を皮切りにニーズがズレ始めるように。 54
55. 技術戦略の実行と全体最適 とりあえず人を増やせば良かったが今は違う フリーランス 正社員 - AI が出始めた 2022 年から比べると，正 14 13.32 10.5 11.06 10.54 9.97 10.07 8.77 8.53 7 7.88 4.86 3.5 0 社員はやや微増に対してフリーランスは大 幅に倍率が急減。 11.06 2022 2023 2024 2025 - AI によって不足していた馬力がカバーでき 2026 280 261 276 229 210 - （情報通信サービス業なので幅広く単純比 70 較は難しいが）倒産件数 も AI が出たタイ ミングから倒産に追い風をかけていると分 0 析されている。 140 55 るようになったからと推測できる。 倒産件数 145 2022 2023 2024 2025 出典：GEECHS https://www.geechs.com/newsrelease/20260807̲ankenbairitsu/ doda: https://doda.jp/guide/kyujin̲bairitsu/data/ 東京商工リサーチ: https://www.tsr-net.co.jp/data/detail/1203052̲1527.html
56. 技術戦略の実行と全体最適 とりあえず人を増やせば良かったが今は違う - IT 人材白書，レバテックの人材白書によれば，AI が発展し始めた 2023 頃からエンジ ニアにソフトスキル，顧客折衝スキル，そして AI スキルが求められるようになった。 2021 エンジニアに 求める役割 AI 活用 幅広い技術 - 2022 2023 2024 2025 技術力に加えて ソフトスキル 新卒にも 技術力とソフトスキルを 求められている 顧客折衝が最優先に 2024 同様 - 生成 AI 活用の 育成対象に 生成 AI 活用経験者の採用 生成 AI 活用経験が ほぼマストに ビジネス上のニーズが強くなってきたということは，業務で求められるスキルの前提である 56
57. そして従来までの開発スタイルは… 57
58. 技術戦略の実行と全体最適 顧客のフィードバックを受けるまでが開発 ② 意図と制約を渡す ③ 実装・レビュー・検証 ① 課題を設計へ落とす 顧客の課題と仕様を決める アーキテクチャの設計 ④ 安全に届ける 実装を追加・変更する リリース ⑥ 異常・障害を検知する ⑦ 顧客の成果を確かめる ⑤ 顧客がサービスを使う 58
59. 人材を集めてこのサイクルを回すだけで良かった 59
60. しかし AI 時代では技術戦略が異なってくる 60
61. 人材を集めるだけでは デリバリー速度を早くするための ボトルネックが解消しないのである 61
62. よくありがちなのは開発に関連するところだけ 個別最適化するケースだ 62
63. 技術戦略の実行と全体最適 顧客のフィードバックを受けるまでが開発 AI で最適化しやすい領域 ① 課題を設計へ落とす 顧客の課題と仕様を決める ③ 実装・レビュー・検証 ② 意図と制約を渡す アーキテクチャの設計 AI で開発 ④ 安全に届ける 実装を追加・変更する リリース ⑥ 異常・障害を検知する ⑦ 顧客の成果を確かめる ⑤ 顧客がサービスを使う 63
64. 技術戦略の実行と全体最適 顧客のフィードバックを受けるまでが開発 人の手が “まだ” 介在している領域 ① 課題を設計へ落とす 顧客の課題と仕様を決める ③ 実装・レビュー・検証 ② 意図と制約を渡す アーキテクチャの設計 AI で開発 ④ 安全に届ける 実装を追加・変更する リリース ⑥ 異常・障害を検知する ⑦ 顧客の成果を確かめる ⑤ 顧客がサービスを使う 64
65. 技術戦略の実行と全体最適 顧客のフィードバックを受けるまでが開発 ① 課題を設計へ落とす 顧客の課題と仕様を決める アーキテクチャの設計 ⑥ 異常・障害を検知する ⑦ 顧客の成果を確かめる ③ 実装・レビュー・検証 ② 意図と制約を渡す AI で開発 ④ 安全に届ける 実装を追加・変更する リリース リリースから顧客がサービスを 使うまでラグがある ⑤ 顧客がサービスを使う 65
66. 個別最適では作るのは早くなっても デリバリー速度は早くならない 66
67. 必要なのは全体最適 67
68. その最適化には技術的負債の返済も含まれる 68
69. 技術戦略の実行と全体最適 技術的負債の返済に対する投資感度 - 人間の手を介さずでも AI によって PoC のための使い捨て，一時的なプロダクトや機 能のコードが生まれ始めるように。 - AI によって生成されたコードがセキュリティ上安全で，安定性があって，スケーラビ リティが担保されているわけではない。だから，これらを高速に評価できるエンジニア のニーズが高くなっていく。 - 高速に仮説としてプロダクトや機能が作られるということは，作ってもすぐに捨てられ る可能性があるということ。その作られたコードは脆弱性があるかもしれないが，AI は制御していなければ，そのコードを劣化コピーし続ける。 - つまり，技術的負債の返済に対する投資感度は従来以上に重要だということである 69
70. 技術戦略の実行と全体最適 技術的負債の返済に対する投資感度 - モノを作り続ければ，技術的負債が増え続けるのは確実である。結果としていらない仕 様や不要だった機能が山のように積み上がる。 - 従来は，一つのモノや機能を作るのにある程度の時間が必要で，しかもそれは “直列” だった。今は AI によって “並列” になり，一つのモノや機能にかける時間が大きく短 縮された。 - 今までは銀行からの借入で利率も低かったのに，利率の最大上限でしかも複数社のサラ 金から借りているみたいな状況である。 70
71. 技術戦略の実行と全体最適 技術的負債の返済に対する投資感度 AI 時代の技術的負債の積み上がり 従来までの技術的負債の積み上がり 100 100 75 75 今までは “直列” での仕事だったので 積み上がりも緩やかであった 50 71 50 25 25 0 0 1 回目 2 回目 3 回目 4 回目 返済 1 回目 2 回目 3 回目 4 回目 返済
72. 技術戦略の実行と全体最適 技術的負債の返済に対する投資感度 AI 時代の技術的負債の積み上がり 従来までの技術的負債の積み上がり 72 100 100 75 75 50 50 25 25 0 0 1 回目 2 回目 3 回目 4 回目 返済 “並列” での仕事になるため 積み上がりが急速に 1 回目 2 回目 3 回目 4 回目 返済
73. 技術戦略の実行と全体最適 技術的負債の返済に対する投資感度 AI 時代の技術的負債の積み上がり 従来までの技術的負債の積み上がり 73 100 100 75 75 50 50 25 25 0 0 1 回目 2 回目 3 回目 4 回目 返済 技術的負債返済を実装と同じ割合で計画しないと 返済速度が間に合わない 1 回目 2 回目 3 回目 4 回目 返済
74. 技術戦略の実行と全体最適 技術的負債の返済に対する投資感度 AI 時代の技術的負債の積み上がり 従来までの技術的負債の積み上がり 100 100 しかも AI はこの積み上げられた負債を元に 75 75 74 劣化コピーをしてしまう可能性がある 50 50 25 25 0 0 1 回目 2 回目 3 回目 4 回目 返済 1 回目 2 回目 3 回目 4 回目 返済
75. 技術戦略の実行と全体最適 技術的負債の返済に対する投資感度 従来まで 人間が開発・ デバッグ・コードレビュー 変更の増減は緩やかだが，少ない変更だったため人間が バグやセキュリティリスクを検知できていた 75
76. 技術戦略の実行と全体最適 技術的負債の返済に対する投資感度 現在 AI が開発・ デバッグ・コードレビュー 変更が大量になり，ハーネス・スキルを作っていたとしても，もはやバグ・セキュリティリスクが 含まれているか検知不能に。更にその課題のあるコードは劣化コピーされていく 76
77. 技術戦略の実行と全体最適 技術戦略としてもセキュリティの投資が重要に - 現に，個人情報の漏洩の報告がここ数年で一気に 個人情報漏洩 増加している。 20,000 19,056 17,139 15,000 なったというのが考えられる。 12,120 10,000 7,685 5,000 0 - AI によって，システムの脆弱性の穴を突きやすく - AI 時代では，セキュリティ上の課題も今まで以上 5,846 に取り組む必要が出てくる。 2021 2022 2023 2024 2025 - 77 ※ PPC (個人情報保護委員会)および NPA （サイバー警察局） の 2021〜2025 までのデータより
78. 明日は我が身 78
79. 今まで見てみぬフリをしてきたものが プライオリティが高くなってきた 79
80. 技術的負債も数年単位で一気に 返済するものではなくなってきている 80
81. では技術的負債を積むか，返すか AI 時代の昨今，どのように判断をすればよいのか 81
82. 技術的負債を引き受ける・返す判断 82
83. 技術的負債を引き受ける・返す判断 状況を理解して戦略を練る - スタートアップ初期などエンジニアのメンバーが少なく，プロダクトのコードもまだ少 ない状態では “並列” ではあるが，技術的負債の積み上がり方は緩やかになる可能性が 高い。 - 一方である程度の年期があり，エンジニアの数もある程度いる， そしてプロダクトのコードもある程度の規模になると，指数関数的（※）に技術的負債 が積み上がっていく可能性が高い。 アーキテクチャやハーネスを整備しないと，コードベースが急速に劣化していく 83 ※ 「指数関数的」という表現はビジネスでよく用いられる意味であり数学的な意味を包含するものでなく，一般的な表現に落とし込む目的で用いていることに注意。
84. 技術的負債を引き受ける・返す判断 状況を理解して戦略を練る - 技術的負債は，従来までは “開発生産性” の観点での意味合いが強く，特にエンジニア にとって関心が強い領域だった。 - 今も開発生産性の側面はあるが，AI を筆頭にデリバリーの速度は経営イシューとして も強くなっている（※）。 - 今までは「人のスキル」で片付けられていたものが，AI 活用の促進によって普遍的 に成果が出やすくなった - 技術アセットを多く持っているエンジニアを採用できなくても，成果が出やすく なった反面，競合他社も同じポジションにいるので，優位に立ち続けるためには， 高速にデリバリーし続けなければならない 84 引用: 経済産業省「DXの現在地とレガシーシステム脱却に向けて」より，私的解釈を一部含む
85. 技術的負債を引き受ける・返す判断 状況を理解して戦略を練る - 「アセットが豊富なエンジニア」を採用するだけだった世界線で，アプリケーション アーキテクチャのあり方だけにフォーカスしていた時代から組織，競合，事業上のリス クを加味して技術的負債を引き受ける・返す判断をする必要性がより強くなってきた （※）のではないかと推察する。 - デリバリー環境の整備をはじめ，技術的負債のクリティカルな課題の把握， AI 活用 の整備などが求められる。 - しかし依然，技術的負債の返済は難易度が高いと評価されており，企業によっては 数年単位かかる取り組みになるケースもあり，中々手をだせない。 85 ※ 私はこれを執筆時点では 2022 年（出版日は 2023 年）の拙著「レガシーコードとどう付き合うか」で伝えているのですが，時代を先取りしすぎました。
86. 技術的負債の返済は二択ではない 86
87. 技術的負債を引き受ける・返す判断 中間を模索する - やるかやらないかの二択ではなく，引き受けるべき部分と返すべき部分をジャッジする 必要がある。 - AI による劣化コピーの速度の観点も踏まえながら，事業上重点的にやるべき箇所か そうじゃないかを評価するか，戦略を立てていく必要がある。 - 事業上重点的にやるべきかは，経営戦略をはじめ，事業計画を組みあげるに対し て，どれくらいタームで，どれほどの成長戦略を描きたいか議論しながら決める。 - そのうえで，該当する KPI，例えばユーザー数や GMV であればその改善施策は 当然に走るので，スケールできるようにしなければならない，となる。 87
88. 技術的負債を引き受ける・返す判断 中間を模索する - 作り直すという選択肢も一つありえる。そして場合によっては言語フレームワークを置 き換えることが，全体のコストパフォーマンスに最適な場合がある。 - 例えば複数台サーバーが必要だった環境やスペックがスケールインできたら，コス ト削減になる。 - デプロイに時間がかからない，ビルドに時間がかからない言語，特有の問題を引き 起こしにくい言語，様々な観点で選択することも AI 時代に容易になった。 - むしろ「特定の言語を書きたい」というニーズよりも IT 人材白書では給与水準が転 職動機であるということも書かれており，現代においては事業として何が最適か， 技術的負債を返済する ROI にもう少し踏み込めるようになったと考える。 88
89. 技術的負債を引き受ける・返す判断 中間を模索する - 全社の状況を鑑みて意思決定しなければならないことから，技術的負債は技術者の関心 事だけではなくなってきている - アプリケーションアーキテクチャの設計の議論だけではなく，もう一段，二段ス コープを広げ，視座を高める必要がある。 - そして，技術責任者や技術者は経営レイヤーに経営イシューとしての技術戦略として 昇華し，課題であることを認識してもらい，合意を得て執行まで責任を追わなけれ ばならない。 89 だからこそ，エンジニアの生産性を定量化することはマスト。モニタリング，分析を行い， 返すべき技術的負債を返せられることで ROI が最大化するというストーリーを描く。 そして，それを経営レイヤーの言葉として合意形成を図る
90. 技術的負債を引き受ける・返す判断 中間を模索する - 実際に経営レイヤーにレガシーコード・技術的負債の課題感の共有（情報共有），開発 のブラックボックス化対策がなされている場合，なされていない場合と比べて， 自律 的に改善施策が取られている 90 引用: 経済産業省「DXの現在地とレガシーシステム脱却に向けて p19」より
91. 技術的負債を引き受ける・返す判断 中間を模索する - また，余談ではあるが，CxO （CIO，CTO など）を設置している企業ではモダナイズ 化が進む傾向がある。技術戦略を経営の言葉に昇華できることが鍵か。 91 引用: 経済産業省「DXの現在地とレガシーシステム脱却に向けて p21」より
92. AI 時代の技術的負債はもう技術者だけの イシューじゃない 92
93. 全体を巻き込んで戦略を立てて返していこう 93
94. ご清聴ありがとうございました 94