EnterpriseZine：コーナー：開発担当者必携！トラブル削減のための原則拾七ヶ条

EnterpriseZine：【壱】書いてある要件はやらねばならない。書いてない要件はやってはいけない。

実装したい物は必ず定義。定義されていない物を強制しない。定義されてない物を絶対に作らない。これが大事。

EnterpriseZine：【弐】「〜と同じ」という要件はない。「〜と同じにする」ための要件定義をする。

何が同じなのか、ハッキリさせる。依頼者側は特にこの事を知っておいて欲しいなぁ。

EnterpriseZine：【参】口頭での要件、修正変更のやり取りを行わない。

口頭でのやり取りは不確実な物。不確実な物で大事なやり取りをしない。

EnterpriseZine：【四】積み残し、先送り案件の明確化と周知徹底。

なんとなくやらない、という事がないように。やらないものも、何らかの方法で周りに知らせる。

EnterpriseZine：【伍】エスカレーション･マネジメントを行う。

悪い報告もしっかりとする。
これ、気が重いですよねぇ…。でも、後で手遅れになったときのほうが更に嫌な気分になると思えば、少しは行く気になるかも。

EnterpriseZine：【六】コンティンジェンシープランを作成する。

不慮の事故の事を考えておく。

EnterpriseZine：【七】有識者なきレビューは開かない。

ちゃんと突っ込める人が必要って事かな。

EnterpriseZine：【八】期限が迫っているからといって、テスト、レビューを省略しない。

これはもうタイトルの通りとしか。テストで頑張って解いたのに、些細なミスで大部分が間違いになってしまうような感じ。

EnterpriseZine：【九】開発メンバーの成果は現物で確認する。

それこそ、コードレビューでもしたらいいのではないでしょうかね。

EnterpriseZine：【拾】修正時の影響分析は有識者の経験やツールを駆使して入念に行う。

関数一つ変えただけで、その関数を使っているモジュール全てで問題が起こる事もありえますしね。

EnterpriseZine：【拾壱】JCL修正のみでも、修正規模が小規模でも テスト、レビューを必ず実施する。

手を入れたところには必ずバグが発生する。割と有名な言葉ですね。

EnterpriseZine：【拾弐】必ず原本に戻ってテスト・検証を行う。

システム全体のテストをする。一番最後に書いていますが、仕様を決めた時に一緒に書くのが一番。

EnterpriseZine：【拾参】リグレッションテストは必ず実施する。

修正を行った時、影響範囲内では無いと思っても全体を確認しておくという事かな？

EnterpriseZine：【拾四】プログラムの修正が無い場合でもデータの流れるシステムはテスト・確認を実施する。

修正しなかった場合でも、流れるデータが変わる場合は、実は修正が必要だったという事もあるので、テスト・確認する。

EnterpriseZine：【拾伍】プログラム類の本番移行管理は確実に行う。

モジュールを本番用の環境に移行し忘れたとかそういう事？

EnterpriseZine：【拾六】サービスイン（カットオーバー）時には必ず本番チェックを実施する。

導入したら、実は問題があったという事はたまにありますよね…。環境が変わると、今まで出なかった問題が出る事もあるから、確認が必要という事。

EnterpriseZine：【拾七】それでもおこってしまったらすみやかに報告を。

トラブルがあったら必ず報告。会見で、報告を受けていないと言う発言が出てくる事になる。

一部、自分の知識・経験に照らし合わせ切れなくて、解釈が間違っている所があるかもしれません。やっぱり、大規模システムになると変わってくるなぁ…。