ホーム
製品情報
ソフトウェア受託開発
システム構築例
コラム
会社案内
お問合せ
  コラム > 仕様の決め方
 
 
       

仕様の決め方

2007/3/9 牧野敏行

システムを構築する時、仕様の決め方で成否が決まる
仕様書をつくり自分自身で何回も何回も見直す
ユーザインターフェースは必ずビジュアル化してレビューする
それでも仕様が変わることが多いが・・使い込まないとわからない改善点も多い
ユーザはあまり真剣に考えてくれないことを前提に仕様を考える
レビューで了承されても運用に入ればどんどん文句、改善要求が出てくる
断言する人が多数いればその仕様はほぼ変わらないと見ていい
あいまいな態度で承認された仕様は変わる可能性が大きい
変わりそうな部分を見極める力が必要 → 変わりそうな部分は変えやすいように作る
1人の意見だけを採用するのは危険、但しその人が十分信頼を置ける場合は採用しても良い
システムを使用しない人(管理職等)の意見はあまり重視しない、でも無視も出来ない
効率アップの鍵を握るシステムを使う人の意見を重視する
初めから難しそうと思って意見が出ない場合も多いので、VEのアイディア発想法が良い
VEのアイディア発想法より        ※筆者は2年間VE業務も経験
@批判厳禁:良いとか悪いとかの批判を一切してはいけない。
A自由奔放:自由奔放に考え,何でも思いついたことをどんどん発言する.
B多数歓迎:できるだけたくさんのアイテアを出す.
C結合改善:すでに出されたアイデアから連想してアイデアを考える.
ちょっとした一言の採用が大きな効果を生む場合がある
全てをわかる必要はないが、システムの操作の流れの要点は理解すべき
仕様変更が発生した場合の修正範囲が少なく出来るように第1次、第2次・・とステップを踏んで
システムを開発した方が良い
稼働したら6〜70%完成で、稼働率が上がって100%完成と考えて開発している
当初の仕様書が8割生きれば御の字と考える
しばらく運用して改善点を洗い出し、なるべくまとめてバージョンアップする
まとめるのは1ヶ月程度とする、ユーザからみどんどん改良されるとういう信頼関係が重要
誤字脱字の修正、表示の改善等の確認作業はほとんどいらない改善は即実施する
1年後くらいにほぼ満足のいくシステムになれば大正解
システムが安定してきたら今後のメンテナンスのために仕様書を修正しておく