単純さの利点があるにもかかわらず、残念ながら複雑さのほうが売れる現実（2022）
(eugeneyan.com)- 単純な方法が論文査読や昇進評価で低く評価される背景には、複雑性バイアスがあり、複雑な成果物のほうがより多くの努力・熟練・革新を含んでいるように見えるためである
- 選択肢や構成要素が多いシステムは柔軟に見えるが、実際の運用では説明・テスト・問題解決が難しくなり、ミスと非効率が増える可能性がある
- 単純なアイデアやシステムは理解・利用・フィードバック・拡張がしやすく、Instagramは2012年の買収当時、13人のチームで数千万人のユーザーにサービスを提供しながら、PostgreSQLとRedisのような実績ある技術を維持していた
- 機械学習でも複雑な手法が常に優れているわけではなく、中規模の表形式データセット45件では木ベースモデルが深層ニューラルネットワークより良く、推薦・検索では内積(dot product)が neural collaborative filtering より優れていた事例がある
- 複雑さそのものに報酬を与えると不要な複雑化やnot invented hereの傾向を強めるため、複雑な問題ほど単純な解法が可能か、複雑性のコストが正当化されるかを先に検討すべきである
複雑さがより魅力的に見える理由
- 複雑さは努力のシグナルとして受け取られやすい
- 難しいアイデアや技術的な詳細が多い論文は、多くの時間と労力が注がれたように見える
- 構成要素や機能が多いシステムは、より小さなシステムよりも手間をかけて作られた成果物として評価されやすい
- 作るのが難しいという印象が、そのまま価値や品質のシグナルとして機能する
- 熟練のシグナルとしても解釈される
- 動く部分が多いシステムは、設計者が各部分を理解し統合する能力を持っているという印象を与える
- 専門用語や証明が多い論文は近寄りがたいが、そのぶん主題に対する専門性を示しているように見える
- 実務でほとんど使わないアルゴリズムやデータ構造を面接で問う慣行も、こうしたシグナルと結びついている
- 革新のシグナルという認識もある
- まったく新しいモデルアーキテクチャを作った論文は、既存のネットワークを修正した論文よりも新規性が高く評価されやすい
- ゼロから作った構成要素が多いシステムは、既存の部品を再利用したシステムよりも独創的に見える
- 「一つだけ変えて残りは既存研究と同じ」という評価は、単純なアイデアの価値を下げうる
- 機能が多いほどより包括的だという錯覚が生じる
- SQL と NoSQL のデータストアの両方をサポートしたり、バッチとストリーミングのパイプラインの両方を可能にしたりするシステムは、あらゆるケースを扱えるように見える
- レゴブロックが多いほど変化にうまく対応できると考えられがちである
- こうした判断が、単純なアイデアやシステムより複雑なものを過剰に好む complexity bias につながる
単純さが実際の利点になる場面
- 単純なアイデアや機能は理解しやすく使いやすい
- 採用可能性と実際の影響が大きくなる
- 伝えやすくフィードバックも得やすい
- 複雑なシステムは説明や管理が難しく、利用者が何をどうすべきか把握しづらい
- 調整項目が多すぎるとミスが増え、手順が多すぎると非効率が生じる
- 単純なシステムは作りやすく拡張しやすい
- 構成要素が少ないほど実装しやすい
- 標準化された既製技術を使えば、実装・保守する人材を見つけやすい
- コードや内部相互作用が減り、理解やテストの負担も小さくなる
- 不必要に複雑なシステムは、構築により多くの時間と資源を要し、無駄を生む
- Instagram の事例は、単純な技術選択の利点を示している
- 2012年の買収当時、Instagram は13人のチームで数千万人のユーザーにサービスを提供していた
- 新しい流行技術ではなく実績のある技術を維持することで、エンジニア一人あたりの運用負荷を下げていた
- 他のスタートアップが流行していた NoSQL データストアを導入して苦労していたとき、Instagram は理解しやすい PostgreSQLとRedis を使っていた
運用コストと保守性
- システムのデプロイは終わりではなく出発点である
- ほとんどの努力は本番投入後に発生する
- 運用は、もともと作ったチームではない別の人が担う可能性が高い
- 単純なシステムは保守コストを下げ、寿命を延ばせる
- 動く部品が少ないほど、より信頼性が高く、修理もしやすい
- 故障しうる箇所が減る
- 内部相互作用が少ないため、個々の構成要素をアップグレードしたり交換したりしやすい
- 複雑なシステムは、限られたチームが理解しなければならない構成要素が多く、保守コストが大きくなる
- 相互依存する部分が多いほど、問題解決も難しくなる
- Thomas Paine は『Common Sense』で、「何事も単純であるほど乱れにくく、乱れたときにも直しやすい」と述べている
機械学習でも単純な手法が劣らない事例
- より精巧な手法が常により良い性能を出すわけではない
- Tree-based models > deep neural networks: 中規模の表形式データセット45件で、木ベースモデルが深層ニューラルネットワークより優れていた
- Greedy algorithms > graph neural networks: 組合せグラフ問題で、greedy アルゴリズムが graph neural network より優れていた
- Simple averaging ≥ complex optimizers: マルチタスク学習問題で、単純平均は複雑な最適化器と同等以上だった
- Simple methods > complex methods: 32本の論文全体の予測精度において、単純な方法が複雑な方法より優れていた
- Dot product > neural collaborative filtering: アイテム推薦と検索で、内積が neural collaborative filtering より優れていた
複雑さに報酬を与えると生じる問題
- 複雑さに報酬を与えると、人は不必要に複雑なものを作る動機を持ってしまう
- 単純な方法やシステムは、簡単そうに見えるという理由で価値が低いと見なされることがある
- 報酬を得るためにシステムを複雑にすると、最も単純な解法がもはや明確な選択肢ではなくなる
- 複雑さはさらに多くの複雑さを生み、最終的には作業不能な水準に至ることがある
- not invented here の傾向も強まる
- 既存の構成要素を再利用すれば時間と労力を節約できるのに、ゼロから作ろうとする傾向が生まれる
- 時間と資源を浪費し、より悪い結果につながる可能性がある
- 昇進プロセスや機械学習論文の査読でも、複雑さが過度に強調されることがある
- Bryan Liles は、単純な解法のほうが複雑な解法より実装と拡張が容易であるにもかかわらず、昇進は複雑な解法を作った人に与えられることが多いと指摘している
- Micah Goldblum は、ML レビューでは手法が単純すぎる、あるいは既存部品の組み合わせだという指摘がよくあるが、単純さは弱点ではなく強みだと述べている
- Kalman Filters、PageRank、SVM、LSTM、Word2Vec、Dropout のような革新でさえ、拒否されたことがある
複雑さに向き合うより良い方法
- 目標は、複雑な問題を可能な限り単純な解法で解くことである
- 解法の複雑さではなく、問題の複雑さに焦点を当てるべきである
- 単純な解法は、問題に対する深い洞察と、より込み入ってコストの高い解法を避ける能力を示す
- Albert Einstein の「すべては可能な限り単純であるべきだが、それ以上に単純であってはならない」という言葉にも通じる
- すべてを包含する複雑な解法よりも、複数の焦点を絞った解法を検討できる
- 万能(one-size-fits-all)な解法は、期待ほど柔軟でも再利用可能でもないかもしれない
- 複数のユースケースや利害関係者を同時に支援すると、強く結合され、計画や移行により多くの調整が必要になる
- 単一目的のシステムは運用しやすく、必要になれば廃棄もしやすい
- 複雑性バイアスを減らす方法として Occam’s razor を適用できる
- 最も単純な解法や説明が通常は正しいという原則である
- 単純なアイデアを早々に退けたり、価値を正当化するために不必要な複雑さを加えたりしてはならない
- 複雑性のコストを考慮し、「それだけの価値があるのか」を問うべきである
慣れた複雑さを再利用する反対側のバイアス
- 「not invented here」の反対側には、既存の構成要素を自動的に好むバイアスもある
- すでに知っていて個人的な経験上より簡単であり、自分の時間と労力を減らせるためである
- しかし既存の構成要素自体が非常に複雑なら、より単純なものを新たに作るよりも時間と資源を浪費し、より悪い結果につながることがある
- 単純な選択肢がないときは、新しく作る必要があるかもしれない
- 新しく作ったものが実際には単純にならず、既存のものと同じくらい複雑な別の何かになってしまう場合もある
- 問題によっては本質的に複雑で、実際には取り除けない essential complexity を持つ
- ORM は悪い例として扱われている
- ORM は繰り返し新しく作られ、最初は単純に始まるが、やがて複雑さが爆発する
- object/relational impedance mismatch はよく知られており、ORM というアイデア自体が本質的に複雑である
- 単純さを保っているように見えるものは、ORM ではなく query builder や data mapper である可能性が高い
- PSR キャッシュ API は取り除ける複雑さの事例である
- PSR-6 キャッシュ API の後に、より単純な PSR-16 キャッシュ API が登場した
- PSR-16 は複雑さと概念数を減らし、API をより小さく、より非依存的な形にした
- PSR-16 実装用の PSR-6 アダプタ と 逆方向アダプタ を作れるという点は、PSR-16 で取り除かれた複雑さが本質的ではなかったことを示している
- 一部のライブラリやフレームワークは、開発者体験の名の下に本質的複雑性を超えて肥大化することがある
- 真の単純さは、コード行数、public method 数、結合度といった指標で測定できる性質を持つ
- ライブラリが数年のうちに元の10倍の規模に膨らみ、6〜12か月ごとに大きな breaking change を出すことがある
- 成長のないライブラリを「死んだ」と見なし、より「活発な」パッケージへ移ろうとする動機も、複雑性バイアスの症状かもしれない
- 広がっていく複雑さを避けるには、新しく作る選択が必要な場合もある
- 要件を固定し、スコープが広がっていく成長を避けられるなら、新しい実装のほうがより単純な選択になることがある
- どちらか一方のバイアスも強めないよう注意すべきである
1件のコメント
Hacker News の意見
FAANG のある企業で、複雑な問題の解決を昇進基準にしていた時期に働いていたが、より複雑な問題を解くほどレベル・報酬・地位が上がっていった
自然と人々は解くに値する複雑な問題を探し回るようになり、他社もその会社のアイデアを真似したことで、複雑な解法を必要としない小さな会社まで似たような技術スタックを持つようになったように思う
最近の自動車 UI、特に電気自動車の複雑で扱いにくい UIを見て同じようなことを考えたし、それが必要とする車を買えないほどになっている
結論としては、洗練された消費者と憧れ志向の消費者はまったく異なり、憧れ志向の消費者のほうがずっと多いということ
だから、洗練された消費者を犠牲にして憧れ志向の消費者に合わせるのは、経済的には合理的である
憧れ志向の消費者は、欠陥や見せかけを消費上の達成の象徴のように受け止めるため、それを受け入れる
乱暴に言えば、「ラグジュアリー」カーに乗るのが嬉しすぎて付いてきたガラクタが見えず、何十年もラグジュアリーカーを買ってきた立場としては、単にシフトレバーが分かりやすければいいと思っている
タッチ対象が理由もなく小さくなりすぎていて、開発者たちは固定された机上のディスプレイや動かない車の中で UI を作り、テストしていたように見える
走行中の車内では、すべてが破綻する
シフトレバー、方向指示器、ワイパー、ライトのレバーがない最新車はめちゃくちゃだ
手を置く場所もない画面で、運転席に座ったまま小さな対象を突いて当てなければならず、間接的な操作・混乱・不正確さ・注意散漫によって、誰もが運転が下手になる
施錠・解錠、窓を閉める、予熱・予冷、朝は会社へ夜は自宅へ自動でナビを設定する、どのスマートフォンキーを使ったかに応じて座席や設定を調整する、といった面倒なことを自動化してくれる
無料の接続のおかげでナビゲーションもきちんと動くし、以前使った車載 GPS はどれも役に立たなかった
音楽の選択と再生画面も良く、音声コマンドも音楽選択にはかなりうまく機能する
完璧ではないが、これまで運転したどの内燃機関車よりも良いと思う
朝、会社へ出発する流れは、ドアを開ける、走行モードに入れる、の2ステップで終わる
冬場の内燃機関車では、キーを探す、車を開ける、ドアを開ける、妻が運転した後の座席を調整する、始動ボタン、フロントガラスの霜取り、リアウィンドウの熱線、フロントガラスの氷を削る、GPS で会社を選ぶ、パーキングブレーキ解除、クラッチ、ギアを入れるまで10ステップ以上あった
実際に持っていない人たちがオンラインでタッチスクリーンを延々と嘆く一方で、Tesla オーナーはタッチスクリーンの有無にかかわらず他の車より優れているので、そのブランドに残り続ける
Technology Connections が最近の動画で、ワイパーを替えるために不格好な90年代風のレバーを4秒間押さえていなければならず、それを知るために説明書を読まなければならなかったと言っていた
バラバラに取り付けた部品で作られた車では、こうしたひどい動作はごく普通にある
一方で自分の車は、リアルタイム監視映像の通知をスマートフォンに送り、通勤時の運転をしてくれ、シフト操作はたいていシートベルトを締めてブレーキを踏めば車が方向を自動で選ぶレベルだ
重要な機能は50個のボタンではなく、ステアリングホイールから文脈に応じてアクセスできる
シンプルでありながら強力で、問題は前述のラグジュアリーカーたちの実装がひどいことにある
Theo Browne という YouTuberをたまに見るが、主にフロントエンド開発者だ
彼が解決策を説明するのを見ると、野球バットで頭を殴られたような気分になるし、デモに入っている要素の数は涙が出るほど多い
1本の動画で言及される React 関連の難解な用語の数にも驚く
特定の人を名指しで非難したいわけではないが、その複雑さが人気を保たせているのではないかと心配になる
一方で Pieter Levels は Suspense、サーバーサイドレンダリング、Hydration といった話なしに、生の PHP をそのまま本番に投入する
どちらも結局は同じ目標に到達するが、Pieter Levels のほうがずっと稼いでいそうだし、複雑さの差は大きい
実際、Nomad List のようなものは、Theo で見るものより機能もはるかに豊富だと思う
その後、別の人が彼に気づき、Theo がチャンネルで強い調子で語っていたテーマについて、親しげに大声で議論しているのを見た
彼の性格は、不要な複雑さを通じてメディアでのエンゲージメントを最大化するのに完全に合っているように見えた
複雑であるほど論点が増え、難解な選択肢に慣れていない人たちにはより賢く見えることもある
おもちゃのような例に使われるライブラリやコードの量は、本番で見るものよりはるかに多く、私自身かなり怪物のようなシステムも見たことがある
これがどれくらい続くのかは分からない
使わない雑多なものが大量に含まれ、肝心の使う部分を邪魔する
問題が起きると、もはやプログラミング言語と自分のコードだけでなく、フレームワーク内で自分が通る経路のコードまで理解しなければならない
その経路は簡単に10〜20個の関数の深さまで潜り、さまざまな境界ケースで何が起きるのかが十分具体的に文書化されていることは極めてまれだ
比較的単純なものを作るために使うツールの量がすさまじく、DevOps でも似たようなことが起きている気がする
この問題は企業の「フロントエンド開発者」たちが作ったもののように思える
フルスタックやバックエンド開発者がやる「本物のエンジニアリング」への劣等感のようなものが、フロントエンドにも「本物のエンジニアリング」問題を作りたくさせたのだろう
何十年もレガシーシステム開発をしてきて、時には自社の設計で、時には顧客との契約作業で、複雑でバグの多いソフトウェアを特定の顧客が好むのだと信じさせられる出来事をたくさん見てきた
理由は、その陰に隠れられるからだ
「ソフトウェアにバグがあって期限までに終わらなかった」「ソフトウェアが Y をサポートしていないので X ができなかった」「犬が宿題を食べた」といった具合だ
多くの場合、単純で簡単でバグがはるかに少ない解決策を設計できたが、そうするとユーザーは、特定の失敗がソフトウェアの問題ではなく自分の無能さのせいかもしれないことを、もはや隠しにくくなる
だから、特に上からの圧力が大きい会社では、管理職が完全には理解しておらず、バグや問題があると知られているソフトウェアで働くことを実際に好む
27歳で5年勤めた最初の職場を移るとき、超複雑な GUI プログラムを、2つの CLI プログラムを包んだ小さな GUIで置き換えた
それは間違った入力が来ても毎回動作し、まれに失敗しても有益なエラーメッセージを返した
それを使っていた3人の女性は、私のことを本当に嫌っていた
会社を辞めてから1年ほどたってようやく理由を理解したが、そのころの私はあまり賢くなかった
時がたつにつれ、人々は Microsoft Teams のようなものを求めているのだと思うようになった。必要なときにそれで自分の尻拭いができるからだ
物理的な UI について、私たちのグループではこれを電子レンジ問題と呼んでいる
電子レンジに付いている20個の追加ボタンは誰も使わず、たいていは1つか2つのボタンしか使わないが、ボタンの少ない電子レンジは誰も買わない
10年来 Samsung ME82V が気に入っていて、ダイヤル2つで済む
だから午前2時にこっそり夜食を食べるには、1999年のように電子レンジを見張ることになる
欲しいのは速度ダイヤル、パルス動作スイッチ、電源スイッチだけで、みんなそれを望んでいるのに、なぜか世代が変わるたびに誰も使わない機能が大量に付く
必ずしもいつも同じ2つのボタンだけを使うわけではないので、ほかのボタンを使えるという選択権が好きだ
それに、ボタンが多いと、より良い仕様が一緒に付いてくる場合もかなり多い
操作も少なく機能も少ないが、ユーザー体験は素晴らしかった
機能が過剰に多く複雑な競合製品と比べて、iPod のすっきりした感じが記憶に残っている
こういう嘆きは、ありきたりな格言だらけでうんざりする。
Einstein や Dijkstra を引用すれば賢く見せるのは簡単だし、後知恵の利点と実際の要件への無知を抱えたまま、複雑な解法を一般化して指さし批判するのも簡単だ。
「できる限りシンプルに、しかしシンプルにしすぎない」は常に正しい。
汚い解法ならもっとシンプルにすべきだったし、原始的な解法が問題を起こしたなら、シンプルにしすぎるべきではなかったということになる。
なぜただ完璧に作ろうと思わなかったのか、という話だ。
現実には、解法に複数のトレードオフがあるとき、何がシンプルなのかに合意することさえ非常に難しい。
複雑なデータベースを1つ維持するほうが、「シンプルな」データベースを3つ置いて管理作業を3倍にし、結局は同期や分散トランザクションを実装するより簡単な場合もある。
今実装しやすいものが後で複雑な問題を生むこともあるし、問題を完全には解決しない既製の解法は、サポートされないケースのための複雑な回避策を生み、最後には適切なものへ移行する複雑さまで追加する。
「とにかくシンプルにしろ」という助言は、そうした解法が万能薬ではなく、複雑さ対シンプルさの明確な選択肢がまれである現実を分かっていないことが多い。
プロジェクトには、既存の汚いシステム、一貫しない法的要件、変化する事業要件のような制約があり、リリース速度や採用可能なスキルを優先することもある。
経済性も容赦なく、年次報告書の出力がルーブ・ゴールドバーグ・マシンのようでも、年に1回しか使わず、作り直しても50年以内に費用を回収できないかもしれない。
複雑性の議論は、プロジェクトと要件が成長するという事実をほとんど認めない。
今は完全にシンプルなものが、後には無能や悪意ではなく、完全に合理的な形で複雑になり得る。
最初はプレーンテキストファイルにデータを保存するのが美しくシンプルでも、後にはひどい NIH データベースになり得る。
だからといって、3行のデータのために最初からデータベースを使うのも過剰設計だ。
リファクタリングにはコストがあるので、常に理想的な解法を使うことも、それほどシンプルではない。
実際に当たり前なことは、思っているよりずっと少ない。
「できる限りシンプルに、しかしシンプルにしすぎない」が完璧を要求している、という解釈は論理的につながらない。
実務では、反復は計画に勝ることを知っている。
何がシンプルかで合意するのが難しいなら、許可を求めず、あとで許しを請えばいい。
この業界、そしておそらく他の多くの業界でも通用する法則だ。
夢想家やフロントエンド開発者に見られる、特定の偶発的複雑性のタイプは確かにある。
複雑性は複雑だ。
より複雑なシステムには、チュートリアルや動画のような周辺資料を大量に生み出す二次効果もある。
また、それを学んだ人たちは会社で必要な技術と責任を持つ存在になるので、ただうまく動いていてそういう人が不要なものよりも雇用の安定をもたらす。
ソフトウェアがシンプルで、ただ動くように作られていたなら存在しなかった仕事が、IT にはあまりにも多い。
シンプルな場合には「ただ動く」が、内部を覗いたり、些細でないことをしようとしなければ問題ない。
比喩としてかなり合っているのかもしれない。
論文査読の話なら、査読者として論文に求めるものはシンプルさでも複雑さでもなく、「新規性」でもない。
私が求めるのは、問題に対する徹底的で思考を促す実証分析だ。
投稿物の中には、1) 既存のアイデアを十数個つなぎ合わせたフランケンシュタインのようなシステムを提案し、各部分の失敗の様相を深く分析せず、手に入る最新のおもちゃをできるだけ動員して「太字の数字」を得ることに成功したもの、2) 既存手法を単に少し変えたら偶然性能が上がったが、なぜ役に立つのかについて適切な実証的・理論的正当化がないものが多い。
2つ目のタイプは、コミュニティや読者にごくわずかな価値はあるかもしれないが、ほとんどは役に立たないと思う。
読者にとって価値があるのは、博士課程の学生が問題を長く見つめた末に、自分の直感を定量的で検証可能な確認へと結びつけ、予測力のある再現可能な観察を得た場合だ。
たとえば「この論文で説明した Z メカニズムを通じて X が Y に影響することを全ての場合で実験的に検証し、その結果 A 指標を B% 改善し、これは Z と一致する」といったものだ。
複雑性とは関係なく、「X をやったら A が B% 上がった」というだけでは不十分だ。
残念ながら、すべての査読者が同意するわけではない。
高校の歴史教師が、第二次世界大戦につながった出来事についてエッセイを書く課題を出した。
最初の質問は分量がどれくらい必要かで、教師は、この複雑なテーマをA4 1枚で扱えるなら満点を与えるが、そんな短い文章で扱えるかは本気で疑っている、と答えた。
みんなその論理に衝撃を受けた。
教師がそんなことを言うのを誰も聞いたことがなく、子どものころから、より多いことは常により良いと教わっていることを示している。
説明はいつでも抽象化レベルを選ぶことで長くも短くもでき、人々は通常、文脈と社会的慣例に応じてそのレベルを選ぶ。
たとえば「キー入力がどのように画面上の文字につながるのか」は一文でも説明できるし、ファームウェア、ソフトウェアスタック、電子工学、材料科学、製造プロセスまで踏み込めば、長い本を何冊も使って説明することもできる。
第二次世界大戦も、Hitler が Poland と France に侵攻したことで始まったと言えるし、Versailles 条約までさかのぼることもできるし、地球上の生命の進化まで語ることもできる。
最後は衒学的だが、技術的には第二次世界大戦につながった出来事であることは確かだ。
Rich Hickey の Simple Made Easy 講演を強くおすすめします
複雑さはまったく売れませんが、簡単なものはよく売れます
企業が「foo」を使える人材を多く採用でき、業界がずっと「foo」について語っているなら、foo が完全な混沌であってもそれを選ぶでしょう
ラムダアーキテクチャ、大半の Apache プロジェクト、コンテナなどを見ればわかります