プログラム製造を始める前にきめておくべきこと。

品質の高い成果物をあげようと思うと、いろいろなことを策定しておかないといけない。

PM・PL経験、もしくは作業リーダーをされたひとは経験があるのではないだろうか？
作業工程の規則が曖昧なために案件が破滅へとむかっていく様子を。

規則というものは作業要員にとっては堅苦しいことこの上ないが、規則をつくっておかないと、テストフェーズが始まると大変なことになる。
最悪、テストフェーズをむかえられないケースありうるだろう。

個人的な経験と統計で恐縮なのだが、最低限、策定しておかなければならないこと、

とくに、絶対やっておかなければならないのは、
モジュール単位でのテスト方法だ。

これがあやふやな案件は大概、障害の嵐が発生し、納品後も障害の嵐がやむことはない。
顧客の信頼は失墜し、取引停止になる場合もある。

案外、軽視されがちなのだが、このモジュール単位でのテスト方法は必ず策定しておかなければならない。
とくにPG経験のない、業務SE等からPM・PLになったアナタ、、、肝に銘じておいてください。

で、具体的な話になりますが、

事前効果として、
モジュール単位でのテストというのは、まず物理設計のモジュール分割、タスク割り当て、IO定義がキッチリしていないとできない。
つまり、モジュール単位でのテスト方法を明確にしておくと、レビュー段階で発覚するため、設計者がずさんなモジュール分割、タスク割り当て、IO定義ができなくなる。

設計者が未熟な場合、どのようなテストが行われるかを考えながら設計を行えるため、比較的作業を進め易い。

そして、実際に製造を始める前にテスト用のフレームワークを構築するべきである。

本番環境のミラーを開発用に作成して、
それをプログラムテスト用に利用して開発していく現場をみうけられるが、
これは、はっきりいって最悪。

理由としては、ひとつの処理の確認のが異様に時間がかかるために作業者のテストファーストという意識が薄くなり、細かい粒度のプログラムテストが行われなくなる。

で、一番痛いのが、トラブルがおきたときや、納品後にモジュールを担当した作業者がすでにいなかった場合（これは作業者を外注の人間を使うことがほとんどなのでよくある）、ほかの人間が大まかな動作確認をするときに、多大なオーバーヘッドが生まれてしまい非常にコストがかかってしまう。

フレームワークを作成しておけば上記のことはほとんど退避できる。
なぜなら、条件ごとに設定しているボタンを押すなりすれば
テスト結果がかえってくるのだから、確認するほうもラクチンである。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

実際に、トラブル案件をひきおこしたPM・PLは上記のことをしていない。

で、救援にまわった人間もモジュールの独立性がないため全体を把握する必要があるため、救援活動も困難を極めるということが常だ（しょっちゅう経験アリ）。

あとで地獄をみないためにもモジュール単位のテスト方法の定義、モジュール単位のテスト環境の構築はきっちりやりたいものである。