先月、東証のシステムがダウンし、終日ストップし多大な影響がでました。株取引、銀行などの金融機関のシステムがトラブルを起こすとその影響は甚大となることは過去の事例が示していますが、最初の大規模トラブルは2002年のみずほ銀行のシステムでした。
第一勧業銀行、富士銀行、日本興業銀行の3行が合併し、みずほ銀行とみずほコーポレート銀行(旧)が発足した2002年4月1日。みずほ銀行の勘定系システムはその初日から①ATMが使えない、②口座振替の遅れが250万件も発生、③遅れるだけでなく二重引き落としが3万件も発生するなど、複雑な機能ではなく基本的な機能が使えないという事態になりました。しかし、こんなことが本番初日に分かるとは!関係者は・・・まさかトカゲの尻尾切り?

この事件をきっかけに、東洋経済がコンピュータシステムダウンの恐怖という特集号に寄稿する機会があり、経験から言える、システムの企画、設計、開発、運用、体制、組織に関して8つのチェックポイントを紹介しました。

加筆訂正(rewrite)して、2つずつ、4回に分けて紹介します。今日は最終回です。時代の変化を受けない普遍的なことを書いていますが、この寄稿は2002年当時の状況を踏まえていることを頭に入れてご覧ください。

 

ポイント7:実行可能なスケジュールか

①クリティカルな部分は明らかになっているか

②無理と思っている関係者はいないか

③進捗管理の方法は確立しているか

簡単に言えば、プロジェクト推進に必要な体制、要員、技術、経験、システム構築の難易度を考慮した実行可能なスケジュールになっているかということです。国力が違う米国に大和魂で無謀な戦いを挑み、敗れるべくして負けた太平洋戦争同様、実態を踏まえない勇ましい精神論や、実態を知らない(知ろうとしない)幹部の意向で無理なスケジュールを作らざるを得ない場合が少なからずあります。予算の年度内消化が前提の自治体ではあり得ることです。一方、質的量的に未経験な場合には、危険なのかぎりぎりセーフなのか、余裕があるのか見極めが難しいことも確かです。様々なことを勘案し、できる限り問題が起きないようにしたスケジュールで臨むものの、大なり小なり問題が発生するのは経験するところです。そこで考慮すべきは、問題発生時にその軽重に応じて影響を最小限に留め、可能な限りスケジュールに沿うような具体策を立てられるメンバがいるか否かがポイントになります。烏合の衆が何人いても役に立ちません。そうなるためには、最初の部分、すなわち問題発生の事実をありのままに報告できる雰囲気が醸成されていることが重要です。問題発生時にはことの軽重が分からないことがあるからです。まずは、第一報!次に、報告された内容の軽重(影響の大きさ、リカバリに必要な手間etc)を的確に評価・判断し、適切な処置を行える体制、メンバのプロジェクトになっているか否かです。もちろん、事の重大性を判断し、優先順位を踏まえた適切な采配をふるえるリーダがいるかいないかは重要です。最大限努力しても後れを回復できない場合には、見栄を張らずにスケジュールの延期を決断する勇気が必要になります。一方、遅れを挽回するために増員を行うと逆効果になることも考慮しなければなりません。質を考えずに増員することにより、バグの作り込みを経験しているSEは多いと思います。

ポイント8:ソフトウェアの品質

①ソフトウェアにも品質があることを理解しているか

②ソフトウェアにバグ(不具合)はつきものと諦めていないか

③品質はスケジュールと密接に関係していることを理解しているか

ソフトウェア(アプリケーション)の中には、複雑な使い方ではないのに、容易に発見されるバグ(不具合)があったり、出荷してから顧客に実際に使ってもらってバグを見つけるという感のある姿勢を持っているソフトウェア会社が少なからずあります。一方、ソフトウェアは工業製品ではなく、人間が作るものなのでバグはついて回らざるを得ないという主張もあります。一理ありますが、これが免罪符になって品質に対する関心が薄れ、ある程度まで検査したあとに発生するバグは不可避で、発生したその都度直せばいいと言う感覚が、パソコンの普及と共に広がり、今の技術者が、おかしくなったら最初から操作し直す、モグラたたき的にバグは出たら直せばいいという、およそ技術者らしからぬ品質に対する安易な考えを持っているかのような状況に出くわすことがあります。バグは出たら直すものではなく、作り込んではいけないものであること、おかしくなったら最初から操作し直すという対応ができない業務アプリケーションがパソコン上で動いていることを理解しなければなりません。スケジュールが立て込んで来ると、品質を保証するために拠り所となるテストを疎かにし、結果的にトラブルの芽を作り込んでしまうことがあります。担当する技術者はもちろん、プロジェクトリーダや幹部の品質に対する正しい理解が必要になります。

 

※ご質問はosugisama@gmail.comにどうぞ!

※リブログ以外、本ブログの内容を無断で流用することを禁止します。