はじめに
目的
昨年度の私の経験を振り返ること。
プロジェクト概要
内容:Webアプリの新規開発(受託）
言語:Java(Spring boot), JavaScript(JQery)
規模:リーダー含め20名ほど
なぜ炎上？
- 設計の工程から遅延していたため
- 遅延により稼働が上がり、退職者が出て人員の入れ替わりが激しかったため
参画当初の状況
自分の役割
テスターとして単体テストのフェーズから参画。
参画したときのプロジェクトの状態
全体的に遅延していて、新規参画者のフォローをする余裕がないような状態。
質問しても忙しそうな雰囲気を出されたり、リモートワークが多くて、インプットに時間がかかるような状態だった。
大変だったこと
いざテストをしてみるとバグだらけで、設計書通りに実装されていなかった。テストができないため、バグの洗い出し、修正から始めた。（Javaは実務経験ゼロで大学の講義で軽く触ったことがある程度、JQeryは全くの未経験だったので、かなりきつかった）
どんな問題があったか？
技術的な問題（プロジェクト全体的に）
- Spring bootの経験者がプロジェクト内に1名しかいなかった
- 設計書通りに実装されておらず、バグが多発。単体テストに着手できるような状況ではなかった
- テスト仕様書の観点が網羅されておらず、テストケースを設計し直す必要があった
マネジメントの問題
- タスク管理がされておらず、スケジュールの意識が薄かった
コミュニケーションの問題
- メンバー間でSlack上で、言い合いなどのいざこざが発生
- 報告が少なく、リーダーが進捗を管理し切れないような状態
どう対応したか
自分がとった行動
- わからないことが発生したとき、15分調べてわからなかったら質問する
- 質問するときは、相手が簡単に回答できるような質問にする（yes or noで答えられる質問にする、不具合が発生したデータなどの環境を共有するなど）
- テスト仕様書を作成する際は、テストする人が何をテストしたいのかが一目でわかるようなケースを作成する
- 進捗を可視化する一覧表の作成（バグ、テストケースの件数のうち、何件対応したか）
うまく行ったこと
- 進捗を可視化する一覧表を作成したこと。マネジメント層が管理しやすいだけでなく、自分自身が今何をしているかや、完了の見積もりが立てやすいなど客観視できるようになった
- メンバーと細かいコミュニケーションをとることで、雑談の中で効率的に進める方法などをインプットできた
結果
担当機能は遅延している状態であったものの、何とか担当機能のテストを終え、案件を終えることができた。
自分の成長
エンジニア1年目ということでわからないことだらけだったが、
とにかくやるしかない状況だったため、
結果たくさんのことを学べた。
- デバッグ方法（Java, JavaScript）
- テストケースの設計
- 進捗を管理できる一覧表のようなものが大事であること
- 設計書の読み方
- テストデータの投入などDBの操作
- 新規参画者のフォロー
etc.
今後に活かすこと
もしまた炎上案件に入ったらどうするか
まず現状の整理から始める。
やることは何があるのかを洗い出して、
何が終わっていて何が終わっていないかを整理する。
その後で、洗い出したタスク完了の見積もりを立てた後でタスクを進める。
質問をする際は、質問したい人が忙しそうな雰囲気を出していても、
何とか対応してもらえる時間を聞いて質問する。
ほとんどの新規参画者は、プロジェクトを加速させるためにアサインされていると思う。
そんな新規参画者が、わからないことを聞かずにいると参画した目的が達成できないことになる。
そのため、質問したい人が忙しそうな雰囲気を出していても何とか対応してもらえる時間を捻出してもらう。
とはいえ、多くの時間を奪ってはいけないので、ある程度調べたり、聞きたいことを整理した上で質問すること。
終わりに
この案件は、長時間の残業が続くなど、本当に厳しい状況だった。
しかし、1年目でこのような経験ができたことは、結果的に良かったと感じている。
「とにかくやるしかない」という環境の中で、テスト設計、新規参画者のフォロー、バグ修正など、多くの業務を短期間で経験することができた。
炎上案件は確かに大変だが、「自分が何のために参画しているのか」「今できることは何か」を意識しながら行動すれば、貴重な学びの場にもなる。
結局のところ、考え方や取り組み方次第で、「ただ辛いだけの記憶」になるか、「今後に活かせる経験」になるかが決まる。
どうせなら、辛かったことも含めて成長につながる経験として捉え、次に活かせる形でプロジェクトを終えたい。