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