専門的な技能を持った個人の集団がコミュニケーションを取りながら成果物を完成させるという点で、ソフトウェアエンジニアリングチームはオーケストラに似ている。長い期間に渡って同じシステムを育て続けるチームを想定している。
似ていること
- 一人ひとりの能力の総和が単純にチームの能力にならない。良いコミュニケーションと良い文化・伝統が必要。
- 一人のスーパースターの存在は、ある程度成果物の質に効いてくるが、決定的ではない。トランペットだけ超うまいオーケストラはトランペットパートで見せ場を作れはするが、それが他の弱点を覆い隠せるわけではない。スーパーエンジニアはアーキテクチャを設計できるが、同時にチームを教育し浸透させないと少しずつアーキテクチャの意図からズレたコピペが横行し、破綻する。
- 技術的なボトルネックの解決とかは一人で大きく貢献できるかもしれない
違うこと
- ソースコードは有形で永続化されている。いつ誰がどのような判断でその一行を書いたのか、高い確率で検証することができる。
- オーケストラも楽譜に歴史が刻まれているとは言える。オーケストラは楽譜を所有しており、過去にやった曲であれば当時の書き込みが残った状態で使う。指揮者が変わって演奏指示が変わったりした場合は書き込みが更新される。しかしgitのように履歴を追跡できるわけではない。
- コードを全く触らなくてもある程度の期間は動かし続けることができる
- 新人をカバーし教育をすることができる。オーケストラでは一人音程が違えばバレてしまうが、ソフトウェアエンジニアリングではプルリクエストとレビューを通してカバーすることができる。
- リアルタイム性の違い
- しかし負担は大きい。『人月の神話』で論じられているように、新人の教育役として作業から離脱する人間が出るので人員追加の採算が取れるまでの時間が長い。
特にここから何かを主張したいというわけではない。それほど考えを深めているわけではない。しかしオーケストラの組織運営は何百年という歴史の中で洗練されてきたので、ソフトウェアエンジニアリングチームもそこからなにか学ぶことが、できたりできなかったりするかもしれない？
- 全体の方向性を指示し、ときにはマイクロマネジメントを行う指揮者（ただしそれらの指示は全て全団員が聴いている）
- 桜井政博氏も組織論の動画でディレクターの指示は誰でも自由に聞ける場でやるって言ってた
- 全体に対してより具体性の高い指示を出すコンサートマスター
- 同一の演奏機能を有する奏者が1つのパートを構成する（レイヤードアーキテクチャ+コンウェイの法則？）が、その中でも1st, 2ndのような役割分担がある
- パート内ではパートリーダーに合わせる
- パートリーダーは必要に応じて他パートと調整を行う
こう、風呂で思いついたときにアイデアとしては面白いと思うんだけど、文章に纏めてみると大した内容じゃないなってやつ、あるある。