※この記事は、[プログラマは「プログラムの翻訳機」ではない(1)]の続きです。
(1)を読んでいない人は、先にそちらを読んでください。
まず、設計フェーズです。
SEはユーザと打ち合わせを重ね、決定事項を設計書にまとめます。
この時点で仕様を把握しているのはSEだけであり、
プログラマには何の情報も渡されていません。
設計フェーズが終わると、実装フェーズが始まります。
この時点で初めてプログラマに設計書が渡され、
SEとプログラマが仕様の情報を共有することになります。
そして、プログラマは受け取った設計書に沿ってプログラムを作成していきます。
「設計書に沿ってプログラムを作成する」と言っても、
これから自分が作る機能の仕様が分かっていなくては、話になりません。
もちろん、結合テストの話で書いた「仕様の劣化コピー」が発生するため、
プログラマが仕様のすべてを把握することはまず無理でしょう。
しかし、仕様について全く無責任でいいかといえば、そんなことはありません。
今回の冒頭に書いた例で言えば、プログラマは「変だと思った」と言っています。
ならば当然、その時点でSEに仕様確認を行うべきであり、
「設計書どおりに作ればいい」と考えて見逃してしまうのではダメなのです。
もしプログラマが「設計書をプログラムに翻訳するだけ」の存在ならば、
わざわざ高い給料を払って雇う必要はありません。
自動翻訳機でも開発すれば、それで済んでしまう話です。
あえてプログラマを雇うのは、自動翻訳機ではまかなえない部分を補うためであり、
その部分とは人間の頭でしか判断できない「仕様」の部分なのです。
こう書くとSEの責任をプログラマに押し付けているように見えますが、そうではありません。
結合テストでは、プログラマが作成したプログラムを、設計担当者であるSEがテストします。
プログラマがバグを埋め込んでいたとしても、それを見つけ出すのはSEの役割になるのです。
もし結合テストでバグを見逃してしまったら、テストを行ったSEも責任を問われるでしょう。
実装を行ったプログラマだけの責任にはなりません。
ならば当然、プログラマもSEのミスを指摘すべきです。
「設計書はSEの担当範囲だから」と考えるのではなく、
「SEとプログラマの共同作業」と考えて、お互いに協力し合うことが重要でしょう。
プログラマは、「自分が仕様ミスを全て見つけてやる」くらいの心構えで
開発に望んで欲しいものです。
