スケーラブルな仕事をするには、スケーラブルな問題を扱う方が都合が良い。プログラマにとってのスケーラブルな問題は、時間をかければかけただけ、沢山のプログラマがいればいるだけ、成果がでる問題と言える。そういう問題はあまりない。でも大きなテック企業はそうしたスケーラブルな問題を解くことで成り立っている、気がする。

プログラマにとってのスケーラブルな問題には大きく2つの特長があると思う。一つは部分問題の直交性が高いこと。開発者やチームの間で多くの協調作業を必要とする問題はつらい。個々のプログラマ、とまではいかないけれど、個々の小さなチームが、それぞれ勝手に部分問題をみつけて解く。その総計が全体の答えになる。機械学習のアンサンブルみたいなかんじ。個々の部分解が互いに矛盾、衝突しやすい問題だと調整が必要でスケールしにくい。

もうひとつの特性は、最終的な成果（たとえば売上）がプログラマにとって扱いやすい指標と強く相関していること。検索連動広告や推薦アルゴリズムはその精度が高ければ売上に直結する。ブラウザはページのロードが速いほど人気が出る。など。プログラマにとって戦いやすい問題を解くことがそのまま成果に繋がるなら、経営者は良いプログラマを集めてプロジェクトにつっこめばよい。プログラマは目の前にあるエンジニアリング上の問題を次々にとけばよい。スケールする。

問題のスケーラビリティについて思い至ったのはUberについて書かれた記事を何かで読んだ時だ。Uberは配車のアルゴリズムを改善すればしただけサービスがよくなり、売上も増える。配車アルゴリズムを評価する指標はそれほど自明でもないけれど、賢い人がよく考えればうまく定義できるだろう。たとえば配車リクエストから自動車到着までのレイテンシが主要な指標の一つなのは間違いない。そしてレイテンシはソフトウェアの問題に帰着できる。そんな風に問題全体を定義できたなら、あとはばんばんプログラマを雇えば良い、気がする。

ウェブ検索は、たぶんすごくスケールする問題だった。ブラウザ開発も、検索ほどではないにせよスケールできる性質はあって、その部分はどんどん良くなった。一部のソーシャルメディアも何かそんな問題を見つけたのだろう。それがなんなのかはわからないけれど。

UIを変えるとか機能を増やす仕事はスケールしづらく見える。画面のreal estateは機能同士が奪い合う資源だから直交とは程遠いし、新しくなったUIや増えた機能と最終的な成果(ユーザ数、売上など) の関係もはっきりしない。洗練されたユーザトラッキングやデータ分析の手法を使えばわかることも多いのだろう。でも精度とかレイテンシとかの方がわかりやすいよね。

Lean 一族をはじめ、起業家精神あふれる人々は問題を見つける難しさをずっと議論してきた。異論はない。一方で大きな問題の袖を掴んだあとに何をすべきかはよくわからない。工学上の指標として問題を定義し、直交した部分問題に分割し、その上に問題解決のプラットホームを作り出す方法。組織論にはそんな話がありそうだ。ソフトウェア開発の言葉でそれを説明したものがあるなら読みたい。Microservices なんかは近いかも。