大型案件で学んだ現場のリアル|手戻り・認識ズレから得た3つの教訓
CONTENTS
システム開発の現場では、設計書やスケジュールだけでは見えない「リアル」があります。実際に手を動かしてみて初めて分かる難しさや、進める中で生まれる認識のズレ、そして一人では越えられない壁。今回は、基本設計から結合テストまで担当した大型案件での苦戦と、そこから得た学びをお話しします。
一見すると「やれるはず」だった案件
今回担当したのは約4人月規模、2か月で回収する案件でした。期間だけ見れば長くはありませんが、中身は想像以上に密度の高いものでした。
機能は一つですが、関連モジュールは3種類に分かれ、影響範囲も広く、しかも自分にとって初めて触る領域でした。要件定義を受けた段階では進められそうに感じていたものの、全体像の把握には時間がかかりました。
どこを直すとどこに影響が出るのか。どのモジュールが主でどこが従なのか。表面的には見えていても、内部のつながりまではすぐに理解できませんでした。この見立ての甘さが、後々の進行に影響していきました。
進めるほど増えていった手戻り

基本設計から詳細設計、製造へと進む中で、少しずつ違和感が出始めました。「このロジックでは想定どおりに動かないかもしれない」「このケースが抜けている」など、小さな違和感が単体テストで次々と表面化していきました。
設計上は成立しているように見えても、実際に動かすと成り立たない。そのたびに修正し、また進めては戻るという状況が続きました。今回の案件では、手戻りが局所で収まらず、影響範囲の見直しにまで広がるケースが多く、想定以上に工数がかかりました。
また、一つの修正が別の不具合を引き起こすなど、変更の連鎖が発生する場面もありました。影響範囲の見立てが不十分な状態で進めることのリスクを、身をもって実感することになりました。
そして痛感したのが、「分かったつもり」で進める危うさです。判断を誤ると、その影響は後から大きく返ってきます。
内結試験で起きた認識ズレ
内結試験では、「この値は本来どうあるべきか」という論点が発生しました。実装としては成立していても、要件の意図として正しいのかが曖昧だったのです。
本来は認識をそろえるべきでしたが、時間の制約もあり、自分なりに方針を決めて進めました。確認連絡も入れていましたが返答が得られず、認識を完全に合わせきれないまま開発を完了させることになりました。
結果として後から認識差異が発覚し、対応のやり直しが必要になりました。作り終えた後に修正が入るのは負荷の大きい経験でした。この出来事から、曖昧なまま進めたものは必ずどこかで止まると実感しました。
周囲の力で前に進めた
今回の案件は、自分一人の力では乗り越えられませんでした。影響範囲の見方や設計の壁打ち、レビューなど、さまざまな場面で周囲の力に助けられました。
開発では「自分で解けること」が重視されがちですが、大型案件ではそれだけでは不十分です。むしろ、周囲の知見を適切に借りながら進めること自体が重要なスキルだと感じました。
特に、有識者の力は早い段階で借りるべきだと感じました。違和感を共有していれば、手戻りを小さく抑えられた場面も多かったはずです。
今回の案件で学んだこと
今回の経験で得た学びは3つあります。
1つ目は、早めに共有すること。相談が遅れるほど、後の手戻りは大きくなります。
2つ目は、影響範囲は一人で抱えないこと。特に初見の領域では、レビュー前提で進める必要があります。
3つ目は、納品視点を持つこと。遅延理由やリスクを説明できる状態で進めることが重要です。
「頼ること」は技術の一つ
振り返ると反省点も多い案件でしたが、大型案件の難しさと自分の課題を明確にできた点は大きな収穫でした。
そして何より、「頼ること」は弱さではなく技術だと学びました。一人で抱え込まず、早めに共有し、チームで進める。それができて初めて、大きな案件に向き合えるのだと思います。
現場のリアルは決してきれいではありません。それでも周囲の力を借りながら前に進んでいく。その積み重ねが、次につながる経験になると感じています。
現場のリアルを知った今こそ、次の一歩を

開発の現場では、知識だけでなく、考え方や進め方も問われます。 だからこそ、早い段階で学び、試し、壁にぶつかりながら積み上げていくことが大切です。
「もっと実践的に学びたい」「未経験からでもエンジニアを目指したい」と感じた方は、 ZeroCode PLUS に挑戦してみてもいいかもしれません。
学び始めるハードルを下げながら、エンジニアとしての土台づくりを進められるサービスです。 記事を読んで終わりではなく、ここから実際に動き出したい方におすすめです。