IT業界でプロとして活躍するには何が必要か。ダメな“システム屋”にならないためにはどうするべきか。“システム屋”歴30年を自任する筆者が経験者の立場から、ダメな“システム屋”の行動様式を辛口で指摘しつつ、そこからの脱却法を分かりやすく解説する。（毎週月曜日更新、編集：日経情報ストラテジー）
上司 「このシステム障害の原因を説明してくれるかな？」ダメな“システム屋” 「要件定義があいまいで、このケースへの考慮が漏れたからです」
上 「しかし入力画面からは3種類のケースを選べるのではないのか？」
ダ 「ですから、第2と第3のケースの違いが要件として定義されていないのです」
上 「要件定義では2種類だったものが設計段階で3種類になったということ？」
ダ 「そうです。ちょっと考えれば3種類あるのは当然で、なぜそれが抜けたのか理解できません」
上 「テストケース設定は3種類のケースを設定したのか？」
ダ 「当然ですよ！3種類を選べるのですから」
上 「そうすると、テストでは何をテストしたことになるのかな？」
ダ 「要件定義がダメだってことが確認できたんじゃないですかね」
上 「設計とテストはダメではなかった？」
ダ 「当然ですよ、むしろ要件定義のダメさをカバーしたんじゃないですかね」
上 「要件定義の漏れを設計で発見したがカバーが十分ではなかった、ではなくて？」
ダ 「だって要件定義はユーザーがOK出してるんですよ！」
上 「設計で作った入力仕様もユーザーがOK出してるんじゃないの？」
ダ 「だから、要件定義のヤツらとユーザーがダメだってことじゃないですか！」
上 「・・・（ダメだこりゃ。でも怒るだけ時間の無駄か）・・・」
ダメな理由：チームプレーを崩壊させる人
前回（報・連・相を振りかざすダメ上司）に続いて、人間関係の話題を取り上げます。情報システムの構築には多くの人が関係します。要件定義を担当する人がいれば、設計を担当する人がいます。開発とテストは別の人が担当するかもしれません。大規模なプロジェクトなら、サブシステムごとに担当チームがあり、それらを統括する本部のような役割が別途設けられることもあります。そしてもちろんユーザー、顧客企業の担当者もいます。
言うまでもなく、情報システム構築は1つのプロジェクトであり、プロジェクトチームにはチームプレーが要求されます。
ちょっと違う世界から事例を引いてみましょう。例えば、サッカーで失点したとします。ゴールキーパーのポジションが良ければ、シュートは入らなかったかもしれません。しかし、守備の誰かが相手のシュートコースを防げば、そもそも相手はシュートを打てなかったかもしれません。それ以前に、中盤でのプレスが強ければチャンスを作らせなかったのではないか。さらにそれ以前に味方のチャンスを生かしていれば、そもそも相手にボールが渡ることはなかったのではないか。
サッカーにおける失点という結果は、数々の小さな失敗の積み重ねであり、どこかで誰かが味方の失敗をカバーしていれば、失点は防げた可能性があります。それなのに自分の責任には全く言及せず、他人の責任を追及してばかりいる選手がいれば、チームが強くなるはずがありません。
チームスポーツでは味方のカバーが常識であるように、情報システム開発における品質管理では、ミスや考慮漏れが発生することを前提として、いかにカバーするかに重点が置かれます。もしここに、仲間のミスをカバーする気が無い人がいたらどうなるでしょうか。
自分以外の他人のミスは責任追及をすればよいものと考え、自分のミスは責任回避する。こうしたダメな“システム屋”の行動様式が染みついた人間がいれば、周りの誰もがやる気を失ってしまいます。
