[のだめ開発] 指揮者 Conductor の役割とは(2)

とある会社で、社内研修をすることにしました(技術顧問も兼ねています)。もとが保守の会社なので、そこにプログラミング要素を付け加えるというパターンで研修内容を組み立てています。なので、プログラミング研修よりも、もっと直近的に使える「社内ツール」を自作できる、程度まで引き上げます。最終的には、製品の内製ぐらいまでですかね。

あまり、言わないようにしているのですが、SE(システムエンジニア)とPG(プログラマ)のためのスキルは別ものです。両方持っているに越したことはないのですが、それぞれが「プロフェッショナル」として仕事をする以上、どちらかの技術に精通している(ゆえに、片方の技術があまり精通しなくてよい)というスタイルになります。仕事上は「分掌」という言い方もしますが、住み分けというか得意分野というところですよね。プロ/仕事なのだから、普通の人よりも十数倍早く出来上がるというのは意外と重要な要素です。その差分が、「支払ってもらう金額」なのですから。

オーケストラというチームビルディング方法

以前、[のだめ開発] 指揮者 conductor の役割とは | Moonmile Solutions Blog を考えていたときは、「カンタービレ」のほうを考えていたのですが、今回は「オーケストレーション」のほうに重きを置きます。詳細は「のだめカンタービレ」を読んでもらうことにして、ソフトウェア開発の視点からオーケストラを見たときの類似点は、専門家の集団ということです。これは、アジャイル開発でもウォーターフォール開発で同じように使えるチームビルディングの方法です。逆に言えば、専門家ではない人を集めてチームビルディングする方法もあります。以前、Microsoft が提唱していた「ソフトウェアファクトリー」とか、Intelが採用している標準的なスキルによるチームビルディングです。これは、どちらが良いとか悪いとかいうのはないので、適材適所でチームの作り方を選びます。勿論、チームに入っているのは「人」なので、その人に向かないチームもあることを忘れないでください。そういう時は、浅田彰の「逃走論」を読んで、清くチーム/会社から去ることをお勧めします。これは、デマルコ著「ピープルウェア」やヨードン著「デスマーチ」でも言われていることですので忘れずに。

さて、今回の研修のように、

  • 中途入社が対象
  • システムエンジニア、プログラマが混在

というスタイルでチームを組む場合は、いわゆる LLC/LLP(合同会社/合資会社)に近い形態でチームを組みます。LLCとLLPは会社法的には異なるものなのですが、ここでは「各自のスキルを持ち寄る」というところに注目します。

ちなみに、新人/自発的に動けない人/モチベーションが低い人、を混ぜるとこの方式は取れません。これは、新人等を否定してるわけではなくて、そういう場合には別なチーム作りがあるということです。例えば、命に係わるようなことは「軍隊式」じゃないとうまくいかない場合もありますからね。そこは、心理学や社会学も含めてベターな方法を選びます。

LLC の場合、それぞれが専門家≒独立できる程度のスキルを持つ人達を集めて、ひとつの会社を作ります。最大のメリットは、営業口を一本化できることと、他の専門家のスキルを自分のスキルとして借りることができる、ということです。いわゆる横のつながりですよね。「引き合わせ」というスタイルです。これは、人材派遣会社と被派遣の関係とは異なります。相互にスキルを渡し合うので、対等な関係になります。LLC の場合、弁護士や医者などの独立した専門家で組むことが多いのですが、実は同じスキルじゃないほうが効率的にチームが組めます。同じスキルの場合は、自分の溢れた仕事や遠地などの都合のあわない仕事に対して、他のチームメンバに振ることになるのですが、異なるスキルの場合は、各専門家に仕事を割り振るというスタイルになります。ちょうど、建築/土建における施工のような感じで、左官、電気工事、内装などの専門家がそれぞれの仕事を受け持つという感じですね。ゼネコンスタイルになると、一次請けという上下関係が発生してしまいますが、もっとフラットな関係になります。

このフラットな関係が「オーケストラ」のスタイルになります。ひとつのオーケストラにおいて、楽器は別々ですが、上下関係があるわけではありません(ヴァイオリンのように第1、第2や、コンサートマスターという役割もありますが、それはチーム内のチームという関係です)。また、楽器の奏者が交換可能というわけではありません。奏者はそれぞれソロでも弾ける実力を持ち、さらにオーケストラとして集まるというチームビルディングの方法です。

ちょうど、システムエンジニア、プログラマ、テスター、データベースアドミニストレータなどが集まってチームを組むところと似ています。大抵の大手のプロジェクトでは、SIer を中心にして系列会社/下請けに割り振るという「ゼネコン」方式を取りますが、独立系の保守会社やソフトウェア会社であれば、オーケストレーションの手法を使えます。

そんなわけで、

  • 色々な専門家を集める
  • 専門家は対等な関係を維持する

を使ったチームを「オーケストレーションによるチーム作り」と呼ぶことにします。

既存のチームビルディングとしてはアジャイル開発スクラムが、オーケストラに近いのですが、専門家の範囲が狭いのと「スクラムマスター」という制度ができてしまったので避けておきます。かつ、スクラムマスター等の「管理/交渉/調節役」と「指揮者(コンダクター)」の役割がかなり異なります。

指揮者 Conductor の役割

のだめカンタービレには、指揮者が何人か出てきますが4巻ぐらいまでの、千秋とシュトレーゼマンの指揮のスタイルを見れば、まずは十分です(もちろん、その先にも色々参考にできるメタファーもあるので、それはおいおいに)。

千秋が、自分の音を表現するために、強烈な主導権をもって指揮をします。それぞれがうまくない学生オケの場合は、奏者のスキルが低いので、そういう教鞭的なスタイルも重要です。これは新人を含めたウォーターフォール形式によいでしょう。しかし、ある程度、おのおのの奏者のスキルが上がっていくと、指揮者の役割は変わってきます。

シュトレーゼマン曰く「楽しい音楽の時間デス」に尽きるのですが、厳しいスキルアップの後には「楽しく」スキルを披露することが重要です。ソフトウェア会社において、スキルを披露するということは、現場でのハードウェアのセッティングであったり、徹夜でのトラブル対処であったり、長期/短期に関わらずソフトウェア開発であったります。いわゆる、顧客に何を「披露」するのかが、重要になってきます。

奏者それぞれのスキルが十分であるならば、複数の奏者がスキルを合わせられるように、出番をそれぞれ調節していくのが指揮者の役目です。勿論、単なる「進行」役(プロンプタ)ではないので、指揮者の目指すところに指揮(誘導)をします。

このあたりが、スクラムマスターとは異なるところで、主にスクラムマスターが強弁であることが重要になる(顧客の対処への交渉力が必須)のに対して、指揮者(コンダクター)は強弁である必要はありません。少しもじるならば「雄弁」ある必要ありますよね。イメージを膨らませて、聴衆(顧客)や奏者(メンバ)に自分のイメージを伝える必要があります。この指揮の仕方は、のだめカンタービレにも出てきてパリ編の指揮のコンテストにも出てきます。

そんな訳で、指揮者(Conductor)と専門家(Professional)の組み合わせが「オーケストレーションによるチームビルディング」の基本になります。

でもって、具体的な話は研修にて。でもって、興味があれば相談してください。研修に加えるか、別途時間を作るか考えます。

補足…「響け!ユーフォマニア」もブラスバンドでチームビルディングの好例なんだけど、あの場合はスキルの低い奏者を集めて指揮者/指導者が引っ張る形(物語的には高校生の成長もあるし)なので、ちょっと違うかな。原作4巻はお勧め。

カテゴリー: のだめ開発プロセス パーマリンク