システム開発は100点を取れない！
毎年冬のオリンピックで話題になるのは、フィギュアスケートの点数における判断基準だ。選手がいかに名演技をしていても、審査員は冷静で減点対象をチェックする。われわれ素人から見れば完璧な演技で金メダルをとったとしても、審査員の目、プロの目からすると小さな失敗はいくつかあるのだろう。いくら才能があっても、いくら練習してもなかなか完璧というものはありえない。
われわれシステム屋にとって、オリンピックの本番演技と同様に緊張するのが、実際のユーザーが業務でシステムの本番使用を開始するときである。近年の開発においては開発ツールの進化によって開発生産性が向上したので、プロトタイプを開発してユーザーに評価してもらったり、段階的に機能を付加していくスパイラル開発が主流になっている。それによって、大きな要件漏れはなくなるはず。しかし、実際は以下のような理由で、要件漏れや要件の取り違えが出てくる。
○本当に業務を行っているユーザーは、新システムの検証に時間をかけていられない
特に派遣社員に業務を任せている会社もある。本来の業務に加え、新システムの検証作業を派遣社員に依頼するのは、契約上無理がある。さらに、テストチェックシートは、業務を行っているユーザーには手間が多すぎる。
○IS部門が、業務を十分に知らない
本来IS部門が要件定義書を作成し、新システムのテストをやるべきである。しかしIS部門が会社のすべての業務を詳細まで知っているなんてことは現実にはありえない。IS部門は実際に業務を行っているユーザーとSIerの通訳にしかならない。
新システムが完成し、いよいよ実際に業務を運用開始する。遅かれ早かれ、何らかの問題が出てくると想定するのが当然だろう。このコラムのタイトルどおり、システム開発では100点を取るのが難しいのだ。さて、ユーザーからトラブルが報告されたどうするか？
（1）まずユーザーと協議し業務への影響度、つまり業務続行可能か否かを判断する
（2）業務続行不可ならば、新システムの利用をやめ、旧システムでの利用に戻す。ユーザーの了解の上なら、新システムで入力したデータは、また旧システムに入れ直すのもやむをえない
（3）業務続行可の場合には、プログラムバグの修正やマスタやトランザクションデータの修正を行う
つまり、業務続行は「バグやデータの修正が比較的短期間でできる」という自信がないと苦しいのだ。トラブルが報告されてから一刻も早く判断しなければならない。判断するためには、システムに対する理解や直感が優れていること、業務要件の理解が早いこと、ユーザーとの折衝がうまいことなど、総合的な能力を要する。このような能力がないと、プロジェクトリーダーになってもうまくいかないことが多い。
「本当の要件はユーザーしか知らない」という根本的な命題において、われわれの仕事には大きなリスクが存在する。そのリスクを避ける舵取りをする人に、プロジェクト成功の明暗がかかっている。