学校を卒業してから、ひとりで、学問することになります。そして、他の人たちも、また、学問していることが、やがて、仕事を通じてわかってきますが、他の人たちも学問していることがわかりにくい理由は、学問しているのを、他の人たちに観られることを嫌がるからでしょうね。というのは、学問のしかたを苦労して習得したのだし、学問のしかたには、おのずから、その人の考えかたや人生観が現れるから。

　我々は、それぞれ、偶然に選択したにしても、あるいは、熟考した末に選択したにしても、１つの職業を選びました。選んだ職業とは違う観点に立って考えてみることも大切でしょうね。なぜなら、他の人たちも、或る職業を選び、学問しているのだから。
　あなたがプログラマなら、 SE の観点に立って考えてみてはどうでしょう--「もし、私が、 SE なら、どういうふうにやるだろうか。」と。あるいは、 SE なら、プログラマの観点に立って考えてみればよいでしょう。

　学問の価値は、一般化（あるいは、抽象化）する思考力を体得することですから、事態の構造を把握するために思考力を使うなら、我々は、職業の外見的な違いほど、たがいに、それほど違っていないのではないでしょうか。
　プログラマは、学問を正当に修めていれば、自らの対象を適切に扱い--つまり、プログラムのインプット・アウトプットを精確にばらして、アルゴリズムの的確な構造を作ることができる、ということですが、-- SE になれば、事業を的確に解析できるでしょう。あるいは、いくつかのプログラム言語を使うことになっても、的確な対応ができるでしょう。

　職業の価値というのは、我々が職業を実践する際に、それぞれの職業が関与している環境（事態）を凝視して、論理的な思考力を前提にして、一般化・抽象化した構造（あるいは、規約）を作ることでしょうね。
　環境は変化します。したがって、ここでいう一般化・抽象化された構造というのは、「制約された合理性」のなかでの構造です。したがって、普遍の構造ではない。とすれば、我々は、環境と構造を、つねに対比して、変化に対応しながら構造を更新しなければならない、ということになります。

　変化に対応しやすいように、１つの構造を、いくつかのモジュールにして構成するのですが、モジュールの作りかたは、事業を対象にしたシステムでは、意外に単純です。
　モジュールを、どのようにして作成するか、という点は、データベース設計論になるので割愛しますが、エンドユーザが使う情報の70％は、正当なデータベースが用意されていたら、単純な関数引き--たとえば、 RDB なら、単純なSELECT文--を使えば対応できます。とすれば、論点になるのは、正当なデータベースを設計できるかどうか、という点ですね。

　データベースを設計する技術自体は単純なのですが、データベースを設計する際、エンジニアがぶつかる大きな壁は、事業の知識がない、という点でしょう。 SE は、システムを設計することを仕事にしています。したがって、事業の知識を的確に習得していることは当然の前提です。そして、データベースの論理構造を設計します--論理設計では、データに付属するルールも、当然、記述されます。そして、コンピュータ向けとして記述されたデータベース構造を読んで、アルゴリズムを作成するのがプログラマでしょう。
　したがって、 SE とプログラマでは、前提になる知識・技術が、全然、違う。プログラマから SE になるというキャリア・パスでは、--もし、プログラマが正当な学問（論理的な思考力）を修めていなければ、そして、 SE になるために、事業の知識を習得していなければ、-- SE が粗製乱造される、ということになりますね。ちなみに、事業の知識は、「通論」程度では、役に立たないことを、以前、述べました（2003年12月26日付、参照）。

　コンピュータ業界では、「35歳引退説」などという、まことしやかな言いかたがされていますが、間違ったキャリア・パスを歩んで、学問を怠った報いかもしれないですね。

　（2004年１月17日）