4年半で約14のプロジェクトやチームを経験したので振り返り

この記事は 株式会社うるる（ULURU） Advent Calendar 2023 の22日目の記事です。

はじめに

初めまして？新卒入社4年目の雑談男です。
普段は雑談をよくしてます。

本記事では入社後様々なプロジェクトやチームを経験してきたので、その簡単な振り返りと学びを残そうと思います。
割と自分語りが多いので、苦手な方は総評だけ読むかブラウザバックをお願いします。

経験してきたこと

一年目

◆やったと

• 旧アプリケーションの運用保守
• データ移行
• スクレイパー開発

◆印象深いこと
入社一年目ですが、データ移行のうち1つフェーズの小チームの旗振りをさせてもらいました。しかし、見積もりに対し内容が濃く大幅にリリース時期が遅れました。また、リリース自体も失敗しました。
育成担当の先輩が切り戻しを引っ張ってやっていくださったので、なんとか大事にならずに済みました。
一年目にして失敗時の適切なリカバリーと速度感の大切さを身をもって学びました。

二年目

◆やったと

• 新アプリケーション開発
• 片方向データ連携システム開発
• 新アプリケーション運用保守
• UI/UX改善
• ログイン前の新アプリケーション開発

◆印象深いこと
ずっとではありますが、ヘルプ要員などプロジェクトやチーム移動が多く一つのことに集中できることがあまりなかったです。しかし、移動が多かったことでキャッチアップスピードが上がり、チームへ参入した際の初速には自信がつきました。

特に意識していることは、参入時に次の様なプロセスで考えを進める様にしています。

プロジェクトの目的→プロジェクトの進捗や現状→プロジェクトの見えている課題→自分の期待されること→プロジェクトを進める上での課題→自分のやるべきことや具体的なタスク

こうすることで、全体を俯瞰しながら自分の動きを効率化できます。

三年目

◆やったと

• 検索制限機能の実装
• 新アプリケーション運用保守
• PHPバージョンアップ
• Vue,Nuxtバージョンアップ

◆印象深いこと
三年目は特筆することはないですが、1,2年目で学んだことを活かしながらどうしたら事業部への影響（利益）を最大化できるかを考えていました。エンジニアとしてのこだわりを残しつつも事業部の利益を考えることの難しさを学びました。

四年目

◆やったと

• SREっぽいこと
• 検索機能のリニューアル
• 現在はまた別のこと

◆印象深いこと
AWSの異常コストを要件から考え一から設計し実装リリースまですることを（周りの力を借りながらも）ほぼ一人でできたことは感慨深かったです。まだまだインフラには弱いですが、キャッチアップスピードや設計、実装、各所との調整など今までの経験が形になったなと思いました。

4年半の総評

つらつらと経験と学びを書きましたが、この4年半で約14のプロジェクトやチームを経験してきた私なりのプロジェクトを進める上での学びを書きます。

フロントとバックエンド間の連携はロスが発生する

多くのプロジェクトではフロントエンドとバックエンドの職能が分かれているのではないでしょうか？
この職能の境での連携にはとんでもないコミュニケーションロスが存在しています。APIの設計内容の連携ミスから始まり、何を実装していて何を実装していないのか、など様々あります。

正直仕方ない部分が多いと思いますが、職能で分けて自分はこの領域だから相手の領域は任せた！ではなく、相手の領域を知り譲歩し合う考えや巻き取りに行く動きができると素敵だなと感じています。

コードの保守性の大切さ

仕事をしていく上でスピードは大切だと思います。しかし、スピードにばかり取りつかれると設計がおかしくなったり、保守性が下がったりとコードの質が落ちます。
コードの質が落ちると、バグを生む確率が上がったり、新機能の実装に時間がかかったり、最悪作り直す羽目になったりします。

この問題はどこでも抱えていて、プロジェクトの期日やQCDSの優先度によると思います。チームによっては基本リファクタは許されないし、綺麗に書いている余裕もないと考えるとこもあると思います。

正直末端の開発メンバーがどうするとかは難しいかもしれませんが、プロジェクトの始動時その分の工数を入れた形でリーダーなどに提案するのが良いと思っています。もし、期日があるのであればリリース後にリファクタをする期間を取る約束をしても良いかもしれないですね。

プロジェクトとして動くのであれば、細かな仕様まで決めておくべき

アジャイルを取り入れている現場は多いと思います。しかし、アジャイルなのにプロジェクトとしてチームが発足し、期日が決まる。この動きをしてしまうと大変なことになります。

アジャイルで開発するのであれば、あーでもないこーでもないと言いながら少しの手戻りが発生するのは致し方ないです。しかし、ウォーターフォール的に期日が決まり、プロジェクトとして動くのであれば、細部まで仕様が決まり、デザインができていないと開発する側としては戸惑いが多く発生します。

もちろん、開発側から仕様の提案等はできると思いますし、どんどん提案すべきです。しかし、その発案/検証/提案/議論の工数は見積もりに含まれていません。

もし、細かいことまで決まっていないが、ウォーターフォール的になるのであれば、上記の様な工数や連携コストなどを上乗せして見積もる必要があると思います。

色々あるけど、チームの雰囲気は大切

ここまで、いろんな課題を出してきましたが意外と乗り切ってこれました。本来であれば、いろんな課題があると思い詰めたりする人が出てきたり、メンバー間でギスギスすることもあると思います。

しかし、それも普段からメンバー同士の関係値を高め結束を強くすることで、円滑なコミュニケーションが可能にな理ます。結果、お互いを助け合い課題解決に前向きになれると思います。
つまり、普段からの雑談は大事です！

長い自分語りと振り返りを読んでくださりありがとうございました。