著者情報
-
独立行政法人 情報処理推進機構 ソフトウェア・エンジニアリング・センター（SEC） リサーチフェロー。
1975年東京海上火災保険に入社。以来30年間、損害保険、生命保険、確定拠出年金といった業務システムの開発に携わった他、東京海上日動システムズ取締役品質管理部長として、トラブル削減や、開発品質管理の向上を実現。2005年から株式会社アイネス。経済産業省・プロセス改善研究部会主査、同・開発プロセス共有化部会副主査。東京海上日動システムズ技術顧問。情報処理学会ＩＳ研究会委員。JUAS主席研究員。JISA要求工学調査委員会委員。
著書：SEC BOOKS「経営者が参画する要求品質の確保―超上流から攻めるIT化の勘どころ」（オーム社・共著）、「実務で役立つプロジェクトレビュー」（翔泳社）
※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
執筆記事
-
2007/10/26【拾七】それでもおこってしまったらすみやかに報告を。
システムトラブルで記者会見といったニュースが後を絶ちません。昨今、システム停止が経営リスクとなっていますが、どのようなトラブルでも、経営危機を引きおこす可能性を持っているのです。トラブルがおこったときの心構えについて考えます。
-
2007/10/26【拾六】サービスイン（カットオーバー）時には必ず本番チェックを実施する。
トラブルには必ず「原因」があり、その原因が作りこまれた誤りを「発見」しなければなりません。またおこってしまったトラブルは、適切に「対策」することが求められます。
-
2007/10/26【拾伍】プログラム類の本番移行管理は確実に行う。
開発、テストがうまく行き、いざ本番！というところで、単純なヒューマンエラーが重大なトラブルを引き起こすことがあります。今回は、これを防ぐにはどうしたらいいかについてお話します。
-
2007/10/26【拾四】プログラムの修正が無い場合でもデータの流れるシステムはテスト・確認を実施する。
トラブルの原因のひとつに「手当て漏れ」があります。人間なので、担当者判断ミスはどうしても起こってしまいますが、そこをテストなどでどう防いでいくことが可能かをお話します。
-
2007/10/26【拾参】リグレッションテストは必ず実施する。
システムに修正を加えた時、今まで動いていたところに影響が出ないことを保証するのが、リグレッションテストです。仕様の変更に伴う修正が入った場合も、システム全体への影響を慎重に考える必要があります。
-
-
2007/10/26【拾壱】JCL修正のみでも、修正規模が小規模でもテスト、レビューを必ず実施する。
ほんの些細なミスが、大きな事故を生むのは、システム開発も同様です。理由にならない言い訳を考える前にルールに従い愚直に実行することが大切です。
