TOP＞プロジェクト管理＞ 本番開始後のトラブル

だからあなたの会社のシステムは動かない 〜システム発注担当者の悩みを解決します〜 第９回： さあ困った 〜その時発注担当者がするべき事は〜 著者：システムクリエイト  田中 徹   2005/1/21

前のページ  1  2  3

本番開始後のトラブル

トラブルは、設計・開発段階だけではありません。開発終了後にも、様々なトラブルがあります。十分な期間をかけテストを行ったつもりでも、トラブルが出るのがシステムというものです。やはり人間が作るものですからしょうがないと言えることでしょう。もし起きてしまったら…発注担当者として、もうひと頑張りです。    まず、トラブルの内容をできるだけくわしく書き留めてください。どんな処理手順をしたときに起きたのか、その前は何の処理をしていたのか、トラブルは毎回必ず起きるのか、稀に起きるだけなのか、プログラムやOSから何かメッセージは出たか、などに纏め上げます。    トラブルが起きてしまったら、誰の責任なのかを追及することは必要であり、それが開発会社のせいなら修正してもらわなければなりません。しかし、責任追及の前にどう対処し、業務に支障をきたさないかを考える必要があります。代替処理で対応するか、時には手作業で行うときもあるでしょう。そしてSEを呼んで解決にあたります。

トラブル時に開発会社の本性が見える

システムが上手く動かないと業務が滞りますから、発注者側としては一刻も早く改善して欲しいと望むでしょう。一方開発会社は、バグなのか運用ミスによるエラーなのか、またはデータの不備なのかを判断したがります。つまり、自分たちの責任なのかが気になるわけです。    「バグならすぐに対応します。そうでないならご自分達で解決してください」という姿勢の開発会社もあります。これでは発注側としてはたまったものではありません。そういう姿勢の開発会社なら、今後の付き合いを考えたほうがいいでしょう。    それとは別に、開発中にいい信頼関係が築けなかった場合、そういう姿勢を見せることは多く見受けられます。つまり開発会社としても早く引き揚げたい、という意思表示なのでしょう。何が原因でそうなったかが分かれば解決できるかもしれませんが、なるべくならそうならないようにしたいものです。

ドキュメントの重要性

テスト中や運用開始後でも、機能が満たされていない場合に修正が必要なことはいうまでもありませんが、このときにとても重要なことはドキュメントの存在です。プログラム設計書の詳細設計書に至るまで、常に最新の状態で更新されていなければ修正作業は困難になります。何度も述べてきたドキュメントの大切さをここでも実感することでしょう。

まとめ

設計中・開発中・テスト期間・運用開始後と、どんな場面でもバグを始めとするトラブルや、未成熟な機能、イレギュラーケースなどが発生する可能性があります。そのようなときまず第一に考えなければならないことは、その時どう対処するかであり、責任追及はその後になるということです。    早期解決のためには、普段から開発会社といい信頼関係が築けているかどうか、ということになります。

前のページ  1  2  3

著者プロフィール システムクリエイト有限会社  田中 徹 代表取締役。1963年生まれ。MS-DOS時代から、汎用機−PCでのデータ送受信を行ってのチャート（金融業）、表・グラフ描画（財務系）などのシステム開発を行う。 社内人事管理（勤怠・人材活用）、流通業、制御系の分野や集計業務なども手掛ける。ソフトウェアハウスや大手開発会社まで多数の現場で開発を経験し、33歳で独立。現在は各業種・分野でSEとして、またシステムコンサルタントとして活動中

INDEX 第9回：さあ困った 〜その時発注担当者がするべき事は〜   さあ困った 〜突然の仕様変更〜   さあ困った 〜プロジェクトが中止に〜 本番開始後のトラブル

だからあなたの会社のシステムは動かない 〜システム発注担当者の悩みを解決します〜 第1回 システム発注担当者の苦悩 第2回 システム開発の流れ 第3回 開発形態と開発会社の規模による違い 第4回 見積もりについて 第5回 発注側の体制・社内体制を整える 第6回 発注担当者に必要なもの（1）〜業務知識とIT知識、業務フロー〜 第7回 発注担当者に必要なもの（2）〜社内調整、SEとの付き合い方〜 第8回 そもそもSE、プログラマってどんな人？ 第9回 さあ困った 〜その時発注担当者がするべき事は〜 第10回 本番に向けてのテスト 第11回 先達に学ぶ 〜トラブル事例紹介〜 第12回 よりよいシステムにするために