私のエンジニア経歴　Web受託開発編

これはなに？

エンジニアとして働いてきた私がこれまでの経験をまとめたものです。これまで現職含めて3社経験しており、会社単位で記事にしようと思いました。すでに1社目の記事を公開しているのでよければご覧ください。

今回は第2弾ということで、2社目でWebの受託開発をしていた際の経験について書いてみました。
単純に読み物として楽しんでいただければと思いますが、もしIT業界目指している方がいれば少しは参考になるかも（？）

ちなみにこの2社目に転職したのは19歳のときでした。

入社するまでの経緯

前回の振り返りもしつつ入社までの経緯を書いてみます。
私の全体的なタイムラインは個人サイトにも記載しているのでよければご覧ください。

私は岡山県で就職後、3ヶ月の研修を経て東京に異動となり就職後1年半ほど働いていました。会社の業態はSESだったため、契約先の顧客オフィスに常駐していました。研修後、炎上した開発プロジェクトを半年、その後平和だったが開発はあまり出来なかった運用保守を9ヶ月していました。

転機が訪れたのは運用保守をしていた時の夏、前回の炎上プロジェクトでお世話になったフリーランスのベテランエンジニア（以降はSさんと表記）に食事に誘われたことでした。Sさんはあまり社交的なタイプでは無かったので珍しいなーと思いつつ、美味しいステーキを食べれるということでホイホイついていきました。

会ってとりあえず近況など話していると、実は最近フリーランスをやめて就職したと切り出されました。Sさんが以前フリーランスとして参画していた会社のプロジェクトがあり、その責任者であった元部長が2年ほど前に独立したとのこと。そして独立して立ち上げた会社でWebの受託開発を行なっており、連絡を取っていたSさんに社員第一号としてお誘いがあったとのことでした。

その時すでにSさんは半年ほどその会社（以降はG社と表記）で働いており、さらに人を増やしたいのでリファラルで採用を行なっているとのこと。そして、常駐先が変わった後も連絡を取っていた私を誘いに来たとのことでした。

その時なかなか開発経験が積めない現状に不満が溜まっていた私としてはまさに渡りに船でした。とはいえG社についてある程度知って納得する必要がありましたし、G社としても私が適性のある人物か確認する必要があるので、面接的な要素を含む面談を行いました。渋谷駅近くにあるG社のオフィスにて社長と直接面談を行い、良い印象だったのですぐに入社したい旨を伝えました。その後入社後の条件や認識のすり合わせを行うためにもう一度会って話を行い、正式に入社意思の提示とG社からの内定通知をしていただきました。

あとは転職の手続きを行うのみとなり、色々と準備が始まるのでした。

退職に向けた相談と手続き

転職先が決まったところでついに会社に退職の意向を伝えるタイミングとなりました。G社は転職の調整次第で入社タイミングは任意で良いとのことでした。とはいえあまりに先すぎるとお互いデメリットが多いので3ヶ月後あたりには退職を済ませる想定としていました。私はすぐに当時の上長的な存在であった営業部長（以降はOさんと表記）に退職に関する連絡を行い、Oさんからは話し合いのために東京に向かうとの連絡がありました。
※会社は岡山にあり、私だけ東京に単身赴任していたのでこのような形になっています

正直なところ綺麗に円満退社とは言い難い感じではありました。もちろん揉めたりはしてないですし、コミュニケーションは冷静に丁寧に行いました。ただ、まだ入社後1年半であることや以前も新卒入社の人が辞めていた背景もあり、会社の人は割とピリピリしていたように感じます。東京に来たOさんと東京で私の面倒を見てくれていた協力会社の営業の方（以降はFさんと表記）と私の3人で退職について話し合いました。就労環境やさらなる成長、会社の方向性などを鑑みて転職することを決めた旨を正直に話しました。Oさんはあまり納得しきれていない感じでしたが、Fさんが私に協力的に話してくださり、ある程度の話し合いをした段階で、あとはOさんとFさんで話すのでここまでで良いと言われました。

その後は事務的に退職手続きが進み、9月末で退職となりました。未経験で雇ってもらっていましたし、私がやらかして迷惑かける場面もあったので申し訳ない気持ちはありつつ、ここに居てもどうしようもないという気持ちもあったので、思い切って良かったと思っています。

引越し

仕事の話からは少しずれますが、元の会社にいたときは家が会社の借り上げ社宅だったため、転職時に引越しが必要となりました。会社が負担していた分の家賃を含めて全額払うようにするならそのまま住み続けるのは問題ないと言われましたが、私が単独で払うにはかなり高い家賃だったので引越しを決めました。

家賃が抑えめで次の職場である渋谷に行きやすいということで、練馬区の駅徒歩15分・築25年の1Rに決めました。路線は西武線・有楽町線・副都心線でした。自分で契約した家はここが初めてでした。以前の家は家具なども付いていたので、新たに生活に必要なものを色々買い集める必要があり結構大変でした。元々給与が低かったことや引越しでお金がかかっていたのもあって、当初はかなり金欠でした。

なんだかんだで引越しも完了して、ここから無事新生活が始まります。

G社にて働き始める

無事に退職も完了して、ついにG社での勤務が始まりました。私が入社した際の社員は、会社の立ち上げからいる社長と執行役員を入れても5人で、それに加えて業務委託のメンバーが2人長くいるようでした。そのため会社としての枠組みやルールはほぼ無い状態で、これからまさに整備していくような過程でした。

G社には親会社がいて、そのグループ会社という立ち位置になっていました。親会社も受託開発を行なっていて規模もそれなりに大きかったので、開発メンバーや営業などは親会社に頼ることが出来ていました。私も親会社の人とはかなり一緒に仕事したり、仲良くさせていただきました。

この後の内容では主に参加したプロジェクトをベースに、時系列で会社や自身の状況の変化などを書いていこうと思います。

最初の仕事 - モバイルアプリのメンテナンス

入社してすぐはSさんとセットで動くように指示されました。最初のプロジェクトはApache Cordovaというモバイルアプリ開発フレームワークで作成されたモバイルアプリのメンテナンスでした。具体的な作業は使用しているプラグインのアップデートというシンプルなものでしたが、意外とCordovaというのが一筋縄ではいかないもので、謎のバグや互換性の欠如などで悩まされました。Cordovaはハイブリッドアプリとして開発できるフレームワークなので、基本的に実装はHTML・CSS・JavaScriptで行いますが、このプロジェクトではプラグインが意図した通りに動作しないことから、プラグイン内部のC++のコードを書き換えたりしました。

とはいえ、このプロジェクトでは基本的にSさんが作業してくださったので、私はそんなにフルで稼働していませんでした。

初の本格的な開発経験と師匠との出会い - サブスクサービス基盤の構築

前述した最初のプロジェクトは小規模でSさんがほとんどやっていたこともあり、私は入社後かなり早い段階で2番目のプロジェクトに加わりました。このプロジェクトは自動車会社で提供するサブスクリプションサービスの基盤となるシステムの構築でした。発注元の自動車会社があり、そこから1次請けの開発会社が5社ほどいて、それらの開発会社の下にたくさんの協力会社が連なっているような体制でした。建設業界などのゼネコンと同じ感じですね。

このプロジェクトでのポイントは下記の通りです。

• 初めてガッツリ開発が経験出来た
• 初めてPHPを使って開発した
• 初めてWebアプリケーションをしっかりと構築した
• 初めてWebAPIを知った
• 初めて性能を考慮した検証と改善を行った
• 初めて脆弱性に対する診断と修正を行なった
• 金額・影響ともにとても大きかった
• 師匠的な存在となる人との出会い

開発経験の土台が作られた

前述している通り、このプロジェクトでは色んな面で初めての開発経験がたくさんありました。ある程度開発を経験している人からすれば当たり前すぎるような要素ばかりなのですが、私は開発経験が乏しかったのでとても大きな機会でした。G社ではこの後PHPを使った開発を中心に行うことになるのですが、それはこのプロジェクトも大きく影響しています。

特にWebアプリケーション、Web APIという概念、それらを実装する際の具体的なソフトウェアアーキテクチャへの出会いは、私の中でもやがかかっていた開発イメージに具体性を与えるものでした。ここでPHPのフルスタックフレームワークであるLaravelに触れ、MVCモデルやORM、バリデーションやseeder、migrateなどの概念についても知りました。

性能やセキュリティといった非機能要件に対する取り組みも初めて行い、こういった観点が必要であることと、具体的な手順としてどういった手段があるのかといったことを初めて学びました。

これらの体験は私にWeb開発の手段を与え、「開発たのしーーー！！」という気持ちを加速させるのでした。

師匠との出会い

このプロジェクトでPjM（プロジェクトマネージャー）であった人（以降はKさんと表記）が、私の師匠的な存在となります。KさんはITバブル（インターネットバブル、ドットコムバブル）の時代にWeb開発の世界に入り、これまでバックエンドプログラムの実装やインフラの構築、その他必要な開発業務に広く関わってきていたベテランのエンジニアでした。

KさんはPjMであると同時にテックリードでもありました。そのため設計や実装は全てKさんにレビューしてもらっていました。私はこれまでちゃんと経験と技術力があって質問が気軽にできる人と一緒に仕事ができる機会が少なかったため、疑問に思ったことは基本ぶつけていたと思います。それがプロジェクトのためになるのと、面倒見がいい人だったので、Kさんは常に向き合って教えてくれたり相談相手になってくれました。

Kさんにはこの後のプロジェクトでもお世話になり、私の成長の原点になった人だったのでかなり感謝しています。

暇になったが故の学び - 社内サーバーの再構築

前述のプロジェクトが一通り納品となり、だんだんと手が空いてきました。次のちょうどよく入れるプロジェクトが無く、1ヶ月ほど手持ち無沙汰になりそうでした。社長（CEO）とCTOが相談した結果、勉強がてら社内サーバーの移行（再構築）をやってほしいと指示がありました。

G社では比較的規模が小さいこともあり、社内で運用するサーバー上で開発に関するデータやツールを管理していました。よくあるVPS（仮想サーバー）でLinuxを使って構築していました。ホスティングにはさくらインターネットを利用していました。しかし、サーバーへの不正アクセスがあり、踏み台にされて他の攻撃に利用されている可能性があるとの連絡があり、急ぎ改善の必要がありました。この時の課題は下記の通りでした。

• サーバーにSSH接続する際の認証方法が公開鍵認証ではなく、パスワード認証になっていたので総当たりで突破されるリスクがあった
  • しかもユーザー名とパスワードが比較的単純なものだった
• 会社の業務で使っている資産を管理しているのに、VPSインスタンスもしくはストレージのフルバックアップがされていなかった
• 接続に関する詳細な制御が行われていなかった
  • プロトコルの制限など
• 当時さくらの提供していたVPS等のIPアドレスが攻撃されやすい可能性

これらの課題をクリアしつつ、新たに社内で使う申請管理システムや勤怠管理システムなども稼働するように整備していました。結果としてAWS Lightsailで構築し直して、自動バックアップの仕組みも整備しました。また、各プロジェクトで使う開発時の検証環境を同様の仕組みで瞬時に構築できるようにしたりと、発展して知見を生かすことが出来ました。

この際も取り組む中でかなり多くの技術・観点・経験を得ることが出来たので、社内改善ではありますがとても有意義な活動になりました。1人でほぼ自由に取り組めたのも良かったです。学べたことはざっくり下記の通りです。

• サーバーの稼働環境に対する理解
• VPSという概念
• 各ホスティングサービスの存在と内容
• AWSでサービスを構築する体験
• プロトコルやIPアドレスなどのネックワーク領域の実践的な取り扱い
• Linux OSへの理解と慣れ
• ApacheやNginxなどのWebサーバーアプリケーションに関する理解と慣れ

初の1からの開発でMVCモデルの限界を知る - チケット管理システムの新規開発

入社後2番目のプロジェクトであったサブスクサービス基盤の構築を行った経験もあり、新規開発を任されることになりました。とはいえ1から開発を行なったことはなかったので、これは私にとって良くも悪くも印象に残るプロジェクトになりました。一応経験豊富なPjMが付いた中でやることになりましたが、開発者は私1人だったのでそれなりにプレッシャーもありました。

要件

このプロジェクトで求められた要件は下記の通りです。

• Webブラウザーからの利用を前提として、Webアプリケーションを開発する
• イベントで販売するチケットを扱う
  • イベント期間に日毎にチケットを購入できる
  • 購入したチケットの内容を確認できる
  • 購入したチケットを電子スタンプで使用済みにできる

使った技術

• フロントエンド ... HTML, CSS, JavaScript(jQuery)
• バックエンド ... PHP, Laravel, MySQL
• 開発環境 ... Vagrant
• 稼働環境 ... AWS EC2, Ubuntu, Nginx

よく出来たと思うところ

このプロジェクトでは決済や電子スタンプなどの要素がありました。これは初めて1から構築するWebアプリケーションとしてはそれなりに難易度があります。ただ、決済は代行決済サービスを使いましたし、電子スタンプもライブラリを使って実装できるものです。ライブラリを適切にアプリケーションに組み込み、うまくパラメータを渡してリクエストしたり、リダイレクトの制御を行なったりという部分が多かったです。今やったら簡単に実装できますが、当時はかなり試行錯誤しながら必死にやっていた記憶があります。

また、稼働当日はチケットが販売される時間も張り付いて稼働状況を確認したり、不具合を検知したら即直してデプロイするなど、気合いでやってました。それもあってか、不具合は多少ありましたが発注元の担当者の方は結構好意的な反応でした。

うまく出来なかったところ

このプロジェクトでは品質面でかなり課題を感じました。品質を担保できなかった要因として下記のようなものがありました。

• 早期リターン、ブロックを小さく保つ、ネストを最小限にする、関数やクラスとして適切に切り出す、といったコーディングの基本が身に付いてなかった
  • コードレビューをする人がいなかったので指摘と改善がなかった
• LaravelのMVCモデルにそのまま実装を組み込んだため、ビジネスロジックが全てControllerに集約され、典型的なFat Controllerになった
• テストコードを書いてなかったので、手動テストに頼っていた

プロジェクトを通じて感じたこと

初めて自分1人で1からWebアプリケーションを開発して、それが実際に商用として稼働したという経験はかなり刺激的で自信に繋がるものでした。この経験はその後の開発モチベーションを大きく上げる要素になったと思います。

その一方で、開発スキルの不足による品質の懸念を強く感じました。この経験からより良いコーディングスキル、適切に分割され依存関係が整理されたソフトウェアアーキテクチャ、テストのコード化・自動化による品質担保と開発の高速化など、Webエンジニアとして求められる要素への関心が強くなっていき、これらを伸ばすことに関する取り組みが増えていきました。

チーム開発・顧客との対話の難しさを感じる - ポータルサイト・問い合わせシステムの開発

前述のプロジェクトではPjMはさほど関与がなく、要所で調整したりお膳立てしたりしてくれていました。新たに始まった生命保険会社向けのプロジェクトでは、結構がっつりとPjMが関与することになりました。この時のPjMは私の入社半年後ぐらいに入った中堅の方でした。発注元である生命保険会社からはグループ子会社の社員が親会社に出向して担当者となっていました。

このプロジェクトでは、すでに稼働しているポータルサイトを改修しつつ、新たに問い合わせ管理システムを構築することになりました。期間は半年ぐらい、実装作業を行うのは私1人で、発注元担当者とPjMで仕様の整理をしつつ私も必要に応じて全体の作業に関与する形となっていました。この時の条件を簡単にまとめると下記の通りです。

• 既存のポータルサイトはPHP5系で実装されている（確か5.2ぐらいだったと思う）
  • この時の最新バージョンは7系（確か7.4だったと思う）
• 問い合わせ管理システムの構築方法は基本的には制限なし
  • ただし細かい要求事項を実現する必要がある
• 稼働するサーバーは新たに用意するマシンのLinux上に構築する（ディストリビューションは覚えてない）

どのように実現するのか

最初に話し合った段階では、既製品やある程度形になっているOSSなどを使って実現する方法についても検討されました。問い合わせ管理と言いますが、要するに課題管理のような側面が強いので、既製品でも近しいものはいくつかあります。ただ、担当者と話し合ったところ細かい要求を吸収出来るものが見つからず、結局スクラッチで開発する方針となりました。

開発の進め方

この開発では下記のような流れで進めていました。

1. 要件・仕様を整理して言語化
2. 仕様に合わせて画面のワイヤーフレームを作成
3. ワイヤーフレームに合わせて実際に Webブラウザ上で動作するモックアップを作成する
4. ワイヤーやモックアップが形になった段階で、それぞれ発注元担当者及び発注元責任者へ見てもらってフィードバックを貰う
5. フィードバックに合わせて修正をする
6. ある程度形になったモックアップをそのまま使って実際のアプリケーションを開発する

Vue.jsとの出会い

このプロジェクトでは、JavaScriptフレームワークであるVue.jsを初めて使ってフロントエンドを開発しました。私はプロジェクトが始まった段階ではVue.jsを認知していなかったのですが、2つ目のプロジェクトで会った師匠的存在であるKさんに教えてもらって、触れてみる中ですっかり感動してしまいました。これまでフロントエンドで動的制御を行う際はバニラJavaScriptかjQueryを使うぐらいしか知らなかったですが、Vue.jsのリアクティブさや双方向バイディングという体験はとても新鮮なものでした。

この時にVue.jsと合わせてBulmaというUIフレームワークやBuefyといったCSS in JavaScriptライブラリにも初めて触れました。これもかなり衝撃でした。自分で頑張ってCSSを書かなくてもイケてるUIが簡単に実装できるからです。しかもこういったUIフレームワークはほとんどの場合class指定するだけで良かったり、Vue.jsなどに対応したコンポーネントをimportして使用する形になるため、コンポーネントとしてパーツを実装していくのとかなり相性がいいです。

すっかり気に入った私はこのプロジェクトでVue.js、Buefyを採用することを決定しました。一番の採用モチベーションは自分が使いたかったからなんですが、Vue.jsだとSPA（シングルページアプリケーション）として実装できることから画面モックアップを作りやすかったという建前は一応ありました。モックアップがあるとバックエンドを含む本格的な開発に着手する前の段階で、ユーザーのフィードバックを得やすくなるため、手戻りを減らしステークホルダーとの認識齟齬を軽減するのにかなり効果的です。

Vue.jsの実装での失敗

Vue.jsでの実装はめちゃくちゃ楽しく、モックアップとして実装したものをほぼそのまま実際のアプリケーションに組み込めたのでとても良かったです。ただ、結果として私の実装にはいくつか問題がありました。

• コンポーネント分割という認識の無さ
• ロジックの切り出しと共通化
• テストコード等の品質を担保する要素の不足

一番問題だったのはコンポーネント分割ということへの認識が全然なかったことです。初めてこの手のフレームワークを触ったこともあり、ベストプラクティスを全然知らない状態でした。そのため、ページコンポーネントにすべてを詰め込んでいました。するとどうなるでしょうか？一つのページコンポーネントが普通に2000行超えたりします。可読性なんて皆無なので、自分で書いたコードを読んでるのにめちゃくちゃしんどかったです。

次にロジックを切り出すこと、共通化することが全く行われていなかったことです。これはコンポーネント内に関してもコンポーネント間の横断的な部分どちらもです。Web APIでバックエンドから受け取った値をそのままv-ifディレクティブで判定させるような書き方に溢れていました。これをやるとある程度複雑な実装をしたときにコンポーネントの表示制御とビジネスロジックが混ざって読んでて意味が分からなくなります。しかも複数のコンポーネントで同じ判定をそれぞれ別で書いていたりしたので、バグを直しても違う箇所の似た制御ではまだバグってるような状態になってました。

テストコードを全く書いてなかったのも品質低下を後押ししていました。まあコンポーネントやロジックを適切な粒度に切り出していない時点でテストも書けないようなもんですが、トリプルパンチでバグがとにかく多かったです。

多くの教訓を得る痛い目にはあいつつ、実装するのはめちゃくちゃ楽しかったので今後もVue.jsとは長い付き合いになります。

Dockerとの出会い

例のごとくKさんにDockerというコンテナ技術、実行環境を教えてもらいました。これも私の開発体験に半端じゃない影響を与えました。これまでの開発では、最初の方のプロジェクトで採用されていたVagrantという仮想化ツールを使って開発を行っていました。これはWindowsなどのOS上で丸々別のOS環境を実行するようなイメージです。稼働環境で使うLinuxイメージで起動して、その中に稼働環境と同じMySQLなどのDB、ApacheなどのWebサーバーアプリケーションを入れる感じでした。ただしVagrantはめちゃくちゃ処理が重く、起動なども時間がかかりまくります。そのため開発体験としては微妙なものでした。

Dockerに触れて感動した要素は下記の通りです。

• 数行～数十行程度の設定ファイルを書いてコマンドを叩くだけで実行環境が起動する
  • そのため環境の構築・破棄・再構築が気軽に出来る
  • しかも早い
• カーネルをホストOSに依存することでコンテナの動作が高速
• Dockerの設定を本番環境に流用することができる

この後のバックエンドを含む開発は、基本的に全てDockerを採用するようになりました。

プロジェクトを通じて感じたこと

このプロジェクトでも多くの反省点がありました。

反省1 顧客とのコミュニケーションとフィードバックループをもっと細かくすべきだった

開発前から要件や仕様について様々な検討が行われていましたが、やはり実際に動くもの無くして細かいフィードバックは貰えません。モックアップにより画面の構成などはある程度認識合わせしていましたが、バックエンドの実装を行ってからも結構フィードバックがありました。もっと顧客とコミュニケーションをたくさん行い、動くものをベースに細かくたくさんフィードバックを貰うことを努力すべきだったと思いました。

反省2 実装への習熟不足

これは毎回のプロジェクトで反省している気がしていますが、ベストプラクティスを把握できていなかったり、品質を担保する仕組みが導入できていないことによる開発後半のバグの増加、開発の遅延が結構ありました。ここはエンジニアとして研鑽していかねばならぬ点なので、個人的な開発などでもより良い方法を模索するようになりました。

反省3 チームとしてPjMや担当者ともっと進め方を相談すべきだった

これはやってなかったわけではなく、むしろ結構やっていたと思うのですが、それでもやはり足りなかったと思います。実装部分に関してもどれくらいの粒度でフィードバックを貰うようにするのか、どの機能を優先度高くするのか、スコープとして入れる必要がさほど無い部分はないか、などプロジェクトを成功させるために会話できることはもっとあったと思います。

コロナによるリモートワークへの移行

2020年序盤からの新型コロナウイルスの感染拡大に伴って、G社では3月中盤あたりからリモートワークが始まりました。初期はリモートワークを本格的に行っている企業もそこまで多くなく、試験的な取り組みとして暫定的な期限付きで開始しました。その後も感染が拡大していく中、リモートでの開発業務はチャットツールやミーティングツール、データ共有サービスなどの既存で使用していたもので実現できることが確認できたため、そのまま期限なしのリモートワークに移行しました。

通勤が無くなって楽な部分はありつつ、これまでと環境が変わることで制度や働き方などで多少の混乱もありました。しかしITの開発というのはリモートワークに親和性が高かったので、顧客なども理解を示してくれるところが多かった印象です。以降のプロジェクトは基本的にリモートワークにて行われました。

初めての本格的なインフラ構築 - AWSにおける環境移行

2ヶ月間という小さめのプロジェクトで、すでに稼働しているWebアプリケーションのインフラを移行するプロジェクトを担当しました。インフラはAWS Elastic Beanstalkで構成されていたのですが、Webアプリケーションで使用しているPHPのバージョンが古くなり、Elastic Beanstalkでのサポートが切れるとのことでした。それでElastic Beanstalkを使わない環境を1から構築することになりました。

この時作ったサービス構成は下記の通りよくある構成です。

• EC2のインスタンス上でWebアプリケーションを実行する
• RDSでデータベースを実行する
• ElastiCacheでセッション用のストアを実行する
• 上記サービスを2つのAZに冗長化する
• Application Load Balancerで、クラインアントサイドからのリクエストを各AZのEC2へバランシングする

業務でこれらの構築を行なった経験は無かったですが、下記のような条件だったので任せていただいたのだと思います。

• 社内でのVPS運用のためにLightsailを使ってシンプルなサーバー環境は構築していた
• 過去のプロジェクトでは構築はしていないものの、似たような構成で稼働するWebアプリケーションを開発していた
  • 開発後のデプロイやチューニングにも加わっていたので、雰囲気どんなものかは以前から見ていた
• プライベートで遊び勉強がてら今回作ったような構成を構築していた
• 開発環境を整備するためにDockerの設定を作る中で、アプリケーションの実行環境についての知見がそれなりに貯まっていた

このプロジェクトでは他の経験が浅いメンバーに移行後の動作検証を担っていただいていました。ただ前提知識や実施手順を共有したりと、私が構築のかたわらサポートする体制でした。私の構築作業はプライベートでの構築経験があったおかげでさほどつまづくこともなくすんなりいき、サポートも十分できる状態だったので、比較的余裕を持って完了できたプロジェクトでした。

ちなみにこのプロジェクトの利益率が良すぎたという話を後から聞いたので、「俺もだいぶ会社に貢献できるようになってきたんだな〜」という嬉しさもあったのでした。

セキュリティ意識の温度差を感じる - SaaS契約管理サービスの開発

これは期間が3ヶ月ほどで、それほど新しく得たものが多くなかったのでそこまで記憶が残ってないプロジェクトです。フロントエンドをVue.js・バックエンドをPHP/Laravelで構築して、GCPでホスティングするプロジェクトでした。今回はフロントエンド担当の若手1人と、バックエンド＆インフラ担当のベテラン1人と、フロントエンド＆バックエンド担当の私、という開発者3名体制でした。

ベテランの方は最初にGCPで実行環境を構築後、バックエンドでSAML認証によるシングルサインオンの箇所を実装していました。若手の方はモックアップをまず作って発注元とすり合わせ後、SPAとして開発を進めていました。私はバックエンドを開発後にフロントエンドを手伝いに入る感じで動いていました。

印象的だったのが、自分の実装がある程度進んでから若手の方が実装した箇所を後から見てみると、クライアントサイドで実行される箇所で権限系の処理分岐を実装していたり、XSSのリスクがある実装が存在したり、定数を作らずにマジックナンバーが多用されていたりとちょっと悲しい感じになってました。最低限は直しつつ、開発が遅延気味だったので目を瞑った部分もありました。

私も初めてフロントエンドを担当した際はそこら辺の考慮はあまり出来ていなかったので気持ちは分かりつつ、セキュリティ面は重要だからある程度担保しないとなぁと感じたのでした。これは若手の人が悪いんじゃなくて、フロントエンドも見れるベテランエンジニアがいたのにレビュー体制を組まなかったプロジェクト自体の問題だと思います。ただ、プロジェクトを舵取りしていたPjMだけを責めるのは違うなーとも思っていて、そこら辺の知見を持っているエンジニア側がちゃんと意見を出して進め方相談していくべきだったな、と後から思いました。

受託開発で遅延していたり炎上気味だと品質やセキュリティがおざなりになるのほんと良くない。

主体的な取り組みによる成果 - コーポレートサイトの作成

これまで書いてきたプロジェクトと並行して、プライベートでVue.jsによるフロントエンド開発のキャッチアップをしていました。その一つとして、Laravel＆Vue.js＆VuetifyによるSPAを作成しました。今見ると実装に改善の余地は多々あるものの、個人的には1人でそれなりのレベルのWebアプリケーションを作成できたので、かなり満足感がありました。これを開発している時は半年ほど土日もほとんどの時間をプログラミングに費やしていました。

これをサーバーで動く状態にして社内に公開したことで、社長やCTOにフロントエンド開発のスキルを一定認めて貰えたというのもあって、その後フロントエンド開発を含むプロジェクトへのアサインなど多くしていただけたのかと思ってます。

そして、さらなる集大成という感じになったのが、自社のコーポレートサイトのリプレイスでした。元々G社ではWixで簡易的に作ったWebサイトを使っていました。しかし、Wixは管理コストは低いものの、独自のスタイルでのコンテンツを追加したり、細かいデザイン調整をするのには向いていませんでした。それで社長へコーポレートサイトのリプレイスを自分から提案して、社内のWebディレクターと一緒に実施することが決まりました。

これは対顧客のプロジェクトではありませんでしたが、かなり頑張りましたし、結果もしっかり出せたと思っています。基本的にこの作業はメインの業務とは別に進めており、フルの時間を業務に当てつつ隙間時間で進めるような体制でした。ただ、隙間時間でやれることは大して多くないので、実際には開発作業のほとんどをプライベートな時間で進めていました。そして夏に着手してから半年ほど後の年末ギリギリに新規サイトの公開までこぎつけたのでした。

良かったこと

このプロジェクトで良かったと思う点は下記の通りです。

• Nuxt.jsのベストプラクティスにある程度則って開発が出来た
• Vuetifyを使ってモダンかつ効率的な開発を行えた
• CMSおよびHeadless CMSに初めて触れることができた
• 動的制御が少なかったのもあるが、ほぼバグなどが無かった
• Vue.jsのコンポーネントを実用的で、保守性・可読性の高い粒度に分割して実装できた
• 限られた時間の中で期限までに公開するという目的のため、優先度の明確化と初期スコープの調整を正しく行えた
• サイトのコンセプト、訴求対象、導線設計など、Webサイトやオウンドメディアとしての高い抽象度の設計から明確に行えた

実装以外の部分は、一緒に開発を進めてくださったWebディレクターの方がとても優秀で情熱があったおかげでもあります。一緒にお仕事させていただけてとてもありがたかったです。

良くなかったこと

逆に良くなかったと思う点は下記の通りです。

• 優先度設定に基づいて進めていた影響もあるとはいえ、全てのサイトコンテンツをCMSに集約できなかった
  • 当初は動的制御だけ用意してコンテンツをデータファイルとして持たせて、取得元をCMSへ移行するつもりだった
  • 退職までにやりきれなかった
• 公開当初にお問い合わせフォームなどの投稿に関するメール転送がうまく動いておらず、社長に迷惑をかけてしまった

やって良かった

このプロジェクトは自分発案の自分主導でやりましたが、とても良い体験・勉強になり、やりきれた自信にもなり良かったです。実際に公開されて使われ続けていることが分かるものはやはり良いですね。

東京から埼玉へ転居

前述の通りコロナによってリモートワークに移行したわけですが、私の家は通勤を意識していたことや入社当時の収入に合わせて選んだこともあって快適に在宅で仕事するには課題が多くありました。居室が狭く、日当たりが悪く、壁が薄いといったストレスフルな環境に嫌気がさしていたこともあり、半年前ぐらいから引越し資金を貯めており、2020年9月についに引越しました。

新しい家を探す上で求めていた条件は下記の通りです。

• 家賃が当時の家に対してプラス3万程度に収まること
  • 収入が大きく増えたので家賃上限も上げた
• 駅から徒歩5分以内
  • 当時の家が駅から徒歩15分ほどでめっちゃ辛かった
• 築浅で外観や内観が綺麗であること
  • ずっと家にいると当時の家のボロさは結構気になった
• 居室が7〜8帖以上あること
  • 6帖はずっと家にいることを考えると狭いと感じた
• バス・トイレが別になっていること
  • 当時の家は一体になっていたが、結構不快だった
• 通勤しようと思えば1時間以内で行けること
  • 今後の可能性も考慮して念の為
• 窓を開けた際に閉塞感や周囲からの視線が少ないこと
  • 当時の家が窓を開けるとすぐに駐車場で、横の道路からも丸見えなのがストレスだった
• ある程度の防音性があること
  • 当時の家は周囲の生活音がめっちゃ聞こえててそれなりにストレスだった

結果として全ての条件を満たす物件を見つけて引っ越すことができました。通勤に関しても家から駅までが近くなったことで以前とほぼ変わらない時間で行ける結果になりました。広くて綺麗で防音性が高い環境になり、仕事に快適に取り組めるようになりました。

ネットバンキングアプリのバッチ改修 - 気づいたら教える側へ

フロントエンド成分が多くなってきましたが、久しぶりにバックエンドだけのプロジェクトが来ました。といっても今回は私は直接作業せず、新しく入社した経験が浅い方の教育・サポート役です。プログラミングスクールを出てすぐぐらいのスキルとのことで、基本的な実装方法や仕事の進め方など、包括的にサポートしていました。

プロジェクトの内容自体は、発注元である銀行で稼働しているPHPのバッチ処理を改修する比較的小規模なものでした。最初にある程度作業の内容と量を見積もって、段階ごとに区切って小さく挑戦してもらう感じにしました。これは丁寧に手取り足取り教えても定着しずらく、ある程度自分で考えて模索する過程もあった方がいいという考えからです。とは言っても割と優しめにやっていた気はしています。

まず、PHPやLaravelフレームワーク、またその前提になっているWeb技術やWeb開発のエッセンスを知っていただく必要がありました。同時期にもう1人経験が浅い方が入っており、2人に対してまとめてオンボーディングを実施しました。

オンボーディングの内容としては、PHP/Laravelで私が用意した簡単なToDoアプリの実装チュートリアルを実施して、それらの実装を進める中で各種知識のインプットを差し込んでいく感じです。私の考えとしては、体系的な知識だけを定着させるのは難易度が高く、実践的取り組みとの関係性を感じながら学ぶのが効果的だと思っています。それっぽく書いてますが、オンボーディングを急に依頼されて焦りながらチュートリアルなどの用意をしたのでだいぶ即席でした。

下記のチュートリアルを使って実際に実施しました。数時間ほどオンラインでミーティングをつなぎながら作業していただき、不明点があれば都度説明するような感じです。

チュートリアルに含まれる要素

チュートリアルには、一般的なWebアプリケーションとして動作させるため要素、各種開発の中で必要になる要素をざっくり盛り込んでいます。

• Dockerを使った開発環境
• Webアプリケーション、WebAPIを作る一連の流れ
• リソースに対するCRUDのパターン
• ルーティング、モデル、ビュー、コントローラーなどのLaravelフレームワークの基本アーキテクチャ
• migrate、seed、validate、factory、test
• WebAPI client、DB clientなどの開発ツール

チュートリアルを進める中でインプットしていた要素

• Webの仕組み
  • クライアントサイド、サーバーサイドの処理関係
  • 通信プロトコル
  • リクエスト、レスポンスのフォーマット
• RESTのお作法
• Webアプリケーション、WebAPIの違い
• コーディングしたプログラムが実際に実行されるまでの流れ
• Webフレームワークの概念
• ソフトウェアアーキテクチャ、デザインパターン

やってみて思ったこと

普段自分が何気なくやっている作業を体系的にまとめたり、観点を言語化するのは意外と大変でした。どこまで前提知識を伝える必要があるのか、どういった文脈であるか、なぜその要素が大事なのか、などを意識してました。

技術的なことはやっていく中で少しずつ身につけていっていただければいいのですが、割と社会人としての基本スキルに近い仕事の進め方の方が重大だと感じました。分からないことを分からないと伝える、自分の質問を上手くまとめて伝える、時間管理を意識して作業を進める、挑戦する姿勢とフォローを求めるバランス、自分の中で溜め込まず適切に連絡したりアラートを上げる、といったことはなかなか最初からできるものではないですね。私としてはそういった要素の方が大事だと思って、サポートの中で伝えるようにしていました。

過去最大の炎上 - クレジットカードアプリの開発

これまではWebアプリケーションをひたすら開発していましたが、ここにきてモバイルアプリの開発プロジェクトがきました。発注元は銀行で、そこで使われるネットバンキング用のアプリでした。iOSとAndroidをそれぞれネイティブで実装することになりました。私の実装範囲はiOS
ということで、言語としてSwiftを使って開発することになりました。

このプロジェクトでは私がモバイルアプリおよびSwiftを未経験ということで、G社の親会社から経験のある若手のエンジニアが参画してくださって、開発をリードしてくださることになりました。これまでは初めての技術要素でも経験者がリードしてくれるプロジェクトはあまり多くなかったので、今回の手厚い体制に比較的安心していたのですが、実際にはこの後つらい大炎上が待っているのでした...。

体制

細かい説明をする前にこのプロジェクトの体制を書いておきます。

• PjM 1名 ... 入社して日が浅いがディレクター経験などはそれなりにある中堅
• PMO 1名 ... PjM経験および開発歴の長いベテラン
• テックリード 1名 ... 技術者極振り。経験値が多すぎる大ベテラン（レジェンド）
• 管理者向けWebアプリケーション開発チーム
  • リーダー 1名 ... それなりに経験がある中堅
  • メンバー 1名 ... Webはそれほど経験が多くないが、他領域で経験が多い中堅
• 利用者向けAndroidアプリ開発チーム
  • リーダー 1名 ... テックリードが兼任
  • メンバー 1名 ... 覚えてない（ごめん）。たぶん中堅
• 利用者向けiOSアプリ開発チーム
  • リーダー 1名 ... 親会社から手伝いにきた、それなりに経験と能力がある若手（ただし後にテックリードと交代）
  • メンバー 1名 ... 私

また、商流としては [ 発注元（銀行） → 1次請負会社（以降はC社と表記） → 親会社 → G社 ] という関係でした。

PjMは入社したばかりで、PjMとしての経験も浅かったようですが、経験豊富な執行役員の方がPMOとしてサポートする形になっていました。また、レジェンド級のベテランエンジニアがテックリードとして入っていました。このテックリードが各開発チームを技術面で統括する形になっています。それぞれの開発チームには別途リーダーが配置されていますが、兼任もありました。

不穏に暇な期間

このプロジェクトは11月付近から動き出したものの、当初は要件や基本仕様を顧客とすり合わせるためにメインの開発作業は進んでいませんでした。ただ出来ることはやっておくということで、開発環境を整備したり、間違いなく必要になるだろう一部機能を実装している状況でした。その中で今回のアプリで使うMVVMアーキテクチャのキャッチアップをしたり、基本実装についてのコードレビューをしてもらっていました。

今回親会社から来てもらっているiOSアプリ開発チームのリーダーは、その後に別プロジェクトもあることから開発完了を見込んでいる年末までの契約でした。その後はテックリードと私で巻き取る想定です。しかし、要件等の調整が予想以上に遅延しており、開発全体がズルズルと後ろにズレていっていました。しかし、正確に現状を把握しているのはPjMだけだったので、開発メンバーは不安を覚えつつもそこまで悲観的な気持ちにはなっていませんでした。

危険を感じ始める

やっと開発前の調整が完了して、いざ本格的な開発がスタートしたのは年末近くになってからでした。iOSアプリ開発チームのリーダーは離脱することになっていましたが、私も1人である程度開発できるぐらいにはキャッチアップしていたのと、テックリードがiOSアプリ開発チームのリーダーも兼任するということで一旦体制はなんとかなりそう（？）という感じになりました。正直あまり大丈夫じゃない気もしましたが、他にできる人もいない状況でしたし、こういった無理のある体制はこれまでもあったので、「こんなもんなのかなぁ...」と受け止めるしかないのでした。

しかし、この時メンバー全員がこの状況を楽観的に捉えすぎていました。実際開発前に遅延している状態だったので、明確な打開策を打つべきでしたが、この時は少し期限が延ばされる程度の調整で終わりました。

信頼関係とコミュニケーションの崩壊

あくまでは我々G社が契約しているのは1次請負会社であるC社でした（親会社は身内なので商流には入るがここでは除外）。また、C社が開発および品質の管理を行っていたので、開発の進め方の決定、コードレビュー、納品の手続きはC社に向けて行うことになっていました。しかし、C社のPjMや品質保証担当とG社のPjM・PMOとの間で度々衝突が発生していたようです。C社は以前に別のプロジェクトでも関わっており、仕事を進めやすい相手ではないことはうっすら感じていました。ただ、今回は担当者が特に癖が強かったらしく、ミーティングの場で暴言・人格否定の言葉が飛ぶなど信じられない状態になっていました。

もちろんG社の進め方や体制、アウトプットの質にも問題があったのだろうとは思いますが、両社は同じ開発成功を目指すチームとしてのまとまりを作ることができず、完全に利害関係が対立した敵のような状態になっていました。これらの信頼関係やコミュニケーションの崩壊は、この後の炎上を加速させる大きな要因となりました。

実装面での諸問題

実装面でもいくつか問題がありました。ざっくり挙げると下記の通りです。

• C社から開発基盤という名目で提供されたオレオレフレームワークが使いにくく、開発に混乱を生んだ
• C社のコードレビューに制限が多かった
  • 確認してフィードバックが来るまでがとても長い
  • 最初に提示されていないルールを大量に後出しされる
  • リポジトリが別になっているので、レビューのたびにソースコードをC社へ展開するのに手間と時間がかかる
• テックリードが完全にキャパオーバーになっていた
• ある程度実装が完了した画面について仕様レベルからひっくり返されることがあった

C社側が関連する部分については、C社の品質保証担当が不親切＆敵対的ということで改善のための取り組みがなかなか行えない悲しい状態を生み出していました。最後まで担当者を変えなかったC社は本当に何を考えていたのか謎です。

テックリードがキャパオーバーになるのは当然と言えば当然の結果でした。テックリードは開発全体の調整、Androidアプリ開発チームのリーダー、iOSアプリ開発チームのリーダー、そしてリーダーとしてのサポートやレビュー以外に難易度の高い実装業務も担当していました。これを1人の人間にやらせるのは体制としてあまりにもおかしいです。まぁレジェンドだったのでそれなりにこなしてしまっているのが体制の改善を遅らせる要因でもありました。

また、実装がある程度形になってC社や発注元に見せるタイミングになって、仕様レベルの変更を要求されたりというよくある悲劇もしっかりありました。

体制の諸問題

テックリードは技術者として大変優秀で経験も豊富な方でしたが、プロジェクトマネジメントスキルが高いわけではありませんでした。というよりそちらへの関心が低いので手を動かす役割に留まっていたのだと思います。それ自体は全然良いのですが、その人がボトムアップでPjMに開発体制やプロジェクト進行の改善について働きかけることはあまりありませんでした。それどころか、プロジェクトとしての優先順位などより技術者としての興味関心で必要以上に特定の機能を作り込んだりしている側面もあったように感じています。そこはPjMがしっかり舵取りする必要がありました。

PjMは前述した通り、入社したばかりでPjMとしての経験もそこまでありませんでした。それを見込んでサポートに入るはずだったPMOは別プロジェクトで手一杯になっており、あまりこちらのプロジェクトに関与できていませんでした。そしてPjMは遅延の発生やC社との関係悪化についてそれとなくはPMOなどに相談していたものの、社長（CEO）には明確にアラートを上げていませんでした。そのため、社長は明確に炎上状態になってからプロジェクトの実態について把握し、そこから火消しのために奔走し始めました。

トップダウンでの制御が機能不全になっているので、ボトムアップでの働きかけに期待したいところですが、このプロジェクトはそこにも阻害要因が多くありました。まず、テックリードとAndroidアプリ開発チームのリーダーおよびメンバーは業務委託で参画いただいているフリーランスの方でした。また、iOSアプリ開発チームのリーダーも親会社の方でした。そのため社内の事情もあまり把握しておらず、自身の役割以外のことへの要求も責任も無い立場でした。

また、数少ない社員である私はこのプロジェクトではiOSアプリの開発キャッチアップを主任務としており、そちらに注力している状態でした。なので精神的にもそちらで手一杯でしたし、要件や仕様の整理などの上流工程や顧客とのやりとりに基本的に関与していませんでした。そのため正確な状況把握や改善のための働きかけにつなげることができませんでした。

炎上稼働で価値観が変えられる

すでにたくさん書いた通りプロジェクトは大炎上中であり、テックリードや私の稼働時間はとんでもないことになっていました。特にテックリードの方は元々ワーカホリックであり、さらに炎上していることもあって月の稼働時間が500時間ほどになっていました。普通に3〜4日ぐらい寝ていないことはザラで、どんなに夜中でも連絡が返ってきました。流石に私はそんな人間をやめてるような稼働は出来なかったですが、それでも月の稼働時間は300時間ほどになっていました。基本的に1日12時間ほど働いて、土日もフルで出勤するような感じです。これが2〜3ヶ月ほど続きました。

寝ている時間以外は常に仕事しているような状態だったので、楽しみが食べることだけになっていて、このプロジェクト期間だけで5kg以上太りました。また、働いている時は若干ハイになったような感じでやれてたのですが、いざ時間を作って休むと無気力すぎて何もできない抜け殻のようになっていました。

それまでの私はプライベートでも仕事関連のことをしたり、次の日の朝まで業務のプログラミングをするようなタイプではあったのですが、この経験を経てから以前よりプライベートに業務を持ち込まなくなりました。また、稼働時間に関しても自分や周囲の人達が出来るだけ長く働くことの無いようにかなり気をつけるようになりました。

また、この経験を経て受託開発そのものやウォーターフォールモデルでの開発に対する嫌気もかなり増幅してしまい、同時にそんな開発を受け入れてしまっているG社へとどまる気持ちも薄れてきているような感じでした。（ただし今すぐ辞めたいというような感情では無いです）

サーバーレスの可能性に触れる - ECサイトにおける外部連携システムの開発

炎上も落ち着いたあと、1ヶ月ほどの短さでしたがAWSのサービスを使ったサーバーレス構成を構築するプロジェクトに携わりました。既存のECサイトにて行われたアクションをトリガーにして、Facebookなどのコンバージョン管理サービスへ通知するものでした。使用したサービスはざっくり下記のとおりです。

• Amazon Route 53
• Amazon API Gateway
• Amazon Kinesis Data Firehose
• Amazon S3
• Amazon SQS
• AWS Lambda

これまでこういったサービスを触ったことがなく、サーバーレス構成も構築したことが無かったので、これは新たな概念や手法を知る機会となってとても勉強になりました。また、一緒に構築を行っていたG社のCTOおよびフリーランスエンジニアの方がどちらもベテランだったので、そういう意味でも良い刺激を貰うことができました。

このプロジェクトはただただ良かったです。

未知の領域への挑戦 - Shopifyアプリの開発

私がG社に在職中に最後に携わったプロジェクトは、物流業務を行うShopifyアプリの構築でした。ShopifyはECのプラットフォームで、ShopifyアプリはShopifyと連携して利用することできるWebアプリケーションです。ただ利用者からはShopifyに組み込まれたアプリとしての体験となっており、一般的なWebアプリケーションとは異なる趣です。基本的にアプリ内で使用するデータもWebAPI経由でShopifyから取得する形になっています。

このプロジェクトは正直結構大変だったのと、やり残した感があるものでした。大変だった要素はざっくり下記のとおりです。

• Shopifyに初めて触れたので、概念や仕様などに不明点が多すぎる状態から始まった
• Shopifyアプリという概念についての情報があまりネット上に存在していないため、参考にする情報源を探すのに苦労した
• Shopifyアプリ向けに提供されているWebAPIでは、RESTよりもGraphQLが推奨されており、機能もGraphQLのほうが拡充されていた
  • そのためGraphQLを採用したが、初めて触れる技術要素だったため、慣れるのに時間がかかった
• Shopifyアプリとして使用するための認証の仕組みを理解するのが難しかった
  • おそらく根底技術に対する私の知見不足
  • そのためフレームワークとしてサポートされているOSSを採用したが、それはそれで独自性を強める要素になって参考情報を集めるのに苦労した
• 当初はもう一人フリーランスの中堅のエンジニアと一緒に進めていたが、途中でその方が離脱したので負荷が大きくなった
• 後から加わってもらったエンジニアが2人いたが、どちらも開発経験が比較的浅かったので、私がリーダーとしてプロジェクトの推進や技術的なフォローをする必要があった

一方で良かった点としては、下記のとおりです。

• 発注元との直取引だったため、無駄なコミュニケーションコストが生まれなかった
• 発注元の担当者が非常に開発に対して理解があり、協力的な方だった
• 物流のドメイン知識は、発注元の担当者にヒアリングしたり、一緒に議論することで把握することができた

一応私の退職が近づいたタイミングでリーダーとしての役割は残ったメンバーに引き継ぎを行いましたが、技術面やプロジェクトの推進については不安が残る状況だったので、ベテランのCTOにサポートをお願いしました。その後どうなったのかは詳しく聞いていませんが、炎上などはせずにプロジェクトは推進されていると風のうわさで聞いたので、とりあえずはホッとしています。

在職中に携わったプロジェクトについての全体的な感想

Webのフロントエンド・バックエンド・インフラ・モバイルアプリなど、Web領域における広い範囲で開発に携わることができました。また、ITにおける開発の難しさやあるあるな事象などの、経験しないと分からないようなことを知れました。さらにプロジェクトマネジメントや開発手法などの抽象度の高い観点についても触れることができました。個人としてモチベーション高く取り組んでいたこともあるとは思っていますが、G社には経験する機会を多く与えていただけたのだと思っています。その点はとても感謝しています。

心残りというか残念だったこととしては、G社において開発経験が多く一番技術力の高かったCTOと一緒に仕事をする機会があまりなかったことです。ところどころでサポートいただいたり、教えていただいたりという機会はありましたが、もっと多くのことを学びたかったという思いはありました。

G社について

これまでプロジェクトについて詳細に書きましたが、G社自体にフォーカスした内容はあまり書いていませんでした。なので少し書いてみます。

待遇について

入社直後は新卒並みの給与でした。これは経験やスキルがなかったので仕方ないと思います。その後は1年ごとに評価に応じて給与が上がっていきました。頑張って働いていたのでそれなりの額を昇給していただけて、入社時と退職時では結構な昇給幅になってました。ただし、一定以上の給与になるとみなし残業時間が含まれるようになるのは少し嫌でした。

余談ですが、残業がそれなりに多かったので残業代でかなり貯金できました。不本意な部分もあるので素直に喜べない部分もあります（笑）

開発について

Webの受託開発ということで、かなり様々な背景を持つプロジェクトに携わる機会がありました。様々な領域への知見を広げ、自身の可能性を模索できる良い環境であったと思います。その一方で、SIer的な開発に嫌気がさすことも多かったです。ウォータフォールモデルによる後戻りのできない開発、開発メンバーのスキルを軽視した人月重視の体制、品質や開発プロセスの杜撰さ、顧客との対話の欠如、といった要素が私の中でモヤモヤとして大きくなっていました。ただしこれは私がこれらの課題に対して解決能力を持っていなかったということでもあります。在職期間の終盤や転職時には、これらの点をかなり意識して行動するようになりました。

社内の取り組みについて

係のような枠を作って、メインの業務とは別に社内改善や発展的な取り組みを行っていました。職種関係なく参加して、営業やマーケティングの施策について検討したり、受注を拡大していくための技術要素のキャッチアップを行ったり、社内交流を効果的な行う施策を行ったりと、意欲的に活動されている方が多かったです。私としても自分の職種に捉われない横断的な取り組みは刺激になりましたし、目の前の仕事以上のことをするという意識を育てる上で良い活動の場だったと感じました。

また、評価制度を丁寧に整備したり、休暇や学習サポートなどの福利厚生の拡充、会社理念を明確にして定期的に周知と見直しを行うなど、小さい会社ながら頑張っている部分は多くありました。

社員について

G社に入社した時点では社員が5名ほどでしたが、私が退職するときには20名を超えていました。さらに在職中に転職に伴って退職された方も多くいたため、多くの方々と関わる機会がありました。小さい会社だったので社員間の障壁が無く、和やかな雰囲気で仕事できていた印象です。退職後も連絡をとっていたりお会いする方もそれなりにいます。そういう意味でも価値ある3年間だったと感じます。

転職へ

キャリア初期の3年間に濃厚な経験をさせていただいたG社でしたが、ついに転職を決意しました。そちらについても詳細に書きたいのですが、また次の記事にしようと思います。

おわり

とっても長い記事でしたが、読んでいただいてありがとうございます！
改めて振り返ってみると記憶が薄れていたり、結構色々やっていたんだと改めて感じたり、思い出に浸りながら記事を書いていました。私は割と泥臭くキャリアを進めている感じがするので参考にはならないかも知れませんが、そんな過程を辿っているやつもいるんだなーぐらいで捉えていただければと思います。

3社目である現職についても転職時の過程を含めて記事にしようと思うので、どうぞお楽しみに！