5月後半、全日本空輸、NTT、JRの情報システムで相次いで事故が起きた。いずれの場合も、些細な操作ミスや切り替え作業が、システム全体が停止するような悪影響を与えてしまい、しかもなかなか原因を特定できなかった。残念ながら今後も、情報システムの事故は続くだろう。そうならざるを得ない構図について、日経ビジネス誌に「ITの07年問題は“逃げ水”　全日空などシステム障害、対応には限界も」という一文を書いた。本欄においては、情報システムの根本的な事故防止策について考えてみる。 情報システム事故の直接原因は、いずれも小さいミスである。しかしそれがより大きな事故につながる以上、現場の情報システム技術者はこれまで以上に細心の注意を払って、システムを開発し、動かし、維持しなければならない。 コンピューターの総合誌、日経コンピュータは6月11日号に「相次ぐ社会インフラの大規模障害」と題した記事を掲載、その中で「

本記事は日経コンピュータの連載をほぼそのまま再掲したものです。初出から数年が経過しており現在とは状況が異なりますが、この記事で焦点を当てたITマネジメントの本質は今でも変わりません。 システム開発プロジェクトの成否はその企業の命運を左右する。しかし，多くのユーザーやインテグレータにおいて，プロジェクトの失敗が絶えない。この状況を打破するには，プロジェクトの進め方を抜本的に革新する必要がある。まず，過去のプロジェクトを洗い直し，問題の所在を調べるべきだ。複数のインテグレータで実態を調査した結果，失敗原因の多くはプロジェクトの開始段階にあることが分かった。 林 衛（はやし まもる） アイ・ティ・イノベーション 代表取締役 「このプロジェクトの目的は結局，何だったのですか」。 「うーん，改まって聞かれると，ひと言で説明しにくいですね」。 「プロジェクトが始まったのはいつですか」。 「実際のソフト

Wikiをうまく活用すれば、プロジェクトの進捗管理表として利用できます。進捗管理者を別途置かなくても、リーダーもメンバーも、各々が参照、記入が可能です。 プロジェクト全体の進捗を把握する上では、Wikiの中の1つのページさえ見ていればOK、という状態を作ることが望ましいといえます。これはリーダーにとってはもちろんですが、メンバーにとっても自分の進捗に加えて、自分が参画しているプロジェクトの状況を把握することで、安心して仕事に取り組むことができます。あるいは、ほかの人のペースにキャッチアップするための指針にもなるでしょう。 これは、戦争において、各部隊が司令官と同じ視点で戦局を見られるようなものです。前線に身を置きながらも、常に全体が見えている状況です。この状態を作ることで、各部隊の行動にムダやムラが少なくなるはずです。 参照項目と更新項目 とはいえ、すべての情報をメンバー全員が更新するのは

筆者は以前，「日経ITプロフェッショナル」という雑誌の編集部に所属していた。そこで，2003年に開発プロセスの特集記事を担当したことがある。ここで言う開発プロセスとは，ソフトウエアを開発する際のエンジニアの役割や手順，作業内容，入力する成果物と作業の結果として出力される成果物，などを定めたものだ。 当時はちょうど，多くのシステム・インテグレータがそれまでの「ウオーターフォール型開発プロセス」の限界を意識し始めた頃で，多くの大手システム・インテグレータがこぞって，反復型やユースケース駆動，アーキテクチャ中心といった特徴を持つ「UP(Unified Process）」を自社の開発プロセス標準の一つとして採用しようとしていた。UPあるいは「RUP(Rational Unified Process）」の“ブーム”と言っていい状況だった※。 ※UPもRUPもIvar Jacobson氏に端を発する開

そもそもなぜプロジェクトは失敗するのか――。前回、まずは1人でプロジェクトマネジメントをしてみようという話を書きましたが、プロジェクトを成功させるためのテクニックに入る前に、“失敗”を考えてみたいと思います。 前回も書いたようにプロジェクトマネジメントというと、何だか小難しい印象を受けますが、基本的には複数のメンバーで実行するプロジェクトといえど、個人のタスクリスト管理の延長にあります。 まずは、プロジェクトが失敗する要素を押さえることで、成功のためのポイントを見つめなおしてみましょう。プロジェクトが失敗する要素――というと、いかにもたくさんありそうに思えるかもしれませんが、実はプロジェクトを失敗させる要素は大きく分けると3つしかないのです。 プロジェクトが簡単に頓挫する3つの要素 無茶な計画 メンバーのやる気 変化を認めない 最初に無茶な計画を立てる プロジェクトを失敗させる最も簡単な方