ポール・ハードリーを叩いてる人が多いけど、「多い」ってほどでもないよ。ネガティブなコメントは3つくらいで、そのうちの1つは記事自体を批判してるだけでポールのことじゃないし。良いポイントを挙げてると思ったけど。

成功しているビジネスや価値のあるビジネスが、必ずしも何百万、何十億のユーザーを持っているわけじゃないってことも大事だよね。私は会社の内部ツールに関わってるけど、自分たちの環境がどれくらい大きいか分かってるし、パフォーマンスに敏感ではないし、自分たちが引き起こさないランダムなスパイクもない。だけど、チームにすべてを最適化しようとする人がいて、その人は自分だけが知ってる新しい言語にコードベースを全部変えちゃったんだ。数ミリ秒を節約するためにね。彼以外は誰も気にしなかったし、誰も気にしてなかった。彼の最適化はリスクを生むだけで、彼だけがサポートできるものを作ってたから、彼が辞めたとき、管理側の要求で全部捨てちゃった。もう少しシンプルで遅ければ、他の誰かが手を加えるのも楽だったかもしれない。

「早すぎる最適化をするな」とは大きな違いがある。「早すぎる最適化」というのは、スケールしたバージョンが最適であることを示唆している。達成するためのリソースコストが見合わないかもしれないけど、それを無視すればそれがベストだと。対して「スケールしないことをやれ」は、スケールしていないプロセスが最適かもしれないってことを示唆している。例えば（これも記事にあったと思うけど）、CEOに直接連絡先を渡す代わりに、共有のカスタマーサービスや営業の受信箱に送信される一般的なフォームを使うのは、製品を売るためのプロセスとしてはずっと良い。問い合わせフォームはスケールするけど、早すぎる「最適化」ではない。別の言い方をすると、スケーリングは悪い。もう少しニュアンスを加えると、必要悪だ。複雑だし、リソースを多く消費するし、顧客との距離を生む。もちろん、ビジネスの目標や環境によってはそうなることもあるけど、それがプロセスの質を低下させないわけではない。だから「早すぎるプロセスの劣化を避けるべき」って言った方がいいと思う。

「自分よりずっと大きな会社のように振る舞おうとしないで」これはいいポイントだね。

成功した会社を作ったことがない人もたくさんいるよね。

多くの人が、一夜にして成功したいと思っているけど、その重圧に耐えられなくなったり、勢いを失ったりすることを心配しているんだよね。だから、水平スケーリングの必要が出る前に、すごくスケーラブルなものを作ろうとする。僕は垂直スケーリングが過小評価されていると思う。モノリシックなバックエンドにリソースを追加するだけで、製品をどうスケールさせるかを理解するための時間を十分に稼げるんだ。もっと重要なのは、ユーザーが求めている製品の強みを再考する時間が得られること。それによって、何をスケールさせるべきかを理解できるようになる。ユーザーが本当に製品を愛してくれれば、パフォーマンスが不安定でも許してくれるよ。初期のTwitterは、すごく不十分なアーキテクチャ（Railsアプリ）で作られていて、よく落ちたりしてたけど、「フェイルクジラ」を覚えてる？それでも、ユーザーはどんどん集まってきたんだ。なぜなら、重要なことをちゃんとやっていたから。僕にとって、初期段階は簡単に反復して、ユーザーを喜ばせる要素を見つけることが全てだと思う。スケーリングは無視して、実験して、ユーザーの声を聞いて、話をしよう。うまくいったら、その時にスケーリングを考えればいい。予想外のタイミングで起こるかもしれないし、最適化できないこともある。テクノロジーは道具であり、楽器なんだ。ストラディバリウスを持っているのは素晴らしいけど、まずは良い音楽が必要だよね。

「自分よりずっと大きな会社のように振る舞おうとしないで」これは、あらゆる段階の組織にとって本当に良いアドバイスだと思う。コンサルタントとして、スタートアップや小さな会社が、自分たちが法人だからといって必要ないポリシーを採用して自分たちを縛ってしまうのを防ぐために多くの時間を使っている。そういうポリシーは、最低でも数百人が関与している組織でしか意味がないからね。k8sからnosql、過度に制限されたセキュリティポリシーまで、いろいろあるよ。Netflixの従業員ハンドブックが、このポイントを強く印象付けてくれた。小さいうちは、良い人材を雇っているなら、実際にスタッフにリアルな責任を委譲して、彼らの判断を信じることができる。リスクが許容できないレベルに達するか、問題が明確になるまでは、すべてを厳格なルールにする必要はないんだ。

要するに「持っていない問題を解決するな」ってこと。

お金を稼ぐだけでいい。指標（例えば利益）が目標になると、それは良い指標ではなくなる。 -- グッドハートの法則。