最近、業界未経験で中途入社してきた新人さんの面倒を見ています。仮にAさんとします。
その人が置かれた境遇から、いろいろ思うところ、学ぶところがあったので、まとめてみます。
プロジェクト概要
Webアプリケーションの改修を行うプロジェクトです。
私は別のプロジェクトをやっているので、技術的な相談等が主です。生活面も何かあれば相談してね、とは言っています。
近くの席でやっているので、状況は把握できる状態です。
新人さんとは別に、一年ぐらい一緒にやってきた若手も、新人さんと同じプロジェクトに異動になりました。そちらも未経験の言語、システムということで、技術的な相談に乗るようにしています。こちらはBさんとします。
プロジェクトには、あと一人ほぼ専属でやっている１年目社員がいるだけです。この人はCさんとします。なぜかタスク管理を一手に行っています。
こんな感じです。
| 人 | 状態 | 役割 |
|---|---|---|
| Aさん | 新人 | プログラマー |
| Bさん | 2年目 | プログラマー |
| Cさん | 1年目 | タスク管理（プログラマー）、質問を一手に受ける |
うん、プロジェクト体制がおかしいですね。人がいないのかな？何が足りないか考えてみましょう。
起こったこと
さて、二人が入ったプロジェクトには、当然PMがいます。
配属になったBさんに出した指示は、
できる限りチーム内で疑問は解決してね
というものでした。
そこまでは、まだ良いです。
ただし、AさんとBさんに対する教育、すなわちソリューション構成や使っている技術の伝達もCさんに任されました。
Cさんはまだ１年目なので、技術はギリギリ扱えるものの、説明できるほどではないです。設計なんて全くできません。
Cさんからしたら、そもそも何を説明したら仕事がスムーズに進むのか、どうやってタスクを振るのか*1については全く知識がないので、やりようがありません。
そして、Cさんは、最初にAさんに振るタスクを決めました。
私がAさんから質問を受けた時に、やるべきことの全体を聞いたのですが、未経験の人間に振るレベルではないもの*2でした。
さすがに見かねて、「このタスク振りは無いわ」とは伝えました。そこまでCさんに振るなと。
そしてBさん。
AさんもBさんもそのプロジェクトで使う言語は初体験でほぼ扱えませんし、これまで大してコーディングしてこなかった*3ので、仕事はなかなか進みません。
それに、チームで頼れるのは１年目社員しかいないという状況。どう考えても失敗はします。
そしてBさんは案の定失敗していました。当然です。
そこでPMがとった行動が…
周りが見ている前で叱るというものでした。叱るというか、説教です。
それでできると思ってるの？
みたいなことを言っていました。
まあ、一度ぐらいなら許容範囲かな、と私は思っていましたが、二週間近くほぼ毎日怒られていました。
結果
Aさんと、Bさんの行動には変化が起きました。本人に聞いたものもありますが。
Aさん
怯えていました。
もし仕事できなかったら、Bさんみたいに怒られるんだ
って言いながら、でも仕事ができない*4という状況に押しつぶされそうになっていました。
結果どうなったか。
自分から質問してこないという状況に陥りました。
PMが質問を禁止、というか、チーム内で解決しろみたいな指示を出したせいで、ほかのメンバーに迷惑がかかるからと、分からないところで一人で悩み続けていました。
質問しづらい雰囲気、みたいなものがチームに作られてしまっていました。
そして質問したら、「なんで早く質問しないの」みたいなこと言われたりと…。
PMが来て、「質問していいんだよ？」と言っていましたが、質問しづらい雰囲気作った本人が何言ってるんだろう、という感じです。
あと、最初の仕事が前述のように無茶振りだったので、
これが当たり前にわからないといけないんだ
という絶望を味わったみたいです。
Bさん
これは本人が言っていたことです。
PMから怒られるけど、一切聞かないことにして、言われたこと全部肯定して適当に相槌打ってます
とのこと。能力不足ですと認めないと、いつまでも同じことで怒られるそうです。
結果、PMを信頼しなくなりました。そして、
あんな風（PM見たいな人）には絶対なりたくない
と言っていました。
それとは別に、Bさんは自分でかなり勉強するようになったようです。
私が、「相手よりできるようになれば、こちらのわがままを通しやすくなる」というようなことを言ったからのような気がします。
あとは、仕事のやり方も多少変わり、できる限り先手を打って確認を取るようになりました。後から責められるのを阻止するために動いています。賢い。
Cさん
一応、管理者的な役割なので、タスク管理のやり方は教えました。
また、Bさんにはタスク管理や進捗管理に関してはかなり教えていたので、分からないことはそちらに聞くといいよ、と伝えました。
まあ、その目論見はPMが潰してきましたが。Bさんのプロジェクト貢献実感させるチャンスが一つ減りました。
Cさんはプロジェクトでの作業には慣れているので、さほどサポートを必要とせず、たまに資料の手直しのアドバイスをする程度でした。
私にできなかったこと、できたこと
正直、PMと正面切って戦えませんでした。ただ、戦うと私が会社にいられなくなるので、どうにもできなかったのは本当に申し訳ないです。
そこで、そのプロジェクトメンバーへの支援は、かなり行うことにしました。
- 必要な本は貸す
- 勉強方法を教える
- 何度か見て手が止まっていたら、声をかける
- 質問は、相手がわかるまで親身に聞く（時間はいくらかかってもよい。分かるまでやる）
- ソースを見てほしいと言われたら、きちんと見る
- 資料（ドキュメント）の見た目がいまいちだったら、こう書いたらわかりやすいかもよ、と教える
ということはやりました。
質問への回答は、相手が理解できるぎりぎりのラインで伝えて、あとはできるよね、という感じでやるようにしていました。
できる限り、やりたいことを聞き出した上で質問に答え、「やりたいことできました！」みたいな感じを出せるように。それで少しでも楽しいと思ってもらえたらいいなと思っていました。
Aさんに対しては、そもそも業務が新人に要求する内容ではない、と伝え、何度も励ましています。
間違いなく、着手当時より成長しているので、問題ないよ、というようにしています。
思ったこと
知識がない人への無茶振りは、例えるなら、赤ちゃんをいきなり外に放り出すようなものです。
しかも、別に生育環境はあるのに、意味もなく放り出して、生き残れるか試しているような感じ、まるで人体実験です。
知識の不足を意識させるのは悪いことではないですが、何も放り出さなくてもよいわけで、少し難しいぐらいの仕事を振ればよいと思います。
あと、PMの仕事は、進捗を聞きまわることではないと、はっきり理解しました。
プロジェクトの状況に目を配り、
プロジェクトメンバーが、安心してプロジェクトを推進できる土壌を作ること。それが大事だと感じました。
みんなで質問しあったり、一緒に考えたり、必要に応じて外部の知識を入れる。そうやってメンバーとプロダクトが成長できるようなプロジェクトが理想だと思います。
学び
メンバーが安心できる環境づくりは、PMの仕事です。むろんメンバーの協力は必要ですが、やはりPMがやるべきです。
そして、プレッシャーを与えるのは、ほとんど意味がないと思うようになりました。
トム・デマルコの『ゆとりの法則』には、
人間は時間的なプレッシャーをいくらかけられても、速くは考えられない
とあるように、プレッシャーをかけられてもその人の能力が劇的に向上するわけがないので、無意味です。
それだったら、プレッシャーがないほうが精神的に良いので、結果プレッシャーは無意味です。
プロジェクト全体にかかるプレッシャー（納期とか）は、仕方ないと思いますが…個人にプレッシャーをかける意味はない、と理解しました。
このところちょうど、『エンジニアリング組織論への招待』を読んでいます。このプロジェクトの惨状を見るちょっと前に読み始めています。
今回のプロジェクトで新人さんを支えるような行動を取り、それで実際に仕事が進んでいる様子を見ており、学びと実践を同時にやれている気分です。
もっとも、私はPMでもなんでもなく、ただの先輩として支援しています。だから実際に適用するのはこれからになりますが、自分の血肉として学びたいと思っています。
何より、メンバー全員、仕事*5を嫌いになってほしくない、と思っています。
今後もできることはやる所存です。
おわりに
最近、リーダーシップについて学びました。そこでは、
リーダーシップは、まずは個人と個人の向き合いから 相手の特性に応じた接し方が必要になる
ということを教えてもらいました。
チームの体制をどうするか、という部分はPMが決めます。それはあくまで「そういう役割」であると思うようになりました。たまたまPMという役割だと。
リーダーシップとは、それとは本質的に違うものです。PM = リーダーではない。
この部分は、いまだ言葉にするのは難しいです。でも、今回のことで何かつかめそうな気がしています。
以前、当ブログでも「心理的安全性」に言及しました。本当に大事なんだ、と痛感した今日この頃です。
