リーダー１年目の懺悔


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


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

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


## ４つの反省と学び
最近、自分の現状と比較できて勉強になった本があります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/489819/6e96091e-23ff-cd9e-4942-5bb97da77936.png)
[アマゾンのリンク](https://www.amazon.co.jp/%E3%83%AA%E3%83%BC%E3%83%80%E3%83%BC%E3%81%AE%E4%BB%AE%E9%9D%A2-%E3%83%BC%E3%83%BC-%E3%80%8C%E3%81%84%E3%81%A1%E3%83%97%E3%83%AC%E3%83%BC%E3%83%A4%E3%83%BC%E3%80%8D%E3%81%8B%E3%82%89%E3%80%8C%E3%83%9E%E3%83%8D%E3%82%B8%E3%83%A3%E3%83%BC%E3%80%8D%E3%81%AB%E9%A0%AD%E3%82%92%E5%88%87%E3%82%8A%E6%9B%BF%E3%81%88%E3%82%8B%E6%80%9D%E8%80%83%E6%B3%95-%E5%AE%89%E8%97%A4%E5%BA%83%E5%A4%A7/dp/4478110514)
**リーダーの仮面** という本です。
この本は、私のようなリーダーになりたての人をメインターゲットに書かれている本で、
「識学」という意識構造改革で、ざっくりに言うと、作業指示から目標設定などなど様々な観点からリーダーに必要な考え方やメソッドが書かれています。

今思うと、明らかに自分の指示の仕方が悪いのですが、
リーダーなりたての頃によく行っていたこととして、
~~~
 ①作業指示は基本チャットに記載
 ②なるべく対等な立場で目線をフラットにする
 ③指摘する時はとにかく優しく
 ④作業を振る時に「お願いをする」
~~~
があります。

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

### ①作業指示は基本チャットに記載
ログとして作業指示が残るというメリットはありますが、デメリットだらけです。
~~~
・作業の意図が理解されているのか分からない
・そもそも作業指示が通っている(読まれている)のか分からない
・チャットが流れて、気付いてない
~~~
まぁ、当たり前ですよね。
基本オンサイトで業務を行っているのに、何してるんだと振り返ると思います。

#### 【アクション】
言わずもがなですが、まずチャットで概要を送ります。
`チャットで概要を送る`とは基本的には以下です。
~~~
・作業指示の概要(作業の内容、ゴール、期限)
・関連する資料が格納されているリンク
~~~

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

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

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

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

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



## 最後に
最後に本書の中で今の自分に刺さる５つのポイントがありました。
~~~
①「いい人」になろうとしていないか？
②「待つ」ことを我慢できるか？
③「部下と競争」していないか？
④ 「マネジメントを優先」しているか？
⑤「辞めないかどうか」を気にしすぎていないか？
~~~

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

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

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

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

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

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