この記事はQiitaのアドベントカレンダー記事のリバイバル公開です。

はじめに

新人研修推進チームの永井です。

この記事はフューチャーAdvent Calendar 2022の9日目に書かれたQiitaアドベントカレンダーのリバイバル記事です。

このアドカレ記事を書いた2022年は、いままでの流通小売の事業部からHealthCare Innovation Group（HIG）へ転籍したり、初のチームリーダーを担ったりと6年目にして変化の多い1年でした。

いままではメンバーとして目の前のタスクやソースコードに集中していればよかったですし、それに甘んずる形でリーダーになることを避けてきたのが正直なところです。半数以上が自分より若いメンバーという中で、チームやプロジェクトをより良い状態にするにはどうしたらいいのか、を模索する1年でもありました。

本記事は、ベストプラクティス、というよりも自分自身の感想と振り返りを記録するものになります。

なお、記事内にちょこっとだけ経営学の専門用語っぽい言葉を使っていますが、その年に受けた中小企業診断士試験で得た知識をなんとか活かせないかなあと考えてたからになります。ちなみにこの年の試験で無事合格しました。やったね。

チームリーダーの役割と考え方

プロジェクトやチームの状況によって変わるかと思いますが、たいてい以下のタスクを求められるかと思います。

1. 計画立てと進捗管理
2. 成果物の品質管理（レビュー）
3. メンバーの育成
4. メンバーの評価（フィードバック）

これで全部というわけでなく、チーム内やチームリーダーより上のリーダーで分担したり、顧客対応など他の役割を担うこともあるかと思います。

また、タスク以外にも、メンバーの働きやすい環境を整えたり、チームをまとめ、凝集性を高めていったり、とタスク（＝Redmine等のチケットにならない）動きも求められるかと思います。ここではまとめてチームビルディングと呼びますが、むしろこちらの方が大切で、いろいろと模索しました。
また、1~4のタスクを行う上で、1on1やナレッジマネジメントを実施しました。

チームビルディング

1.メンバーとの良好な関係を築く：心理的安全性を高める

心理的安全性を高めるという言葉も最近よく聞きますが、メンバーとの良好な関係は、チーム運営の土台であると考えています。
もちろん単なる「仲良しこよし」というわけでなく、仕事を行う上での良好な関係であり、場合によっては耳がいたいことも互いに言うことができる関係性を目指していました。

「ホウレンソウ」がないのはリーダーのせいかもしれない

よく世の中には、「部下の報告が遅い」という愚痴などを見聞きします。「メンバーはネガティブニュースを早く上長にエスカレーションすべし」はメンバーのあり方としては正しいのですが、リーダーとしては報告が遅いと愚痴っているだけでは何も解決しないのではないでしょうか。いわゆるホウレンソウが来ない原因を取り除く必要があると考えています。

気軽に相談できるような関係性を築ける取り組みとしては、まず、アサインやフェーズの初めのうちは相談枠を設けたり、こちらから声をかけたりしていました。

また、相談には時間の許す限り、一緒に解決方法を考える（なるべく突き離さない、自分じゃどうしようもならないときは、別の有識者に頼ることもあり）ことも意識してました。逆に、進捗が悪い、コーディングがうまくいかないと言ったネガティブなことをエスカレーションしたとしても、怒られたりするだけで、何にも解決にならないのであれば、進んでエスカレーションしようとはならないよなあとも思っており、しっかりとメリットを与えることを意識していました。

私に相談すればメリットがあるということを「信じてもらえる」ようになって、対面（Web会議含む）だけでなく、チャット(Slack)上でもコミュニケーションが進み始めたかなという印象です。

2.プロジェクト成功へ向けてのモチベーション・パッションを高める：凝集性を高める

モチベーションコントロールは自責なのか

自分のモチベーションをコントロールするのがプロとしてあたりまえ、仮にモチベーションが低くても、成果に影響を与えないのがプロだという考え方もあります。１プレイヤーとしてその考え方はめちゃくちゃかっこいいのですが、チームリーダーという立場であれば、メンバーのモチベーションを把握し、なるべく高めていく働きかけを行なった方がよいのではないかなと考えていました。

メンバーを突き放したところでそのメンバーのモチベーションが上がらないよなというのが大きな理由です。

私に「仮にモチベーションが低くても、成果に影響を与えないのがプロだ」という考え方を伝えてくれたリーダーも、決して放置することなく、対話などを通じてモチベーションを保つ働きをしてくれていました。

目標を共有する・身近にする

モチベーション、もうちょっと熱を帯びた言い方をすればパッション（熱意・情熱）を高めていくには、共通の目標を共有し、それに向かって頑張ろうと鼓舞していくことが有効かと思います。

プロジェクトの（目の前の）目標というと、システム開発では問題なくリリースすることになるかと思いますが、メンバーのプロジェクト参画時にはその背景や大義などが共有されるかと思います。定期的にその背景や大義を振り返ってみるのも良いかと思います。

また、1 on 1を通じて、プロジェクトの成功とメンバーのタスク、そしてメンバー個人の成長目標達成が結びつけられるように話すこともありました。

1 on 1

1 on 1については、Future tech blogの真野さんの記事を参考に実施していました。

特に記事内の「1 on 1を開催する意図」に賛同していて、そのままGoogleカレンダーの1 on 1の予定の説明欄に引用していたりしますw

1 on 1 を開催する意図とは？
こまめなフィードバックをしたい
半期ごとの評価時に行うフィードバックをもっと刻みたい
「あの時、実はこうして欲しかった」みたいに伝える人もいるけど、「その時に言ってよ」と過去の自分が思ったのも影響している
私のビュー（視点）からはこういうふうに見えていると伝えたい
良くも悪くも事実だと思うので、やったことが伝わってない場合は見せ方を変えるなどに活かしてほしい。活かしたくないなら無視して欲しい
アドバイスをできる範囲で。一方で自分過去の武勇伝を語っても仕方ないので、なるべく自分で考える切っ掛けを与えようと思う
振り返りの場としても活用して欲しい
キャリア志向にそったタスクアサインにも活かしたい
もちろん、不満や業務上の聞きにくい質問もOK。それで時間が潰れたら別途枠を用意する

私自身、半期や1年ごとの評価の場で、初めて評価・フィードバックを下されるガラガラポン状態に違和感がありましたし、フィードバックする側として半年前のことまで覚えている自信もなく、こまめにフィードバックしたいと思っていたので、チーム内で開始しました。

真野さん記事の…

私のビュー（視点）からはこういうふうに見えていると伝えたい
良くも悪くも事実だと思うので、やったことが伝わってない場合は見せ方を変えるなどに活かしてほしい。活かしたくないなら無視して欲しい

…にあたりますが、（特にネガティブな）フィードバックについては、「理解」してもらうことを意識しています。理解してもらうために事実とどう見えていたかを丁寧に説明するように心がけました。なお「納得」してもらうことまでは求めてません。¹絶対に従ってくれと思っているわけではなく、フィードバックを受けて自分自身で考えて行動してほしいからです。

開催頻度としては隔週を標準にして、アサイン当初やフォローが必要かなと思ったときは週１回に頻度を増やして実施していました。

ナレッジマネジメント

ナレッジマネジメントは主に育成面に関わります。

ナレッジマネジメントというと、俗人化している暗黙知をwikiとかに書いて形式知にしてみんなが使えるようにしよう（＝表出化）というイメージが強いと思いますが、SECIモデルが提唱しているように、暗黙知を暗黙知として移転するというプロセス（共同化）もあります。

▼SECI（セキ）モデルとは？具体例をもとにわかりやすく解説｜ITトレンド より

ペアプロなんかはまさに良い例で、上級者はこんなショートカットキー使ってる、に始まり、このメソッド使うと冗長にならずシンプルに書けるのかとか、エラーがでたときに、エラー文のどの部分に着目して、どういった検索ワードで調べて、どのあたりの情報に着目して解決していくか、といったことを横で学べます。

この例でわかるように、すべての暗黙知が形式知できる（しやすい）といったわけでもないです。ショートカットキーやメソッドは文章化しやすいですが、上級者のエラーの対処のコツを言葉にしていくのはなかなか難しいです。そのため、共同化プロセスも結構有効だったりします。

上記のようなコツだったりを共有する目的で、チーム内でもペアプロや、対面でのレビューを実施していました。
もちろん暗黙知を形式知化する表出化も大切で、「そのノウハウはぜひwikiに書こう」という呼びかけもしていました。

リーダーをやってよかったかもしれない。あと未来の話

プロジェクトが無事終わったとき、システムのリリースそのものよりも、メンバーの成長への嬉しさだったり、このチームでやり遂げたぞといったところのほうが自分自身の中の達成感として大きく残りました。過去一番小規模なプロジェクトにも関わらず、一番の達成感がありました。

学生時代に就職活動をするなかで、当社への入社の決め手となったのが働いている「人」だったので、人に関心があって人で達成感を感じるのも自分らしいなとは思います。

「リーダーの作法 ささいなことをていねいに」、という本があります。自分にはできてなかったなと反省することも多く、表紙のハチに刺されたような痛みを感じますが、次回に生かしていきたいです。

今振り返ってみて（新人研修の立場から）

ここまで当時の記事をなるべくそのまま記載してきました。

現在の立場から、何点か補足したいと思います。

今の立場からの補足

「メンバーはネガティブニュースを早く上長にエスカレーションすべし」はメンバーのあり方としては正しいのですが、リーダーとしては報告が遅いと愚痴っているだけでは何も解決しないのではないでしょうか。

自分のモチベーションをコントロールするのがプロとしてあたりまえ、仮にモチベーションが低くても、成果に影響を与えないのがプロだという考え方もあります。１プレイヤーとしてその考え方はめちゃくちゃかっこいいのですが、チームリーダーという立場であれば、メンバーのモチベーションを把握し、なるべく高めていく働きかけを行なった方がよいのではないかなと考えていました。

現在新人研修を運営・推進する立場になっているので、新人に対しては正しいメンバーのあり方を伝えるのが重要だったりします。「ホウレンソウが遅いです」と私は何回も言っていますし、言わなくてはいけなかったりします。

「モチベーションが低いです」と言われれば、DeNA創業者の南場智子さんのように「給料をもらって仕事をしている自覚はないのか²」と言わなくてはならないのです。（いまのところそのシチュエーションになってませんが。）

これには、チームで顧客に対して成果をだすことが第一である現場のチームリーダーと、新人の成長こそが成果となる新人研修担当の違いや、そもそもメンバーとして正しいあり方を知っている現場のメンバーと知らない新人という相手がそもそも異なるという点があります。

（特にネガティブな）フィードバックについては、「理解」してもらうことを意識しています。理解してもらうために事実とどう見えていたかを丁寧に説明するように心がけました。なお「納得」してもらうことまでは求めてません。
絶対に従ってくれと思っているわけではなく、フィードバックを受けて自分自身で考えて行動してほしいからです。

新人研修では、「どう見えているか」はだいぶ意識して伝えているところではあります。この辺りは未来報で記事になっていますので是非お読みください。

最後に

プロジェクトが無事終わったとき、システムのリリースそのものよりも、メンバーの成長への嬉しさだったり、このチームでやり遂げたぞといったところのほうが自分自身の中の達成感として大きく残りました。過去一番小規模なプロジェクトにも関わらず、一番の達成感がありました。
学生時代に就職活動をするなかで、当社への入社の決め手となったのが働いている「人」だったので、人に関心があって人で達成感を感じるのも自分らしいなとは思います。

これは今も変わらず思っていることですし、この時の体験がある種の縁で現在新人研修を担当するに至っています。

未来報にもあるように、今後研修が終われば現場へと私も戻るのですが、再度チームリーダーになったり、より上位のリーダーの役割を求められることもあるかもしれません。

この記事が未来の自分も含めた、チームリーダーを任された方に役立てば幸いです。