人間系を利用する |
||
|
機械だけではうまくいかない |
||
|
可能な限り効率の良い設計をと思っていくら考えても、どうしてもどこかで矛盾が生じてしまうということがあると思います。そういうときは、そもそも解こうとしている問題の定義自体が間違いなのかも知れません。だとしたら、いくら考えても無駄なはずです。 |
||
|
どのようにしても効率良く作れそうもないというときは、運用形態もシステムの一部にしてしまうと解決するかもしれません。コンピューターシステムを操作するオペレータ、すなわち人間も、システムの一部とみなすのです。 |
||
使えるものは客でも使う |
||
|
たとえばこれまですべて人の手によって行ってきた事務処理の効率化を目的として、コンピューターシステムを導入することを考えます。普通の発想でとらえれば、これは新規開発ということになります。しかし人間系もシステムの一部と考えるなら、これは既存システムのメンテナンスであるととらえることができます。機械には難しい問題でも人間なら簡単に解決できるということがたあくさんあるので、システムの「一部」をコンピューターに置き換えるのだという認識があれば、人間が得意な部分は人間がやる、コンピューターの正確さが必要な部分はコンピューターでできるようにするという開発方法になるでしょう。 |
||
|
また、このような考え方は「運用形態を含めて設計する」という発想にもつながります。コンピューターを導入する前にもっとも効率の良かった運用形態が、コンピューター導入後もそうだとは限りません。せっかく作るのですから、ソフトウェアがもっとも威力を発揮できるような運用の仕方もセットで考えたいものです。そのためには、要求されるものだけをせっせと開発するばかりでは不十分でしょう。本当に必要なシステムは何を満たしているべきなのかということを、徹底的に議論しなければなりません。お客さんが欲しいと言うものを作ってあげることばかりが我々の仕事ではないのです(それはだれでもできることです)。 |
||
|
よく、パッケージソフトと受託開発されたソフトの差についての議論で、「受託の方が業務形態に馴染むシステムを作れる代わりにコストがかかる」というのがありますが、ただ現在の業務形態にあわせるばかりでは超高級パッケージソフトと変わらないような状態になってしまいます。 |
||
|
そうはいっても、大きなプロジェクトチームに加わっていると、なかなかお客さんと直接会う機会が少ないという現実もありますね。とくに下請け開発などの場合はまったく見込みなしということもあるかもしれません。常に「現場感覚」を忘れずにいたいものです(・・・と、自分に言い聞かせつつ今回は書きました。私が近頃参加しているプロジェクトは下請け開発なんです)。 |
||
|
|
|
|
|||||
(「コーディングの向こう側」は2000年4月から2001年5月にかけて作成されたコンテンツです。)