あるプロジェクトで、ユーザーに価値を届けるため（機能開発のため）、落ちているタスクを積極的に拾ったことがあった。 "落ちているタスク"とは、ここでは、「明確にオーナーがおらず、しかしプロジェクトの成功には必要不可欠な仕事」を指している。
それは非技術的なタスクで、むしろドメインの専門知識が必要な類だったが、英語ができる自分であれば相対的に容易にこなせるタスクでもあった。
そのタスクをやると決めたのは、自分の技術力も未熟で、なんとかバリューを出したかったからだ。 そもそも二人のエンジニアで進めているプロジェクトで、他にチームで手が空いている人もいなかった。
結果的にリリースは間に合ったし、ユーザーにも大きな価値を届けることができた。 技術ではないタスクとはいえ、ドメインの勉強にはなったし、作業タスクをどう効率的にさばいていくかの学びもあった。
だが当然ながら、そのタスクから分かりやすい技術的な成長*1はなかった。 技術力をつけたいと強く思っていただけに、後から振り返って、そのタスクに時間を使ったことに強い悩みと葛藤を感じることになった。 バリューを出すことはできたが、それが次の成果を大きくすることには繋がっていないのではないか。 エンジニアとしてできることは増えていないんじゃないか。 しばらくそんな悩みを抱えることになった。
方向性が決まっているなら、自分本位な選択をすることも大事
この時の私は、自分の成長と仕事の関連の度合いを強く意識はしておらず、 事業視点で成果が出るように動くことが結果、自分の成長に繋がると考えていた。 今まで読んできたいくつかの本にもそう書いてあるし、実際正しい。 高い視座から仕事の優先度を判断して、眼の前の仕事を全力でこなすことができれば、誰にとっても大きな成長につながるだろう。
ただ、成長したい方向性、自分が身に着けたい力が朧気でも決まっているのなら、追加の調整が必要だ。 事業や会社にとって大事なこと、ビジネスインパクトがあることが、必ずしも自分の成長の方向性と一致しているとは限らないからだ。身に着けたい技術を使っている別のチームに移ったり、自分の成長の方向性をマネージャーに相談して関連タスクを取れるように動く必要がある。
つまり、会社と事業の方向性から、自分に求められていることを理解して実行すると同時に、自分のキャリアプランと沿うように仕事を選択していくのだ。 もし担当する仕事が自分のキャリアプランと沿わなければ、モチベーションを失ってパフォーマンスを落とすかもしれないし、結局成果が出なくなるなら、会社にとっても良くない。 もちろん、個人の成長ばかり追い求めてインパクトのない仕事ばかりしていれば、今度は会社からみた成果が出ない。本人も評価されないために成長機会は失われるわけで、プロダクトも改善されないので、ユーザーにとっても不利益となる。要はバランスではある。
ビジネスインパクトと自身の成長が重なる割合をできるだけ大きくする努力を怠ると、成長はしていても自分の願ったキャリアとは別の方向に進んだり*2、いつまでも欲しい力が身につかなかったりするのではなかろうか。 人によっては、事業の目指す方向性に100%共感していて、あるいは、チームの仕事が自分のやりたいことと100%マッチしていて、ビジネスインパクトだけ考えて仕事をすればいいかもしれない。 しかし残念ながらそういう人間でも、そういう環境でもない場合*3、長期に持続的に成果を出していくためには、自分のキャリアの方向性に照らしてどうか、の視点をある程度考えた方がよい。
念の為断っておくと、「会社は自分が成長するためにあるから、自分の成長だけ考えていればいい」という話ではない。（私はこの考え方が好きではない。） 長期的視点から、事業に対して生み出す価値の総量の期待値を最大化しようとすると、自分の成長を考慮に入れた意思決定が最善だという話だ。
エゴを出す
つまるところ、「どのプロジェクト/タスクをやるか選ぶときや、仕事をする中で、ビジネスインパクトと自分の成長のバランスをうまくとること」が大事だ。 意思決定に自分の成長を加味することを、私は「エゴを出す」と呼んでいる*4。 とはいえ、プロフェッショナルとしてお金をもらって仕事をする以上、自分の成長を考えることには抵抗があるだろう。
どのようにバランスをとるとよいか。 私の意見では、自分の経験が浅ければ浅いほど、組織が大きければ大きいほど、エゴを出していいと思う。 それは、ビジネスインパクトと自身の成長が重なる割合が低くなりやすいからでもあるし、期待値の中に成長も入っているはずだからでもある。 小さな成果しか出せないのに、目先の成果を追い求めることで将来の成果が出せなくなる機会損失の方が、トータルの損失は大きいはずだ。
それは必ずしも、短期的成果をないがしろにするという話でもない。 仕事で成長できるなら、仕事はより楽しくなるし、楽しく仕事をすればチームの雰囲気を良くすることに寄与するはずだ。 やりたいタスクが自分の実力に対して多少難しいタスクでも、オーナーシップを持ってチャレンジすれば、周りは応援したくなるし、助け舟も出してくれる。 そういった姿は、周りのエンジニアに刺激を与えることになる。 むしろ、チームで経験の浅いエンジニアが、成長しないようなタスクばかり取っている方が心配になる。 遠慮してそこそこのタスクに落ち着くよりも、エゴを出して挑戦する方が遥かに良い。挑戦は自分のためならず、だ。
後輩にあたる新卒と話した時に、「なんでもやります」と話す方が何人かいた。 気持ちはわかるし、やる気があるので大きな心配はない。 だが、「自分が何をしているときが楽しいか」「何はやりたくないか」「何は楽しくないか」といった自分の希望を少しでも言語化できていると、より濃い成長機会が得られるし、マネージャーなど、アサインする側も助かるはずだ。 「やりたいこと」がない場合は、今年度（2023）の東大の入学式の祝辞を読んでみることをおすすめする。
具体的に何をすることがエゴを出すことなのか
では具体的に何をすればいいか。 行きたいチームの希望を出したり、身に着けたい技術に関連したタスクを取ることはすでに触れた。 具体のタスクをやっている中でも、初歩的な例をあげれば、「コピペで済むところを中のコードまで追ってみる」がある。
理解してコードを書いても、コピペで書いても、それが動くコードであれば、翌日与えるビジネスインパクトは変わらない。 だから少し自分の成長のために、そしてもちろん、良いコードを書くために、自分が何をコピペしているのか、しっかり理解する。 多くの人が当たり前にやっているだろうが、人によって深さは違うのではなかろうか。社内レポジトリの実装まで追うのか、依存パッケージまで見るのか、標準ライブラリやさらにその下のレイヤーまでみるのか。 横に広がる人もいるはずだ。マイグレーションを扱うライブラリは複数あるが、何故その技術選定がされたのかを調べてみたり、あるいは、別の実装の方が良い気がするから他の選択肢を調べてみたり、など。
エゴと両立できる組織じゃないとスケールしない
冒頭の話を起点に、エゴを出すことが、先々に生み出せるインパクトに影響することを書いてきた。 冒頭の話について、私がエゴを出すべきだったと思う理由がもう一つある。 それは、私が非技術的なタスクを取ったタイミングが、本当は、会社やチームにとっても、その仕事の専門家を配置する体制を作る機会になったはずだというものだ。
私の所属する会社（当時）は十分に体力のある会社で、必要であれば人材を雇うことはできるのに、あの場では私の腕力で解決することを選択してしまった。 もし私が早い段階でヘルプを求めて、専門のリソースが必要だと伝えれば、それが人員の再配置に繋がり、今後の同様のタスクがより早く処理される体制が作れただろう。 プロジェクトが終わった後にマネージャーにフィードバックして、しばらくたってから専任で人もつくようになったが、もう少し早く動けたはずだ。
会社が十分に大きいというのは私が見逃していたポイントで、例えばスタートアップであれば特に問題ではないし、腕力は一つの正解だろう。 リリースが間に合ったのだから万事OKだ。 私のケースも、もちろんスケジュールは厳しかったし、専門家が来るのを待っていたら間に合わなかっただろう。
だが腕力による解決はスケールしない。大きな企業ほど向いていない。
開発の現場のエンジニアが望まない仕事をしなければいけない状態、本来専門家がやる方が安全な仕事をエンジニアがやってしまってる状態*5は健全ではない。 健全でないとはつまり、持続可能性が低かったり、人材定着率が悪いことを指す。 早期にシステム的な解決を図らないと非効率が生まれ、組織が大きければ大きいほど、その非効率はいたるところで発生する。 （保身のために言っておくと、私は望まない仕事をしていた感覚はなく、必要だから淡々とやった。ただ、それが私でなくてもできるとは思わないし、再現性はないと思っている。） 「それは私の仕事ではないので」などの態度は論外だが、その根底にある「人は楽しくない仕事ではパフォーマンスがでない、長続きしない」点は見逃さずにシステムで解決しないと、組織規模が拡大しても、成果が伸びない要因になりうる。
まとめ
自分語りも含めて長々とかいてきたが、言いたい事をまとめると3行だ。
- 事業の方向性から自分に求められていることを理解し、自分のキャリアプランと沿うようにチームやタスクを選択していく。
- すると、自分のモチベーションも保ちつつ楽しく成長でき、より大きな成果を出せるようになる。
- 大きな価値を生み出せばユーザーも会社も嬉しいし、その過程においても周りに良い影響を与える。
