Open2ヶ月前にコメント追加1

1.6 「偽りのイノベーション」の楽園：「インターネット」

作者電子メール：fagaombse@gmail.com
1.6 「偽りのイノベーション」の楽園：「インターネット」

図1-43 リン・チェンイン（林正英）映画ポスターある呪医が治療法を発明しました。彼は率直に言います。「私のこの方法は癌にはあまり効かないかもしれませんが、風邪にはとても効果がありますよ！信じられないなら、風邪の患者を連れてきてごらんなさい！」呪医は風邪の患者を八卦模様が描かれた四角いテーブルに寝かせ、患者の周りを八八六十四周回ります。一周ごとに歌う詞が異なり（見てください、彼にも一つの方法論があるのです！）、そして患者に言います。「帰って好きなように飲み食いしてごらん、五日以内には治るから！」案の定、患者は治りました。呪医は自身の革命的で画期的な風邪治療法をあちこちで宣伝し、瞬く間に多くのファンを獲得しました。真相はこうです。風邪の場合、ただの水を飲む、ジャンクフード＋生姜を飲む、塩水を飲む、漢方薬を飲む、合成薬を飲む、呪医が施術する、いずれの方法でも、風邪の患者がたどるプロセスはほとんど同じです。なぜなら、それは自身の免疫力によってウイルスと戦うからです。 ★厳密に言えば、これらも完全に「無益」というわけではありません。これ幸いと体型管理をサボり、ジャンクフードを飲み放題にできます。合成薬はいくつかの症状を和らげることができます。呪医の施術は心理的な安心をもたらします。
1.6.1 「インターネットシステム」
ここで言う「インターネットシステム」とは、より厳密には、大衆向けで利用者数が膨大なネットワーク情報システムを指します。現在（2025年）多くの情報システムで使用されている技術スタック、デプロイ方法、およびアクセス方法は「インターネットシステム」と似ています。例えば、ある製薬企業が社内で使用している製薬業界の生産管理システムがありますが、これは大衆向けではなく、利用者数も多くありません。このようなシステムは、ここで言う「インターネットシステム」ではありません。
インターネットの波が到来する前は、情報システムの競争の焦点は機能でした。 ★私は1997年に修士課程を卒業し、まず大学で1年間教師を務め、その後ソフトウェア企業にプログラマとして入社しました。最初に開発に参加したシステムは、ホテル管理システムでした（実装：Visual Basic + SQL Server）。このようなシステムは利用者が少なく、サーバー一台と各部署にクライアントPCを一台置けば十分でしたが、宿泊、チェックアウト、会計、客室、飲食、エンターテイメント、財務、電話課金、各種レポートなど、ホテルの内部プロセスのあらゆる側面をカバーする多くの機能がありました。
インターネットの台頭は、このようなシステムをもたらしました。システム機能は非常にシンプルで、システム開発時に考慮すべきコアなドメインロジックはごくわずかですが、インターネットを通じて、システムを非常に多くの人々が利用できるようになりました。初期の典型的な例は、1996年に登場したHotmail（マイクロソフトに買収後、https://www.google.com/search?q=今日のOutlook.comに発展）です。これはWebベースの電子メールシステムで、リリースから1年余りで1200万人の利用者を獲得しました。同時期にはICQ（インスタントメッセージ）、GeoCities（個人ホームページ）なども同様のシステムでした。 ★注意：メールシステムにも豊富なロジックがあります。標準化されたプロトコル（SMTP、POP3、IMAP、MIME…）、アドレス解決とルーティング、暗号化などです。しかし、これらのロジックのほとんどはすでに先人たちによって明確に解明されており、実際に利用可能なコンポーネントも提供されているため、Web電子メールシステムの開発者がゼロから考えたりモデリングしたりする必要はありませんでした。今日、典型的な例はWeChat（微信）、Douyin（抖音）、Weibo（微博）などです。もちろん、それらの利用者数はしばしば億単位、あるいは十億単位に達します。利用者数の増加と機能の単純化は相互に促進し合います。システム利用者数の増加に伴い、システムの機能は往々にして様々な利用者が求める機能の「公約数」を取るようになります。何かを追加したい場合は非常に慎重にならざるを得ず、一部の特定の人々の特別な要求のためにシステムに新しい機能を追加することはありません。例えば、一部のWeChatの個人販売者が、相手の仕事の性質や性格に応じて送るメッセージを美化し、相手の心を動かしやすくする「マーケティング話術美化」機能をWeChatに提供してほしいと望んでも、張小龍（WeChatの創始者）は間違いなく無視するでしょう。もちろん、他の開発組織はこれらの特定の層のために対応するWeChatミニプログラムを開発できますが、それは別のシステムであり、その利用者数もWeChatの利用者数とは異なります。逆に、機能がシンプルなシステムで利用者数が少なければ、収益化の可能性がなく、開発チームを維持することもできず、後述する「偽りのイノベーション」の弊害も現れません。今のメモ帳の使い勝手が悪いと感じて、自分で使うために自分で書いたとしましょう。好きなように開発すればいいのです。ただし、それをネタに自身の「アジャイル開発経験」を共有したとしても、その影響は非常に小さいでしょう。もしあなたのメモ帳が偶然に何らかの課題（痛点）を突き、利用者数が激増したとしても、模倣者もすぐに現れます。この時、バックグラウンド（背景）、人脈、資金を競う段階に入ります。勝てなければ、「先駆者」は「殉教者」になります。勝てて、勝者となれば、その時に自身の「アジャイル開発経験」を共有する影響力は大きく変わってきます。このような「インターネットシステム」に何か「技術的な難しさ」があるとすれば、それは機能の実装ではなく、利用者数が増加した後にパフォーマンスを低下させない方法です。大きな役割を果たすのはやはり金銭——競合他社を打ち破るまで、インフラを支えるための十分な資金があるかどうかです。この「技術的な難しさ」も競争の鍵となる要素ではありません。WeChatの前にはMiTalk（米聊）があり、後発にはYixin（易信）、Laiwang（来往）などがありました。WeChatの競合他社が競争に敗れたのは、彼らがWeChatの機能を作れなかったからでしょうか？彼らの技術が利用者数の増加に対応できなかったからでしょうか？
1.6.2 「アジャイル」の楽園
多くの開発者は、このような「インターネットシステム」を開発または保守する企業、ここでは「インターネット企業」と呼びましょう、に入社しました。このような企業は、「アジャイル」の名を冠する多くの「方法論」（実際には大した方法論はなく、ただ「やるだけ」が売りですが）にとっての楽園となりました。よく人から言われます。「潘先生、アジャイルというやり方は、工場管理システムなどにはあまり向かないかもしれませんが、インターネット開発には非常に有効だということを認めざるを得ません！」と。私はまた、インターネット企業の開発者が様々な技術会議の壇上を独占し、「インターネット開発思考」や「アジャイル開発思考」をあちこちで説教しているのを見てきました。よくあるシナリオは、インターネット企業の開発者が壇上で自分たちのシステムをどう開発したかを語り、聴衆はそれ聞いて、「なんだ、これはただのデタラメじゃないか、以前よく言われた家内制手工業的な開発じゃないか！」と思うのです。もちろん、講演者は自身を「アジャイル試行錯誤」や「アジャイル開発」と称します。しかし、認めざるを得ません。彼らの会社は上場し、そして今や収益を上げ始めています！聴衆の中にいる電力や税務などのソフトウェアを開発している学生たちは反省し始めます。「彼らは『デタラメ（アジャイル試行錯誤）』をやっているのに、これほど成功している。私たちはあれこれ規範を守り、モデリングをして、一年苦労してわずかな儲けしか得ていない。いけない、彼らから学ばなければ。すぐにインターネット思考とアジャイル開発思考を導入し、私たちの研究開発プロセスをインターネット化、アジャイル化するぞ！」と。実際にそのように試みた会社もありましたが、結果は収拾のつかない事態になり、後になってまた私のところにやって来て、「潘先生、やはりモデリングといったものを取り戻さなければなりません」と言いました。まず、これは「生存者バイアス」で説明できます。「デタラメ（アジャイル試行錯誤）」をやっていた会社の多くは倒産し、「その中で働いている」開発者は存在せず、ましてや技術会議の壇上で説教することなどできません。次に、生存者であったとしても、彼らが他の競合相手を打ち破って生き残ったのは、自社のシステムの能力が競合他社のシステムの能力を一段と上回っていたからではなく、他の要因によるものです。布道者は自身のイメージを向上させるために、意図的または無意識的に、自分が所属する会社の成功を「デタラメ（アジャイル試行錯誤）」と結びつけ（この点については、「偽りのイノベーション」の買い手について語った際にすでに述べました）、聴衆を「誤った帰属」の論理の罠に陥れるのです。「デタラメ」が事実であり、「成功」も事実ですが、共存を因果関係と見なし、「デタラメだから成功した」「デタラメであれば成功できる」、さらには「デタラメでなければ成功できない」という結論を導き出すことはできません。おそらく、その会社のバックグラウンド、人脈、そして費やされた資金こそが成功の原因であり、会社内の開発チームがどのような開発方法を採用したか、立って開発したのか、座って開発したのか、寝て開発したのか、逆立ちして開発したのかは重要ではありません。しかし、布道者は巧妙に共存を因果関係に転換したのです。ある日、Aさんは酒に酔って宝くじを買いに行き、結果的に当選して2億円を獲得しました。皆がAさんに壇上で経験談を話すように頼むと、Aさんは正直に「その日、酒に酔って宝くじを買いに行ったら、大当たりしたんです」と話しました。すると、聴講していた宝くじ購入者たちは皆、半酔いになってから宝くじを買いに行くようになり、そうすれば大当たりすると思い込みました。残念ながら、当選しなかったBさんやCさんたちは壇上で説教する資格がありません（生存者バイアス）。酔っていたことは事実であり、大当たりしたことも事実ですが、それによって「酔っていたから大当たりした」という結論を導き出すことはできません（誤った帰属）。 Aさんが大当たりしたのには、間違いなく原因があるはずです。ただ、その原因は非常に複雑で、「神のアルゴリズム」に属し、人類にはまだ明確に計算できません（そうでなければ、明日の宝くじを計算できればどれほど良いでしょう）。そのため、観察可能または理解可能な事柄に帰属させがちです。「酔っぱらう」というのは、読者の印象を深めるための極端な例ですが、より一般的な帰属は、Aさんが「先祖の徳を積んだ」からです。リバプールとマンチェスター・シティが激しく戦い、最終的にリバプールが2対0で勝利しました。なぜリバプールが勝てたのか、その原因は選手、技術、戦術の問題であり、どの要素がうまくいったのか、あるいは失敗したのかは、チームの監督であるスロットやグアルディオラは理解しています。しかし、一部のサッカーファンにとってはそれは複雑すぎます。彼らは自分が理解できる範囲で原因を探そうとします。例えば、選手のユニフォームの色、監督がどんな下着を穿いているか、選手が更衣室で立って会議をしているのか座って会議をしているのか、選手がペアでシャワーを浴びているのか、などです。 ★インターネットの布道者のような誤った帰属は、インターネットが登場する前のソフトウェア開発業界にもすでにありました。前世紀、多くの企業の情報化改善は大きな抵抗を受け、「うちの企業は何年も前からこのやり方でやってきて、ずっと儲かっているじゃないか」という反対意見が出ました。これは共存を因果と見なす例です。 ★「情報化改善をしていない」ことと「儲かっている」ことは共存していますが、儲かっているのは、その背景にある特定のバックグラウンドがあるからです。改革開放初期の歴史を知っている学生なら、「双軌制（二重価格制）」や「官倒（役人の横流し）」といった言葉をご存知かもしれません。以前は一部の役人の親戚が会社を設立して儲けるのは非常に簡単でした。もしこの権力による恩恵をずっと享受し続けられるのであれば、情報化改善を行うかどうかは関係ありませんでした。改善が必要になったのは、この「ボーナス」がもはや享受できなくなったからです。もしかしたら、「機能がシンプルだとしても、これほど多くのユーザーに対応するには、背後の技術的な敷居も低くない。多くの技術****専門家がいなければ、ウェブサイトはとっくに崩壊しているだろう」と言う人もいるかもしれません。再び酔っぱらいのAさんが宝くじに当たった話で考えてみましょう。酔っぱらうことと宝くじに当たることとは共存しますが、因果関係ではありません。これは前述の通りです。もう一つの問題を見てみましょう。Aさんが2億円に当選した場合、4000万円の所得税を納める必要があります。そうでなければ当選金は没収され、さらに投獄されます。もし富豪のBさんが、Aさんが最初に2億円に当選し、その後4000万円を納税したのを見て、Bさんが先に4000万円を税務署に前納してから宝くじを買いに行くとします。Bさんが2億円に当選する確率が大幅に上がるでしょうか？ 4000万円の納税は2億円当選の結果であり、当選の原因ではありません。インターネット企業の多くの開発者は「納税型」に属します。会社の成功が彼らをもたらしたのに、彼らは自分が会社の成功をもたらしたと誤解しています——「我々がいなければ、独身の日にはウェブサイトは崩壊していたでしょう」。 ★もし「納税」という言葉が耳障りなら、「ボディーガード」と言い換えられます。Aさんが2億円に当選し、その後ボディーガードを雇い、ボディーガードが「私がなければ、この2億円は手に入りませんでしたよ」と言うようなものです。
1.6.3 「ドメイン駆動設計」の楽園
インターネット（およびモバイルインターネット）の拡大に伴い、仕事や生活の様々なプロセスにおける一般大衆とのインターフェースのほとんどが情報システムのインターフェースに変わりました。例えば、ショッピングプロセスにおける注文段階、医療プロセスにおける予約段階、行政サービスプロセスにおける申請段階などです。開発者は一部のドメインロジックについて考えざるを得なくなりましたが、以前から「アジャイル」に慣れてしまっていたため、モデリング能力が全般的に低下しているか、あるいは最初から確立されておらず、また真剣に学ぶ努力をする気もありませんでした。そこで、このような開発者の好みに合わせた「偽りのイノベーション」が華々しく登場しました。その代表格が「ドメイン駆動設計」です。[1.5.4.1 すり替え]の項ですでに述べたように、難しくて学ぶのが面倒なモデリング方法論を「伝統的な方法論」と分類し、「ドメイン駆動設計」を「新世代の方法論」と喧伝します。これらの開発者は議論する際に「新世代」（あるいは革命的、画期的）に焦点を当て、自分たちは「伝統的な方法論」については語るに値しないほど熟知しているかのように暗黙の了解で装います。そのため、このような奇妙な現象が現れました。「ドメイン駆動設計」という名前である以上、当然ながらドメインロジックが複雑なシステムほど**「ドメイン駆動設計」が必要とされるはずですが、「ドメイン駆動設計」が「大流行」している場所は「インターネットシステム」であり、その布道者の大部分は「インターネット企業」出身なのです。よくあるドメイン駆動設計の記事は、次のような構成です。まず「DDDは業務システムの複雑性を解決する方法論である」というお経を唱え、その後、いくつかのDDD造語を褒め称えます。このコピー＆ペーストの定型作業だけで、かなりのページ数を占めます。次に、例を挙げ始めますが、例は1～2個のドメインクラスしかなく、関わるドメインロジックも極めて単純です（おそらくDDDサークルから見れば十分に複雑なのかもしれません）。それから、エンティティ、値オブジェクト、リポジトリ、コンテキスト、アグリゲートルート、ヘキサゴナルアーキテクチャ…について大々的に語り始め、コードも提供されます。コードは一層また一層と積み重なり、かなり壮観です。わずかなドメインロジックで、これほど多くの「餃子」（アウトプット）を包むのですから、「偽りのイノベーション」の買い手（開発者）が「役立つ！」と叫ぶのも無理はありません！銀行、保険、医療などの業界組織の開発者の中にも、「ドメイン駆動設計」の経験談を共有する人がいますが、今度こそ本物があるかと思いましたか？やはりありません。彼らは象徴的にいくつかのドメイン概念を簡単に羅列し、「ほら、ここにドメインがあるでしょう？」という意味で示し、その後は先ほどと同じパターンです。最後に、ドメイン駆動設計がどれほど多くの利益をもたらしたかを主張します。ドメインロジックは簡単に羅列しただけでは表現できません。クラス図やステートマシン図のようなモデリングスキル**（または同等の形式）を使わなければ、なかなか記述することはできません——しかし、彼らは気にしません。自分自身を、そして他人を欺くのです。コーディングを始めれば、ドメインロジックは自然と天から降ってくる、と。一歩譲って、最悪の場合はひたすら「アジャイル試行錯誤」を繰り返せばいい、と。「偽りのイノベーション」サークルがもし歯を食いしばって学び、本当に役立つモデリング知識を習得すれば、高い確率で以前の「偽りのイノベーション」の話術を信じなくなり、かつてそれらを信じていたことを恥ずかしく思うことさえあるでしょう。しかし残念ながら、「偽りのイノベーション」サークルではそうする人はほとんどいません。彼らはサークルを結成し、人間関係を築くことにもっと熱心なのです。業界組織における「偽りのイノベーション」の買い手（開発者）は、特に彼らが自動車、航空、宇宙、国防などの分野に進出する際には、より警戒すべきです。より詳細な議論については、私が書いた**「DDDドメイン駆動設計批判」の文集**を参照してください。