スクラムチームにおける従来からの役割には、プロダクトオーナー、開発者、スクラムマスターがある。明らかに存在していないのが、チームリーダーの役割で ある。チームは、自己管理することが求められる。同様に、オルフェウス室内管弦楽団(リンク)は、チームでリーダーシップを共有して決定を行うというプロセスを支持 し、指揮者の役割を完全に省いた。その結果、世界で最も有名な室内管弦楽団の1つに成長した。その過程でオルフェウス室内管弦楽団は、スクラムチームが利 益を享受できるような連携方法とレッスンを身につけた。
「IEEE Engineering Management Review」(リンク)の最新版には、「The Conductor-less Orchestra（指揮者のいないオーケストラ）」(リンク)というタイトルの記事が掲載されている。これは、「Leader To Leader Journal」(リンク)のこの中(リンク)で以前に公開されたものである。この記事では、オルフェウス室内管弦楽団が従来の指揮管理リーダーシップモデルを、オルフェウス プロセスと呼ばれる、より参加型のモデルに置き換えることで収めた成功について論じている。このプロセスは、8つの原則に基づいている。
原則1: その仕事をしている人に権限をもたせる
楽団が創設された1972年当時からのメンバーであるコントラバス奏者のDon Palma氏によると、オルフェウスでの仕事と従来のオーケストラでの仕事には、劇的な違いがあるとのことだ。Palma氏は、次のように述べている。 「私はごく初期の頃にオルフェウスを1年ほど離れ、ロサンジェルス・フィルハーモニックに行きましたが、そこでのやり方が嫌でした。常にやるべきことを指 示され、従順な兵士であること以外に価値がないかのように扱われるのが嫌でなりませんでした。物事に影響を与えることへの無力さを感じました... 一方、オルフェウスは、私に関与させます。私は、音楽が進んでいく方向に関与することができるのです。それこそが、私たちの多くが長い間この楽団に参加し 続けている理由であると思います。」
同様に、従来式に編成されたソフトウェア組織のメンバーは、チームや製品に影響を与える権限をほとんど持っておらず、コードを作成する能力だけが評価され ると思っているかもしれない。スクラムチームのメンバーは、チームと製品の全体的な成功に可能な限りの方法で協働して貢献することが期待される。
原則2: 製品品質に自己責任を負わせる
オルフェウスには指揮者がおらず、パフォーマンスの質に責任を取る人物がいないため、オーケストラの各メンバーが楽団の成果に対し非常に実質的かつ個人的 な責任を感じている。オルフェウスはメンバーの一人一人に指揮する機会を与えているが、それによって皆が一丸となって協力するという責務が生まれている。 各演奏家は、パフォーマンスに対する独自のアプローチを完璧にすることだけに焦点を合わせるのではなく、仲間のパフォーマンスやオーケストラ全体の音を完 璧にすることに個人的関心を持っている。
スクラムチームの場合、品質はチーム全体の責任である。1人の担当者のコードにバグがなくても、コードの他の部分の問題によって製品が使用できなければ何 の価値もない。そのため、チームメンバーは、ビヘイビア駆動開発(リンク)、ペアプログラミング(参考記事リンク)、継続的インテグレーション(リンク)、自動化された承認テスト(参考記事リンク)など、品質を向 上させる手法を探して採用することが要求される。さらに、スクラムのレトロスペクティブ（ふりかえり）(参考記事リンク)の手法は、チームが手法を改善できる領域を見つける ことに役立つ。
原則3: 役割を明確にする
オルフェウスには指揮者がいないが、明確に定められた役割がある。オーケストラが演奏する曲ごとに、1人のメンバーがコンサートマスターとして選出される。その他の明確な役割も適用される。
スクラムチームの場合、3つの明確に定められた役割がある。プロダクトオーナー(リンク)、スクラムマスター(リンク)、および開発者である。プロダクトオーナーは、プロダク トバックログを管理し、どの機能に最初に取り掛かり、どれが待機するかの優先順位を決定する。スクラムマスターはプロセスに注意を配り、通常はミーティン グや重要なチームのやりとりを円滑にする。開発者は製品を作成する。「開発者」という包括的用語には、ソフトウェア開発者の他に、テストや文書化を専門と する人物が含まれることもある。
原則4: 平等なチームワークを育てる
オーケストラ内で生じるあらゆる質問に対するすべての答えを持っている人物が存在しないため、オルフェウスは、メンバー全員の専門知識を活用するために、 公式・非公式に平等なチームに頼っている。メンバーが非常に限られた問題や機会だけに焦点を絞ることに人為的に制限されないため、チームは平等である。オ ルフェウス内のチームのメンバーは、組織の境界を越えて自然に通じ合い、アドバイスを得たり、機会に影響を与えたり、問題を解決したり、決定を行ってい る。
スクラム(参考記事リンク)、そして特にスクラムのスクラム(リンク)は、この平等なチームワークの概念をソフトウェアプロジェクトに適用できるフレームワークを提供する。
原則5: リーダーシップを固定させない
ほとんどのオーケストラには、1人のリーダー、つまり指揮者がいる。演奏家は、指示に従って演奏することを求められ、一般に自身の解釈を表さない。オルフェウスは、曲ごとに意図的にリーダーシップを交代させ、特定の曲に対する知識や情熱に基づいてリーダーを選んでいる。
スクラムチームの場合、正式なリーダーが存在しないことで、各個人が自身の知識やスキルがチームの現在のニーズに最適なときにリーダーシップを発揮でき る。チームの最優先事項が品質の問題を解決することである場合は、QA担当者が取り組みを率いることができる。また、チームがリファクタリングによって コードの設計やアーキテクチャを調整する場合は、上級開発者やソフトウェアアーキテクトがリーダーシップを取ることができる。
原則6: 話の聞き方、話し方を学ぶ
オルフェウスのメンバーは、コミュニケーションのパワーを知っており、それが組織の活力源である。メンバーは、お互いの見解や意見を聞き、同意する、しないに関係なく発言の内容と発言した人を尊重することが求められるだけでなく、話すことも要求される。
明瞭かつ継続的なコミュニケーションはソフトウェアプロジェクトの源でもある。日常のスタンドアップ(リンク)ミーティングや、レトロスペクティブ（ふりかえり）(参考記事・リンク)や、スクラムマスター(リンク)の関与などの手法は、浮かんだアイデアや情報を維持することを目的としている。
原則7: コンセンサスを形成する（コンサンセスを支持する創造的なシステムを構築する）
オーケストラにとって決定の重要性が高いほど、より大勢の人がその決定に関与する。これは、非常に重要な決定は組織図の上層部の数人で行うというビジネス 界の大部分とは対照的である。コンセンサスによって創造的な決定を行うことは、個性や面白みのない結果につながる恐れがあるというのはもっともな意見に思 えるが、オルフェウスの結果は、必ずしもそうではないことを証明している。オルフェウスは、その素晴らしさを国際的に認められ、定期的にカーネギーホール で公演し、グラミー賞までも受賞した。
従来のソフトウェア組織では、アーキテクチャや設計などの重要な決定は、選定された人物によって行われ、その後、他のメンバーに渡されて実施される。スク ラムチームは、チーム全体が理解して支持する決定に達するように、できるだけ多くのメンバーと一緒に重要事項について議論する傾向がある。
原則8: 職務へのひたむきな献身
仕事に対して熱意がある従業員は最高の製品、チーム、および会社を作ると一般的に信じられている。オルフェウスプロセスは、参加への障害を取り除くことで各メンバーの情熱を引き出すことを目的としている。
オルフェウスのメンバーが組織に感じている情熱は、次の事実で測ることができる。それは、メンバーの大半が、ニューヨークフィルハーモニック管弦楽団やメ トロポリタンオペラなどの他の楽団でも演奏したり、ジュリアード音楽院やマンハッタン音楽院などの学校で指導したりしているが、オルフェウスでの演奏が最 も充実した音楽的経験であるとみなしているということである。
スクラムは、オルフェウスプロセスと同じような方法で機能して、各チームメンバーの情熱を解き放ち、可能な限り最高のソフトウェア製品を作るように働きかけ、権限を与えている。
原文はこちらです：http://www.infoq.com/news/2008/07/self-organizing-orchestra-orpheu