PG業務でやっておきたいこと

プログラムを理解できるか

PGに関する仕事を始めてある程度経つと、すでにあるシステムの改修や機能追加といった案件にかかわることが多くあると思います。
私の仕事もそういった改修作業が多いです。

そういった作業を行う場合、一番覚えておくべきだと感じた指摘があります。

「自分の担当になったプログラムは、一行一行なんのために存在するものか説明できるようにすること」

似たようなことは入社したばかりの頃に言われたような気がしますが、
当時は「いやできるに決まってるでしょ」と思って真剣にとらえていませんでした。

そして今できているかというと、できない

なぜできていないか

繰り返しますが、私が担当する案件では、すでにあるシステムの改修や機能追加が多く、まっさらな状態で1からシステムを作るということはありません。
そうすると、すでに存在する他の機能を参考にして開発することが多くあります。

参考先からコピペを多用して開発すると、なぜこう組んだのかと聞かれても「他の所でそうしていたので…」という説明しかできません。
コメントがあるからわかるだろうと思っていても、いざ説明しようとするとできないことが多いです。

そうして組んだプログラムをテストするとき、観点抜けや網羅率の悪さでツッコミ入れられて、説明もできずやり直し。しかし理解していないのでどこが抜けてるかわからなくて以下ループ
最悪の場合レビューしてくれてる人が実質テスト設計書を作ったような形になったりします。

設計書の確認と、PGをしっかり解析して理解すること
とても基本的なことですが、できてなくても結構何とかなってしまいます。
そして設計のスキルを期待される年代に入ったあたりで詰みます（まさしく今の私…）。

もしコピペ無双でプログラミングをしている人がいたら、一度自分の関わったプログラムすべての行を説明できるか挑戦してみるといいかもしれません。