第３９回：障害を避けられないものとして対策を練るべき[2003-11-9]
　10月3日、東京証券取引所の株式売買システムが、株取引を正常に処理できないという異常事態が発生した。みずほフィナンシャルグループの株式の売買で、本来処理しなければいけない1128株分の売り注文を残したまま、その日の取引を終わらせてしまったのである。新聞等でも大きく報じられたので、このシステム・トラブルをご記憶の方も多いだろう。

第３８回：公的ITインフラのトラブルはどこまで許されるのか[2003-10-10]
　「公共ITインフラ」とでも呼ぶべき、社会生活に欠かせないインフラとしての性格を持つ大規模システム。これらの大規模システムのトラブルはどこまで許されるのか。いささか乱暴なきらいのある記者の問いかけでしたが、本当に皆さんからは示唆に富むご意見を頂きました。

第３７回：カヤの外の国民に残る不満と不安[2003-10-01]
　やはり、住基ネットの現状については厳しい声が多いようだ。システムの共同化事例としての問題点に加えて、導入までの過程で国民一人ひとりが納得できる説明を受けていたとは思えない点を、疑問視するご意見を複数頂いた。住基ネットの今後の運用には、いくつもの課題が残されたままだと言えそうだ。

第３６回：住基ネットはシステム共同化の失敗例なのか[2003-09-12]
　8月25日から住民基本台帳ネットワーク（住基ネット）が本格稼働した。個人情報に関するセキュリティが問題になることが多い住基ネットだが、今回は住基ネットをシステム共同化の一例として考えてみたい。

第３５回：複雑化と不信、不況が運用現場を襲っている[2003-09-03]
　「運用」という、重要であるけれども、これまでなかなかスポットの当たってこなかったテーマを「動かないコンピュータ・フォーラム」で取り上げたところ、皆さんからは非常に参考になるご意見をいただきました。

第３４回：運用ミスと動かないコンピュータについて考える[2003-08-11]
　新システムの開発が減り、運用の重要性が強く指摘されるようになっている。こういう時代には運用の問題によるシステム・トラブルについても考える必要があるのではないだろうか。そこで、今回はシステムの運用と動かないコンピュータの関係について考えてみることにしたい。

第３３回：システム・コストの節約は一筋縄ではいかない[2003-08-01]
　コストの問題は奥が深い。やはり、やみくもなコスト削減はシステム・トラブルを招きかねない。ITコストの削減にあたっての留意点について、読者からさまざまな参考になるご意見を頂いた。

第３２回：システム・コストの節約は「動かないコンピュータ」を呼ぶか[2003-07-11]
　長引く不況の影響を受けて、システム・コストの節約に頭を悩ます企業が増えているようだ。記者が取材していても、システム・コストをどうやって削減すべきかについての話を聞くことが多い。本誌も最近、ITコストに関連した特集をいくつか企画したばかりだが、読者の反響は高い。
　しかし、システム・コストの削減は良いことばかりなのだろうか。暴論かもしれないが、記者はシステム・コストの削減が「動かないコンピュータ」を増やす可能性もあると考えている。そこで、今回のフォーラムでは、システム・コストの節約と動かないコンピュータの問題について考えてみたい。

第３１回：ベンダーの技術力に異議あり[2003-07-03]
　本来プロであるべきベンダーに、技術を知らない技術者がいることは否定できない。とはいえ、ベンダーは自らの利益を追求するもの。雇っている技術者をプロジェクトに参加させるのは当然のことである。動かないコンピュータを減らそうと考えるのであれば、ユーザーはやはりベンダーのシステム開発力をきちんと評価して、問題があれば異議を唱えるべきだろう。

第３０回：「オープンソースの不具合で動かないコンピュータ」への読者の反論から考える[2003-06-10]
　今回の動かないコンピュータ・フォーラムは、本誌5月19日号の「誤算の検証　動かないコンピュータ」に対して寄せられた、読者のメールから考える。「オープンソースのソフトに問題があったかのようなタイトル」については大いに反省した上で、「基礎的な知識のない技術者が開発に携わる」ことがなぜ起きてしまうのか、技術者の選択の実態はどうなっているのかについて、ご意見を頂きたい。

第２９回：「下請けは不可欠」に甘えてはいけない[2003-06-02]
　システムの開発や運用において、下請け会社の利用は避けられない。しかし、下請けの利用が当然だからといって、無反省に現状を受け入れてはならないだろう。発注者や元請けのリスク管理体制の欠如、入札制度の不備、品質よりリストラを優先するベンダーの姿勢など、で現状を変える努力をしていかなければ、第二、第三の防衛庁データ流出事件が起こるのではないか。

第２８回：防衛庁データ流出事件裁判で残った謎を考える[2003-05-06]
　今回の動かないコンピュータ・フォーラムでは、いわゆる防衛庁データ流出事件について、今だからこそ分かる事実を含めて再度問題を提起したい。この事件にも「動かないコンピュータ」にかかわる重要な問題があると思うからだ。

第２７回：リストラで増える「動かないコンピュータ」[2003-04-28]
　読者からも「国産メーカーのリストラが、動かないコンピュータの増加に影響している」とのご指摘が集まった。国産メーカーは2002年度決算で業績を回復させたが、経験豊富な技術者をいかに生かしていくのかについては、残念ながら何も聞こえてこない。

第２６回：国産コンピュータ・メーカーのリストラの影響を考える[2003-04-04]
　近年、日本の大手コンピュータ・メーカーは相次いで大規模なリストラを敢行した。確かにリストラはメーカーの収益を回復させる効果があるが、ユーザーのシステムを構築するという点では、マイナスの影響をもたらしているのではないだろうか。

第２５回：改めて問われる平時のあり方[2003-03-27]
　3月は大規模システムで移行・更新に伴う障害が多発した。そうしたケースは、やはり移行までの準備と危機管理体制のあり方に問題があるようだ。しかし、理想的な準備や体制作りの前に、厳しい現実が立ちはだかる。

第２４回：システムの移行・更新の恐ろしさを考える[2003-03-06]
　3月に入って早々にシステム関連のトラブルが連続して起きた。3月1日の航空管制システムのダウンと、りそな銀行誕生にともなう障害である。両者ともにシステムの移行・更新がトラブルの直接のきっかけだった。

第２３回：日本のネットにも無視できない障害は起きていた[2003-02-27]
　あまり知られてはいないが、実はSQLスラマーによる被害は日本にもあった。ネット障害の問題は、多くの企業にとって無関心ではいられない問題である。

第２２回：大規模化するネット障害にどう立ち向かうか[2003-02-06]
　1月下旬、全世界レベルのネット障害が発生した。韓国では、一時的にインターネットの利用がほとんどできなくなった。障害は次第に大規模化している。今回は、ネット障害の問題について議論してみたい。

第２１回：課題は山積だが、前進あるのみ[2003-01-30]
　今回は、e-Japanの失敗について取り上げた。フォーラム参加者からは、人、制度、ベンダー、セキュリティなど、さまざまな問題の指摘が集まった。e-Japanを成功させるためには乗り越えるべき課題がいくつもあるようだ。

第２０回：e-Japanを失敗させないために[2003-01-09]
　今年はe-Japanの勝負の年といってもよい。本来なら、e-Japanの実現を喜ぶべきなのだろうが、どうもこのままでは上手くいくとは思えないのである。はっきりいえば、失敗する可能性があると言ってもよい。巨大な動かないコンピュータが誕生してしまう、というと言い過ぎだろうか。

第１９回：いずこも同じ人材と専門家の不足[2002-12-24]
　中堅・中小企業が情報化に失敗する理由として、みなさんからいただいた回答は社内の人材、特に専門家が不足していることの指摘が多かった。中堅・中小企業ではトップ自身の責任が重くなる、社内に馴れ合い体質が起こりがち、という指摘もあった。また多くの回答者が「動かないコンピュータは企業規模に関係なく起きる」とした。

第１８回：中堅・中小企業の情報化はなぜ失敗するのか[2002-11-28]
　1980年代のオフコン（オフィス・コンピュータ）の導入を契機に、中堅・中小企業の情報化の歴史もすでに20年が経過した。しかし、依然として情報化に失敗する中堅・中小企業は少なくない。今回は、なぜ中堅・中小企業が情報化に失敗するのかについて考えてみたい。

第１７回：コンサルタントだけを非難できない[2002-11-21]
　「動かないコンピュータとコンサルタントの関係」について、読者の方からいただいたご意見をまとめた。「問題のあるコンサルタントは確かにいるが、結局プロジェクトの成否を左右するのは、コンサルタントを使う企業の力量である」という結論になった。

第１６回：失敗とコンサルタントの関係[2002-10-31]
　5～6年前からの傾向のように思うが、「動かないコンピュータ」になったプロジェクトの原因を調べていくと、コンサルタントに突き当たることが多い。流通、製造、金融の各ユーザーでの失敗例を紹介し、典型的なパターンを抽出してみた。コンサルタントがらみでのプロジェクトの失敗も結局は「経営トップが馬鹿だから」であり、「システム部門と既存システムを手掛けたインテグレータがだらしないから」経営トップがコンサルタントに幻惑されるのである。

第１５回：「わかっちゃいるけどまとまらない」からの脱却[2002-10-24]
　読者の皆さんからいただいた意見で共通していたのは、プロジェクトに参加する大勢の企業から出される要望を、一つのシステムにまとめることの難しさである。この難しさは、単に技術的な面だけでなくプロジェクト参加者の感情面や参加企業の政治的な駆け引きなども問題も含まれる。

第１４回：システム共同化の成否はどこか[2002-09-26]
　「多くの企業でシステムを共同で利用すれば、頭数で割る分、開発コストが削減できる。１カ所でまとめて運用すれば運用コストも削減できる」。しかしなぜか、現実のシステム共同化プロジェクトがこの目論見通りに進まないことも事実だ。システム共同化プロジェクトが、動かないコンピュータを生みやすい原因はどこにあるのだろうか。

第１３回：IT無知への処方箋（下）----経営者が分かる仕組みを作る[2002-09-24]
　「経営者や利用部門の無知から理不尽な要求が押しつけられ、動かないコンピュータが生まれてしまう」。読者からのご意見の紹介を続ける。「ITプロフェッショナル側の努力だけでは無理で、経営の仕組みそのものを変えることが必要」，「小さくてもかまわないから，情報システムがビジネスを成功させる体験を全社で持つことが、情報システムが理解される一つのステップとなる」といった指摘があった。

第１２回：IT無知への処方箋（上）----地道に理解を広げる[2002-09-19]
　「経営者や利用部門が情報システムについて不案内なため、理不尽な要求がITプロフェッショナルに押しつけられることが多い。その結果、動かないコンピュータが生まれてしまうこともある」。この問題について読者から、様々なご意見が寄せられた。代表的な意見を今日と9月24日の2回に分けて公開する。

第１１回：なぜ情報システムは理解されないか[2002-08-29]
　情報システムという言葉を知らないビジネスパーソンはいないと思われるが，その実体を理解している人は専門家を除くと非常に少ない。情報システムを企画，設計，開発，運用，そして保守するとは，いかなる作業なのかについて，多くの経営者や利用者は無知なままである。これが動かないコンピュータの遠因になっている。今回は，この問題について考えてみたい。

第１０回：「可用性はビジネスに応じ判断すべき」だが「ATMは止めるな」[2002-08-08]
　「情報システムの可用性は，企業や組織がビジネスの観点から判断し，決定すべきである」との筆者からの主張にはほぼ全員の方が同意を示された。だが『銀行のATM（現金自動預け払い機）も，経営判断として可用性を極限まで追求せず，別の顧客サービスを提案する銀行があってよいのではないか』という例示には，読者から厳しい反論が目立った。

第９回：システムは止まることもある[2002-07-18]
　情報システムの可用性は，企業や組織がビジネスの観点から判断し，決定すべきである。横並びで「止まらないシステム」作りにこだわるのは経営判断ではない。経営目標に基づいてシステムの可用性を選択し，その結果をビジネスを通じて消費者に問う必要がある。
　弊社を含む報道機関も，その観点からシステム・ダウンをとらえなければならない。ただし再発防止に役立てるため，技術的な原因と対策は専門誌が報道すべきと考える。

第８回：みずほ再生策，異論続出[2002-07-04]
　「みずほ銀行の勘定系システムの一本化は，予定通り進めるべきか，延期ないし白紙撤回すべきか」という大問題に対し，読者の意見も千差万別，異論続出となった。

第７回：求む，みずほの再生策[2002-06-20]
　動かないコンピュータ・フォーラムでは，みずほのシステム障害について，多数の方々の意見を提示してきた。読者の方々はトラブル原因の分析や責任問題の議論を今さら読みたくないであろう。そこで今回は，みずほがシステム一本化を無事完了させ，顧客からの信頼を取り戻すための方策を読者とともに考えたい。
　意見の呼び水として，みずほが今後とるべき施策をいくつか列挙してみる。思いつきのところが多いので，ぜひとも建設的な批判をお寄せいただきたい。

第６回：「みずほ」問題を考える（その3：トップと信頼関係を築く）[2002-06-13]
　「NOと言えなかった，みずほ銀行」についての読者のご意見紹介の最後のテーマは，「NOと言うにはどうしたらよいか」である。結論は，経営トップとシステム担当者の間で信頼関係を築き，経営者にシステムをもっと理解してもらう，という正論にまとまった。経営者と話しやすくするため，リスクを可視化する指標が必要だとの指摘もあった。

第５回：「みずほ」問題を考える（その2：権限と責任）[2002-06-05]
　「NOと言えなかった，みずほ銀行」について，読者の方々から寄せられた意見を引き続き紹介していく。第2回目は，もっとも書き込みが多かった，「権限と責任を明確に」というテーマについて報告する。最初に，開発現場からの告発を紹介したい。

第４回：「みずほ」問題を考える（その1）[2002-05-30]
　「NOと言えなかった，みずほ銀行」について，読者の方々から多数の意見が寄せられた。しかもその多くが相当な長文である。量が多かったので，全3回に分けて，意見を紹介していきたい。第1回目は，ご意見の傾向の総括である。今回もっとも数が多かった書き込みは，「経営トップ，システム担当役員，現場の権限と責任を明確にしておくべきだ」というものであった。

第３回：NOと言えなかった，みずほ銀行[2002-05-09]
　みずほ銀行はなぜ，ミスを防止できなかったのか。問題の中核は「NOと言えなかったシステム担当役員」と言える。みずほのシステム担当役員を指弾することはたやすい。しかし，自分がその立場であったら，NOと言えたかどうか。これは重い問いである。
　今回は，「NOと言えるシステム担当役員」，「NOと言えるシステム部門」を考えてみたい。たいへん難しいとは思うが，皆様のご意見をお寄せ下さい。

第２回：正しくNOと言ってこそプロ----「ユーザーも正しいNOを」[2002-04-25]
　「動かないコンピュータ」対策として，必要なら顧客企業に物申せる「NOと言えるインテグレータ」の条件を読者と議論した。おりしも発生したみずほ銀行のトラブルの原因として，幹部が「NOと言えなかった」ことが注目されている。投稿の中にも「顧客企業のSEこそ，経営側にNOと言える能力が必要」，「ソフト会社などがNOと言える強さを持てるよう，下請けを脱し業界のステータスをあげなければならない」といった意見が見られた。

第１回：「NOと言えるインテグレータ」[2002-04-01]
　日経BP社のWebサイト「IT Pro」の日替わりコラム「記者の眼」で数回，動かないコンピュータに関する記事を書き，読者の方々とやり取りをした。そのときに動かないコンピュータ対策のキーワードとして登場したのが，「NOと言えるインテグレータ」であった。この言葉は結構，評判になったので，本フォーラムの第1回目のテーマとして取り上げることにした。 ・・・