私達はエンジニアですので、おそらく性能には敏感だと思います。また API 利用料やインフラの稼働といったクラウドの従量課金にも敏感なはずです。（もう一つ、技術的負債もありますが、これは人次第プロジェクト次第なので割愛しましょう）
もう一つ無視できないものがあります。コミュニケーションコスト です。残念ながら、こちらについては技術的負債と同様か、それ以上に軽視されているように感じます。ここで一つ問いません。
あなたは一日三時間以上、誰にも邪魔されずひとりで作業または議論に集中できる時間帯を確保できますか？
Yes の人、あるいは No だけど「二日に一回くらいなら Yes」の人は問題ありません。これ以外の場合、たぶんコミュニケーションコストがかかりすぎています。
容易に想像できるとおり、コミュニケーションの改善は非常に複雑で難しい（ですから私はソフトスキル・エンジニアリングを立ち上げました）。
それでも改善、特に軽減に向かうためには、シンプルでわかりやすい原則があるといいでしょう。というわけで一つつくりました。
Minimum Main Member Principle とは、メインとなるメンバーを最小限に留めましょうという原則です。
本当は Minimum Core Member としたかったのですが、3M の略称 で揃えたかったので Main としました。
コミュニケーションコストの肥大化を防ぐためです。
理想は一人ですが、一人だとバイアスがかかる点と能力や権威が偏る点がネックです。しかし、人が多いとそれだけコミュニケーションに時間がかかります。皆さんも会議や資料作成、あるいはオンボーディングやメンタリングにウンザリした経験があるかと思います。
よりわかりやすいたとえは、小説やブログ記事、その他ドキュメントの執筆です。一人でも大変な仕事なのに、これを二人で一緒につくるとしたら？と考えてみてください。三人なら？四人なら？――考えるだけで恐ろしいことです。論理的なソフトウェアの世界は、創造的ではあるけれどももう少しマシですが、それでも創造的な世界ではある。「ひとりでつくって」「それを確認してもらう」スタイルが必須なのです。
ですので 1 人よりは多いが、できるだけ少なく済ませるのがベストな塩梅となります。
3M Principle に則ったチームにはいくつものパターンがあります。
最適なパターンを各自模索してください。ここでもいくつか紹介します。
最もシンプルかつわかりやすいですが、レビューを終えた後（アフターレビュー）にどちらが何をするかが不明確です。
典型的にはレビュアー側が上位者であり、アフターレビューを担います。しかしティール組織の助言プロセス（上位者は助言するだけであり意思決定権はない）のように、作業者に任せるスタイルもあります。ただ、アフターレビューには影響の行使が必要ですが、影響は権威がないと与えられないことが多いため、作業者では厳しいこともあります。
役割別の分担です。どの分野も一人で二つ以上行うのは難しい（できるなら独立できます）ので、一役割一人を据えようというわけです。
どれも難しいです。エンジニアはフロントエンド、バックエンド、SRE などフルスタックな知見が要求されます。デザイナーは GitHub や CSS などエンジニアリング寄りのツールも覚えないといけません（でないと 3M ではエンジニアの負担が大きくなりすぎて破綻します）。マネージャーはプロジェクトマネジメントとプロダクトマネジメントを両方行わねばなりません――ね、どれも難しいでしょう？
このパターンでやるなら、本格的なプロジェクトよりも PoC レベルに留めたいところです。
これは私が Worker Triangle と呼ぶパターンです。
まず一番大事なのが手を動かす Worker であり、この人を最大限尊重します。しかし、Worker だけではまかなえない部分が出てくるので、Helper を置きます。わかりやすく言えば、Worker は直接作業、Helper は間接作業を担います。従来だと全員が直接作業も間接作業もやらされますが、そうではなく、優秀な Worker にだけ任せるイメージです。そのかわり、間接作業は Helper がやる。
次に、これだけだと改善や変革ができないので、もう一つ据えます。Advisor です。その名のとおり助言を行うのですが、対象は Worker ではなく Helper です。というのも、Worker は直接手を動かすことに特化しているので、改善や変革といった目線には弱いからです（エンジニアがソフトスキルを嫌うのと一緒です）。しかし、それでは何もできないので Helper を経由させるわけです。
Worker <--> Helper <--> Advisor
そういうわけで、一番重要なのは Helper だったりします。Worker の事情を理解して Advisor に伝えるのはもちろん、Advisor からの先進的な提案も理解した上で、それを Worker に伝えなければならないからです。そういう意味では、Helper ではなく Transolator と呼んでもいいかもしれません。