記事であまり触れられていない重要なポイントは、時間とともに開発スピードがどう変わるかってことだね。プロジェクトやチームの規模が大きくなると、時間が経つにつれてそのスピードは落ちていく。減少率を最小限に抑えるためには、長期的な速度のために短期的な開発を遅らせるようなことをしなきゃいけないかもしれない。例えば、テストやドキュメント、意思決定ログ、アジャイルのセレモニーなんかがそうだね。初期開発でのいくつかの見落としは、後々長い間ネガティブな影響を及ぼすことがある。例えば、最初からコードに観測可能性を組み込まなかったり、テストしやすさを明確な目標にしてコードを構造化しなかったりすることが挙げられる。

「未知の未知」を明らかにすることができる。プロトタイプは、予想できなかったことを明らかにすることが多い。これは僕の経験とは真逆だな。何かをいじっているときは、良い部分だけを体験していて、悪い部分は全く感じない…いわばハネムーン期みたいなもんだ。エッジケースをカバーしたり、無効な状態を防いだり、ユーザーに役立つエラーメッセージを表示したり、潜在的な副作用を排除しようとするまで、「未知の未知」に気づくことはない。

スケールがここではかなり重要だと思う。自分で何かを作ったり、小さなチームでやっているなら、投稿に書いてあることには完全に同意するよ。実際、そういう状況では迅速で雑な開発手法に頼るべきだと思う。これが小規模開発の強みだからね。うまくやれば、大きなプロジェクトよりもずっと早く進められる。バグは小さなチームやソロ開発者にとってはほとんどいつでも簡単に修正できるし、関わる全員がプロジェクト全体のほぼ完璧なメンタルモデルを持っているから、コード自体もコンウェイの法則のおかげで比較的シンプルに保たれる。大規模な開発プロジェクトでは、バグや特にアーキテクチャのミスを修正するのは、コードの理解が断片的で、アーキテクチャが悪夢のように複雑だから、指数関数的にコストがかかる。大規模なリファクタリングは、コードベースの一部をロックダウンすることを意味して、数十人から数百人が何もできなくなる（つまり、ほとんど起こらない）。そんな状況では、全てのステップでの正確さが重要な焦点になるべきだと思う。スケールの経済は、個々の開発者がそんな風に働いていても、許容できるペースで物事を進める助けになるよ。

最近、十分に堅牢なシステムを素早く構築する方法を学んだよ。ここで学んだことをいくつか挙げるね。* 一つのツールをしっかりと使いこなすこと。表面的には問題に適しているように見えるツールよりも、自分がよく知っているツールを使う方が多くの場合良い。非常に多くの現実の問題に対して、Djangoは絶妙な選択なんだ。何度かプロジェクトを始めるときにDjangoは重すぎるかもと思ったけど、すぐにそのプロジェクトは初期のアイデアを超えて成長した。例えば、最近ステータスページアプリを作ったんだけど、最初は単一ファイルのDjangoアプリだったけど、Djangoの制限を回避するのは意味がないとすぐに気づいた。* Djangoモデルに合うアプリケーションでは、データモデルが全ての中心にある。ラフなプロトタイプを作るときでも、データモデルのリファクタリングを後回しにしないこと。時間が経つにつれて、変更するのがどんどん高くつくし難しくなるから。* ほとんどのアプリケーションはシングルページアプリである必要もないし、重いフロントエンドフレームワークも必要ない。恩恵を受けられるものでも、従来のDjangoビューで80%のページは十分だよ。残りについてはAlpineJS/HTMXを考えてみて。* ほとんどの場合、自分で作った方が簡単だよ。顧客を保存して編集する必要がある？Djangoを使えば、数時間でアプリ内にシンプルなCRMアプリを開発できる。商業CRMを統合するのはもっと時間がかかる。これはステータスページ、CRM、サポートシステム、営業プロセスなど、ほとんどのDjangoアプリやライブラリにも当てはまるよ。* いつも超つまらない技術を選ぶこと。全てにPython/Django/Postgresを使って。KubernetesやRedis、RabbitMQ、Celeryは忘れて。Alpine/HTMXは例外だけど、JavaScriptスタックの多くを避けられるからね。