「人にタスクをお願いする」エンジニアリーダーにチャレンジした時の気づきと学び

|

ありがたいことに、2023年7月あたりからリーダーポジションで仕事をすることが増えてきました。

具体的には以下のようなことをやっています。

  • 朝会での相談対応
    • 別チームとの調整とか
  • タスクの順番等の整理
    • 基本ルールは「各メンバーが自分で取る」なのですが、タスク間で依存関係がある場合はよしなに交通整理したりします
  • PullRequestのレビュー
  • PjMへの進捗報告、スケジュール感のすりあわせ

こういった仕事について、良い感じに成長痛を感じているので、初期の気づき/学びを書いておきます。

もっとこうすると良いよなど、指摘があれば教えてください！

[st-myblock id=”447″]

マインド面

「質を上げるとスピードも上がる」の意識、常に必要

「今はスピード重視の時期だから、設計微妙だけど一旦リリースしちゃって、後で直そう…」は結局幸せにならない。

内部品質とリリーススピードはトレードオフの関係ではない。

t_wadaさんのスライドでは、「内部品質への投資の損益分岐点は意外と早く(1ヶ月以内)やってくる」、つまり、「イケてないコードをマージすると1ヶ月後の自分達が苦しむことになるよ！」と書かれています。

speakerdeck.com

自分でボールを持ちすぎない

意識しないと、以下のようなNGな進め方で仕事してしまいがちです。（もしかして初心者あるある…??と思っています）

全部自分の思い通りにコントロールしたくなる
↓
自分でやるか、細かいところまで詳細をお願いしちゃう
↓
自分のタスクが増える
↓
自分がチームのボトルネックになる

解決策としては、

  • 自分1人でできることはたいしたことないことを自覚する
  • 人を信頼する + ある程度「まるっと」投げられる度胸を持つ
  • ヤバくなったら自分でなんとかできるように準備はしておく

こんな感じかなと言うのが一旦の仮説です。

「まるっと投げられる度胸を持つ」が一番価値観ぶっこわさないといけないところで、時間と経験を要するところですね。

2,3ヶ月先を意識したスケジュール管理

プロジェクトの全体感にも寄りますが、最低でも2,3ヶ月先のスケジュールに対して「今遅延しているのか、オンスケなのか」は気にするようにしていました。

もし遅延が見え始めてきた場合には改善案を話す場を設けて、見えてきたボトルネックを解消します。

また、山根の経験だと、ボトルネックは

  • コミュニケーション体制
  • 人が足りない

の二つに大きく2分されるような気がしています。

設計判断の引き出しは多い方が良い

自分の中で設計知識（特にアーキテクチャ・基本設計レベル）は、チーム運営の観点でも多い方が良いな〜と思います。

技術的課題が上がった時に、

  1. 要件を満たすための設計の案出し
  2. 関係者へのメリデメ説明
  3. 最終的な意思決定

という流れが一般的かと思いますが、設計の引き出しが多いと、上記の1~2がすごくスムーズになるので、最終的に3.意思決定へのリードタイムが短くなります。

山根は実務の中で1(案出し)に時間かかりすぎたり、一人称で進められなかったりした経験があるため、こういった「自分の設計引き出しの数、少なくね？」という課題感を持つようになりました。

改善のための一手として、こういった本↓を読んだりしつつ、「ベストプラクティスは何？」を探究する旅に出ております。。

www.socym.co.jp

「自分の技術を高める時間」が足りなくなりがち

前項と矛盾してしまうところです。

前項で「技術力が必要」なことを書いたのですが、一方で相談事に受け応えする時間が増えるので、「自分で技術検証したり、調べ物したりする」いわゆる自分の技術力を養う時間が減ります。

じゃあどうすればええねん、というと

  • オフの時間でアンテナ貼って調べごとをしてみる
  • 調べたら(このブログみたいに)アウトプットしてみる

ぐらいが今やれることかなと思ってます。

相談事がいろいろあると「ワイ、手を動かすべきではない…??」と思う時もあるものの、現場でコード書いて設計力とか養っておかないと、相談に乗る側でバリューを出しづらくなるので、難しいところです。

まとめ

リーダーとして仕事し始めた時の気づきについてまとめてみました。

まだまだ未熟者ですが、より信頼される、成果の出せるリーダーになれるように、経験積んでいきます！