２２）既有資産は軽視せず最大限に活用する
既開発システムや処理、ツ−ルは流用、転用、代替を図り最大限にその機能を引き出す事が有効なケースもある。 A,B
２３）教育、システム活用に気を配り、ユーザに対する指導性を持つ
ユ−ザ側でのシステム開発に際しての心構えを徹底して貰う事を心掛け、全工程での作業でリ−ダ−シップをとって作業を進め易くする。
その為にはユ−ザの問題点を指摘したり、対案を提出したりして信頼を得ること。又付き合いや節目毎の完了祝い等も企画し、ユーザと開発者との親密度を高める。
技術的には当然出来る事でも”出来る”という表現にもってゆく等ちょっとしたこともユ−ザの信頼感を得る一つの手になる。
ユーザーの現業をそっくりそのまま機械化するよりも、先ず事務処理上の文言、配列などの標準化、統一化を提案すること。
現状の事務処理を機械化しやすい形に出来ないか聞いてみる等、事務処理まで一歩踏み込んだ方が主導権を取りやすい。
たとえ業務知識が無くても、SEにとっては既知の知識でユーザには気付きにくい操作性向上の工夫を提案することは信頼性確保する上で有効である。（例えば入力原票設計に当たり、全角、半角モード変更キイ入力を少なくするために同一モード項目を纒めて配列したり、原票項目並び順と入力順を合わせたり、マウスよりも数字とタブで入力スピードを速くする等々.) A
|
２４）細部の確認
あいまいなまま残した所は、後でボロが出易い。
小さな事でも一つ一つの確認を沢山積み重ねておかないと、後の交渉でリ−ダ−シップがとれなくなる。 A
２５）記述はスピ−デイ−に
レビュ−の為に仕様書は不可欠になる為、スピ−デイに書き上げてしまう手腕が必要である。
全てが決まってから細部まで書くのではなく、大きな構想をラフに描がいてしまう。
システム全体を取り敢えず余白の多い冊子の形にしてしまい、これをベ−スにユ−ザ要求との齟齬をなくす様肉ずけしてゆく。（処理目的１行、ポイント数行／頁） A
２６）仕事の始末
最終段階では余り細部まで手を入れず、一定の成果が出れば程々に切り上げて一端ケリをつけた形にし、整理（数年経ても即取り出せる様ひとまとめにして保管しておく事が大事）と次の仕事準備に取りかからねばならない。
システムには開発者の性格が現れる。
在る程度は剛直にさっぱりとかたずける大胆さが無ければぐずぐずした、いつまで経っても完了しないシステムになってしまう。 D
| |