List of Technical-Debt [text.Baldanders.info]

技術的負債と生成 AI

2026-08-05T03:00:44+00:00

ふと思いついて Kagi Assistant に「生成 AI が世の中に登場してからの大まかな年表って作れる？」って訊いてみたら作ってくれた。年表自体は公開しないが AI が参考にした Web ページは以下らしい。

ターニングポイントになっているのは2017年の Google による論文 “Attention Is All You Need” の Transformer アーキテクチャと，2022年の OpenAI による一般向けの ChatGPT サービスの登場のようだ。今年に入ってからはエージェント型 AI が台頭し，完全に仕事の仕方が変わってしまった。

というわけで，以下の記事。

AI普及でデザイン業の倒産が前年比2.7倍に　「独自性なき企業は淘汰」　東京商工リサーチ

グラフィックデザインなどの「デザイン業」で一千万円以上の負債を抱えて倒産する企業が増えているという記事。背景として以下を挙げている。

東京商工リサーチは、倒産増加の背景を大きく3つに分類している。1つ目は、生成AIの普及を受け、顧客企業のデザイン業務の内製化が進んだこと。2つ目は、デジタル広告の需要拡大により、紙媒体を主力とする企業が影響を受けたこと。3つ目は、ハウスメーカー（木造建築工事業）の倒産増加に伴い、内装や家具などのインテリアデザインを手掛ける会社に影響が及んだことと分析している。

AI普及でデザイン業の倒産が前年比2.7倍に　「独自性なき企業は淘汰」　東京商工リサーチより

私はアートデザインの分野はさっぱり分からないので断言できないのだが，上の記事を読む限り主因は2つ目と3つ目じゃないの？と思ってしまう。つまり産業構造の変化だ。

ぶっちゃけてしまうが，顧客に「自分でやったほうがはやい」と思われたら，そこで試合終了なのよ。

自分のところ（IT 業界）の話で申し訳ないが，今世紀に入って，いわゆる受託開発の仕事はどんどん減っている。というか，もう殆どないかも知れない。例外は公共事業関連くらいかな。まぁ，日本は公共事業への依存度が高いんだけど。

理由は色々とあるが，事象としてはまさに「自分でやったほうがはやい」という風潮になり，これに適応できない中小企業はブラック化（極端に安い単価で過剰に受ける）して，最終的には潰れた。ゼロ年代の話である。

生成 AI，特にエージェント型 AI によって仕事の仕方は大きく変わったが IT 産業の構造としてはとっくにシフト済みで，バカな管理職・経営者が従業員を AI で置き換え（られ）るとか言い出さない限り，業界として大きな構造変化はないと思う。とはいえ，個々のエンジニアについては（特に年配者は）適応できない人もいるだろうし（そっと耳を塞ぐ），本当に AI 導入を理由にエンジニアを解雇するバカな経営者も（特に米国では）いるみたいだが¹。

「技術的負債」というものがある。この言葉が流行ったときは，できの悪いコードや製品を揶揄して言うことが多かったが，本来の意味としては（銀行でお金を借りるように）「より早く実現するために引き換えにするもの」を指す言葉らしい。なので，この「負債」自体には良し悪しというものはない。

お前も技術的負債にしてやろうか！もしくは技術的負債と和田卓人さんをめぐるシンクロニシティ - YAMDAS現更新履歴

ソフトウェア・エンジニアリングにおいて生成 AI を使うメリットは「そこそこのものを早く作れる」点である。この点で AI は人間より優れていると（たぶん）断言できるし，それ故に生成 AI と技術的負債は相性がいいと言えるだろう。

となると，考えないといけないのは，「そこそこ」で収まらない部分に対して AI が残した負債（そもそも負債と気付かない可能性もあるが）をどうやって返すのか，ということだ²。知り合いと話すときは大体ここで（エンジニアの教育も含めて）行き詰まる。 Web 上の技術関連のサイトやページを眺めても，そういったことに言及する記事はほとんど見かけない。まぁ，それこそが本当の意味で「技術（＝お金を取れるところ）」だからなんだろうけど。 AI のために残業するとか論外だしね。

ブックマーク

業態が変わって合わないエンジニアを解雇するというのは昔からあるが，AI 導入を理由（名目）にエンジニアを解雇するような企業が，あとで「やっぱ人間要るわ」となって雇い直そうとしても，ヤバすぎて近付きたくないと思ったりするんじゃないのかなぁ。一度浮気をした男は必ず二度三度と繰り返す（笑） ↩︎
本文の受託開発がなくなった話とも絡むが，今は要件定義から製造・デプロイまでの一連の工程を一発で完遂させるようなプロジェクトはないと言っていい。大抵は小さな単位に分割して，持続的にイテレーションを回していくスタイルだ（故にプロジェクトではなくミッションと言ったりする）。「技術的負債を返す」というのはこのスタイルを前提にしている。これも例外は政府・自治体主導の公共事業で，大抵は予算と期間が決まってるし，開発フェーズと運用（保守）フェーズが分かれているので「持続的にイテレーションを回す」ことができない。もっとも今は公共事業でも大手が持ってるパッケージを使うケースが多いかもしれない。これなら自社製品のカスタマイズとして受けられるので，企業側も（持続的でない）公共事業への依存を減らせる。 ↩︎

技術的負債と FOSS

2021-07-26T12:13:02+00:00

今回の戯れ言の起点はここから。

発端は2021年春頃に発覚した話で，知っている人は知っていると思うが簡単に言うと，どこぞの大学関係者が論文のネタに Linux Kernel にわざと脆弱性を含むパッチを提供し，それがどのように解消されていくか（あるいはされないのか）を観察するという，なかなかに鬼畜なことをやらかしたらしい。

私もこの話は知っていたが，あまり重視していなかった（ブックマークにも入れてなかったし）。いや，これって大学関係者がやらかしたから物珍しかっただけで¹，脆弱性のあるコードの混入自体は別に珍しくないだろ。悪意や害意はないにしても Ubuntu の APT ベースで月に何回 Kernel を更新してるんだって話である。

伽藍であれバザールであれ，隠された悪意や悪意なき害意を見つけるのは困難である。こういうのは人的な統制をしても無駄で，結局はコードで証明していくしかない。まぁ，昔に比べれば典型的なバグや脆弱性の検出についてはずいぶん楽になったけどね。

大昔にソフトウェアを「大量生産される一品もの」と評したことがある。当時は XaaS とか考慮してなかったので当てはまらないことも多いと思うが，私は製品を作るときは「開発」と「製造」を分けるべきだと思っている。何故ならそれぞれに要求される技術要素が異なるからだ。でもソフトウェアはしばしば「開発」と「製造」が混濁する。

Linux Kernel の場合は（営利企業を主体とする）ディストリビュータが「製造」で要求される品質を担保していると思っていたが，そういうわけでもないらしい。

ところで，上の記事を見て連想したのが「技術的負債」というフレーズだ。「技術的負債」については，同じく yomoyomo さんの記事が参考になる。

お前も技術的負債にしてやろうか！もしくは技術的負債と和田卓人さんをめぐるシンクロニシティ - YAMDAS現更新履歴

「技術的負債」を，お金を前借りするように「より早く実現するために引き換えにするもの」とするなら， FOSS と「技術的負債」は本来は相性がいいと言える。ただ，負債の清算（＝リファクタリング）が上手く回らないのであれば，何らかの見直しが必要だろう。これは FOSS 全体というよりは個々の製品・サービス毎に考えるべきことだ。

FOSS 最大の特徴は「不完全でおｋ」という点だと思う。不完全さを埋めようとする限り，その製品には伸びしろがある。その変化のプロセスが重要なのである。

さて，最初に挙げた記事では進化する「オープンソースへの脅威」への対応策として

Limit the spread of monocultures. Stuff like Alva Linux and AWS’ Open Distribution of ElasticSearch are good, partly because they keep widely used FOSS solutions free and open source, but also because they inject technical diversity.

Reevaluate project governance, organization and funding with an eye toward mitigating complete reliance on the human factor, as well as incentivizing for-profit companies to contribute their expertise and other resources. Most for-profit companies would be happy to contribute to open source because of its openness, and not despite it, but within many communities, this may require a culture change for existing contributors.

Accelerate commodification by simplifying the stack and verifying the components. Push appropriate responsibility for security up into the application layers.

via The end of open source?

モノカルチャーの広がりを制限する。オープンソースであるというだけでなく、技術的多様性（technical diversity）の導入が重要

プロジェクトのガバナンス、組織、資金を見直し、特定の人に完全に依存しないようにしながら、営利企業が専門知識などのリソースを提供する動機付けを行う

スタックを単純化し、コンポーネントを検証してコモディティ化を促進。セキュリティ面のしかるべき責任をアプリケーション層に押し上げる

オープンソースの終焉？ではなく次代の（技術、ガバナンス）モデルに移るべきという話より

とか書かれているが FOSS 関係なくね？ yomoyomo さんも「タイトルはいくらなんでも釣り」と呆れているが，そのとーり（by 財津一郎）だと思う。最後のやつとか，普通にアーキテクチャ設計の基本の話だよね。

ちうわけで，そろそろ『Clean Architecture』の読書感想文を書かなあかんかなぁ，と思ったりする（予定は未定）。

ブックマーク

【コラム】オープンソースの終焉が来ているのだろうか？ | TechCrunch Japan : よーやく日本語記事が（笑）
技術的負債とハッカー

参考文献

リナックスの革命 ― ハッカー倫理とネット社会の精神: ペッカヒマネン (著), リーナストーバルズ (著), マニュエルカステル (著), 安原和見 (翻訳), 山形浩生 (翻訳); 河出書房新社 2001-05-26; 単行本; 4309242456 (ASIN), 9784309242453 (EAN), 4309242456 (ISBN); 評価

[Comment] 大昔に買ったんだけどうろ覚え。買い直そうかと思ったが邦訳は Kindle ではないのか。それにしても「リナックスの革命」とかいう頭の悪いタイトルはどうにかならなかったのだろうか。副題だけで十分ぢゃん。

reviewed by Spiegel on 2020-12-12 (powered by PA-APIv5)

伽藍とバザール: 原題: The Cathedral and the Bazaar; レイモンドエリック, 山形浩生 (翻訳); 1999-04-16 (Release 2014-09-17); 青空文庫; 227 (図書カードNo.); 評価

[Comment] プロジェクト杉田玄白正式参加作品。翻訳者のページも参照のこと。今となっては古典だけどねぇ。

reviewed by Spiegel on 2022-10-18 (powered by aozorahack)

Clean Architecture　達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ): ＲｏｂｅｒｔＣ．Ｍａｒｔｉｎ (著), 角征典 (著), 高木正弘 (著); ドワンゴ 2018-08-01 (Release 2018-08-01); Kindle版; B07FSBHS2V (ASIN); 評価

[Comment] 実務に即効性のある技術解説書というわけではないが，ものの「考え方」を示す本としてはよく出来ている。ソフトウェア技術史の読み物としても面白い。

reviewed by Spiegel on 2021-04-03 (powered by PA-APIv5)

今回の話を聞いて私はむしろ「ありがち」と思ったよ。大学が「善」なわけない。真理に善悪はないのだから。たとえば1990年代の米国暗号シーンに於いて大学は何をしてたのかってことだし，もっと言うと，ゼロ年代の Winny 狂躁は（お上による弾圧のほうがクローズアップされるが）明らかに「余計なこと」で，日本はアレで P2P に関して周回遅れになったし，日本企業が「リモートワーク」に及び腰なのはゼロ年代のこの悪夢が尾を引いてるよね。 ↩︎

技術的負債とハッカー

2020-12-12T12:37:03+00:00

最近，立て続けに「技術的負債（technical debt）」という単語を見かけたので。

私も気軽に「技術的負債」という単語を使うが，どうも「技術的負債」自体は単に「そういう事象」を指すものであって，良いとか悪いとかの評価の外にあるようだ。

借入をすれば物事をより早く前に進めることができるようになりますが、そのかわり返済し終えるまでは利子を払い続けることにもなります。私はお金を借りるのは良いアイデアだと、つまりソフトウェアを急いで世に出し、それによって学びを得るのは良いアイデアだと考えていました。次第に日常に戻ってきたら、もちろん借金を返済していくことになるでしょう。つまり、そのソフトウェアについての学びを深めるにつれてリファクタリングを行うことで、得られた経験をプログラムに反映していくのです

【翻訳】技術的負債という概念の生みの親 Ward Cunningham 自身による説明より

つまり，ソフトウェアを「早く作る」ことと引き換えにしたものを金融用語の「負債」に喩えているだけで，それをどう返済（＝リファクタリング）していくか（あるいはなぜ返済できないのか）についてはまた別の話，ということのようだ。

念の為に言うとハッカー気質（hacker ethic）的には「早く作る」ことは美徳とされているし「早く作る」ことと「雑に作る」ことはイコールではない。早く作って評価（試）してみて，そこから改良（＝リファクタリング）していって限りなく「完成」へ収束していくのである。

言い方を変えるなら，「ソフトウェアは常にベータ版」であり，その「ベータ版」から理想とする「完成版」への差分が「負債」である，とも解釈できる。

ふむむむむ。

それを踏まえて

ジョージ・フェアバンクスが強調するのは、病気によって必要な薬が異なり、いろんな病気を一括りにしてしまうと薬の選択が難しくなるように、いろんな問題を「技術的負債」の傘の下に一括りにしてしまうと対応を間違ってしまうので、言葉の厳密な定義を持っておくべきだということ。現在広まってしまった「技術的負債」の広い定義が強力すぎて変えられないのなら、（ウォード・カニンガムが意図した）元々の「技術的負債」を指す場合は ur- をつけて、ur-technical debt と言ったらどうかと提唱している

お前も技術的負債にしてやろうか！もしくは技術的負債と和田卓人さんをめぐるシンクロニシティより

という話にはなんだか既視感がある。

というわけで過去の ~~黒歴史~~ 日記を掘り返してみたら15年も前に

「ハッカー」は既に寿命を終えた「死んだ言葉」だと思う。ってなことを書くとハッカーな方々に怒られるかもしれないが，はっきりいってハッカー以外に「ハッカー」を正確に説明し理解できる人はいないと思う。「ハッカー」という言葉の定義はハッカーの内部で閉じている。故に「我こそはハッカー」と叫ぶ人を誰も止められない。かくて世界には様々に定義された「ハッカー」が乱立することになる。「ハッカー」という言葉は既に発散してしまったのだ

しっぽのさきっちょ 2005年10月 -- Spiegel's Trunkより

とか書いてた。あぁ，これと相似形か。

「ハッカー」という単語も，元々は良いも悪いもない，単に「そういう人」を指す言葉だったが，いったんネガティブなイメージが付くとそれを払拭するために強弁する人が現れてだんだん意味が発散し，挙げ句の果てには「ホワイトハッカー」とか意味不明の言葉が登場したりする。

“ur-technical debt” ちうのもその類の話なのだろう。まぁ，今後は「技術的負債」とか迂闊に口にせんことやね（笑）

ブックマーク

Hackについて（What’s a Hack?）

過去に書いたこの辺の記事も黒歴史になるかな（笑）

参考図書

リナックスの革命 ― ハッカー倫理とネット社会の精神: ペッカヒマネン (著), リーナストーバルズ (著), マニュエルカステル (著), 安原和見 (翻訳), 山形浩生 (翻訳); 河出書房新社 2001-05-26; 単行本; 4309242456 (ASIN), 9784309242453 (EAN), 4309242456 (ISBN); 評価