# マネージャーにならなくても評価されるのか？ じゃあ、あきぃくん、今日ワンオン宜しくお願いします。 宜しくお願いします。 そう、今日はですね、相談したいことをいつも持ってきたんで。 はいはいはい、いいね。 いいですか、相談したいこと。 もちろん。 はい、じゃあ一つ目なんですけど、僕結構入社4年目くらいになってきて、 そうだね。 エンジニアとしては割とこれからキャリア考えてるんですけど、 自分が向いてるなっていう方向性としてはやっぱりスペシャリストみたいな、 スペシャリスト、はい。 ディクリードみたいなのを考えてるんですけど、 どっちかというとエンジニアリングマネージャーとかの方がいいっていう意見もあったりして、 はいはいはい。 そこはどうなのかなって、ちゃんと技術を突き詰めても評価されるのかなって気になってます。 うんうんうん。 エンジニアリングマネージャーがいいっていうふうにきゆくんが言ったところって、 評価されるっていう点のいいっていうところ。 そうですね、結構イメージとしてはエンジニアをまとめて出すアウトプットを最大化するっていうものだと思うんですけど、 ディクリードっていうと、やることとしては技術のエキスパートというか、 エキスパートを引っ張っていくっていう感じになると思うんですけど、評価的にどうなのかなっていう感じですね。 なるほど、ありがとう、理解です。 Voiceは基本的にはテックリードとエンジニアリングマネージャーの部分で評価とかも、 テーブルも全く一緒なので給与とかも全く一緒みたいな形になっていますというところとかもあるので、 基本どちらだからいいみたいな話ではなくて、 どちらも同等に評価されてっていう形になるよっていうのがVoiceのところになったりするかな。 世の中の部分とかは今結構色々、 特にテックリードとかはスタッフエンジニアみたいな概念とかもあったりしていて、 見直されつつあるなっていうところはあるんだけれども、 どっちにしても重要なのが事業にいかに向いているかみたいなところで、 そこから逆算してそれをテクノロジーで解決していくか、 チーム作ったりとか、いわば他の人たちを巻き込みながら作っていくかみたいなところの差があるから、 それは自分自身どっちにチャレンジしたいかみたいなところで選んでいくのがいいんじゃないかなと思っているかな。 なるほど。 実際、キャリアとしてスペシャリストに昇格した人とかもいると思うんですけど、 昇格するエンジニアっていうのはそういう事業に向いて、 事業を考えて報道できる人っていう感じなんですかね。 そうだね、事業に向くってちょっと抽象的になると思っているんだけれども、 これ逆の質問になってしまうんだけれども、 事業を向いて技術で解決していくみたいなところになったときに、 KEY君とかも一緒に昇格した人たちと働いているわけじゃん。 どういう活躍しているように見えている? そうですね。 一つは方向性を決定するというか、 例えば負債とか技術的負債とかは、 プロダクト開発では発生すると思うんですけど、 そういうものに対しての対応とかをリードして開発していくとか、 あとは外部登壇とかを積極的にして、 そういう姿を見せていって、 他のエンジニアに何て言うんですかね、 他のエンジニアに巻き込んだりとかね。 という感じですかね。 でも結構一つの方向性とし合っているかなというふうに思っていて、 テックリードはVoiceだと4種類あるなというふうに整理をしているんだけれども、 一つがアーキテクトがうまいとか、 アーキテクチャの知識が深かったりとか、 そういうところとかが1点と。 あともう1個がいわゆる開発力。 その人だけで他のエンジニアよりも10人ぐらいのパワーがあるみたいなところとか。 もう1個がいわゆる解決力。 あらゆるものとかをうまく使いながら、 解決に導いていくみたいな、 そういうところがうまい。 あとはいわゆるDevOpsとか開発性させ上げる。 エネブリメントしていくみたいなイメージなんだけれども、 他のエンジニアの人たちとかがより開発が速度が上がるみたいな話とかがあるかなというふうに思っていて。 なのでそれぞれ一つしかできてなくてもVoiceの場合は評価されたりもするんだけれども、 それはやっぱりアーキテクトは例えば他のエンジニアの人たちとかがめちゃくちゃ開発しやすくなるし、 将来開発の速度を上げたりとか、 機能を開発しやすくできるみたいなのもできたりとかもするので、 基本的にはその事業に向くっていうところ、 技術で解決するっていうところの裏側には、 10Xエンジニアとかって聞いたことある? なんか最近知られてますけどね。 これは1の部分を10とか100とか。 やっぱり技術があれば、今AIとかもうまく使えば、 そこをどんどん先継ではなくて、 指数関数的な形で強くしていくみたいなところもできると思っているんだけれども、 それをもう少し深まったときにアーキテクトをうまくやるとか、 開発性・産生性を上げてイネベルメントするとか、 いろんな技術を得意だからすぐ解決策を取ってくるとか、 誰よりも10倍アウトプットを出せるとか、 っていうような形で、 他のエンジニアとかも刺激しながら、 10Xをいかに作っていくかっていうことは、 結構ボイスでは重要視していて。 なので、スペシャリストを目指すって言っても、 結構いろんな種類があったりとかするから、 そこはKey君の好きなところというか、 自分自身ができるなっていうところをすごく大切にしたいのが、 うちの文化なんで。 選んでいけるといいんじゃないかななんて思ったりしてます。 ありがとうございます。 # 勉強時間は就業時間に入れられるのか？ 2つ目の質問ですが、スペシャリストやマネージャーと言いましたが、そういうキャリアアップをするには、いろんな技術のキャッチアップやどういう方法があるのかが必要だと思うんですが、そういうのを学びたいとき、どこまで業務内でやっていけばいいのかなと考えていて、そこはどう考えていますか? 業務内で勉強時間を取るんだっけ、勉強時間で勉強していいんだっけ的なやつね。よく世の中で話題になりがちではあるけれども、最初Voicyのスタンスみたいなところで話しておくと、あんまりちゃんと決めていない感じで、結構だって業務内でやることもあるし、勉強みたいな。 新しい技術のキャッチアップ。やってることもあるかなと思うし、逆にキリくん土日も勉強してたりとかもあるでしょ、好きな技術とか。 そこってそんなに制限しても仕方ないかなというふうには思っています。ただ、絶対に勉強時間を修行時間につけるなっていうのも違うと思っていて、どちらかというと大事にしたいのは価値を出すために、自分が何をキャッチアップするかっていうのを整理しながら、 それをうまくキャッチアップして、成果で繋げてくれば何でもOKという感じかなと思っています。 なので、Voicyとして投資しているところとかは、書籍購入制度。本買って、キーくんも今、輪読会とか仲間とやってみたいな。今何の本読んでたっけ? 今はクリーンアジャイルを読み終わったところです。 読み終わった?ちょうど読み終わったのね。 ちょうど読み終わりました。 それもね、みんな書籍購入制度で買って読んでるし、修行時間内でやってるし、あとはカンファレンスの参加費用みたいなのもちょうどこの前、制度として入れたりとかしていて、 なのでそういう時間も業務時間つけてみたいな状態も最近アップデートできたしみたいな。 ただ、これのいわゆる方法論よね。どうやって効果的な学習をしていくかみたいなのって。 そこは難しいですね。 キーくんとかどう考えてる? そうですね。結構自分の興味ある方向性と今やってることは結構合ってるので、そこはちょっと運がいいというか。 趣味とか業務でも読む本と興味ある本なんで、それを読めてるんで、興味あった方が効果的に勉強できると思うんで、そこは大事かなと思います。 素晴らしいですね、確かに。それは確かにそうで。 ちょっと最初の話に戻ってしまうけれども、なぜボイシーそういうスタンスを取ってるんですかというと、 資格時間、資格勉強時間とか取ってやらされ感があって、絶対身につかないんじゃないかっていう風にも思っているので、 どちらかというとボイシーはミッションベースでいろんな技術にチャレンジするみたいなところとかは考えてアサインはするようにはしていて、 キー君は今AIのところ。 そうですね。 AIも。 キャッチアップして。 おもろすぎるよね、あれ。 おもしろいですね。あとなんか朝会の後とかにもみんなでキャッチアップしたやつと共有しようみたいな会話があったり。 そうね。定例で今日は何があったっていうのを常に振り返る。 今日というか昨日。 そういうのも楽しんで興味が出るみたいなところとか、結局新しい技術を身につけていくのが好きじゃないとなかなかエンジニアとしても成長していかないし、 内発的な動機どうやって刺激するんだっけみたいなのはボイシーの組織としては大事にしていたりするので。 なのでキー君はもう就業時間とかとりあえずこだわらず仕事中も勉強していいし。 価値を出していれば? 価値は出す。しっかりそこは見るっていう。 しっかり価値を出していれば勉強っていう。 ほんとずっと知らなくないみたいな。 勉強してるだけじゃないとダメだと。 それはね。 ちゃんと価値を出してるから。 全員プロフェッショナルだと思っているので。 そうですね。 そこはそれでそういう会話をさせてもらうっていう感じかな。 はい。ありがとうございます。 # 会社の方針で開発ストップ、受け止め方は？ 3つ目なんですけど、Voicyってまだスタートアップだったので、開発を行っている中で方針とかが変わって、開発したものがリリースされないとか、公開取り下げるみたいなことがあると思うんですけど、 そういう時にせっかくここまでやったのにっていう気持ちになることも多少あるかなって思うんですけど、そこはどうしたらいいんですかね。 どうしたらいいみたいなところで、イメージでいうとどう考えたらいいみたいな感じですかね。 そうですね。結構熱意をかけて開発機関をかけて開発してきたものに対して、それをリリースできないと言うとちょっと青春的に、 せっかくここまでやったのになってはならないと思うんですけど、どうその気持ちを処理して考えればいいんだろうなっていうのは思ってますね。 これはそうだよね。めちゃくちゃわかるよね。なんかずっしり来るものもあるよね、実際のところ。 でもいわゆるまず頭の整理の部分とかはすごい大事だなっていうふうに思っていて、例えば何事もチームでやってて失敗があったりとか、 アジャイルとかスクラムみたいなのを開発してると振り返りみたいなのもあったりすると思うんだけど、 それってエンジニアが障害を起こしてしまうみたいなところとか、そういったところを含めて何かがうまくいかなかったときって成長のチャンスになる。 伸びしろやん、伸びしろみたいな感じだから。だからいわゆるKeptとかよく言われてるKeep Problem Tryのところとかで、 伸びしろもあるし、そのプロジェクトを進めて良かったこともたくさんあると思うんだよ。 だから何が良かったんだろうっていうところは改めてそういうとき振り返るといいし、それがまた自信につながったりとかもするから。 チームとして強くなってるよねみたいなところとか、これを機にどこに気づきがあったんだろうとか、 その気づきをどう次アクションしたらより良くなれるだろうっていうところをしっかりとチーム、 あと自分の頭の中で繰り返していくってすごく大事かなっていうふうに思っていて、 それをしっかりできると今回の感情の血肉が次につながるっていうふうに。それも必ずそうなんで。 もちろん感情面でいろいろ思うこととかも出てくると思うんだけど、まずはそれを一旦俯瞰して頭の中で整理する。 やっぱりチームのプロセスとか、このプロセスとかには入れるべきだと思うし、 孫石もそういうような形で、なるだけこういうことを考えた系のところでこういうことを考えてますもそうだし、 プロダクトとしてはこういうことできるよねみたいなところとかは話すようにしたりしてるかなっていう。 そうですね、確かに。 結構やっぱり大きい風害とか影響の大きい風害とか出したときは感動的に打ってられたからあるんですけど、 ちゃんとポストモーティングしてエンジニア全体を振り返ったりするところは大事かなと思ってます。 やっぱり会社の方針とかスタートアップだからこそいろいろぐんぐんぐんぐん変わるみたいなこととかは全然あったりするので、 このときにお互いエンジニア以外のチームとかもいろいろ考えながらもそれで進んでる中で、 何かうまくいかないことがあってストップしてしまってるっていうところではあると思うんだけど、 これに対して変に社に構えたりとかせず、素朴な疑問のところとかは言ってほしいし、 むしろ自分がより良くしていくんだみたいな形で、 エンジニアチーム以外のところとかでもこういう風に思ってますよみたいなところとか、 うまく伝わるコミュニケーションとかを意識してくれると嬉しいなという風に思っていて、 エンジニアを作るところに注力しがちではあるんだけれども、 会社としてなんでこういう風に起こってしまったんだろうというところとか、 会社を守護にしたときとかになぜそうなってしまったんだろうみたいなところとかの視点で考えられると、 より同じ気持ちで会社のことを問われることができるから、 なんかそれはこう、なんだろうな、なんかモヤモヤするなみたいなものとかも、 あるいはうちだったら尾形さんとかもめちゃくちゃ距離も近いから、尾形さんとかに聞いてみたりとか、 それだけでも感情のところの部分も変わるし、会社の視点も身につくし、 やっぱ難しいんだよね結局。難しいからこういうことが起こっちゃうっていう話ではあるんだけれど、 そんな簡単な事業をやってるみたいな感じでもないんで、 だからこそ自分自身でよりよくコミットツーチームしていくみたいなのは、 意識的にはすごい重要かなと思ってます。 確かに。ちゃんと整理して、 あと今言ったことって結構最初の方に話した事業に向くエンジニアっていうのもちょっとあるかなと思ってて、 そこは大事なんだなと思いました。 これはエンジニアが一番上手いですから、振り返り。 エンジニアってレビューされるじゃん。レビューされるって最初つらいってよく言うじゃん。 行動を否定してるのであって人格を否定してないっていう、 感情の分け方ってエンジニアが多分俺一番上手いと思っていて、 だからこそこういう時にエンジニアが主導して振り返りの雰囲気を作っていくみたいなのはすごい重要だと思ってたりもしてるかな。 なんでキー君も期待してます。 ありがとうございます。頑張ります。 頑張っていきましょう。