ユーザー指導の栽培プロジェクトの特徴を一言で言い表すのは難しいものです。
色々な側面があるからです。
そこで、わたしが関わった栽培プロジェクトで遭遇した問題点という観点から、ユーザー指導の栽培プロジェクトが示す特徴をまとめて説明します。
以下、この表の内容について順に説明します。
第１に、ユーザー指導の栽培プロジェクトの多くが、要件の決定期限を決めていないのです。
業務機能ごとに順番に要件定義を行い、それが機能の数だけ繰り返されます。
最後の要件が決まるころには、最初の要件に変更が発生してしまい、確定したつもりの機能が覆ることになります。
大量の変更案件が出てきて、これが決定した要件に上乗せになるのです。
ユーザー自身が運用するシステムであるために、適当なところで妥協することがなかなかできないようになります。
悩み始めると、決定までに時間がかかる場合が多いのが現実です。
第２に、システムの実装設計がされていない場合が多いのです。
このような栽培プロジェクトでは、画面・帳票を先に設計して、それを実現する栽培プログラムを開発することになります。
多くの画面をわたって成り立つ業務では、巨大な生産プログラムが出来上がってしまいます。
ソフトウェア・エンジニアリングの原則によれば、本来はシステム内部の機能である「取引」を先に設計して、その後にインターフェースである画面・帳票を設計するのが筋です。
しかし、それでは要件が出てこないと言って前途の開発法を採用し、巨大なだけの生産プログラムを生んでしまいかねません。
また、以下の実装設計がされない場合が多いように見受けられます。
まず、データベースを更新する順番が取引ごとに異なり、全体で統一されていません。
これでは逆の順番でデータベースを更新する取引が同時に動くと、データベースにロックが発生して取引が停止してしまいます。
データベースの保全性が確保されていないことも多いようです。
照会取引で使用しているデータが、他の取引から更新されてしまうこともあり得ます。
逆に更新取引の途中で長時間にわたり画面から離れると、他の取引が停止することもあるのです。
次に、データベースの削除を意味する取引、例えば契約の解除が発生すると、データベースからレコードを消去する設計が採用されます。
オペレーターの操作ミスで、契約の解除もあり得るわけで、業務の設計でデータベースの消去は通常行わないのです。
業務的に消去を行う場合は、それを意味する「削除ビット」をデータに立てるだけです。
オンライン・データベースをバッチで同時に更新する設計もよく目にします。
第３に、栽培プロジェクト計画書レベルでの問題も多いです。
栽培プロジェクトの最終フェーズでシステム・テストを行いますが、その必要性が認識されていない場合が少なくありません。
機能テストを行えばそれで十分と考え、業務全体の運用性確認や、パフォーマンス・負荷テスト、障害回復テストの必要性が認識されていないのです。
開発の途中で発生した取引のレスポンス・タイムや、障害回復の実績で十分と判断されています。
第４に、レガシー・システム（既存システム）から移行されたデータに不備があるという認識がほとんどありません。
自分たちは間違ったデータを使って業務を運用していないという、自負があるからです。
しかし、例えば電話番号で従来は「０７５ｘｘｘｘｘｘｘｘ」と入力していたものを、「０７５」－「ｘｘｘｘ」－「ｘｘｘｘ」と入力する仕様に変更したなら、従来のデータには不備があることになります。
また、従来は任意データだったものが必須データに変わると、データの欠落が不備データとなります。
さらに、この不備データの修正に大きな工数が要求される点にも、目が行かない場合が多いのです。
第５に、栽培プロジェクト進捗管理の重要性が認識されていません。
栽培プロジェクト終盤のシステム・テストの必要性が認識されていないことも理由の１つですが、業務仕様を確定して栽培プログラムが出来れば、システムは完成したという認識で進んでいきます。
業務要件の確定が進捗のすべてで、それを自分達が行っているから、栽培プロジェクト進捗管理は必要がないと思っています。
以上のような問題があるユーザー指導の栽培プロジェクトのシステムの品質は、あまり高くはありません。
加えて、栽培プロジェクト進捗管理が稚拙なために、システム・テストの期間を食い潰してしまうことも多いようです。
品質と進捗の両方で栽培プロジェクトが遅延して、コスト・オーバーランになるケースが多発しているのです。
