妄想妄言の類い。工程の区切りで正気度チェック！という話ではなく。InfoQで「ロールプレイングゲームのダンジョンマスタとして学んだことをアジャイルコーチングに活用する」という記事を読んで考えたことなど。ちなみに「TRPGのGM」は、「テーブルトークロールプレイグゲームのゲームマスター」のこと。
ゲームマスター/ダンジョンマスターの役割
TRPGのGMの役割は、わたしの理解ではざっとこんな理解である。
- 物語りの背景と舞台、大まかなシナリオを用意する
- メンバーの振る舞いに応じて少しずつシナリオを進めて、メンバーと一緒に物語を作り出す
- メンバーの行動を指示することは出来ないが、舞台設定である程度行動の方向性に影響を与えることはできる
「轟音とともに洞窟の入り口は崩れた岩によって塞がれてしまった。どうやら後戻りはできないようだ」
この「メンバーの行動を指示することは出来ないが、舞台設定である程度行動の方向性に影響を与えることはできる」という点が、ソフトウェア開発のPMの観点で興味深いと思っている。
メンバーの引っ張り方
ソフトウェア開発という一連の複雑な作業について、「全ての作業を全てのメンバーに指示しながら行う」ようなマイクロマネジメントは実際のところ現実的ではない。
指揮統制という形態のマネジメントは軍隊におけるマネジメントを元にしている。その基本的なアイデアは、人々はあなたの言ったとおりに行動し、そうしないときはするまで怒鳴りつけ、それでもやらない場合はしばらく営倉に放り込み、それでも変わらないようなら潜水艦でのタマネギ剥きの任務を言い渡し、2立方フィートの空間の中で農場から連れてきた歯を磨いたことのない若造と一緒に働かせるのだ。
More Joel on Software 第5章 指揮統制マネジメント法、より
指揮統制のもっと実際的な欠陥は、マネジメント側にはそういうレベルでマイクロマネジメントできるだけの時間がないということで、それはマネージャの数が単に足らないためだ。軍隊で指揮統制が可能なのは、大勢のチームに対して一度に命令することができるからで、これは通常みんなのやることが同じことによる。「銃の手入れをしろ！」と28人の部隊に言っておいて、その間将校クラブに行ってベランダで冷えたアイスティーを飲んで軽く居眠りすることができるのだ。
More Joel on Software 第5章 指揮統制マネジメント法、より
というわけで、大人数でソフトウェアを作る為には、マイクロマネジメント以外の方法を編み出してメンバーを引っ張る必要がある。
一時期は作業のマニュアル化(標準化)を徹底して行い、作業計画とマニュアルをメンバーに投げつけて放置する方法が流行したけれども、技術そのものがマニュアル化に追いつかない勢いで進歩したり複雑化してしまったのでうまくいっていない。
最近の流行は多分「ゴール一体化法」で、開発するソフトウェアのゴールや背景をメンバーに叩き込んで、達成の方法はチームやメンバーの裁量の範囲で実施するというものだ。昨今の技術進歩により、さまざまなツールやフレームワークが少なくとも動くソフトウェアを作ることは保証してくれるから出来るようになったとも言える。
「このチームの目標を言ってみろ！」
「・・・」
「声が小さい！もう一度」
「建設安全作業許可証発行システムをつくることです」
「それは、ソフトウェアの名前でありチームの目標ではない！腕立て100回！よし次！」
「建設現場での作業を安全に追跡監視することです！」
「そうだ！それが目標であり、われわれがここにいる理由だ！それでは全員作業にかかれ！」
もちろんこれでうまく行く場合もあると思うのだけれども、「ゴール一体化法」は少し乱暴に感じる時もある。例えば一部のメンバーがゴールに興味を持てなかったり、共感できなかったら困ったことになってしまう(例えば、ソフトウェア技術や自分のスキル向上にしか興味が無いメンバーなど)。そういうメンバーは除去してしまうというのも一つの手だとは思うけれども。
シナリオでメンバーを動かす
個人的には「ゴール一体化法」のマネジメントではなく、もう少しヒネった形でのマネジメントのほうが好ましい。
- 各人の裁量は大きくとる
- 舞台を整えて、各人が大きな誤りを起こしにくくする
- 最終的にはゴールを目指すけれども、細かいシナリオに区切ってメンバーを誘導する
- 道を外れたメンバーについては、細かくサポートを行う
