プレイヤーとマネジメントの境界線

Photo by mali desha on Unsplash

もともとソフトウェアエンジニアとしてJOINさせてもらって現職だが、入社1ヶ月くらいだけVue.jsでフロントエンドの開発をやった以降ずっと、5、6名プロジェクトのPMとして働いている。

PMで開発マネジメントばかりする生活に辟易し、自らソフトウェア開発をしたいがため前職を辞めたのだが、結局行き着いた先でもPMをしている。なんとも皮肉なものである。ソフトウェアエンジニアとしてよりレベルアップをするため、そしてエンジニアが楽しく開発できる文化を作りをやってみるための転職だった。ある程度うまく回りつつあるように感じてはいるが、自らが希望していた形で動けていないので、残念な思いは未だにある。

私は開発が好きだ。プログラムを書いて価値を生み出すものを作る。作ったものが価値を生み出す瞬間、それをいかに短い時間で正確に作り上げていくか。私の中では一種のゲーム、パズルゲームの早解きだ。故に開発初期の技術検証や、パフォーマンスチューニング、開発ワークフローの整備等、効率を上げることが得意でもあった。

しかし、それもほんの数年前までの話になってしまった。PMの仕事はビジネスとエンジニアの間を繋ぎ、期待される期日に、なるべく高い品質で、限られた費用でシステムを開発することだ。自分が手を動かすことではない。他のメンバーの支援をしながら走らせないといけない。

これまでは自分で最高速度を出せればそれでよかった。しかし、今は自分だけが最高速度を出しても価値にはつながらない。チームを引っ張って、顧客を巻き込んで。1つの価値を生み出すための作業や工程が増える中、乗って来れないメンバーに引きづられて落ち込んでいく。

マネジメントが陥る移譲できない問題はおそらくこのようなものだろう。自らがやれば早く正確である。他のメンバーに移譲すると教育や説明のコストが乗っかる上に自分でやるより早く正確にはできない。どこかで読んだがせいぜい6割できれば上出来ということらしい。

こういう実体に心が耐えられないのだろう。自らのコストを増やして前準備をしっかりしてメンバーに下ろす。でも前より遅くなってしまう。この苛立ち。少なくとも今の自分はそう感じることが多い。

もちろん、移譲がどれだけ大切かは理解してるつもりだ。長い目でみれば移譲されたメンバーが8割9割再現できるようになりさえすれば、結果的にチームが生み出せる仕事の総量は増える。マネジメントがやるべきことは、仕事の抽象化と属人性の排除である。自分しか生み出せない価値を誰もが実現できるように整理し、共有する。そして組織全体の生み出せる価値を最大化する。これができないマネジメントは、与えられた職務を全うできていないわけだ。

今のところ、なんとかその活動はやれてはいる。だが、時折寂しくなるのだ。これまでいろんな努力や苦労を積み重ねてきたソフトウェアエンジニアの長い経験は、一体何のためになったのだろうかと。