「自分がやった方が早い」と思っていた頃がある
こんにちはあるいはこんばんは
前までは、よく思っていた
自分が見た方が早い
自分が直した方が安全
自分が説明した方が、お客様にも伝わりやすい
たぶん、今でも少し思っている。
PLやリーダーの立場になると、そう感じる場面は少なくない。
納期がある。
品質もある。
お客様に迷惑をかけるわけにはいかない。
だから、つい自分で巻き取りたくなる。
それは、単なる独りよがりではなく、責任感でもあると思う。
ただ最近は、それだけでは少し足りないのかもしれないと感じている。
1. たぶん、本当に早い
自分がやった方が早い。
これは、たぶん本当に早い。
経験がある
過去の失敗も知っている
お客様が気にするポイントも、なんとなく分かる
このまま進めると後で揉めそうだな、という匂いも少し分かる
レビューで資料を見ていると、つい思ってしまう。
ここはこうした方がいい
この説明だと伝わりにくい
この観点が抜けている
その前提だと、あとで手戻りになりそう
説明するより、自分で直した方が早い。
実際、目の前の仕事だけを考えるなら、その方が安全なこともある。
SEの仕事は、ただ作るだけではない。
影響範囲を見る
品質を見る
お客様の反応を読む
あとで揉めそうなところを先に潰す
説明責任を持つ
そこまで考えると、自分がやった方が早いと思うのは、ある意味では自然なことなのかもしれない。
でも、それを続けていると、少しずつ別の問題が起きる。
2. でも、判断が上に集まり続ける
PLが最後に直す
リーダーが最後に判断する
上の人が見えないところで整える
これが続くと、現場は一見うまく回っているように見える。
でも、実際には判断が上に集まっているだけかもしれない。
メンバーは作業はできる。
指示されたことも進められる。
言われた修正もできる。
けれど、判断の前提に触れる機会が少ないままになる。
なぜそこで止めるのか
なぜその説明では足りないのか
なぜその見積もりでは危ないのか
なぜその仕様変更を、そのまま受けると苦しくなるのか
なぜその進め方だと採算が崩れるのか
そういう部分を知らないまま、作業だけを進めることになる。
すると、次もまた聞くことになる。
これでいいですか
どうしたらいいですか
どこまでやればいいですか
そしてまた、上が巻き取る。
短期的には安全でも、長期的には少し危ない。
PLやリーダーがいないと進まない状態になってしまうからだ。
判断が、チームの中に分散していかない。
ここが一番こわいところだと思う。
3. 伸びない人、と決めつける前に
なかなか力を出しきれていないように見える人がいる。
周りも、どう関わればいいのか悩む。
本人も、たぶん悩んでいる。
正直に言えば、こちらも悩む。
どう任せればいいのか。
どこまで任せていいのか。
どこで手を入れるべきなのか。
でも、少しずつ変わってきている姿を見ると、単純に「できない人」と決めつけるのは違う気がする。
人は、能力だけで見えるわけではない。
仕事の渡し方
責任の範囲
説明の粒度
一緒に組む相手
戻ってこられる場所
その組み合わせで、人の見え方はかなり変わる。
細かい確認が得意な人もいる。
全体の流れを見る方が得意な人もいる。
最初から自由に任されると止まるけれど、前提が整理されていれば動ける人もいる。
逆に、細かく言われすぎると力が出ない人もいる。
その人が伸びないのではなく、まだ合う渡し方をこちらが見つけられていないだけかもしれない。
そう考えると、PLやリーダーの仕事は、人を変えることだけではないのだと思う。
人と仕事の組み合わせを見ること
人と人の組み合わせを見ること
任せる範囲と確認タイミングを見ること
責任と裁量の組み合わせを見ること
そこに目を向けるのも、PLやリーダーの仕事なのかもしれない。
4. QとDだけでは、プロジェクトは見えない
プロジェクトの現場では、どうしてもQとDに意識が寄りやすい。
QはQuality（クオリティ／品質）。
DはDelivery（デリバリー／納期）。
品質を守る
納期を守る
これはもちろん大事だ。
ただ、PLとしてプロジェクトを成功させるなら、Cも外せない。
CはCost（コスト／採算）。
どれだけ工数を使っているのか。
契約の前提と合っているのか。
このまま進めると利益は残るのか。
誰かが余分に巻き取っているコストは見えているのか。
現場にいると、品質と納期は見えやすい。
不具合が出れば分かる。
遅れれば分かる。
お客様から指摘があれば分かる。
でも、コストや採算は、意識しないと見えにくい。
追加作業なのに、誰もコストとして見ていない
仕様変更を、つい対応できますと言ってしまう
見積もりの前提が曖昧なまま進む
テスト観点の抜けを、最後にリーダーが拾っている
気づいたら、誰かが見えないところで吸収している。
Cは、単に数字を見ることではない。
誰がどこで無理を吸収しているのか。
その作業は契約の前提に入っているのか。
追加で発生した確認や手戻りが、見えないコストになっていないか。
そこまで見ないと、プロジェクトは成立しているように見えて、実は誰かの無理で持っているだけ、ということもある。
最近、中堅向けにプロジェクトの見方を話す機会があった。
そこで伝えたかったのは、細かい計算方法そのものだけではなかった。
プロジェクトを見る視点を、少し渡したかった。
品質だけを見るのではなく。
納期だけを見るのでもなく。
その仕事が、チームとして、会社として、ちゃんと成立しているのかを見る視点。
PLは、教育係だけではない。
品質を見る
納期を見る
採算を見る
お客様との約束を見る
その中で、どこまで任せるかを決める。
だから難しい。
人に任せたい。
でも、プロジェクトを失敗させるわけにはいかない。
この両方を見ながら任せるから、PLの仕事は難しいのだと思う。
5. 任せる側には、設計がいる
任せるというのは、丸投げではない。
ここでいう設計は、システム設計ではなく、任せ方の設計だ。
作業を渡すことと、判断を渡すことは違う。
作業だけなら、手順を伝えれば進むかもしれない。
でも判断まで渡すなら、前提も、制約も、戻ってくる条件も一緒に渡さないといけない。
何を任せるか
どこまで任せるか
何が起きたら戻ってきてもらうか
どの判断は自分でしてよくて、どの判断は相談してほしいのか
そこまで決めずに任せると、任された側も苦しい。
自由にやっていいと言われても、どこまで自由なのか分からない。
相談してと言われても、何を相談すればいいのか分からない。
結果として、動けなくなる。
あるいは、本人なりに進めたあとで、最後に大きく直される。
それは、任された側にとってもつらい。
だから、任せる側には設計がいる。
小さく任せる
途中で見る
戻ってこられる場所を作る
判断の理由を一緒に確認する
最初から全部を任せる必要はない。
でも、全部を巻き取り続けてもいけない。
その間にある渡し方を考えること。
そこに、PLやリーダーの仕事があるのだと思う。
6. PLやリーダーは、正解を出す人だと思っていた
昔は、リーダーは正解を持つ人だと思っていた。
迷ったときに答えを出す人。
問題が起きたときに判断する人。
お客様の前で説明できる人。
もちろん、それも必要だ。
最後に責任を持つ場面はある。
自分が出た方がいい場面もある。
止めるべきものを止める判断も必要だ。
でも最近は、それだけでは足りないと感じる。
少なくとも、PLの仕事は正解を持つことだけではない。
誰に何を任せるか
どこまで任せるか
どこで確認するか
誰と組ませるか
何を見れば判断できるようになるか
そういう組み合わせを整えることも必要になる。
人を無理に変えるのではなく、その人が少し動きやすくなる配置を考える。
任せっぱなしにするのではなく、判断できるだけの前提を渡す。
失敗しないように全部巻き取るのではなく、小さく試して戻ってこられる場所を作る。
それが、次の世代に仕事を渡すということなのかもしれない。
7. 「自分がやった方が早い」の先にあるもの
自分がやった方が早い。
その感覚は、たぶんこれからも消えない。
実際に早い場面もある。
自分が出た方が安全な場面もある。
最後は自分が責任を持つべき場面もある。
でも、いつもそれを選んでいると、判断がチームの中に広がっていかない。
PLやリーダーだけが経験を積み、メンバーは判断の手前で止まってしまう。
それでは、いつまでも次の人に渡せない。
PLやリーダーの仕事は、正解を持つことだけではない。
正解に近づける組み合わせを整えること。
任せ方を設計すること。
プロジェクト全体を、自分ごととして見られる人を少しずつ増やしていくこと。
最近は、そんなふうに考えている。
あなたの職場にも、
「この人にはまだ任せにくい」と思っている仕事はありませんか。
それは、その人の能力の問題なのか。
それとも、任せ方や組み合わせの問題なのか。
わたしもまだ、考えている途中です。
関連して、こんな記事も書いています
今回の記事は、PLとして「任せ方」をどう考えるかを書きました。
もう少し広く、中間管理職として世代や価値観の間に立つ感覚については、こちらで書いています。
プロジェクトを見るときの「コスト」や「効果」の難しさについては、こちらでも書いています。
