はじめに

この記事について

「エンジニアのキャリア戦略とアウトプットの重要性」というテーマでなにか話をしてほしいと依頼されて以下のイベントでしゃべったので、その記録です。

スライドは公開しませんが、内容的には前半は以下の記事記事とほとんど同じになりました（今回時間が少なくてダイジェストっぽくなってしまいましたが）。

nunulk-blog-to-kill-time.hatenablog.com

ソフトウェアエンジニアのキャリア戦略について

極端にいえば、一人一人そのときどきの自分に合ったキャリア戦略は異なるだろうし、いろんな側面があるので、一概にこうすれば上手くいくよっていうのはなかなか言いにくいです。戦略なしっていうのも、ある意味では戦略ですが、そうはいっても、ひとつひとつの選択において、なんの選択基準も持たないっていうのはないと思うので、意識してないだけで、それなりに戦略は持ってると思います。

今回のトークで話したことのうち上の記事に書いてないことは、2つ目のテーマである「アウトプットの重要性」と絡めて、キャリアラダーを登ろうとするなら、どのみち（IC → Staff の流れでも Manager の流れでも）チームの成果を求められることになるので、チームの成果を上げるためにはどうすればいいかっていう視点は持っておいたほうがいいと思います、ってことでした。

まれに個人的にキャリア相談を受けることもあるんですが、つまるところ「どうしたいんですか？」って聞き続けるしかない気がしていて、相手が自分の内なる声を聞く手助けはできても、導くことはできないので、こうやって登壇依頼が来ることはありがたいと思いつつも、他人ができることは気づきを与えることくらいで、あとは自分で考えないといけないと思うんですよね。

意識的にやろうが無意識的にやろうが、上手くいくかどうかは時の運もあったりしますが、「これはチャンス」って思って飛びつけるかどうかで変わることもあるので、意外と戦略はそれほど大事ではないかもしれません。

アウトプットの重要性について

話したことは、最近投稿された以下の記事に近い感じのことが載っていたので、リンク張っておきます。

qiita.com

上の記事を読んで、今回のトークでは言いませんでしたが、以下の考え方は伝えたかったと思いました。

あなたが10分かけたエラーは世界の誰かも10分書けて調べます。あなたが記事にして書くことによって誰かの10分を救うことができるのです

もしアウトプットをためらっている方がいたら、こういう精神が大事なのかなってお伝えしたいです。

自分がなにか書いてもな…みたいな逡巡は、わりと杞憂だと思うので、がんがん出しちゃっていいと思ってる派です。

今回のイベントでは、ソフトウェアエンジニアとしてのアウトプットはもちろんプロダクトが第一ですが、テキストや音声による情報共有も大事ですよっていう話をしました。

キャリア戦略のところで言った、チームの成果っていう観点では、いかに情報を伝播させるかっていうのも重要になってきます。アウトプットしたからOK、ではなく、それが伝わるようにするってことです。

セルフブランディングっていうといい印象を持たない人もいるかもしれませんが、自身の提供できる価値を目に見えるようにする、あるいはどう見せるか工夫する、ということであって、もちろん誇大広告は良くないですが、臆することなく、自己をアピールしていけばいいと思います。

といいつつ、自分は、外向きにはテキストでのアウトプットはもう自分のブログに駄文を連ねることしかしていなくて、自分にとってはもうセルフブランディングは必要ないのと、単純に書く意欲がなくなってしまったので、その辺に関してはじゃっかんの後ろめたさみたいなのを感じつつしゃべってました。

一方で、内向きにはドキュメントを書くのはがんばっていて、チーム内の知識の伝播とか、平準化みたいなのには常に気を配っています。

キャリア戦略にしてもアウトプットにしても、けっきょくのところ、他者にどれだけ価値提供できるかっていうのが肝なので、いまの自分にできることはなんなのかを常に考えるといいんじゃないでしょうか。それがやりたいことであればハッピーですし、そうでなければ、どうすればそれを好きになれるんだろう、楽しめるんだろう、っていう工夫をすればいいし、意外と単純なことなのかな、と思います。

2024-06-21 23:00 追記

さっきたまたま読んだ記事に関連したことが書いてあったのでメモ代わりに貼っておきます。

https://logmi.jp/tech/articles/330670

これから先は何が求められるかというと、暗黙知を形式知にして、コンピューターで実行可能にする人材なんですね。だから、とがった人材が欲しいというわけじゃなくて、暗黙知を形式知に変換できる人材が欲しい。

いいドキュメントというのは、それのみで経験をトレースできるというか、再現可能なものだと思うので、ドキュメントに関しても、チーム内でレビューし合うといいんじゃないでしょうか、なかなか個人でドキュメントの質を上げていくのは難しいと思うので。

おわりに

一緒に働くチームメイトに対してはもちろんのこと、駆け出しエンジニア、みたいな位置づけの人たちに対しても、なにかご縁があれば相談に乗るのはやぶさかでないですし、だれかの参考になるのであれば、話をするのもためらいはないんですが、ウェビナー形式だとどうしても一方通行のコミュニケーションになりがちなので、そこが不満点ではありますね。