２７）ユーザー目的中心の割り切り
保守段階で、エラーやシステムダウンなどの各種トラブルでお手上げになってしまった時は、ビクビク深刻になっても、ユーザー、開発者双方とも何にもならない。
腹を括って簡易代替システムをサット作ってユーザーが納得できる出力を得られれば、それで良い。
システムがガッチリ満足行くよう回復しなくても、本来、ユーザーの欲しいものさえ出来れば良い。
手段や完璧なシステムを作ろうとする自己満足より大事な事はユーザーの目的達成である。
この時こそ用意された汎用コマンドを駆使して、データーベース言語の使いやすさを生かせることが多い。A,B,C,D
２８）受注心得
大企業のシステム開発専門ユーザを対象とする汎用機のソフト開発では、開発費の見積もりも在る程度基準が出来ていて、実体と大きくかけ離れることは少ない。
しかし小型機のｿﾌﾄ開発ではｿﾌﾄの価値が確立されておらず、顧客も不慣れで、開発するシステム形態も多伎に渡るため、赤字になりやすい。
それなのに汎用機と同様に、低級言語による単品受注を行っていては採算性は難しい。
|
もっとも最近では、大型機の分野でもERPのようなパッケージ製品による低コスト志向が台頭しているが、どうしても柔軟性に欠ける事は否めない。
小型機では業種別パッケージや汎用ｿﾌﾄによる分野で採算性を上げるか、受注ｿﾌﾄであっても、なるべくプログラミング無しで、ユーザの目的を達するという、より上流のコンサルテーション能力が一番大切になってくる。
なぜならﾌﾟﾛｸﾞﾗﾑ処理が多く、ｼｽﾃﾑ規模が大きいほど、等比級数的にバグが増大し、その対処に忙殺されてしまうからである。
見かけの良さよりも、ｼｽﾃﾑ構造が単純であることが大事である。
要は数億円規模の汎用機の様な、きめ細かい入念なアプリケーションソフトを手がけない事である。
２９）見積りは細部項目まで漏れなく行なう
全体の作業ロ−ド配分、費用の見積りに当たっては、帳票印刷のコストや期間、関連物品手配、操作マニュアル作成、操作指導等全項目を漏れなく拾い上げる事。
設計、プログラミング以外の工程を充分視野に入れておき、全てが予定通り進む様に工程管理を行なう。
進捗管理では、客観的裏ずけを持たせるため、具体的な成果物で期限毎に定量的にチェックする。
遅延の場合は、代替手当てや要員手当てなどで早急にその回復策を講ずる。 D
| |