事業成長を伴う技術的負債の説明責任と AIによるモニタリング、認知的負債について Masato Ishigaki Sep. 17, 2026 1 

About me 石垣 雅人 合同会社 DMM.com プラットフォーム開発本部 副本部長 新刊 2 

Outline 1. 事業成長に伴う説明責任（Accountability）の重要性 2. 技術的負債の返済と予算の取り方 3. 難易度が高い技術的負債の解消 3 

Outline 1. 事業成長に伴う説明責任（Accountability）の重要性 2. 技術的負債の返済と予算の取り方 3. 難易度が高い技術的負債の解消 4 

技術的負債のあらゆる議論は エンジニアのAccountability（説明責任） に運命がかかっている 5 

技術的負債の構造を説明できているか 事業成長と比例してソフトウェアは複雑化していく。 成長によって使える予算が増える一方、前と同じことをするコストも同時にN倍になっていく 6 

技術的負債の構造を説明できているか 膨大な予算をかけて 元に戻す ことになる リプレイス リファクタリング 7 

まず、自分たちがどこにどれだけの 投資工数をかけているかを説明できるか 【開発区分の構造】 投資⼯数区分 新規開発 新しい価値を作れる費用 資産化 開発（Capex） エンハンス開発 運⽤（Opex） 保守開発 現状システムの維持費用 運用 開発区分 ⼯数（⼈⽉） ⼯数（割合） 1. 新規開発 57.38 28.38% 2. エンハンス開発 30.29 14.98% 3. 保守開発 24.40 12.07% 4. 運⽤ 35.89 17.75% 5. 管理業務、その他 50.65 25.06% 6. - 3.55 1.76% 総計 202.17 100.00% 費用化 管理業務、その他 ※ DMMは勤怠と工数管理を紐づけてDWH（BQ）連携して可視化 8 

まず、自分たちがどこにどれだけの 投資工数をかけているかを説明できるか 単に「リファクタリングする時間がない」ではなく、投資工数として自分たちがどの開発区分に何割 のリソースを割いているかを話せる必要がある。 例えば、障害が多く運用工数に4割割いており、ポストモーテムや恒久対応に時間を取れれてい るからシステムの刷新をすることで、この作業がなくなり、そのの余剰工数を新規開発に回せるの で採算が取れると思います。みたいな話し方ができると良い 9 

事業成長にもストップをかける脅威の説明ができているか 事業の持続可能性、顧客の情報を守れているか 2025年に初めて悪用が確認された884 KEV（＝実際の攻撃で悪用されたことが確認されている脆弱性）のうち、 28.96%はCVE（＝脆弱性が認識）公開日以前または当日に悪用の証拠があった。 明らかにAIによって脅威が増えてきている 引用：VulnCheck State of Exploitation 2026 10 

事業成長にもストップをかける脅威の説明ができているか こうした脅威に対応する工数の確保がで きているか 特に最近はGitHubのシークレットの漏洩やサプ ライチェーンの侵入が多い。 Dependabotの対応やgitleaksやTakumi Guard によるローカル保護はできているか。非エンジニ アもAIを使う時代に改めて問う必要がある https://thinkit.co.jp/article/39249 11 

AIコストの増加の理由を説明できているか - プロンプト → コンテキスト → ハーネス → ループへ - トークンコストについても定額制から従量課金が世界的にトレンドへ - トークンマキシングからトークンマネジメント、FinOps / 人材関連費の見直し - 去年までは何ができるかの仮説期間だったが、今年度の予算策定では明確に費用対効果が求めら れる状況（1億円つかったら1億円の投資対効果はどこに表れるのか） 管掌部門も、1年間で5倍へ 12 

AIコストの増加の理由を説明できているか P/L スケール方法 +700万 +700万 +700万 + +700万 人材関連費 ・給与手当 / 賞与 ・法定福利費 / 福利厚生費 ・地代家賃 / 採用費 ・販管費 / 支払い手数料 +700万 + + +20万 +20万 販管費 / 支払手数料 +700万 +20万 （ライセンス料） + + + +20万 +20万 13 

開発の遅延について説明ができているか 事業 / 経営 - エンジニアの見積もり（予測）を信じて、計画を作る - なのに毎回遅れる。ただ、なぜ遅れるのかはわからない - リカバリーのための人件費（エンジニア、PM）を投入 - ここが操作可能変数のため 14 

開発の遅延について説明ができているか 事業 / 経営の技術的負債への解釈 - そもそも内部品質が改善したら、どうなるのかがわからない - 実際に多いのはエンジニア自身もその効用がよくわかっていない。故にうまく説明でき ない / してもらえない - リファクタリングをすることは良いことは知っているが、かと言ってどこまで必要なのかが わからないので予算見込みが不明 - 結果、度重なる不具合や開発生産性の低下から大きなリプレイスが必要になったが、 踏み込むタイミング（数億円規模）を見失いがち 15 

開発の遅延について説明ができているか 開発組織の心情 - 見積もり（予測）は、大小外れるものという共通認識がある - 遅れた事実は数値化しやすいが、“なぜ遅れたか”は数値化しにくい - 予算を使い大量投入されても、”人月の神話” 状態 - 根本的に内部品質の改善に時間をかけたいが時間がかかるので後回し になってしまう 16 

すぐ「できない」と言っていないか やってはいけないのは、改善を提案する人を冷めさせないこと 否定から入るのをやめる (システムをよく知っているからこそ、一般論が通用しなくなってくる) 17 

信頼を作っていかないと管理せざる負えない - 開発優先度をブラックボックスにせずに伝える - ちゃんと説明責任を果たさないと「何しているかわからないがいつも忙しそ う」と見られる。細かく優先度をつけるしかない - ミドルウェアのバージョンアップ、セキュリティーへの対応、テストの追加やイケてない設計 のリファクタリング、開発生産性をあげるルール改善、新しいメンバーのオンボーディングな ど - ユーザーに直接的に価値を届ける以外の様々なIssueがバックログにある - 🙋この案件を差し込もうとすると半年後です。状態へ 18 

信頼ポイント - 見積もり ──傾向値の提供── ○ 見積もりの予測と実際の乖離が生まれる閾値の共有 計画より上回っている 計画より下回っている 引用: IPA 「IT企業4,564プロジェクト プロジェクトマネジメントの実践・改善に活かす 最新定量データと分析結果」 19 

信頼ポイント - 見積もり ──約束を使い分ける── 二つを分ける 見積りを約束としない 20 

信頼ポイント - リファクタリング ──言葉の丁寧さ── 「リファクタリングをしたいです」という言葉を使わない - リファクリングは良いことなので許容するが何をしているかはあまりわかっていない かつ、リファクタリングには終わりがないので「いつまでやるの？」状態で工数を取っていく this is exactly the problem with "refactoring the code". In many cases it means doing a really important work, but it's indistinguishable from almost-slacking-off, like renaming variables for no apparent reason. And this is what I mean by "don't refactor the code": use different words when talking about things you did, are doing or plan to do. Don't "refactor". Instead try these: アジャイルを導入したいときに「アジャイル」という用語を言わずに 表現して伝えるのと一緒 21 

Outline 1. 事業成長に伴う説明責任（Accountability）の重要性 2. 技術的負債の返済と予算の取り方 3. 難易度が高い技術的負債の解消 22 

徹底的な「人件費」の分解をすることからスタート 生産性ツリー Budget - 見えるデータ ① 財務指標（予算） 開発 Capex Opex 運用 ② 投資工数分布 (Bigquery→Looker) 開発 ③ 施策工数・工期 10⼈⽉ / 5ヶ⽉ 施 策 1⼈⽉ / 0.5ヶ⽉ 3⼈⽉ / 1ヶ⽉ Commit Design UI Dev 20% 40% 30% PR In-Review Approve 人件費 : 1億円 └ 人件費 : 1億円 └ 開発工数（Capex） : 4,000万（4人月） └ Aプロジェクト（3.5人月） └ Bプロジェクト （0.5人月） └ 運用工数（Opex） : 6,000万（6人月） └ 障害対応 （2人月） └ 目標設定/評価（4人月） (Bigquery→Looker) └ 開発工数 : 4,000万（4人月） └ Aプロジェクト（3.5人月 / 1ヶ月） └ Bプロジェクト（0.5人月 / 10日） ④ バリューストリーム ( Bigquery→Looker ) └ Aプロジェクト（3.5人月 / 1ヶ月） └ 設計（20%） └ 開発（30%）...etc ⑤ 開発ライフサイクル └ 開発（30%） └ プルリクエストA └ PR - Approve : 20h └ プルリクエストB └ PR - Approve : 5h …etc (GitHubのライフサイクル) （Findy Team+） 23 

①財務指標 + ② 投資工数分布ごとに戦術を作り込み 投資⼯数区分 開発（Capex） 運⽤（Opex） 開発区分 ⼯数（⼈⽉） ⼯数（割合） KPI 金額 戦略 施策 1. 新規開発 57.38 28.38% 10,000円 → xx% 戦略1 戦術A 2. エンハンス開発 30.29 14.98% 10,000円 → xx% 戦略1 戦術B 3. 保守開発 24.40 12.07% 10,000円 → xx% 戦略2 戦術C 4. 運⽤ 35.89 17.75% 10,000円 → xx% 戦略2 戦術D 5. 管理業務、その他 50.65 25.06% 10,000円 → xx% 戦略2 戦術E 6. - 3.55 1.76% 10,000円 → xx% 戦略2 戦術G 総計 202.17 100.00% どこを効率化したら余剰工数が作 れるかの戦略を作り込みと戦術を 選定を行う 24 

余剰工数を作ったりリファクタリングが必要な箇所の洗い出し Modifius / Modifius CI 評価・目標設定のサポート 技術的負債の分析や設計提案などの 機能を提供およびGHAでの提供 Slack・Google Meet・GitHub の履歴から評価参考情報を自動生成し、1on1面 談や定期評価の補助ツールとして活用します Aさん 25 

コード品質はAIのトークンコストに直結する コードを綺麗にしてもClaude Codeの「タスク成功率」はほぼ変わらない。しかし、必要なトークン量 やコードを行ったり来たりする回数はかなり減る。 負債が溜まっているコードほど、お金がかかる 26 

徹底的にトラッキングしてい実例 経営 経営層 CxO・役員 （経営企画 / 経理） 資産価値 / 減価償却 モニタリング基盤を構築して、 正しくレポーティング Sales Mktg BM 経理 BM cost（⾦額） 事業責任者 PdM PdM BigQuery PdM man-month （⼯数） EM 開発組織 スループット （1⼈⽉あたりの⽣産性） Eng Eng 横断 組織 PM/Dir Des Eng Eng Des 27 

予算と組織を構造化して繋げていくとナラティブで語れるように ヘルスチェックレポートの運用 1. 2. 3. 4. 5. 管理会計 / 財務会計の数値 人員構成（雇用形態 / 等級） 採用計画・育成計画 開発生産性（投入工数の内訳） a. 開発 / 運用の割合 b. AIコスト（トークンマネジメント） プロジェクト ここまで見えて初めて、「プロジェクトの遅れ」が語れるように なる 点と点を繋げて、未来を語れる部門運営へ 28 

例 : Cursor Dashboardを使ったリードタイム（VSM）の計測も盛んに ・勤怠工数 / Slack / GitHub / 会議..etcをもとに生成 ・さらに細かく知りたくなったらCursorに追加で質問できた 29 

ここまでいくと因果・相関関係がはっきりしていくので やりやすくなる 実際にはリファクタリングの予算をもらうのではなく 投資工数の区分を継続的に臨機応変にコントロールしていくイ メージ 30 

Outline 1. 事業成長に伴う説明責任（Accountability）の重要性 2. 技術的負債の返済と予算の取り方 3. 難易度が高い技術的負債の解消 31 

32 

認知的負債にどう勝っていくか どこまで言ってもついてくる認知的負債 ● 「動いている／テストも通る」でも、理解が追いつかないと負債は加速する = 認知的負債 速度が理解力を上回るとき 技術的負債はシステム障害や保守コストとして顕在化するのに対し、認 知的負債は開発速度の指標には現れません 。 コードは正常に動作し、テストもパスし、機能もリリースされます。しか し、この負債はシステムを構築したエンジニアの心の中にのみ存在し、 彼ら自身の仕事に対する不安として現れます。 33 

認知的負債にどう勝っていくか - Technical Debt：アーキテクチャやコード品質に蓄積する負債 - Cognitive Debt：システムに対する人間の理解や推論能力が失われる負債 - Intent Debt：目的、制約、仕様、設計判断など意図が残らない負債 https://forest.watch.impress.co.jp/docs/serial/aidriven/2137349.html 34 

ハーネスは整えつつも 35 

基礎力勝負にもっていく AIエージェントを効果的に動かすには 人間の手がまだ必要 自動掃除機が掃除しやすいように人が部屋を片付ける現象 36 

AIは、まだ人間の増幅器なので 人間の設計力が高くないと高みには行けない 37 

まとめ 1. 事業成長に伴う説明責任（Accountability）の重要性 2. 技術的負債の返済と予算の取り方 3. 難易度が高い技術的負債の解消 38