参画初日の朝、僕はパソコンを開いた瞬間にリポジトリをクローンしてソースコードを読み始めました。恥ずかしながら、それが最初の間違いでした。
そのプロジェクトはJavaで書かれた某業務システムで、もともとのチームが納期を2ヶ月押している状態でした。「補強として入ってほしい」と言われた入社2年目の僕には、とにかく早く役に立たなきゃというプレッシャーがあって。だからすぐコードを理解しようとしたんですよね。
でも2日後に、プロジェクトに慣れた先輩から一言もらいました。「コードより先に人を知らないと、あのプロジェクトはしんどいよ」と。
初日にやるべきだったこと
今思えば、最初の2日間は「関係者のヒアリング」に全力を注ぐべきでした。炎上プロジェクトには、必ずと言っていいほど「誰も言語化できていない問題」があります。
最初に全然分からなくて、先輩に教えてもらいながら整理したリストがこれです。
# 途中参画時の確認リスト
## ステークホルダー把握
- 誰が最終意思決定者か
- 誰が今一番困っているか
- インフォーマルなキーパーソン（必ずいる）
## 課題の棚卸し
- 遅延の根本原因は技術か？プロセスか？人間関係か？
- タスクの依存関係でボトルネックになっている箇所はどこか
- 「言えていない問題」を引き出す（仕様未確定・スコープの認識ずれ等）このリストをもとにヒアリングして回ると、3日目に重要なことが判明しました。スケジュール遅延の主な原因は技術的な難しさではなく、仕様が未確定のまま実装を進めていたことでした。コードを読み続けていたら、おそらく1週間経っても気づかなかったと思います。
ドキュメントがない中でシステム全体像を把握する
「設計書はどこですか？」と聞いたら「古くて当てにならないです」と返ってきたときの絶望感は今でも覚えています。そこで教わった方法が「動いているものを逆引きする」アプローチです。
まず画面を操作しながら、実際に動くJavaクラスをデバッガで追っていきます。
// Controller を起点に、Service → Repository の流れを手書きメモしながら追う例
@RestController
@RequestMapping("/orders")
public class OrderController {
private final OrderService orderService;
@PostMapping
public ResponseEntity<OrderResponse> create(@RequestBody OrderRequest request) {
// ここから OrderService#create を辿る
return ResponseEntity.ok(orderService.create(request));
}
}このように画面起点でクラスを追いながら、紙にざっくりした関連図を書いていくと、2〜3日でシステム全体の輪郭が見えてきます。ドキュメントより実コードのほうが正確なので、逆引きのほうが早いケースが多かったです。
ただ、追っていく中でわかったことがあります。コアのServiceクラスが1000行を超えていて、あらゆる処理が詰め込まれていました。これが技術的負債の入口でした。
チームの信頼を積み上げた方法
コードを把握しながら、少しずつチームに貢献することが大事だと学びました。大きな改善よりも、小さくても確実に役立つことを繰り返すほうが信頼を積みやすいんですよね。
最初にやったのは、ログ出力の改善でした。バグ調査のたびに「ログが出ていないから追えない」という会話が繰り返されていたので、例外を握りつぶしている箇所を直しました。
// 改善前: 例外をswallowしていた（このパターンがコード全体に点在していた）
try {
processOrder(request);
} catch (Exception e) {
// 何もしていない
}
// 改善後: ログを出力してから再スロー
// ※ 本来は例外の種類ごとにハンドリングを分けるべきで、改善の余地はまだある
try {
processOrder(request);
} catch (Exception e) {
log.error("注文処理でエラーが発生しました: orderId={}", request.getOrderId(), e);
throw e;
}ロジック的にはほぼ何も変えていません。でも、この修正以降「バグが出たらログ見ればわかる」という空気がチームに生まれて、調査時間が体感で半分以下になりました。
「あの人が来てから少し調査しやすくなった」という小さな評価が積み重なると、その後に「この設計を変えたい」という提案を出したときの通りやすさが全然違います。
技術的負債の整理と段階的な改善計画
2週間の終わりに、先輩と一緒に技術的負債の棚卸しをしました。全部リストアップして、「緊急度×影響度」のマトリクスで仕分けていく作業です。全部直そうとすると今のスケジュールがさらに伸びる。でも何もしないと毎日の開発が鈍化し続ける。どこから手をつけるかを決める作業が、実はいちばん重要でした。
優先度の高い順に直すものを決めて、それ以外は「次フェーズで対応」と明示的に先送りする。この「意図的に先送りする」という判断が、当時の僕には難しかったんですよね。全部直さないと気持ち悪くて。でも、先送りする判断を記録しておくことで、後から「なぜここを直さなかったか」が説明できるようになります。
振り返って
今後は、どのプロジェクトに途中参画するときも、最初の2日はヒアリングに使うことにしています。コードより先に人とプロセスを知る。それが遠回りに見えて、実は一番早いということをこの2週間で学びました。
「炎上プロジェクトの途中参画」は正直きつい経験でしたが、通常の案件では学べないことをまとめて体験できた2週間でもありました。もっとうまいやり方を知っている方がいたら、ぜひ教えてください。