俗に言う「SE」はテストコードを書けるようになるべき

work

IT業界(笑)を牽引するSEという職種では、コードを書けることよりも「業務を理解している → 仕様が作れる → 仕様書が書ける」ということが重要らしいです。

じゃあさ、もう一歩進めて「テストコードを書く」ところまでやってしまえばいいじゃないの。クラス・モジュール単位のテストは実装との距離が近いから難しいにしても、WebアプリならSeleniumのテストぐらいは書けるよね？


設計と実装を別々の人間がやるのであれば、その実装の正当性は設計をやった人間が確認しないといけないはず。SEが設計、PGが実装という切り分けをするなら、「SEが書くべきテスト」「PGが書くべきテスト」というのも切り分けて考えるべき。

例えば、SEの下にPGが2人（Aさん、Bさんとする）がついてるチームがあったとする。Aさん、Bさんは自分の担当範囲のコードとテストを書く。SEは全体のテストを書いて、

  • それぞれの挙動が要求通りであること
  • Aさんが作ったものと、Bさんが作ったものの整合性が取れていること

を確認する。

これが自然な形だと思うんだけど、世の中にはテストもPGに丸投げして、最後にブラウザからボチボチ触って「まぁいいんじゃないの」みたいなSEが多いんじゃないかなーというイメージがある。これってSEの怠慢だよね。


いいか悪いかは別にして、業界では「SE > PG」という扱いになってるのなら、SEはPGのコードに対してPG当人以上に責任を持たなければいけないはず。なら、PGの書いたコードが要求に沿っているかを確認するテストコードを書くのはSEとして当然じゃないのか。

受託開発の世界では、設計をn次請けがやって、実装をn+1次請けがやるなんてパターンも多いはず。ここをちゃんと考えてないから起こる「会社間の責任のなすりつけあい」も少なくないんじゃないかと思う。

そもそも「SE > PG」としたいなら、PGが作ったものが正しく動作することを前提にプロジェクトを回そうというのが虫がよすぎる。下の者がミスすることも想定した体制も作れないなんて、リスクヘッジができていないにも程があると思うんだが、どうよ？