🚢

テンショク・ジャーニー　—航海士だった僕が、SaaS企業でエンジニアとして働き始めるまで—

2024/03/20に公開

ポエム

はじめに

自己紹介

2020年10月よりWeb系受託開発企業でWebエンジニアとしてのキャリアをスタートさせ、現在はとあるSaaS企業でバックエンドエンジニアとして働くシンオクと申します。以前は航海士として国際貨物船での操縦や航海計画立案・貨物管理をしながら、インド洋・アラビア湾・シンガポール海峡・パナマ運河・カリブ海などの文字通りの大海原を航海しておりました。

なぜこの記事を書いたのか

紆余曲折を経て航海士という珍しい経験がありながら現在はフルリモートで働くWebエンジニアとして自宅からネットの海にどっぷり浸かっているのですが、時たま参加する技術イベントで初対面の方から「え？何？航海士からエンジニアってどういうこと？」と強い興味（困惑??）を持ってもらえることが多く、「文字に起こしてみたら面白いんじゃないか？」という思い付きでこの記事を書き始めました。

どんな人に読んで欲しいのか

内容の大半は自分語りになってしまっていますが、過去の私のように、異業種未経験からWebエンジニアへの転職を目指している方、自身が描くキャリアパスと所属組織がエンジニアへ求める役割にギャップがあってモヤモヤを抱えている方に、何か１つでも気付きや、一歩踏み出すきっかけを提供できるような記事にしたいと思って書き上げました。

また、勉強会などで私という人物を知って興味を持ってくださった方に読んで頂けるであれば、たいへん嬉しく思います。

注意事項

この記事は私の身に実際にあった出来事をベースとしたノンフィクションです。
内容の9.5割は事実です。残りの0.5割は、以前に所属した企業や、お取引のあった企業の特定を避けるためにあえてぼかして書いた部分もあります。
所々で人物のセリフが「かっこよすぎないか？」と思われる場面があるかもしれませんが、私という人間の厨二病フィルターを通してデフォルメされている可能性があります。予めご了承ください。

カイゼン・ジャーニーへのリスペクト

"カイゼン・ジャーニーたった1人からはじめて、「越境」するチームをつくるまで"が大好きなので、ここから先はその名著を存分にオマージュさせて頂いた上で、ストーリー形式で話を展開していくことも最初にお断りさせて頂きます。

第1話僕が船を降りた日

文系の大学生から航海士になった理由

船を降りよう、と決意した。ここは僕がいるべきところではない。

「他の人がしたことのない経験をしたい」「誰もが見たことのない景色を見たい」という夢を抱いてこの会社に入社したはずだった。

入社時点で航海士として働くための免許を持っていなかった文系学部出身の僕は、同じ境遇の同期達と寮生活をしながら、実に2年間の歳月をかけて航海士として働くための免許「海技免状」を取得したのだった。

でも、それももう役に立つ日が来ることはないだろう。商船系の大学や高専出身の同期が入社時点で保有している海技免状を、文系学部出身の僕にも取らせてくれるために費用のみならず訓練期間の給料まで保証してくれた会社には今でも感謝しているが、それに報いることはもうできない。

船を降りる理由

家族・友人と離れて、周りに何も見えない大海原を仕事場にしながら、外界との接点はLINEのテキストメッセージだけ、という条件で半年間休みなく働くという環境に、僕はどうしても耐えることができなかった。

乗船後の3ヶ月間の連続休暇や、平均水準と比べて高い給与が振り込まれる通帳を見ながら最初の数年は何とか耐えることができた。

しかし、会社に入社して5年目の乗船中、家族にトラブルが起こって緊急下船をしなければならない出来事があって、そこで僕は限界を迎えてしまった。たまたまロサンゼルス港に停泊中だったことと、会社の対応が迅速だったおかげで家族から連絡をもらってから5日以内には帰国することはできたのだが、それでも「家族の危機に駆けつけられないくらい遠くまで行ってまでやりたい仕事なのか？」という疑問が自分の中で無視できないぐらいに大きくなってしまったのだ。

その後、会社に「もう船に乗ることはできない」と伝え、何度か話し合いを重ねたのちに僕は退職することとなった。業界内でも大手の会社だったので、船には乗らないが航海士としての知見を活かせるような職種の仕事がある関係会社への就職斡旋も提案してくれたが、それも断った。最初に抱いていた「航海士への憧れ」が「自身の適正のなさ」によって打ち砕かれてしまった時点で僕にはもうこの業界でやりたいことなんてなかったのだ。

新卒で入社して5年目の春のことだった。こうして僕は「航海以外の専門性を何も有していないのに航海関係の仕事は絶対にしたくない」という意味で、27歳で専門性ゼロの人間として生きていくことになった。

第2話 27歳、無職

転職活動失敗

航海士としてのキャリアを丸ごと捨てることになった僕は自分でもやりたいことが何なのかよくわからないまま焦って転職活動をし、なんとか得た内定先の中から法人営業の仕事を選ぶこととなった。当時は「こういうことがしたい」みたいなイメージは持っていたはずだが、今になって思うと「人と話すのは得意だから営業ならできそう」「でも個人営業は辛そうだから法人営業の方がいいかな」ぐらいの浅い認識しかなかったと思う。

そこからはあまり語っていて楽しい思い出じゃない。営業マンとして何のバリューも発揮することができなかった僕は「3ヶ月の試用期間が終了後は契約社員から正社員へと雇用形態が変わり給与も上がる」という条件で入社したが、試用期間終了後も正社員にしてもらえることができず、給与も据え置きのままだった。そして、そこに何の文句を言えないくらいには僕は無能だった。結局は入社から半年程度の短期間でその会社も辞めてしまった。もちろん何の引き留めもされなかった。

航海士を辞めた時は「なんとかなるでしょ！」という根拠のない自信も少しはあったのだが、ここで本格的に「航海士の経験を取っ払ったら僕って本当に何者でもないんだな」と自覚した。僕は晴れて27歳無職となった。航海士時代に貯金は十分にしていたのでそれを切り崩していけば何とか生活はしていけそうな見込みが立っていることだけが救いだった。

第3話エンジニアリングとの出会い

転職失敗からの学び

何の成果も得ることのできなかった2社目での経験で学べたことが１つだけあった。「僕は自分が強い興味を持てない仕事はできない」というシンプルなことだ。

僕は航海士という仕事はそれなりに気に入っていた。それまで文系の大学生だった僕にとって航路計算のために三角関数を習得したり、船が海上に浮いて航行する仕組みを知るために船舶工学を学ぶことはハードだったし、それまで縁のなかった海上衝突予防法などの法律をほぼ丸暗記しなくてはならないのもしんどかった。同じ船には日本人だけではなくフィリピン人やインドネシア人の船員もいたので、彼らとコミュニケーションを取るために英語力と異文化理解力も上げる必要があった。僕は船に乗るまで海外に行ったことすらなかった。

そんないくつもの障害を乗り越えられた要因を当時は「仕事でやるしかなかったからやれた」という風に捉えていた。でも違ったのだ。僕は船と、航海士という仕事を嫌いではなかったのだ。だから何とか一隻の船の三等航海士を任されるぐらいの能力は身につけることができたのである。

そもそも僕はこれまでの人生を思い返してみてもあまり優秀な人間ではない。航海士になるための訓練を受けている時代は、10人いる同期のうち僕1人だけが試験に落ちて追試を受ける、なんて出来事が一度や二度ではなかった。自分の興味のある分野でさえこの有様なのだから、そもそも自分が仕事で何をしたいかも明確になっていない状況で新しいことに挑戦し始めること自体が無謀だったのだ。この気付きから僕は、無職期間を利用して「自分のやりたいことは何なのか？」に向き合った。

僕がやりたいこと

航海士として勤務している中で、長期間の乗船と同じくらいストレスだったのは、日々の業務に占めるルーティンワークの比重が高く、自分が創造的な仕事している感覚を得ることが難しいことであった。

また、そのようなルーティンワークの自動化への手段として世の中に溢れている便利なIT系のツールを使えないことだった。

理由は2つあって、1つ目は、船の通信環境が陸上と比べて大幅に低速であることから、通信が前提となるアプリケーションが機能する環境ではなかったこと、2つ目は、単純ではあるものの航海士という職種でしか求められないような仕事であったため、世に存在するツールでは航海士のルーティンワークを簡略化できるものがなかったことである。

そんな事情もあって、少しでもルーティンワークを楽にするため、何とか自動化できるものはないかとExcelなどで関数を使って「なんちゃって便利ツール」を作って試行錯誤することも暗黙的には航海士の仕事の1つであった。

そして、そのような「なんちゃって便利ツール」作成作業を僕は割と楽しいと感じていた。自分が作ったツールで日々の作業が楽になるのはとても気持ちの良いものであったし、同じ船に乗っている同僚や先輩に使ってもらえるのも嬉しかった。

ルーティンワークを省力化し創造的な仕事の比重を高めたいという願望から自動化・業務効率化に試行錯誤していた過去の自分を思い出し、ふと「僕がやっていたことは自分と同じ船の同僚を楽にするためのツール作成だったけど、多くの人を幸せにできるツールをこの手で作れたらめちゃくちゃかっこよくない？」という気持ちが芽生えてきた。

無職で時間だけは有り余っていた僕は、業務自動化について調べ、エンジニアリング、プログラミング、といった領域に興味を持ち始めることとなった。

「プログラミング初心者」などのワードで検索し、まずはProgateからプログラミング学習を始めてみて、その後、Railsチュートリアルなども齧った僕は決意した。
「僕もアプリケーションを作れる人になる。」

こうして僕は、エンジニアを目指し始めることとなる。

第4話 28歳、エンジニア0年目

4ヶ月の学習期間

未経験からエンジニアを目指すにあたって、僕は完全な独学ではなくプログラミングスクールを利用する、という手段をとった。理由は単純。一人でエンジニアを目指すのが寂しかったからである。金額面でも教育訓練給付制度の対象のスクールであれば費用の70%は厚生労働省が負担してくれるためそんなに大きいものではなかった。無職に優しい国、万歳。

対面のコミュニケーションで仲間とワイワイしながら開発できるかと思いきや、世界的な感染症の流行によりオンライン受講に切り替わることを余儀なくされたり、エンジニア転職に燃えている人ばかりかと思いきや、モチベーションが高い人と低い人でまちまちだったりとイメージとは違う部分は正直あった。
それでも、モチベーションが高くて真剣にプログラミングに向き合っているメンバーと積極的に仲良くなりにいって、バーチャルオフィスツール上で連絡を密に取りながら朝から晩までプログラミングと向き合った4ヶ月間は僕にとってはかけがえのない日々となった。
その時の仲間とは受講終了から4年近く経った今でも定期的に飲みにいく間柄だ。そんな仲間ができただけでもスクールを受講した価値が十分にあったと思っている。

技術面で振り返ってみると、4ヶ月間必死で学習したとは言ってもやはり未経験の状態から学べることには限界があって、Ruby・RubyonRails・JavaScript・AWSの基礎的なことしか習得できなかったとは思っている。当時書いたコードを見返してみると「よくこんなんでエンジニアになりたいとか言えてたな...」と恥ずかしい気持ちになるのが正直なところだ。

だが、学習を進めていく中で、プログラミングというものの面白さ・奥深さを自分の中に言語化できたり、チーム開発のカリキュラムでエンジニアの仕事の進め方を疑似体験できたり、少しずつできることが増えていくにつれて「エンジニアになれたらこういうことをしてみたい」というキャリアイメージが明確化されていったので、決して無駄な時間ではなかった。

未経験からのエンジニア転職

4ヶ月の学習期間を終えると、いよいよ転職活動を始めることとなる。面接では技術的な質問も聞かれることには聞かれたが、それよりも「過去の経験を活かした上で、自分がIT業界でどのような価値を発揮できると考えているか」「数ヶ月間プログラミングを学習した上で、今後どのようなアプリケーションを作りたいと思ったか」「今後どのようなエンジニアになっていきたいか」という類の質問が多かったように記憶している。僕はこの手の類の質問には割と明確に自分なりの回答を持っていて、

能力面では
- 船の職場では失敗が死に直結するという極限状態の中でチームワークが求められるため、高いレベルでのチームビルディング力と危機管理能力が求められていたこと
- その2つの力はエンジニアリングの分野でも応用できると想像していること
作りたいアプリケーションについては
- 海運業界の航海士というレガシーな業界のレガシーな職種の経験があるため、テクノロジーの恩恵を必要としている人達の気持ちが想像しやすいこと
- この世に溢れている「人がやりたくないと思っている仕事」をシステムの力で自動化することで、多くの人が「本当にやりたいと思っている仕事」に集中する時間を獲得できるようなアプリケーションを作りたいこと
今後のキャリアについては
- 航海士として外国人の部下を率いて航海や港での作業を進めていた経験から、一定水準以上のリーダーシップやマネジメントスキルと呼ばれるものが自身の中に備わっている自覚があること
- そのリーダーシップとマネジメントスキルは、20代後半といういささか遅いキャリアスタートを逆転していくための武器として考えていること
- とはいえ、その武器を発揮するためには背骨となるエンジニアリング力が前提となると考えており、最初の数年間はその土台作りを怠りたくないこと

と答えていた。

そのような僕の姿勢と、受託開発企業との相性がかなり良かったらしく、僕は最終的に3社のWeb系受託開発企業から内定を貰うことができ、そのうちの1社への入社を決断した。決め手としては、

エンジニアの絶対数が多く、僕のような未経験層からベテラン層までレベル感のグラデーションが豊富でキャリアのステップアップが描きやすそうだった
プロジェクトマネジメントができるメンバーの不足を課題と感じており、入社後に自分の得意領域で会社への貢献がしやすそうなイメージを持てた
面接を担当してくれた人が入社後は自分の上司になる想定だと事前に知らされており、その人の単刀直入な話し方が気に入っていた

という3つがあり、ほとんど迷いはなかった。

そして、航海士を辞めてから実に1年半後に僕はエンジニアとしてのキャリアを歩み始めることとなった。無職になった当時よりも1つ歳を重ね、僕は28歳になっていた。

第5話師匠との出会い

最初のプロジェクト

僕の記念すべき最初のプロジェクトは受注金額が億を超えるような、会社としても最大級の大型案件だった。上司から「隣の部署が進めているプロジェクトでリリース前の最終チェック中のシステムがあるから、ヘルプにいってもらっていいかな？最初はテスターの仕事でもしながら業務に慣れてよ」と伝えられて始まった。

しかし配属されてすぐに様子がおかしいことに気付く。隣の部署のKさんから「この通りに操作して、期待結果と同じにならないテストケースがあったらバグ報告書をあげて欲しい」と言われテスト仕様書を受け取ったが、いざ実施してみると期待結果通りになるテストケースが半分もないのだ。中には「〇〇画面の中部にあるXXXというボタンをクリックしたときに~」というテストケースで、その前提となるXXXボタン自体がどこにも見当たらないようなケースもあった。素人目に見てもとてもリリースを控えているアプリケーションには見えなかった。

困り果てた僕はテスト仕様書を渡してきてくれたKさんに、仕様書通りに進めるととんでもない数のバグ報告書を書くことになりそうなこと、そもそもテスト仕様書に書いてある画面やボタンが存在しないため目の前のアプリケーションとテスト仕様書が想定している状態に齟齬がありそうなことを伝えた。するとKさんは少し困った顔をして、大規模プロジェクトであるためテスト仕様書を用意したチームとアプリケーションを構築しているチームが違っており、かつ、そこのコミュニケーションが分断されてしまっていること、要件定義書・ワイヤーフレーム・クライアントとやりとりしているタスク管理ツール上でのコメント・そして現状書かれているRubyのコードの状態がどれも少しずつ違っており、もはや何が正解なのか誰もわからないことを正直に教えてくれた。

そして、Kさん自身もキャッチアップに苦戦しているような状況であり、もし何か少しでも手助けをしてくれると嬉しいとのことだった。最後にプロジェクトのドキュメント類へのアクセス権を付与してくれて、忙しそうに去っていった。

沈没しそうなチーム

付与されたアクセス権でプロジェクトのドキュメントを読み漁っていくと、それぞれのドキュメントが作成された時期ごとにそれぞれ少しずつ書いてることが違うし、さらに言えばそのドキュメントを執筆する担当者によっても少しずつ解釈が違っているみたいだった。さらに悪いことに、開発を担当しているこちら側のプロジェクトマネージャーも、発注側のクライアントの責任者、どちらも退職をして後任へと引き継いでいた。その時期からドキュメントに書かれた仕様のブレはカオスさを増しているようだった。

このカオスさを自分なりに少しでも理解しようと、タスク管理ツールのチケットにカテゴリーをつけたり、テスト仕様書の備考欄に関連するチケットやドキュメントのリンクを用意するなどの整理整頓を始めたが、やはり1人では限界があった。完全には明文化されていないことについては最新のリモートリポジトリのプロダクトコードを確認した方が早そうな部分もあったが、何しろ僕は実際の業務で使われているコードを読むのはこれが初めてだ。1人で読んだとて理解できるわけもなかった。

助けを求めるためにプロジェクトのSlackチャンネルに疑問点を整理した上で質問を投げてみるが、特にメンションもつけてなかったため誰からも反応はなかった。メンションをつけようにも誰が何の担当をしているのかも知らないのでKさんの元へ聞きにいった。「その疑問点については〇〇さんが知っていると思う」とのことで、その〇〇さんに質問すると、疑問点の一部については答えてくれたが、残りの部分については自分にはわからず、誰の担当かも把握していないとのことだった。僕の疑問点を全て解消するのは長い旅路になりそうだった。

タスク管理ツールのコメントやSlack上でのやり取りで何となく感じていたことだったが、プロジェクトのメンバーは自分自身に割り当てられたタスクをこなすので精一杯で、他のメンバーの状況に気を配るような余裕は一切なさそうだった。

当然、明示的にアサインが決まらないタスクは容易にこぼれ落ちる。唯一、僕にプロジェクトの現状を説明してくれたKさんだけが、こぼれ落ちそうなボールを拾う最大限の努力をしているみたいだったが、1人では限界があった。

そして、そのようなチーム状況は「機能同士の繋がりが崩壊したアプリケーション」という形で顕在化しているようだった。この人たちに大型船の操縦を任せたら一日もしないうちに沈没するだろう。

技術部門のトップである師匠がプロジェクトマネージャーを務める理由

そんなこんなで、1週間ほどはKさんがこぼれ落ちそうなタスクを必死で拾いにいくのを手伝っていた。それでもこぼれ落ちていくボールの方が多く、プロジェクトのカオス具合は増し続ける一方だった。

「これはかなりヤバそうだぞ」と僕が気付き始めたちょうどその時に、上司が僕の様子を見にきてくれた。上司の隣には、上司の上司も一緒だった。実はこの上司の上司は、その後に、僕の師匠とも言える大きな存在になるため、以後「師匠」と表記する。

師匠は、このプロジェクトのプロジェクトマネージャーでもあった。元々のプロジェクトマネージャーが退職し、その後を引き継いだのだ。ちなみに、1人目のプロジェクトマネージャーはクライアント側の要望により強制降板、2人目は休職、3人目は退職という経緯で4人目のプロジェクトマネージャーということになる。当然のごとくクライアントの不信感は大きくなっていて、会社としても「これ以上の人材はウチにはいません」という姿勢として技術部門のトップである師匠を1プロジェクトにアサインさせるという大盤振る舞いをせざるを得なかったのだ。僕たちにもう失敗は許されていなかった。

エンジニアとしてのキャリアの方向性が決定付けられた瞬間

この時点で僕は師匠と顔を合わせるのは初めてだったため、初めましての挨拶を交わした後、話題はプロジェクトのことになった。「シンオクさんはこのプロジェクトについてどう思います？」と質問された。

「プロジェクトを完遂させるためのチームが機能していない気がしています。誰一人作るものの完成図をイメージできていないみたいですし、メンバー間で作るものの擦り合わせもできていないので、機能同士の結合時に前提条件が間違っていたことに気付いて丸ごと作り直す事態になったという話も聞いています。」
「なるほどね、シンオクさんはどうすればいいと思う？」
「どうやったらこのシステムが完成したと言えるかをクライアントも含めて認識を合わせる必要があると思います。あとは、誰も拾わず狭間に落ち続けるタスクを拾っていく役割の人も必要そうです。プロジェクトマネージャーが全てを把握しながら1つ1つのタスクを担当者に割り振っていくには大き過ぎるし、複雑過ぎる。あくまでプロジェクトマネージャーは全体を俯瞰して意思決定に集中できる状態を維持したまま、細部の話をケアする役割を置くのが良さそうだと思っています。」
僕の話を聞いていた師匠と上司は顔を合わせた。システム開発未経験で入社してきたやつがいきなりそれっぽいことを言ってきたので驚いたのかもしれない。
「私が考えていたことと大分近くて驚いたよ。私もプロジェクトマネージャーを1週間前に引き継いだばかりなんだけど、やっと他のタスクを片付け終えることができて本格的に動けるようになるのは今日からなんだけどね。何なら、シンオクさんの方が状況をちゃんと把握できているかもね。」
「いえ、ただの素人意見ですが...」

口ではそう言いつつ、僕にとっては、何の根拠もなしにした発言でもなかった。僕が唯一持っているのは船に乗っていた経験なので、そこの尺度に当てはめたのだ。船において最終決定権を持っているのは船長のみだったし、航海士の仕事は突き詰めていくと、その意思決定を支えるための準備・情報整理のみと言っても過言ではない。プログラミング力で劣っていたとしても、船上で培った状況把握力と、そこから必要なアクションを特定する能力はシステム開発にも転用可能だとも思っていた。
そんな不遜な僕の本心を知ってか知らずか師匠はこう言った。

「シンオクさん、キミがエンジニア未経験でこの会社に入ってきてくれて、まずはプログラムの書き方を学んでいくことから始めたいと思っていることもわかっています。それをわかりながら誘うのですが、プロジェクトマネージャーである私のサポートとして働いてくれませんか？知っての通り、このプロジェクトは大分崩壊しかけています。私の知識と経験を総動員して向き合うつもりですが、シンオクさんも言ってくれた通り、プロジェクトマネージャーが頑張るだけでは限界があります。」
「ちょっと待ってください。他のプログラミング未経験で入社した先輩方は、ある程度人数に余裕がある開発案件でメンターがついたりしながらコーディングの経験を積んでいると思うのですが、私にはその機会がない、ということになりますか？」
「もちろんシンオクさん自身がコーディングできる部分はコーディングしてもらって構いません。ですが、基本的にはプロジェクトを完了させるための行動を優先して欲しいです。メンターという意味では私がシンオクさんのメンターということになると思います。教えてあげられることは、コーディングよりも、上流にあたるプロジェクトの推進という部分になるとは思いますが。」

この申し出を断って１人のエンジニアとしての基礎を定着させるという選択もできたと思う。最初の数年間はエンジニアとして手を動かす仕事の比重を高めて、自信がついてきた頃にマネジメントと呼ばれる領域に進むというキャリアを当初はイメージしていた。
でも、それ以上に目の前の師匠からの提案は魅力的だった。金額として億クラスの大型案件のプロジェクトの意思決定を近くで見るチャンスは、次いつ自分の前に転がってくるかはわからなかった。
極論かもしれないが、プログラミング自体は自分のプライベートの時間に学習をすることは可能だが、プロジェクトマネジメントの経験は仕事でしか得ることのできない経験だ。

そんな僕の迷いを察してか、師匠は続け様に言った。
「もちろん、このプロジェクトに入っているエンジニアたちは"コードを書く"という点についてはシンオクさんよりも優秀です。ですが、彼らはもう長くこのカオスなプロジェクトを担当していて、気持ちが前を向くのが難しい状態になっています。シンオクさん、あなたには過去の経験を活かしてこのプロジェクトの救世主になってもらいたいのです。」
なんてクサいセリフを言う人なんだろう、とは全く思わなかった。誰もが見たことのない景色を見たい、という理由で航海士になった過去からわかる通り、僕は一生治らないレベルの重度の厨二病を抱えていた。師匠の言葉は、厨二病のアラサーの心に火をつけるには十分な火力を持っていた。

「やらせてください。」
その後の僕のキャリアの方向性を決定付けた瞬間だった。

第6話初めてのプロジェクトマネジメント

プロジェクトマネージャー補佐就任

こうして僕は、入社してすぐに大型案件のプロジェクトマネージャー補佐に任命された。上司からは「師匠に上手く乗せられたな」と笑われた。後から知ったことだが、師匠は社内でも「天性の人たらし」として有名だった。

ちなみに、僕の他にもう1人プロジェクトマネージャー補佐を任命されたメンバーがいた。プロジェクトに入ったばかりの僕にテスト仕様書やドキュメントの権限を用意してくれたあのKさんだった。僕が入社する前からプロジェクトの建て直しのために奮闘していたKさんが仲間にいるのは本当に心強かった。

こうして、師匠の主導の元でプロジェクトの立て直しが始まった。

師匠の戦略

師匠はまず始めに「何をどうすればアプリケーションが完成したと言えるのか」を明確にするため、現時点のアプリケーションをクライアント企業にそのまま見てもらった。責任者以外にも何人かに見てもらったが、先方からの反応は最悪で「これでは使えない」という意見だった。中には「この数ヶ月間あなた方は何を作ってきたのか」と怒りを露わにする方もいた。

それもそのはずだ。すでに最終確認テストを控えておりもうすぐ利用可能になる、と聞いていたものが実際に見せられてみるとバグだらけでとても使えるような代物ではないのである。

師匠はそれでも、「なぜ使えないのか」「具体的に何が足りていないのか」「挙動として何が間違っているのか」を丁寧に深掘りしていった。クライアント企業側の様々な立場の人、システム担当者・顧客対応担当者・ビジネス企画者から意見を集約し、不足している機能・挙動に誤りがある機能を洗い出し、タスク管理機能にチケットとして登録した。
その一覧を見ながらクライアント側の責任者と何度もミーティングを重ね、チケットが全て完了になればアプリケーションとして完成したと言える状態に、チケットのリストを充実させていった。

お金の話

その後は、ある意味一番ハードなお金の話が待っていた。当初の予定であれば、すでに開発は終盤に差し掛かっておりあとはリリースを控えているはずの時期にやっと作るものが明確化されたのだ。そこから追加で数ヶ月単位での開発期間が必要なことは明らかだった。うちの会社としてはその期間分についても先方から開発費用を貰いたいが、先方としては最初に支払う予定だった予算以上のものは用意していない。交渉は難航したが、最終的には正規の開発費用にある程度の割引率を掛け合わせたものを追加で支払ってもらうということで決着がついた。先方側も一度責任者の退職があったため、契約当初の話を完全に把握している人が誰もおらず、強くは言えない側面もあったようであった。師匠の交渉力なしにはあり得なかった決着だったとは思う。

生きたテストデータの準備

そういったお金の話をお偉いさんたちがしている間、プロマネ補佐である僕とKさんはデータベース定義書の更新に取り組んでいた。この段階でデータベース定義を根本から見直すことになったらどうしよう、という恐れもあったが、幸いにも開発を1からやり直すレベルの大掛かりな見直しは必要なさそうなこともわかった。これから作ろうとしているシステムはクライアント企業が元々保有している基幹システムとの連携を前提としており、そこのインターフェースとの兼ね合いで自ずとデータベース定義が決まるものだったからだ。あとは、基幹システムにはなくてこちら側のシステムだけにあるという類の属性の見直しだけで済みそうだった。

そして、更新版のデータベース定義に合わせて、なるべく実運用に近いようなテストデータも用意した。これまでは開発チーム共通で使うテストデータを用意せず、各々の開発者が各自の機能で必要となるデータを自前で用意して開発を進めていた。このことが原因となって機能間のつながりがなくなってしまっていたり、仕様に反する機能が出来上がってしまっていたと、師匠・Kさん・僕は仮説立てたのだ。

また、これらの作業は僕自身の仕様理解の解像度を格段に高めることにもつながった。テストデータを用意する上では仕様書やクライアントから上がっているチケットの内容の理解が必須であり、これらのドキュメント類をより深くまで理解することでこれまでぼんやりとしていた顧客のビジネスの全体像をしっかりと掴めていっている感覚があった。

そして、ちょうど師匠がお金の話を上手く纏め終えたのと時を同じくして、Kさんと僕はデータベース定義書の更新とテストデータの拡充を完了させた。ここからプロジェクト再始動だ。

チーム状況の見える化

プロジェクトの再始動にあたり、チームの中でルールを定めた。タスク管理ツール上のチケットのステータスを見れば実際の開発状況を把握できるよう、チーム全員で常に最新の状態に保つことだ。まだ誰も手をつけていないチケットであれば「未対応」、ブランチを切ってコーディングをし始めれば「作業中」、PRのレビュー依頼を投げれば「対応済」、そのPRがリモートでマージされれば「完了」とするという至極基本的なルールであったが、以前はここの運用が疎かになっていたせいでプロジェクトマネージャーが全体像を把握するのにコストがかかりすぎていたのである。

最初は、このルールを全員に守ってもらうのにも苦労が多かった。エンジニアのメンタルモデルとして「タスク管理ツールを扱うのはプロジェクトマネージャーの仕事であり、エンジニアはコーディングと向き合うのが仕事」というのが深く根付いていたためだ。若干マイクロマネジメントっぽくなって嫌だったが、しばらくの間、僕はタスク管理ツール警察となってチーム内を巡回するしかなかった。
「X機能やってくれてるの誰でしたっけ？お！Aさんなんですね！したらチケット担当者にご自身のアカウントを紐付けてもらってステータスを作業中にしてもらえると嬉しいっス！」「Bさんに担当してもらってるY機能、どうなりましたっけ？あ、もうレビュー終えてマージされたんですね！そしたらこのチケット、コメントにマージ済みのPRのリンクを貼り付けて完了にしておいてもらえると！流れでY機能と関連の深いZ機能の担当者をBさんにさせていただいてもいいですか？やって欲しい内容はチケットに書いてあるので、読んでわかんない部分あったらいつでも声かけてください！」という感じだ。

そんなパトロール活動を地道に続けた甲斐もあって、少しずつではあるが、それぞれのメンバーがチケットの状態を最新の状態に更新することが定着してきた。プロジェクトマネージャーである師匠はタスク管理ツールさえ見ればプロジェクトの最新状態を把握できるようになり、どの機能の開発が順調に進んでいて、どの機能の開発に関してはサポートが必要なのか、もわかるようになった。それまでは「誰が何をしているかわからない」有様だったチーム内のタスク状況は完全に見える化された。

クライアントと開発エンジニアをつなぐ方法

チーム内の改革がうまく進んだ後に取り組んだのはクライアントと開発チームの関係性を改革することだった。それまでは、PRがマージされたら「完了」扱いとして、「完了」になった機能については僕やKさんから個別でクライアント側の担当者に「X機能については完成し、ステージング環境で確認可能な状態にあるのでフィードバックして欲しい」と連絡し、貰ったフィードバックについては一度プロマネ補佐であるKさんと僕で受け止めて、アプリケーションのリリースに本質的には関わってこなそうなものについては、Nice-to-haveリストとしてリリースに向けての必須事項としない選択をしたり、リリースまでに絶対に必要となる優先度の高いものについてはPRマージまでを担当してくれたエンジニアに内容を共有して再実装してもらったりしていた。

このやり方は1つ重大な欠点があった。クライアントが必要としている機能のイメージが、その機能を作っているエンジニアに伝わる過程で、コネクタとなっているプロマネ補佐（Kさんと僕）がボトルネックとなってしまうのである。

この問題を解決するため、タスク管理ツールにクライアントを巻き込むことに取り組んだ。
「完了」の定義を、「PRがマージされたとき」ではなく「クライアント側の担当者が機能の充足を認めたとき」に変更したのだ。運用としては、PRがマージされてステージング環境上で一連の機能の動作確認が行えるようになった後、該当チケットの担当者をクライアント側の担当者に付け替えて、「X機能がステージング環境で確認可能になっているので、動作として問題がなければチケットを完了に、指摘事項があれば内容をコメントに追記した上でチケット担当者をこちらに戻して欲しい」というメッセージを添えるようにするのだ。それを、プロマネ補佐（Kさんと僕）だけでやるのではなく、機能実装を担当したエンジニアが行うようにする。理論上はこれでKさんと僕がボトルネックになることはないはずだ。

実際には、「我々が欲しいものは完成したアプリケーションなのに、なんで作っている最中にそんな面倒な手順を踏む必要があるのか」と拒否反応を示す一部のクライアント担当者を、師匠が「良いアプリケーションを作るためには私たちの作り込みだけでは不十分で皆さんの協力体制が必要なんです」と説きにいく必要があった。社内においても、「クライアントの担当者と直接コミュニケーションを取るのはエンジニアの仕事ではないのでは」という拒否反応を示すメンバーを、「確かにこれまでのエンジニアの役割ではないかもしれないけど、プロジェクトを完了させる上で必要なアクションはどこかが過負荷にならないようにみんなで受け持っていこう。必要なサポートはこれまでクライアントとの接点を持っていたプロマネ補佐の二人が責任を持って行うから。」と協力を仰いだ。そんな二方面での説得の甲斐もあって、クライアントの求めるものがエンジニアに直接伝わるコミュニケーションが確立したことによって開発スピードを向上させることに成功した。

アプリケーションのリリース

そのような改革の甲斐があって、開発スピードが増して、チーム内やクライアントとのコミュニケーションが改善した。もちろん、全てが順調にいったわけではない。パフォーマンスの問題が顕在化したり、我々が作っているシステム側ではなく、基幹システム側に問題が発覚して、インターフェース部分の改修が必要になったり、クライアント側で巻き込むべき部署が1つ漏れていてギリギリになって追加仕様が発生したりと様々な問題が起こった。その度に僕たちは問題の根幹を特定し、次にすべきことを明らかにして、それを1つ1つ対処していった。決して楽な期間ではなかったが、着実に一歩ずつ前に進んでいる充実感はあった。

そして、師匠がプロジェクトマネージャーを務める新体制になってから半年後、無事にアプリケーションを本番稼働させることができた。本来のリリース予定からは3ヶ月以上遅れてはいたが、一生終わらないかのように思えたプロジェクトをなんとか完了させることができたのである。半年間という決して長くはない期間ではあったが、この経験は初心者エンジニアであった僕に大きな自信を与えてくれた。もちろんコーディング能力については、改善すべき部分がたくさんあったが、プロジェクトを推進させる能力については、業界歴20年以上の師匠のやっている仕事を毎日隣で見てきたのである。他のプロジェクトを比べても2倍、3倍の経験と学びを得たと胸を張って言うことができた。

プロジェクト継続、そして何でも屋さんへ

僕が入社した頃は最悪だったクライアントとの関係性もこの半年間で随分と回復した。その甲斐もあって、本番稼働後も準委任契約を結んで引き続きこのアプリケーションの保守&新機能開発に関わっていくことが決まった。「まだまだビジネス上の競争力を高めるために構想している機能がたくさんあるので御社には引き続き協力して欲しい」という言葉を貰った時は不覚にも涙が出そうになった。このタイミングで師匠はプロジェクトを外れ、僕とKさんの二人体制で保守&新機能開発を担当することとなった。クライアントとしても「Kさんとシンオクさんであれば問題はないでしょう」という判断をしてくれたみたいだ。

こうして僕は、社内で「プロジェクトマネジメントと開発をこなす何でも屋さん」としての地位を確立することとなった。「リーダーシップとマネジメントスキルを武器にしてキャリアの遅れを取り戻したい」という方向性を描いていた僕にとっては理想的な働き方だった。僕は次の挑戦に早くもワクワクしていた。簡単な挑戦ではないだろうが、半年間二人三脚で頑張ってきた僕とKさんならどんなハードな状況でも必ず乗り越えられるはずだと信じていた。

第7話満たされない思い

突然のプロジェクト打ち切り

そんな意気揚々と始まった新機能開発のプロジェクトだったが、結果としてはいくつかの簡単な機能追加だけを行なって3ヶ月で終了してしまった。僕たちとクライアント側の担当者の間ではやりたい構想がたくさんあって「長い関係になりそうですね」と言い合ったりしていたのだが、クライアント側の役員陣から僕らのプロジェクトの必要性が疑問視されてしまったのだ。現場レベルから見れば師匠の改革を契機に僕らとクライアントの関係は強固なものになっているように見えていたのだが、先方の役員陣からすればそんなことは全くなかった。「元々の予算と期間を超過して何とか本番稼働まで漕ぎ着けたと思ったら、準委任契約で開発を継続する？そんな開発会社と今後も長期間に渡って関係を続ける必要がいったいどこにあるんだ？」というわけだ。クライアント側の担当者は「私としては御社と一緒に作りたい機能はまだ多く残っているので何とか会社と戦ってみます」と言ってくれたが、結果が覆ることはなく、当初思い描いていた新機能開発の10％も達成することなく契約は終了となってしまった。

クライアント側の担当者は「もっと長く一緒にやりたかったのですが」と言ってくれたし、師匠も「引き継ぐ前に先方のキーパーソンを私の方でちゃんと抑えておくべきでした、申し訳ない」と言われたが、誰が悪いという話ではなかった。もちろんクライアント側の役員陣の選択だって、経営判断という視点から言えば何一つ間違っちゃいない。ただ、やるせなさだけが残った。落ち込んでいる僕を見て上司が「あんま気にすんなよ。この受託開発の仕事をしてればたまに起きることだ、シンオクはできる限りのことはやった。」と声をかけてくれた。頭ではわかってはいたし、気にかけてくれるのは嬉しいかったが、悔しいことには変わりなかった。

こうして僕が入社してはじめて関わったアプリケーションとの関係はあっさりと終わりを告げた。元々違う部署に所属していた僕とKさんは、いつかまた一緒に仕事をしようという言葉を掛け合ってそれぞれ別の案件に携わることとなった。せっかく信頼関係が築けたのにと残念な気持ちが強いが、うちの会社では基本的にプロジェクトごとにチームが組成されてはプロジェクトの終わりとともに解散する。これもまた受託開発の宿命と言えるかもしれなかった。

何でも屋さんとしての日々

その後も僕は成功・失敗を繰り返しながら引き続き「プロジェクトマネジメントと開発をこなす何でも屋さん」としての日々をこなしていた。
デザインのリニューアルが主目的でデザイナーとタッグを組みながら仕事を進めるタイプのプロジェクトもあったし、大型案件の受注が見込まれながらもクライアントとの関係構築がうまくいかずに要件定義フェーズで打ち切られてしまったプロジェクトもあった。短い期間でパフォーマンスのボトルネックを見つけ出し、画面の描画速度を30倍以上高速化させることに大成功したプロジェクトもあった。
成功・失敗を問わず積極的にプロジェクトを推進していく姿勢は会社から評価されて順調に昇給は重ねていったし、現場のリーダー的なポジションとして経営会議の場に呼ばれることも増えた。周りから見ると、未経験ながら順調にキャリアを積んでいるように見えていただろう。気付けば未経験で入社してから2年半の歳月が経っていた。

求められる役割と抱く理想とのギャップ

しかし、内心はこれで良いのかと常に葛藤があった。当時の何でも屋の僕を支えている要素は主に以下のようなものだった。

クライアントから思い通りの回答を得るための誘導力
タスクを細分化して開発リソースをフル稼働させるための緻密な計画力
自社が不利益を被らないための契約書の作成能力
クライアントからのちゃぶ台返しリスクを最小化するための議事録作成能力

すなわち「炎上させないための能力」だ。もちろん、設計力や、コーディング力も日々の業務の中で向上はしていたものの、他者と差別化できるレベルのものではなかった。当初描いていた「誰かを幸せにするためのアプリケーションを作れるエンジニア」という方向性に進んでいるとは言い難かった。僕はこの2年半で「受託開発においてプロジェクトを成功に導く」という能力を向上させることには成功していたが、そのプロジェクトによって完成したアプリケーションが誰かを幸せにしているかどうかはまた別の話だった。

あるプロジェクトではこんな話があった。決して小さくなくない金額で請け負った既存アプリケーションに対する機能追加のプロジェクトを僕らは納期通りに完了させクライアントを満足させた。
そのプロジェクトはクライアントにとってシステムリプレイス案件のベンダーの選定材料という観点もあり、僕らの仕事振りを信頼したクライアントはその機能追加後のアプリケーションについて、オンプレミスからクラウドへの移行およびフレームワーク刷新のシステムリプレイスについても僕らを指名することを決定した。
クラウドへのデータ移行にあたって本番環境の各テーブルのデータ量をまとめていた僕は、機能追加によって新しく作成したテーブルのデータ量が著しく少ないことに気付いた。当初に予測していた機能利用状況と比べて100分の1程度だったのだ。クライアントにこれらのデータについて誤削除などはなかったかと質問したところ、そのデータ量で間違いないという回答であった。つまり、決して小さくない金額と期間をかけて追加した機能は、実際のユーザーにはほとんど使われていなかったということだ。
担当者は発注した内容通りの機能が完成して満足、僕らの会社も予定通りプロジェクトが完了して満足、でもただそれだけだった。実際に動くアプリケーションとしてはほとんど誰も幸せにすることはなかったのである。

もしかしたらそのプロジェクトがたまたまそのような結果になっただけかもしれない。しかし、思い返してみると僕が2年半やってきたプロジェクトでは、最終的にユーザーがアプリケーションをどのように使っているか、ユーザーが満足をしているかを知る機会はなかった。どのプロジェクトも新規にアプリケーションを構築するか、クラウド移行をするまでがプロジェクトの範囲内で、運用フェーズにおいて「プロダクトをどう育てるか」という領域まで関われることは一度もなかったのである。必然的に、僕らエンジニアの関心ごとは「どうしたらユーザーが満足するアプリケーションにできるか」ではなく、「何を開発すればクライアントは満足するか」になっていた。そのような姿勢では当初エンジニアを志したときの「誰かを幸せにするアプリケーションを作る」という理想に近付くことはない。そのことに気付いたとき、僕は始めてエンジニアとしての転職を意識することとなった。

第8話誰かを幸せにするアプリケーションを作るために

熱量を持ったエンジニア達との出会い

転職を意識したとは言っても、そこから具体的な行動を起こしたわけではなかった。現職に待遇的・環境的な不満は全くなくて、上司、同僚とも良好な関係を保てていた。むしろその環境の良さを考えると転職を躊躇したりもしていた。

決定的な契機となったのは、Startup Aquariumというスタートアップキャリアフェアへの参加だった。ベンチャーキャピタルであるCoral Capitalが主催しており、そこから出資を受けた50社以上のスタートアップが一堂に介してプレゼンやブース出展を行うお祭りのようなキャリアイベントである。基本的にはSaaSビジネスをメインとしている企業が多く、エンジニアとしては一日で勢いのあるスタートアップ企業と個人面談や情報交換ができる魅力的なイベントだった。そこで出会うスタートアップのエンジニアたちはどの人も魅力的な人が多く、自分たちのプロダクトで世界を良くしようという野心に溢れていた。羨ましさでどうにかなりそうな一日だった。僕も、そのような熱量でプロダクト開発に向き合いたいと思った。

SaaS企業への転職活動

こうして、僕はエンジニアとしての2社目の会社を探し始めることとなった。
「誰かを幸せにするアプリケーションを作る」という理想に少しでも近付くための転職活動であったため、テックブログなどでプロダクト開発に関する発信を積極的に行っていそうな企業をピックアップして、気になった企業についてはイベントやカジュアル面談を利用してエンジニアが熱量を持ってプロダクト開発をしていそうかという観点で受ける企業を絞っていった。
結果として、選考に応募した企業は全てSaaS企業になった。

自分自身のアピールとしては主に下記のような点を強調していった。

エンジニア兼プロジェクトマネージャーとして、プロジェクトを主体的に推進することと、自分で手を動かしての開発を両立できる
クライアントとのコミュニケーションを通じて、作るアプリケーションを明確化し、プロジェクトの関係者全員が満足するような成果物を生み出した経験がある
データベースに関する知識が比較的豊富（データベーススペシャリスト資格取得）で、パフォーマンス改善の経験がある

逆に、以下のような分野に関しては知識・経験が不足していることも正直に伝えていった。

どうしても目の前の納品という目的に縛られてしまい保守性を犠牲にして開発を行ってしまう場面が多かったこと
自身の作った機能について自動テストで全てをカバーしきれているとは言い切れず最終的にはマニュアルテストに頼ってしまうことが多々あったこと
エンドユーザーの声が意識できるようなユーザーファーストな環境での就業経験がないこと

入社決断

このように自分のやりたいこと・できること・できないことを整理した上で面接に臨んだのが功を奏したのか、幸いにも4社の企業から内定をいただくことができた。創業したてのスタートアップから、100名規模のエンジニア組織を有する企業まで規模は様々であったが、どの企業も高い熱量でプロダクト開発に取り組んでいることは共通していた。

最終的に、組織としてはエンジニアが100名規模のSaaS企業（日本のSaaS企業のエンジニア組織としてはかなり大きな部類に入ると思う）への入社を決めた。テックブログでの発信内容や、面談・面接で話すエンジニアの会話の節々から「ユーザーにとって価値のあるプロダクトを作ろう」という思いを大事にしている姿勢が伝わってきたし、そのためには何でもやろうの精神でいい意味でエンジニアの職務範囲が限定され過ぎていない点も魅力だった。これまでのエンジニア兼プロジェクトマネージャー、すなわち何でも屋だった自分にとってぴったりの環境のように思えた。

28歳でエンジニアのキャリアをスタートして、2年8か月後のことだった。僕は31歳にして初めてSaaSの開発というものに携わることとなった。

第9話現在、そして未来へ

受託開発とのギャップ

その会社に入社した僕は「誰かを幸せにするアプリケーションを作れるようになったか？」答えは「NO」だ。その理想には程遠い。入社当初は本当に上手くいかないことばかりだった。

開発スタイルについては、受託開発時代のウォーターフォール開発での考え方が思っていたよりも自分の奥深くに根付いており、組織として前提としているスクラム開発の手法や、アジャイル的な思想に馴染むのが苦労した。長期的なプロダクト価値向上を見据えなければならない場面でも短絡的なアウトプットで満足してしまい、チームのメンバーと同じレベルまで深く考えることができなかったのだ。

コーディングスキルについても、メンバーとのレベルの差に愕然とした。いかに自分が今まで質の低いコーディングをしてしまっていたかを自覚したし、可読性・保守性・効率性の全てを妥協しないメンバーのコーディングスキルに追い付く日は来るのかと弱気になってしまう自分もいた。

そして、ここが最も大きな問題ではあるが、なかなか自分の中のマインドセットを変えることができずにいた。
スクラム開発では透明性を重視し、その前提のもと検査・適用のサイクルを回していく必要があるが、僕はこの透明性、つまり自分の仕事をオープンにすることをなかなかできずにいた。
前職の頃だって自分の仕事をオープンにしていた自負はあったのだが、それはあくまで、自身がやっていたことを「とりあえず進んでますよ」と宣言していただけに過ぎなかった。
スクラムでは、チームは機能横断型であるべきとされている。この概念自体は、スクラムチームは「チーム内で要件定義からリリースまでを完結できる機能を備えているべき」というものだが、僕が入社した会社ではこの概念を拡大解釈し、誰かがボトルネックとなることなく仮に誰かが欠けたとしてもチームの出力を落とさない状態を作るという境地を目指していた。その境地を目指すためには、一人一人が個人で把握・取り組んでいることをチームに対して全てオープンにしていくことが求められる。
それを継続することによって、メンバー同士で学習し合えるし、もっと良い方法があればフィードバックし合えるし、仮に誰かが急遽働けない事情ができても他のメンバーで巻き取ることが可能になる。
これが僕にはできていなかったのだ。理由は至極単純、あまりにも周りとの実力差に落ち込んでいたせいで「間違ったことをしていると、無能だと思われるかも」という不安が拭いきれていなかったのだ。

乗り越えるべき壁

では現在はこれらの「開発スタイルのギャップ」「コーディングスキルのギャップ」「マインドセットのギャップ」の3つの問題は乗り越えられたのか？これについての答えは「YES」だ。

1つ目の「開発スタイルのギャップ」については、会社では本当にスクラムを愛しているメンバーが多く、そこにキャッチアップするための機会や知見はいくらでも揃っていたのだ。チームは僕のどんな些細な疑問やモヤモヤにも反応を示してくれたし、正しい方向に導いてくれた。

２つ目の「コーディングスキルのギャップ」については、もちろん改善の余地はまだまだあるが、モブプログラミングを定期的にすることによって知識共有を促進してくれたし、コードレビューもかなり丁寧にやってくれるので、自身のコーディングスキルの向上を日々実感できた。

最後の「マインドセットのギャップ」については、エンジニア全員がHRT（謙虚・尊敬・信頼）のソーシャルスキルを大切にしていたことが大きかった。この会社には能力の欠如を理由に他者を攻撃するようなメンバーはいないということはすぐにわかったし、むしろ「無能だと思われるかも」という不安から仕事をオープンにできていない僕自身が、他者を信頼するスキルを高める必要があると自覚することもできた。あとは自分自身が余計なプライドを捨てるだけだった。
もしかしたら受託開発時代のようにプロジェクト毎にチームが誕生しては解散していくような環境ではこの部分の解決は難しかったかもしれない。しかし、今の会社では基本的にチームは長期的な継続性を前提としており、メンバーの入れ替えというのもほとんど発生しなかった。HRTが溢れたメンバーに囲まれてスプリントを回して毎週のようにレトロスペクティブの場でお互いにフィードバックを与え合うのだ。メンバーに対する信頼感というものは少しずつ増していった。気付いた時には自身の仕事をオープンにすることに対する躊躇や恐怖は跡形もなく消え去り、純粋に今のメンバーとスクラムをしながらプロダクト開発を楽しむようになっていた。

ここで改めて問おう、今の会社で僕は「誰かを幸せにするアプリケーションを作れるようになったか？」答えは「NO」だ。今はまだ。
これからも僕はチームのメンバーと一緒に、毎週のスプリントを全力で駆け抜け、ユーザーの求めるものは何なのかを必死で考え、チームとして強くなるための方法を常に模索していく。その先にいつか、僕らの作ったアプリケーションで誰かを幸せにすることができた、と思える日が来るのかもしれない。

おわりに

またどこかで！

「航海士からWebエンジニアに転職した自分の経歴を文字にしたら面白いんじゃないか？」という軽い思い付きで書き始めましたが、かなりの長文になってしまいました。
過去の私のように、異業種未経験からWebエンジニアへの転職を目指している方、自身が描くキャリアパスと所属組織がエンジニアへ求める役割にギャップがあってモヤモヤを抱えている方が、この記事を読んで何か少しでも気付きや、一歩踏み出すきっかけのようなものを見つけてくださっていれば幸いです。
記事について、不明点やもっと詳しく聞きたい部分とかがあればTwitterなどからいつでもご連絡ください。もちろん、ただフォローしてくれるだけでも嬉しいです！

https://twitter.com/_shinoku

最後になりますが、ここまで読んで頂きました皆様本当にありがとうございました。またいつか、ネット上のどこか、もしくは数多ある勉強会の１つでエンカウントしましょう！