開発リーダーの心得
どんな人向けの記事か
- エンジニアをしているが、開発リーダーやPMを任された
- 何らかのリーダーを務めることになった
- 開発リーダーやPMの仕事の進め方について知りたい
エンジニアのキャリアについて
エンジニアのキャリアは大きく分けて二つあります。
- 技術のスペシャリスト になる
- 技術のことがわかる マネージメント職 になる
1. 技術のスペシャリストになる
より専門性の高い技術領域のスペシャリストになることです。
インフラエンジニア、フロントエンド、データ解析、ディープラーニング、などなど。
会社の中で、その技術について一番詳しいポジションにいる人や、
シリコンバレーのトップエンジニアをイメージしてもらえると良いと思います。
2. 技術のことがわかるマネージメント職になる
開発リーダーや、プロジェクトマネージャーのことを指します。
年齢が上がるにつれて、こちらの方が人数比が多くなる印象があります。
技術のことがわからないPMより、技術のことがわかるPMの方が、現場では重宝されます。
求められるスキルは以下のようなことです。
- リーダー経験
- 一定のエンジニアとしての開発経験
- コミュニケーション能力
- クライアントとの交渉力
- 営業スキル
- 人を動かすスキル
どちらに進むべきか
合う合わないもあるので、若い時から上記のキャリアをイメージしておくと良いでしょう。
また、厳密に上記2つに縛られる必要もなく、
両方を兼ねるプレイングマネージャー、のような立ち回りをしている方もいます。
リーダー経験の重要性
リーダー経験があると、その人の市場価値が上がります。
理由は、リーダーの気持ちを理解できる人の方が、リーダーが一緒に仕事をしやすいから です。
あらゆる組織において、基本的にすべての質問・相談・問題の解決依頼はまずリーダーに来ることが多いです。
また、それを解決できなかった場合の責任も、リーダーにあります。
1人では回らない分量が一気に押し寄せるので、タスク委譲（＝メンバーに仕事をお願いすること）が必須になってきます。
この時に、仕事をお願いして快く引き受けてくれるメンバーが多い組織の方が、うまく回りますよね。
「全部一人でやらないといけない・・」「自分でやった方が早い」と思って抱え込んでしまうリーダーもいますが、
それだと長期的に見てスケールしません。
結果、パンクして人に迷惑がかかってしまいます。
このようなことから、リーダー経験があり、いろんな立場の人の気持ちが想像できる人の方が、市場価値が高いと言えます。
開発リーダーの心得
本題です。
開発リーダーを任される立場の人は、他のチームやプロジェクトでもリーダーを務めているケースが多いです。
単純に仕事量が多すぎるので、仕事の進め方を変えないと、うまく回りません。
そのために、以下がポイントになってきます。
- タスクを一切持たない（＝タスク委譲する）
- 属人化させない
- 常にスケールを意識し、メンバーを成長させる
- 完璧を求めすぎない
- 余剰時間を作り、仕事内容ではなく、進め方に問題がないか考える
- 本やYouTubeなどで常に勉強する
順番に解説していきます。
タスクを一切持たない（＝タスク委譲する）
実装タスクも含めて、すべてのタスクを極力持たないようにしましょう。
エンジニアの場合、コードを書きたい欲がめちゃめちゃ湧いてきますが、ここはグッと我慢しましょう。
なぜなら、プロジェクトで与えられている役割は、コードを書くことではなく、
プロジェクトを炎上させず、一定の利益率を確保し、メンバーが安心して開発できる環境をつくり、クライアントに感謝されるアウトプットをすること
だからです。
リーダーには想定外の緊急度の高いタスク（相談、炎上案件の調整、断りにくいクラウアントからの急な要望など）が、急に割り込んでくることが多いです。
もし、プロジェクト内で重要な実装タスクを持っていたらどうなりますか？
割り込んできた緊急度の高いタスクにより、実装タスクが押しのけられ、期日が守れなくなり、炎上することになります。
このように、開発リーダーは割り込みタスクが入ってきた時に柔軟に対応できるようにしておく必要があります。
どうしてもコードを書きたい場合はどうするか
しばらくコードを書いていない人が、コードレビューをする、という状態は決して良い状態ではありません。
このために、開発リーダーは以下のような方法で少しでも良いのでコードを書いておきましょう。
- 趣味で好きなものを作る
- コードレビューする際に、pull してきて手元で少し修正してみる
- 小規模案件の場合は、プレイングマネージャーとして少しの実装を担当する
属人化させない
ずっと同じメンバーで仕事ができれば良いのですが、現実はそうではありません。
組織とは、様々な事情で人が入れ替わっていくものです。
長期的な視点で、プロジェクト内のタスクは属人化しないようにしておきましょう。
Aというタスクがあったとすると、それを A-1 と A-2 というタスクに分解し、
A-1 を山田さん、 A-2 を鈴木さんにお願いします。
これにより、Aというタスクは山田さんと鈴木さんが把握しているので、
どちらかが抜けても、新たに人を追加して引継ぎしやすい状態になります。
加えて、常にドキュメントを書く、という習慣もとても重要です。
開発リーダーは、常に人が入れ替わっても良いように、
タスクの割り振りを考え、同時にドキュメント化する作業もお願いしていく必要があります。
常にスケールを意識し、メンバーを成長させる
メンバーのスキルは様々ですが、チーム全員のスキルが上がることで一気にスケールします。
タスクの割り振りは、 ちょうど良い難易度 を意識しましょう。
ちょうど良い難易度とは、 簡単ではないが、頑張ればできる 程度です。
それぞれのメンバースキルにあったタスクを割り振っていくことで、
メンバーが成長する機会が生まれ、
徐々に、仕事の裁量を任せられるようになっていきます。
タスクが難しすぎると、たくさんのサポートが必要になりますし、
逆に簡単すぎると成長にならず、スケールしません。
メンバーのスキルを把握し、 ちょうど良い難易度 を意識しましょう。
スキルを把握するために雑談をしたり、ランチを企画してコミュニケーションをとったり、
ということも重要です。
完璧を求めすぎない
すべてにおいて完璧を求めすぎないことも重要です。
可能な限り保守性の高いコードにしたいのですが、完璧を求め過ぎることで、納期に間に合わないと本末転倒です。
開発リーダーに求められていることは、ある程度保守性の高いコードをアウトプットし、
クリティカルなバグ数を最小に抑え、 プロジェクトを遅延なく進行させること です。
"すべてを完璧に進めないといけない" マインドではなく、
"何が今一番クリティカルな問題なのか、優先順位をつけて、解決する" マインドでいましょう。
余剰時間を作り、仕事内容ではなく、進め方に問題がないか考える
「優秀なリーダーは暇である」ということをよく聞きます。
これは、暇になるように仕事量を調整しているということです。
さらに、その暇な時間を以下のようなことを考え、言語化する時間にあてています。
- プロジェクトを俯瞰して、クリティカルな問題や、抜けている事がないか
- スケジュールは正しく引かれているのか
- 炎上リスクになることはないか
- 今の進め方で問題はないか
- 急に人が変わっても問題がないか
- メンバーが楽しく仕事できる環境になっているか
この時間がとても重要です。
タスクやミーティングに追われてしまい、この時間が確保出来ず、後に炎上するというケースがよくあるのではないでしょうか。
人間は、毎日の業務が忙しいと、充実感を感じたり、仕事している感を感じてしまう生き物です。
開発リーダーは、毎日の業務に追われてはいけません。
追われるのではなく、能動的に、仕組みや進め方を変えることで常に改善していきましょう。
本やYouTubeなどで常に勉強する
開発リーダーに限らず重要なことですね。
勉強することを習慣化できた人は、
1年後、3年後、5年後と時間が経過するにつれて圧倒的に差がついていきます。
実際のプロジェクトで経験して学習することと、
本や動画で学ぶことを良いバランスでインプットして改善する、を繰り返しましょう。
まとめ
- エンジニアのキャリアは、技術のスペシャリストか、マネージメントの大きく分けて2つある
- 年齢を重ねると、マネージメントに進む人の方が多い
- リーダー経験があると市場価値が上がる
- 開発リーダーの心得
- タスクを一切持たない（＝タスク委譲する）
- 属人化させない
- 常にスケールを意識し、メンバーを成長させる
- 完璧を求めすぎない
- 余剰時間を作り、仕事内容ではなく、進め方に問題がないか考える
- 本やYouTubeなどで常に勉強する
世界には様々なタイプのリーダーがいますし、その人にあった考え方や仕事の仕方があると思います。
この記事の内容が100%正しい、ではなく一つの参考にしていただければと思います^^
参考サイト
Discussion