プロジェクトが窮地に陥ると溜っていた不満が噴出していきます。
- 炎上する現場
- 雰囲気の悪いプロジェクト
- やる気がないメンバー
- Aさんが気に食わない
- etc…
それを未然に解決できればいいのですが、現実として全てを防げる事は中々難しい事です。
アジャイルでやっても炎上する時は炎上します。
そこで上記のような炎上し始めた場合にやるマネジメント方法として下記の事を実践したら大体のプロジェクトで上手くいったのでメモ
前提
- 主にエンジニアを取りまとめるマネージャー、リーダーを対象として話しています。
- プロジェクトあたり5人以上の人が存在するプロジェクト
- それ以下の人数の場合は多分純粋なリソース不足に陥ってるケースが多いので該当しません。
ゴールイメージ
- メンバーがタスクを行うにあたり完了までのスピードをあげる事(タスク処理の効率化)
- メンバーが自立的に課題を取り組めるような環境を提供すること
ドラゴンボールマネジメントとは？
メンバーに対してどんな願いも1つだけ叶える
上記をメンバーに対して実践する事になります。
なぜ願いを叶えるのか？
メンバーとの信頼関係を構築する為に必要だからです。
炎上しているプロジェクトの場合は大体何かしらの不満、物理的に厳しい要求等が少しづつ重なり炎上に発展していきます。
小さな炎(不満、要求)が少しづつ重なり燃え広がる = 炎上
ですから。
なぜ信頼関係を構築しなくてはいけないのか？
当然の事ながら信頼関係を構築しないと、要求に対して実行までのプロセスが長くなるからです。
v = false
while v == true do |v|
if "Aさん「Bさん、このタスクちょっとお願いしてもいいですか？」"
if " Bさん「えー、だってCさんがアレでコレだから嫌ですよ」"
elif "「でもさー、アレがコレでどうしても今お願いできるのはBさんしかいなくて。。。」"
if "Bさん「えー、でもさーーー」"
.
.
.
end
end
end
end
プログラムで表しただけでももうカオスなコードですよね。
信頼関係を構築できると大体の人はこんな形な大分すっきりしたコードで表せると思います。
yokyu = "タスク"
v = ""
res = false
case v
when "「Bさん、この#{yokyu}ちょっとお願いしてもいいですか？」"
say = "Aさんが言うなら。。。。いいですよ"
if /いいですよ/ =~ say
res = true
end
when "「Cさん、この#{yokyu}ちょっとお願いしてもいいですか？」"
say = "Aさんが言うなら。。。。いいですよ"
if /いいですよ/ =~ say
res = true
end
when "「Dさん、この#{yokyu}ちょっとお願いしてもいいですか？」"
say = "Aさんが言うなら。。。。いいですよ"
if /いいですよ/ =~ say
res = true
end
end
大分コードが綺麗になりました。
マネジメントに専念する為に自分がタスクに手を出しては行けない
炎上中の場合、崩れるのはまず指揮系統が破綻している場合が多いです。
なのでこの時にタスクを自分でタスクを抱えてしまうと、燃え広がり方を監視できなくなるのでなるたけ手をだすのは止めましょう。(もしくは本当にすぐに完了できるタスクのみ)
願いの内容のヒアリングについて
炎上中の場合は願いの要求のハードルがすごく高くなっています。(不満が爆発しているので)
なので願いのハードルを下げるようにしましょう
1.個室又はプロジェクトから離れたスペースに連れ出す
個室に連れ出すのは有効な手段です。
個室やプロジェクトから離れたスペースに連れ出さないと本音をほとんど聞き出す事はできません。
特に「人間関係のこじれ」は聞き出せません。
複数人でプロジェクトを進めていると人対人なので必ずこじれは発生しています。
なので少し面倒でも一人づつ個室に誘致しましょう。
2.何が困っているか？を聞き出す
最初の冒頭は大体下記の一言を言っています。
「私はあなたの味方(仲間)です。
あなたが困っているように感じているのであなたを助けたい。
でも、私はあなたではないのであなたの困ってる事を全て把握はできていません。
なので困っている事を教えて欲しい」
これでも本音が出てきていないと感じたら
「例えば、Aさんが気に食わないとかでもいいですよ」
とか言ってます。
炎上している場合は、当然ながら敵(プロジェクトの進行を阻害する人)もプロジェクトに来ます。まずは味方だとアピールすることは非常に重要です。
困ってる事は非常に重要でそこに必ずヒントが隠されています。
そのヒントを取得する為に本音を聞き出しましょう。
困ってる内容を話しはじめてくれたら、次のポイントを念頭に置きながらヒアリングを進めていきます。
願いの落としどころをどこでつけるか?
ドラゴンボールマネジメントと言いながら、当然どんな願いでも叶えれる訳ではありません。
でも、願いは叶えないと信頼関係は築けません。
3.どういうプロセスで願いを叶えるかを提示する
「よしわかった。叶えよう！！」とすぐに叶えられるものはほとんどないはずです。
ましては内容を聞いて長期的な改善、プロセスが必要なものもあります。なので
- まずはコレをする
- コレをした後アレをする
- そしてアレの結果を見て次にソレをする
と困ってる人に対してプランニングを提示しましょう。
コレで大体の人は納得してくれるはずです。
これで信頼関係の第一歩が取れました。
そして次からタスクをお願いする時に
「この前言った通りにまずはコレをする為にはこのタスクを消化する必要があります。申し訳ありませんがお願いできますか？」
とお願いします。
「おまえの願いを叶えるためにドラゴンボールを集めるタスクを課す」
ということです。
複数の願いが存在する場合
そこは一点だけにしましょう。
シェンロンだって１つの願いでやっとなのですから
ポルンガになると自分が潰れますし、一つの願いを叶えることによって、その他の願いは自然に解消する事もあります。まずは一番叶えたい願いを叶える努力をしましょう。
困っている事をメンバー全員にヒアリングできたら
メンバー達の困ってる事を見比べましょう。
これは一点だけからの意見だけだと偏りが発生しますので、3人以上が似た意見を言っている場合はその困ってる事がボトルネックになってると仮定してその困ってる事を解消するように動きましょう。
またメンバー達に提示したプロセスの修正が必要な場合はプロセスの修正を各メンバーに伝えましょう。
ここまでのプロセスが完了したら
- 叶えられそうな願いから順にタスクを消化しましょう。
- メンバーの前にたち障壁となっているものがある場合は率先してその壁を壊す、どかす努力を行いましょう。(これはアジャイルサムライにも書いてあった）
- エンジニアが集中してコードをかける環境を用意できるようにしましょう。
- エンジニア以外のセクションとも積極的に話を聞きにいきましょう(アジャイルサムライのお隣さんが探せ)。
これを少しの期間(感覚値として２週間程度)実行するだけで大分信頼関係が構築できています
- 信頼関係が構築できると手元に情報が集まってきます。
- 情報が集まれば更にマネジメントは行いやすくなります。
- 情報を上手く活用する事により炎上から鎮火までする経路を作成することができます。
よって上で説明したロジックが構築できるようになります。
task = "タスク"
you = "A"
member = ["B","C","D"]
task_do = false
def お願い(you, member = [], task)
member.each do |v|
puts "#{v}さん、この#{task}ちょっとお願いしてもいいですか？」"
say = "#{you}さんが言うなら。。。。いいですよ"
return true if /いいですよ/ =~ say
return false
end
end
task_do = true if お願い(you, member, task)
大分コードもスッキリしてきましたね。
集約された情報を元に決断者に現実と未来プロセスをエスコートする
決断者とはプロジェクトの進退を決めれる人に現実をまとめて報告しましょう。
ここでポイントは現状の問題点を報告してそれが、色々な事が絡んでこうなっている現実を素直に報告することです。
炎上している時は物理的な現実と理想な現実とはかけ離れている状態ですので
- 炎上している現実を知ってもらう事(気付いていない場合もあるので)
- 情報を元になぜ炎上したかのタイムラインを作成する = 説明責任を果たす
- 炎上鎮火プロセスを提案する
- 集約された情報に大体答えがあるので情報をよく見る = ボトルネックの抽出
- 次回は同じ過ちを繰り返さないように次回のプロセスを提案する
- 提案内容はメンバーの願いを叶えるような内容にしてプロジェクトが円滑に進めるようにする = 未来プロセスのエスコート
上記を実行します。
上記を実行して決断者が渋った場合は更に決断者に困っている事をヒアリングを行い、メンバーの困りごとと決断者の困り事の間で
願いの落としどころ
を計ります。
すぐに鎮火できていないじゃん！！
燃えた火は大体の場合はすぐに鎮火できませんので火を消す事に目をむけるのではなく更に火が出ないようにします。
火の延焼を防ぐように障害を破壊消防しましょう。
終わりに
やっている人はやっているし、別の手法で実践して成功している方も沢山いらっしゃります。
ただマネジメントってプログラムと違い、こうやれば、こうできる！！って答えがない無形な形なものです。
参考程度に見てもらえればと思います。