現職を含め，これまで3社の自社サービス企業*1で働いてきた*2．
1社目ではメインのプロダクトがすでにサービスインしていた．主要な機能は大体完成しており，徐々に新規ビジネス案件のプロジェクトが減って運用フェーズに移行し始めるタイミングだった．最初の仕事は社内向け管理画面のちょっとした修正とかだったと思う．当時，20代半ばの若手で経験も少なかった自分は，そういう最後まで残っていた重要度の低いタスクを担当していた．入社して半年ぐらいでデカい新規開発プロジェクトを担当した後は，本格的にチームの人数が減り始めて運用フェーズに移行していった．
2社目では入社時点ではサービスインはしていたものの，割とやった方がいい残タスクが結構残っている状態で，バグも結構残っていた．自分の入社直後の仕事は，開発体制の見直し，バグの可視化，バグつぶしがメインだった．別にそれをやってくれと言われた訳ではないが，まずは体勢を整えないと安心して仕事ができなさそうだったのでそれまでの知見を活用してどんどん改革していった．それまで雑多にWeb APIをリリースしていたのが，決まった曜日，決まった時間帯の週1回になったのは自分がそう決めたからである．ただ，それらを片付けて綺麗にした途端，ビジネス要件的にはもう十分といった感じになってしまい，割とヒマになってしまった．幸いにもその後いくつか難しめのプロジェクトも経験できたが，やがてビジネス起因のタスクは発生しなくなり，Web API本体のリファクタリングやバグフィックスやライブラリのバージョンアップ，それもやり切ってしまうと社内データ分析基盤の整備や他プロジェクトの手伝いに精を出していた．それが最後の1年間ぐらい続いた．
3社目は現在の会社だが，サービスインしてからの時間はこれまで経験した会社の中では最も長い．現在所属しているチームでは運用をいかに安定させ，内部コンポーネントのリファクタリングにより開発コストを低下させる作業に注力している．自分の場合，現在は自社サービスのコンポーネント間だけで使われるプロダクトを改善している時間が大半を占めている．
これまで経験して思うのは，ゼロベースで新規にプロダクトやcustomer facingな機能をゴリゴリ開発しているのはほんの一瞬で，その後は長く運用フェーズが続くというライフサイクルである．運用フェーズが長く続いているというのは，言い換えればビジネス的に成功している，もしくはクローズするほどひどくない，等のポジティブな事実を示している．そのため，経営視点で見れば良い状態だと言える．実際，自分の収入も運用フェーズが長いプロダクトの企業ほど改善されてきている気がする．
ただ一方で，運用フェーズが長いと技術的に新しいことを試す機会が減る，やることが同じことの繰り返しになって単調になる，という事実と向き合わなければならなくなる．
技術的に新しいことを試す機会が減ること自体は，収入を得続ける点においては問題ではないと考えている．例えば，同じ会社の同じプロジェクトに居続けるなら，同じ技術を使って仕事を続けていてもすぐに問題になることは少ないだろう*3．実際，自分も前職では2年3カ月の間ずっとRailsのWeb APIのメンテナンスを続けていたが，それで仕事を失いそうになることはなかった．その前はJava + Springだったが同様である*4．
一方，「やることが同じことの繰り返しになって単調になる」問題は，未だに自分にとって深刻な問題として残っている．多分，一般的なソフトウェアエンジニアと比べても自分は相当な飽き性なんだろうと思う．もしくは，プライベートで楽しみを見つけることが下手で，仕事に楽しみを求めすぎてしまっていたことも原因の一つであると考えている*5．先に書いたように，プロダクトはいずれ運用フェーズに移行する．Webサービスは永遠のベータ版*6なんて言われていた時代があったが，本当にそうだろうか．足りないものを片っ端から作らなければならない，毎日のようにコードを書かなければならない，そんな夢の日々は一瞬で終了する．ベンチャーで働くソフトウェアエンジニアというのはそういう生活をしていると想像する人もいるのかも知れないが，そんなフェーズはどんなプロダクトでも一瞬だと思う． *7
この傾向はAWSやその他便利なサービスを活用することで近年さらに顕著になっていると考えている．インフラエンジニアがいなければherokuに重課金すれば十分で，サーバを持つにしても当然のようにIaaS*8で，メールを送信するのに自前でメールサーバ立てるなんてのは大抵の場合は不要で外部サービスに丸投げすれば十分で，GitHub ActionやCircle CIでリッチなCI/CD環境を最初から低コストで整えて開発をスタートできる*9．バックエンドエンジニアがいなければFirebaseで代替してフロントエンドだけを開発すれば場合によってはサービスインも可能な時代で，もはや自分のようなほぼWeb API開発だけを専門としてきた人材は，自社サービスを運営するベンチャーにとって必ずしも必須ではないと考えている*10．
このような状況下で，自分は今後どうすればいいのかと頭を抱えることが増えた．今後も同じ問題に遭遇したら，これまでのように「開発フェーズ」にあるプロダクトを作っているベンチャーを探して転々とするのか，勝負する領域を変えて長く戦える場所を探すか，できることを増やして*11運用フェーズに入っても開発を続ける機会を生み出す別の能力を身に着けていくか．何が正解なのか分からないが，このままだと過去と同じことを繰り返すだけになってしまう．転職自体はそこまで苦ではないが，いい加減それ以外の手段も持ち合わせていきたい．
*1:この言い方もう死語かも知れないけど，いわゆる受託開発専門じゃない会社を指している．
*3:2年7カ月以上同じ会社にいたことがないダメ人間なので実態は良く分からない．けど別に4年いようが5年いようが，会社がメインで使っている技術スタックが変わらなければ本人の技術スタックが変わらなくてもすぐにその人の評価が下がる，プロジェクトにありつけなくなる，といった事態は起きないのではないだろうかと考えている．
*4:ソフトウェアエンジニアとしての評価と使える技術の幅はそこまで比例しないものである．
*5:反省してプライベートでいくつか何の役にも立たない個人プロジェクトを積極的にやるようになったのはつい3年前からの話だ．
*6:https://gigazine.net/news/20060823_beta/
*7:なお自分はWindows NTの開発記である「闘うプログラマー」やFaccebookの立ち上げ時期の様子について書かれた「フェイスブック 若き天才の野望」に出てくるデスマ話が大好きで，なんで自分はこれらのプロジェクトに参加できなかったんだと読む度に悔しい気持ちになる．
*8:これも死語かも知れない．AWSとかGCPとかAzureの仮想サーバ等の計算リソースを指す．
*9:昔はJenkinsってやつを社内で飼ってた企業が多かった．
*10:これが自分が仕事辞めて大学院に進学した理由でもある．https://serihiro.hatenablog.com/entry/2018/04/23/213418
*11:例えば今年に入ってからDLを中心に機械学習を勉強している．最近は畳み込みフィルタを適用する本来の意味について知りたくなってComputer Visionの勉強も始めた．
