こと開発において、マネージャーがどの程度現場で手を動かすべきか。あるいは動かすべきではないか。というのは、ソフトウェア開発において常々語られるテーマです。

この問題については、事業やチームの状況・コンディションに大きく左右されるため一概に正解を導くことはできないものの、 N=1 を増やしていくことによって、ケーススタディを増やすことはできるテーマであるとも考えています。

自分自身、他人の仕事への取り組み方をエッセンスとして取り込んでいることは多くあるため、他の開発者・マネージャーに向けて、私自身の現在を情報として残しておこうと思います。

私の状況について

現状私のレポートラインにおいて管轄の外部向けの事業は2つ存在し、それぞれで現場についてはプロジェクトの進行まで含めてチームメンバーに任せているプロジェクトと、現場のリードとして私が出向いているプロジェクトが1つずつある状態です。

社内サービスなどの場合は諸々の融通が効くことから特に意識する必要がないこと、また現場が手から離れている場合は出向くことは基本的にないことから、今回は私が現場のリードを兼任しているプロジェクトでの立ち居振る舞いに限定して言及します。

今回紹介するプロジェクトである『LINEスキマニ』の事業並びにチームの概要はこちらから。

https://speakerdeck.com/line_recruiting/introduction-of-line-sukimani-front-end-development-team

原則工数はつけず、たった一つの例外を設ける

結論からいうと、私が今行っている方針は

• 「原則開発の見積もり・アサイン段階では工数をつけない」
• 「唯一の例外として、直近のリリースに含まれるもので、かつそのときに未アサインのものアサイン・着手を容認する」

となっています。

LINEスキマニではおおよそ二週間を一つのスプリントとして開発・リリースがされており、場合によって1~3週間程度で±1週間のブレがある状況です。

そのため、必ず現在リリース準備中のバージョンと、将来のリリース予定のバージョンが有ることになります。例えば今週末に v1.10 をリリースするとなると、 v1.11 のリリースは 2 週間後、 v1.12 のリリースは 4 週間後になります。

この場合、私が着手するのは v1.10 に含まれるもので、かつあとから急ぎで対応してほしい対応事項（いわゆる「差し込み」と呼ばれるもの）と QA において発生した修正事項のみとしています。

特にこのプロジェクトはまだリリースから一年も経たないプロジェクトであり、行いたい改善や急ぎで対応したいもの、高速にイテレーションを回したい課題などが豊富に存在します。

それに伴い大きな feature であれば将来に向けて腰を据えて開発をすべきですが、細かな改善はスピーディーに対応するほうが、機会損失を最小限にできることは間違いないでしょう。

一方でこの対応をメンバーに強いる場合、常時高負荷になることや、差し込みによって一日に行うタスクが分散レされてコンテキストスイッチも増え、結果的に本来アサインされているタスクの工数見積もりに対しての実績値への信頼が低下することから、今仕事を持っているメンバーに依頼することは得策ではないと考えます。

そのため、こういった仕事に限定してマネージャーである私があえて実働することで、ノイズと機会損失の両方を最小化する戦略をとることとしました。

なお、 QA において発生した修正などはそれを含めてメンバーに依頼することが多いので、どちらかというとリリースが近いタイミングで来る相談事項をヒアリング後すぐに実装するケースがほとんどです。しかし、そうは言っても現実は現実。分散したほうが効率が良い場合や、ドラスティックな変更が多くて QA にて修正事項が多数出てくることが予想できる feature については、私も積極的に現場での対応に参加している状態です。

次の半年どうするか

とはいえそれは今日の話。

サービスも成長を続けていることから、半年もするとメンバーの規模も、開発チームに求められるフットワークの軽さと壮大さのバランスも変わるのは当然。そのため将来的にはこのポジションは、マネージャーとは切り離したリードとして存在すべきであると考えています。

私は今はリードでありマネージャーである状況ですが、これらは「開発者の観点として、プロダクトのデリバリーに責任を持つ」開発リードと「メンバーの状況に応じて最適な人員配置と全員のvelocity最大化に責任を持つ」マネージャーの2つの役割を兼任しているだけであり、分割できるはずです。

現状は異常系のリスクと機会損失のリスクであれば、後者のほうがより重大ですが、近いうちにその関係は逆転することでしょう。

そういったときに、明日のデリバリーと一年後のデリバリー両方に責任を持つ人。端的にいうと、エンジニアとして enjoy できるタスクより、事業観点で必要だけどもしかしたら開発者としては exciting ではない仕事を担当することを受け入れることができる人はどこかで必要になるはずです。

なぜならいつかそれは「個人の利を会社の利に結びつける」というマネージャーの役割と相反する部分が出てくるから。

そのときには、きっと工数を自身にはつけない状態になっており、リードとマネージャーがコミュニケーションをできる。そして本当の有事のときだけ出てくるという姿がベストかなと考えています。

また半年後にも、振り返ろうかと。

展望に対して工数が足りない場合にどうすべきか、などなどまだまだ語りたいことはありますが、この議題としてはここまで。