入社後10年の節目に

はじめに

2012年2月20日に現職に就職してから10年が経ちました。だからなんだと言う気もしますが、ある種の節目として何かを書いておくこともまあ大事かなと思うので書こうかと。学会云々の話だけが書かれてるnoteというのもいかがかと思うし。

10年前から思えば、よく10年生き抜けたなあというのもありますが、ここ数年は生き抜くだけならそこそこ楽、という思いもあります。この辺の感覚もどう変わっていくのかなあというのは楽しみでもあり、怖くもあり。思い起こせば現職に就職するきっかけなんかもちゃんと書いた記憶は無いですし、それらも含めて一度整理しておこうかと思います。

とか言いながら年始にちょくちょく書き始めたんですけど、書いていったら思いの外長文になってしまいました。かといってなにか実りのあることが書かれてるわけでもないです。おんなじようなことを繰り返してるところもあります。

あと、なんか期待してる人もいるかも知れないので最初に明確にしておきますが、退職エントリではありません

転職前後の話

転職前の状況

修士課程の修了後、2009年の4月から日立製作所中央研究所に新卒として入社して働いていました。決して優秀ではなかったと思いますが、その理由も当時はうまく言語化出来ませんでした。今なら少しは理解できるのですが、ざっくり言えば「自分が何がやりたいかがわからないし、何がやりたくないかもわからない」「何を求められているかもよくわからない」という本質的にどうにもならない状態であり、その中で目の前のノルマであるところの研究報告書とか特許をこなしていました。こなせていたのかもよくわかりませんが、周りに助けていただいて数字上はなんとかという感じでしょうか。この辺については後でもう少し書きます。
約2年が過ぎた2011年の年明けあたりは2つの大きなイベントがありました。1つ目は会社の二年目の社員が全員経験するという「研修員発表」という仕組み、もう一つは3月11日の東日本大震災です。
研修員発表というのは、2年間の成果を事業所全員の前で発表するというイベントで形式は事業所によって異なるのですが、我々は確か1−2ページの予稿と15分くらいのプレゼンだったかと思います。ボリューム的にはその程度は大したことないし、普通に誰でも卒論やらなにやらでやったことがあるとは思うのですが、事業部長レベルも見てコメントをするということもあり、指導員→課長→部長→センタ長(本部長)といった数々のチェックを段階に分けて通さなければならないというのが大変でした。特に僕にとってはそういうのが極めて苦手であるというのを自覚させられる時間であり、苦しかったですね。
今から思うと僕はこの発表の意義というのを誤解していたように思います。日立ではこれは教育の一環だと言われていて確かにそれはそうなのですが、「偉い人のチェックを通すための文章の書き方」の教育だと認識していたんですね。確かに最終的にはそういう事にもなるんですがちょっと違う。後でもうちょっと書くのですが、そもそもこの過程で作られたものの文責が僕になるという意識に欠けていたように思います。

東日本大震災については、当日に同期と寮まで歩いて帰ったことや、何故か定時まで建物の外で待機したことなどをよく覚えています。待機中は寒かったので、配られたアルミにくるまっている人などがいました。なんだったか、とりあえず上長の指示を仰ぐんだということで何度か携帯にかけたのに繋がらないーと言ってるのを横目で見ながら、何もすることがないなあと考えていました。
当時は辻堂の寮に住み戸塚の事業所に通うという生活だったので、片道15キロくらいはあったんじゃないかと思います。今ならいい感じのランニングのトレーニングになりそうとか思うのかもしれませんが、なんの準備もしてないのはもちろんのこと突然の震災なので、まあこの辺はしょうがないですね。あんまりリアルタイムのニュースなんかも見れなかったので、津波の話なんかも翌日以降に知りました。
当時はあんまりツイートもしてなかったようで、調べてみたけど特にツイートが残ってなかったですが、僕はどうやって生存報告してたんでしょうか。記憶にないです。
辻堂の寮の近くに着いたときにすぐ近くにあったデニーズに入りました。その時の店員さんが可愛かったなあ、とその時は思ったんですが、歩き疲れてみた幻影かもしれません。そのあと何回かデニーズに行きましたが、記憶にある店員さんに会うことはできなかったです。

それはさておき、当時は研究職ということで基本的にはサーバーのファームウェアに関係する研究開発がお仕事でした。何しろ10年も経ったのでもう時効かもしれませんが守秘義務も一応あるので詳細は書きません。しかし立場としては「開発職」ではないのですね。なので、いわゆる製品開発を直接的に担う訳ではなく、「プロトタイプ作成」や「仕様書」が最終的な成果となる感じですね。そこに至るまでの特許や研究報告書、論文なんかも成果になりますが。とはいえ数ヶ月だけ事業部に派遣(正確な表現はわかりませんと断っておきます)される事により、開発する経験をしました。これは既に退職も決まった後だったんですけど、とても楽しかったです。やっぱり僕は開発者のほうが向いてるなあとしみじみ思いました。

転職のきっかけと経緯

2011年4月28日にこんなメールがやってきました。

Hi Sawa-san,

My name is [リクルーターの名前] with Google's Engineering Staffing group. Your name and brief background came up when doing some research and I would like to speak with you about potential engineering opportunities within Google.

このメールをきっかけとして、履歴によればゴールデンウイークにメールを送ったりなんかしながら就職活動を進め、7/5と7/13に面接を受けたようです。これらの面接は平日だったのですが、当時は東日本大震災後の電力不足が原因で輪番休日という仕組みがあり、それらを利用することで会社を休まずに転職活動できました。
このメールを受け取った時点では、転職するかどうかは特に決めてなかったので(なんなら通過しても行かない選択肢もあった)、他の企業を受けたりすることは考えませんでした。
面接の質問自体は基本的なことを聞かれただけでそこまで難しいとは感じなかったと思います。もちろん覚えていても問題自体をしゃべることはしませんが。一問くらいヒントなしではすぐには解けなかったことがあったような気がしますが、うーんとホワイトボードの前で唸ったら解けたとかそういうのもあったような無かったような。ただ、すごく疲れたのを覚えています。45分間の面接を複数回やる訳ですからまあ辛いですよね。なんにしてもどうやら通過のボーダーは超えたらしく、その後リクルータから連絡が来ました。入社が決まったのは8月の後半であり、どうやら社内調整に1ヶ月半ほど時間がかかったようです。この間隔はすごく長かったですね。何度か「マダァ?(・∀・ )っ/凵⌒☆チンチン」とGoogleにせっついた記録と記憶が残っています。そしてそこから約半年後の2月に実際の入社となりました。これはまあ、プロジェクトの状態とか色々あったのですが、普通はこんなに間があかないものだとは思います。
12月くらいに現在の住居にも近い両国のマンションに引越しを行い、寮を引き払ったりしながら最終日を迎えました。短い間とはいえ、両国から戸塚に通うのとか、あるいは出張で小田急線の渋沢駅まで行くのはちょっと辛かったです。東海道線・横須賀線のグリーン車を使ったりもしながらなんとか耐えました。
ちなみにみんな大好きなお金の話ですが、お賃金はざっくり言えば前職との比較で3倍程度になりました。いくつかの噂なども勘案してみると、同等の役職だとすると課長くらいまでであれば額面で3倍程度、それ以降だと倍率はもっと上がりそうです。いわゆる福利厚生もアップグレードされたので、そういう点では完全に良くなりましたね。とはいえ、もちろん税金も増えるので単純に手取りがそれだけ増える訳ではないのですが。あともう一個思い出したお金の話としては、前職の退職金はほとんどなかったと思います。確か3年未満で自己都合の場合にはほぼ0って書いてあったような記憶がうっすらあります。

転職直後の環境

ということで、2/20というとても中途半端な日の入社でした。こんな日に入社するやつは他にいないだろうと思っていたら、知り合い(twitter:@ainsophyao)がいました。彼が入社することも知りませんでしたが、同日入社とは超意外でした。
入社時点では基本的に新卒と同様の待遇として入社となってました。後から考えるとこれはすごく良かったです。給料的にはもちろん中途入社待遇の方がだいぶ良いのですがその分期待される中身も大きいですし、何より新卒待遇の時点で一番期待されていたのはコードを書くことです。たくさんのコードを書く事にかけてはそれなりに自信があったし、何より書けば書くだけ評価されるというのはとても幸せな時間でした。

入社後に最初に配属されたチームでは、とあるモバイルアプリを作るチームでした。このアプリは結局日の目を見ることが無かったものなので、詳細について述べることは出来ません。このチームで学んだことは結構今も生きています。一番衝撃を受けたのは、別のチームの人とのコミュニケーション方法ですね。世間的にはこんな感じの図がよく知られています。

各社の組織図のイメージ

僕の中では、さらに末端間でのコミュニケーションがちょっと衝撃的で、結構勝手に個人が動くという印象です。例えば僕がプロジェクト上使うライブラリを管理しているチームがニューヨークにあるとして、そこでサポートされてないユースケースがあったとするじゃないですか。その時Googleだと僕はいきなり先方に変更の提案をします。先にDesign docを送るかいきなりコードを送るか、あるいはメールで質問を投げるか等は人や状況によると思うのですが、少なくとも自分や先方の上司に事前にお伺いを立てたりは滅多にしないんですね。これは僕が前職で下っ端であったことも大きいとは思うのですが、各人に与えられてる裁量がだいぶ大きいなと感じました。
それ以外だと、世間ではもう当たり前になってる概念が大量に使われてました。CI/CDくらいは当時から言われてはいたかもしれませんが、それでも当時に全社規模で走らせてる企業は少数派だったと思いますし、コンテナの概念もborgとかで使われてたし。
社内のcodelabと呼ばれる各分野の入門ドキュメントがいくつかあって、それをこなしてなんとなくツールのことを理解していく、というのもよかったですね。社内の技術がかなり標準化されていることを意味していますし、よく知られているようにシングルレポジトリで他のチームのコードが読めるという点があるからだろうと思います。
このあたりの話はSWE本でもっと詳しく書かれているので、興味のある人はそっちでお願いします。

最初のチームにいたのは半年くらいで、その後Google Mapsのチームに拾われてからはずっとGoogle Mapsに関わっています。

そうそう、最初のチームの人達の多くはもうGoogleをやめていて、現在F社にいるようです。もちろん一部はまだGoogleで仕事をしています。

Google Mapsでの仕事

殆どの時間、僕はAndroid版のGoogle Mapsに関わっています。直近で大きくチームが変わる予定は無いので、もうしばらくはこのままやり続けるのではないかと思います。
Androidアプリ開発はそんなに興味があったわけでもないですし、別にこの会社でやらんでもいいのでは、と思っていました。ほら、大量のサーバーリソースとかとはあんまり関係なさそうじゃないすか。別の小さい企業でも同じようなことをやってそうというか。これは半分はその通りで、半分はちょっと違うかなという感想ですね。バックエンドシステムの制約を吸収する仕組みが必要であることもあるけど、単なるAndroid固有の問題はStackOverflowを見て解決することもある。
そういうわけで、本質的にはAndroidにそこまでモチベーションがあるわけでもないのですが、これだけ長くやってるとそれなりに愛着も湧くし、ドメイン知識やらハマりどころの知識なんかもついてくるので、なんとなく続けています。

小さ目のチームの変更自体はそこそこ頻繁にあって、例えば上司が変わったりとかテーマが変わったりとか、一時的にwebフロントエンドを触ったりとかそういうのはありました。作ってたものをもう一回焼き直す、のようなプロジェクトもあったし、ひたすらUIのスタイルを変えるだけみたいなのもあったし、今まで他のアプリでは使われてなかったUIフレームワークを作ったこともありました。その後似たようなUIフレームワークで作られているアプリを見てニヤニヤしてたりします。

今から思えばすごく昔の話ですが、2014年エイプリルフールのポケモンなんていうのもありましたね。とはいえこれはもう知ってる人も減ってきたんじゃないですかね。

チームの中で期待される役割も良くも悪くも変わってきました。多分。初期には担当部分をひたすら早く実装することが第一の目的でしたが、他のチームを助ける仕事だったりとか、チームメイトが穴に落ちる前に気付く仕事とかも増えてきたし。

そこそこ技術負債も残していますが、一方で他人に押し付けた技術負債よりも他人から引き取った技術負債の方が多いと思います。多分。プロジェクト移管の時にはある程度は綺麗にしてから渡すというのをちゃんとやってきてると思ってるんですが、この辺は他の人からどう見えてるかの方が大事ですね。まあそもそも会社をやめていく人がそれなりの割合でいる以上、残ってる人は技術負債を返す方が多くなるでしょ、というのはあるとは思うんですが。

現職での成長

英語

弊社のコミュニケーションは基本英語です。上司が日本人じゃない期間もそれなりにあるし、チームメイトも大半は日本語ネイティブではないです。少なくとも仕事の話を日本語でできる人たちは会社では少数派になります。
いわゆる英語力はついたとは言い難い一方で、コミュニケーションはマシになったのかなあと思います。もちろん単語や何やらを多少覚えたのはありますし、発音の練習なんかも多少しましたが、「コミュニケーションの責任者を明確にする」ことで乗り切れるようになったんじゃないかなと思います。

もうちょっと書くと、僕は少なくとも各話題について、「誰が困るのか」を考えながらやりとりしています。もしそれが、相手が困ることなのであれば、それを言語化して伝える責任は相手側にあります。なので僕としてはあくまでベストエフォートとしてやればよくて、たとえそれが僕の英語力の欠如が原因であったとしても、伝えきれないのは相手が悪いと考えて問題ないわけです。もちろんベストは尽くしますし、相手が望むなら何時間も使ったりもします。が、それでも最終的に僕に問題を理解させるのも、例えばその結果僕の解法を相手が理解するのも、基本的には相手の責任です。

一方で、僕が困る問題については、僕は最大限の力を使います。相手が異なるタイムゾーンにいるのであれば深夜までだって起きるし、出張にも行きます。ミーティング前に説明の練習をしたりもしますし、可能な限り事前に文章化して間違いがないようにします。本当にここに注力します。それでもどうにもならなかったら日本語がわかる人に相談もします。別に英語力自体を問われることはないわけで、解ければ勝ちです。

あと誰も困らないってパターンも結構あります。そういうのは適当に聞き流しておけばいいわけです。暇なら聞くけど、まあどうでもいいことがほとんどですね。

こうして書くと、本当に頑張るべき英語なんて少ないことがわかります。送られているメールや参加した会議の発言、全てを最初から理解する必要などないのです。というつもりでやっているのでいつまで経っても英語のレベルが上がらないんですよね、というオチでもありますね、これ。

もう一点。弊社を含めたベイエリアの最近のカルチャーでは、英語の下手さ(発音含む)は減点に使ってはいけないことになってます。

そこまでたどり着きながら英語を自分達のものだというところは決して譲らないアメリカという国に思うところは腐るほどあるのですが、それはそれとしてこういった様々な環境で僕のクソみたいな英語であってもそんなに気にしないでやっていけます。

あ、ここまで英語を適当にしかやらない理由を並べましたけど、これらはあくまでちゃんと意思疎通をしようという気持ちが十分にあることは大前提です。一応、意思疎通をしようという気持ちだけは持っています。

あとは、このエントリを書くきっかけにもなっている在職10年というのもあって、最近だと忖度してもらってるような気もします。ありがたいことです。英弱としては、そういうのも遠慮なく使っていく所存です。

プログラミング、設計能力

コードはまあまあよく書きました。コンスタントに一日数千行書いてる時期もあったと思います。ただまあこれは、高校3年生くらいからずっとなので、特にこの「コードを書き続ける体力」的なのはGoogleに入ってから増えた気はしません。むしろ年齢と共にちょっとずつ落ちてきているかなあ。意外だったのは、これくらい量を書けるというのはGoogleという会社の中でもそこそこアピールできる能力だということです。やっぱりコードを書かずに設計云々をごちゃごちゃ言うより、動くものをとりあえず出すというのはどこであっても強い。そこで問題があれば、さらに深い議論が出来るので。コードを書かずに設計議論をするのは、ちゃんとコードを書くことができるというのが大前提だと思うわけです。

英語の話も近いのですが、Googleのソフトウェアエンジニアの中では「困ったら自分でコード書いて解決しろ」的な文化であって、相手がコードを書けることは前提として話が進みます。なので、まずコードを書く能力が高いというのはあらゆることのスタートラインだと思います。例えば面接のスタイルやフォーマットもこの10年でもそこそこ変わってきていますが、この一点は一切ブレてないと思います。他のビッグテックはわかりませんが、未経験からエンジニアみたいなのをやるんであれば、何はともあれある程度の物量を苦にせずできるというのは大事だと思います。

思うところとしては、(Google Mapsとかいうバカでかいプロジェクトでは)ビルド時間がめっちゃかかる一方で、それなりに実機テストが容易なAndroidはコードをいっぱい書きながら動かしたい僕には結構合ってるのかなあという感じですかね。サーバーサイドとかも勿論テストはできるんですけど、ユーザーの直接的な体験はやっぱりクライアント側じゃないとなあと。

プログラミングに限らず、テストの方法論やトレードオフの考え方なんかも現職で身につけたと思っています。この辺は場数をこなせばこなすだけ身につくところありますよね。

エディタはvimです。Android Studio使わずに書いてる我はさすがに少数派になりつつある自覚はあります。でも別にそんなに不便を感じてないんですよね。脳内コンパイラは大体いい仕事するし。

文章を書くこと

文章書くことは入社時には少なくて、コードばっかり書いてました。昇進の審査の時にはdesign docなんかを求められることも多いのですが、それが無くて困ったことも多いです。この節の後ろの方で書きますが、そもそもなぜ書くかがわからないので書かなかったんですね。
しかし成長というか昇進というか、そういうのに従って書く機会も増えました。日立で指摘されたことが今生きてるなあと思うことも多いです。その一方で現職で初めて実感したこともあります。

あまりに当たり前すぎるんですが、僕は「自身の主張をする」ことと「フェアに書く」ことの両立というのがわかってなかったんだなあと思ってます。このわかってないというのは、単に出来てないということではないんです。何をしなければいけないかがわかってなかったんです。あるいは意思決定というものを理解してなかったとも言えます。

例えばあるデータがあったとします。この生データを用いることは大事です。捏造は許されません。まあ見やすいように加工くらいはしますよね。で、そこまで。だって僕はどっちでもいいんですよ。知りたいのはあなた(上司だったりリーダーだったり)ですよね。そのあと進む方向を決めるのは僕じゃないんですよ?頼まれればデータは提供しますけど。こういう感じの考えなんですね。
別の例として、ある技術課題があったとして、解決案が複数あるとします。そうするとそれを列挙します。それぞれのメリットデメリットくらいは書くかもしれません。これもそこまで。だって決断するのは僕じゃないんだし、そこの責任取らされても困るし、勝手に決めるなって思うでしょ。
ざっくり言えばこんな感じ。いや、もちろんそこで終わったりはしませんよ。でも言われたからやるという意識の延長上なんですよ。日立の時にも「おすすめはどっちですか」と聞かれたので、もちろんそれは答えるんですが、あくまで意思決定者に委ねるという立ち位置でした。

実は多くの場合、今から思い返せば自分が意思決定者だったんです。例えばプレゼンの発表内容。これは間違いなく自分の発表なんだから、誰がなんと言おうと僕が意思決定者なんです。でも他人の承認を得る必要がある→他人が意思決定者という思考回路だったんですよ。承認と意思決定者は別ということがわかってなかった。

言い訳をしておけば、この意識を強化する環境というのもあって、例えば日立だと書類の全てに上長の決済印が押されるし、GoogleのコードレビューでもreviewerのLGTMが乗っかるわけです。勝手はそんなに許されないわけです。研修に出ればうるさいように報連相の徹底を言われる。なので自分が意思決定をできる立場だとは本当に思ってなかったんです。

今はちょっと考えを改めました。意思決定者はどんな決定をするにせよ決定した結果を他の人達(これは更に上の上司だったり、別のチームだったり、あるいは部下であることもある)に説明して理解を得ることが必要である、と。たとえ社長が下した意思決定であっても、ちゃんとその意思決定を部下に伝えなければみんな動かない。表面的な理解だけ伝えても、おそらくチグハグに動いて、結果として空中分解する。そう考えれば、別に意思決定者が「偉い人」「承認者」である必要はない。結局みんなの理解を得ないと進まないんだから。

でも僕はこれに気付けなかった。というかこれ、みんないつどこで学ぶんですか?部分的には大学院とかなんですかね?
この概念ってそんなに自明じゃないと思うんですよ。でもこれを理解できたのは現職であって、それも明確に僕の中で言語化できたのはこの数年なんです。正直恥だと思うんですが、他にも同じような人達がいるんじゃないかと思うので、一度書いておくことにしました。

なんにしても、これを理解することでようやく全てが繋がったというか、日立で指摘されてたことの本当の意味がわかった気がしました。どうやったら伝わるか、あるいはなぜこれでは伝わらないか、みたいなことを言われ続けてたんですが、そもそも伝える中身が違ったんですね。テクニカルライティングみたいな話は何度も何度も指摘されたし研修も受けたんですが、僕が必要としてた話はまずそこじゃなかったんだなあという。こうしてこれを書いている裏ではTwitterでは論文の書き方云々が盛り上がっていて、そしてまあそれもよくわかる。僕も決してそこができてたわけでもない。ただ、それとは直交した概念としての「仕事の進め方」はそれはそれで必要で、これがようやくおぼろげながらわかってきた。

これがわかるようになると、書くべき内容がクリアになった実感があります。そもそも承認を得るというのはあくまで同意を得ることでしかなくて、必ずしも上下関係とかそういう話ではない。間違った意思決定をして僕が困らないようにアドバイスをしているだけである、という(マウントを取るためという場合等もあるが、少なくとも建前上は)。だからアドバイスを受け取る側としては、「相手が不満に思っている」ということではなくて、「この状態だと将来的に僕がどう困るのか」あるいは「相手がどう困るのか」を知らなくてはならない。それを可能な限り漏れなく文書化して、トレードオフを議論して妥協点を探す。単にそれだけの話なんですよね。そしてそれは別に文章に限らず、コーディングだってそうなわけです。おそらくUX designerも同じだし、PdMがやってることもそれ。
これを意識してからは、主語がIなのかWeなのかは結構意識しながら喋ってる気がします。更には "I personally" と強調したり、"We, Xyz team" みたいに限定したりとか。ともあれステークホルダーという概念が明確になったし、交渉相手もわかるし、相手がそれを曖昧にしてることにも気付けたり。 

わかってしまえば当たり前過ぎて、誰もこんな話をしないんだと思うんですけど、でも時々見かけるデータサイエンティストどうこうみたいな話でもこういうのをよく見かけるので、結局これって意外と難しい概念なのかもしれないです。まあ正直、日立でも言われてたかもしれないけど響かなかったんですよね。
「そんなことも教えられないとわからないなんて最近の若いもんは」と思う人もいるかもしれませんが僕はもう若くないし、生存バイアスについてもう少し思いを馳せていただけると、というのと、僕自身がこういうことをちゃんと伝えていかなきゃなとも思っています。

変わったもの

ここまで書いてきた英語の話や文章の話なんかは例えば視野が広がったとポジティブに言い換えることもできると思うのですが、その一方で老害感もでてきたなあと思います。
どうしたって年齢も上がったし、キャリアも積んだソフトウェアエンジニアとして、相手も僕を尊重しないとしょうがない部分があると思うんですね。もちろん心理的安全性みたいなのの意識もあるんでしょうが、それに上乗せされている感じ。心理的安全性というのはある意味で権利であり、自分がそれを確保することを強く主張することは大事なんですが、一方でそろそろ控えめにしていかないと危うい立場だなと。ゼロサムゲームをやっているわけではないにせよ、相手の心理的安全性を逆に損なうことに繋がりかねないし。ともあれ、こういう風に考えられるようになったことは良いことなのかな、多分。

否が応でも責任ある立場になる年齢ですよね、というだけの話ではあるのですが。


変わらなかったもの

良い意味で変わらなかったのは、コードを書くこと自体が好きだという感情ですかね。もちろん面倒だなあと思うことも多いんですが、それでも根本としてはコードを書きたい欲求があって、それを満足させてくれるソフトウェアエンジニア職はいいですね。とはいえ、上にも書いたように文章を書くことも増えていて、そうすることでコードを書く前に議論して手戻りが少なくなったりしたとは思うんですが、それはそれでちょっとなあと思わなくはないです。ほら、あーでもないこーでもないとやりながら大量のゴミコードの量産って、それはそれで楽しくないですか?あんまり共感は得られないかもしれないし仕事としては他人を巻き込むことになるからアレなんですけど。車輪の再発明とかも楽しいですよね、みたいな。

あとなんだかんだチームの宴会やらなにやらを設定する役回りは継続しています。これは前職からやっていて、前職でも社員旅行を企画したりしてました。現職だとさらにもっと色々やっています。誰もやりたくないなら継続しますが、これも若者がやりたいようにしてあげるのがいちばんかなあと思っております。

次の10年のキャリアを考える

僕自身、「10年後に自分がどうなっていたいか」という答えを持っているわけではないし、その質問をされることは好きではありません。ただこれはある意味後進にロールモデルを示せてないということでもあって、なんとかひねり出すことで誰かの役に立てるかもしれないと思いながら書いてみます。

既に書いたように、僕がAndroid開発してるのはあくまで成り行きで、特に希望はしてなかったのでそこにこだわる理由はなんにもないです。ただ、続けた以上は多少の愛着はあります。

Android OSが10年で完全に消失することはないにせよ、その立ち位置が変わっていく可能性は高いし、現在持ってるAndroid固有の知識が使えない局面は増えるんだろうなと思っています。なので、何かしらの別技術のキャッチアップは必要でしょう。そこで自分が先頭に立ってデバッグをしながら理解していく、というプロセスに対する恐れが無いといえば嘘になります。完全に若者と同じプロセスを踏んで、横で働けるのか。やらねばならないからやるだろうし、少なからず現在までの蓄積は使える部分はあれど、どこまで第一線でコードを書けるのか。よくわかりません。
すでに体力は衰えつつあるし、頭の回転は日々落ちてるなあと思っています。ノウハウが増えているとは思っているものの、本当にそこのスキルが上げられているのか。自問自答の日々です。頑張らざるを得ないので頑張りますけど。

管理職はどうだろう。そこまで興味はないのですが、大きな理由は大体「自分で書いた方が早い」という点に由来してる気がしていて、仮にその前提が崩れるのだとすれば管理職として前線でコードを書く人達を助けるというのも良いのかもしれないなあと漠然と思っています。今じゃないけど、とも思うんですが。特に今の新型コロナウイルスでリモートワークになっている中で管理職やるのはキツそうだなあと思ってます。

それ以外だとバックエンドエンジニアとかも興味がないわけではないですし、他の製品に興味がないわけでもないです。先に書いたようにGoogle Mapsという製品に関わっているのもAndroidのコードを書いているのも成り行きによる部分が大きくて、エイヤと別分野に行くための動機が無いだけなんですよね。なんと消極的なと自分でも思うんですが、結構Googleの中でもそういう人は多いと思います。

ソフトウェアエンジニア以外のキャリア。研究職にはもうならないと思います。世界で一番になる必要は無いと考えることが今の僕を支えているんで。どこでも通用する一般的な知識が人類に増えることは勿論良いことだし、それは必要な営みなんですが、自分がそれを作り出さなくても技術で人類に貢献できるなと思っていて、そう考えたときにとても気持ちが楽になりました。

それ以外の職種。うーん。あんまりですねえ。お金を貰うことを目的とする労働の中だと、現状これ以上にフィットする業種が無いと思います。やってもいいけど、お金を今のレベルで貰うのには申し訳ないことしかできないかなあ。給与を減らすならソフトウェアエンジニアを続けて早く引退したい。まあ今後ソフトウェアエンジニアが斜陽になって、もっと稼げる別の職種が出てきたら、そっちになってるかもしれません。

転職とかも考えないわけではないですね。ただ、現職に大きな不満がないというか、一番の不満は労働することそれ自体だったりするので、転職しても特にメリットが無いというか。
リセットしたい人間関係があるとか、何をおいても解決したい課題があるとかじゃなければ、給与が爆上がりしない限り転職しないんじゃないかなと思います(なおこれは転職しないという意思表示ではなく給与を爆上げしてくれるオファーをお待ちしていますという意味です)。

引退はいつでもしたいです。が、数週間ならともかくとして数年とか休んでしまうとキャリア的には相当なデメリットというか、老後の休みの前借り以上に失われるものがあると思うんですよね。なので、もうちょっとはできないかなあ。でもあと20年働くのはつらいなあ。5000兆円欲しい。

まとめ

結局何が言いたかったかという話もないまま、ダラダラと書き連ねてみました。単なる節目だから書いた以上のものにはなってないですが、とりあえず10年の節目に間に合えばそれでいいという勢いで公開します。

何か聞きたいことあったら聞いてください。気が向けば補足するかもしれません。

この記事が気に入ったらサポートをしてみませんか?