EnterpriseZine：【壱】書いてある要件はやらねばならない。書いてない要件はやってはいけない。
実装したい物は必ず定義。定義されていない物を強制しない。定義されてない物を絶対に作らない。これが大事。
EnterpriseZine：【弐】「〜と同じ」という要件はない。「〜と同じにする」ための要件定義をする。
何が同じなのか、ハッキリさせる。依頼者側は特にこの事を知っておいて欲しいなぁ。
EnterpriseZine：【参】口頭での要件、修正変更のやり取りを行わない。
口頭でのやり取りは不確実な物。不確実な物で大事なやり取りをしない。
EnterpriseZine：【四】積み残し、先送り案件の明確化と周知徹底。
なんとなくやらない、という事がないように。やらないものも、何らかの方法で周りに知らせる。
EnterpriseZine：【伍】エスカレーション･マネジメントを行う。
悪い報告もしっかりとする。
これ、気が重いですよねぇ…。でも、後で手遅れになったときのほうが更に嫌な気分になると思えば、少しは行く気になるかも。
EnterpriseZine：【六】コンティンジェンシープランを作成する。
不慮の事故の事を考えておく。
EnterpriseZine：【七】有識者なきレビューは開かない。
ちゃんと突っ込める人が必要って事かな。
EnterpriseZine：【八】期限が迫っているからといって、テスト、レビューを省略しない。
これはもうタイトルの通りとしか。テストで頑張って解いたのに、些細なミスで大部分が間違いになってしまうような感じ。
EnterpriseZine：【九】開発メンバーの成果は現物で確認する。
それこそ、コードレビューでもしたらいいのではないでしょうかね。
EnterpriseZine：【拾】修正時の影響分析は有識者の経験やツールを駆使して入念に行う。
関数一つ変えただけで、その関数を使っているモジュール全てで問題が起こる事もありえますしね。
EnterpriseZine：【拾壱】JCL修正のみでも、修正規模が小規模でも テスト、レビューを必ず実施する。
手を入れたところには必ずバグが発生する。割と有名な言葉ですね。
EnterpriseZine：【拾弐】必ず原本に戻ってテスト・検証を行う。
システム全体のテストをする。一番最後に書いていますが、仕様を決めた時に一緒に書くのが一番。
EnterpriseZine：【拾参】リグレッションテストは必ず実施する。
修正を行った時、影響範囲内では無いと思っても全体を確認しておくという事かな？
EnterpriseZine：【拾四】プログラムの修正が無い場合でもデータの流れるシステムはテスト・確認を実施する。
修正しなかった場合でも、流れるデータが変わる場合は、実は修正が必要だったという事もあるので、テスト・確認する。
EnterpriseZine：【拾伍】プログラム類の本番移行管理は確実に行う。
モジュールを本番用の環境に移行し忘れたとかそういう事？
EnterpriseZine：【拾六】サービスイン（カットオーバー）時には必ず本番チェックを実施する。
導入したら、実は問題があったという事はたまにありますよね…。環境が変わると、今まで出なかった問題が出る事もあるから、確認が必要という事。
EnterpriseZine：【拾七】それでもおこってしまったらすみやかに報告を。
トラブルがあったら必ず報告。会見で、報告を受けていないと言う発言が出てくる事になる。
一部、自分の知識・経験に照らし合わせ切れなくて、解釈が間違っている所があるかもしれません。やっぱり、大規模システムになると変わってくるなぁ…。
