はじめに
うめりんです。前回は思考整理のためのトレーニングでした。
まだご覧になっていない方は、記事に順序性は無いので後からでもご参考にして頂ければと思います。
過去記事（①〜③）＋他処での投稿記事を整理してまとめた
技術書典7で初頒布の「できるエンジニアリーダーになるためのトレーニング法」がBOOTH／とらのあな にて取扱中です。
https://booth.pm/ja/items/1573718
https://ec.toranoana.shop/tora/ec/item/040030792842/
更に、技術書典8-2日目にて、新刊発売予定です。
④自らがボトルネックにならないように、仕事を渡せる／受け取れる形にしておく
ここで言う「ボトルネック」とは、流れを滞らせる箇所の意味で、数々のタスクを捌く上での阻害要因になることを指しています。
エンジニアに限らず、1メンバーからリーダーへステップアップをするためには欠かせない考え方や準備です。
なぜ必要なのか？
リーダーになることは、1名以上のメンバーを束ねたチームを率いる役割を持つことを意味します。
そして一般的に、チームの外（上司や他職種／部署）からの依頼や、チームから外への報告や発信は、全てリーダーを介してやりとりする事が多いです。
単純に考えても最低2名以上の情報量を常にやりとりする（ハブになる）訳ですから、自分1人だけの作業で手一杯になっていたら回りません。
具体的に何をすれば良いのか
まずは、自分以外の誰かに仕事を渡す場合に、どのくらいの情報量があれば良いかを常に考える癖をつけて下さい。
当然、渡す先の（受け取る側の）メンバの知識やスキルによって、必要な情報量が変わることは分かると思います。
だからこそ合わせて、誰がどのくらいの知識やスキルを持っているかも把握する必要があります。
チームが担う手作業の粒度では、リーダー自身しか出来ないタスクをゼロにすることが、目指すべき状態となります。
次に、他者の状況を把握する癖をつけて下さい。
ここで言う他者とは、最終的にはチーム外の人達にも及ぶのが理想ですが、まずはチームメンバとなる人達を想定して下さい。
状況把握の目的は、手が空いている／手が一杯になっている、どちらかの状態では無いことを認識することです。
手が空いている場合は、他のタスクを依頼しないと手持ち無沙汰となりチームのパフォーマンスが上がらないですし、手が一杯の時には他のタスクを受け取れないので、チーム外の人達からの依頼を断らなければいけない状態のはずだからです。
最後に、品質を確認する基準とタイミングを考えて下さい。
どの粒度で作業を依頼するかにもよりますが、多くの場合コーディング作業を任せているけれどソースコードのレビューでリーダーがレビューに時間を取られすぎて、リリースまでの時間が短縮できない状態になることが多くの現場で見られます。
コーディング規約レベルの指摘はまだマシな方で、要求仕様が曖昧なまま進めてしまい、実装が全部終わったタイミングで「そもそも仕様がおかしい」となってしまった場合には、大きな手戻りが発生する事になってしまいます。
他者へ依頼する場合には、必ず「この部分をここまでやって欲しい」という意図・ゴールイメージを持って依頼することが肝心です。
おわりに
できるリーダーになるためには、できない（不慣れな）リーダーになる段階が必ずあり、不慣れでもリーダーになるためには、できるメンバであることが必須条件です。
自分の事すら出来ない人に他の人を含めたチームを任せることは、どのような業界や職種でも無いと思いますので、できるメンバになるためにも本記事の観点を活用して頂けますと幸いです。