SEとPG
私のチームではSEとPGは以下の役割を担っています。
PGは別会社に委託することが多く、委託するには我々が顧客と合意した内容をもれなく伝える必要があります。しかし、外部設計書に全てをもれなく記述するのは困難なのが実情です。
そのため委託先からできあがってくるプログラムは、多くの場合求めている仕様と異なっています。
そこで我々は委託先のプログラムを受け取った後に「受入検証」というフェーズを設け、SEとPGとで不具合票等のやりとりを何度もおこない、求める仕様に近づけています。
この「受入検証」は以下の2つの問題を抱えています。
- 時間がかかる
- プログラムが修正修正の繰り返しで汚くなる
この問題を解決するにはどうすればよいでしょうか？
問題の原因は前述のようにSEからPGへの仕様伝達がうまくいっていないことにあります。
では仕様伝達をうまくおこなうためにはどうすればよいでしょうか？
外部設計書をこれまで以上にもっともっと時間をかけて詳細に記述すればよいでしょうか？
いや、それでは開発期間がいたずらに延びてしまいます。短納期が要求される現在のシステム開発に、開発期間を延ばすような方法は認められません。
すこし考え方を変えてみましょう。
SEからPGへ、仕様を伝達しなければよいのではないでしょうか？
つまり、SEがPGを、あるいはPGがSEの役割を兼ねればよいのではないでしょうか。
具体的には「SEがプログラミングをおこなう」、「PGが外部設計をおこなう」のです。
こうなってくるとSEとPGを分けることにあまり意味はなくなってきます。
あえて分けるとすれば、提案、要件定義あたりのコンサルをおこなう役割と、外部設計以降を担当する役割くらいで分かれるのではないでしょうか。
外部設計以降は各担当が一気に設計をおこない、一気にそのまま製造してしまう。
このメリットは先ほどの受入検証の2つの問題を解決するだけではありません。
設計者が製造者を兼ねるということは、設計段階でサンプルプログラムを作成することが可能になります。
設計段階で顧客にサンプルプログラムを提示できれば、設計の質もかなりあがることが期待できます。
「百聞は一見にしかず」です。
デメリットとしては人件費の安いPGという職種がなくなり、人件費があがることが予想されます。
しかしそれが本来の姿ではないでしょうか。
プログラミングは単純作業ではないのです。
