プロローグ

2023年1月にフリーランスエンジニアとして、個人事業主になった。
目指している場所はあるのに、行先は見渡す限り真っ暗な闇。
後ろを振り返えれば真っ暗な崖。

今後どこへ進んでいくのか。
この真っ暗な世界を進むには、灯りや指針を獲得する必要がある。

これまでのキャリアを振り返ることにした。

2020年4月春

英3文字のSIer企業に新卒で入社した。
SIerとはエスアイアーと読み、エスアイアーとはSystem Integrator(システムインテグレーター)の略称で、SIとはSystem Integration(システムインテグレーション)の略称である。
ややこしいが、日本のIT業界には、英3文字のSI事業で稼いでいる企業が沢山ある。

7月末までの4ヶ月間、新人研修があった。
研修が始まって2ヶ月間はITの基礎的なことばかりで、焦燥感に駆られた。
こんな低レベルな研修内容で良いのだろうか。
都内では、新型コロナウイルスが流行していて、リモートでの研修がメインだった。

7月からC#、SQLを使ったアプリケーションを開発する研修にシフトした。
アプリケーション開発によって、システム開発における基礎的な土台が構築された。
何よりも手を動かすことが好きなので、楽しかった。
研修期間の前半に感じていた焦燥感や退屈さは消えていた。

2020年8月夏

部署に配属され、隣を見たときに何百人もいた同期が1人しかいないことに少し驚いた。
配属には、事前面談の内容が考慮され配属先が決まる。
面談では客先常駐を回避すべく、今後どんな開発をしたいのかを日焼けの凄い部長に熱く伝えた。
部長は、白い歯を出して笑顔で面白いねと言ってくれた。
日に焼けた肌から見える白い歯が眩しく感じられた。

その選択が功を奏し、客先常駐が8割以上の組織で見事に残りの2割の席に座ることができた。
同時に客先常駐でのシステム開発の機会を失ったということでもある。
客先常駐を否定するわけではないが、あまり良いイメージを持っていなかった。

社食が充実していたため、本社へ出社したいという思いが強かったのが最大の理由でもある。
この判断は正解で、社食は間違いなく日本トップレベルのクオリティだった。
ランチを食べると、エンジニアの仕事を辞めてここで働こうかなという思考すら過ぎるほどに。

配属されたグループの雰囲気はとにかくカジュアルだった。
極端に表現するなら大学生のノリを持った人達だった。
特に勤怠に関しては、Teamsで「業務を開始します。」と入力するだけで良かった。

リモート勤務の日は、朝起きて30秒以内にデスクに座りPCを起動して業務開始を宣言する。
朝ごはんを食べながら、Outlookでメールを確認する。
歯を磨きながら、作業を洗い出していくというのが、毎朝のルーティーンとなっていた。
業務をする上で勤怠方法が楽で柔軟性があるのは、非常に重要なことだと知った。

グループには毎日9:30から朝会があり、タスクの共有を終えた後に10分弱アイスブレイクの時間が用意されていた。
配属されて1週間後の朝会で、「このアイスブレイクってなんのためにやっているのでしょうか？」と思わず失言をした。
コロナ禍になって顔合わせが減ったのでコミュニケーションを促進させるために実施しているんだと、ボットの様な返答をされた。

案件にアサインされて、エンジニアとして働く前との大きなギャップを感じるようになった。
それは、組織にナレッジが溜まっていない、知見がドキュメント化されていないことであった。
例えばある課題が発生したときに、暗黙的に解決するフローを理解している人はいるが、私や他の開発メンバーは知らないというケース。過去に知っている人がいたが、今はチームに存在しないというケースなどに頻繁に遭遇した。
この業界では、知っていれば3分以内に解決できることも知らなければ解決に1日以上かかってしまうことが、山のようにある。
組織には沢山のナレッジが蓄積されているんだと勝手に思い込んでいたため、大きな衝撃を受けた。
発生した課題、対策案、実施した対策、結果、を纏めてドキュメント化する。
これが、未来の自分や開発チームを助けることに繋がると学んだ。

開発の工程では、処理の共通化を実装しておくことも重要だとこの時に学んだ。
例えば、Azureの認証、データベースの連携、カラムの暗号化など様々な処理。
類似案件で、そのまま共通化した処理を利用できれば、開発工数を大幅に削減できる。
ナレッジマネジメントが機能している組織であれば、そんなの当たり前である。

私のグループでは全くできていなかった。
グループと言っても会社全体で見れば小さな単位ではあるが、そのような文化がこの組織には根付いているのかも知れない。

2021年4月春

入社して1年が経過した。
主にお客さんの業務を自動化するツールを開発していた。
私のグループに関わらず、SIerでは複数の案件を掛け持つ状態がある。
この状態のメリットとしては、沢山の知見が得られることにある。
私もそのメリットを享受することになり、短い期間に、Azure、SQL、C#、Unity、VBA、 Powershellなど様々な技術に触れることができた。
このメリットには、その知識を有していないことが前提条件として存在する。
例えば、知見を得た後に類似の案件を経験する場合、新たな知見を獲得するのは格段と難易度が上がる。

また、グループで扱っていた案件は、プライム案件と呼ばれる元請けの案件が9割であり、大企業のお客さんと仕事をする機会に恵まれていた。
プライム案件によって要件定義からリリースの工程まで携わることができた。
特に、リリースの工程でお客さんの検証環境、本番環境にアプリケーションをデプロイできたのは良い経験となった。
Azureなどのクラウドを使った検証環境や本番環境を構築することもあり、手順書と呼ばれるドキュメントを事前に用意する必要があった。
「猿でもわかるように、猿でもわかるように。」
と復唱しながら、誰でも手順に従えばを環境が構築できる詳細な手順書を目指した。
私がいなくても環境が構築できるように。

配属されてから今まで、多くの案件に携わった。
開発工程のメンバーが私1人という体制のプロジェクトにもアサインされた。
その開発工程の見積もりを見たときに、「こんなシステムがこんなに高いの」と驚愕した。

案件を掛け持つことのデメリットは、勤務時間が長くなることだ。
この頃グループ全体が忙しく、Teamsの勤怠を覗くとグループのメンバーが22時以降に業務終了宣言をするのが当たり前となっていた。
リソースも貧しい状態で、開発チームが疲弊しているのを肌で感じた。

雨ばかりで湿度が高くなってきた頃、Webアプリケーションを開発する案件にアサインされた。
次のお客さんとの定例会議で画面のデザインを見せることが決まった。
内部の定例会議で、先輩が作成した画面のデザインを確認した。
10年以上前のWebアプリケーションを彷彿させ、「何これ」と言ってしまい、ミュートが有効になっていたことに安心した。
端的に言えば、令和の時代に生み出された代物とは思えなかった。

その画面デザインでGOサインが出るとは思わなかったため、私はやる気を失い口を閉ざした。

しかし、その画面デザインを見せることが決まった。
この会議で、私はPMやチームに対して強い不信感を抱いた。
PMとはプロジェクトマネージャーの略称であり、役割としてはプロジェクトの全体を取りまとめる。

翌日のお客さんとの定例会議で、「もう少し画面のデザインにこだわりたいです。もしあれだったら、うちでデザインしましょうか？」と言われた。
PMは二つ返事で「はい！お願いします。」と言った。
これでは、どちらがお客さんなのか分からない。

そして、翌週の定例会議で、お客さんはユーザビリティの高そうなクールな画面デザイン提示してきた。

お客さんとの会議が終わった後、内部の定例会議でPMが「画面のデザインの工数が浮いて良かった。」という発言をした。
その発言に他のメンバーは賛同の声をあげていた。
こんなにも退屈なシステム開発が他にあるだろうか。

この瞬間、この会社を辞めようと決意した。

翌週、上司に会社を辞めたいと伝えた。
話をしていく中で、上司からは「転職先が見つかってから辞めるってことで合ってるかな？」と聞かれた。
今すぐにでも辞めたかった。
私は、「来月の7月末には辞めたい。」と言った。
しかし、案件を複数抱えていて来月辞められる様な状態ではなかった。

退社を決意した頃から、クリエイティブって何だろうかと、考えるようになった。
出社して開発チームの人に会った際には、現状の開発についての本音を聞くようになっていた。
みんな口を揃えて「うちの開発はつまらない。」と答えた。
更にそこからは、このグループの開発に対しての不満ばかりが溢れていた。

そもそもこの会社の受託開発という形態は、限られた貧しいリソースで開発をする傾向にある。
貧しいリソースで開発が始まり、決められた品質、コスト、納期を充足しなければならない。

プロジェクトマネジメントの分野では、品質、コスト、納期はQCDと呼ばれる。
限られたリソースの中でQCDを充足することは困難である。
開発チームの能力によっては、開発チームの稼働が高くなってしまうこともあるだろう。
リソースが貧しいからこそ、退屈なシステム開発となり、成果物も退屈なものが出来上がる。
何の工夫もしない限り、この状態に陥る会社は少なくない。

私は、システム開発にQCDCsを求めたい。
CsとはCustomer Satisfactionの略称であり、顧客満足度である。
顧客満足度を追求できれば、システム開発がクリエイティブになっていくのではないだろうか。
私は、その論理を大学時代から夢みている。
認知している範囲ではあるが、この会社にはクリエイティブを求めて開発をしている人がいないと知った。
システム開発に携わり、クリエイティブを実践するのは苦しいものだとも学んだ。
私は、いつの日かクリエイティブなシステム開発がしたい。
クリエイティブな成果物によって人は心を躍らせる。

2021年10月秋

担当していた案件を全て終わらせて、9月末で退社した。
会社を辞める旨を上司に伝えた際に、これからやりたいことも伝えた。
転職経験の無い上司からは、「転職はかなり苦労するよ」と言われていた。
転職先は2週間であっさりと決まってしまった。
会社を辞めた理由をよく聞かれるが、会社を辞めるに至った要因なんて挙げればキリが無い。
なぜ辞めたのかを聞くのは愚問だと思う。私の場合、話が長くなるから。

1つ気がかりなのは、優秀だった同期の行く末。

秋の暮れに、モバイルアプリケーションを自社開発している企業に入社した。
春頃からiOSのアプリケーション開発に携わりたいと考え、プログラミング言語Swiftを学習してきた。
iOSのアプリケーション開発に携わりたいと考えたのは、シンプルにApple製品が好きだったから。

入社初日にMacBook Proを渡され、胸が高鳴なった。
以前の開発ではMacBookとは微塵も縁がなかったため、これから毎日MacBookを触れることを想像して幸せを感じた。
人事の話によると、開発チームには海外の人が4割もいるらしい。
遂に、苦手な英語と向き合うときが来たように感じた。

その感情はすぐさま打ち砕かれ、海外の人達は上手な日本語使って会話をしていた。
私は、日本語で自己紹介をした。

自社開発のアプリケーションは既にリリースされていたため、アプリケーションの仕様を理解するところから始まった。
XcodeやAndroid Studioでソースコードを確認すると、ソースコードの量に体が震えた。
ソースコードの海に溺れそうになり、MacBookの画面を閉じた。

iPhoneのロック画面を見ると、入社してから1ヶ月が経過していた。
その頃、上司から「プッシュ通知のパフォーマンスを改善しておいて。」とタスクを雑に投げられた。

プッシュ通知のサーバーはFirebaseのFunctionsを使用していて、その内部ではNode.jsを使ってプッシュ通知を実装していた。
私はFirebase、Node.jsを触った経験は無いし、javascriptについて少し経験がある程度だった。
分からないことばかりで、何もかもが新鮮に感じられ、やる気と不安が渦巻いていた。

処理を確認していくと明らかになったことがある。
Node.jsの大量のソースコードにはコメントが全く記載されていなかったこと。
関数名、変数名、データベースのカラム名には意味の分からない略称が使用されていたこと。
控えめに言っても状況はカオスだった。

この不明瞭な状態を脱却するには、デバッグして処理の中身を確認するしかない。
そもそも、この環境のデバッグ方法が分からなかった。
Functionsのデバッグ方法は、エディターの行番号の隣にブレークポイントを置いて再生マークを押すと処理が止まるほど容易ではない。
ローカル環境で、エミュレータの起動、データベースの構築をしてからHTTPリクエスト経由で関数を呼び出す工程を経てやっとデバッグできる。
一つ一つ分からないことを明確にしていき、処理のボトルネックとなっていた部分を特定した。

2022年1月冬

iOSのタスクと並行して、プッシュ通知のパフォーマンスの改善に成功した。
新たに経験する技術領域では、まず初めにデバッグする方法を理解することが重要であると学んだ。

上司から「次は、iOSの自動化テストを追加して欲しい。Androidも必要であれば修正しておいて。」とタスクを依頼された。
自動化テストとは、UIテストのことだった。
入社して初めてAndroidの自動化テストが通るところ見た時は、まさに青天の霹靂だった。
「凄い…」と感動したのを覚えている。
前の会社では、何時間もかけて人力でテストして、Excelのテスト項目にOKかNGのどちらかを纏めていたのだから。

自動化テストを構成する技術としてはBitrise、Appium、RubyのRspecが使用されていた。
3つとも全く経験が無く、心が躍っていた。
この山を乗り越えたら、どんな景色が広がっているんだろうか。

ローカルでiOSのシミュレーターを起動させて、自動化テストを通すまでにはそれなりに時間を要した。
デバッグ用のiPhoneにUSBを繋いだ場合の自動化テストが出来るようになるまでは、途轍もない時間を消費してしまった。
自動化テストにおいてシミュレータと実機の場合では、環境を構築する手順が大きく異なることを学んだ。

この業界では、検索しても自分の探している答えが見つからない場合、つい時間を浪費してしまう。
日本語で見つからないなら、英語で検索する。
英語でも見つからないのなら、一つずつ対応を切り分けて検証して調査する。

調査した結果はドキュメント化することにした。
これで他のメンバーが、私と同じ険しい登山をしなくて済む。

非常に初歩的なことではあるが、検証する際に一つずつ対応を切り分けるというのは前の会社で学んだ。
簡単な例を挙げるなら、データベースからデータを検索する処理でタイムアウトが発生していたとする。
対応としては、タイムアウトする秒数を見直す、検索するSELECT文の処理を見直す、クラウド上のデータベースならば性能をアップグレードするなど対応は様々である。
同時に全ての対応をすると、対応策に対しての期待値が分からないため一つずつ切り分けをするのが重要である。

自動化テストが通るようになって、ようやく本題のRubyのソースコードを修正する時が来た。
いつ、誰が、どんな環境で、どんな順番で実行してもテストが通ることを意識してソースコードを描いた。
例えば、シミュレータでは成功するが、実機だと失敗するテストケースはあってはならない。
環境に依存しない自動化テストを実装することが私の美学となり、それを目指した。

私の実装したソースコードによって、アプリケーションの画面が遷移され、ボタンがタップされる。
テストが通っていく様をぼんやりと眺めているのは面白かった。
自動化テスト中に他の作業をしていても全く問題はなく、最終的にテストケースの成否はコンソールに出力される。
コンソールに緑色で「successfully」と表示されるのが嬉しかった。
システム開発におけるテストの工程が好きになった。

2022年4月春

この半年間で、見える景色が大きく変わった。
そう感じるのは、きっと少しは成長しているのだろう。
私生活でiOS版のYoutubeやTwitterなどを使っていると、部分的ではあるがUIのソースコードを想像できるようになっていた。
前の会社では得られないような、技術領域を経験する機会に恵まれた。

この頃から自社開発のアプリケーションで売上が発生していないことが、社内で問題視されるようになっていた。
開発チームは優秀な人達ばかりである。
どんなにITの技術力が秀でていても、アプリケーションの売上には直結しないということを肌で感じた。

2022年7月夏

業務を開始すると、朝から部長との面談が予定に入っていた。
「何かやってしまったのでは。」と不安で、心が破裂しそうなった。

そんな鬱々とした心境のなか、面談が始まる。
「おはようございます。」とできるだけ明るく、簡単に挨拶を済ませた。
頭を抱えた様子で残念そうに、部長は「この部署を他の企業へ譲渡することが決まった。」と告げた。
私は、「なんだ、私に関することではないのか。」と安心して力が抜けた。
「そうなんですね。」と返答した。
大学時代の先輩からは、「その無関心そうな、『そうなんですね。』は本当に良くない。」と未だに注意を受ける。
力が抜けて油断していたのか、悪癖が露見してしまった。

話を聞いていく中で、いくつかのことが明らかとなった。
自社開発のアプリケーションと開発メンバーをセットで他社へ譲渡すること。
譲渡先はまだ決まっていないが、これから譲渡の候補先を選定し、デューデリジェンスをして、上手くいけば年末には譲渡先が決まること。
デューデリジェンスとは、交渉段階において企業の価値やリスクなどを精査することである。
今回の場合、自社開発のアプリケーションや私達開発メンバーに対しての詳細な調査が行われるようだ。

部長からは、「譲渡先でもこのアプリケーションの開発を続けていきたいか？」と聞かれた。
特に強い思いもなかったが、「続けていきたい。」と前向きな返答をした。
この返答とは裏腹に、今後どうするのか思考を巡らせた。

ドラマしかり、漫画しかり、小説しかり、フィクションの世界でしか起こらないイベントだとばかり考えていた。
入社したことに後悔はないが、このイベントは想定することができたはず。
了見の狭さを身に沁みて感じた。

近い未来、3つのルートをチョイスすることになりそうだ。
譲渡先の企業へ行くこと、今の会社で開発とは全く関係のない仕事をすること、会社を辞めることである。
ここが、私の大きなターニングポイントだと確信した。

2022年12月冬

今月末で会社を辞めことが決まった。
日本の文化なのか、会社を辞めた途端に「プー太郎」などと呼ばれる。
嫌な文化であり、冗談でも聞きたくない。
心が落ち着くまでは、どんなに親しい友人であっても退職したと伝えることはない。

大学時代から3年後のキャリアについては考えていた。
就職して3年間は働いて、他のIT企業に転職するか、エンジニアとして独立するかである。

冬が来る前に、会社を辞めてエンジニアとして独立することを決断していた。

決断したはいいものの、今まで感じたことのない不安が夜な夜な押し寄せてきた。
独立して案件が獲得できなかったら。
条件の一致するiOSのアプリケーション開発の案件が無かったら。
案件を獲得しても、戦力外通告を受けたら。
今よりも良い条件に加えて安定した譲渡先に行った方が良いのでは。
幾ら考えてみても、それらの不安を解消することは困難であった。
最善の未来や最悪な未来を想像した。

不安はあったが、能力的に最善の未来も明瞭に想像できた。

この会社の開発では、機能を追加するにしても既に大量のソースコードが存在していたため、リファクタリングする能力が鍛えられた。
リファクタリングとは、外見の動作を変えずに内部の構造を整理することである。
簡単に言えばソースコードを綺麗にすること。
リファクタリングにおいて重要なのは、修正によってバグを発生させないこと。
修正した後にバグが発生することをデグレードとも呼ぶ。
開発チームのメンバーから「デグレしています。修正してください。」と強気に伝えられたこともあった。
世の中のシステム開発で、ソースコード修正後にバグが発生するなんてことは日常茶飯事である。
誰が、いつ、どのファイルで修正して、バグが発生したのかを迅速に特定するためにはソースコードの管理能力が肝となる。

どんな小さな修正であっても、プルリクエストをする厳格な文化もあったため、ソースコードを管理する能力も大幅に強化された。
プルリクエストとは、修正したソースコードを他者がレビューし、レビューがOKであればその修正が統合されることである。
今では考えられないが、前の会社ではソースコードのレビューはTeamsで依頼する形式で、プルリクエストをする文化はなかった。
この状態では、レビュー漏れが必ず発生する。

リファクタリングとソースコードを管理する2つの能力が掛け合わさることで相乗効果を生み出す。
それは今までの開発経験から学んだ。
この相乗効果によって、未経験のプログラミング言語で構築されたシステムであっても、バグの修正は難しくない。
これは私の抱いている論理であり、他のエンジニアが合意するかは分からない。
既にどんなプロジェクトにアサインされても開発では困らないと自負していた。

エピローグ

気づけば、個人事業主になり半年が経過していた。

冬に感じていた、迫り来るような不安は解消されていた。
想定していた最善の未来ではないにしても、継続的に案件を獲得して、戦力外通告も告げられていない。
今の現場は、独立してから2つ目の案件となる。
やはりiOSのアプリケーション開発に携われることに幸せを感じる。

2023年6月5日、WWDC2023でAppleがVisionProを発表した。
私は、VisionProのプロモーション動画を見た。

衝撃的で夢のように美しく、現実とは思えない魅惑的な世界が広がっていた。
全身に熱が広がるような感覚。

真っ暗だった世界に、一縷の光が差した。

熱い、次の冬が楽しみだ。