Scribble at 2026-05-13 08:47:37 Last modified: 2026-05-13 09:47:53

一つの段落にまとめてもらうと上記の通りなのだが、このブログ記事には興味深い話題がいくつもあって、丁寧に扱うことが望ましい。生成 AI で上のように「今北産業」を読むだけでは、ものを考えるきっかけとして情報が不足している（上の要約は多くの画面で３行の表示になってないと思うが、桁あたりの文字数を増やせば３行にはできる。もちろん「今北産業」というフレーズの趣旨が行の数でないことは分かった上での注釈にすぎない）。ここでのテーマとは別の話になるが、生成 AI の要約という「考察や推論の結論」だけを大量に読んでいても学術研究などできないし、ましてや思想家を名乗る見識など身につかないのは、これが決定的な理由だ。あるいは、東大暗記小僧の大半がただの小賢しい物知り野郎にすぎず、思慮深くもなければ人として尊敬に値するわけでもない人物が多い（というか、遥かに低い偏差値の大学を出た人たちと大して変わらない）のは、同じ理由によるのである。

さて、では上のブログ記事の内容を更に丁寧に展開しながら議論してみよう。

シニア開発者が自分の専門性を部外者（特に社内の営業部門や管理部門や経営陣といった人々）にうまく伝えられない理由は、複雑性の管理という自分の問題の枠組みで話してしまい、開発の経験や知識がない相手の側が抱える不確実性の削減という問題に答えていないからだという。

同じ言葉でも、開発者と非開発者では受け取り方が異なる。両者のあいだで大切なのは、メッセージを受け手に合わせることだ。これができていないと、たとえば開発者は直感的に「AI で開発者が不要になる」というマーケティングのメッセージは間違いだと感じるが、非開発者にはもっともらしく聞こえてしまう。もちろん、マーケティングではわざと（真実であろうとなかろうと）もっともらしく聞こえたら「勝ち」なのであるから、自分たちが正しいと思うことを間違って伝えられてしまっていると思うなら、そうしたマーケティング（或る意味では「マーケティング」の機能を正確に表しているから、敢えて「インチキなマーケティング」といった loaded language は使わない）を相対化するようなメッセージを非開発者へ効果的に伝えなくてはいけない。

ここで、まず優れた開発者とはなんであるかと問うてみると、昔から laziness という標語があるとおり、優れた開発者は「できるだけ作らない」ように発想するものだ。つまり、新しい何かを作れと課題が与えられたときに、まず手持ちの手段を眺めながら、「本当に必要？」とか「既存のこれで代用できないのか？」と考える。そして、実際にそうする。僕が15年以上も前に（PHP5 の時代に）書いた「美乳コードの代用文字列」だとか、入力値の validation / sanitization 用のクラスを社内で別のエンジニアが使い続けていたりしたのは、もちろん僕の書いたコードが10年以上も巨大広告代理店案件で使えるレベルのものだからでもあるが、それ以前にプログラマの多くがそういうコードを自分で最初から設計したり書くのは嫌だからなのだ。

彼ら開発者が恐れるのは、複雑性だ。複雑性は、理解、デバッグ、修正、教育、仕事や開発環境の安定性をすべて悪化させる。仕事は常にシンプルに、見晴らしや見通しのしやすい環境で行うのが望ましい。他方で、非開発者、つまり営業、マーケティング、SE、法務、経理、デザイン、それから経営陣といった人々は、市場から学ぶことが最優先であるから、彼らにとって怖いのは複雑性よりも不確実性である。それゆえ、未整理であったり環境が整備されていなくても、とにかく早く試したいとか、早く市場に出して結果を見たいと考える。ああ、うちのプロフィット部門も、同じように１週間単位で動くような人々だと助かるのだがねぇ（経営会議という１か月の単位で何かを試したり動くというのは、ネット・ベンチャーでなかろうと遅すぎる。相手の事業者がいくら月次決算の世界で動いていようと、営業やディレクションや経営が同じように一か月の単位で動いていては、「負ける」のは当然であろう）。

ということなので、企業にはスピード重視で、試行錯誤をよしとする（不確実性を減らそうとする）人々と、安定性、理解可能性、保守性が尊ばれる（複雑性を増やす変更を嫌う）人々という、二つのグループがあり、両者は目的が違うので、話が噛み合わないことがある。開発者は、非開発者から新しい課題が提案されると、「複雑性が増えるから嫌だ」と考えて抵抗する。しかし非開発者は「不確実性を減らしたい」だけなので抵抗される理由が分からない。このような状況で、他人の問題を自分の問題において評価して応対しても、相手には理由や事情が伝わらないことがあるのだ。開発者にとって大切なことは「作らずに済ませる工夫」であるから、それを（非開発者が望むような）不確実性の削減に役立つようにするにはどうすればいいかを考えて応対するべきである。

そこで、"Can we try something quicker?" と非開発者に語りかけることが効果的であろうとブログ記事の筆者は言う。"try" によって試行錯誤の可能性を示し、"something" によって何か新しい代案があるかもしれないと促し、そして "quicker" でスピード重視であることも伝えられる。もちろん、その "something" が自分たちの手持ちの道具を使うことだったとしても、この言い方なら相手を納得させられる可能性が高まる。新しい作業をするのだから、既存のツールの使い回しであろうと "try" であることに違いはないし、自分たちのツールを使って作業を始めるのだから "quicker" でもあろうというわけだ。もちろん、専門職の責任として、これは相手を騙すわけではない。本当に新しいツールを作る必要があれば作るべきだし、短期間にリリースすることが望ましいなら対応しなくてはいけないだろう。われわれは、どのみちサラリーマンなのである。敢えてサラリーマンの開発者として言うが、エンジニアの教示など企業の利益にとってはクソみたいなものだ。そんなことに拘って食えなくなれば、UNIX 精神がどうとか、「死ぬまでコーディングしていたい」（(R) サイボウズラボの・・・誰だったっけ？）と口にしてみたところで無意味である。われわれは、エンジニアであるよりも前に企業人でありサラリーマンだ（もちろん、企業人であるよりも前に社会人であり人であるから、社内の慣行や理屈だけで違法行為や脱法行為を漫然と行っていてはいけない）。そして、「開発者」のロール・モデルが単純化されているきらいはあるものの、この記事には納得させられる点が多い。

それから最後に AI についても議論されているから、づいでにご紹介しておこう。

まず、生成 AI を利用する開発やコーディングはスピードを劇的に向上させていて、これは非開発者が望むような価値観にとって大きな効果があると期待されている。しかし、開発者が尊んでいる開発環境や開発プロセスの安定性を破壊しているのだ。それは、生成 AI の吐き出すコードが本質的には他人が書いたコードの寄せ集めなので、(1) 理解が困難であり、(2) 修正やデバッグが難しく、(3) 他人への共有や教育も時間がかかるという欠点があるのに加えて、(4) AI は責任を取らないという大きな問題がある。仮に、非開発者が「AI で開発者は必要なくなる」などと『キントーン』のコマーシャルの受け売りみたいなことを考えるとしても、では実際に開発者なしで事業を支えられるのかと言えば、そうではない。非開発者は、コードを書くことだけが開発者の役割なのではないという実務や実態や実情を、そもそも知らないからだ。この点についても、開発側は非開発側のニーズや発想に合わせた説明が必要だろう。そして、そういう説明に失敗すれば、「Claude を契約したので、あなたは必要ありません」と（どれほど誤解にもとづいていたとしても）言われる羽目になるのである。しかし、それは経営者や営業が開発について分かっておらず愚かだからではなく、評価基準や仕事の目的意識が違うからなのだと気づかなくてはいけない。もちろん、僕は気づいているという立場で弊社の情報セキュリティや個人情報保護マネジメントに20年にわたって取り組んできているからこそ、還暦に近い爺さんでも（小言を口にする老害感はあるかもしれないが）権威があるのだ。