多少大きめのプロジェクトになると、当然ながら同じシステムを複数チームで開発をすることになります。その時に、皆さんはどのようにチームを分割しますか？
この図は、かなり簡略化しているので、実際はこのように単純にならないとは思いますが、説明のために簡潔にしてみました。
- 同一アーキテクチャチーム（機能横断）
同一のアーキテクチャレイヤーを一つのチームとして作る場合。メンバー構成として、同じ技術やアーキテクチャへの知識を持っていればいいので、チームは作りやすい。ただ、実際機能を作る局面になると、別々にプロジェクト管理をする必要がある。
- 機能別チーム（アーキテクチャ横断）
同一の機能を一つのチームとして作る場合。顧客の意向やプロダクトの目的を共有しやすい。ただ、アーキテクチャを横断するため、複数のアーキテクチャや技術を習得する必要がある。
当然ながら例えばこの2パターンを考えただけでも、チーム作りの仕方は全然変わります。どういうメンバーが必要か、プロダクトへの姿勢やプロジェクト管理の方法など、少し考えるだけでも、いろいろな要素があります。
同一機能チームを目指したい
私の周りでは、どうしても作りやすさを優先して同一アーキテクチャのチームを作りがちなのですが、何のためのプロダクトかを考えると、機能別チームを目指したいところです。とはいえ、アーキテクチャがあまりにも違いすぎるとその学習コストが大きすぎる。それを上回る利点を出すことができなくなる。
そうなるとパフォーマンスが出なかった場合、盲目的に考えると、チームが悪い、チームの努力が足りないということになることを見てきました。でも、本当にそうなのか？というのが最近の私の疑問です。
アーキテクチャを選択する基準
アーキテクチャは、もちろん技術的に優れているとか、パフォーマンスが出るとか、開発効率が良いとかそういうことを基準に含めるべきだと思いますが、実際に開発するのがチームだとすると、チーム（人）のことも考える必要があると思います。
技術要素に加えて、アーキテクチャを選択する際に考えたほうが良いと思う要素を挙げてみます。
- メンバー構成（想定される個々が保持している技術）
- 別々にモデリングされても同一または近い技術である
- オープンな技術（学習コストの低さ）
- 社外に出ても技術が使える（習得したい）
- 社外に出てもエンジニア同士で会話が通じる技術
- エンジニアが成長できる（奥が深い）
システム開発は人間でありチームがすることです。そう考えると、抽象化されているアーキテクチャというレイヤーであっても、人間的な部分を含める必要があるのではないかと最近感じています。もっと言うと、そこまで考えないと真の高いパフォーマンスに近づけないのではないでしょうか。
