*下記はPDFよりテキストを抽出したデータです。閲覧はPDFをご覧下さい。

83 FEBRUARY 2004 ある。
このため当事者以外の目で科学的に状況を分析し、対応して いく必要がある。
開発当事者の努力の限界としては、計画の誤り、マネジメントの 不備、うまく行っていない場合でも経営の視点からは対処できない （自分たちからはなかなか言えない）などの問題がある。
結果として、 当初は目標完遂のために「やるしかない」とがんばるが、結果とし てダメだったというのはありがちな事例である。
いずれのケースに 対応するためにもシステム監査が有効といえる。
4. システム監査 監査とは、「他人の行為について批判的かつ綿密に調べ、その正当 性、適正性または妥当性を判定すること」を指し、外部監査／内部 監査、法定監査／任意監査、会計監査／業務監査などに分類される。
そして、システム監査は「監査対象から独立かつ客観的立場のシス テム監査人が情報システムを総合的に点検及び評価し、組織体の長 に助言及び勧告すると共にフォローアップする一連の活動」と定義 されている。
経営上の問題点やコンピュータセキュリティ上の問題点によって、 システムの信頼性や安全性、効率性が低下することが懸念されるが、 これらの課題解決のために「システム監査」が必要である。
このシ ステム監査は、基本計画書作成（年間計画）→個別計画書作成→予 備調査→本調査（調査・分析・検討）→評価・結論→システム監査 報告書作成、と提出という手順で進められる。
システム監査は元来、内部統制の問題であるから自社で決めれば よいことだが、システム監査のための基準やガイドラインが経済産 業省や総務省から提供されているので参照するといい。
5. アベイラビリティ低下の要因と対応策 アベイラビリティを低下させる要因やリスクには、当事者の努力 で避けられるモノ（たとえばプログラムバグ、設計ミス、運用ミス、 犯罪行為など）と、当事者の努力では避け得ないモノ（たとえばハ ード障害、自然災害、通信回線障害、テロなど）がある。
その対応 策としては「回避」、「軽減」、「受容」といった方策、すなわちリス クマネジメントを行う必要がある。
これをシステムアベイラビリティ向上に適用すれば、「回避」は不 良のないシステムを作ること（システム監査など）であり、「軽減」 は障害が発生しても影響させない、あるいは影響を限定化すること （冗長化・多重化）であり、「受容」は障害が発生しても最低限度の 影響に抑えること（障害対応体制、訓練、緊急時計画など）、という ことができる。
2004年1月のフォーラムは新春特別研究として、日本ロジスティク スシステム協会（JILS）の2003年度ロジスティクス大賞を受賞され たオリンパスのロジスティクス改革について、オリンパスロジテック の酒井路朗氏に解説してもらった。
その内容は次回、このコーナー で紹介する予定だ。
2月のフォーラムはデム研究所の城戸俊二社長による「新しいプロ ジェクトマネジメント（PM）教育方法論」と題した講演を予定して いる。
このフォーラムは年間計画に基づいて開催しているが、単月のみ の参加も可能。
この場合は1回の費用が6,000円となる。
フォーラムに 参加希望の方や、SOLE東京支部の活動内容に関するお問い合わせは sole_consult@jmac.co.jpまで。
SOLE報告 The International Society of Logistics 次回フォーラムのお知らせ SOLE東京支部では毎月「フォーラム」を開催し､ロジスティクス 技術、マネジメントに関する意見交換を行い､会員相互の啓発に努め ている。
前回のフォーラムは12月18日に開催し、冠夢堂システムズ の代表山田一彦氏による講演「アベイラビリティとシステム監査」 を聴いた。
以下、講演の概要を紹介する。
1. はじめに 日本の銀行オンラインシステムは1秒間に数十件のデータ処理を行 う、きわめて高度なシステムだ。
これを維持するために銀行は通常、 社内にシステム監査部門を設けている。
銀行にとってオンライン業 務におけるアベイラビリティの低下は大問題であり、またこうした 大規模な情報システムのアベイラビリティを確保するためには「シ ステム監査」が不可欠である。
本日はシステム障害との闘いについ てお話したい。
2. アベイラビリティの低下がもたらすもの 『日経コンピュータ』誌の「動かないコンピュータ」という記事の なかに、某家電メーカーの事例が紹介されていた。
このメーカーは、 販社や量販店からの注文を受けて物流部門に出荷指示を出すための 新システムを構築したが、大型機を使用したシステムがピークに対 応できず大混乱を引き起こしたという。
処理能力の不足と、数多くのプログラムミスが重なったことが原 因というが、根本原因はプロジェクトマネジメント（PM）がうまく 行かなかったことにあった。
他にも歴史的にみると、1984年の世田谷ケーブル火災、1998年の 東証システムダウン、最近のUFJ銀行、みずほ銀行のトラブルなど、 業務に深刻な影響をもたらした事例は数多くある。
3. システムエンジニア（SE）の使命 アベイラビリティの維持にはトップのリーダーシップも必要だが、 技術者のそれなりの努力が大切だ。
SEの使命は経営が求める情報シ ステムを作って稼動させることだが、その際には当たり前に動くも のを作り、当たり前に動かすことが当然の前提とされている。
SEは、設計〜稼動段階では要求仕様を達成しつつ、障害の起きな いシステムを作ることに注力するが、そこではPMがきわめて重要だ。
運用段階では、SEは障害への対処にも関心を持たねばならない。
では、ここでいう障害とは何か。
たとえ障害が発生しても、すな わちシステムが停止しても、システムに期待されている目的を阻害 しなければ大きな問題ではない。
ハードウエアの障害や災害などは 避けられないものだ。
ようは障害を発生させないことよりも、障害 が発生してもサービスを継続すること（フェイルセーフ）が重要だ。
システムの障害を防ぐための努力や方策にはいろいろあるが、限 界もある。
いかにシステムが完全でも、システムを運用する人間が ミスを犯してはどうにもならず、そのための対処法として事務管理 の徹底とシステム化をあげることができる。
ハードウエアについては信頼性の高いメーカーや機種を選定する など選定時の対応が可能だ。
ソフトウエアについては設計・プログ ラム製造でバグを作らない仕組みが大切で、そのためにはテスト、 PM、開発基準、教育が重要だ。
運用については、使い方を誤らない 仕組み、たとえば自動運用システム、マニュアル（通常時／障害時） の整備、オペ日誌、監視体制などがあげられる。
ここでは二次災害 を引き起こす可能性のある対処時のミスも考慮する必要がある。
しかし、運用フェーズで発生する障害の温床となる問題について は、システムが動いている間は当事者は気づかないというケースも ＳＯＬＥ東京支部フォーラムの報告