きっかけ
5月31日、私たちの会社のプロダクト責任者が社内のグループメッセージで採用を呼びかけました。友好的な協議を経て合意に達し、私は兼務でプロダクト業務の一部を担当することになりました。転職したわけでもなく、完全に変わったわけでもありません。迷っている方々への記録として、また自身のログとして感想をまとめます。長いと感じる方は、最後まで飛ばして要点をご覧ください。
キャリアの振り返り
0. 手探りの摸索
大学1年目は技術以外のことを多く行い、その後、主力言語として発展させるために高水準プログラミング言語を選ぶことにしました。JavaとC#を長期間調査した結果、C#を選択しました。C#を選んだ理由は単に、日本語サポートが充実していたからです（マイクロソフトのドキュメント、Visual Studio、IntelliSenseも日本語対応）。また、C#はJavaに比べて、コードで行いたいことをより明確に記述できると感じました。一方、Javaはコード量が少なくないと感じました（例えば、Java 8で日付データを文字列に変換する際の冗長さは、経験者ならご存知でしょう）。
いずれにせよ、当時の外部環境ではJavaを選ぶ方が良い選択でしたが、私は強い第六感でJavaに抵抗を感じ、最終的に快適なC#を選びました。自分が快適に感じることでなければ、持続的に投資できないと信じています。
その結果、リソースの問題に直面しました。大学にはC#関連のコースはなく、授業はすべてJavaでした。C#を教えられる教員もごくわずかでした。今振り返ると、どうやって一人でやり続けたのかわかりません。半年もの間、学習を続けても小さなプログラムすら作れませんでした...しかし、この期間の手探りの摸索の中で、非プログラミング文法の概念（例えばオブジェクト指向の理解）を探求しました。その後、オンラインで喜科堂（Xiketang）のトレーニングに申し込み、ようやく本格的に入門しました。
1. 大学プロジェクトチーム
喜科堂のC#トレーニングコースは、ほぼ基礎を固める内容で、文法だけでなく、工学的な経験（例えば、何かを行う際の分析の仕方、どこから着手して考えるかなど）も含まれていました。卒業の2年前には、独立して受講生管理システムを作成できるようになりました。ちょうどその頃、友人の口コミで大学に授業を免除してもらえるプロジェクトチームがあることを知りました。これは私にとって、実際の開発に触れる機会でした。しかし、彼らの開発チームはすでに満員で、テストチームに空きがありました。夏休み中にテスト知識とSeleniumを猛勉強し、面接に合格してテストチームに参加しました。
テストの仕事は比較的暇でしたが、別の視点からプロジェクトを見る貴重な機会であり、自分のスキルを磨く時間もありました。誇れることが一つあります。テスト中にバグを発見し、ブラウザで調査した結果、正規表現が間違っていることに気づきました。そこで修正した正しい正規表現を開発者に送り、そのままコードに組み込んでもらいました。熟練者ならご存知でしょうが、これはテスト開発の業務であり、テストと開発の両方を理解していることになります。
また、この期間中にVisual Studio 20周年記念イベントに参加しました。その際、ある方が勤めている企業に応募しましたが、不合格でした。理由はWebができないからでした。帰宅後、C/SからB/Sへ転向し、2か月以内に個人ブログを立ち上げました。フロントエンドと管理画面を含み、パブリッククラウドにデプロイし、独自ドメインを取得して备案（ICP登録）し、HTTPSやCDN、その他の技術を使用しました。この時点で、開発からデプロイまでの一連の流れを理解できました。
この段階での私のキーワードは、自分を開発だけに限定しないでした。様々な経験から、大学在学中に実際のプロジェクト開発に参加することはありませんでしたが、結果的に非技術的な事柄にも触れることができました。
2. Newegg Chinaでのインターンシップ
その後、偶然にもNeweggでインターンシップを始めることになりました。ちょうどその頃、2つの大きな出来事がありました。.NET Core 2.0のリリースとマイクロサービスです。私はあのPentium 4 CPUのインターン用PCで、メモ帳とコマンドラインを使ってコードを書くことを強いられました...新しいフレームワークだったため、インターンチームでは自分で簡易的な3層アーキテクチャを構築し、さらに基本的な.NET Core Webフレームワーク（ミドルウェア、HTTPパイプライン）を理解しました。その後、MKPLチームに配属され、そのチームがちょうど.NET Coreの探求を始めていたため、私はCoreのSDKやプロジェクトフレームワーク、UT（ユニットテスト）の研究、デプロイなどの雑務を担当しました。
この段階での私のキーワードは、オープンソースです。
後にNeweggを離れて再び面接を受けた際、面接官から「.NET Frameworkと.NET Coreの最大の違いは何か」と質問されました。私の回答は、「Frameworkの時代は低レベルのライブラリがブラックボックスだったが、Coreの時代は思想が閉鎖から開放へと変わった」というものでした。以前は開発リソース（SDKライブラリなど）はすべてマイクロソフトが提供し、非マイクロソフトのものは採用するかどうかを長く検討する必要がありました。しかし、Coreの時代以降はコミュニティをより信頼し、積極的に参加するようになりました。
Neweggでの経験に戻ると、もう一つは基礎能力を固めたことです。状況は次の通りです。
- Neweggは20年以上の歴史を持つ企業で、私たちのチームのプロジェクトも10年を超えていました...その中には数え切れないほどの落とし穴がありました。
- MKPLは出品者向けプラットフォームを担当しており、他のチーム（例えば注文、返品交換）と連携する必要がありました。出品者にとっては、他のチームの問題も私たちの担当プロジェクトで表面化することがありました。
- Neweggの全体的な雰囲気は、メンバーが自らプロジェクトを推進する必要があり、上司の指示を待つことはありませんでした。例えば、プロジェクト内のあるインターフェースを任された場合、自分で他のチームと具体的なフィールドやインタラクションロジック、テストロジックを調整し、開発ドキュメントを作成する必要がありました。要するに、私はそのインターフェースの直接責任者であり、PMではないということです。
この期間中、基本的な技術知識だけでなく、職業上の基礎素養も向上しました。例えば、インターン時にはバグランキングで上位にいましたが、後には7、8位まで下がりましたが、開発作業はインターン時よりもはるかに多くなりました。
この段階での私のキーワードは、職業的基礎素養です。Neweggは規模は小さいながらも、仕事の管理プロセスからインターネットアーキテクチャまで揃っており、社員の基本的な素養も他の企業に比べて総合的でした。そのおかげで、その後、より小規模な企業に移っても余裕を持って対応できました。
3. 短命だった2つの仕事
2019年にNeweggを離れました。理由は、20人未満のチームに2人のアーキテクトクラスの人がいて、キャリア発展の余地が小さすぎたからです。その後、2社連続でわずか3〜4か月しか在籍しませんでした。
1社目：製品の出発点は良く、社長も資金力がありました。しかし、社長はソフトウェアを理解していませんでした！そのため、毎回プロジェクトの終盤になってから大規模な変更が入りました...その変更の規模がどの程度のものか理解しておらず、最終的にはソフトウェア部門が1年以上何の成果も出していないと非難しました。結果として、私が退職してから2か月以内に、以前からの社員は全員去り、ソフトウェア関係者はほぼ全員いなくなりました。私が退職を申し出たその日に、部門マネージャーやプロダクトマネージャーも退職しようとしていることを知りました...？？？？
2社目：政府系プロジェクトを手がける会社で、基本的には共通のコードを少し修正して複数の地域の部門に販売するスタイル...チームビルディングだけにこだわり、顧客がプロジェクトを使用する際に正常に動作すればそれで良いという考え方。数日でダウンしても誰も気にしないようでした...しばらくいて感じたのは、ここでは私のような人間よりも、むしろ「老練なプレイヤー」が必要とされているということでした。
この段階での私のキーワードは、Neweggの良い雰囲気に守られすぎていたです。1社目では主に調整業務を担当しました。チーム内の調整、部門間の調整。2〜3か月でほとんどコードを書かず、人間関係の仕事が多かったです。2社目は完全に地雷原に足を踏み入れてしまいました。しかし、得るものもありました。技術以外の面で、仕事上のコミュニケーションにおいて非常に多くの経験を積みました。
4. 上級雑用係
そして、現在の会社に来ました。簡単に言うと、私は以下の業務を担当しています：新技術の推進、プロジェクトフレームワークの構築、共通コードベースのメンテナンス、社内サーバーのメンテナンス、プロダクト部門とのコミュニケーション、時には同僚間の作業調整など。
技術的には、ほぼ35%のC#コード、55%のJSコード、10%のシェルスクリプトまたはその他の設定です。この会社に来る前は、私は絶対にJSを書かない人間でした。部門のCI/CDを構築する際、イメージ名とタグを管理要件に準拠させる必要がありました。私はC#で小さなツールを作成し、CI/CDパイプラインに組み込みました。業界でCI/CDを構築する場合、ほとんどがシェルスクリプトとYML設定だけです。
転機はここにあります。テスト担当者は単にクリックしてテストするだけ、開発担当者は開発だけ、プロダクト担当者は技術を理解していない。私はここでよく中継役を務めました。第2、第3段階での経験から、テスト担当者の考えていること、プロダクト担当者の考えていることを理解できました。そしてそれらを開発者に伝えたり、逆に伝えたりしました。社内の人間関係は非常に良好ですが、異なる職種の人々は長年の習慣で思考パターンが異なります。仕事が忙しくなると、相手が理解できる言葉に変換することを忘れがちです。結局、私たちは皆、同じ製品を作っており、製品の収益が上がれば（給与やボーナスなど）より良く存続できるからです。この状況が、私がスムーズにプロダクトを兼務できる理由であり、他の人が転職（完全な異動）となるのとは対照的です。
この段階での私のキーワードは、成功は偶然ではないです。実際、プロダクトを兼務したいと思ったのは、将来の逃げ道を確保するためでした。そして、困難な兼務を実現できたのも（800人以上の社員がいる会社での兼務は管理コストが高い）、これまでの蓄積があったからです。
5. まとめ
記事を書くにあたり、自分のキャリアを振り返りました。主に、無駄なエネルギーを使わなかったことです。効率の悪いことをした時期もありました（例えば、大学でC#を選び、半年間ほとんど成果がなかったこと）。しかし、その経験の蓄積が別の時点で役立ちました。偶然の経験から、ネットワーク、ソフトウェア開発とソフトウェア工学、ソフトウェアプロジェクトの開始から完了まで、各方面で少しずつ知識が蓄積され、主力であるバックエンド開発もおろそかにしませんでした。
未来
35歳という節目は大きな壁と言われています。私も迷いはありますが、不安はありません。無理ならプロダクトに転向することもできます。現在の医療ソフトウェア業界は業界経験が重視されるため（プロダクト部門も長期間採用できず、社内公募となった次第です）。将来、他にも機会があるかもしれません。このように一歩一歩進んでいけば、他の人より効率は劣るかもしれませんが、後退したり崩壊したりはしないでしょう。また、プロダクト経験を活かして現在の中級開発者の壁を突破し、私が目指す上級へと進みたいと考えています。
あなたへのアドバイス
人それぞれの要求や状況は異なります。多方面に投資し、一点に固執しないことが大切です。IT以外にも、私は週末にTRPG（テーブルトークRPG）をしています。これもまた別の分野です。
- 現在の仕事や現状に満足できない場合。すぐに飛びつかず、じっくり考えて自分が本当に求めているものを見極め、今後3〜5年の計画を立て、それを簡単に放棄しないでください。たとえその計画が失敗しても、失敗も経験ではありませんか？人生はまだ長いのです。
- 現在の仕事や現状がまだ良い場合でも、あまり安定に安心しきらないでください。絶対的な安定はありません。自分の計画のために準備や蓄積をしておき、不測の事態に備えましょう。
- 正しくて時間のかかることを行う。
3について：例えば、オープンソースへの貢献です。多くの人は最初は続けますが、次第に利益がないと感じて諦めてしまいます。しかし、技術が好きで共有したいと思うなら、共有した瞬間に喜びを感じられるはずです。それだけで既に負けない立場に立っています。もし追加の見返りがあれば、それはおまけです。そうすれば、外部からの見返りがなくても、自分自身のモチベーションで継続的に投資できます。それを好きになって、それのために努力するのです。そうでなければ、生活の奴隷になってしまいます。