デスマーチを防ぐスケジューリング : LINE Corporation ディレクターブログ
こんにちは。「livedoor 検索」担当の須田です。 今回はデスマーチを防ぐスケジューリングについて書きます。 以前紹介された、「4つのステップで作る webサイト開発のスケジュール作成」という記事も併せて参考にしてください。 みなさんは周囲で、「このお客様は大事なお客様なので、納期早めでお願いします」または、「大型の案件なので早めに作業してください」という声を聞いたことはありませんか？ 仮に、優先すべき案件だとしても、無理なスケジュールで作業を進行することは好ましくありません。 デスマーチ状態に陥るようなスケジュールを作成してしまった場合、ディレクターとして以下のような原因が考えられます。 1）技術者を魔法使いであるという幻想を持っている。 ※これに関しては、「エンジニアは魔法使いという幻想」という記事にも紹介されています。 2）技術者の作業内容について、「結果」は知っているが、「過程
第1回 ソフトウエア改造力が足りない：変更ミスがトラブルの温床に
ソフトウエアの改造力が足りない――。そのために，システムの変更作業でミスが生じ，次々とトラブルが引き起こされている。 2006年5月9日，シティバンク（エヌ・エイ在日支店）で顧客口座の取引処理にかかわるシステム障害が発生。約6万9800件の取引が二重処理された。原因は，追加したプログラムの不具合。シティバンクは，「障害が発生した原因は、新規プログラム導入に際し、口座取引情報処理において間違ったシステム処理が発生したものです。十分事前テストをいたしましたが実際の運用に際し、結果的に、予想しなかった不具合が発生しました。」と発表した。 2006年6月19日には，プログラム変更のミスによって，労働金庫連合会のシステムにトラブルが発生。総額5億円を超える送金に失敗した。この実例から，なぜ改造が引き金となってトラブルが発生するのかを見よう（図1）。 図1●改造のミスはトラブルに直結する 6月19日の
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
