> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/ja/2024/essay-collection-informal-talks.md).

# 随筆集・雑談編

年明け前にA/Bテスト基盤の構築を調査した。詳しい内容は[ABの問題領域](https://km.sankuai.com/collabpage/2103469706)にまとめた。

1. 自分たちの段階をどう見るか。実験の成熟度モデルで見ると、鯨湾は「歩く」段階、そのほかの事業は「這う」段階だろう。「這う」は成熟度モデルの最初の段階であり、その前を呼ぶなら、私は「目覚め」や「啓蒙」の段階としたい。「這う」段階の目標は、基本的な実験条件、とりわけツールと基礎的なデータサイエンス能力を整えることだ。
2. 社内で先を行くA/Bテスト基盤。団プラットフォームのHorizonと、到家の配送履行部門のA/Bテスト基盤について重点的に話を聞いた。おおむね「走る」段階にあり、どちらも、大規模に実験の敷居を下げ、実験の信頼性を確保する方向へ進んでいる。実験者が設計の妥当性の説明に多くの労力を費やすことや、人為的な要因が実験の信頼性を損なうことを避けるためだ。データサイエンスの専門職も導入している。評価指標を見るだけでも、接続、トラフィックの分割、実施、意思決定を一体で捉えていることが分かる。たとえば、新規実験の客観性を判定できる割合や、重要な実験結果の客観性などだ。
3. **到家の配送履行部門におけるA/Bテスト基盤の発展から得た示唆。これは中核メンバーの1人との対話で得た情報であり、私には、技術が事業を支える典型例に見える。技術と事業の具体的な関係を更新し続ける中で、最も貴重なのは、事業と技術を一体で捉える考え方と人材だ。** こうした専門領域では、事業側は問題を明確に説明できず、ときには問題の存在にも気づかない。事業を十分に支えるには、自分の専門領域から出て、現場に入り、事業を理解し、視点を切り替えなければならない。配送履行は到家の中核であり、その効率改善は極めて重要だ。LBSの多面モデルには大量のアルゴリズム・戦略実験が必要なので、高水準のA/Bテスト基盤への要望も強い。当初は基盤と事業が疎結合で動き、プラットフォームらしい軽快さが目立っていた。2022年には配送履行への支援に集中し、全面的なマネージドサービスへ移行した。事業側は要望を出すだけで、実験の設計、実施、分析までをデータチームが一貫して担う。提供するのは能力だけではなく、能力、ツール、方法を含む解決策である。課題が十分に難しい領域では、配送履行部門は早い段階から研究機関との協力も探っていた。外部開放には3段階あり、プラットフォームによる全面管理、部分管理、分析エンジンの開放を提供している。それぞれ、プラットフォームによる統一管理、実験設計と評価の能力の開放、個々の分析手法を単位とした開放に対応する。

***

最近、コンポーネントライブラリの取り組みを振り返り、曖昧な問いに答えようとしている。生命力の強いコンポーネントライブラリには、どうすればなれるのか。ありふれたものなので、通常は明快で単純な話に見える。だが、人気があり、使いやすく、長く生きるもの、とりわけ長く生きるものは数えるほどしかない。2つの角度から考えてみたい。

**定めた範囲内の本当の問題を解き、投資対効果をプラスに保つ。**

目指す価値の水準で、自分たちの本当の問題を見つけ、詳しく調べたうえで確実に解決する。どの範囲の問題を解くのかを重視したい。範囲が違えば、コストも選べる解決策も変わる。たとえばMeituan全体、金融サービス部門、チーム内のコンポーネントライブラリでは、目指す価値そのものが違うかもしれない。

価値を生める範囲が限られたプロジェクトでは、投資対効果に常に注意が必要だ。知らない間に維持費が実際の価値を超え、中長期的には修正を迫られることがある。最近、より使いやすいAPIモックツールのYAPIが保守を停止し、PAPIは今も公式の第一推奨であることを、皆が惜しんでいた。両ツールの組織上の違いをひとまず置くと、YAPIの保守コストが、開発者に与える使い勝手の追加価値を超えたのではないかと私は推測する。データによる裏づけはない。ただ、大半のプロジェクトがYAPIへ移らなかったという結果からは、体験の追加価値が小さく、移行費用さえ相殺できなかったことがうかがえる。

**適切な抽象度で問題を解く。**

問題の本質と、それが存在する範囲を合わせて、初めて本当の問題になる。コンポーネントライブラリは、すでに1つの解決策だ。より高い水準の範囲では、最適解ではないかもしれない。抽象度が上がるにつれ、解決策を大まかに実装、ライブラリ、フレームワーク、標準に分けられる。コンポーネントライブラリは第2の抽象度の解決策であり、MTDがうまくいかなかった理由はここにあると考えている。コミュニティには[A Global Design System](https://component-odyssey.com/articles)というプロジェクトがあり、世界中のデザイナーと開発者に共通部品を提供することを目指している。実際にはコンポーネントライブラリではなくSystemであり、Material Designのようなデザインシステムでもない。この種のプロジェクトでは、成功するかにこだわる必要はない。高い抽象度の問いをどう探索するかを学ぶことが重要だ。

***

事業チームの技術的な仕事は、大きく2種類に分けられる。1つは、現段階で目立つ問題を解く仕事で、力を集中し、1つずつ突破する必要があり、技術の特別プロジェクトとして進めることが多い。もう1つは、コンポーネントライブラリやInfrasなどの開発基盤のように、長く構築・運用し続ける仕事だ。細かく継続した積み重ねが必要だが、適切な運営の仕組みが不足している。実はその仕組み自体が、基盤の活力と生命力をどう保つかという重要な問いへの答えの一部にもなる。

チームが大きくなり、開発の土台が固まるにつれ、私たちの重点も、短期集中型から長期に機能する形へ移す必要がある。

基盤は0から1を作る段階を通り、1から∞へ進む経験を探る時期に来た。今の運営は閉鎖的で、閉じれば個人に依存する。チーム内の貢献意欲は高くなく、上からの指示に頼っている。成熟したオープンソースプロジェクトから学び、開かれた持続可能な仕組みを作って、チームの創造力を引き出したい。

草案は[ワーキンググループの仕組み Working Group](https://km.sankuai.com/collabpage/2610619313)にまとめた。Working Groupの考え方を採り、RFC、Membershipなどを導入した。チームの規模を踏まえ、効率と開放性の釣り合いを取りながら、省略や調整を加えている。考えのある人は、ぜひ意見を寄せてほしい。

***

最近、帳簿関連の事業調整に伴い、フロントエンドもバックエンドも、アーキテクチャの妥当性に向き合っている。妥当性は品質に直接表れ、生意カードのリファクタリングもそこから始まった。フロントエンドの業務アーキテクチャについて、理解を整理したい。

1. アーキテクチャの位置づけは、フロントエンドとバックエンドで対等ではない。フロントエンドでは業務アーキテクチャ設計の合意がまだ十分になく、話題はフレームワークやツールチェーンの選定に偏りがちだ。主な理由の1つは、アーキテクチャ上の難題に直面することが少ない点かもしれない。多くのプロジェクトは、業務アーキテクチャの意思決定による制約に、ライフサイクルを通じて一度も達しない。ひな型から作った汎用プロジェクトで、事業の上限まで対応できてしまう。
2. 何がアーキテクチャ上の決定で、何が違うのか。アーキテクチャは、対話、分析、推論の結果であり、単なるツール選びではない。最終成果のディレクトリ構造や文書だけを見ると、分離と再利用、状態管理、依存性逆転といった重要な概念を見落としやすい。これらのほうが、実際の品質や業務要件を支える能力に関係する。たとえばゲームのECSは、特定領域の保守性を解くアーキテクチャだ。
3. フロントエンドとバックエンドのアーキテクチャを分ける必要があるのか。それとも共通の設計チームだけでよいのか。この問いは広く複雑で、システムの構造はチームの対話の形を自然に映す。コンウェイの法則にはここでは立ち入らないが、2つの見方を挙げたい。第一に、全体設計には徐々にフロントエンドも含まれるようになる。私たちはまだ、少数派の言語から主流の言語へ、自分たちの仕事を理解してもらう途中だ。品質と効率では、すでにフロントエンドが考慮され始めた（技術リスク管理の試験は、まだ実務から離れた情報処理試験のようだが）。アーキテクチャでも遠くないのではないか。第二に、両者は互いから学べる。フロントエンドはDDDなどのバックエンドの設計思想から学び、業務の問題をより深く理解できる。バックエンドは、フロントエンドの効率的なプロトタイピングや、コンポーネントをサービスとして捉える考え方を学べる。
4. フロントエンドのアーキテクチャを理解するなら、[What is Frontend Architecture?](https://ducin.dev/what-is-frontend-architecture)は必読だ。この分野では、著者のTomasz Ducinを継続して追いたい。

***

物理的限界、工学的限界、体験の限界について。先週気になった問いを考えたい。最適化について話すとき、どの水準の最適化を指し、どの境界の内側で行っているのか。

物理的限界を理解する意味は、根本的な制約を知り、複雑な革新の過程でも冷静さを保ち、資源投入を賢く決めることにある。今も永久機関に取り組む民間の研究者がいるが、19世紀にカルノーは熱機関の効率に理論上限があることを示した。永久機関の試みは徒労に終わる。AIが進歩すればすべての問題を解き、人間に取って代わると考える人も少なくないが、20世紀のチューリングなら、この問いには明確に答えられただろう。世界の問題のうち数学的な問題は一部で、そのうち解があるものはさらに一部、チューリングマシンで計算できるものはその一部、現在のコンピュータで実現できるものはさらに一部だ。AIが解ける問題は、その集合の内側にある。物理学の限界を覆すことはほぼ不可能で、数学の限界を覆すことは完全に不可能だ。数学は実験観察から得られるのではなく、厳密な論理の上に成り立つからである。

工学的限界を考える意味は、実践の方向性と効率を高めることだ。既知の物理的境界の内側で、多方面から性能を改善し、工学上の最適解を探す。たとえば赤色光の代わりに青色光を使うDVDは、短い波長によって容量を増やす。2Gから6Gへの発展も、一定の帯域幅と信号対雑音比の下での通信路容量について、シャノンが定めた理論上限を超えてはいない。各世代は、周波数帯、符号化・変調、ネットワーク構成を工学的に最適化している。ムーアの法則は今も続く。シリコンの物理的限界へ近づきながらも、3D積層などのパッケージ技術、SOCやヘテロジニアス計算などの構成上の改善で、性能は伸ばせる。

体験の限界を考える意味は、それが終わりのない営みだと理解することにある。体験は境界と向き合い続ける。人の需要、期待、想像力自体が変化し続けるため、技術がどこまで進んでも、MOTや人間の特性を中心とする体験の改善は終わらない。ある技術水準に達すれば、もう何かを改善しなくてよいという話にはならない。

***

『现金为王』を読んだ。売上は虚栄、利益は賢明、現金こそ王だ。効率がものを言う現在の成熟市場では、とりわけ当てはまる。競争は単純な規模拡大や成長追求から、効率を深く掘り下げるものへ変わる。

本では、体重管理を使って「現金こそ王」という論理を説明している。

1. 小さな皿を使う。節約し、運営費を妥当な有限の資源に収める。パーキンソンの法則という経験則では、供給が増えると需要も増えるという。渋滞を減らすために道路を拡幅しても、増えた車線を埋める車が来るので、いつまでも解決しない理由だ。
2. 野菜を先に、炭水化物を後に食べる。会計の定番式「売上−費用＝利益」を、「売上−利益＝費用」に書き換える。先に利益を取り分け、残りをどう使うか考える。根拠は初頭効果だ。
3. 誘惑をなくし、食べてはいけないものを隠す。取り分けた利益、株主への還元、納税分などを別口座に置く。引き出しにくいほうがよい。
4. 少量ずつ何度も食べ、山と谷をならす。月に2回、銀行残高を確認し、使える現金から経営状態を逆算する。最も単純な銀行残高による帳簿のつけ方だ。

Appleが睡眠管理でアラームを設計し直したことを思い出した。iOSのどの版からかは覚えていない。通常、アラームでは何時に起こすかを考える。Appleの睡眠アラームは、まず目標の睡眠時間に目を向けさせ、そこから就寝と起床の時刻を調整させる。考え方の変化が製品設計に表れた例だ。「利益を先に」という考え方も、小帳簿に同様に反映できるはずだ。

***

半画面オーバーレイ型の決済画面は、再構築後のトラフィック拡大がずっと宙に浮いていた。いよいよ正面から決着をつけるときだ。ほぼ1年、チームの意志を削ってきた問題へ再び向き合うにあたり、選択肢は2つある。私が解くか、人を率いて解くか。管理職としての役割を考えれば、組織は後者を期待していると思う。人を率いて難題に挑むには、心の持ち方、人、目標、戦略を、この順に考え切る必要がある。最初に解くべきは、心の枠組みを組み直すことだ。同じ挑戦にどんな態度と心構えで向き合うのか。新しい姿勢を作り、チームに伝えたい。

ちょうど『Reframe Your Brain』という新刊を見つけた。reframeとは枠組みを設定し直し、現実を自分にとってより役立つ新しい物語として能動的に解釈することだ。FPGAチップのように脳を再プログラムする。心理学にも認知再構成という似た考え方がある。ある状況、経験、考え、感情に対し、自分がどう見ているかを認識し、その見方に疑問を投げ、別の見方へ変える。たとえば、困難を挑戦、挑戦を冒険、冒険を最後にはゲームとして捉えられる。

本には多くの方法が載っているが、重要な1つは受け身を能動的な姿勢へ変えることだ。数年前、Jerryにも似た話をされた覚えがある。「何をやれと言われているか」から「自分は何をやるか」へ変える。さらに、「やりたい（want to）」から「やると決める（decide to）」へ進む。決めることは徹底して能動的で、自分自身へのcommitmentだ。やりたいだけなら、条件が変われば気が変わるかもしれない。だが、やると決めたら、あらゆる手を尽くして成し遂げ、何にも妨げさせない。

こうした心の枠組みの変更は、「精神勝利法」のような気休めなのだろうか。マーケティングとねずみ講が、表面上はどちらも物を売っていても、本質的には最終的な価値を誰が生むかで分かれるのに似ている。組み直した説明で重要なのは、正しいかどうかより効くかどうかだ。正しくない説明でも、自分に効くならそれでよいものもある。

***

先週、決済画面への事業接続で、プラットフォームのコンテナ制約により、事業側が決済製品の種類を切り替えざるを得ず、大きな調整コストを払った事例があった。この機会に、過去のコンテナ切り替えが事業へ与えた影響を整理した。時系列で追うと、重要な問題が浮かび上がった。tiangeの署名にある「標準化の過程で、対象を抽象化しすぎず、規則を単純化しすぎず、行動を機械化しないよう努める」という言葉のとおりだ。私は、対象が具体性を失う問題が最も大きいと思う。金融サービス部門は標準コンテナの最大の顧客かもしれないが、過去の多くの技術判断で、現場の私たちに自ら調査や聞き取りに来た例を見たことがない。事業に入り込み、現場に根を下ろして行う設計こそ、実務に即した設計だ。

プラットフォームが推進する技術製品や標準は、一般に90%の場面をうまくカバーできる。悩ましいのは、残り10%のロングテールが、たいてい「知らなかった」ために漏れ、事業側が体験かコストを犠牲にして設計の欠陥を埋めることだ。プラットフォームへの実感と評価は、まさに最後の10%で決まる。百里を行く者は九十里を半ばとする。品質管理のシックスシグマ理論を思い出す。高水準の結果には、工程能力を6標準偏差の水準まで高める必要がある。最後に残る見えにくい設計欠陥の除去に集中し、周辺やロングテールの問題に目を向け、解決することが、大きな品質向上や競争優位につながる。

自分たちへの戒めでもある。標準化や管理を行うとき、特に注意したい。