30代未経験で転職したソフトウェアエンジニアが生き残るために
TL;DR
・30代未経験でソフトウェアエンジニアに転職した
・ソフトウェアエンジニアとしての死が常に迫っている
・自らの頭を使って生き残る
自己紹介
WASD株式会社（WASD Inc.）開発チームのうなむねと申します。店舗におけるお客様のスタッフ呼び出しを効率化する、デジちゃいむというサービスの開発、運営に携わっております。
前職は地方公務員という全くの畑違いであり、趣味程度にコードを書いたりすることはあったものの、実務としてはほぼ未経験の状態で転職しました。昨年の10月に入社したため、ソフトウェアエンジニア歴としては約半年となります。転職経緯等につきましては、拙文をご笑覧ください。
転職してからの半年間
この半年で様々な新機能が追加され、デジちゃいむは単なる店員の呼び出しサービスから店舗接客・店舗オペレーションを包括的に支援するサービスへと成長しています。呼び出し時に画像を送信できる機能であったり、お客様の呼び出しの位置を店内マップ上に可視化する機能はその一例です。
このような機能開発の中、私はフロントエンドに軸足を置きつつフルスタック気味にデジちゃいむの開発に取り組んでいます。先に挙げた店内マップ機能では、先行して技術調査をやっていた関係で、なし崩し的ではありますがチームのマネジメント的なこともやっていました。
また直近にも、呼び出し時のビデオ通話機能やLINEと連携した順番待ち管理機能など、店舗オペレーションをより進化させる機能が続々公開される予定です。これら新機能のリリースに向けて、現在粛々と開発を進めています。
30代未経験ソフトウェアエンジニアの価値
話は変わりますが、私は平成元年生まれの今年32になる歳で、開発チームの中ではCTOと並んで最年長です。また、ネイティブアプリ開発のアルバイト経験こそあるものの、生業という意味では、チームにジョインした段階ではメンバーの中で唯一実務でコードを書いた経験がない状態でした。
転職からの半年を経て、実装力という点では格段に力がついてきたと思いますが、それでも将来を見据えて勉強している情報系の学生の方々に比べて確実に勝てるとは言えない状況です。
前職では（収入面を気にしなければ）何も考えずとも60歳まで職を得ることができましたが、現在の環境では自分のポジションを確保し続けることが必要です。また、この点については日頃CEOやCTOからも言われていることですが、WASD Inc.がどれだけ大きい会社になったとしても、定年まで会社に居続けることはなく、遠くない未来に転職する機会が間違いなく訪れることとなります。
いざその時がやってくるまで、ただ漫然と仕事に取り組んでいたらどうなるか。例えばコードが書けることは重要ですが、そのことだけがサービスの開発、ひいては会社の利益に繋がるわけではありません。これから体力的、思考力的に確実に衰えていく中、転職市場に放り出された時にそのような状態であったら、私のソフトウェアエンジニアとしての価値はゼロに等しいでしょう。すなわち、ソフトウェアエンジニアとしての死です。
このことは転職前から覚悟しており、転職前と比べて間違いなく仕事に対するモチベーションは向上しましたが、それと同時に「もはや次はない」という焦燥感を常に感じています。以下に記すのは、この感覚をプラスに変換して自らの市場価値を高めるための、そして私がソフトウェアエンジニアとして生き残るための生存戦略です。
生存戦略①：チームの中で果たすべき役割を考える
ソフトウェア開発を行う手法は様々ありますが、開発チームのメンバー構成や開発スケジュールなど、とるべきアプローチは様々な要因に左右されることとなります。
さらに、開発手法はある程度方法論が確立されているものの、その中でのメンバーの役割は、メンバーのスキルや年齢構成、はたまたその日抱えているタスクなどにより刻一刻と変化するでしょう。
したがって、今日の仕事のやり方が明日通用するとも限らない中、チームの中で果たすべき役割を常に自分の頭で考え、それを実行に移すことが重要であると私は考えています。
例えば弊社の場合、現在CTOを筆頭に、社員4名（うちUI/UXに特化したエンジニアが1名）とインターン1名、加えて業務を受託してくださる方とチーム一丸となってデジちゃいむを開発しています。また、デジちゃいむを広く使っていただくサービスにするべく、大きな開発スケジュールがある中でもお客様やビジネスチームからの要望を即座に反映できるようなスピード感が求められます。（この点、事業の完遂に5年、10年かかることが珍しくなかった前職の感覚からすると驚くべき早さです）
上記の理由から、弊社の開発チームでは開発手法としてスクラムを採用しています。この枠組みの中で、各メンバーは要件定義から実装・テストまで、いわゆるV字モデルの全工程に責任をもって取り組んでいます。当然、要件定義のような上流工程にも決まった正解があるわけではないので、ここでもしっかり頭を使う必要があります。
この状況の中で、スキルのキャッチアップをしながら開発を進めるべく、経験がないことを言い訳にせずにチーム最年長という立場を踏まえながら、日々自分のすべきことを考えて仕事に取り組んでいます。
生存戦略②：今の仕事の位置付けを把握する
結局のところ、価値のあるソフトウェアエンジニアになるためには会社に利益をもたらさなければならず、その利益を産むためにはお客様に最短で価値を届けることが必要です。（これはエンジニアに限った話ではありませんが）
そのためには、自分の今取り組んでいる仕事が大きな開発の流れの中でどのような位置付けになるのかを常に把握することが重要です。例えば、思いつくだけでも以下のような把握すべきポイントが挙げられます。
・それは新規機能の開発なのか？既存機能の改善なのか？バグ修正なのか？
・それはお客様が明日必要なのか？来週必要なのか？来月必要なのか？
・それは直ちにやるべきなのか？このスプリント内にやるべきなのか？月内にやるべきなのか？
・それは自分がすべきか？他のメンバーに依頼すべきか？
・リファクタリングがサービスの価値を高めるためのものになっているか？自己満足になっていないか？
・...
これらのことを踏まえながら優先順位づけや取捨選択をしていくことで、自分が今何に取り組むべきか、次に何をすべきかが自然と見えてくるものであると考えています。
弊社の場合では、以下のフローでデジちゃいむの開発を行っています。月ごとにメンバーが増えるなど体制が過渡期ということもあり、全てがこの通りにできているわけではありませんが、なるべくこれに沿うよう会社全体で心がけています。
・欲しい機能や改善したい機能などについて、ビジネス側・開発側を問わず起票する（弊社ではこれを「欲しいものリスト」と呼んでいます）
↓
・定期的に棚卸しして、実施の可否やスケジュール感、優先順位等を決めて並べる
↓
（ここまでがビジネスチームと開発チームの共同作業）
↓
・実装レベルの仕様に落とし込んでGitHub Issuesに起票する
↓
・優先順位に応じて実装を進め、テスト、レビューを経てリリースする
デジちゃいむ開発チームではスプリントの長さを1週間と定めているため、毎週のスプリントレビューで成果物が見せられるよう、このフローに則りながらデジちゃいむの開発を進めています。
この際、欲しいものリストやGitHub Issuesの管理にはかんばん方式を採用しています。欲しいものリストはNotion、GitHub IssuesはZenHubを利用して、 何ができていて何ができていないのか、何を次にやるべきなのか等が一目見てわかるように整理しています。
本来、かんばんは常に見えるところに掲示されていることが望ましいですが、弊社は全員フルリモートの勤務形態なため、それは実現困難です。私は、長期的な開発スケジュールやこれらのかんばんを日に何度も意識的に見るように心がけており、今自分のしていることが間違った方向に逸れていないか、手が空いた時に次に何をすべきかを常に頭の片隅で考えながら仕事に取り組んでいます。
おわりに
本記事では、私がソフトウェアエンジニアとして生き残るために日々考えていることを、デジちゃいむの開発における事例を踏まえながらご紹介しました。
いずれも共通しているのは、ある程度の方法論はあるものの、最終的には自分の頭でふさわしい仕事の方法を考え抜いてそれを実行することです。これをやめてしまった時点で、私が必要とされることはなくなるでしょう。
転職したことを後悔する日が来ないよう、そして5年後、10年後もソフトウェアエンジニアでいられるよう、私は生き残り続けます。
この記事が気に入ったらサポートをしてみませんか？