はじめに

アドベンドカレンダーでは本来、Techなお話しをするところですが、
偶には違う角度のものをということで、今回は私がチームリーダー1年目で色々感じたこと、学んだことをつらつら書ければと思ってます。
リーダー(マネジメント)歴/プロジェクトの経験が長い方からしたら、何言ってるんだという所があるかもしれませんが、
もしかしたら、同じ境遇の方、来年ないしは4月からなりますという方がいるかもしれないので、そういった方々に読んでもらえたらと思います。

突然任された役割

重ねますが、私は今いるプロジェクトで開発チームのチームリーダーを担っています。
約1年ちょっと前から突然担当することになりました。所謂、新米リーダーです。
タスクやスケジュールの管理,要員関連の作業からプロジェクトの詳細設計書やソースのレビュー,時には自分でも手を動かすので、
プレイイングリーダーと言った方が良いでしょうか。

タイミングは、何気なく日々開発チームの一員として業務をこなしてた時です。
要員が少ない時期で私ともう一人Aさんがいたのですが、その方は現場この道10年のベテランです。
ですが、Aさんは私が参画する前から「管理やります」と言っていたようなのですが、進捗表やタスク管理もできなかったので、私が代わりに対応することに。
少しずつ要員も増えてきた中、Aさん突然の離任。
「いやぁ、まだドメイン知識もまだまだだし、アーキテクチャとかも理解しきれてないのに....」なんて思いつつ、この離任をきっかけにチームリーダーとしての旅が始まりました。

４つの反省と学び

最近、自分の現状と比較できて勉強になった本があります。

アマゾンのリンク
リーダーの仮面 という本です。
この本は、私のようなリーダーになりたての人をメインターゲットに書かれている本で、
「識学」という意識構造改革で、ざっくりに言うと、作業指示から目標設定などなど様々な観点からリーダーに必要な考え方やメソッドが書かれています。

今思うと、明らかに自分の指示の仕方が悪いのですが、
リーダーなりたての頃によく行っていたこととして、

 ①作業指示は基本チャットに記載
 ②なるべく対等な立場で目線をフラットにする
 ③指摘する時はとにかく優しく
 ④作業を振る時に「お願いをする」

があります。

参画メンバーがほぼ全員若手なことも影響し、彼らには何も力になっていませんし、成長しません。

①作業指示は基本チャットに記載

ログとして作業指示が残るというメリットはありますが、デメリットだらけです。

・作業の意図が理解されているのか分からない
・そもそも作業指示が通っている(読まれている)のか分からない
・チャットが流れて、気付いてない

まぁ、当たり前ですよね。
基本オンサイトで業務を行っているのに、何してるんだと振り返ると思います。

【アクション】

言わずもがなですが、まずチャットで概要を送ります。
チャットで概要を送るとは基本的には以下です。

・作業指示の概要(作業の内容、ゴール、期限)
・関連する資料が格納されているリンク

これらを基に、不明点や詳細に詰めるところは対面で会話しています。
※これに関しては、リーダーだからじゃないです。何となく見てみて自分だと思った方は直しましょう。

②なるべく対等な立場で目線をフラットにする　③指摘する時はとにかく優しく

本書にもリーダー1年目の人はプレイヤーの心が残っているため、プレイヤー目線で物事を考えてしまうと書かれています。
思いっきりこれに合致していました。
「これ大変だよねぇ〜」　「今そんな感じだから、後これくらいかかるかな？」のような感じです。
同情や提案型の質問で伺い、相手の一時的な心理的安全を認識するようなやり方です。

【アクション】

現代社会の表現として正しいかはさておき、「上司と部下」の関係性を少しずつ意識するようになりました。
上から目線で接するのではなく、作業を振る人、こなす人という区別を意識して同情や提案型で行うのではなく、
「〇〇をいついつまでに実施してください」などと指示する意識を持つようにしています。

④作業を振る時に「お願いをする」

今もなお、気をつけてても行ってしまうことの一つです。
「来週までに設計書のここの修正お願いできるかな...？」や「ちょっとこの作業、今やっている作業の合間で良いからできたりする？」などの指示がこれに該当します。

【アクション】

本書にも記載されているのですが、「言い切る」ように変えました。
上記で改めると....
「来週の⚪︎曜日までに、この設計書の指摘をもらってる箇所の修正をお願いします」
「この作業を今やっている作業の合間で完了できるので⚪︎曜日までにお願いします」
と言ったように提案型から提示型にすることです。

最後に

最後に本書の中で今の自分に刺さる５つのポイントがありました。

①「いい人」になろうとしていないか？
②「待つ」ことを我慢できるか？
③「部下と競争」していないか？
④ 「マネジメントを優先」しているか？
⑤「辞めないかどうか」を気にしすぎていないか？

エンジニアチーム観点からすると、

①「いい人」になろうとしていないか？
　→ 部下(若手)に対して、言語やツールを手取り足取り教えているか？

②「待つ」ことを我慢できるか？
　→ 新規参画者の半年〜１年経ってドメイン知識や仕様がつくことを我慢できるか？
　　(半年〜１年は大雑把な例です)
  
③「部下と競争」していないか？
　→ 言語やシステム知識をプレイヤー目線で意識していないか？

④ 「マネジメントを優先」しているか？
　→ 作業者に任せるべきタスクを自身で行っていないか？
 
⑤「辞めないかどうか」を気にしすぎていないか？
　→ 部下の成長(コーディング技術やその他知識)のスピード感や心理的安全性を意識していないか？

リーダーなりたての私は全てに該当していました。
私はこれらの観点を本書を基に改善している途中です。
特に①,④はリーダーなりたての人は陥りやすいのかなと経験して感じました。

土台となる考え方を知れたので、更に自分の考え方もブレンドして、より良いリーダーを目指していきます。
もちろん、技術的成長は怠ることなかれで継続していきます。

はじめに

突然任された役割

４つの反省と学び

①作業指示は基本チャットに記載

【アクション】

②なるべく対等な立場で目線をフラットにする ③指摘する時はとにかく優しく

【アクション】

④作業を振る時に「お願いをする」

【アクション】

最後に

②なるべく対等な立場で目線をフラットにする　③指摘する時はとにかく優しく