|
||||||||||||||||||||||||||
| 1 2 3 次のページ | ||||||||||||||||||||||||||
| いいシステムとは | ||||||||||||||||||||||||||
|
ひとくちに「いいシステムとは何か」を表現することは難しいですが、一般的に言われることとして、(1)使い勝手がよい、(2)汎用性・拡張性に優れている、(3)作り方がシンプルである、などがあるでしょう。 |
||||||||||||||||||||||||||
![]() |
||||||||||||||||||||||||||
| 使い勝手がよい | ||||||||||||||||||||||||||
|
「使い勝手がよい」システムは、業務をよく理解していなければ作れません。一般的な業務知識だけではなく、その会社特有の処理方法などにも精通していなければ、システムを導入したらかえって不便になったなどと言われかねません。 さらに、オペレーション対象を十分意識して、「不特定多数が使う」画面・機能と「限られた人だけが使う」画面・機能を配慮して作ることが必要になる場合もあります。 不特定多数の人が使う場合は、操作マニュアルなどがなくても画面を操作できるくらいに分かりやすいものがいいですし、ヘルプ機能、ガイドなどが随所に表示されていることも必要でしょう。逆に、特定の人だけが使う場合は、その画面操作に慣れていることを前提に作りますから、必要以上のガイドは煩わしさを感じてしまうでしょう。使い込んでくればショートカット機能や、デフォルト値の設定などもできれば、非常に便利なシステムとして認識されるはずです。 |
||||||||||||||||||||||||||
| 汎用性・拡張性に優れている | ||||||||||||||||||||||||||
|
「汎用性・拡張性」は、将来の2次開発やサブシステムが明らかな場合、それを踏まえて基本設計を行い、常に汎用性や拡張性を意識して開発しますので問題はないでしょう。しかし、そのシステムで完結する場合に汎用性・拡張性を意識するかどうかで将来の良し悪しが出てきます。 あらゆる将来的な可能性を想定して設計しなさい、というわけではありません。仮にそんな発想のもとで設計をしたら、無駄な作業が大量に発生してしまいます。汎用性、拡張性についてまずあげられるのが、必要以上にOS、データベースに依存しないで作るということです。この辺は開発会社に対してのお話のようですが、発注側もこういうことを知っていれば、開発手法についての打合わせで話す機会もあるでしょう。 もうひとつ重要なことは、ソースと設計書が一致しているかということです。システム開発では、開発途中に仕様が変わることは珍しくありません。その機能についてのプログラミングがされていなければ設計書の変更で済みますが、既に作ってしまった場合に、変更箇所を付け足したような格好でプログラムを継ぎはぎにしてしまうことがあります。 本来は、仕様変更された設計書に従い、不要な部分を削り、設計書通りに作成することが正しいのですが、プログラムの継ぎはぎは往々にして見受けられることです。こうして作られたプログラムソースとプログラム設計書は、メンテナンスなどで将来それらを見比べたとき、非常に困ります。必要があって設計書の修正を行うときは、くどいくらい発注者側から確認してください。 |
||||||||||||||||||||||||||
| 作り方がシンプルである | ||||||||||||||||||||||||||
|
「シンプルな作り方」というのも重要です。発注側から「なるべくシンプルな設計、プログラムを心がけて」と要求しましょう。シンプルな作り方をすれば、検証作業中も結果を見ることが容易になりますし、たとえ運用中にトラブルが発生しても、事後処理が比較的らくに済みます。 今は容量を気にせずに開発できる環境が整っています。制限があって苦しいデータの持ち方をする必要もなければ、処理時間を気にすることもないでしょう。シンプルな作り方は拡張性にも繋がります。 |
||||||||||||||||||||||||||
|
1 2 3 次のページ |
||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||
|
||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||
|
||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||
|
||||||||||||||||||||||||||


