のだめカンタービレ – Wikipedia を見ると、原作のほうは2001年から、アニメのほうは2007年から、ということで、TOMOKO NINOMIYA WEBSITE が二ノ宮女史のページ
音楽のオーケストラを、ソフトウェア開発のオーケストレーション（コンピュータ用語では、自動化の意味を示すのだけど、ここでは、本来の意味の Orchestration アンサンブル 管弦楽法 – Wikipedia のほうに意味にあわせる）を考えたときに、以前は「指揮者 Conductor」を「プロジェクトマネージャ project manager」と同値に考えて、「管理者」という言葉の響きからくる「管理する人」「管理される人」という区分を類推してしまい、いまいち…と思っていたのですが、ちょっと思い直して manager とは違う、本来の意味の conductor から、ソフトウェア開発プロセス/チームを考え直してみよう、という企画です。つーか、まぁ、妄想も大いに。
アニメの lession 5 で、S オケで千秋真一君が失敗したのは、コンダクターではなくて、オケを管理しようとしていたから、という解釈をして話を進めていくと、
- オーケストラのメンバを「支配」しようとうする management をすると、失敗する例
として挙げられる。その後に、シュトレーゼマンが、S オケのメンバをとりなす手法は、ワインバーグの言う「くすぐり」の手法なんだけど、これが conductor の手法のひとつでもあるワケ。これを、そのまま複数名のソフトウェア開発に当てはめると（ウォーターフォールでも、アジャイルでも同じ）、
- プロジェクトメンバを「支配」しようとする management をすると、失敗する
となる。ただし、これは類推にすぎなくて、実はソフトウェア開発として「支配的」に行う場合もあり得る。「支配的」≒「mission commander と soldier の関係」ということですね。いわゆる「軍隊式」という奴です。「社畜といえども楽しい職場」という言葉がある通り（これはある）、soldier 的に働いている方もいらっしゃるわけで、逆に言えば、何も全てを「アジャイル式」にしなくてもよいし、何も全てを「軍隊式」に仕上げなくても良い。それぞれの company の風土もあれば、mission も様々で、オーケストラが様々なように、オーケストレーション自体も様々、という具合。
…が、ここでは、本来の「オーケストレーション」を目指してみると、
- プロジェクトメンバを「支配的」に扱うと、そのプロジェクトは失敗する確率が高くなる（ほぼ 100% に近くなる）
- プロジェクトメンバを「支配的」に扱わないことが、唯一のオーケストレーションの道である。
と結論付けられる。ここで言う「支配的 dominant」を再定義すると、千秋真一君が「俺の言う通りに演奏しろ」から派生させて、
- 「俺の設計通りに作れ」
- 「俺のスケジュール通りに進めろ」
- 「俺のリスク管理は完璧なんだ（俺の感知しないリスクは考えなくていい）」
- 「俺のワークの分け方 WBS は完璧なんだ」
ってところで「俺様」風が発生してしまうと、アレなわけです。このあたり、しばらくのだめを見続けると、先にももう一つ指揮者コンクールのシーンがあります。
この「俺様」のところ、管理的/支配的（本来の management の意味とは離れるので、commander のほうを充てるのがよいかも）に頭の中の展開を「絶対」にしてしまうところにが「軍隊的」であったりします。いやいや「俺様」自体は実は悪くは無くて、
- 「俺が考える最高の設計を作った」
- 「俺が考えるできる限り実現可能なスケジュールを立てた」
- 「俺の考えるリスク管理だ」
- 「これは、俺の WBS の分け方だ」
というような、「俺様」カテゴリ内の「事実/製作物」だけ取り出せばよいわけで、それを未知なる現実やプロジェクトメンバとの突合せとしての現実にあわせたときに、そこに出てくるのは conductor の技法なわけです。メンバ自体は、実はばらばらの「理想」を持っている（あるいは「技量」を持っている）ので、それを加味した上で（それは指揮者の技量かもしれず、あるいは現実解なのかもしれず）、全体としてのオーケストラを作り上げて、音楽を作り上げる（観客に聴かせる）という目的を達成するわけです。
これを、ソフトウェア開発の管理者、指揮者、プロジェクトマネージャに引き合わせてみると、理想としての目標あるいは目的、あるいは現実としての目標を掲げると同時に、その「行程」に責任を持つ（あるいは助力する）ということになります。
「行程に対する助力」って何ぞや、というのは次回。
