Photoruction工事中!

Photoructionの開発ブログです!

職業エンジニアとしての初プロジェクトを振り返ってみた(前編)

こんにちは!株式会社フォトラクションでWebエンジニアをしている田中喜規です。 この記事は、Photoruction Advent Calendar 2021の3日目の記事になります!

今年2月に異業種から転職して、職業エンジニアとしてフォトラクションに入社。

その初プロジェクトで、プロジェクトが大幅に遅れるという、大失態がありました。

その時の経験を糧にすべく、本記事を執筆しようと考えました。。!

 

本記事を書くに至った経緯


  • 職業エンジニアとして、初プロジェクトでの反省を残したかった
  • 失敗談ってみんな興味あるんじゃなかろうか?

     

目次

 

前提①:PJ内容


💡 Photoruction内のプロジェクト検索機能の改修

 

前提②:メンバー状況


チームメンバーは以下の6名の体制で進めました。

  • PM(神澤さん。明日の後編記事を執筆してくださいました)
  • Webエンジニア(田中):
    • 2021年2月から異業種からエンジニア転職
    • 職業エンジニアとしてチーム開発を進めるのは初
    • Web側の実装をフロントエンド、サーバーサイド両方担当
  • iOSエンジニア
  • Androidエンジニア
  • UIデザイナー
  • QAエンジニア

チーム開発の難しさ


前述の通り、職業エンジニアとして、初めてのプロジェクトに参画したので、難しさを感じる場面が多々ありました。というか、初めてのこと尽くしで大変でした笑

 

大変さを感じた場面


  • Mobile APIを作らないといけない

    • これまで、個人での開発(職業エンジニアになる前)では、外部APIを利用することはあったが、実際に作る側になると、作るって何?状態からスタートした
    • ロジック部分に関しては、APIの問題なので、バグチケットでMobile側の問題と起票されていても、Mobile APIの修正になることが多い
    • 責任範囲が広くなったのと、重くなるのだと実感
  • 工数見積もり

    • これはチームでのPJの進め方とは直接関係はないが、上記のMobileAPIの作成を先に行わないといけないこともあり、よりシビアに
  • WebとMobile端末間での仕様差の確認

    • 仕様を統一しないといけない部分と、Web Mobile間で差異が出る部分の認識のズレが出ることが多々あった
    • これにより、作業の出戻りが発生することがしばしば
  • WebとMobile間での進捗の足並み確認

    • リリース日は決まっているので、リリースができるかどうかを、PMだけでなく、エンジニア間でも確認することが重要だと感じました
    • 本PJだと、エンジニアの調整役を私が担っていたこともあり、その役割がほとんど果たせなかった

       

PJを進める中で起こったこと


内訳は大きく分けると、以下2つの期間がありました

  • リリース予定日まで
  • リリース予定日以降

     

リリース予定日までの話


  • Webは詳細設計段階で、遅れ気味で実装に入る
    • 工数見積もりでは、間に合うスケジュール感
  • ユニットテストができていなかった(Web)
    • 実装自体が遅れていた
    • それに伴い、ユニットテストが不十分なまま、スモークテストを迎える
  • リリース予定日でリリースするとmtgでは擦り合っていた
    • リリースサイクルに乗っていて、マージも済んでいた状況
  • リリースの延期判断がリリース日の直前となった(←問題)
    • リリース直前でのテストで大量の不具合が出た
    • テストに入る直前での仕様変更があった
  • デグレが発生し、リリース日が1日延期した上に、本PJはリリースできなかった
  • Web、Mobileエンジニアそれぞれに仕様の認識のズレがあった

     

リリース予定日以降からの話


  • Webは1ヶ月遅れでリリース

  • Mobileは3ヶ月遅れでリリース

  • リリース前のタイミングでの改修確認

    • そこで改修の確認ができないと、リリース延期の判断になった(そりゃそう)
  • Mobileのバグチケットが、結果Web由来(Mobile API)となり、チケットが増えた

    • Mobile側のテストが遅れており(webと同時期出なかった)、Web側の残チケットが0になっても後から、チケットが追加されていたような状況
    • また、改修戻しが多かった
  • お見合いのチケットが発生した(Web対応かMobile側での対応か)

  • Web側の改修内容がマージされていたが、Mobile側の実装が遅れていたため、再度Mobileのリリースを延期することとなり、Web側でリバート作業が発生した

  • 最後の方は、他PJがスタートして、同時並行で進めなければ、ならず、スピードが鈍化

     

結果、どうなったのか?


💡 結論:3ヶ月リリースが遅れた

 

PJが遅れると次のPJにも影響するので、大迷惑をかけてしまいました。

ここまで遅れたのは、私個人の問題だけでもないとは思うのですが、

仕事を行う上での意識次第では、少しはリリースを早められたのではないかと思っています。

また、結果として、周りの方に迷惑をかけたのも良くなかったと思います。

直前になって、駆け込み寺の如く、先輩エンジニアの方に見てもらったり、QAやテスターさんに何度もテストしてもらったりと、大変お世話になりました。

事前にアラートをあげたり、その回数や頻度を減らしていけるよう、心がける必要があると思いました。

 

反省を糧にしよう


経験・スキル不足

  • 設計や仕様理解、実装のスピード感が遅い
  • 自分のタスクで手一杯で周りを見る余裕がなかった
  • PJの進め方やMobile側との開発の進め方が分かっていなかった

→事実ではあるが、本記事ではフォーカスを当てない

 

マインドセット不足(意識次第で改善ができること)

  • 良くも悪くも、自分でやり切る意識が高すぎたと思う
    • エンジニアとして独力で問題解決ができるようになる意識は大切
    • お客様は勿論、社内のメンバーに迷惑をかけてしまった
    • 月並みだが、聞いて即解決出来るのであれば、その方が良い
  • アラートを早めに上げる意識
    • リリース直前での延期はエンジニア側がアラートを上げれば、回避できたはず
    • 頑張ればできます!的な考えは結果迷惑になるので良くない
  • 見積もり3倍の意識くらいは必要
    • 見積もりが甘いので、自分ができると思う3倍を見積もる
  • コミュニケーションは必要十分満たさなかった
    • 密に取りすぎず、必要なだけの情報量を発信することを日々心がける必要がある
    • 周りのメンバーがスムーズに動けるよう、前もって情報共有する必要がある

       

明日は、PMとしての反省!


以上、紆余曲折ありましたが、この経験を次に活かせるかが重要だと思います。

半年後、一年後に、笑い話にできるよう励みます!

明日は、本件を担当したPMの神澤さんが、本PJの振り返りをします。

気になる方は、次回も読んでいただけると嬉しいです!

 

 

株式会社フォトラクションでは一緒に働く仲間を募集しています