アンチ・・・
世の中には多くのコンピュータシステムが開発されていますがその中にはいくつもの「失敗」と見なされているものがあります。「アンチパターン」（ソフトバンク編）の中では「６つの内５つのプロジェクトは失敗と見なされている」となっていますし、「動かないコンピュータ」（日経コンピュータ編）の中にも、さまざまな失敗の例が載っています。当社が扱ったプロジェクトにおいても「これは問題がありそう」とか「このシステムは成功とはいい難い」といったものもあります。 それらの原因は単純でない場合がありますが、ここでは少なくとも「こんな状態は失敗のもと」といったことを経験を元に記述しました。あくまで、「こんな時、プロジェクトは失敗する」ではなく、「失敗の要因になりうる」ということです。
これらを正直に受け止めた上で今後の「プラス要因」として生かす姿勢を持ちつづけたいと考えます。
次のようなプロジェクトは、怪しい。
・最終納期からスケジュールが決まっている。 各作業の実質的なボリュームを考えずに作業比率だけでスケジュール分割している。スケジュールが無理なのは誰の目にも明らかなのに誰もそれを指摘しない場合。あるいは、指摘しても全く無視されるような雰囲気のプロジェクト。
・仕様が十分に見えていないのに、分ったような気持ちになっている。 システム設計の初期の段階でプロジェクトの概要は分るものの、不明瞭な部分が存在し、実際にはその部分のボリュームが大きい場合。（ここまではよくあるケース）そして、開発者が不明瞭な部分をなんとなく分ったように感じている場合に問題が発生する。
プロジェクトのリーダ(SE)が次のような時。
・開発言語を知らない。
自分が携わってきた言語については精通しているがプロジェクトの開発言語を知らない場合、プログラマへの注意や指示がどうしてもチグハグになる。当然、仕様書も携わってきた言語風になり、十分ではない。
・優先順位を把握できない。 例えば、プロジェクトが進んで重大な問題が発覚した場合、まずその問題の把握と対処をすべき時なのに、誰の責任かを追求したり、現状のスケジュールばかりを気にしている。
プロジェクトの担当者（ユーザサイドの管理者）が次のような時。
・担当者自身がプログラムに対して間違った仕様を指示する。
プログラムに対する知識が中途半端にある時に発生する。例えば、データベースで管理すべきデータをCSVなどで使用するように仕様を決定している場合など。そして、仕様の修正は受け付けてもらえないため、チグハグな部分に最後まで引きずられる。
・とにかく相手の責任にする。 プロジェクトを進めていくといろんな問題が発生します。仕様の変更、進行の遅れ、ハードトラブル・・・ ここまではよくある話です。問題なのはその原因をとにかく相手の責任にする場合。自分の責任のありそうな部分はさらっと流し、相手の責任が明白な時はとことん追求する担当者。これでは、信頼関係が崩れてしまいます。
プログラマが次の場合も、非常に怪しい。
・分かったフリをする。
仕様などを説明した時に分かったようにフリをするが、実際には良く分かっていないプログラマ。
・分かりにくいコードを書く。 とにかくコードが見にくい。コメントが少なくてもきれいなコードは見やすい。逆にコメントが多くても構造や変数名が変なプログラムは見にくい。
・プログラムの進捗を正確に伝えられない。 プログラム開発が思うように進んでいないのにそれなりに進んでいるように伝えるプログラマ。納期直前になって、遅れの問題が爆発する。
・プログラムのコードを適当に変更する。 プログラムのデバッグや、パフォーマンスを上げるために適当にコードを変更するプログラマ。変更するのはいいけれど、変更後の結果だけをみて「これでよし」と思う奴。他に与える影響はどうすんでしょう？
完璧な人間はいません。どんなに優秀なSEやプログラマでも最初は素人です。失敗も何度かはしているはずです。重要なのは、失敗を素直に認め、向上する気持ちを持つことです。そうすれば、失敗要因を抱えていても次回のプロジェクトはいいものになるでしょう。