新しい領域への挑戦を続けて成長するために必要だったソフトウェアエンジニアとしての「軸」とは

新しい環境に挑戦し続けたからこそ、エンジニアとしての「軸」を手に入れられた

ソフトウェアエンジニアがキャリアについて考えるときに、自分の好きな技術や得意なスキル、あるいは興味ある事業ドメインをもとに次を選択することがあります。とはいえ専念したい技術領域がすぐに見つかるというものでもないでしょう。得意分野が見つかるまで自分を成長させることも大切です。

柴﨑優季@shibayu36さんは開発者として12年間を、toCのコンテンツプラットフォームに始まり、toBのSaaS事業、現職のメタバースプラットフォームと、転職ごとに異なる事業ドメインを選択しています。担当する技術領域や職能も幅広く、選り好みすることなく経験を積んできました。

ただ次々とチームを移り変わるだけでは、次につながる知識を得ることも難しいでしょう。技術や職能にはこだわらない代わりに、一貫した軸をもって開発にあたってきた柴﨑さんに、新しい環境での仕事で意識することや、どのように技術を磨いてきたか、そして見つけた得意領域の話などを伺いました。

「エンジニアリングで課題を解決する」を続けてきた

── 柴﨑さんはこれまでに、一般ユーザーが利用できるコンテンツプラットフォームから、特定の業界に向けたバーティカルSaaS、そして現職がメタバースプラットフォームと、事業ドメインが異なる会社に在籍されていますが、働き方にもかなり変化があったのでしょうか。

柴﨑 そうですね。事業ドメインだけでなく、担当する職務もどんどん変わりました。新卒入社したはてなでも、最初にプラットフォームのチームで通知システムの開発を担当し、ブログサービスのエンジニアからPM(プロダクトマネージャー)になり、小説投稿サイトの立ち上げにも携わりました。技術スタックもインフラからサーバサイド、フロントエンドまでさまざまな領域を経験しました。

── エンジニアリングだけでなくマネジメントや新規ビジネスまで、幅広く経験されていますね。何らかの技術のスペシャリストとして特化するキャリアは考えなかったのでしょうか。

柴﨑 特定の技術領域でスペシャリストになるエンジニアや、全てを技術力で突破していくすごいエンジニアへの憧れは確かにありました。ただ、それは僕の性質とは違っていて、自分はどちらかといえば目の前の課題をエンジニアリングで解決することに楽しさを感じるタイプだったんです。

そして新しい課題に取り組むことも、そこで得た経験を違った課題で生かすことも楽しかったですね。そういった楽しさを追求していたら、いつの間にか広範な職務や技術を経験していた感じです。

── 職務が変わるごとに新しい課題に挑戦することになるわけですね。

柴﨑 目の前にある課題の解決策は、その時々で変わります。バックエンド側で解決すべき課題もあれば、フロントで解決した方がいい課題もあります。課題解決のための一番いいやり方を毎回模索していくと、自然と多様なキャリアを積むことになりますね。

── そうした柴﨑さんのキャリア観はどのようにして生まれたのでしょう。ロールモデルとなるエンジニアがいたら教えてください。

柴﨑 やはりエンジニアとして最初の先輩の影響は大きいですね。はてなには入社前からアルバイトもしていましたが、同じチームに伊藤直也@naoya_itoさんや、antipop(栗林健太郎、@kentaroさん、大西(康裕、@yasuhiro_onishiさんがいたことがあります。まさに「そのとき問題になっていることをいろいろな手段を用いて解決していく」ことを実践している方々でした。

── 伊藤さんも栗林さんも今ではCTOを務めている方ですが、何か影響を受けたことはありますか?

柴﨑 naoyaさんは、パフォーマンスチューニングしたいときにOSの仕組みから理解するとか、いちから勉強する方でした。問題解決のために技術を深掘りする姿勢には感じるものがありました。

あんちぽさんには、ひたすら「何とかなるからやってみろ」と言われた記憶があります。やれそうなことは一回やってみたらいいじゃないかという考え方は、今につながっています。

新しい環境ではプライドを捨て、常に「新人気分」で臨む

── 転職の際だけでなく同じ会社でも新しい領域に挑戦してきたということは、新しい知識を学び直すことも多いでしょう。リスキリングは簡単なことではないと思いますが、どのように自分自身を成長させてきたのでしょうか。

柴﨑 常に意識していたのは「いつでも新人気分で臨む」ことです。例えば新しいチームに入ったり、これまでやったことのない領域に行ったりすると、正直自分より社会人経験の浅いメンバーよりも仕事ができないところからスタートするわけです。

そうした状況で変にプライドを持って自分のやり方に固執したり教えを請わなかったりすると、自分の成長も遅くなってしまいます。僕は新しい領域やチームに入るたびに積極的に質問して、知識を吸収するようにしてきました。

ただし人に聞くだけではだめで、聞いた話の中で分からない単語が出てきたら、単語の意味を調べるくらいなら自分でできますよね。どんどん質問する、そこで出てきた単語や要素については関連する本を読んだりして、自分の中で整理して腹落ちさせる。この流れが大事だと思っています。

── 自分の中で整理するとは具体的にどんなことでしょうか。

柴﨑 アウトプットが大事だと思っています。アウトプットにもいろいろな方法がありますが、僕はひたすら技術ブログを書いています。自分で言語化できないことは、本を読んだりして分かったつもりでいても、実はぜんぜん理解できていないんですよね。だからとにかくブログで言語化してきました。

やはりアウトプットすることは重要で、プログラムに落とし込んでみるのも立派なアウトプットですし、学んだことをチームで実践してみるとか、何でもかまいません。自分の得意な形でアウトプットし続けること。それがエンジニアとしての成長につながるはずです。

そうやって身に付けた技術や知識は本当の意味で自分のものになるので、領域が移っても生かせることがよくあります。例えばデータベースのパフォーマンスを深掘りしていたときに書いたブログが、その後の障害対応や改善に役立ったことがありました。

参考:MySQLをさらに理解するために読んだ記事まとめ - $shibayu36->blog;

自分の得意や苦手を言語化しておくと適した仕事も分かる

── 新しい領域に挑戦していると、中には自分に合わなかった職務もあったのではないでしょうか?

柴﨑 それはやはりありましたね。はてな時代に経験したPM(プロダクトマネージャー)などは、自分には向いてないなと思いました。といってもチームメンバーの目標を設定したり、1on1などを通して組織をマネジメントしていくことは好きだったんですよ。

── 目標設定などもマネジメント業務の1つだと思いますが、向いている・向いていないの違いはどのあたりにあったのでしょう?

柴﨑 先ほどから話しているように、課題としてはっきり見えることをあらゆる手段を使って解決することは好きです。また、曖昧な課題から何が問題なのかを明確にして、解決策を導いていくことも苦手ではありません。むしろそれも好きで、メンター制度の改善なども「今の制度がメンバーの成長に役立っているのか分からない」くらい曖昧な粒度の課題でしたが、楽しく取り組んできました。

参考:エンジニアメンター制度の効果的な運用を目指して/improve-mentor-system - Speaker Deck

苦手だったのは、肝心なプロダクトマネジメントの領域です。状況が不確実な中、一歩踏み込んでサービスやプロダクトの方向性を決めることがどうしてもできなかった。曖昧な課題を明確に言語化できず、自信を持ってチームに説明できなくなってしまった。組織や人に対する曖昧な課題は見つけられるのですが、プロダクトの舵取りは難しかったですね。

── マネジメントの業務でも得意とする部分と苦手な部分があるということでしょうか。

柴﨑 そうですね。いろいろな部署の関係者との会議で1日が埋まるみたいな状況も苦手でした。ただ、PM(プロダクトマネージャー)の経験で苦しんだことも今では役に立っています。エンジニアの立場では、PMの発言を「なぜそんなことをしなきゃいけないんだろう?」と理不尽に感じることもあります。

一方でPMからすると、そう言わないといけない事情があるんですよね。PMだってネガティブな反応は受けたくないし、怖いです。でも伝えないといけない。PMとして業務を経験したからこそ、そうした気持ちが分かります。今の僕はエンジニアとしてPMに接することが多いので、言葉の背後にある狙いや思いについて丁寧にコミュニケーションして、チームがいい雰囲気で仕事できるように心がけています。

── 両方の立場を経験しているからこそできることですね。

柴﨑 はい。これまでさまざまな領域や職務で得てきた経験が、そうした場面で生きていると思います。いろいろな知識を持っていると、相手の立場で欲しい情報を提示しやすく、やりたいことを提案したときに、賛同してもらいやすいんですよ。

── 実際に経験している人の意見は説得力が増しますよね。ところで苦手な仕事に対してはどうモチベーションを保っていたのでしょうか。

柴﨑 僕は苦手な仕事の中でがんばってモチベーションを上げていけるタイプではなくて、もちろんベストは尽くすのですが、それでも難しい場合は会社に相談して別の職務に移してもらっていました。幸い、これまで勤めてきた会社はどこもエンジニアのモチベーションを大事にしてくれたので。

ただ、そのときに職務や業務の中でどの部分が自分に合わなかったのか、どこなら好きだと思えるのかについては、しっかりと言語化して分析していました。そうすることで、好きになれる仕事に出会える可能性がどんどん高まるからです。自分の場合は、大まかな方針として決定したことに対して段取りを組み、どうすれば効率よく達成できるかを考えるのは大好きだと分かりました。

新しい領域に挑戦して分かった強みを深めていきたい

── 新しい職務や技術に積極的に取り組んで成長するお話を伺ってきましたが、その中でも変化が大きな転職という選択についてお聞きします。異なる事業ドメインに転職するモチベーションは何でしょうか。

柴﨑 最初の転職では、全く異なる事業ドメインに移ることで自分の目線を多角化したいと考えました。新卒で入社していろいろな経験を積むことができましたが、他の職場を知らないので、それまで積み重ねてきた技術やキャリアが他の環境でも通用するか、活躍できるのかが分からなかったからです。

── どんな職場でもよかったわけではないと思いますが、転職において大事にした軸は何でしょうか?

柴﨑 やはり自分が得意とする「課題をエンジニアリングで解決する」ことにはこだわりました。逆にそうした役割が担えるなら、事業ドメインや技術領域は問わなかったとも言えます。それからワークライフバランスですね。仕事も好きですが、一番大切なのは家族です。あまりにも忙しいと家族との時間が取れません。仕事にも打ち込みつつ、プライベートも大事にできる環境であることを重視しました。

── 実際に異なる事業ドメインに移ってみてどうでしたか?

柴﨑 前職ではとくに意識していなかったけれど実は大事だったという軸がいくつかあることに気づきました。例えば自分はバックエンド側の技術が好きなんですが、意外とバックエンドエンジニアだけで働くより多職種混成、フロントエンドエンジニアやデザイナー、それこそセールスまで同じチームにいる環境の方が好みだということです。また、プラットフォーム寄りで仕事をしていてもユーザーの顔が近くで見えるサービスを開発すると楽しいということですね。

── ユーザーが見えるサービス開発については、現職に移る際に「クリエイターを応援したい」とブログに書かれていましたが、現在は実際にどういう働き方をされていますか。

柴﨑 今の会社では、どんなデバイスでも遊べるメタバースプラットフォーム「cluster(クラスター)」を開発・提供しています。clusterはサービスの中でイベントを開催してユーザーと直接コミュニケーションすることも多く、お客さんとすごく近いサービスだと感じています。

サービスの機能として、バーチャル空間の中でクリエイターがさまざまなコンテンツを作って公開できるだけでなく、ユーザー同士がSNS的なつながりを持ってコミュニケーションを取ることができます。その1つとして「写真を投稿してタイムラインとして表示する」機能があり、僕はサーバサイドエンジニアとして、機能に必要なAPI開発やパフォーマンスに問題が起こらないような設計を担当しています。

── 今後、エンジニアとして目指したいことや展望について教えてください。

柴﨑 これまでいろいろな職務を経験してきましたが、自分の強みも分かってきたので、これからはもう少しいくつかの職務で強みを深めていきたいと思っています。クラスターにはいろいろな職種の人が同じチームにいるので、自分と違う専門領域は強い人に任せることもできますから、僕は僕でバックエンドの難しい部分をちゃんとできるようになっていきたいですね。

とにかく今はチームの一員として、いろいろなロールの人と一緒にプロダクトを成長させられるエンジニアを目指していきたいと思います。特にチームのマネジメントや開発プロセスの改善にも興味を持って取り組んできましたから、その中でチームを活性化させるような役割も担いたいです。

── 最後に、新しい環境でどのように成長するかについてあらためて聞かせてください。

柴﨑 新しいことに挑戦するのは不安な人も多いと思います。ただ、先ほどお話ししたように、新しい環境に入ったら怖がらずにどんどん聞いていくことが大事です。分からないことは分からないと発信した方が、その後でスキルが身に付くスピードも段違いに早くなると僕は思っています。

また、仕事をとりあえずこなしているだけになると、そこから得られるものはありません。その仕事に興味が持てなくても、例えば隣接領域からキャッチアップすることもできます。僕も隣接領域について学んだ経験が、後から役立つことがよくありました。

── 意識して学ぶ姿勢が大切ですね。本日はありがとうございました。

柴﨑さん近影

取材・構成:山田井 ユウキ@cafewriter
編集・制作:はてな編集部
写真はすべて柴﨑さん提供