負債解消という仕事は儲かる

Transcript

1. 負債解消という 仕事は儲かる きのこカンファレンス 2026 in 関⻄ セッション9 発表：すぎうり @uproad3
2. ⾃⼰紹介 すぎうり Twitter:@uproad3 今年36歳 プログラミング歴20年 業歴2014〜 仕事：Rails | AWS | LT芸⼈ 趣味：アーキテクト | リファクタリング ⾔語：Ruby | C# | C | JS | ほかいろいろ 技術：Terraform | Unity | Ubuntu | MySQL 悲しきフルスタックエンジニア RubyKaja 2026 特別賞受賞 求められるまま転職を繰り返し現在5社⽬ 負債解消のプロを名乗っています 普段はニコニコしています
3. 第1章 システムは 芸術作品である
4. クラスは材料を製品へ変える加⼯機である INPUT CLASS OUTPUT 材料 加⼯ 製品 必要な情報を 受け取る 判断し、形を変える ⽬的を果たす形で 次へ渡す 2
5. オブジェクトが美しいダンスを踊るとき 指揮者はいない。役割とメッセージだけがある。 01 02 03 役割を持つ 声を掛ける ⽬的へ進む ⾃分の仕事を ⾃分で引き受ける 命令ではなく メッセージを渡す 協調の結果として ⼀つの価値が⽣まれる 3
6. 貧弱なオブジェクトは何も加⼯しない 同じ「クラス」でも、存在⽬的の有無で作品は変わる。 働く加⼯機 何もしない箱 材料を受け取る 判断する 製品を返す データの重複保持 振り分け 実⾏結果の横流し ⽬的のない分割は、⼯場を⻑くするだけだ。 5
7. 第2章 コードは 美意識を育てる 6
8. ⾼校⽣の時にタイピングゲームを作った ⾃分が欲しいゲームを、⾃分で作る。 利⽤者 ＝ 作者＝私 遊ぶ → 気づく → 直す 使い続けるから、次に直すべきものが⾒える。 7
9. HSPでは機能追加が速かった 処理は順に流れる。欲しい場所へ差し込む。 処理は記述順に実⾏ 処理 → 処理 → 機能追加 → 処理 → 処理 初速だけなら、構造化するより⼀本道のほうが速い。 8
10. 構造の差は、壊れたあとに現れる 変数を⻑く引き回すほど、原因と影響範囲が⾒えなくなる。 ? ? 不具合 ? どこで？ なぜ今？ どこまで？ 動いていた事実は、壊れ⽅までは教えてくれない。 9
11. C#で不具合をクラスの中へ閉じ込めた 原因と影響範囲を、⼀つの役割の内側へ戻す。 外へ漏れる状態 CLASS → ⼊⼒ → 判断 状態 → 出⼒ 原因も影響も、この中に留まる 設計は、不具合の捜索範囲を狭くする。 10
12. C#で実⽤を知り、Rubyで美しさを知った C# Ruby 原因を閉じ込める 影響を局所化する 保守を助ける オブジェクトが協調する 表⾯は直感的に⾒える 内部では処理が躍動する 設計は役に⽴つ。そして、⾒惚れるほど美しくもなれる。 11
13. XNAからUnityへ、20年間育て続ける 基盤が終わるたび、同じ作品を次の時代へ移し替える。 HSP C# + XNA Unity 初版 再構築 再構築 20年 作品を育てるたび、作者の⾒る⽬も育った。 12
14. 第3章 美意識は 専⾨性である 13
15. 美意識は異常検知器である 理由が分かる前に、不調和は「気持ち悪い」と届く。 おかしな名前 ⼊⼒の過不⾜ 貧弱な出⼒ ⾒えない役割 ↓ 気持ち悪い → 異常候補 違和感は、理由より先に届く。 14
16. 設計書は「気持ち悪い」に名前を与える 設計の⾔葉 気持ち悪い → 責務 依存 凝集度 → 説明できる 直せる 直感に名前がつけば、違和感を共有し、設計を改善できる。 15
17. クラスの存在⽬的をドメインから逆算する ユーザーへ届く価値から、各加⼯機の仕事を割り当てる。 クラスの役割 ← システムの⽬的 ← ユーザーへ 届く価値 クラスの役割は、クラス単体ではなく価値から逆算して決める。 16
18. 美意識はドメイン上の型検査である 名前‧必要な⼊⼒‧期待する出⼒を、ドメインの意味で照合する。 予想 名前 → ⼊⼒ → 加⼯ → 出⼒ 実装 名前 ≠ ⼊⼒不⾜ → 加⼯不明 ≠ 別の出⼒ 意味上の型エラー 17
19. 熟練者の直感は圧縮された設計レビューである 経験 設計知識 → 直感 → 違和感 ドメイン知識 直感の理由は、あとから⾔葉にできる。 18
20. 美意識は、学べる専⾨性である 感じる → 名前をつける → 理由を説明する → 改善する 才能ではない。鍛えられる。 ⼀つのシステムを⻑く育て、違和感を知識で解凍する。 19
21. 第4章 価値と 負債 20
22. 価値はコードの外にある コードは処理を⽣むが、価値は利⽤者の変化として⽣まれる。 欲求がある → システムを使う → 結果を得る → 次へ進める 価値は、処理ではなく変化として受け取られる。 21
23. 守るのはコードではなく、価値である 実装は価値を運ぶ⼊れ物であり、それ⾃体が⽬的ではない。 利⽤者が達成したい⽬的 価値を受け取る体験 交換可能な実装 外側の価値を守るために、内側の実装を変える。 22
24. 価値を妨げる構造が負債になる 負債は醜さではなく、価値へ届く道を塞ぐ構造である。 価値を 増やしたい → 変更できない → 実装時間と 不具合が増える → 価値が届かない 価値の提供を⽌めさせた瞬間、その構造は負債になる。 23
25. 技術的負債と醜いコードは同じではない 醜いが、働いている 価値を妨げている 読みにくい構造 古い仕組み 不格好な処理 変更が進まない 障害が増える 成⻑を⽌める 利息がなければ待つ 返済すべき負債 気に⼊らないことと、返すべきことを分ける。 24
26. 負債の利息は、理解範囲に現れる 変更対象より理解対象が⼤きいほど、⽀払う利息は増える。 ⼀つ直したい 局所だけ分かればよい 全体を読む 環境を再現する 影響を推測する 境界内を読む ⼿順を再現する 履歴から追う 理解範囲が広い 理解範囲が狭い 理解範囲の縮⼩は、変更速度を買う。 25
27. 価値が残るなら、実装は壊してよい 交換するものと、固定するものを明確に分ける。 内部構造 → ← 保存形式 ユーザー価値 ↗ ↖ 実⾏基盤 運⽤⼿順 価値が同じなら、内部の動きは壊してよい。 26
28. すべてを同じ品質で守らない 価値の順位に応じて、品質と⼯数を配分する。 中⼼となる価値 最優先 価値の連続性 維持 周辺の体験 調整 内部の同⼀性 不要 ⼯数を均等に配らず、価値に応じて配分する。 27
29. 負債解消とは、価値を救出する仕事である 価値を選ぶ → 妨げを⾒つける → 構造を壊す → 価値を救出する 守るのはコードではない。価値である。 28
30. 第5章 負債解消の実践 29
31. 理想をスケッチする 実装する前に、ドメインと構造の⾏き先だけを描く。 ⼿を動かす 頭でスケッチする コードを書く 検証する 関係者を巻き込む 理想のドメイン 構造の境界 移⾏の順序 ⼯数がかかる ⽚⼿間でできる 答えだけ先に持っておく。 30
32. 困るまで実装を待つ 動いている 違和感を持つ 痛みが出る 実装する コードには価値がある 理想だけ描く 変更不能‧障害 準備済みの理想へ 利息が現実の痛みになったとき、返済を始める。 31
33. 困った瞬間に、⾒積もりと解決案を差し込む 組織の痛みは、理想へ進むための予算になる。 困った → スケッチを出す → ⼯数を⾒積もる → 仕事になる ⼼理的な隙へ、準備済みの答えを⼊れる。 32
34. 期限は品質の配分を決める 完全性より、価値が間に合うことを優先する。 完全を待つ 核を先に届ける 差分をすべて調べる 危険を先に潰す 完成してから届ける 中⼼の価値を守る 周辺の不完全を許す 届けた後で直す 価値が間に合わない 価値を⽌めない 完全より、⽣きている価値を選ぶ。 33
35. 予防できない失敗は、復旧能⼒で受ける 危険を予測する 予測の限界 価値を先に届ける 壊れた所を直す 分かる範囲を備える 全部は分からない 中⼼を⽣かす 事実へ集中する 完全性を前払いせず、実際に壊れた箇所へ⼯数を使う。 34
36. 機能の最⼩ではなく、価値の最⼩を選ぶ 期限の中で、⽬的が成⽴する核だけを確実に作る。 ⽬的が成⽴する核 価値が届く⼀連の流れ 後回しにできる周辺機能 機能の数ではなく、価値の成⽴条件を残す。 35
37. 仮設は、期限までの橋として使う 正式な仕組みが 未完成 → 仮設でつなぐ → 価値を先に届け → 正式な仕組みへ る 替える 危険な仮設は、短く使い、必ず置き換える。 36
38. 技術的負債は期限を買うために借りる 借りるなら、価値‧危険‧返済⽅法を先に決める。 守る価値 → ← 動かせない期限 意図して借りる負債 ↗ ↖ 許容する危険 返済の道筋 負債は悪ではない。無⽬的な借⾦が悪い。 37
39. 第6章 負債解消は職業になる 38
40. フルスタック＋SRE＋DevOpsのリリーフ投⼿として⽣きる 詰まった場所へ⼊り、領域をまたいで再び動かす。 アプリケーション → ← クラウド‧基盤 詰まったプロジェクト ↗ デプロイ‧運⽤ ↖ ドメイン‧設計 役割は、守備範囲を広げることではなく、試合を動かすことにある。 39
41. 専⾨領域は技術名ではなく、⽣み出せる変化で決める 技術名で名乗る 変化で名乗る Rubyエンジニア AWSエンジニア SRE 変更できる状態へ戻す 安定して動かす 運⽤を続けられるようにする 道具ごとに市場が分かれる 負債解消の専⾨家 道具は変わる。⽣み出せる変化は残る。 40
42. 難局を解ける⼈材は、いつも⾜りない 複数の問題が絡むほど、担当境界の外へ落ちていく。 平時の機能実装 多い 単⼀技術の改善 いる 複数領域の障害 少ない 不⾜ 負債の難局 誰の担当でもない問題が、専⾨家の仕事になる。 41
43. 負債解消を専⾨にすると仕事が途切れない 企業が成⻑する 既存構造が詰まる 専⾨家を探す 次の難局へ 機能と利⽤者が増える 変更と運⽤が遅くなる ⾃社だけでは解けない 需要が繰り返す 成⻑する限り、負債解消の需要は消えない。 42
44. 理想を描き、必要な瞬間に仕事へ変える 理想を描く → 痛みを待つ → 難局を解く → 評価される 美意識を、組織が買える形へ変換する。 43
45. 第7章 専⾨性は市場を呼ぶ 44
46. 「技術的負債解消のプロになりたい」とレジュメに書く “ 技術的負債解消の プロになりたい 技術の⼀覧ではなく、⽣み出せる変化を看板にする。 45
47. 転職ドラフト4回で26件の指名が来た 4回 26件 負債 転職ドラフトへ参加 企業から理由付き指名 ⼀貫して掲げた専⾨領域 専⾨性を名乗ると、市場が実際に反応した。 46
48. 企業が具体的な負債を書いて送ってくる 逆求⼈では、⾯談前から困りごとが開⽰される。 クラウドが落ちる → ← リプレイスしたい あなたに直してほしい ↗ ↖ 開発が遅い 運⽤を変えたい 転職活動が、最初からお悩み相談になる。 47
49. 最⾼800万円――市場が付けた値札 800万円 解決への期待 指名時に提⽰された最⾼年収 難局を解けることへの先払い 値段は技術名ではなく、解消できる痛みに付く。 48
50. カジュアル⾯談を、逆インタビューへ変える “ いま、何に困っていますか？ 何ができるようになりたいですか？ 会社説明より先に、採⽤理由の核⼼へ⼊る。 49
51. ホワイトボードに解決の道筋を描く その場で、困りごとを構造と順序へ変換する。 現状 → 制約 → 変更順序 → 到達点 答えではなく、解く過程を⾒せる。 50
52. ⾯接中に、採⽤後の仕事を始める 困りごとを聞く 構造を描く ⾒積もる 成果を想像させる 採⽤理由を具体化 理解を共有 現実性を⽰す ⼊社後を先に体験 ⾯接を、未来の仕事の試写会にする。 51
53. ⾯談担当者の⽬が輝く会社へ⾏く 専⾨性と需要の⼀致は、相⼿の反応に現れる。 驚き 嬉しさ 期待 そんな解き⽅があるのか この問題が前へ進みそうだ ⼊社後に任せたい 条件表より先に、⽬の前の熱量を⾒る。 52
54. 年収450万円から700万円台へ 400万円台 450万円 600万円 700万円台 設計と実装を学ぶ リプレイス経験 負債解消で⼊社 近代化を継続 負債解消の実績は、給与として積み上がった。 53
55. ⽣み出せる変化を名乗ると、市場から困りごとが届く ⽣み出せる 変化を名乗る → 困りごとが届く → ⾯談で解く → 仕事と⾦になる 専⾨性を⾒える形にすると、市場が使い道を⾒つけられる。 54
56. 第8章 AI時代の負債と 戦略 55
57. AIは10時間で実機動作まで作れる 品質に⽬をつぶれば、初速は圧倒的に速い。 仕様書 コード⽣成 初コンパイル 実機動作 barerubyの設計 Opusへ実装を委任 約10時間 最初の価値へ到達 動くものを作る能⼒は、すでに⼗分⾼い。 56
58. マイルストーン進⾏で既存破壊と堂々巡りが増えた 規模が増えると、トークン当たりの機能追加が落ちていった。 M1 初期機能 速い M2 機能拡張 順調 M3 既存破壊 低下 M4 堂々巡り 失速 ボトルネックになるのは、コード量ではなく理解量である。 57
59. AIは責任のないクラスを切り出す 形だけ分割する ドメインから切る 元の処理を移す 中継するだけ ⽬的は増えない 材料が決まる 加⼯⽬的がある 製品を返す 責任のないクラス 働く加⼯機 分割はできても、存在⽬的は決められない。 58
60. レビューAIも⾒逃しと誤修正を起こす 約3割 ⾒逃す 誤修正 違反を⾒つける体感ヒット率 原則を読んでも検出が安定し ない 修正案⾃体が別の違反になる レビューを増やしても、判断主体は増えない。 59
61. AIが作った負債は、次のAIがトークンで利息を払う 複雑なコード → 再読と探索 → 実装資源が減る → さらに複雑化 利息の⽀払先は、⼈間の時間からAIのトークンへ移る。 60
62. 説明と機械的変換はAIへ任せる AIへ任せる ⼈間が持つ 未知技術の解説 複雑な処理の読解 確定した形への変換 価値の順位 設計の⽬的 許容する危険 ゴールが決まっている ゴールを決める AIに読ませ、⼈間が決める。 61
63. 理想像とロードマップは⼈間が描く トレードオフは、価値の不快を引き受ける仕事。 何を守るか → ← 何を捨てるか ⼈間が決める ↗ ↖ どこまで許すか どの順で進むか AIへ⾏き先を教えることが、設計になる。 62
64. AI製システムの負債解消市場に備える 今 成⻑ 数年後 再設計 AIで初速を得る 機能とコードが増える 理解と変更が詰まる 負債解消が必要 今のAIコードを観察し、未来の直し⽅を蓄える。 63
65. AIに現在地を読ませ、⼈間が⾏き先を決める AIが読む → ⼈間が価値を選 → ⼈間が道を描く → ぶ AIが進める AIの速度を利⽤し、美意識で⽅向を与える。 64
66. 第9章 まとめ 65
67. 美意識を鍛えるという専⾨性 美意識は才能ではなく、⻑期保守で鍛えられる判断⼒である。 作る 使い続ける 忘れる 直す ⾃分が欲しいもの 価値を⾃分で受け取る 他⼈のコードになる 設計の結果を知る 美意識は、⻑期保守で⾝体に刻まれる。 66
68. 市場へ美意識を売り込む 技術名ではなく、美意識で解ける困りごとを掲げる。 美意識を専⾨性 にする → 解ける問題を名 → 乗る 困りごとが届く → 成果と報酬にな る 美意識を⾒える形にすると、市場がその価値を買える。 67