「引き継ぎ資料の内容が不足していた」
「リリース手順書が整備されていない」
「仕様が誰にもわからない」
エンジニアなら一度は耳にしたことがあるかもしれない、あるいは直面したことがあるかもしれない、そんな開発現場のリアル。私が担当することになったプロダクトは、まさにその渦中にありました。法改正対応や溜まったタスクが押し寄せる中、開発体制は限界を迎えていました。
しかし、私はそこで一歩前に出ることを選びました。
結果として、その行動は社内で 「敢闘賞」 という形で評価され、チームは劇的な改善を遂げることができました。なぜ、火中の栗を拾うような真似ができたのか。それは、カオスな現場を整理していくプロセスこそがエンジニアとしての最大の成長機会であり、何よりそのプロダクトへの 「恩返し」 になると信じていたからです。
この記事では、ドキュメントすらない状態からどのように開発体制を立て直し、チームを安定稼働まで導いたのか。その記録を振り返ります。
1. 誰も触れない「ブラックボックス」からのスタート
当時、チームは非常に苦しい状況にありました。
前任者からの引き継ぎが十分に行われておらず、仕様書やドキュメント類は散逸。特に致命的だったのは、「リリース手順書」すら他が見てわかる状態で整備されていなかったことです。
もちろん、最初から現場が崩壊していたわけではありません。
度重なる法改正への追従、急な人の入れ替わり、そしてスケジュールのひっ迫……。そうした複数の要因が不運にも重なり、結果として手が回らない「カオス」な状態が出来上がってしまっていたのです。
しかし、目の前には待ったなしのタスクが山積していました。
法改正への対応、溜まりに溜まった機能開発……。
仕様もわからない、リリースも怖い、しかし納期は迫る。まさに「開発体制の立て直し」と「大量の機能開発」を同時に求められる、最もハードな局面でした。
2. まずは「守り」を固める：当たり前を取り戻す戦い
この状況で私が最初に着手したのは、コードを書くことではなく 「足場を固めること」 でした。
安全地帯を作る：リリース手順書の整備
まず最優先で行ったのが、リリース手順書の整備です。
過去にリリース作業で時間がかかり、トラブルの原因になっていたことを聞いていたため、まずは「安全かつ確実に本番環境へ反映できる状態」を作らない限り、どんなに良いコードを書いても意味がないと判断しました。
これにより、デプロイ時の心理的・技術的なハードルを下げ、開発サイクルの安定化を図りました。
開発フローの正常化
次に着手したのが、開発プロセスの整備です。それまでは口頭ベースや曖昧な仕様で進むこともありましたが、前プロダクトでの経験を活かし、上長やチームメンバーと連携して以下のフローを徹底しました。
- まずはIssueを作成する
- 実装前に要件を完全に固める
- QAチームと連携して仕様を確認する
非常に基本的なことですが、これを徹底したことで「手戻り」が激減しました。QAチームとも連携が取りやすくなり、チーム全体のリズムが整い始めました。
まとめ
・リリース手順は担当開発者以外が見てもわかるようにしよう！
・基本的な事でも徹底して対応をしよう！それがチーム間の連携を強くする！
3. 役割を超える：CS対応と改善
守りの体制が整ってきた段階で、私はギアを上げました。「与えられた開発タスクをこなす」だけでなく、「チームとプロダクトのために必要なことは全部やる」 というスタンスへの切り替えです。
誰よりも数をこなす
「対応依頼表」にあるタスク、特に不具合対応の開発・原因調査など、誰よりも多くのチケットを消化しました。リソース不足の現場では、圧倒的な行動量こそが最大の信頼構築になると考えたからです。
CS対応への積極介入
開発者としての枠を超え、CS（カスタマーサクセス）からの問い合わせ対応にも深く踏み込みました。「顧客の困りごとをすぐに解決したい」「CSメンバーの負担を減らしたい」という思いがありましたが、結果として、問い合わせ内容を深掘りすることでシステムに潜むバグや改善点を発見することに繋がりました。
根本原因の特定
CS対応や日々の調査の中で、環境固有の潜在的な不具合を発見することができました。これらは、単にタスクを消化しているだけでは見つけられなかったものです。
泥臭い調査や改善提案を繰り返し、Issue化して潰していく。周囲から「伝説に残る改善施策」と評価いただいたのは、こうした地道な活動の積み重ねでした。
まとめ
・積極的な行動が結果として大きな改善に繋げる事が出来た！
・地道な活動の積み重ねで大きな評価を頂いた！
4. なぜそこまでやったのか：「恩返し」と成長
今回、「自らの役割を超えて主体的に行動する」「最も大変な時に手を挙げた」という点を評価いただき、敢闘賞を受賞することができました。
正直なところ、ただ「がむしゃら」でした。しかし、その根底には二つの明確な動機がありました。
一つは、「困難こそが成長の糧になる」 という確信です。
整った環境でコードを書くだけでは得られない、カオスからの脱却プロセスそのものが、エンジニアとしての地力を大きく引き上げてくれました。
そしてもう一つは、「恩返し」 です。
担当したプロダクトは、私にとって大事な人が作り上げたものでした。「このプロダクトをもっと良くしたい」「守りたい」という個人的な愛着とリスペクトがあったからこそ、苦しい局面でも折れずに、改善を楽しみながら進めることができたのだと思います。
カオスな現場は、見方を変えれば「改善の余地しかない」宝の山です。
これからも、役割という枠にとらわれず、プロダクトとユーザーのために必要なことに全力で向き合っていきたいと思います。
5.補足と感想
この記事はAIと対話しながら作成しました（少し文章がドラマチックすぎる気もしますが……笑）。
この対応を行っていた当時は、本当にがむしゃらに作業をしていたこともあり、自分がやったことを全く整理できていませんでした。今回、AIと会話をしながら記事に落とし込む過程で、当時の行動や思考を振り返ることができ、とても良い機会になりました。
自分自身、このプロダクトに配属される前までは、そこまで積極的に行動できていたとは言えません。「この件をきっかけに自分が変われるかもしれない」と期待して異動したのかもな……と、今振り返ると思います。
まだまだ、やれること・やるべきことは沢山あります！
今後も自分を奮い立たせて、プロダクトの改善に取り組んでいきたいと思います！