「トラブル」に関する記事とニュース

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

　システムトラブルで記者会見といったニュースが後を絶ちません。昨今、システム停止が経営リスクとなっていますが、どのようなトラブルでも、経営危機を...

2007/10/26

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

　トラブルには必ず「原因」があり、その原因が作りこまれた誤りを「発見」しなければなりません。またおこってしまったトラブルは、適切に「対策」するこ...

2007/10/26

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

　開発、テストがうまく行き、いざ本番！というところで、単純なヒューマンエラーが重大なトラブルを引き起こすことがあります。今回は、これを防ぐにはど...

2007/10/26

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

　トラブルの原因のひとつに「手当て漏れ」があります。人間なので、担当者判断ミスはどうしても起こってしまいますが、そこをテストなどでどう防いでいく...

2007/10/26

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

　システムに修正を加えた時、今まで動いていたところに影響が出ないことを保証するのが、リグレッションテストです。仕様の変更に伴う修正が入った場合も...

2007/10/26

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

　システムの品質を上げるには、テストをしっかり行っておくことが重要ですが、要件定義などに誤りがあれば、決めたとおりに出来ていたとしても誤りの作り...

2007/10/26

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

　ほんの些細なミスが、大きな事故を生むのは、システム開発も同様です。理由にならない言い訳を考える前にルールに従い愚直に実行することが大切です。

2007/10/26

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

　保守作業において、プログラムを新設、修正する場合、その影響度の調査は念入りに行ってもしすぎるということはありません。ツールやドキュメントを駆使...

2007/10/26

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

　分業の進んだシステム開発では、何時までにどこが完成するとか、何時どの部分がテスト出来るようになるかといった、各担当による成果物管理が大変重要に...

2007/10/25

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

　システムは納期との戦いです。急がされることがほとんどではないでしょうか？　しかし、頑張った結果が大失敗では浮かばれません。どのような局面でも、...

2007/10/25

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

　システム開発の様々局面で行われるレビューは、レビューアーの資質がその目的を達成するために大変重要な鍵を握ります。レビューを成功させるためには「...

2007/10/25

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

　万全を尽くしても人智の及ばない出来事は起こりえます。そんなときのために「コンティンジェンシープラン」の準備が必要なのです。

2007/10/25

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

　システム開発担当者は、合理的に、適切に、タイムリーに、上位者に対して、問題の扱いレベルを上げていくこと、すなわちエスカレーションが大切です。

2007/10/25

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

　システム開発に発生しがちな「先送り案件」。しかしその内容が明確に、周知徹底されていないと、トラブルの元となります。

2007/10/25

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

　トラブル発生時など、口頭でやり取りした時も、必ず文書で確認をすることが大事です。ドキュメントを軸に仕事を進めることがトラブル発生防止の鍵といえ...

2007/10/25

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

　よく「いつもと同じ」というニュアンスで要望が出されることがありますが、は「いつも同じ」はいつも同じではありません。なにが「同じ」なのかをはっき...

2007/10/25

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

　システム開発において大切なことは、何を作るかについて開発依頼者と、開発受託者の認識しているものが一致していることです。そのために要件定義書は大...

2007/10/25