「自分がコードを実装した方が早い（幻想）」「メンバに仕事を渡す勇気（理想）」「キャリア」の話

開発規模が大きくなると、マネージャが必要

ソフトウェア開発では、数人月程度の開発規模であれば、少人数のメンバがリーダーシップやオーナーシップを発揮して、勢いで開発しきれます。しかし、開発規模（開発期間、エンジニアの人数）が大きくなるにつれて、雰囲気での開発が困難になりがちです。

開発の不確実性を排除しながら、エンジニアに円滑に実装してもらうためには、開発を管理する役割を用意する考え方（方法論）があります。なお、この考え（トップダウンで管理する方法）はスクラムの世界では一般的ではありません。スクラムでは、チームを最大10人程度に絞り、チーム主体でセルフマネジメントする傾向にあります。

しかし、私の観測範囲では正しいスクラムを実践していません。「顧客と仕様調整をするディレクター」や「ディレクターとエンジニアの間に立って、作業調整するエンジニアマネージャ」がトップダウンで作業の指示を出します。会社が良しと判断した方法で、プロダクト開発を進めています。

自分が実装した方が早い、そんな幻想

私は今、エンジニアとディレクターを繋ぐProxyを担当しています。プロトコルは、UDPです。過去には、エンジニアと顧客を繋ぐ役割も担当していました。経験年数は、4年程度です。

このような役割で仕事をしていると、「この不具合を直して欲しい」「この機能追加をして欲しい」という要望をいち早くキャッチできます。脳内では、「修正範囲はココで、1〜2時間ぐらいで実装できるな」と具体的な修正案が思い浮かぶこともあります。

しかし、私は30分ぐらい説明に時間をかけて、他のメンバに実装して貰う選択肢を選びます。「私が実装した方が早いのに」と思いながら、仕事を渡します。現実は、他のメンバの方が仕事が早いです。その理由は、他のメンバは作業割り込みが少ないので、着手から実装終了までのスパン（リードタイム）が短い傾向にあるからです。

マネージャーである私の方がドメイン知識があり、かつコードを把握していますが、私は割り込み作業が多いのでリードタイムが長い傾向にあります。私は、作業を着手してから一週間程度放置することもあります。工数ではなく、リードタイムで考えると、私の作業は相当遅いのです。私の方が早いは、幻想です。

メンバに仕事を渡す勇気

プログラマあがりのマネージャにとって、全ての設計やコーディングをメンバに渡すことは、勇気が必要です。エンジニアとして成長する筈だった機会を捨てているからです。しかし、その勇気によって、プロダクト開発の全体最適化は推進されます。

個人的な感情で作業を抱え込んでも、そこがボトルネックとなるだけです。作業を切り出して、他のメンバにポンポン手渡した方がリリースまでのリードタイムは短縮されます。リリース（納期）を遵守することがマネージャの責務であることを忘れてはいけません。

とは言え、キャリアどうするのよ

私は、エンジニア人生の半分以上がマネージャです。

しかし、マネージャの仕事ができるだけで、自身の性格と一致した役割ではないと考えています。私は、他人と対面で話すと体力と精神力を奪われるので、他人と私の間にレイヤーが挟まれるテキストコミュニケーションが好きなタイプです。そんな私が仲介役を行うと、ストレスが指数関数的に増えます。

そもそも、私は技術的に優れたエンジニアに憧れ、David Cutler（Windows NTの開発者）やJohn D. Carmack（FPSの生みの親）、Linus Torvalds（Linux／gitの開発者）のような尖った方々が好きです。チームに対する共感性／協調性の高さより、コーディングスキルの高い方々が好きです。

しかし、自分の「好き（コーディング）」が仕事にならず、「得意（できること）」が仕事になりやすいことを理解しています。このような背景を踏まえて、私に残された道は３つあると考えています。

• エンジニアからマネージャに完全にジョブチェンジ（妥協する）

• エンジニアに戻る道を選ぶ（好きを貫く）

• 仕事は力を抜いて、OSS開発でスキルを磨く（現実路線）

私も若くないので、来年までには上記のいずれかを選択するつもりです。