失敗談から考えるシステム開発

設計

【エンジニア募集中】フルリモート可◎、売上/従業員数9年連続UP、平均残業8時間、有給取得率90％、年休124日以上 etc.　　詳細はこちらから＞

【失敗談】
プロジェクト全体のスケジュールが厳しく、全員がいろいろなことに手が回らずにいるような現場だったため、設計書にSQLの条件や詳細な処理の内容も記載できない様な状態でした。
そんな中、そのプロジェクトは設計とコーディングを別の人が担当しており、設計が終わった個所からどんどんコーディングを行っていくスケジュールとなっておりました。そのため、設計者も次々設計書を作成していかないといけなかったのですが、設計書が詳細に記載されていないため、コーディングの担当者から頻繁に設計書の内容についての確認があり、設計のスケジュールが更に遅れ、コーディングのスケジュールも厳しいものとなってしまう悪循環の現場がありました。

【教訓】
急がば回れという言葉があるように、スケジュールが厳しくても設計書は誰が見ても作りたいものが分かるように記載したほうが早く終わったかもというお話でした。
結局この後テスト完了までドタバタでしたが何とかプロジェクトは完了することができました。

コーディング・テスト

【失敗談】
区分に値を追加する簡単な修正だったため、影響調査や有識者へのレビュー等を特に何も行わず、修正したソースの個所のみの簡単なテストを行いＯＫとしていました。
しかし、別の担当者の修正内容と合わせて、テスト環境へ修正ソースを反映した所、テスト環境のシステムが正常に動作しなくなったことが判明しました。
原因を確認した所、実は修正したソースの個所以外にも修正だったことが分かり、同時に修正内容をテスト環境に反映した方のテストスケジュールに影響が出てしまうことになりました。

【教訓】
どんなに簡単そうな修正だったとしても、コーティングを行う前に影響個所の調査は必須となります。
自分で行った影響調査に不安があれば有識者へ確認を取るなど不具合を入れ込まないような環境作りが大切となります。
また、コーディングだけでなく、テストケースもレビューをしっかり行いテスト漏れがなるべく発生しないようにしましょう。

【エンジニア募集中】フルリモートも◎(リモート率85.7％)、平均残業8時間、年休124日以上、有給取得率90％ etc.　詳細はこちらから＞