| ▲ このウインドウを閉じる |
| He is good for nothing. |
自らの人生を振り返ってみれば、２０年ほど前に、 RDB を日本に導入して、ひたすら、データベースの領域において仕事をしてきました。小生は、いまでも、自らの専門領域は、 DBA だと思っていますし、 RDB のパフォーマンスを（最高速の）極限まで実現する技術に関しては、いまだに、だれにも負けないと自負していますが、世間では、小生の専門領域は、「データ設計」であるとみなされているようですね。 エンジニアが、自らの工具を最大限に活用するなどは当然のことであって、いっぽう、システムを構築するクライアントにしてみれば、工具のしくみを知るのは第一義ではなくて、システムが経営（および、事業）に対して、どれほどに貢献できるか、という点のほうが目的となるのも当然でしょうね。自動車を運転する一般ユーザが、エンジンの構造を知らなければ運転できない、というような前時代的なプロダクトなどマーケットでは拒絶されるでしょう。ただし、プロダクトを設計したり修理したりするエンジニアは、プロダクトの構造（internals）を、当然ながら、知っていなければならない。
エンジニアは、プロダクトの構造（internals）を前提にして、プロダクトの「効率的な」使いかたをエンドユーザに指導しなければならない。エンジニアが、たとえば、データベースを熟知しているかどうか、という点は、モニタリングとチューニングをやらせてみれば、すぐに、技量を見て取ることができる。プロダクトの構造（internals）を知っていれば、的確なモニタリングと適切なチューニングができるが、構造を知らなければ、複数のパラメータを弄り廻しながら、trial and error を繰り返すしかない。構造を超えたパフォーマンスを実現することはできないのだから、構造を熟知していれば、チューニングの限界も言うことができる。
いっぽう、そのプロダクトを使って、事業に役立つシステムを作るためには、「戦略（事業戦略）」が論点になります。「戦略」というのは、環境適応力のことをいいますから、事業に役立つシステムを作るには、当然ながら、事業に関する知識と事業環境に関する洞察力が前提になります。使い古されてきた言いかたですが、「問題点の認知力」と「改善案の提言力」という２つが、システムを作るエンジニアが習得していなければならない技術です。
いかなる事態であれ、それが１つの事態なら、自足しているというのことは当然であって、その事態が構造として問題点を孕んでいるかどうか、という点は、ほかの事態（あるいは、構造）と対比しなければ認知できない。つまり、物事は、対比されて理解される。とすれば、エンジニアは、仕事の前提として、事業に関して、一般化された知識枠を習得していなければならない、ということです。言い換えれば、いくつかのプロジェクトのなかで、job-analysis と称してやってきた体験など、（一般化するには数が少なすぎて）あてにならない、ということです。かといって、「通論」程度のテキストを、数冊、読んで、おおまかな知識を得ても、（最小限の前提知識としては役立つが）システムを実地に作る際には、役に立たない。システムを設計するエンジニアが体得していなければならない知識枠というのは、（「通論」を前提にして、さらに）「原論」といわれている「物の見かた」です--たとえば、経営（management）なら、経営の「モノの見かた」であり、会計なら会計の「モノの見かた」であり、生産管理なから生産管理の「モノの見かた」です。「モノの見かた」のことを「文法」といってもいいでしょう。「文法」は、無意識のなかで使われなければならない。それぞれの領域の「モノの見かた」を習得するには、当然ながら、膨大な読書量と絶大な思考力がなければならないでしょう。 さて、 SE と呼ばれている人たちが、プロダクトの構造（internals）も知らないし、事業の環境適応力を判断できるほどの「事業の文法」も知らないとなれば----「効率」を実現する技術を使うこともできないし、「効果」を実現する思考もできないとすれば--、いったい、なにものでしょうか、、、。 （2003年12月26日）
|
| ▼ このウインドウを閉じる |